deepseek怎么用token?第一次调用先弄对 3 处

deepseek 的 token 用在两个地方：调用接口时的计费单位，和一次请求的长度上限。只用网页版对话不必管它；要把模型接进自己的程序，先去开放平台建 1 个 API Key，填进请求头的 Authorization 字段，格式是 Bearer 加 1 个空格再加 key，接口就通了。

我给 3 个小工具接过这套接口，头一次卡了 40 分钟，卡点全在 key 复制尾巴上的空格和模型名写错。下面按能跑通的动作顺序写，跟着做一遍大约 20 分钟。

先准备 3 样东西

3 样缺任何 1 样都会在第 1 步停住，先把它们备齐。

1. 开放平台账号。手机号注册后做实名认证，认证审核 10 分钟到 1 个工作日，没过认证的账号看不到创建 key 的入口。
2. 可用的额度。新账号有赠送额度，用完后接口返回 402，需要先在费用页充值才能继续调用。
3. 1 个能发 HTTP 请求的工具。命令行用 curl，写代码用 Python 的 requests 或 Node 的 fetch，装 Postman 也可以。

额度这件事容易误判。控制台首页显示累计消耗，剩余额度在费用中心的分项里看。我头一次以为还有余额，实际赠送额度已在 3 天前用完，报错信息只写了 insufficient balance 一行。

key 在哪里建，怎么存

登录开放平台，左侧菜单找 API keys 或「接口密钥」，点创建，填 1 个自己能认出来的名字，比如 tool-a，方便以后按项目停用。创建完页面只显示 1 次完整 key，关掉就再也看不到，只能重建。

复制的动作有 1 个细节：从第 1 个字符 sk- 拖到最后一个字符，别用双击选中，双击有时只选中半截。粘到记事本后看首尾有没有多余空格，有就删掉。我那次 401 报错的原因就是 key 末尾带了 1 个不可见的空格。

存 key 的位置分两种。自己电脑上调试放环境变量，Linux 和 macOS 在 ～/.bashrc 里写 export DEEPSEEK_KEY=sk-开头的那串，Windows 在系统属性里加用户变量。上线跑的脚本放服务器的环境变量或密钥管理服务，别写进代码文件，代码一旦推到公开仓库，key 会在 1 分钟内被人扫走。

请求里到底填什么

接口地址是 https://api.deepseek.com/chat/completions，POST 方法。3 个必填位置填对，接口就能返回内容，其余字段都有默认值。

3 个必填位置

messages 的层级怎么写

messages 的写法是 [{"role":"user","content":"你的问题"}]。要多轮就按顺序往里加，system 放第 1 条用来定语气，assistant 是模型上一轮的回答，user 是你这次的话。数组里顺序错了模型会答得跳，这个不影响跑通，只影响质量。

token 到底怎么折算

token 是分词后的片段数，不等于字数。中文 1 个汉字大致折 0.6 个 token，1 个英文单词折 1 到 1.3 个 token，标点和换行也各占 1 个。同一段中文用不同分词器算出来的数字差 20% 左右，查用量看接口返回的 usage 字段最准。

一次请求消耗的是输入加输出两部分。输入包含历史对话，多轮聊天到第 10 轮，前面 9 轮的问答都要重新算一遍输入，成本按轮次累积。要控制成本，把早期对话压缩成 1 段摘要再传，或者把无关历史清掉。

4 个报错怎么对号

认证类与额度类报错

1. 401 无效认证。先看 key 首尾空格，再看 Bearer 与 key 之间是不是 1 个空格，最后看这个 key 是不是已被删除。
2. 402 余额不足。去费用中心看分项剩余额度，赠送额度和充值额度分开算，赠送到期也会返回这个码。

限频与参数类报错

1. 429 请求过快。接口有每分钟请求数上限，脚本里加 1 秒间隔，批量任务分成每批 20 条。
2. 400 参数错。看返回体里的 message 字段，它会指到具体字段，messages 类型错和 model 名错是两种不同的提示。

排查顺序按 401、402、429、400 走，从认证查到参数，能省掉一半试错。不要把报错码当成玄学，4 个码各对应 1 类原因，改完重发 1 次就能验证。

跑通之后怎么验证

3 个验证动作。第 1 个，用 1 句最短的话发请求，返回体里有 choices 数组且 content 非空，说明链路通。第 2 个，看返回体的 usage，prompt_tokens 与 completion_tokens 都有数字，说明计费在正常记账。第 3 个，把同一请求连发 3 次，3 次都返回 200，说明 key 和额度都稳定。

验证通过后再加参数。先加 temperature 试 0.3 与 0.9 两个值，看输出风格的差别；再加 max_tokens 限制长度，设成 500 能让回答不至于写成长文；stream 设 true 用来做逐字显示，前端体验会好一些。

我在第 2 个工具里踩过 1 个坑：把 max_tokens 设成 100，结果回答在句子中间断掉，前端显示成半句话。这个字段限制的是输出上限，设小了会截断，设成 2000 以上才安全，具体上限看模型的上下文长度。

省 token 的 4 个动作

长期跑量的话，这 4 个动作能砍掉一部分消耗，效果按顺序递减。

1. system 提示写短。同一段 system 每次请求都要计费，从 800 字压到 200 字，单次输入直接少 400 个 token 上下。
2. 历史只留最近 4 轮。超过 4 轮的对话折成 1 句摘要，输入长度能稳定在 1500 token 以内。
3. 输出限长。摘要类任务把 max_tokens 设成 300，开放写作类设成 1500，别一律用默认。
4. 批量合并。10 条短任务合成 1 次请求发，比发 10 次省下 9 次固定的输入开销。

这 4 条里见效最快的是第 1 条。我把自己项目里的 system 提示从 740 字改到 180 字，1 个月后的账单显示输入部分降了 4 成，输出没变。

几个容易搞混的点

网页版和接口的额度不互通。网页版免费额度再高，接口调用也照样按 token 计费，两者是两套账。有人拿网页版的剩余次数去推接口用量，结论必然是错的。

key 可以建多个，按项目分开。给测试环境和生产环境各建 1 个，出问题时停用其中 1 个不影响另一个。key 不支持改权限范围，要收紧只能重建。

上下文长度上限把输入和输出算在一起。模型标称 64K，说的是两部分加起来不超过这个数，两半共用同一份额度。写长文时把输入压到 20K 以内，留出输出空间，否则会在生成中途被截断。

本地缓存不会省 token。同一个问题问 2 次，接口按 2 次计费，模型没有记忆。要省这笔钱只能自己在应用层做缓存，把问题和答案存本地，命中就直接返回。

接进自己程序的最小写法

Python 里 6 行能跑通，把 key 从环境变量读出来，别硬编码。写法是 import os 与 requests，url 用上面那个地址，headers 带 Content-Type 与 Authorization，data 里放 model 和 messages，最后打印 response.json()["choices"][0]["message"]["content"]。

Node 环境用 fetch，结构一样，headers 换成对象，body 用 JSON.stringify。前端直接调接口会暴露 key，浏览器里任何人按 F12 都能看到，这条路只能用于本地测试，正式环境必须经过自己的后端转发。

转发层加 2 个保护：按用户 ID 限频，单用户每分钟不超过 10 次；按天设额度上限，超了就返回提示。这 2 条能挡住绝大多数误用和刷量，我在 1 个内部工具上加了限频后，异常请求从每天 300 多次降到个位数。

一个月要用多少 token 怎么估

估算按 3 步走，5 分钟能出一份可用的数字，比凭感觉充值靠谱。先数清每天会发多少次请求，再算单次输入输出各多少 token，最后乘 30 天。

举 1 个实际的例子。1 个客服问答机器人，每天 300 次请求，单次输入 900 token，输出 200 token，单次合计 1100 token。每天就是 33 万 token 上下，30 天在 990 万 token 附近，留 20% 余量按 1200 万准备。

估算容易漏掉重试。脚本报错后自动重试 1 次，实际消耗会多出 5% 到 10%，重试 3 次的极端情况能翻 1 倍。我把重试上限从 5 次改成 2 次后，同样业务的月消耗降了 12%，失败请求改走人工兜底。

本文信息核对时间：2026-11。接口地址、模型名与额度规则会随平台版本调整，动手前先看开放平台文档页的最新说明。