DeepSeek 的 token 怎么用，3 个查看入口与用量核对方法

DeepSeek 的 token 是计费和算上下文长度的单位，聊天网页里不显示这个数字，开放平台的用量页和接口返回里的 usage 字段才给。记 3 个数就够：1 个汉字约 0.6 个 token，输入和输出分开计，一次请求的总量不能超过模型的上下文上限。

上个月帮一家做五金件的客户核账，5 个人共用 1 个 key，月底费用是预估的 2 倍多。翻调用记录才看清：有个脚本把 8000 字的工艺文件整篇塞进每次请求，一天跑 300 多次，光输入就吃掉几十万 token。改成分段摘要后再跑，同样的活降到原来的 1/5。

这篇按「准备什么、在哪看、参数怎么填、报错怎么排、怎么确认省下来了」写。文中数字对应 2026 年 11 月网页与开放平台的实际界面，模型版本迭代后字段名可能增加，位置不变。

一、开查之前要准备什么

缺下面 4 样里的任何一样，都会在某个页面被卡住，先补齐再看数据。

1. 账号：网页版 chat.deepseek.com 与开放平台 platform.deepseek.com 是 2 套登录，手机号注册的账号两边通用，用微信登录的要在开放平台单独绑手机号。
2. API key：只在开放平台「API keys」页生成，生成时整串只显示 1 次，关掉页面就看不到了，必须当场复制到本地文件。
3. 余额或免费额度：开放平台的「充值」页能看到剩余额度，没有余额时接口返回 402，这不是 token 超限。
4. 一次真实调用：空白账号没有任何用量记录，用量页是空的，先跑 1 次最小请求再回来看。

第 4 条常被跳过。我见过有人拿着空账号问「用量页为什么是 0」，其实是从来没调过接口，页面没数据可显示。

二、token 在哪看，3 个入口各看什么

入口 1：开放平台用量页

登录 platform.deepseek.com，左侧菜单点「用量信息」，页面顶部有按日汇总的折线，下面一张按模型拆开的表。表里 4 列要分清：输入 token、输出 token、缓存命中、请求次数。缓存命中那列是重复前缀被复用的部分，单价低于正常输入，做长文档问答时这列数字会很大。

入口 2：接口返回的 usage 字段

每次调用的响应体末尾都有 usage 对象，包含 prompt_tokens、completion_tokens、total_tokens 3 个字段。这个数字比用量页细，能落到单次请求。抓 1 天的请求日志，把 total_tokens 求和，与用量页的当日合计对一遍，差得远说明有请求没走你统计的那个 key。

入口 3：网页版对话里的上下文提示

网页版不直接显示 token，只在对话框上方显示「上下文已用 xx%」。这个百分比按当前会话的累计长度算，开新对话就归零。想估算单段文字多少 token，把文字粘进开放平台的 tokenizer 演示页（「文档」→「Token 计算」），页面会给出逐段切分结果。

三、参数怎么填

接口调用时 4 个字段决定 token 花多少，填错的地方集中在 max_tokens 和 temperature 上。

max_tokens 的含义是上限不是目标。填 8192 并不代表一定输出 8192，但模型判断失误时会一路写到底，这 1 项是失控成本的主要来源。给客户改脚本时我固定把它压到业务需要的 1.5 倍，月度费用波动从 ±60% 收到 ±10% 以内。

输入侧更值得省的地方

输入 token 通常占总量的 7 成以上。3 个动作能明显压下来：把重复的系统提示放在消息数组最前面（命中缓存后单价低），把长文档先切段只送相关段，把历史对话按轮数截断而不是全量回传。

四、卡住了怎么排查

1. 返回 400 且提示 context length exceeded：单次输入加输出超过模型上下文上限。现象是短问题也报错，原因是历史消息累积没清。把最早的几轮对话删掉，或改成分段送。
2. 返回 402：余额不足，与 token 无关。去充值页看余额，充完 1 到 2 分钟生效。
3. 返回 429：请求频率或并发触顶。现象是脚本前几十次正常、后面连续失败，加 1 秒间隔或降低并发数即可。
4. 用量页数字与自建统计差 3 倍以上：多个人共用 1 个 key，或有服务在别的机器上跑。按 key 拆分，1 个业务 1 个 key。
5. usage 里 total_tokens 明显大于输入加输出之和：请求带了工具调用或多轮重试，把重试次数打日志看一眼。
6. 缓存命中列一直为 0：每次都把变动的文字放在提示最前面，前缀对不上。把固定部分挪到最前，命中率会上去。

第 1 条和第 4 条占了实际报障的多数。前者是写法问题，后者是管理问题，跟模型本身没关系。

五、怎么确认真的省下来了

1. 对比同一天的用量页合计：改动前后各取 1 个完整自然日，看输入 token 那列的降幅。取 1 天不够，取 3 天取中位数更稳。
2. 看单次请求的 usage 均值：抓 20 条日志算平均 total_tokens，均值下降说明省的是常态而不是偶发。
3. 看缓存命中占比：这个比例从 0 涨到 3 成以上，说明前缀复用生效了。
4. 看输出质量有没有掉：抽 10 条结果人工读，摘要漏点、抽取错位就要把 max_tokens 或截断策略调回来。

我自己的习惯是把这 4 个数记进 1 张表，每周一填 1 行，连续 4 周就能看出改动是真有效还是被业务量增长盖过去了。

六、不调接口怎么估 token

写方案、做预算的时候手上没有调用记录，要靠估算。3 个办法的精度从粗到细，选 1 个够用就行。

1. 按字数折算：中文 1 个字算 0.6 个 token，1000 字约 600 个 token。这个方法误差在 15% 以内，够做月度预算。
2. 按字符数折算：1 个 token 平均对应 1.5 个汉字，也就是 1000 字约 666 个 token。与第 1 条差 10% 左右，取中间值更稳。
3. 用官方 tokenizer 逐段算：把文字粘进演示页，页面给出精确切分。适合核对异常账单，不适合日常估算。

英文和代码的折算比例不一样。1 个英文单词约 1.3 个 token，1 行普通代码约 10 到 15 个 token。混排内容按两种语言各自字数分别折算再相加，比整篇按中文系数算更接近实际。

我给自己定的粗算口径是每 1000 汉字 650 个 token，报预算时再上浮 20% 作为余量。按这个口径给 6 个客户报过成本，结算时偏差都在 1 成以内，其中 1 次偏低的客户是因为把历史对话全量回传，长度比预估多出 3 倍。

七、几个容易踩的细节

中文和英文的 token 比例不一样，1 个汉字大约 0.6 个 token，1 个英文单词大约 1.3 个 token。同一段 1000 字的中文，换成英文表达后 token 数可能翻倍， multilingual 场景按目标语言估算更准。

网页版和 API 是两套计费。网页版免费额度用完后限流，不扣 API 余额；API 按量扣费，两边额度不互通。有人把网页版的「今日剩余」当成 API 余额，充了钱还觉得没到账。

模型版本升级会改上下文上限，旧脚本里写死的长度判断会失效。把上限做成配置项，别写进代码常量，升级时改 1 个数字就行。

最后提一句团队管理：1 个 key 多人用时，用量页只给合计，分不清谁花的。按人按业务各开 1 个 key，月底对账不用翻日志。文中界面与字段位置对应 2026 年 11 月的版本，入口名称若有调整，看开放平台首页导航当时的叫法。

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