deepseek怎么用token?先看这3个扣费与查看入口

DeepSeek 的 token 是计费和长度单位，1 个汉字大致等于 0.6 到 1 个 token，1 个英文单词大约 1.3 个 token。想知道自己用了多少，两个地方能看：开放平台的「用量信息」页按天记录调用次数与消耗，接口返回体里的 usage 字段给每一次请求的 prompt_tokens、completion_tokens、total_tokens。

我用它跑了 3 个多月的接口，日常查询和批量改稿都在用，下面按「先准备、再看数、再省」的顺序写，每一处都标清登录后点哪个位置。

先准备：3 样东西缺一不可

动手之前要把账号、密钥、余额三件事落实，任何一项没到位，后面都会在同一个地方卡住。

1. 账号：在 platform.deepseek.com 注册，用手机号或邮箱都行，注册完先做实名，未实名的账号调用会返回权限类错误。
2. 密钥：左侧菜单「API keys」→「创建 API key」，复制出来的字符串只显示 1 次，关掉页面就找不回，先存到本地文件。
3. 余额：左侧「充值」页看当前可用额度，新账号一般有少量赠送额度，赠送额度用完会直接报余额不足。

密钥不要写进前端代码或者公开仓库。我在 2026 年 9 月帮一个客户排查过一次，密钥被贴进了网页源码，2 天内被刷掉大半额度，最后只能作废重建。

在哪看 token 用了多少

三个入口对应三种颗粒度，按你要回答的问题来选：查趋势看用量信息页，查单次看接口返回，查钱看账单明细。

入口一：用量信息页

登录后点左侧「用量信息」，页面默认显示近 7 天的调用次数与 token 消耗，可以切到 30 天。这个页面给的是按天汇总，能看到哪一天突增，但看不到具体是哪一次请求吃掉的。

我一般每周一看一次，把上一周的日消耗对一遍。连续 3 天消耗翻倍，基本就是有脚本在循环调用，或者某段提示词写得过长。

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

每次调用成功，返回的 JSON 里有一个 usage 对象，包含 3 个数字：prompt_tokens 是你发过去的输入量，completion_tokens 是模型吐出来的输出量，total_tokens 是两者相加。官方文档里也给了缓存命中的细分字段，命中缓存的输入部分计费更低。

写代码时把这 3 个数打进日志，排查长文本任务特别有用。上个月有个批量摘要的任务，单次 total_tokens 跑到 3 万多，后来发现是把整份 80 页的 PDF 一次性塞进去了。

入口三：账单与明细

「费用中心」里能按天看扣费明细，颗粒度到调用类型。查「为什么余额掉得比预期快」时用这个页面，把每天的 token 量和扣费额对一下，能算出自己实际的平均单价。

这张表里第 2 行最容易被忽略。很多人只看总量，不看输入和输出的比例，结果一直在优化输出长度，实际问题出在输入那一侧。

一个请求到底吃多少 token

token 数量和字符数的换算不是固定的，中文、英文、代码、标点的比例都不一样。下面这组数是按官方分词器实测出来的量级，够用来估预算，不要当精确值。

按这张表估，一篇 2500 字的中文长文大约是 1700 到 2000 个输入 token。如果提示词里再塞一份参考资料，总量很容易翻倍，这就是很多任务单次消耗远超预期的原因。

上下文上限怎么算

模型的上下文窗口是把输入和输出加在一起算的。假设上限是 64K，你发了 60K 的输入，剩下给回答的空间只有 4K，回答写到一半被截断就是这个原因。

实际操作里把输入控制在窗口的 70% 以内比较稳。要读的长文档超过这个比例，先拆成几段分别处理，再把结论汇总，比硬塞进去成功率高得多。

怎么把 token 省下来

省钱的动作都发生在写提示词和拆任务这两个环节，模型参数能调的空间不大。下面 5 条是我实际用下来最见效的。

1. 把固定的系统提示词放在最前面，内容不要每次改一个字。前缀稳定才能命中缓存，命中后这部分的单价明显低。
2. 长文档先做一次结构化抽取，只把抽出来的字段喂给模型，不要把原文整份传。80 页的合同抽成 20 行要点，输入量能降到原来的十分之一。
3. 限制输出长度。多数接口有 max_tokens 参数，设成任务真正需要的上限，避免模型把话说满。
4. 批量任务分批跑。一次 50 条比分 5 次各 10 条更容易触发超长上下文，而后者失败重试的代价小。
5. 调试阶段用短样本。提示词没调好之前别拿全量数据试，先用 3 到 5 条样本把逻辑跑通。

第 1 条和缓存有关，效果最直接。我把同一份 1200 字的角色设定固定下来之后，连续调用的输入费用降了大约 40%，这个比例和第 1 周与第 2 周的账单对比能对上。

常见报错怎么排查

调用失败的信息都不长，但对应的问题差别很大。下面列的 5 种覆盖了我遇到的大部分情况。

第 4 种最难查，因为错误信息不会说明是空白字符的问题。我的做法是把密钥写进环境变量，代码里只读变量，从根上避免复制粘贴带进来的隐藏字符。

输出被截断的两种情形

一种是参数限制，max_tokens 到顶就停，特征是每次都在同一个字数附近断。另一种是上下文占满，特征是前面聊得越长，后面回答越短。

区分办法是看返回的 finish_reason 字段。值表示长度到顶就是第一种，改参数；没有正常结束标记就是第二种，要清理历史消息。

怎么确认额度还够用

三步能形成一个闭环，每周花 5 分钟就够，不用天天盯。

1. 看日均消耗：用量信息页取近 7 天总数除以 7，得到一个基线值。
2. 算可用天数：可用额度除以基线值，低于 14 天就该充值了。
3. 核异常波动：把最近 3 天的日消耗和基线比，超过 2 倍就去费用中心看调用类型分布。

我给自己定的线是 14 天。低于这个数就充，原因是充值到账和实名审核都可能耽误 1 到 2 个工作日，卡在最后一天容易耽误正事。

团队共用账号的场景要另算。3 个人共用一个密钥，谁跑了长任务都看不出来，这种情况给每人建一个密钥，在用量页按密钥维度分开看，问题定位快很多。

最后提醒一句：token 只是计费口径，真正决定成本的是任务设计。同一个需求，把提示词从 300 字压到 120 字、把输入从整份文档改成抽取结果，消耗能差 5 倍以上。先把任务拆清楚，再谈省不省的问题。

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