DeepSeek V4 Pro 正式版对比预览版：思考量减少 18-62%

在相同任务上，DeepSeek V4 Pro 正式版的推理 token 比被其取代的预览版少 18% 到 62%。它修复了一个可能耗尽整个 8,192 token 输出窗口的故障，也是首个能通过关闭思考来可靠完成严格 JSON 提取的 Pro 版本。但它也失去了预览版直言“不知道”的能力。正式发布四天后，我们在同一批测试中对比了 deepseek-v4-pro-0813 和预览版。这里只比较 token 数量，因为 DeepSeek 在测试前一天调整了 V4 定价，并引入了峰时／非峰时计费。拿两张不断变化的价目表直接比较美元成本，参考价值反而不如 token 数量。DeepSeek 发布正式版时没有博客文章、变更日志或新闻稿，想知道具体改了什么，只能实测。

TL;DR

• 正式版每项任务消耗的推理 token 少 18-62%；简单查询为 18，而预览版为 48。
• 两个版本开启思考后，都会破坏严格 JSON 中的值，正确率仅为 2/8；我们只找到一种完全可靠的配置：正式版关闭思考，正确率为 8/8。
• 正式版修复了预览版的一个故障：设置 thinking_budget: 16 后，预览版在 9 次测试中有 5 次耗尽 8,192 token 输出窗口；正式版 9 次均未出现。
• 正式版失去了明确拒答的能力：面对虚构实体，预览版会在 100 到 150 个 token 内拒答；正式版要么什么都不返回，要么编造答案。

正式版的思考量减少了多少？

减少 18% 到 62%，任务越浅，差距越大。下面是四项标准任务的结果。每项任务运行三次，每次带唯一编号避免命中响应缓存；表中取推理 token 和完整输出 token 的中位数：

所有任务中，两个版本的准确率都保持在 3/3，因此这是纯粹的效率提升，并非以质量为代价。容量规划时需要关注这种梯度：任务越深，节省得越少。单跳查询减少 62%，五步推理链则只减少 18%。无论两个版本的实际费用是多少，差异趋势都是如此。结构化提取的收益最大：使用严格 json_schema 后，推理 token 从 159 降到 40，只有原来的四分之一。

切换版本不会改变缓存行为：两个版本都能缓存 5,000 token 前缀中的 4,096 个 token，并在预热请求 4 秒后命中缓存。目前变化的是费率，而不是缓存机制。DeepSeek 上调了 V4 系列价格，并从 2026-08-16 16:00 UTC 起引入峰时／非峰时计费，非峰时费率减半。因此，在把这些 token 数换算成美元前，需要查看各版本当前的价目表以及请求运行时段。

正式版修复了哪些可量化的问题？

修复了，而且这是该系列成本最高的故障模式。向预览版发送 thinking_budget: 16 会让模型失去任务主线：它不会短暂思考后给出答案，而是陷入重复循环，例如“I’ll output: 168. I’ll output: 168…”，直到耗尽 max_tokens。对同一项五步任务运行九次，预览版有 5 次填满整个 8,192 token 窗口；正式版一次都没有，每次都能在 79 到 130 个 token 内正常作答。

这个故障的关键就是成本：原本为了省钱而限制思考量的请求，最终却产生 8,193 个输出 token，而正常答案约为 130 个。要求模型少思考，输出账单反而扩大 63 倍。预览版使用 64 token 预算同样不安全，3 次中有 2 次返回错误答案，分别为 183 和 174。如果仍固定使用预览版，并通过较小的思考预算控制成本，应优先停用这种组合。

这里可以安全关闭思考。之所以需要明确指出，是因为该系列并非所有模型都适用：Flash 0731 关闭思考后，两跳算术准确率从 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 个推理 token，预览版为 116-167，均无单调变化趋势。正如我们的跨厂商思考档位矩阵所示，DeepSeek 真正起作用的控制方式是关闭开关和预算，而不是 enum 档位。

思考仍会破坏严格 JSON 吗？

会，两个版本都有这个问题；但正式版是首个提供可靠规避方案的 Pro 版本。我们最早在 DeepSeek V4 Flash 0731 上发现了这个缺陷：JSON 符合 schema，但其中的数字是错的。这个问题延续到了 Pro。我们要求两个版本在严格 json_schema 下，从三行发票中提取四个字段。每种配置运行八次，并检查具体值，而不只是检查 schema：

每个失败结果都能正常解析，也符合 schema，但内容不真实。文档明明只有三个条目，模型返回的条目数却包括 45、22、2026、-4、-35 和 -3864；一次预览版响应给出的总额是 -139,308,173,307,904，一次正式版响应甚至凭空换成了另一家公司“MITRE”，总额为 1000。对验证器而言，这些全都是合法 JSON。

运维结论很简单。正式版关闭思考后，该缺陷在所有测试中都消失了。仅这一项设置，就足以成为迁移出预览版的最有力理由，因为预览版即使关闭思考，8 次中仍有 6 次出错。这与我们在 Flash 上测得的系列规律一致：关闭思考同样让每次结果恢复正常。它也再次符合思考控制矩阵中的单步任务安全区：提取任务不需要审慎推理，而在这个系列中，推理反而会直接破坏结果。

正式版失去了什么？

直言“我不知道”的能力。我们针对五个虚构实体提问，包括公司股价、研究所人数、城镇章程、合金熔点和奖项得主。预览版会在 100 到 150 个输出 token 内明确拒答：“I don’t have any information about a 1987 Pan-Continental Robotics Prize.”正式版则会出现以下两种情况，哪一种都没用：

发布前，我们又通过第二条独立请求链路进行了验证。在那条链路上，预览版对三道抽样问题全部拒答，分别使用 101 到 148 个 token；正式版有一道题消耗 8,191 个 token 后返回空答案，一道题给出保留性回答，另一道题则为不存在的合金断言了具体熔点“2,314 degrees Celsius”。不同客户端表现出相同的不对称行为，说明问题来自模型本身。

对检索流水线而言，实际后果是双重成本：索引无法回答的问题会消耗整个隐藏推理窗口，而返回结果要么为空，要么是验证器会照单全收的编造内容。如果把未命中查询路由给该模型，应把 max_tokens 设得足够低，让故障既明显又便宜，并把空输出视为未命中，而不是错误。

切换版本后还有其他变化吗？

变化很少，因此切换主要是行为选择，不是集成问题。两个版本都能在单次调用中接受 279,000 个输入 token，并能从中间位置准确取出指定信息（大海捞针式检索）。它们共用该系列的 tokenizer：同一份中英混合代码语料在正式版、预览版和 deepseek-v4-flash-0731 上的 token 数完全相同，因此整个系列可以原样复用 token 预算。两个版本都会静默接受 temperature、top_p 和 top_k，也都支持预填充 assistant turn，即 DeepSeek 文档中的前缀补全功能。

两者的缓存行为完全一致，连分块粒度都相同：512 token 前缀完全不会缓存；超过该长度后，都会按精确的 1,024 token 页缓存，分别为 1,024、2,048 和 4,096，并在预热请求 4 秒后命中。页大小与 Flash 相同。还有一个成本问题可以明确：两个版本都会在 reasoning_content 中返回完整思维链，而在下一轮请求中重放这些内容不会产生费用。无论上一轮推理内容是保留还是删除，后续轮次在正式版上都计为 134 个输入 token，在预览版上都计为 56 个。与逐 token 对保留推理重复计费的模型不同，这个系列会直接忽略它。

工具循环没有明显优劣。在包含两个函数的 agent 循环中，模型先查询事故，再重启事故对应的服务。正式版第一跳思考更多，为 48 个推理 token，预览版为 34；第二跳则更少，正式版为 18，预览版为 35。两个版本选择正确工具的准确率都是 3/3。考虑到 DeepSeek 把 agent 工作负载作为这个版本的主攻方向，逐跳思考量更接近持平，而不是总体效率数据所显示的明显提升。对于会遇到死路的 agent，上述拒答行为更值得关注。

常见问题

正式版运行成本低多少？

按 token 计算，每项任务的推理量减少 18-62%；使用严格 json_schema 时，推理量只有原来的四分之一。美元成本需要查看当前价目表：DeepSeek 于 2026-08-16 调整了 V4 系列定价，并引入峰时／非峰时计费，非峰时费率减半。因此，相同 token 数会因版本和时段不同而产生不同费用。

正式版在简单任务还是复杂任务上节省更多？

简单任务。单跳查询的推理量减少 62%，两跳文字题和 JSON 提取约减少 48%，五步算术链则只减少 18%。深层多步任务中，两个版本的表现趋于接近；浅层高流量请求最能从切换中获益。

还应该在 DeepSeek V4 Pro 上使用较小的思考预算吗？

预览版不应该。设置 thinking_budget: 16 后，预览版会陷入重复循环，并在 9 次运行中有 5 次耗尽整个 8,192 token 输出窗口。一个本应便宜的请求，输出账单反而扩大约 63 倍；设置为 64 token 时还会给出错误答案。正式版在相同预算下 9 次全部正常，因此只有带日期的正式版能安全使用小预算控制。

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

仅限关闭思考的正式版。每种配置运行八次后发现，两个版本开启思考时，虽然响应都符合 schema，但 8 次中有 6 次数字错误。三条明细的发票会返回 45、2026、-3864 等条目数。正式版使用 thinking: {"type": "disabled"} 后，8 次结果全部正确；预览版即使关闭思考，8 次中仍有 6 次错误。必须验证具体值，不能只验证 schema。

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

预览版会在 100-150 个 token 内拒答。正式版大多不会：面对虚构实体，它要么耗尽整个输出窗口进行思考后返回空消息，要么在窗口更大时自信地编造答案。应使用自有数据源进行验证，不能因为模型没有拒答就相信结果；空输出应按未命中处理。

测试于 2026-08-17 通过 Synthorai gateway 完成，当时距正式版上线四天。每项对比都在同一批次中重新运行预览版。测试包括：档位与关闭开关矩阵（7 个 effort 值、5 个 budget、2 个关闭参数，n=3）、四任务推理扫描、严格 JSON 结构化输出、两轮函数调用循环、在两种窗口大小下针对五个虚构实体的探测、四字段严格 JSON 值完整性探测（每种配置 n=8）、一组推理重放计费对照、两种等待时间下的隐式缓存对照和缓存下限区间测试、带大海捞针式检索的 279K token 上下文接受测试、V4 系列固定语料 tokenizer 对比，以及采样／预填充／n>1 接受度探测。失控比例来自每个版本在 max_tokens: 8192 下各九次运行。本文报告 token 数而不是美元成本，因为 DeepSeek 在本批测试前一天，即 2026-08-16，调整了 V4 系列定价并引入峰时／非峰时计费。拒答行为和失控问题均通过第二条独立请求链路交叉验证。费率和行为可能变化；依赖任何单项数据前请重新测量。

← 返回博客