deepseek怎么用token?自己申请还是用自带的

DeepSeek 的网页版和手机 App 不涉及 token，手机号登录就能对话。要把模型接进自己的程序、或者用第三方客户端时，才需要申请 API key，申请免费，用量按 token 数结算。下面按操作顺序写 5 步，顺带写清 4 个常卡住的地方。

先分清自己属于哪种用法

同一个模型有两种入口，token 只在第二种里出现。打开 chat.deepseek.com 直接打字的人，属于第一种，账户里既没有 key 也不需要充值。写代码调用接口、或者把 key 填进其他软件的人，属于第二种。

网页版对话按天限次数，超出后提示次日再来，账单里不会出现 token 记录。API 走的是另一套入口 platform.deepseek.com，进去看到的是用量、余额、key 管理三块内容，两边的账号可以打通，余额不互通。

我上个月帮一个做外贸的客户接客服机器人，他先在网页版聊了 3 天，觉得效果好，让我“把 token 充上”。实际打开他的账号，网页版根本没有充值入口，需要先注册平台账号。这一步走错，会白等 1 到 2 天。

申请前准备 3 样东西

申请本身 5 分钟能完成，卡住的地方几乎都在准备工作。手机号、可用的支付方式、一个明确的用途说明，这 3 样齐了再动手。

• 手机号或邮箱：注册用，一个号对应一个账号，团队多人用就多注册 2 到 3 个。
• 支付方式：平台支持在线充值，单次起充金额在充值页面写明，未实名的账号看不到充值入口。
• 用途说明：部分接口在开通前要填调用场景，写清是内部工具还是对外服务，20 字以内即可。

浏览器建议用近 2 年内更新的版本。我遇到过在旧版内置浏览器里点“创建 key”没反应的情况，换成常规浏览器后 1 次就成功，问题出在脚本兼容。

申请步骤：5 步走完

整个流程在 platform.deepseek.com 完成，从注册到拿到 key 顺利的话 5 到 8 分钟。每一步都写清入口位置和大致耗时。

1. 注册并登录：进入 platform.deepseek.com，用手机号收验证码，约 1 分钟。这一步和网页版对话账号可以共用同一个手机号。
2. 完成实名：在账号设置里提交身份信息，审核多在 10 分钟内出结果，个别时段要等 1 个工作日。
3. 充值余额：进入“充值”页，选金额、扫码支付。到账是即时到账，页面右上角的余额数字会立刻变化。
4. 创建 API key：左侧菜单“API keys” → “创建新 key”，填一个自己认得出的名字，例如 bot-test-01。key 只在创建时完整显示 1 次，页面关掉就再也看不到。
5. 把 key 填进程序：在环境变量里存成 DEEPSEEK_API_KEY，代码里读变量，不要写死在文件里。填完发 1 次测试请求，返回 200 就通了。

第 4 步最容易出事。key 是一串以 sk- 开头的字符，创建后只显示一次，我见过 2 个客户直接把页面关了，只能删掉重建。建议创建时先粘到本地文本文件，再往程序里填。

参数怎么填

接口的必填项只有 3 个：模型名、消息列表、key。其余都能用默认值跑通，先跑通再调优，比一上来配 10 个参数省事。

temperature 这一项值得单独说。做客服、做资料整理，把值压到 0.2 以下，同一问题问 3 次答案基本一致；写文案、起标题再往上调。我通常准备 2 套配置，一套稳一套活，按任务切换。

token 怎么算，怎么省

计费按输入加输出一起算，中文 1 个汉字大约占 0.6 到 1 个 token，英文 1 个单词约 1.3 个 token。一段 1000 字的中文提问，输入侧大致 600 到 900 token。

省 token 有 3 个实招。把重复的背景说明做成 system 消息，别每次重发；长文档先切段，只把相关段落送进去；需要多轮对话时保留最近 5 到 8 轮，更早的做摘要。按这 3 条改，我们内部一个问答工具的月用量降了约 4 成。

余额和用量在哪看

平台首页的“用量统计”按天给曲线，能看到输入、输出、缓存命中三项分开的数字。缓存命中部分单价更低，同一段长提示词反复用时，命中率能到 60% 以上。

什么时候该换模型

简单分类、固定格式抽取这类任务，用小一号的模型就够，单价差 3 到 5 倍。需要长链推理的再切回大模型。同一个项目里混用两种模型，是常见的省钱做法。

报错怎么排查

接口报错大多集中在 4 种，状态码能直接定位方向。先看码，再看返回体里的 message 字段，比搜别人的帖子快。

1. 401：key 错了或没带上。检查请求头里有没有 Authorization、Bearer 后面接的是不是自己的 key，复制时有没有带多余空格。
2. 402：余额不足。充值后立刻可用，不用重启程序。
3. 429：请求太密。降到每秒 1 到 2 次，或加重试间隔，从 1 秒起每次翻倍。
4. 400：参数格式不对。最常见是 messages 结构错了，或者 max_tokens 超了模型上限。

状态码之外的两类问题

还有一类不在状态码里：请求发出去了，前端一直转圈。多数是 stream 打开却按整段读取，或者反向代理把分块传输缓冲了。把 nginx 的 proxy_buffering 关掉，问题就消失。

另一类是偶发的超时。同一个请求 10 次里有 1 到 2 次超过 30 秒没回，先在本地用 curl 复现，绕过自己的业务代码。curl 正常而程序超时，检查连接池有没有复用失效的连接，把空闲连接存活时间压到 60 秒以内。

怎么验证真的通了

跑通的标准是 3 件事同时成立：返回 200、返回体里有 choices 数组、内容非空。只看“没报错”不够，空内容也会返回 200。

建议写 1 个 5 行的测试脚本，固定问一句“回复 ok”，连续跑 3 次。3 次都返回内容，说明 key、余额、网络三处都正常。之后再换成业务提示词，出问题能立刻分清是环境还是提示词。

key 怎么管才不出事

key 等同于账号密码，泄露后别人用你的余额。管理上守 3 条：不写进前端代码、不进 Git 仓库、一个项目一个 key。

一个项目一个 key 的好处是能单独吊销。哪天某个服务不用了，删掉对应 key，其他业务不受影响。团队里 3 个人以上协作，再加一条：离职当天吊销该成员的 key，别等交接完。

充值也别一次充太多。先充够 1 个月用量的额度，跑满 30 天看清曲线，再决定下次充多少。我们第一个项目一次充了 500 元，结果用量只有预期的一半，余额在账上放了 4 个月。

常见误解 4 条

• 以为网页版能直接用 API。两边入口不同，网页版看不到 key。
• 以为 token 能攒着用。按量扣费，余额才是账户里的钱。
• 以为 key 可以随便贴到群里。贴出去等于把余额交出去，发现泄漏要立刻删 key 重建。
• 以为充了钱就一定快。速率限制和余额分开算，余额充足照样会 429。

本文信息核对时间：2026-11。控制台入口名称、模型名与计费规则由平台调整，操作前按官方文档当期说明核对。