Quartz 4

01-推理阶段的非确定性

8 min read

LLM 推理的非确定性：为什么 Temperature=0 也无法保证一致性

这是面试和项目中常见的陷阱题。很多人会说”浮点数精度”，但那只是表面原因。真实情况要复杂得多。

相关文档：术语表

问题的本质

理论上，temperature=0 意味着模型每次都选择概率最高的 token（贪心解码），应该是完全确定的。但现实中，即使设置 temperature=0 和固定 seed，调用 GPT-4 多次也经常得到不同的输出。

为什么会这样？答案在于整个推理栈中存在多个”非确定性源头”。

导致不一致的核心原因

1. 浮点数运算的微小偏差

直观理解：计算机处理小数时存在精度限制。当多个 token 的概率非常接近时，微小的舍入误差就可能改变排序。

举个例子：模型计算出”很好” = 0.500000001，“非常好” = 0.499999999。这两个概率几乎相同，但 GPU 的浮点精度在第 8 位可能产生差异，导致这一次选”很好”，下一次选”非常好”。

为什么会这样：不同的硬件、不同的计算顺序，甚至同一个 GPU 在不同时间的计算，都可能在小数点后的某一位产生不同结果。

2. 并行计算的执行顺序不固定

为什么浮点数加法有问题：

(a + b) + c ≠ a + (b + c) （由于精度限制）

现代 GPU 为了提高效率会并行计算。计算 100 个数字的求和时，可能这次从左往右加，下次分成 10 组同时加再合并。这两种计算顺序虽然应该结果相同，但在浮点数世界里，累加顺序的微小差异会传播和放大。

当这种差异作用在 token 的概率计算上时，就能改变 top-1 token 的选择。

3. MoE 架构的动态路由

背景：GPT-4 等模型采用 MoE（Mixture of Experts）架构，由多个专家子网络组成。系统动态决定每个 token 由哪个专家处理。

问题所在：在生产环境中，多个用户的请求会被打包成一个批次处理。你的请求每次被批处理时的”邻居”不同，可能导致关键 token 被路由到不同的专家。

具体例子：

  • 你发送：“解释量子计算的原理”
  • 这次，它和 9 个用户都在问数学问题的请求打包到一起
  • 路由器为了负载均衡，把”量子”这个 token 分配给了相对空闲的”物理专家”
  • 下一次，你的请求和问图像处理的请求打包到一起
  • 路由器这次把”量子”分配给了”通用专家”
  • 结果：同一个 token 被不同的专家处理，后续输出就不一样了

即使 temperature=0，这也不是采样的随机性问题，而是计算路径本身改变了。

4. 动态批处理与调度

云服务为了资源效率，会动态地将用户请求组合成批次。同一个请求在不同时间发送，其所在的批次组合可能不同。这影响了：

  • 内存布局
  • 缓存命中率
  • 计算优化的路径选择

不同的批次配置可能导致不同的计算路径，进而产生不同的结果。

5. 框架与算子实现的非确定性

深度学习框架（如 PyTorch）为了追求速度，默认允许某些非确定性的算法实现。比如：

  • 矩阵乘法有多种 GPU 实现方式
  • 框架会根据效率动态选择实现
  • 这些实现可能因使用原子操作等策略而产生微小差异

6. 硬件异构性

云服务商可能拥有不同型号的 GPU 集群。你的请求可能这次落在 A100 上，下次落在 H100 上。不同硬件的驱动、计算内核可能略有不同，从而导致微小但足够的数值差异。

总结：不确定性的分层

采样层 (最明显)
  ↓ temperature 参数控制
贪心解码 (理论上确定)
  ↓ 但实际上...
浮点数精度 / 并行计算顺序
  ↓
MoE 路由 / 批处理调度
  ↓
硬件异构性

Temperature=0 只能消除采样层的随机性。其他几层的非确定性是系统固有的，难以完全消除。

如何最大化一致性

虽然无法保证 100% 确定性，但可以采取以下措施：

基础设置

# API 调用
temperature=0
top_p=1
seed=42  # 如果 API 支持

自托管模型的方案

import torch
 
# 启用 PyTorch 的确定性模式（会牺牲性能）
torch.use_deterministic_algorithms(True)
torch.manual_seed(42)
 
# 禁用非确定性的 CUDA 算子
os.environ['CUBLAS_WORKSPACE_CONFIG'] = ':4294967296'

工程实践

  • 固定硬件：在自己的服务器上部署，避免异构集群
  • 统一环境：相同的 PyTorch 版本、相同的 GPU 型号
  • 重试逻辑：关键应用中实现输出验证和重试机制
  • 指纹化：记录输入的哈希值，用于调试非确定性问题

面试回答模板

问题：Temperature=0 时为什么仍然无法复现输出？

答案分层：

  1. 第一层：浮点数精度和并行计算顺序会导致相近概率的 token 排名逆转
  2. 第二层：MoE 架构的动态路由在不同批次中可能改变关键 token 的计算路径
  3. 第三层：云服务的批处理调度和硬件异构性进一步放大这些效应
  4. 结论：Temperature=0 消除的只是采样层的随机性，系统级的非确定性是根本问题

相关概念：

  • argmax vs sampling：前者确定但系统非确定，后者算法非确定
  • seed 参数的局限性：只能固定随机数生成器，无法消除数值计算的非确定性
  • CUBLAS_WORKSPACE_CONFIG：控制 cuBLAS 是否使用非确定性算法

Graph View

Backlinks