DeepSeek V4-Pro 对 token 上限参数置若罔闻

一次对 V4-Pro 默认推理模式的手测

⚠️ 本文由 AI 辅助生成（Claude）。所有数据均来自作者在测试当天对 DeepSeek 官方 API 的真实调用，每个结论均附有样本量说明。作者为独立开发者，与 DeepSeek 或 OpenRouter 均无关联。

测试时间：2026-08-14，测试模型：deepseek-v4-pro，测试端点：DeepSeek 官方端点（生产版 V4-Pro-0813）。

推理默认开启。在没有任何推理相关参数的情况下，单次"Liar's Dice"（撒谎骰）决策消耗了 3,072 个输出 token——全部是推理过程，没有任何可见答案。

OpenAI 风格的修复方案无效。我发送了 max_completion_tokens: 3072，API 返回了 HTTP 200，随后在 222 秒内生成了 15,809 个 token。它没有拒绝该参数，只是表现得好像从未见过它一样。

甚至捏造的参数也被接受了。totally_bogus_param: true 也返回了 HTTP 200。未知的参数被静默吞掉，所以你无法判断某个限制是否生效——直到账单寄来。

相同任务在关闭推理时只需 2 秒和 95 个 token。开启推理后，需要 65 秒和 4,500 个 token，而可见答案的长度几乎相同。

每次可用答案的成本：关闭推理时 ¥0.0105；开启推理且 8,192 token 预算时 ¥0.175——贵了 16.7 倍。以 3,072 token 为预算时，有效成本趋于无穷：三次调用中可用答案为零，但每一笔都被计费了。

质量有提升吗？与 OpenRouter 上较旧的量化版本相比，在一个几乎没有解读空间的硬指标上，我没有检测到任何可察觉的改进（1/71 vs 2/22；样本量较小，差异不具统计显著性）。

推理可以关闭。reasoning_effort: "none" 和 thinking: {type: "disabled"} 有效。enable_thinking: false 无效——而且 API 从未告知我。

我在做什么

我正在开发一款名为 Kai! 的单人"撒谎骰子"游戏。对手不是预设脚本机器人，而是由大语言模型驱动。它使用与玩家相同的游戏引擎、看到相同的信息、在质疑前揭示思考过程，还能跨回合记住你的玩法。换一个模型，你就相当于换了一个对手。

这意味着我需要知道每次决策的成本和耗时。这不是跑分的好奇心，而是延迟和计费强加给我的现实问题。

第一堵墙：我为三个空字符串付了钱

一次撒谎骰决策的提示词约 3,200 个中文字符。在 max_tokens: 3072 的设置下，连续三次调用全部失败：

finish=length  completion=3071  reasoning=3071  visible=0 chars  50s
finish=length  completion=3072  reasoning=3072  visible=0 chars  47s
finish=length  completion=3072  reasoning=3072  visible=0 chars  42s
=> usable: 0/3

这 3,000 多个输出 token 全部流入了推理过程，没有一个可见答案字符输出。计费基于生成的 token 数量，所以我为三次调用全额付款，却收到了三个空字符串。

更糟的是，应用程序对结果的解读是这样的：无法解析的动作 → 降级策略将这一步标记为不合规 → 仪表盘显示"该模型在 94.4% 的回合中违抗了指令"。这个数字来自我项目 8 月 13 日的批次，而非这次独立测试。我差点把一次真实的 token 预算失败记录成模型行为问题。

那么它到底需要多少预算？

我在四种配置下对同一任务各运行了三次：

同时成立的三件事：

1. 预算越紧，模型越有可能把它全部耗尽。 3,072 token 的预算最终停在 3,072。8,192 token 的预算通常接近 8,192。只有当我把限制提升到 32,768——远超它正常需要的 3,200–5,800 token——它才可靠地自然停止。

2. 推理用量难以预算。 同一任务中，推理消耗从 3,137 到 5,691 token 不等。由于设定的限制被无视，它攀升到了 15,774。这不仅仅是"想得更多"。这使得按调用计费变得不可靠：当用量可能几乎翻倍——或者更高——你该按哪个数字来准备资源？

3. 更长的推理没有产生更长的答案。 关闭推理时，可见答案 123–156 个中文字符。开启推理后，答案只有 117–140 个。47 倍的 token 用量和 22 倍的延迟，并没有换来更长或更完整的答案。

对于我的应用来说，还有一个更根本的问题：每回合有 30–60 秒的节奏预算，而一次开启推理的决策需要 49–222 秒。到了这个地步，问题已经不只是价格了。产品体验直接崩溃了。

是协议的问题，还是 DeepSeek 的问题？

发表之前，我分别测试了参数行为。答案是：两者都有份，但权重不同。

在协议层面，OpenAI 兼容的 max_tokens 字段把推理和可见输出放在同一预算里。如果推理消耗了额度，答案就什么都不剩。OpenAI 自家的推理模型也踩过同样的坑，所以才有了 max_completion_tokens 的引入，文档也因此警告说预算太小可能产生空响应。这部分是协议设计问题。

然后我对 DeepSeek 端点测试了相关参数：

最后一行是问题的根源。API 静默接受未知参数。每个被忽略的设置因此看起来都像是成功生效的设置。你发送了一个限制，收到 200，就以为调用已被限制——直到账单告诉你真相。

max_completion_tokens 是最典型的例子。它的存在正是为推理模型而生，正是为了解决这里描述的预算失效问题。DeepSeek 接受了它，返回了 HTTP 200，然后让模型生成了 15,809 个 token。不支持的参数可以被拒绝。静默忽略它们是最糟糕的行为。

我的结论：协议挖了坑；DeepSeek 把坑挖得更深，还把梯子撤了。

但生产版本至少更好吗？

这是我最想让数据为 DeepSeek 说点好话的地方。它没有。

首先，价格需要仔细措辞。OpenRouter 上较旧的 deepseek-v4-pro 构建标价为 $1.17/$2.34 每百万输入/输出 token。生产版 -0813 标价为 $0.43/$0.87，而 DeepSeek 官方端点收费 ¥3/¥6——约 $0.42/$0.85。纸面上看，生产版便宜了约三分之二。但 OpenRouter 对旧版本定价本来就相对偏高，我无法把渠道溢价和实际降价分开。所以我无法诚实地声称"生产版变贵了"。

真正上涨的是每次可用答案的成本。关闭推理时，一回合 ¥0.0105。开启推理且 8,192 token 预算时，三次调用中只有一次产生了可用答案。包含那两次浪费的调用，有效成本变为 ¥0.175——贵了 16.7 倍。以 3,072 token 计算时，有效成本趋于无穷：没有一次调用可用，但全部被计费了。无论标价怎么变，这个倍数把省下的钱全吃掉了。

质量方面，我选择了一个几乎没有策略模糊度的硬指标：当当前叫注已经保证为真（只基于模型自身的骰子）时，模型仍然选择质疑。那次质疑必然失败。

z=1.22；差异不具统计显著性。严谨的结论不是生产版更差，而是我无法在该指标上检测到任何改进；如果有方向性信号，反而指向另一边。

这个结果需要一个重要的附加说明：两个版本从未在同一批次中正面对比过。比较中包含了不同的对手、不同的随机种子和不同的提示词修订。生产版也只有 22 个相关情境。数据可以反驳"明显改进"的说法，但无法证明退步。

我的意思不是 DeepSeek 不好

关闭推理时，V4-Pro 两秒内返回一个干净的决策，每回合约一分钱，在我桌上表现出色。我的托管席位仍然跑在 DeepSeek 上。

真正的问题是三个产品决策的组合：

推理默认开启。 对于按调用计费的应用，这可能是纯粹的成本而非收益。

没有可用的推理预算限制。 OpenAI 风格和 OpenRouter 风格的设置都被无视了。

未知参数被静默吞掉。 这让前两个问题难以诊断。

第三个决策是最需要改变的。返回错误的 API 十分钟就能调试出来。静默返回 200 的 API 迫使你从账单和一个误导性的"94.4% 不合规"仪表盘反向追溯，才能发现实际发生了什么。

如果你用程序调用这个模型

不需要推理时，明确发送 reasoning_effort: "none" 或 thinking: {type: "disabled"}。不要依赖 enable_thinking: false：在我的测试中它没有任何效果，而 API 也没有告知你。