怎样让LLM推理尽量稳定：temperature=0只是起点

一、先破除一个流行误区

在许多开发者的认知里，temperature=0 等价于贪婪解码：每一步都选概率最大的 token，生成路径理应被彻底锁死，输出 100% 一致。这个推理的前半段没有问题，但结论在工程现场经常翻车——同一个 Prompt、同一套参数、同一个模型，跑十次偶尔仍会蹦出一两次细微差异：有时是一个标点，有时是一个近义词，长文本场景下甚至整段走向都不一样。

先把结论放在前面：只设定 temperature=0，做不到 100% 稳定。以当前的技术条件，大模型推理的绝对确定性无法被承诺；工程上能做的，是系统性地压缩不确定性的来源与影响范围，把波动控制到业务可接受的水位。

二、temperature=0 到底锁定了什么

先拆开看一次解码的完整流程：

模型前向计算产出 logits → logits 经 temperature 缩放 → Softmax 归一化为概率分布 → 采样或 argmax 选出下一个 token。

当 temperature=0 时，工程实现通常会直接退化为 argmax，即贪婪解码。注意它给出的保证是有前提的：在 logits 完全相同的情况下，选择结果完全相同。它锁死的是”从概率分布到 token”这一段映射，锁不死的是”从输入到 logits”的计算过程。

换句话说，贪婪解码承诺的是映射的确定性，而非计算的确定性。一旦 logits 本身存在哪怕极小量级的抖动，这个承诺就自动失效。而 logits 的抖动，在 GPU 大规模并行计算的时代，几乎无法根除。

三、logits 为什么会抖：五个层面的技术根源

3.1 浮点数天生带精度上限

IEEE 754 标准规定了浮点数的表示与运算规则：单精度只有约 7 位有效十进制数字，双精度约 16 位。一次模型推理是数以亿计的乘加运算，每一步都可能产生舍入误差。更麻烦的是，浮点加法不满足结合律——同一组数按不同顺序累加，最终结果可能不同。误差不是”会不会出现”的问题，而是”必然出现、只差大小”的问题。

3.2 GPU 上存在天然非确定性的算子

主流深度学习框架的官方文档都设有”可复现性（Reproducibility）”专章，并明确提示：部分 GPU 算子本身就是非确定性的。典型来源有两类：

• 原子操作：归约、scatter 类算子依赖原子加完成并发累加，而原子操作的执行顺序在硬件层面是未定义的。叠加”浮点加法不满足结合律”这一特性，执行顺序不同，累加结果就会出现末位差异。
• 动态算法选择：GPU 底层数学库为了性能，会依据矩阵形状、硬件代次等条件，在多套实现中动态挑选”当前最优”的矩阵乘算法。不同算法的分块方式、并行策略、累加顺序各不相同，结果自然存在细微差别。硬件厂商在公开技术文档中也承认这一点，并说明这是”性能换确定性”的设计取舍。

3.3 深层网络把微小误差放大成”蝴蝶效应”

单次运算的误差可能只有小数点后第七位，看似无害。但大模型动辄几十上百层、数百上千亿参数，误差会逐层累积、混合。当传播到最终 Softmax 层时，若两个候选 token 的概率极其接近——例如 49.99999% 对 50.00001%——一丁点扰动就足以让 argmax 翻转，选出的词随之改变。

更关键的是自回归生成的滚雪球效应：某一步选出的 token 不同，后续上下文就整体不同，差异随生成长度持续放大。这解释了两个常见现象：

• 输出差异往往出现在长文本的中后段，而不是开头；
• 表现为”十次里偶尔崩一两次”而非”每次都不同”——多数解码步的 top-1 概率遥遥领先，只有恰好撞上”近似平局”的分叉点才会翻车。

类似地，如果模型内部存在依赖概率比较的动态计算路径（例如稀疏专家路由），近似的 logits 差异甚至可能改变整条计算路径，影响面更大。

3.4 执行环境差异：同一份代码，不同的数值路径

即便代码完全一致，以下变量都会改变计算路径：

• 硬件与软件栈：不同型号 GPU、不同驱动版本、不同框架与加速库版本，算子实现可能不同；
• batch size 与 padding：单条请求独跑与多条请求拼批，序列 padding 长度不同，底层 kernel 的任务划分与执行调度就不同；
• 算子融合策略：推理引擎为提速会自动融合算子，融合后的中间结果精度可能与逐算子执行存在差异；
• 精度与量化：FP16、BF16、INT8 等低精度方案有效位更少，”近似平局”出现的概率显著上升，不确定性被进一步放大。

3.5 采样实现里的”暗坑”

还有一个容易被忽视的层面：采样代码自身的实现细节。部分生成式模型的实现中，即使显式关闭了随机采样，top-k、top-p 过滤逻辑仍会生效。业界曾有知名开源实现库的早期版本就存在这类问题——贪婪模式下 top_p 参数依然被应用，导致输出与预期不符，排查过程让不少开发者头疼。

因此配置卫生很重要：不要只动 temperature。top_k、top_p、repetition_penalty 等所有会影响候选集与排序的参数都应显式固定，并核对你所用版本的实际行为，避免”默认值悄悄生效”。

四、工程对策：把不确定性压到最低

4.1 固定随机种子：必要，但不充分

自建推理链路的第一步，是统一固定各层随机源：

# 示意代码：统一固定各层随机种子
def set_all_seeds(seed: int = 42):
    builtin_random.seed(seed)                 # 脚本语言内置随机源
    matrix_lib.seed_all(seed)                 # 数值计算库随机源
    dl_framework.manual_seed(seed)            # 框架 CPU 侧随机源
    dl_framework.accelerator_seed_all(seed)   # GPU/加速器侧随机源

两点提醒：

• seed 只能消除”随机性”，消除不了”非确定性”。原子操作顺序、动态算法选择造成的波动与随机数无关，设了 seed 也拦不住；
• 分布式推理时，确保每个 worker 的种子设置策略一致，否则不同副本的行为可能对不上。

4.2 开启确定性模式：用性能换稳定

主流框架普遍提供确定性算子开关。开启后，框架优先选用具有确定性实现的算子版本；若某个算子没有确定性替代，会直接报错，把隐患显式暴露出来，而不是悄悄给出不同结果。部分 GPU 数学库还要求通过环境变量显式声明确定性工作区配置，否则即便框架层面开启了开关，底层也会回退到非确定实现。

代价是性能：确定性实现通常更慢，吞吐会有可感知的下降。这是典型的”稳定 vs 吞吐”取舍，建议只在稳定性强相关的链路（如评测、回归测试、对齐调试）上开启。同时要认清边界：确定性模式承诺的是”同环境下可复现”，并不承诺跨硬件一致。

4.3 固定执行环境：把变量一个个钉死

• 硬件对齐：稳定性关键链路固定使用同型号 GPU；
• 版本对齐：框架、加速库、驱动、模型权重、分词器全部纳入版本管理。任何升级都应视为”可能改变输出分布”的变更，先走回归验证再上线；
• batch 策略：对稳定性要求极高的场景，考虑 batch_size=1 并固定 padding 长度，避免动态拼批改变数值路径；
• 精度锁定：量化方案与推理精度档位保持固定，不要在生产链路上随意切换。

4.4 数值层面主动”拉开差距”

既然分叉高发在”近似平局”处，可以做两件事：

• 风险监控：在推理链路中记录每步 top-1 与 top-2 的概率差，差值越小风险越高。对高危步做统计，可以量化评估当前链路的稳定水位；
• 关键层高精度：对 logits 敏感的输出层附近保持高精度计算，降低近义 token 概率贴近的概率；低比特量化需谨慎评估——它省下的算力成本，可能以输出波动为代价。

4.5 业务侧容错：接受波动，管理波动

最务实的做法，是在应用设计上给不确定性留出缓冲：

• 语义稳定优先于字面稳定：回归测试与评测采用语义等价断言（关键结论比对、结构化字段校验），不苛求逐字符一致；
• 缓存与幂等：相同”Prompt + 参数 + 模型版本”的请求直接命中缓存，既降成本，又天然消除重复调用间的波动；
• 输出校验与重试：对输出做格式与规则校验，不合规自动重试或降级到兜底逻辑；
• 明确稳定性承诺：对外提供服务时，承诺”模型版本 + 参数”级别的稳定，而不是承诺”永远输出同一句话”。

五、回到一个现实的目标

需要坦率承认：受浮点精度、非确定性算子、硬件差异、分布式执行等多重因素影响，”100% 稳定”在当前技术条件下无法承诺，跨硬件的逐字节复现更是几乎不可能。工程上的合理目标是三层：

1. 同环境尽量可复现：seed + 确定性模式 + 环境固定；
2. 偶发波动可控：缓存、幂等、重试、语义校验兜底；
3. 差异可解释：版本变更流程 + 输出监控，让每一次”变化”都有据可查。

最后附一份可直接落地的检查清单：

• temperature=0，并显式固定 top_k / top_p 等全部采样参数；
• 统一设置各层随机种子，分布式场景逐一核查每个 worker；
• 稳定性关键链路评估开启确定性模式的性能代价；
• 固定硬件、驱动、框架与加速库版本；
• 模型权重与分词器纳入版本管理，升级必走回归验证；
• 固定 batch 与 padding 策略（必要时 batch_size=1）；
• 关键层保持高精度计算，谨慎使用低比特量化；
• 测试断言采用语义等价而非精确字符串匹配；
• 引入缓存与幂等设计，输出增加格式校验与自动重试。

做到这些，虽然仍不敢说 100%，但足以把不确定性压缩到绝大多数业务都能安心接受的水位——这也正是”尽量减少不确定性”的工程本义。