大模型推理稳定性保障：温度设为零的局限与工程实践

在很多开发者的直觉里，把生成温度（temperature）设为 0，就等于让模型每次都选择概率最高的那个词，采样路径被完全锁死，输出理应逐字一致。然而在实际工程落地中，同一个提示词跑十次，偶尔仍会蹦出一两次细微差别。这不是幻觉，也不是配置写错了，而是当前深度学习推理体系固有的不确定性在起作用。本文从原因到方案，系统梳理这一问题，并给出可落地的稳定性保障实践。

一、为什么 temperature=0 做不到 100% 稳定

1.1 浮点运算的精度天花板

神经网络的前向传播本质上是海量矩阵运算。这些计算在 GPU 上执行时，遵循 IEEE 754 浮点数标准，而该标准本身就存在表示精度限制。当模型在不同硬件、不同批处理大小（batch size）、甚至不同算子融合策略下运行时，累积的舍入误差会让最终输出的 logits 出现微小差异。

对于一个拥有数百亿甚至上千亿参数的模型，这种微小的精度误差会在几十到上百层网络中层层累积。到了最后的 Softmax 层，就可能引发“蝴蝶效应”：假设 Token A 的概率是 49.99999%，Token B 是 50.00001%，一丁点累积误差就能让这两个数值颠倒。此时即便使用贪婪解码（Greedy Decoding），选出来的词也会改变——第一个词变了，后续所有 token 的上下文随之改变，输出便彻底分叉。

1.2 非确定性算子的普遍存在

主流深度学习框架的官方文档中都有关于“可复现性（Reproducibility）”的专门章节，明确指出某些 GPU 算子本身就是非确定性的。典型来源包括：

• cuBLAS / cuDNN 的算法选择：底层加速库在默认配置下会根据硬件特性动态选择最优算法。例如卷积操作的 GEMM 实现，在不同 GPU 架构下的执行路径完全不同，归约顺序不同，浮点累加结果自然不同。
• 原子操作的执行顺序未定义：GPU 上的 atomic 操作（如梯度累加、直方图统计）在多线程并发时执行顺序不确定，导致结果随运行次数波动。
• 低精度推理放大误差：在使用 FP16、BF16 等低精度格式时，舍入误差进一步放大，不确定性更加明显。

1.3 采样参数的“隐形残留”

即便 temperature 设为 0，很多实现中的 top-k、top-p 过滤仍然可能生效。历史上部分推理库在 do_sample=False 时仍会应用 top_p 参数，导致输出与预期不符。这类实现细节问题曾让不少开发者踩坑。因此，稳定性保障不能只盯着 temperature 一个参数。

1.4 其他扰动源

• 批处理组成变化：同一请求与不同请求拼批，会改变矩阵乘法的分块方式和归约顺序。
• 动态图与算子融合：推理引擎的图优化、算子融合策略可能随输入形状变化而切换。
• 多卡并行：张量并行、流水并行的通信顺序与规约方式引入额外不确定性。

二、工程上的稳定性保障方案

需要先明确一个前提：在当前软硬件体系下，绝对 100% 的确定性难以完全保证，工程目标是尽可能收敛不确定性，把波动控制在可接受范围内。 以下是按优先级排列的实践手段。

2.1 固定随机种子并启用确定性模式

本地或自建推理服务中，第一步是固定所有随机源，并开启框架提供的确定性开关。以 PyTorch 风格为例：

import torch, random
import numpy as np
def set_deterministic(seed=42):
    random.seed(seed)
    np.random.seed(seed)
    torch.manual_seed(seed)
    torch.cuda.manual_seed_all(seed)
    # 强制使用确定性算法
    torch.backends.cudnn.deterministic = True
    torch.backends.cudnn.benchmark = False
    # 关闭可能引入非确定性的优化
    torch.use_deterministic_algorithms(True, warn_only=True)

需要注意，use_deterministic_algorithms 可能使部分算子回退到较慢的实现，需要在性能与稳定性之间权衡。warn_only=True 便于先观察哪些算子触发了非确定性告警，再针对性处理。

2.2 统一推理配置，消除批处理差异

• 固定批处理大小：尽量让同一类请求以固定 batch size 推理，避免动态拼批带来的归约顺序变化。
• 固定输入形状：对长文本场景，采用固定长度分块或 padding 策略，减少形状变化引发的算子切换。
• 锁定推理引擎配置：关闭自动调优（autotuning）、固定算子融合策略、固定精度模式（如统一使用 FP16 或 BF16），并在服务启动时固化。

2.3 清理采样参数，显式关闭随机采样

在调用推理接口时，显式设置 do_sample=False，并确认 top_k、top_p 等过滤参数不会在贪婪模式下被误用。建议在服务封装层做参数校验，避免不同版本库的行为差异。对于需要稳定输出的业务场景，还应关闭所有形式的随机增强、随机丢弃等训练期特性。

2.4 固定软件与硬件环境

• 锁定框架与加速库版本：算子实现随版本变化，升级可能改变数值行为。
• 固定 GPU 型号与驱动：不同架构的归约顺序不同，混部会引入差异。
• 容器化交付：将推理环境打包为镜像，确保线上线下一致。

2.5 结果校验与容错设计

即使做了上述措施，仍建议在业务层增加兜底：

• 关键字段校验：对结构化输出做 schema 校验，失败时重试或降级。
• 多次推理投票：对稳定性要求极高的场景，可采样多次取多数一致结果，以成本换稳定。
• 日志与差异监控：记录每次请求的输入、输出与关键中间统计量，发现漂移及时告警。

三、小结

temperature=0 只是关闭了采样随机性，并不能消除数值计算层面的不确定性。浮点精度限制、非确定性算子、批处理与形状变化、参数残留，都是输出漂移的潜在来源。工程上的正确姿势是：固定种子与确定性模式、统一推理配置、清理采样参数、锁定软硬件环境、辅以业务层校验与监控，把不确定性收敛到可控范围。在百度智能云等云平台的推理服务实践中，这类稳定性保障同样是构建可信赖大模型应用的基础能力。理解不确定性的来源，比追求一个不存在的“绝对开关”更有价值。