很多人想先不花钱试一下 DeepSeek，卡在三件事上：免费额度从哪来、Key 拿到之后请求怎么写、跑着跑着突然不通了不知道是额度用完了还是代码写错了。这篇不聊模型好不好，只讲工程落地：一条最小可跑通的调用路径、额度与限流的判断方法、以及把免费渠道用稳的几个动作。
很多人想先不花钱试一下 DeepSeek，卡在三件事上：免费额度从哪来、Key 拿到之后请求怎么写、跑着跑着突然不通了不知道是额度用完了还是代码写错了。这篇不聊模型好不好，只讲工程落地：一条最小可跑通的调用路径、额度与限流的判断方法，以及把免费渠道用稳的几个动作。
先说清楚边界：免费额度通常只够做原型验证和本地调试，不适合直接挂生产。下面给的路径你可以照着走一遍，半小时内应该能跑出第一个返回；跑通之后再决定要不要上付费口径。
免费额度从哪来：先把获得渠道分清楚
免费额度不是一种东西，来源不同，限制口径也不同。常见三类：官方平台给新账号的赠送额度、云厂商模型广场里的试用额度、聚合或中转平台赠送的体验额度。三者的可用模型、有效期、并发上限都不一样，别拿一家的经验去套另一家。
| 来源 | 典型限制 | 适合拿来做什么 | 不适用场景 |
|---|---|---|---|
| 官方平台赠送 | 额度有有效期、并发低、部分模型不参与 | 单个模型跑通、接口联调 | 多模型对比、批量跑数据 |
| 云厂商试用 | 绑定实名或企业认证、额度口径不一 | 试用该云上部署的模型 | 跨云切换、长期在线服务 |
| 聚合/中转体验 | 额度小、模型池杂、稳定性看平台 | 快速比几个模型的手感 | 对稳定性有要求的业务 |
拿到额度后先确认四件事：能用哪些模型、额度是金额还是次数、有效期多久、并发上限多少。这些一般在控制台或平台文档里，核对时以站内 DeepSeek 官方价格与规格页的说明为准；国产平台额度规则改得快，具体数字到官方 API 价格页和大模型平台目录页看当时的页面。
最小调用怎么写：三板斧够用了
第一次调用不要写完整业务逻辑，就写一个最小的请求：一个地址、一个鉴权头、一个最短的消息体。跑通这个，后面所有问题都好定位。
- 拼请求地址把平台给的接口地址和路径拼对。拼错最常见的结果就是 404。写完先单独用命令行请求一次，确认能通，再去改代码。
- 加鉴权头把 Key 放进请求头的 Authorization 字段，注意前缀和空格。Key 只在服务端用，别塞进前端页面或浏览器请求里，一旦泄露只能作废重发。
- 构造消息体按平台要求的角色和内容结构传一个最简单的提示词。先跑非流式，返回正常了再换流式；参数含义不清时对照站内基础概念词典。
- 验证返回返回异常先看错误类型和状态码，再回头看代码。401、403、404、429 分别对应鉴权、权限、路径、限流，别一律当成额度用完。
# 只做连通性验证，Key 用环境变量传，别写死在脚本里；\n# 具体地址与模型名以站内 DeepSeek 官方价格与规格页当时的口径为准\ncurl -sS -X POST \"$BASE_URL/chat/completions\" \\\n -H \"Authorization: Bearer $API_KEY\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\"model\":\"$MODEL_NAME\",\"messages\":[{\"role\":\"user\",\"content\":\"你好\"}]}'这条命令的作用是排掉「代码问题」这个变量。如果命令行能通、代码不通，那问题基本在代码里的请求库、代理配置或者转义上，而不是额度和网络。
免费渠道怎么用稳：超时、限流、降级三件事
免费渠道的稳定性天然不如付费，但大部分「跑着跑着就不通」都是可以提前防的。核心就三件事：超时怎么设、限流怎么退、出问题往哪降。
- 超时按连接、读取、整体分开设。免费渠道排队时间长，读取超时要给够，但整体超时必须设上限，避免请求挂在那里不动把调用栈占满
- 免费额度并发通常很低，批处理任务串行或小并发跑。触发限流走指数退避重试，重试次数设上限，别无限重试把额度烧完
- 准备降级路径：主渠道报错时切到备用模型或备用平台。切换逻辑写成配置项，不要写死在业务代码里，否则换渠道要改代码
- 每次请求把模型、耗时、状态码、token 用量记进日志。出问题先看日志判断是额度问题还是网络问题，字段口径可以参考站内 Session 转换器这类工具的习惯写法
| 现象 | 更可能的原因 | 先做什么 |
|---|---|---|
| 固定时间点集中失败 | 免费额度或并发上限被触顶 | 看日志里的状态码分布，把任务错峰 |
| 请求偶发超时 | 读取超时设得太短或上游排队 | 调大读取超时，整体超时保留上限 |
| 换台机器就不通 | 网络出口或代理配置不同 | 用命令行在同环境再测一次 |
| 所有请求都 401 | Key 失效或鉴权头格式不对 | 检查前缀空格，必要时重新生成 Key |
这张表不是穷举，但它能让你在五分钟内把问题范围缩小到某一类，而不是从头怀疑整套代码。
验证与排错顺序：别一上来就改代码
排错最怕顺序错。正确的顺序是：先确认接口能不能连通，再确认鉴权对不对，然后看请求格式，最后才怀疑代码逻辑。顺序反了，容易在无关的地方改半天。
连通性单独用工具测一次，可以到站内接口测速页量出你当前网络下的延迟基线，之后变慢了还是本来就慢才有得比。把最小可复现的请求体留下来，报错时直接拿它去测，别在完整业务代码里大海捞针。
还有一个容易被忽略的动作：把每次切换渠道的原因记下来。是额度用完了、被限流了，还是模型返回质量不达标，原因不同，后续的处理方式完全不同。记满一段时间，你自己就能判断这个免费渠道到底值不值得继续用。
如果你在中转平台拿的体验额度，先看它的可信度记录再决定要不要接进项目。免费的东西省的是钱，搭进去的是排查时间，这两者要一起算。
下一步想确认某个中转平台的免费额度靠不靠谱，先去可信度档案页看它的历史表现和检测记录，再决定要不要把 Key 接进代码。→常见问题
免费额度和付费额度在调用方式上有区别吗？
调用写法基本一样，区别在限制：免费额度通常并发更低、可用模型更少、有效期更短，还可能排队。所以代码层面要按最严格的限制写，比如默认低并发、超时给宽、失败可重试，这样换到付费渠道时不用大改。
Key 拿到了但一直调不通，从哪查起？
按顺序排：先用命令行单独发一次请求确认地址和鉴权对不对，再看返回的状态码属于哪一类，然后核对请求体的字段名和层级。多数情况是地址拼错、鉴权头格式不对或请求体多包了一层，三种都能通过一次最小请求定位。
自己写的请求偶尔成功偶尔失败，是什么问题？
大概率是限流或网络抖动，不是代码错。先看失败时的状态码和返回提示，如果是频率类提示就把并发降下来、加退避重试；如果没提示、时快时慢，多半是链路问题，可以到 AI 服务监控（/ai-status） 看看当前服务状态再判断。
