Temperature 参数正在被放弃：新一代推理模型为什么不再让你调它？

很多开发者第一次接触大模型 API 时，都会记住一个简单经验：把 temperature 调低，输出就会更稳定；把它设为 0，就更接近确定性；需要创意时，再把它调高。

这套经验正在失效。

新一代推理模型并没有统一地把 temperature 做得更强，而是在 API 层限制它、固定它，或者用 reasoning_effort、thinking_level、verbosity 和输出预算等更高层参数替代它。本文的判断很明确：

Temperature 参数正在被放弃。更准确地说，它正在从跨模型通用的默认调参旋钮，退居为少数模型和特定模式下的可选参数。

这不是说所有模型都删除了 temperature。真正发生变化的是：开发者不能再假设“所有模型都支持它”，也不能再假设“temperature 越低，推理质量越高”。

一、Temperature 原本解决什么问题？

Temperature 作用在每一步生成的 Token 概率上。温度越低，概率分布越尖锐，模型越倾向于选择当前最可能的 Token；温度越高，候选 Token 的概率差距被拉平，输出通常更有变化。

因此它曾经承担三件事：

• 用低温减少随机表达；
• 用 temperature=0 接近贪心解码；
• 用高温增加创作和采样的多样性。

但这三个用途都建立在一个前提上：模型的主要问题是“最后一步选哪个 Token”。对于具备长推理过程的模型，这个前提已经不够了。模型可能在内部推理阶段走进一条错误或循环的路径，最后一步的采样温度并不能修复这条路径。

二、OpenAI：推理强度开始取代 Temperature

OpenAI 当前模型指南 对 GPT-5.2 的参数兼容性已经给出了非常直接的信号。

在 GPT-5.2 中，temperature、top_p 和 logprobs 只在 reasoning.effort 为 none 时支持。请求使用其他推理强度，或者向较早的 GPT-5 推理模型传入这些字段，就可能直接报错。

这意味着同一个参数是否可用，不再只由模型名称决定，还由模型当前是否进入推理模式决定。

官方建议使用以下参数替代传统采样参数：

• reasoning.effort：控制模型愿意投入多少推理工作；
• text.verbosity：控制回答的详略程度；
• max_output_tokens：控制最终输出上限。

在 GPT-5.6 的模型指南中，OpenAI 继续把推理强度、输出详略、工具调用和上下文管理放在参数设计的中心位置。对于本站价格页中的 gpt-5.6-sol，开发者更应该关注推理强度与延迟、Token 成本之间的关系，而不是把所有请求都附带一个 temperature。

OpenAI 开发者论坛中的实际问题也说明了这一变化并非纸面设计：GPT-5 models - Temperature 主题目前有超过 1.2 万浏览，讨论集中在 temperature 被拒绝、只能使用默认值，以及“推理模型为什么不再开放这个旋钮”等问题。

三、Gemini 3：低温可能带来循环和性能下降

Google 的 Gemini 3 开发者指南 给出了更加明确的迁移建议：Gemini 3 系列建议保留默认温度 1.0；如果把温度调到 1.0 以下，复杂数学或推理任务可能出现循环或性能下降。

Google 同时提供了 thinking_level，用它控制模型在生成最终答案前进行多少内部思考。也就是说，控制推理质量的主旋钮从 Token 随机性转移到了推理过程本身。

这件事对使用 OpenAI-compatible API 的团队尤其重要。一个网关可以让不同厂商共用 messages 和 temperature 字段，但不能因此假设这些字段在各家模型上具有相同语义。本站价格页中的 gemini-3.5-flash、deepseek-v4-flash、qwen3.7-plus 等模型，应该在模型能力表中分别记录参数支持，而不是由一个全局默认值统一注入。

四、这不是单一厂商的偶然决定

Anthropic 的扩展思考文档也体现了类似方向：在部分支持 Extended Thinking 的模型上，启用思考模式时，温度需要保持在固定值。重点不在于某个具体版本的数值，而在于 API 设计趋势——一旦模型进入思考模式，厂商会优先保证内部推理策略，而不是继续开放所有采样旋钮。

因此，本站文章样本应使用当前可用的新模型，包括：

这里的比较重点不是给出一个永久有效的“最佳温度”，而是观察每个模型属于以下哪一种：接受温度、只接受固定默认值、在某种推理模式下拒绝温度，或者使用厂商自己的思考控制参数。

五、为什么低温反而可能让推理模型循环？

一篇公开研究论文 Let’s Let’s Let’s Let’s… Understand Looping in Reasoning Models 研究了推理模型中的重复循环现象。论文摘要指出，提高温度可以降低循环，但不能修复由任务难度引起的根本错误。

这给出了一个重要的反直觉结论：

temperature=0 可以让模型更一致地走向同一条路径，但不能保证这条路径是正确的。

当某条错误的推理模式在当前上下文中具有较高概率时，过低的温度会让模型反复选择相似的 Token，形成“看起来稳定、实际上在循环”的输出。适度随机性有时能让模型跳出局部路径，但它也不等于更高的准确率。

因此，推理模型的质量控制更适合使用：

• 任务级评测集；
• 推理强度或思考预算；
• 结构化输出和 Schema 校验；
• 工具调用结果验证；
• 超时、循环和异常输出监控。

单独把 temperature 调成 0，已经不能承担“可靠性开关”的职责。

六、开发者应该怎样迁移？

1. 不要向所有模型全局注入 Temperature

下面这种网关逻辑正在变得危险：

const request = {
  model,
  messages,
  temperature: 0.2,
};

更合理的做法是先查询模型能力，再决定是否传参：

const request = { model, messages };

if (capabilities.supportsTemperature) {
  request.temperature = temperature;
}

if (capabilities.supportsReasoningEffort && reasoningEffort) {
  request.reasoning_effort = reasoningEffort;
}

对于明确拒绝 temperature 的模型，应该省略该字段并记录日志，而不是强行传入 1。固定默认值和“不支持该参数”不是一回事。

2. 用模型类型决定调参方式

3. 不要把“输出不同”误判为“模型变差”

去掉 temperature 后，模型可能仍然产生不同答案，因为服务端调度、模型版本、上下文处理和推理路径都可能带来变化。真正应该评估的是任务成功率、格式合规率、工具调用成功率、延迟和成本，而不是单纯比较两次回答是否逐字相同。

结语：Temperature 正在被放弃，但不是被所有模型删除

Temperature 仍然是一个有效的采样参数，但它正在失去“所有模型都应该支持、调低就更可靠”的地位。

新一代推理模型正在用三种方式推动它退出默认配置：限制参数、固定默认值，以及用 reasoning effort、thinking level 和输出预算替代它。对开发者而言，最大的变化不是少了一个参数，而是不能再依赖一套跨模型通用的调参口诀。

对于统一 API 平台，正确方向也很明确：保留兼容字段，但建立模型能力注册表；能传 temperature 时再传，不能传时就按模型规范处理；需要控制推理质量时，优先使用厂商提供的推理控制参数。

Temperature 参数正在被放弃，真正需要被放弃的，是把它当作大模型可靠性的万能开关。

参考资料

• OpenAI Model Guidance
• Google Gemini 3 Developer Guide
• Anthropic Extended Thinking
• OpenAI Developer Community: GPT-5 models - Temperature
• OpenReview: Let’s Let’s Let’s Let’s… Understand Looping in Reasoning Models
• UnifyLLM Pricing