确定性解码为何仍不稳定：并发浮点归约差异对比

一、对比背景：当“温度设为零”不再等于“结果唯一”

在调用大语言模型时，很多开发者会形成一种直觉：只要把温度参数设为零，采样过程退化为贪心解码，即每一步都取 logits 最大的 token，输出就应当是确定性的。然而实际调试中经常出现一个反直觉现象：同一个 prompt 重复输入多次，得到的输出仍然不完全一致。

这就引出了本文要对比的两类解释视角：

• 视角 A：采样随机性——由温度、top-k、top-p 等采样参数引入的随机选择；
• 视角 B：并发执行与数值非确定性——即使采样完全确定，底层算子的执行顺序、浮点归约顺序仍可能让结果产生微小偏差，并逐步放大。

本文的核心结论是：温度设零只排除了视角 A，并不能自动排除视角 B。两者在表象上都表现为“输出不一样”，但根因、可复现性、影响范围和修复手段完全不同。

二、对象定义：两种非确定性来源分别是什么

2.1 采样随机性

采样随机性来自解码策略本身。当温度大于零时，模型按概率分布抽取 token；即使温度设为零，如果实现中仍保留了某些随机采样路径（例如未正确进入贪心分支），也可能引入随机性。这类非确定性通常表现为：

• 同一 prompt 输出差异明显，甚至语义走向不同；
• 设置固定随机种子后，部分框架可复现；
• 与底层算子实现无关。

2.2 并发执行与浮点归约非确定性

这类非确定性更隐蔽。它不来自“选哪个 token”的随机，而来自“算出来的数值本身就有微小差异”。典型场景是矩阵乘法或向量归约中，多个线程各自计算局部结果，再按不同顺序合并到全局结果。

关键点在于：IEEE-754 浮点加法不满足结合律，即：

((a + b) + c) ≠ (a + (b + c))

当多个线程以不确定顺序把局部结果累加时，不同的归约顺序会产生不同的舍入误差。温度设零后，argmax 仍然是对 logits 取最大值，但如果两个候选 token 的 logits 非常接近，微小偏差就可能改变 argmax 的结果，从而改变整个生成轨迹。

三、相同点分析：两类非确定性的共同表象

尽管根因不同，两类问题在工程表现上有若干共同点：

维度	采样随机性	并发浮点非确定性
表象	输出不同	输出不同
与温度关系	温度越高越明显	温度设零仍可能存在
可复现性	固定种子可能复现	固定种子通常无法复现
影响范围	全局解码策略	特定算子、特定硬件、特定线程调度
调试难度	较低，参数层面可查	较高，需逐层比对数值

两者都会让“同一输入得到同一输出”的预期落空，但只有后者会在温度设零、采样确定的前提下依然出现。

四、核心差异分析：从架构到调试手段

4.1 技术架构差异

采样随机性位于解码层，属于模型推理的上层策略；并发浮点非确定性位于算子层，属于底层计算实现。前者可以通过设置参数、固定种子、切换解码模式来控制；后者往往需要深入算子内部，检查线程调度、锁顺序、归约顺序。

4.2 触发条件差异

• 采样随机性：温度 > 0，或实现中保留了随机采样路径；
• 并发浮点非确定性：多线程并发执行、原子操作、自旋锁、非固定顺序归约、混合精度累加等。

4.3 传播方式差异

采样随机性在每一步独立引入随机选择，误差不会以数值方式累积；并发浮点非确定性则不同，前面 decode step 的微小偏差会进入后续 step 的输入，被自回归结构逐 step 放大，最终导致 trajectory 越来越不一样。

4.4 调试手段差异

针对采样随机性，常用手段是固定种子、关闭采样、检查解码配置。针对并发浮点非确定性，则需要对每层输出做 hash 并 diff 多次运行结果，逐层定位到具体算子。例如可以抽象为如下伪代码：

for each layer:
    out = run_layer(input)
    hash_out = hash(out)
    compare(hash_out, reference_hash)

当发现某一层 hash 不一致时，再进入该算子内部，检查是否存在原子计数器、自旋锁、非确定顺序的 reduction。

4.5 一个典型的并发归约示例

某类自定义算子在实现矩阵乘法时，采用如下模式：

1. 每个线程通过原子操作从全局计数器领取可用分块；
2. 对分块内每一行计算内积，累加到线程私有缓冲；
3. 再通过加锁进入临界区，把私有缓冲加到全局结果。

由于不同线程领取分块和获取锁的顺序取决于硬件执行顺序，等价于把 N 条局部向量按某个随机顺序做 reduction：

res = 0 + (p[0] + p[1] + (p[2] + p[3])) + ...

浮点加法不满足结合律，不同顺序产生不同舍入误差，最终输出出现偏差。

4.6 验证与修复思路

一个简单的验证方法是：把自旋锁改成按线程编号轮流排队，同时确保领取分块和 reduction 的顺序固定。如果多次运行该算子输出一致，就说明非确定性来自并发归约顺序。

但需要注意，即使该算子修复，最终 response 仍可能变化，因为其他算子或卸载到其他计算设备上的层可能存在类似现象。这类问题通常不被视为严格 bug，对模型最终表现影响有限，但在需要强一致性的场景下必须重视。

五、对比表格：两类非确定性关键差异

对比维度	采样随机性	并发浮点非确定性
所在层级	解码层	算子层
温度设零后	通常消失	可能仍存在
根因	概率采样	线程调度 + 浮点舍入
可复现性	固定种子可复现	通常难以复现
误差传播	每步独立	逐 step 放大
调试方法	参数检查	逐层 hash diff
修复手段	关闭采样	固定归约顺序
影响程度	设计预期内	通常轻微，边界场景需关注

六、典型场景选择：什么时候该关注哪类问题

• 开发测试阶段：如果发现输出不稳定，先检查温度、top-k、top-p、种子等解码参数，排除采样随机性；
• 生产推理服务：如果温度设零后仍不稳定，且服务是多线程、多并发、异构计算的，应重点排查算子层的并发归约；
• 高一致性要求场景：如结果审计、可复现实验、回归测试，需要同时控制解码策略和算子执行顺序；
• 性能优先场景：如果业务对微小数值差异不敏感，可接受一定非确定性，则应优先保证吞吐和延迟。

七、选型建议：如何判断与取舍

1. 先分层排查：先确认解码层是否完全确定，再进入算子层；
2. 固定执行顺序：对关键算子，尽量使用固定顺序的归约，避免依赖原子操作和自旋锁的调度顺序；
3. 权衡性能与确定性：固定顺序可能降低并发效率，需要根据业务对一致性的要求做取舍；
4. 逐层验证：对每层输出做 hash 比对，定位偏差来源；
5. 接受合理边界：如果非确定性不影响业务指标，不必过度工程化。

八、迁移与使用注意事项

如果从“允许非确定性”的方案迁移到“强确定性”方案，需要关注：

• 接口兼容性：固定归约顺序可能改变算子实现，需确认上层接口不变；
• 性能回归：顺序化归约会降低并行度，需做基准测试；
• 硬件差异：不同计算设备的浮点行为可能不同，跨设备一致性需单独验证；
• 运维复杂度：确定性方案通常需要更严格的版本控制和回归测试；
• 成本结构：性能下降可能带来资源成本上升，需要综合评估。

九、总结

温度设零只解决了采样随机性，无法自动消除并发执行与浮点归约带来的非确定性。两类问题在表象上都是“输出不一样”，但根因、调试手段和修复成本差异显著。理解这一对比，有助于在开发、调试和选型中快速定位问题，并在性能与一致性之间做出合理取舍。对于需要强一致性的场景，建议从算子层固定归约顺序并逐层验证；对于一般业务场景，则可接受合理范围内的数值非确定性，优先保障整体效率。