deepseek怎么用token?API调用每一步点哪里

DeepSeek 的 token 有两层含义：计费用的计量单位，调接口用的 API Key。做开发要去开放平台建 Key，网页聊天不用管 token。换算上，1 个汉字大致折 0.6 个 token，1 个英文字母折 0.3 个。

我给两个内部小工具接过这套接口，前后折腾了 3 天。真正耗时间的环节不在写代码，在实名审核没过、Key 写进前端被人刷了两百多次、max_tokens 没设让摘要断在半句。这三件事下面都写了处理办法。

先分清两件事：聊天不用 key，接口才用

打开网页版或 App 直接对话，走的是平台自己的账号体系，用户看不到 token，也不为 token 付费，只受每日次数与模型档位限制。这条路径适合写材料、问问题，跟开发没关系。

调接口是另一条路径。你拿一把 Key，按发出去和收回来的 token 数量结算，费用从账户余额里扣。同一句问话，接口调一次和网页问一次，模型可能一样，计费方式完全不同。

有人问「deepseek 怎么用 token 登录」，多数是把 Key 当成了登录密码。Key 不用于登录任何页面，它只出现在 HTTP 请求头里，面向程序。

先准备：3 样东西，缺一样都调不通

1. 开放平台账号。手机号或邮箱注册 platform.deepseek.com，注册后要完成实名认证，没实名拿不到能用的 Key。
2. API Key。进「API keys」页面点创建，Key 的完整内容只在创建那一刻显示 1 次，页面关掉就只剩前 4 位。
3. 余额。按量扣费，余额为 0 时接口返回 402，充值要手动操作，平台不做自动续费。

三样里最容易漏的是实名。我第一版代码调试时一直返回 401，换了 3 个 Key 都一样，后来在控制台看到账号状态写着「待认证」，审核通过当天就通了。

本地环境只要求能发 HTTPS 请求。用 curl 就能测，不必先装 SDK。装 SDK 反而多一层版本问题，第一次调通之前，命令行的反馈最直接：返回体、状态码、耗时，一眼能看完。

调用接口的 5 步，每步点哪里

第 1 步，确认接口地址。这套接口按 OpenAI 的格式设计，base_url 填 https://api.deepseek.com，聊天接口的路径是 /chat/completions。地址末尾不要带斜杠，多一个斜杠就是 404。

第 2 步，定模型名。常用两个值：deepseek-chat 走通用对话，deepseek-reasoner 先输出思考过程再给答案。模型名写错返回 400，报错文本会列出当前可用的模型名，照着抄一遍就对了。

第 3 步，把 Key 放进请求头。写成 Authorization: Bearer 加 1 个空格加 Key，漏掉 Bearer 这个词照样 401。Key 只能放服务端，前端 JS、小程序源码、App 安装包里都不要出现。

第 4 步，设 max_tokens。它是输出上限，不填走默认值，长回答会在半句断掉。写摘要给 500 到 800，写 2000 字文章给 2500 以上，留 20% 余量。

第 5 步，读返回里的 usage。prompt_tokens 是发过去的量，completion_tokens 是模型回过来的量，total_tokens 是两个相加。扣费按前两个分别计价，输出单价高于输入。

参数怎么填：6 个字段的对照

token 数量自己怎么估

中文按 1 个汉字 0.6 个 token 估，英文按 4 个字母 1 个 token 估，误差在 10% 以内。要准确数字就用平台文档里的分词工具在本地跑一遍，几千字的稿子跑一次 2 秒。

上下文长度是一条硬线。超过上限的请求会被直接拒绝，返回 400，不做自动截断。一份 3 万字的材料要拆成 3 段发，每段都带上同一段背景说明，否则前后文的指代会乱。

拆段的时候按章节砍，别按字数砍。按字数砍容易把一张表格或一段引用劈开，模型读到半张表，答出来的结论就偏了。

多轮对话怎么带上下文

接口本身不记状态。第 2 轮要把第 1 轮的问答一起塞进 messages 数组，模型才看得见前文。塞得越多，每次请求越贵，因为输入是重复计费的。

我的做法是保留最近 6 轮原文，更早的压成 1 条摘要，放在数组最前面。一套 10 轮的项目问答，这样处理后输入量从 8000 token 降到 3200 左右。

6 类报错，先看状态码

1. 401 Unauthorized。现象是建好了 Key 还是不通。原因多半在复制时带了空格，或账号没实名。重新复制 Key 去掉首尾空白，再去控制台看账号状态。
2. 402 Insufficient Balance。现象是前几天能跑，今天全挂。余额扣完了。充值后立刻恢复，不需要重建 Key。
3. 400 Bad Request。现象是偶发失败，换一段话又好了。问题在参数或消息格式，比如 messages 里缺 role，或者 content 传了 null。
4. 422 Unprocessable Entity。现象是每次都失败。messages 直接传了字符串，套一层数组就好。
5. 429 Too Many Requests。现象是并发一高就报。触发了速率限制，把并发降到 2 到 3，请求之间加 200 毫秒间隔。
6. 500 或 503。现象是间歇出现。服务端过载，客户端做 3 次重试，间隔 2 秒、4 秒、8 秒，仍然失败就放弃这一次。

怎么确认真的调通了

1. 看返回体的 finish_reason。值是 stop 说明正常收尾，值是 length 说明撞到了 max_tokens 上限，回答被截断。
2. 看 usage 三个数对不对得上。total_tokens 应等于前两个相加，对不上说明中间发生过重试。
3. 去控制台用量页看当天消耗。调用成功后 1 到 2 分钟内出现一条记录，带时间、模型名和 token 数。

验证时故意发一句很短的话，比如「回复 ok」，返回的 completion_tokens 应该在 5 以内。这个数字是判断计费有没有异常的基线，后面每次改代码都拿它比一下。

Key 泄露了怎么办

控制台里点删除，30 秒内旧 Key 失效，再建一个新的。已经产生的费用不会退，但能止住继续被刷。我那次泄露是因为把 Key 写进了示例网页，2 天被刷 200 多次，删除后当场就停了。

规范做法是每个环境一个 Key：开发一个、线上一个、临时测试一个。哪个环境出问题就删哪个，其余两处不受影响。三个 Key 共用同一份余额，账单里按 Key 名字区分，超支时能定位到具体项目。

成本怎么控，3 个动作

第一个动作是压输入。同一段背景反复发给模型最费钱，把固定说明放进 system 消息，别每次都塞一遍。

第二个动作是压输出。max_tokens 按任务实际需要设，写摘要设 800 和设 4000，单价一样但消耗差 5 倍。

第三个动作是缓存重复问。同一批数据跑第二遍之前先看结果文件，能复用的直接读本地，别重跑接口。

批量任务还有一条经验：把 100 条短问题合成 1 次请求，让模型按编号输出，比发 100 次请求省下大量固定开销。代价是单条出错时整批要重跑，所以每批控制在 20 条以内。

不写代码怎么用 token

网页版和 App 里的对话不扣 token，也不显示 token，只按次数与模型档位限制。想在网页端看到 token 数，只能看接口返回。

要给非技术同事用，做个最简页面：一个输入框、一个按钮、一段结果区，Key 放后端环境变量。这种页面 1 个下午能写完，比让每个人去学接口省事。

3 个常见误解

1. 以为 token 就是字数。同一段中文，分词后可能多出 40% 的量，报价按 token 算，估算按字数算，两头对不上。
2. 以为 Key 能直接给客户。Key 等同账户权限，给了别人等于把余额交出去。要给别人用就做一层自己的接口，转发请求。
3. 以为换了模型就不用改代码。deepseek-reasoner 的返回里多一个推理字段，老的解析代码会读不到正文，改 2 行取值逻辑就行。

还有人把接口当成网页搜索来用。它没有联网能力，问当天的新闻会得到一段看起来合理但没有来源的话。要联网得自己先抓页面，再把正文塞进 prompt。

最后一个细节：请求超时时间别用默认。长文生成经常跑到 40 秒以上，客户端默认 30 秒就断，断掉的钱照样扣。把超时改成 120 秒，成功率能从六成提到九成。

这些参数在文档里都写着，第一次接的人容易跳过。花 20 分钟把上面那张表对着文档核一遍，能省掉后面几天的排查。

本文信息核对时间：2026-11