大模型推理稳定性：温度设为零就够了吗

在很多工程团队的认知里，只要把采样温度设为 0，模型就会退化为贪婪解码——每一步都选概率最大的那个 token，输出路径被彻底锁死，结果自然应该完全可复现。然而真正做过线上部署的人往往会发现：同一个提示词跑十次，偶尔仍会蹦出一两次细微差别。有时是标点变了，有时是某个词换了个同义表达，甚至整段结构都出现分叉。

这不是玄学，而是当前深度学习推理栈的客观现实。本文将从底层原理出发，逐层拆解不稳定的来源，并给出一套可落地的工程缓解方案。

一、核心结论先行

仅设置温度为 0 无法做到 100% 稳定，在当前软硬件体系下也不存在绝对意义上的 100% 确定性推理。我们能做的是：识别不确定性来源，尽可能压缩其影响面，把”偶发漂移”降到可接受水平。

下面逐条分析原因。

二、不稳定的根因分析

1. 浮点精度：IEEE 754 的天然限制

神经网络的前向传播本质上是海量矩阵运算。IEEE 754 标准下的浮点数表示本身就有精度上限，单次运算的舍入误差通常在 1e-7 量级，看起来微不足道。但问题在于累积效应：

• 一个大模型动辄数百亿甚至上千亿参数，层数可达数十到上百层；
• 每一层的矩阵乘法、归一化、激活函数都会引入微小误差；
• 误差在层间层层放大，到最后的输出层时可能已经改变了 logits 的相对大小。

考虑一个典型场景：某个位置上 Token A 的概率是 49.99999%，Token B 是 50.00001%。这点差距远小于累积误差的量级。一旦数值因误差发生翻转，贪婪解码选出的词就会改变，后续生成路径随之彻底分叉——这就是所谓的”蝴蝶效应”。

2. 非确定性算子：GPU 上的执行顺序问题

即便浮点误差可控，GPU 上还有一类更棘手的问题：非确定性算子。

主流深度学习框架的官方文档中都专门设有”可复现性”章节，明确指出部分 CUDA 算子本身是非确定性的。原因在于：

• 某些底层线性代数库和卷积库会根据硬件特性动态选择最优算法，不同 GPU 架构、不同驱动版本下走的执行路径完全不同；
• 归约类操作（如求和、求均值）在 GPU 上常用原子操作实现，而原子操作的执行顺序是未定义的，浮点加法又不满足结合律，顺序不同结果就不同；
• 算子融合策略、内存布局、线程调度等都会影响最终数值。

换句话说，同一个模型在不同硬件、不同批次大小、甚至同一台机器不同时刻运行，都可能得到不同的 logits。

3. 低精度推理会进一步放大不确定性

当使用半精度或更低精度进行推理时，尾数位大幅减少，舍入误差显著增大。原本在单精度下还能”压住”的微小差异，在低精度下更容易演变为概率排序的翻转。这也是为什么很多团队发现：量化后的模型输出稳定性明显下降。

4. 采样参数的”残留效应”

一个容易被忽视的坑是：温度设为 0 并不等于其他过滤参数失效。

部分推理框架在 do_sample=False（即贪婪解码）时，仍然会应用 top-k、top-p 之类的过滤逻辑。历史上就有过这样的问题：某版本推理库在贪婪模式下依然读取 top-p 参数，导致输出与预期不符，困扰了不少开发者。虽然后续版本修复了，但这提醒我们：

温度只是采样策略的一个开关，不代表其他参数被自动忽略。实现层面的细节决定了实际行为。

三、工程缓解方案

既然绝对稳定做不到，我们就从”减少不确定性”入手。以下是经过实践验证的几条措施。

1. 固定随机种子

在本地或自建推理服务中，第一件事是设置全局随机种子，覆盖 Python、NumPy 以及深度学习框架的随机源：

import os
import random
import numpy as np
import torch
def set_global_seed(seed: int = 42):
    os.environ["PYTHONHASHSEED"] = str(seed)
    random.seed(seed)
    np.random.seed(seed)
    torch.manual_seed(seed)
    torch.cuda.manual_seed_all(seed)

种子能锁定大部分随机来源，但它无法约束非确定性算子，所以还需要下一步。

2. 开启确定性模式

主流框架提供了确定性算法开关，强制使用确定性版本的算子：

torch.backends.cudnn.deterministic = True
torch.backends.cudnn.benchmark = False
torch.use_deterministic_algorithms(True)

需要注意几点：

• 开启后性能通常会下降，因为放弃了针对硬件自动调优的非确定性算法；
• 部分算子可能没有确定性实现，会直接抛错，需要设置环境变量允许回退或改写调用方式；
• 环境变量（如控制底层库工作空间的变量）需要在进程启动前设置。

3. 对齐批次与输入

批次大小会改变算子的执行路径和归约顺序。如果追求可复现，尽量让每次推理的批次大小、序列长度、padding 策略保持一致。动态批处理虽然能提升吞吐，但会引入额外的不确定性——在需要严格复现的场景下应关闭。

4. 固定硬件与软件栈

不同 GPU 架构、驱动版本、算子库版本都会影响执行路径。如果业务对稳定性要求极高，建议：

• 推理集群尽量使用同型号硬件；
• 锁定驱动、CUDA、框架版本，避免滚动升级带来的行为漂移；
• 建立回归测试集，每次环境变更后验证输出一致性。

5. 清理采样参数

在贪婪解码场景下，显式关闭所有采样相关参数：

outputs = model.generate(
    input_ids,
    do_sample=False,        # 贪婪解码
    num_beams=1,            # 不用束搜索
    top_k=None,             # 不启用 top-k
    top_p=None,             # 不启用 top-p
    temperature=None,       # 不参与采样
)

不同框架的参数默认值不同，不要依赖默认行为，显式声明永远更安全。

6. 在服务层做兜底

对于面向用户的在线服务，可以在应用层增加一致性保障：

• 对相同输入缓存首次推理结果，命中缓存直接返回，避免重复计算带来的漂移；
• 对输出做后处理规范化（如统一标点、去除多余空白），消除表面差异；
• 建立监控指标，统计同一输入的输出差异率，及时发现异常。

7. 用日志与版本管理固化现场

每一笔推理请求都应记录：模型版本、权重哈希、框架版本、驱动版本、批次配置、随机种子、完整输入输出。一旦出现不一致，可以快速定位是环境变化还是算法本身的问题。

四、实践建议清单

措施	作用	代价
固定随机种子	锁定随机源	几乎无
开启确定性算子	消除非确定性计算	性能下降
固定批次与输入	稳定执行路径	牺牲动态批处理
统一硬件软件栈	减少环境漂移	运维成本
清理采样参数	避免参数残留	无
缓存与后处理	应用层兜底	内存与逻辑开销

五、总结

温度设为 0 只是关闭了采样随机性，它管不住浮点误差、管不住非确定性算子、也管不住实现层面的参数残留。想要让大模型推理尽可能稳定，需要从数值精度、算子确定性、批次对齐、环境一致性、参数显式化、服务层兜底六个维度协同发力。

工程上的正确心态不是追求”100% 稳定”这个不存在的目标，而是把不确定性量化、隔离并压缩到业务可接受的范围内。对于绝大多数应用场景，做到上述几点后，同一输入的输出差异率可以降到极低水平；而对于确实需要严格复现的场景（如审计、评测），则应在架构设计阶段就把确定性要求纳入考量，而不是等到线上出问题再补救。