AI 翻译到底投入了多少思考？

Gemini 确实总能带来惊喜。对于大多数语言，它都是目前开箱即用的最佳翻译大模型。凭借其思考能力，你甚至能攻克最棘手的难题，例如成语、动漫梗或是塑造独特的品牌调性™。

但问题在于，思考既耗时又费钱；每一个 token 都要计费。作为开发者，你自然希望这两者都能尽在掌握。

Gemini 2.5 简单省事。Gemini 3 则让事情变得棘手。

以下是我们在 Transept 实验室的发现

Gemini 3 带来的变化

Gemini 2.5 拥有 thinkingBudget：一个推理 token 数量的数值上限。Gemini 3 弃用了它，取而代之的是 thinkingLevel：一个包含四个值的类别设置——minimal、low、medium、high。这两个参数是互斥的；在目前的 SDK 中，同时向 Gemini 3 模型发送这两个参数会返回 400 错误。

这改变了“成本控制”在实际操作中的含义。以前，你可以为支出设定一个硬上限。现在，具体的消耗量则取决于模型对“medium”等等级的自行裁量。

我们推测，这是因为模型经过后期训练，能够像人类一样根据任务难度调整思考长度。因此，设置随意的限制会损害这种能力。

但 low、medium 和 high 实际上到底消耗了多少 token？

数据

以下是我们两周内真实翻译业务流量的样本，涵盖了三个 Gemini 3 模型的约 1000 次调用。思考 token 数据取自每个响应中的 usageMetadata.thoughtsTokenCount，这是目前最准确的数据来源。

各模型思考 token 统计

15,725 这个数字并非笔误。在 Flash 模型上，使用中等设置进行的一次翻译调用，竟然消耗了 1.5 万个推理 token。

通常，这类 token 虚高是因为 Gemini 将原始思考 token 泄露到了输出中。正如你所知，模型展示的“思考”并非其真实的思维过程，而是经过润色的总结；大语言模型真正的推理过程更像是一种意识流。

值得注意的是，在这个案例中，Gemini 正在不紧不慢地推敲一段文学作品的英乌翻译，其中有一句是“纯钢不染漆”。它像是在穷举一样，反复“念叨”了大概 12 种方案，直到选出满意的输出。

几周后，情况有了更新。那 15,725 个 token 的消耗并非 Gemini 偶尔的卖力表现，而是一种针对复杂任务的特定模式。

随着访问量增加，尤其是在 gemini-3.1-flash-lite 上，同一个数字反复出现。在数十次调用中，数值高度集中在 15,724–15,729 这个极其密集的区间内，且几乎全是 Lite 模型在死磕术语表审核。有趣的是，这些调用运行在“低思维强度”（low）模式下，按理说这不该是最耗费资源的设置。

一个模型如果先后 11 次都得出相同的数字，说明它触碰到了上限，而非在推敲措辞。在“低思维强度”（low）设置下，token 消耗在大约 1.57 万处达到饱和。由于 lite 这样的小模型思维效率较低，处理复杂任务时会消耗大量 token；而大模型则不会出现这种情况，它们的每一个 token 都更有可能是在朝着答案迈出的实质性一步。

此外，这种饱和现象是有代价的。在 Gemini 3 中，思维 token 会占用 maxOutputTokens 的配额。如果一次调用在“思考”上花掉了 1.57 万个 token，留给答案的空间就几乎所剩无几了；然而，所有的思维 token 都是按输出档位计费的。在 16K 的预算下，处理小型文档时，审核结果大约有一半的时间返回为空（finishReason=MAX_TOKENS），这促使我们展开了调查。

提高预算只是治标不治本。我们将低强度（low）模式下的审核预算调高到了 32K，这样在思考达到饱和后还能剩下约 1.6 万个 token 用于输出——空回复的情况确实消失了。但思考过程并没有缩减。在 Gemini 3 上，你无法限制它的思考上限，所以它依然会消耗约 1.57 万个 token；更高的预算只是为答案留出了空间。

要彻底解决这 1.6 万个 token 的“思维触顶”问题，唯一的办法就是缩小任务范围。

minimal 是唯一能起到真正限制作用的层级，其上限约为 2,000 个 token。不过，该选项仅适用于 Lite 模型。

按任务类型划分的思维 token 消耗（Flash vs Pro，均为 medium）

在基础翻译任务中，Pro 的思考量比 Flash 少了将近一半。只有在处理改写任务时，Pro 的思考量才会超过 Flash。可见推理投入的多少取决于任务难度，而非模型的市场定位。

可以说，Pro 之所以能在翻译基准测试中表现更出色，正是得益于它在必要时进行深度思考的能力。

实践建议

• 不要为 Gemini 3 模型设置 thinkingBudget。该设置要么会被忽略，要么会报错。
• medium 档位上不封顶。比较现实的预估是每次调用产生约 4k 个 p90 思考 Token，而非 2k。
• 如果你需要硬性的成本上限，请尽可能使用 minimal。强行截断输出没有意义：无论如何，你都要支付这部分费用。
• 如果你是按调用计费，请读取每次响应中的 usageMetadata.thoughtsTokenCount。这个数值不会出现在响应正文中，但会体现在账单上。
• 在 medium 档位下，Pro 处理简单任务时的思考量通常低于其中位数，而处理复杂任务时则会思考更多。Lite 和 Flash 并不存在这种波动。

这意味着，如果追求超越大模型基准水平的校对和润色效果，Pro 是最佳选择，因为这类任务能激发其创造力。至于初稿翻译，交给 Flash 处理效果更好。

不过，这确实需要投入更多时间和金钱。在 Transept，我们摸索出了一套降低 Pro 成本的方法：利用智能校对逻辑，仅在最困难的部分启用 Pro。我们还让 Pro 负责规划和决策，而将具体的执行工作交给更小的模型或微调模型。

这样一来，整套方案就能高效运转。