temperature=0≠100%稳定：LLM推理不确定性全解析

一、一个流传甚广的误解

很多工程师初学大模型时都有这样的直觉：把 temperature 设为 0，解码就退化为贪婪搜索（Greedy Decoding），每一步都取概率最大的 token，输出路径应当被“锁死”。然而在大模型工程落地中，即便 temperature=0，同一个 Prompt 跑十次，偶尔仍会出现细微差别——某个词不同、标点漂移，甚至整段话从某个位置开始分叉。

要解释这个现象，必须认识到：temperature 只控制了“概率分布形状”这一个变量，而推理的数值路径上还叠着大量不受它控制的变量。下面从采样机制、数值计算、硬件执行、服务架构四个层面逐层拆解。

二、temperature=0 究竟改变了什么

先厘清概念。temperature 的作用是对 logits 做缩放：p_i ∝ exp(z_i / T)。当 T 趋近 0 时，分布退化为 one-hot，等效于 argmax，即贪婪解码。但有三点容易被忽略：

1. 数学上的极限不等于实现上的行为。 多数推理引擎在 T=0 时会走专门的贪心分支，但也有一些实现把它当作“极低温度的采样”处理，后续的过滤与惩罚逻辑照常执行。
2. 采样管线的其他参数相互独立。 top-k、top-p、min-p、重复惩罚、频率惩罚等 logits 处理器与 temperature 互不隶属。社区中曾出现过知名开源推理库在关闭采样后仍应用 top_p 截断的缺陷，导致“明明是贪心，输出却被过滤逻辑改写”的怪象，困扰了不少团队。
3. argmax 自身也有平局问题。 当两个 token 的 logits 完全相等时，不同实现的平局裁决策略（取先出现者、取索引最小者等）可能不同，而浮点误差恰恰最容易制造这种“近似平局”。

因此，仅设置 temperature=0，离“100% 稳定”还差得很远，这一点在当前技术条件下无法完全绕开，只能尽量压缩不确定性。

三、不确定性的真正根源

3.1 浮点数的先天精度限制

按照 IEEE 754 浮点数标准，计算机只能近似表示实数：FP32 约有 7 位十进制有效数字，FP16/BF16 更少。神经网络前向传播是数十亿次乘加运算的堆叠，每一步都可能产生舍入误差。单次运算的误差微不足道，但大模型有上百层网络、上千亿参数，误差会沿深度层层累积。到了最后的 Softmax，就可能触发“蝴蝶效应”：Token A 的概率是 49.99999%，Token B 是 50.00001%，一丁点累积误差就能让两者颠倒，贪心解码的选词随之改变。

低精度推理会进一步放大该问题。FP16 的尾数只有 10 位，量化到 INT8/INT4 后动态范围更窄，同样的扰动更容易跨过相邻 token 之间的“决策边界”。

3.2 浮点加法不满足结合律：并行归约的不确定性

这是最核心、也最容易被忽视的一点。浮点加法不满足结合律：(a+b)+c ≠ a+(b+c)。而 GPU 上一次矩阵乘法要由成千上万线程并行完成，最后通过归约求和，归约顺序取决于线程调度与分块方式，这并非恒定不变。更关键的是，部分算子依赖原子操作做跨线程累加，而原子操作的完成顺序在硬件上是未定义的——谁先抢到锁谁先累加。加法顺序不同，舍入误差就不同，最终 logits 便可能出现跑与跑之间的差异。

3.3 底层加速库的动态算法选择

主流 GPU 厂商的数值计算库在执行矩阵乘、卷积等重负载算子时，往往不绑定唯一实现，而是根据张量形状、硬件代际、资源占用等信息动态挑选“当前最优”的算法。不同 GPU 架构上的执行路径可能完全不同；即便同一块卡，某些库还会在运行时做自动调优，用计时基准挑选 kernel，这也会引入跑与跑之间的波动。主流深度学习框架的官方文档中普遍有专门章节讨论“可复现性”，明确警告部分 GPU 算子本身就是非确定性的，并提供了相应的确定性开关。

3.4 批处理与多卡并行的连带影响

生产级推理服务几乎都采用动态 batching：请求随到随插，与陌生请求拼批次。batch 形状一变，kernel 选择、切分方式、归约顺序都可能变，于是“你的请求”的输出会受“同批陌生人”的影响。张量并行下还有另一层：计算结果需要跨卡做 all-reduce 求和，求和顺序与卡数、通信拓扑相关。此外，推理引擎可能根据序列长度自动切换不同的注意力实现，KV Cache 精度、混合专家架构的路由与专家并行策略也可能随批次构成变化。同一个 Prompt 在不同时间、不同负载下命中不同执行路径，输出差异自然偶有发生。

3.5 环境与版本的隐性变量

推理框架版本、量化配置、驱动与 GPU 运行时版本，都可能改变数值路径。线上排查时，“同参数不同结果”往往不是玄学，而是这些隐性变量中某个发生了变化。

四、工程上如何逼近稳定

先给结论：目前没有银弹能做到绝对的 100% 复现，但可以通过组合手段把不确定性压到极低，并让业务对残余随机性免疫。

4.1 固定随机种子并开启确定性模式

本地或离线场景的标准做法是三件套：固定全局种子、开启确定性算子开关、关闭 Dropout 等随机层。示意性伪代码如下（不同框架接口名略有差异）：

# 伪代码：推理前的确定性配置
set_random_seed(42)                    # 固定全局随机种子
enable_deterministic_algorithms(True)  # 强制选择确定性实现的算子
model.eval()                           # 关闭 Dropout 等随机行为
params = SamplingParams(
    temperature=0.0,
    top_k=1,                # 显式收敛为贪心，避免过滤逻辑残留
    top_p=1.0,              # 显式关闭核采样截断
    repetition_penalty=1.0, # 显式关闭重复惩罚
)

需要注意：确定性开关通常要求运行库放弃高度优化的非确定性 kernel，性能损耗可能相当可观，且无法覆盖所有算子。本质上这是“可复现性换吞吐”的权衡。

4.2 锁定软硬件环境

要复现，先冻结变量：同型号 GPU、同版本驱动与运行时、同版本推理框架及其依赖、同一份权重与同一套量化配置，任何一项升级都可能改变数值路径。建议把“模型版本 + 框架版本 + 量化配置 + 硬件类型”作为推理指纹写入日志，并对输出做哈希记录，一旦出现分歧可快速定位是哪一层变化导致。

4.3 控制批处理策略

对可复现性要求极高的场景（如离线评测、回归测试），可采用固定 batch size 的批量推理、单请求独占实例、关闭动态插批，或选用支持确定性调度选项的推理服务。无论自建推理集群还是使用百度智能云这类云上推理平台，都应主动确认服务端的批处理与调度策略。线上高并发场景则需接受现实：动态 batching 与严格确定性天然冲突，应转向容错策略。

4.4 数值层面的谨慎选择

关键路径（如最终 logits 的归约、Softmax 前的统计量）尽量使用高精度累加；评估量化方案时，把“输出稳定性”作为与精度、吞吐并列的指标；对疑似平局的高熵位置保持警惕，可监测 top-2 概率差——差距过小的位置本身就是不稳定的高发区。

4.5 用工程手段对残余随机性免疫

与其追求苛刻的复现，不如让业务不依赖复现：

• 多数投票：对高风险任务采样多次取众数，用统计稳定性替代单次确定性；
• 结构化约束：用 JSON Schema 等方式约束解码空间，把差异压缩到不影响字段语义的范围；
• 幂等与缓存：对相同的（Prompt，参数，模型版本）组合做结果缓存，既省成本又屏蔽波动；
• 校验与重试：对输出做格式与规则校验，失败自动重试并记录分歧样本用于归因；
• 分流设计：产品层面把“创造性任务”与“精确任务”分开，前者保留温度，后者收敛全部随机性配置。

五、正确的认知：确定性是一个谱系

把上述手段叠加，可以从“经常不一致”推进到“几乎总是一致”，但通往数学意义上的 100% 确定性，仍受限于并行硬件的物理现实。成熟团队的做法是：离线评测锁环境、锁种子、锁批处理，追求严格复现；在线服务则通过投票、约束、缓存与监控，让不确定性不构成业务风险。理解“temperature=0 只封印了采样这一层”，才是做好 LLM 推理稳定性的第一步。