DeepSeek 的 token 怎么用，从建 Key 到看用量的 6 步

DeepSeek 的 token 有两个意思：模型读写文字的计量单位，和开放平台账号里的调用额度。要用起来，走 6 步：注册实名、建 API Key、充余额、按接口地址调用、看用量页、按上限裁剪上下文。全程在 platform.deepseek.com 完成，20 分钟能跑通第一条请求。

下面按操作顺序写，每一步写清点哪个位置、填什么、卡住会看到什么提示。手上只需要一个能收短信的手机号。

一、先准备 4 样东西

1. 手机号 1 个，用于注册和实名，企业账号还要营业执照信息
2. 浏览器，建议用电脑端操作，后台页面在手机上看不全
3. 余额，按量付费，先充最小档试跑，够测几百次短请求
4. 调用工具，命令行、Postman 或者任意支持 HTTP 的程序都能发请求

准备环节最常卡在实名，这一步没通过，后面 5 步都是白做。个人账号上传身份证正反面即可，企业账号要填统一社会信用代码，审核 1 到 2 个工作日。没通过实名，Key 建得出来但调用会一直被拒。

第 4 样东西要提前选。命令行适合临时调试，页面工具适合一次改 3 个字段反复试，写进业务流程就得用代码。测试阶段建议先用页面工具跑通，确认参数都对得上，再搬进代码，能省掉一半排查时间。

二、6 步把 token 用起来

第 1 步：注册并完成实名

打开 platform.deepseek.com，用手机号注册，进控制台后到「账号设置」找实名入口。个人和企业两条通道，选错之后改起来要联系客服，注册时先看清自己的用途。

第 2 步：建 API Key

左侧菜单点「API keys」，右上角「创建 API key」，起个能认出用途的名字，比如「测试-客服问答」。创建后**密钥只完整显示 1 次**，关掉弹窗就再也看不到，只能重新建。我的习惯是建完立刻粘到密码管理器，同时在纸上抄一份放抽屉。

密钥的管理方式决定后面出事的成本。3 条底线：不写进前端页面、不提交到代码仓库、不发给外部人员。做前端的项目，密钥一律放在服务端中转，页面里只调自己的接口。这条在 2025 年之后已经成了行规，栽在上面的事故基本都是把 Key 写进了 JS 文件。

一个账号可以建多个 Key，按项目分开建，出问题能单独删掉某一个，不影响其他业务。这一步用的人不多，但真遇到密钥泄露时，能省掉全部重配的麻烦。

第 3 步：确认余额和计费方式

到「充值」页看余额，按量付费，输入和输出分别计量。同一段文字被重复送进上下文时，命中缓存的部分计费更低。想控成本，把固定不变的前缀（系统提示、产品资料）放在消息最前面，后面的对话接在后面，缓存命中率会高一些。

第 4 步：按接口地址发起请求

接口地址是 https://api.deepseek.com，请求格式与 OpenAI 的 chat completions 一致，会写 OpenAI 调用的，改两个字段就能跑。3 个必填项：模型名（deepseek-chat 或 deepseek-reasoner）、messages 数组、以及放在请求头里的 Authorization: Bearer 加你的 Key。

messages 是数组，每条带 role 和 content。role 有 3 种：system 放固定要求，user 放这次的问题，assistant 放历史回答。只想问一句就发 1 条 user，要做多轮就把历史按顺序接上。

token 怎么估，中文按 1 个字 1 个 token 算，英文按 4 个字符 1 个 token 算，误差通常在 2 成以内。手上有一段 5000 字的资料，一次全塞进去就是 5000 token 上下的输入，成本是短问题的几十倍。要反复问同一份资料，把资料放进 system 并保持前缀不变，命中缓存后这部分计费会低一截。

长文档还有另一种处理方式：先让模型把资料压成 300 字摘要，再把摘要接进对话。做合同条款问答时我用这个办法，一份 40 页的合同压到 500 字，后面 12 轮追问都基于摘要加原文片段，输出的准确度和全量输入差不多。

第 5 步：看用量页确认 token 花在哪

控制台「用量信息」按天列输入 token、输出 token 和请求次数。跑完第一条请求，等 1 到 2 分钟刷新，能看到 1 条记录。数字对不上时，先看是不是把长文档反复塞进上下文，这类请求的输入 token 会是输出的几十倍。

第 6 步：按上下文上限裁剪

两个模型的上下文上限不同，超出会直接报错，不会自动截断。做多轮对话必须自己裁：保留最近 6 到 10 轮，更早的压成 1 段摘要放进 system。我做过一个客服问答，不裁剪时第 9 轮开始报超长，裁到最近 8 轮之后连续跑 40 轮没出问题。

三、参数怎么填

max_tokens 这一栏值得单独说。它限制的是输出长度，不设的话按默认值走，做摘要、分类这类短输出任务，设成 200 到 500 能省下一截成本，也避免模型把短答案写成长文。

temperature 按任务定。从合同里抽字段、做分类打标这类任务，设 0 到 0.3，同一段输入跑 3 次结果基本一致；写文案、起标题这类任务设 1.0 以上，输出才有变化。设成 1.5 以上时句子会开始发散，做业务流程用的场景不建议。

四、报错怎么排查

401 是 Key 的问题，3 个原因：粘的时候带了空格、Key 已被删除、请求头少写 Bearer。402 是余额不足，充值后要等 1 到 2 分钟生效。

429 是请求太密，把并发降到每秒 1 到 2 次，或者加 1 秒间隔重试。400 里最常见的是上下文超出上限，看报错里提示的 token 数减去实际内容长度，差多少就是历史堆了多少。

404 多半是模型名写错，deepseek-reasoner 拼错一个字母就报这个。还有一类是超时，长文本请求超过 60 秒会断，把任务拆成 2 到 3 段发，或者开流式。

五、怎么验证跑通了

3 个动作：用量页出现 1 条记录、返回内容里 choices 数组不为空、usage 字段里 prompt_tokens 和 completion_tokens 都是正数。三个都对上，说明链路通了。

再压一次边界：故意发一段很长的文本，确认报错信息里提示的是上下文超限。这一步能提前发现代码里把 Key 和内容拼错位置的问题。我第一次接的时候就踩过，Key 拼进了 messages，报 401 查了 40 分钟。

验证还有一步容易被省：用同一个 Key 从另一台机器发一次请求。本机跑通但服务器跑不通，原因多在网络出口、域名解析或者环境变量没读到。这 3 类问题在本地永远复现不了，换一台机器跑一次就能定位。

最后留一个习惯：把每次请求的 usage 字段记进自己的表里，字段有 3 个，输入、输出、总 token。跑够 200 条请求后按任务类型分类看均值，哪类任务吃 token 一眼能看出来。我那张表上，最长的一类是「整份文档问答」，平均单次输入 6800 token，是其他类的 11 倍。

把接口跑通之后，建议先做 20 条真实请求再上线。20 条能覆盖掉大半参数配置问题，包括超长输入、空返回、并发冲突。接口本身不难，难的是边界情况，提前跑一轮比上线后半夜被叫起来改强。

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