DeepSeek 系列接入中转：标准型与推理型的计费差异

两类模型的本质差异

同一个 DeepSeek 系列里，标准型（对话/指令型）与推理型（带思考过程）在计费上不是「贵一点」的关系，而是计费结构不同。

标准型

一次请求的 token = 输入 + 输出。

输出长度基本由你的 max_tokens 和任务复杂度决定，通常可控。

推理型

一次请求的 token = 输入 + 思考 token + 输出。

关键：思考 token 通常按输出价格计费，而且往往占总输出的 70%–95%。

也就是说：你看到回答了 300 字，实际计费的输出可能是 5000 token。

为什么思考 token 会失控

思考长度和「问题难度」不是线性关系。几个会显著拉长思考的场景：

1. 数学与逻辑题：模型会反复验算；
2. 需要多步规划的 Agent 任务：每一步都要重新规划；
3. 模棱两可的问题：它会尝试多种解释；
4. 被要求「仔细思考」：提示词本身会诱导更长的思考。

反过来，简单的事实问答也可能产生很长的思考 —— 因为模型的思考长度不完全可控，取决于它的推理策略。

四种可落地的成本控制

一、分层路由（收益最大）

不是所有任务都需要推理型。

Agent 场景的分层收益特别明显：规划需要推理，执行不需要。把执行步骤也交给推理型，是在为每一步重复付思考费。

二、限制 max_tokens

显式设置 max_tokens，不要留默认（默认往往是最大值）。

注意：max_tokens 是否包含思考 token，取决于实现。有的把它算在 max_tokens 内，有的分开。这一项必须实测确认，否则你的成本模型会错。

测试方法：设一个较小的 max_tokens（如 200），看返回的思考 + 输出总长度是否被限制在这个值以内。

三、看 usage，不要看文本长度

对账时以 usage 字段为准，不要用「回答看起来很短」来判断成本。

推理型的 usage 结构通常是：

"usage": {
  "prompt_tokens": 85,
  "completion_tokens": 4820,
  "completion_tokens_details": {"reasoning_tokens": 4450}
}

有 reasoning_tokens 字段时，直接拿它统计。

如果你发现某家中转站的 usage 里没有 reasoning 相关字段 —— 值得单独确认它是怎么计费的。有可能它按总输出计，也可能它把思考部分隐藏了但照样收费。

四、缓存思考过程（如果支持）

部分实现支持在多轮对话中复用上一轮的思考结果，避免重复推理。如果中转站透传了这个能力，对多轮推理任务的成本影响很大。

判断方法：多轮对话中观察 usage 的 reasoning_tokens 是否随轮次递减。

一个常见的误判

「推理型比标准型贵，所以能用标准型就用标准型」是错的。

正确的判断依据是总成本（单价 × 需要的调用次数），而不是单价：

• 一个复杂任务，标准型可能要试 3 次才对（3 倍调用），推理型 1 次成功；
• 3 次标准型的成本可能已经超过 1 次推理型。

所以：对准确率要求高的任务，先测「一次成功率」再比价格。 单位「成功任务」的成本才是可比的量。

对中转站选择的额外要求

推理型对中转站提出了三个额外要求：

1. usage 字段完整（必须有 reasoning token 的计数），否则你无法对账；
2. 流式下要能区分思考与输出（有些客户端会把思考内容也显示出来，需要服务端区分字段）；
3. 超时设置要更宽松（推理时间显著更长，容易撞上网关超时）。

第 3 项最常导致「用不了」：请求没失败，只是超过了网关的等待上限，被断开。遇到推理型超时的站，不一定是它不支持，可能是它的超时配置没为这类模型调整。

场景建议

适合推理型：

• 数学、算法、逻辑推理；
• 复杂代码调试（需要定位根因而不是改表象）；
• 多约束的决策问题；
• Agent 的规划阶段。

不适合推理型：

• 简单抽取与分类；
• 翻译、改写；
• 高并发、低延迟要求的场景（思考时间本身就慢）；
• 批量数据处理（成本会失控）。

一个实用的起步策略：先用标准型建好全套流程，记录「哪些请求结果不满意」。然后只把这些请求转到推理型。这样你的推理型用量始终落在真正需要它的地方，成本增加有限，效果提升明显。