DeepSeek V4 Pro GA 评测：推理 token 减少 18-62%，JSON 提取终于可靠

DeepSeek 的 V4 Pro 正式版在相同任务上比它取代的预览版少消耗 18% 到 62% 的推理 token，修复了一个可能烧掉整个 8,192 token 输出窗口的故障模式，也是首个关闭 thinking 后能让严格 JSON 提取变得可靠 Pro 版本。它同时也失去了预览版"表示自己不知道"的能力。我们在 GA 发布后四天在同一批次中测量了 deepseek-v4-pro-0813 与预览版的差异：只测 token 数量，因为 DeepSeek 在我们测量前一天修改了 V4 定价并加入了高峰/非高峰计费模式，而两个变动的卡片之间的美元对比给出的信息比 token 数量更少。DeepSeek 发布 GA 版本时没有发博客文章、更新日志或新闻稿，所以了解变化内容的唯一方式就是去测量。

GA 构建每个任务的推理 token 消耗减少 18-62%，一次查询任务从 48 降到 18。

两个构建版本上 thinking 都会破坏严格 JSON 的值（正确率 2/8）；GA 关闭 thinking 是我们发现的唯一干净配置（8/8 正确）。

GA 修复了一个预览版的故障模式：thinking_budget: 16 在预览版 9 次运行中有 5 次会填满 8,192 token 的输出窗口；GA，9 次中 0 次。

GA 失去了干净的拒绝能力：对于虚构实体，预览版在 100-150 token 内拒绝回答；GA 要么什么都不返回，要么编造一个答案。

GA 构建的思考量减少了多少？

减少了 18% 到 62%，差距在浅层任务上最大。我们的四个标准任务各跑三次，加盐处理，取推理 token 和总完成 token 的中位数：

准确率在两个构建版本的所有任务上都维持在 3/3，所以这是纯粹的效率提升而非质量交换。需要规划的模式是梯度：任务越深，节省越少，从单跳查询的 62% 降到五步链式推理的 18%。无论两个构建版本对你的成本是多少，这就是差异的形态。结构化提取获益最大，在严格 json_schema 下从 159 降到 40 推理 token，减少了 4 倍。

两个构建版本的缓存行为完全一致：两个版本都缓存了 5,000 token 前缀中的 4,096 token，并在 priming 调用后 4 秒返回缓存命中。现在变动的部分是费率，不是机制。DeepSeek 在 2026-08-16 16:00 UTC 提高了 V4 系列价格并引入了高峰/非高峰计费（非高峰半价），所以在把这些 token 数量换算成美元之前，先去看每个构建版本的当前价格卡（以及你运行的小时时段）。

GA 修复了什么可测量的东西吗？

是的，而且这是该系列中最昂贵的故障模式。向预览版发送 thinking_budget: 16 会让它失去主线：不是简短思考后回答，而是退化为一个重复循环（"我将输出：168。我将输出：168..."），一直运行到耗尽 max_tokens。在同一个五步任务的九次运行中，预览版有 5 次填满了整个 8,192 token 窗口；GA 则 0 次，每次都在 79 到 130 token 内干净回答。

这个故障的代价才是重点：一个本意通过限制思考来节省费用的请求，反而被计费 8,193 个完成 token，而正常回答大约只需 130，输出账单相差 63 倍。预览版上 64 token 的预算同样不安全，3 次运行中有 2 次返回错误答案（183、174）。如果你仍然绑定在预览版并通过小思考预算来控制成本，这个组合是首先要退役的。

关闭 thinking 在这里是安全的，值得明确说明，因为在这个系列中并非处处安全：Flash 0731 在关闭 thinking 后从 2 跳算术的 6/6 降到 0/6，而两个 Pro 版本在我们的五步链上，无论 thinking: {"type": "disabled"} 还是 enable_thinking: false，都保持在 3/3。 在 Pro 上，关闭开关在推理任务上不损失准确率，还能修复结构化提取问题（见下文）。

刻度盘本身在两个构建版本上仍是装饰性的。reasoning_effort 接受 low、medium、high、xhigh 和 max，拒绝 none 和 minimal 并返回 400 列出有效集合，在我们五步任务上各级别产生了 76-122（GA）和 116-167（预览版）推理 token，且没有单调趋势。正如我们跨供应商的刻度盘矩阵所发现的，DeepSeek 通过关闭开关和预算来 steering，而不是通过枚举值。

thinking 是否仍然会破坏严格 JSON？

是的，在两个构建版本上，而 GA 版本是首个提供干净解决方式的 Pro 构建。我们在 DeepSeek V4 Flash 0731 上发现了这个缺陷：schema 有效的 JSON 但数字是错的。这个问题延续到了 Pro。我们让两个构建版本在严格 json_schema 下从一个三行发票中提取四个字段，每个配置跑八次，然后检查值而不是 schema：

每次失败都能解析、通过 schema，却在撒谎。一份明显列出三个条目的文档，条形计数在运行中返回了 45、22、2026、-4、-35 和 -3866；一份预览版回复报告了总计 -139,308,173,307,904，一份 GA 回复则完全发明了一家不同的公司（"MITRE"，总计 1000）。验证器在所有这些情况下都看到有效的 JSON。

运营层面的结论很短。在 GA 构建版上，关闭结构化提取的 thinking，缺陷在每次运行中都消失了；这单个设置是离开预览版最有力的论据，而预览版即使关闭 thinking 也有 6/8 的失败率。这与我们在 Flash 上测到的系列模式一致，关闭 thinking 同样清理了每次运行，也是我们 thinking-controls 矩阵中单步安全区的又一个例证：提取不需要思考，而这个系列上思考反而会损害它。

说"我不知道"的能力

在五个虚构实体（一家公司的股价、一家机构的人数、一个城镇的宪章、一种合金的熔点、一位获奖者）上，预览版干净地拒绝回答，输出 100 到 150 token："我对 1987 年泛大陆机器人奖没有任何信息。"GA 构建版则做两件事之一，而且都不是有用的：

我们在发布前通过第二条独立的请求路径检查了这一点。那边预览版在 101 到 148 token 内拒绝了所有三个采样问题，而 GA 在一个上烧了 8,191 token 得到一个空答案，在另一个上含糊其辞，在第三个上为一个不存在的合金断言了一个具体的熔点（"2,314 摄氏度"）。同样的不对称，不同的客户端：行为跟着模型走。

对于检索流水线，实际后果是双重收费：你的索引无法回答的问题会消耗一整个隐藏推理窗口，而返回的内容要么什么都没有，要么是你的验证器会欣然接受的虚构内容。如果你在将未回答的查询路由到这个模型，max_tokens 要设得足够低让失败可见且便宜，并把空完成视为未命中而不是错误。

切换时还有其他变化吗？

很少，这使得切换成为一个行为决策而不是集成决策。两个构建版本都接受一次调用 279,000 个输入 token 并从中间回答一个针问题。两个版本共享系列 tokenizer：相同的混合英中代码语料在 GA 版本、预览版和 deepseek-v4-flash-0731 上计数完全一致，所以 token 预算在整个系列中不变。两个版本都静默接受 temperature、top_p 和 top_k，都接受 prefilled assistant turn（DeepSeek 文档化的前缀完成功能）。

缓存在量子级别上完全一致：两个构建版本都不缓存 512 token 前缀，在那以上都以精确的 1,024 token 为页面大小缓存（1,024、2,048、4,096），在 priming 调用后 4 秒返回命中，页面大小与 Flash 相同。另一个值得关闭的成本问题：两个构建版本都在 reasoning_content 中返回完整思维链，在下一轮重放它是免费的。无论上一轮的 reasoning 是否被包含，后续轮次在 GA 上都计费相同的 134 输入 token（预览版 56），所以与那些逐 token 重新计费保留推理 token 的模型不同，这个系列直接丢弃它。

工具循环是平手而不是胜利：在一个双函数 agent 循环（查找一个事件，重启它命名的服务）上，GA 在第一跳上思考更多（48 vs 34 推理 token）而在第二跳上更少（18 vs 35），两个构建版本都 3/3 选对了工具。考虑到 agent 工作负载是 DeepSeek 定位此版本的场景，每跳思考更接近平手而不是标题效率数字所暗示的；上述拒绝行为对遇到死胡同的 agent 更为重要。

GA 构建版运行成本降低多少？

在 token 上，每个任务推理减少 18-62%，在严格 json_schema 下减少 4 倍。在美元上，看当前价格卡：DeepSeek 在 2026-08-16 改变了 V4 系列定价并加入了高峰/非高峰计费（非高峰半价），所以相同的 token 数量因构建版本和时间段不同而价格不同。

GA 构建版在简单还是复杂任务上节省更多？

简单任务。单跳查询推理减少 62%，2 跳文字题和 JSON 提取约 48%，五步算术链仅 18%。深度多步工作是两个构建版本趋同的地方；浅层高频流量才是切换划算的场景。

在 DeepSeek V4 Pro 上是否仍应使用小思考预算？

不在预览版上。thinking_budget: 16 使其陷入重复循环，在 9 次运行中有 5 次消耗整个 8,192 token 输出窗口，大约是本意便宜请求的 63 倍输出账单；64 token 产生了错误答案。GA 在相同预算下 9/9 干净处理，所以小预算杠杆只在过期构建版上安全。

能信任 DeepSeek V4 Pro 的严格 JSON 输出吗？

仅在 thinking 关闭时，且仅在 GA 构建版上。在每个配置八次运行中，schema 有效的响应在 thinking 开启时 6/8 携带错误数字（三项发票的条形计数为 45、2026、-3866），在两个构建版本上都如此。GA 在 thinking: {"type": "disabled"} 时返回正确值 8/8；预览版即使关闭 thinking 也保持 6/8 错误。验证值，而不只是 schema。

DeepSeek V4 Pro 会拒绝它无法回答的问题吗？

预览版会，在 100-150 token 内。GA 构建版大多不会：在虚构实体上它要么花整个输出窗口思考后返回一个空消息，要么，给一个更大的窗口，断言一个自信的编造答案。不要信任非拒绝，而是根据你自己的来源验证，并把空完成视为未命中。

测量于 2026-08-17 通过 Synthorai 网关进行，距 GA 构建版出现四天，预览版在同一批次中重新运行以进行每次比较：刻度盘和关闭开关矩阵（7 个 effort 值、5 个预算、2 个关闭参数，n=3）、四任务推理扫描、严格 JSON 结构化输出、双轮函数调用循环、两个窗口大小的五问题虚构实体探测、四字段严格 JSON 值完整性探测（每个配置 n=8）、推理回放计费对、两个等待时间和缓存底板括号的隐式缓存对、279K token 上下文接受度与针问题、V4 系列固定语料 tokenizer 比较，以及采样/prefill/n>1 接受探测。失控率来自每个构建版在 max_tokens: 8192 下的九次运行。报告 token 数量而不是美元，因为 DeepSeek 在 2026-08-16（测量前一天）改变了 V4 系列定价并引入了高峰/非高峰计费。拒绝行为和失控率在第二条独立请求路径上进行了交叉检查。费率和行为可能变化；在依赖任何单一数字之前重新测量。