推理模型为什么不再鼓励手动设置 temperature

temperature 曾经是调用 LLM（大语言模型）时最常见的参数之一。很多人会把它理解成一个“随机性旋钮”：值越低，输出越稳定；值越高，输出越发散。早期做问答、摘要、代码生成时，这个经验大体可用，所以不少工程代码都会显式写上：

{
  "temperature": 0
}

或者：

{
  "temperature": 0.2
}

但在推理模型上，这个习惯正在变得危险。OpenAI 的 o1 系列开始限制 temperature，后续推理模型也延续了类似做法；Gemini 3 的文档建议移除显式 temperature 设置，尤其不要为了确定性而设置过低温度；DeepSeek-R1、Qwen QwQ-32B、Qwen3 Thinking 模式等开源或开放权重模型，也都有“不建议 temperature 太低”的使用提示。

这不是单个厂商的接口偏好，而是推理模型和低温解码之间出现了结构性冲突。

temperature 到底控制了什么

LLM 每生成一个 token，都会先算出词表中每个候选 token 的分数，这些分数通常叫 logits。模型不会直接输出 logits，而是通过 softmax 把它们变成概率分布。

temperature 的作用，是在 softmax 之前缩放 logits：

p_i = softmax(z_i / T)

其中：

• z_i 是第 i 个 token 的 logit；
• T 是 temperature；
• p_i 是最终采样概率。

不同温度下，概率分布会发生明显变化：

可以用一个简单例子理解。假设模型在某一步有三个候选 token：

低温会把 A 的优势放大，高温会让 B、C 更有机会被选中。也就是说，temperature 并不改变模型“知道什么”，它只改变模型在多个候选 token 之间如何取样。

flowchart LR
    A[输入上下文] --> B[模型计算 logits]
    B --> C[temperature 缩放 logits]
    C --> D[softmax 得到 token 概率]
    D --> E[采样或贪心选择]
    E --> F[生成下一个 token]
    F --> A

关键点在这里：temperature 操作的是 token 层面的局部选择，而不是语义层面的整体规划。它只能影响“下一步选哪个 token”，并不能直接保证“整个推理路径更正确”。

低 temperature 曾经解决过哪些问题

temperature 被广泛使用，主要是因为它看起来能解决三个需求。

早期 LLM 的回答通常比较短，推理链也不长。此时降低 temperature 确实可能减少一些奇怪输出，因为模型每一步都更倾向于选择最高概率 token。

但推理模型改变了这个前提。它们会在回答前进行更长的内部思考，输出或隐式生成大量中间推理 token。一次任务不再是几十个 token 的局部生成，而可能是一条很长的推理轨迹。轨迹越长，局部选择带来的累积效应越明显，低温不一定更稳，反而可能把模型锁进某种重复模式。

推理模型上的新现象：低温更容易 loop

looping 指模型陷入循环输出，反复生成类似内容，无法自然结束。在推理模型中，典型表现包括：

我需要再检查一下……
让我重新分析……
需要确保没有遗漏……
我需要再检查一下……
让我重新分析……
需要确保没有遗漏……

或者在数学、代码、逻辑题里反复验证同一个步骤，却始终不进入最终答案。

已有公开实验和模型说明里出现了几个一致现象：

一个 ICLR 2026 投稿中讨论过类似现象：temperature 在大约 0.6–0.8 的中间区间时，准确率可能达到峰值；继续降低 temperature，不但不一定提高正确率，还可能让无限循环更严重。

这和传统经验相反。传统经验认为“更低温度 = 更稳定 = 更可靠”，但推理模型里的稳定有时只是稳定地重复错误模式。

为什么低温会把推理模型卡住

可以把推理过程看成模型不断在几个方向之间选择：

1. 继续展开新步骤；
2. 回头检查已有步骤；
3. 修正前面的推理；
4. 给出最终答案；
5. 陷入重复表达或重复检查。

当任务简单时，“推进到下一步”通常有很高概率，低温不会造成明显问题。任务变难后，模型对正确路径的信心下降，各种候选路径的概率差距变小。此时如果“继续检查”“再想一遍”“重复已有模式”略微高于其他选项，低温会不断放大这个局部优势。

flowchart TD
    A[复杂问题] --> B[模型进入长推理]
    B --> C{下一步 token 分布}
    C --> D[推进解题]
    C --> E[检查已有步骤]
    C --> F[重复已有表达]
    C --> G[输出最终答案]

    E --> C
    F --> C
    D --> C
    G --> H[结束]

    C -. 低 temperature 放大局部最高概率 .-> F
    C -. 中等 temperature 保留跳出机会 .-> D

低温解码的问题在于，它让“当前最高概率选项”持续胜出。只要循环模式在某些状态下成为局部最优，模型就可能一次又一次选择它。

中等 temperature 反而可能给模型一点跳出局部循环的空间。它不会像高温那样完全打散分布，但能避免每一步都死死选中同一个局部最优 token。

这也是为什么一些推理模型推荐使用默认温度，或者明确建议不要设置过低温度。

RL 后训练可能放大了这个问题

很多推理模型会经过 RL（强化学习）后训练，让模型更擅长多步推理、检查答案、发现错误并修正。这个方向本身很有用，因为复杂问题确实需要分解、验证和回溯。

但它也可能带来一个副作用：模型学到了大量“继续思考”“重新检查”“不能草率下结论”的模式。正常情况下，这些模式能提高复杂任务表现；一旦模型卡在不确定状态，它们也可能变成循环的燃料。

可以粗略理解为：

flowchart LR
    A[RL 后训练] --> B[鼓励长推理]
    B --> C[模型更常检查和反思]
    C --> D[复杂任务表现提升]
    C --> E[不确定时更容易继续想]
    E --> F[低温解码放大重复路径]
    F --> G[looping]

这里不能把根因简单归结为 RL。公开信息还不足以精确说明每个模型内部发生了什么，不同厂商的训练流程也不一样。更稳妥的说法是：推理模型的长轨迹生成、反思模式和低温解码叠加后，更容易暴露循环问题。

各家模型对 temperature 的态度变化

几个代表性变化可以放在一起看。

这些变化说明，temperature 不再是所有 LLM 调用里都适合暴露给业务层随意调节的参数。尤其在 reasoning mode / thinking mode 下，模型提供方往往更希望使用经过验证的默认采样策略。

temperature 的三个旧用途正在失效

用 temperature = 0 获取可复现性

在自部署开源模型时，如果推理框架、模型权重、硬件、并行策略都固定，greedy decoding 确实有机会得到高度一致的输出。

但商业闭源 API（应用程序编程接口）很难保证这一点。即使 temperature 为 0，结果仍可能因为这些因素变化：

如果业务真的需要可复现，不应该只依赖 temperature。更可靠的做法是记录完整输入、模型版本、输出结果和中间工具返回；必要时把关键生成结果落库，而不是每次重新生成。

用低 temperature 提高可靠性

低 temperature 只能让模型更倾向于选择高概率 token。高概率 token 不一定代表事实正确，也不一定代表推理正确。

比如模型在一道难题里有两个路径：

低温会更偏向 A，因为 A 在训练语料中更常见、更顺滑。它降低了随机性，却没有增加知识，也没有增加验证能力。

提高可靠性更应该依赖这些手段：

temperature 可以作为采样策略的一部分，但不能当成可靠性方案。

用高 temperature 获得多样性

高 temperature 确实会增加输出变化，但它增加的是 token 层面的随机性。业务真正需要的多样性，通常不是“句子更随机”，而是“方案角度不同、约束不同、样例不同”。

更可控的多样性可以从上下文中注入：

请给出 5 个方案，要求它们分别从以下角度展开：
1. 成本最低
2. 实现最快
3. 长期维护最简单
4. 对性能最友好
5. 对安全边界最保守

或者：

请生成 3 个不同版本：
- 版本 A 面向初级工程师，强调概念解释
- 版本 B 面向架构师，强调权衡和边界
- 版本 C 面向运维团队，强调部署和监控

这种方式比单纯提高 temperature 更可控，因为差异来源被显式写进了任务，而不是交给随机采样。

工程代码应该怎么改

如果正在接入推理模型，建议把“普通聊天模型配置”和“推理模型配置”分开，不要沿用同一套默认参数。

不推荐：所有模型共用低温配置

DEFAULT_GENERATION_CONFIG = {
    "temperature": 0.0,
    "top_p": 1.0,
    "max_tokens": 4096,
}

response = client.responses.create(
    model="reasoning-model",
    input="解决这个数学题……",
    **DEFAULT_GENERATION_CONFIG,
)

这类写法的问题是：低温参数可能对普通模型没问题，却在 reasoning / thinking 模式下触发循环、被 API 拒绝，或者导致模型表现变差。

更稳妥：推理模型使用厂商默认采样策略

response = client.responses.create(
    model="reasoning-model",
    input="解决这个数学题……",
    # 不显式传 temperature / top_p
)

如果需要同时支持多类模型，可以在配置层明确区分：

MODEL_CONFIGS = {
    "general_chat": {
        "temperature": 0.7,
        "top_p": 0.9,
    },
    "reasoning": {
        # 推理模型优先使用服务商默认值
        # 不传 temperature / top_p
    },
}

def build_generation_args(model_type: str) -> dict:
    return MODEL_CONFIGS.get(model_type, {}).copy()

对 Gemini 3 这类明确提示的模型，删除低温设置

# 不推荐
config = {
    "temperature": 0.0,
}

# 推荐：使用默认值
config = {}

如果旧系统里为了“稳定输出”统一设置了 temperature=0 或 temperature=0.2，迁移到推理模型时要重点检查。最容易出问题的地方通常是：

如果业务需要稳定输出，应该控制什么

放弃低温不等于放弃稳定性。稳定性应该从任务结构、输出约束和验证链路上解决。

flowchart TD
    A[稳定输出需求] --> B[固定模型版本]
    A --> C[固定输入模板]
    A --> D[结构化输出]
    A --> E[外部校验]
    A --> F[结果缓存]
    A --> G[失败重试策略]

    D --> H[JSON Schema / 函数调用]
    E --> I[规则校验 / 单元测试 / 检索核对]
    F --> J[关键结果落库]
    G --> K[超时、循环、格式错误分别处理]

可以按需求选择控制点：

对推理模型来说，temperature 只是一个低层采样参数。真正能让系统稳定的是端到端工程约束。

一个简单的迁移清单

从旧聊天模型迁移到推理模型时，可以按这个清单检查：

一个实用的原则是：普通模型可以保留采样参数作为风格控制；推理模型尽量不要手动压低 temperature，除非模型文档明确允许并给出了推荐范围。

temperature 不是推理能力的控制杆

temperature 的退场，并不表示解码参数完全不重要，而是说明 token 层面的控制越来越难承担语义层面的目标。

早期 LLM 输出较短，temperature 还能粗略影响风格、保守程度和随机性。推理模型引入长思考链后，模型行为更多取决于训练方式、推理模式、上下文结构和任务难度。此时继续用低温去追求“更可靠”，可能得到相反效果：模型更确定地走进局部循环。

更合理的做法是：

• 推理模型使用默认 temperature 或官方推荐配置；
• 不再用 temperature=0 当作可复现性的主要手段；
• 用结构化输出、外部校验、评测集和结果缓存控制稳定性；
• 用明确的上下文约束制造多样性，而不是只调高随机性；
• 把普通聊天模型和 reasoning / thinking 模式的配置分开管理。

temperature 曾经是 LLM 接口里最常被调的旋钮之一，但在推理模型时代，它正在从“默认必配项”变成“谨慎使用项”。对工程系统来说，最安全的变化通常很简单：删掉旧代码里为了稳定而写下的低温设置，让推理模型按经过验证的默认策略工作。