简介：本文深入分析大模型推理中“temperature=0仍输出不一致”的根因，从浮点精度、GPU非确定性算子、计算图优化差异等角度展开，并给出可落地的稳定性提升方案。读者将理解为什么无法做到100%稳定，以及在实践中如何将输出波动降到最低。
很多开发者第一次接触大模型推理时，会形成一个直觉判断：既然 temperature=0 意味着每次选择概率最高的 token，那输出就应该是确定性的，同一个 Prompt 无论跑多少次，结果必然一致。
这个判断在理论层面似乎成立。贪心解码（Greedy Decoding）的逻辑非常清晰——每一步都取概率最大的那个词，没有任何随机采样环节。既然没有随机性，路径自然应该被“锁死”。
但在真实工程环境中，情况远没有这么简单。你可能会观察到：同一个模型、同一个 Prompt、同一个 temperature=0 设置，连续请求十次，偶尔还是会有一两次输出出现细微差别。可能是某个词被替换了，可能是标点发生了变化，甚至可能是后续整段文本都走向了不同的分支。
这不是你的代码写错了，也不是模型服务出了问题。这是一个更深层的、根植于计算底层的问题。
现代神经网络的前向传播，本质上是一系列大规模的矩阵乘法、加法、归一化和激活运算。这些运算在 CPU 或 GPU 上执行时，底层使用的是 IEEE 754 标准定义的浮点数表示。
浮点数的核心特征是：它能表示的数值范围很大，但精度是有限的。以 FP32 为例，它只有 23 位有效尾数位，意味着很多十进制小数无法被精确表示。比如 0.1 在二进制浮点数中是一个无限循环小数，存储时必然发生舍入。
一个拥有数百亿甚至数千亿参数的大模型，从输入层到输出层要经过几十甚至上百层变换。每一次矩阵运算都会引入微小的舍入误差，每一层都在上一层的近似结果上继续做近似计算。这个误差累积的过程，就像一个极其微小的扰动被逐级放大。
考虑一个具体场景。在解码过程中，经过 Softmax 后的概率分布可能是这样的：
两者的差距只有 0.00002%，远小于浮点运算中可能出现的累计误差幅度。当底层计算因任何原因产生了微小扰动，这两个数值就完全可能发生翻转。
一旦翻转，贪心解码就会选中 Token B 而不是 Token A。接下来的每一步解码都基于新的上下文历史，于是整条生成路径出现分叉。这就是为什么 temperature=0 也无法保证绝对稳定——因为“最高概率”这个词本身，在浮点世界里是存在不确定性的。
这个问题在过去几年被各大框架的官方文档反复提及。查阅主流深度学习框架关于“可复现性”的章节，可以看到一个明确的共识：部分 GPU 算子在默认配置下本身就是非确定性的。
具体来说，GPU 上的矩阵乘法通常由高度优化的计算库实现。这些库在设计时，优先考虑的不是“每次结果完全一致”，而是“尽可能快地完成任务”。为了实现速度目标，它们会根据硬件架构特征、矩阵的维度、内存布局等因素，动态选择不同的执行算法。不同的算法意味着不同的计算顺序，也就意味着不同的舍入路径。
此外，GPU 上大量的并行计算依赖于原子操作。当数千个线程同时对同一块内存区域执行累加时，这些累加操作的执行顺序是不确定的。虽然单次累加在数学上是可交换的，但在浮点运算中，(a + b) + c 与 a + (b + c) 的结果可能不同，因为每次加法都可能产生舍入。
除了单个算子的非确定性，另一个容易被忽略的因素是计算图优化。在推理框架中，模型的计算图通常会经过一系列优化变换，比如算子融合、常量折叠、冗余消除等。
算子融合是一个典型的场景：将两个连续的操作（例如矩阵乘法和偏置加法）合并成一个更高效的内核执行。融合后的执行路径和融合前的执行路径，在数学上是等价的，但在浮点计算结果上可能存在细微差异。
问题在于，这些优化决策往往依赖于具体的运行条件——输入的形状、可用显存大小、批次大小、当前硬件负载等。同一个模型在不同批次大小下运行时，优化器可能选择完全不同的融合策略，从而产生不同的输出。
还有一个工程层面的细节值得注意。在某些推理框架的实现中，即使设置了 temperature=0 或 do_sample=False，后续的过滤逻辑仍然可能被触发。
在较早版本的一些主流推理库中，存在这样的行为：关闭采样后，代码依然会应用 top_p 或 top_k 过滤。如果概率最高的 token 恰好被过滤掉了，模型就会在剩余候选中选择概率最高的那一个。这意味着生成结果不仅取决于模型本身的概率分布，还取决于过滤逻辑的实现细节。这类历史问题曾经困扰了不少开发者，排查起来相当费时。
如果模型使用 FP16 或更低精度进行推理，上述不确定性问题会被进一步放大。
FP16 的有效尾数位只有 10 位，舍入误差比 FP32 大几个数量级。在大模型推理中，为了降低显存占用和提升吞吐，使用半精度或量化精度已经成为常见做法。但代价就是：计算结果对底层执行路径的敏感性更高，同一条 Prompt 在不同请求中产生差异的概率也随之增加。
值得注意的是，这并不意味着低精度推理不能用。对于大多数生成任务而言，输出在语义层面的差异微乎其微，用户通常不会感知到区别。但如果你在做评测、复现实验或者构建对输出格式有严格要求的系统，这些细微差异就可能是致命的。
在讨论解决方案之前，有必要先明确一个现实：在大规模分布式推理场景中，追求 100% 的确定性是不切实际的。你可以在单机、固定环境下尽可能减少不确定性，但一旦涉及多机部署、负载均衡、动态扩缩容、硬件异构等生产级因素，完全一致的目标就无法保证了。
所以，更合理的目标不是“完全消除”，而是“工程上可控”。
对于需要本地复现的场景，最基础的操作是固定所有涉及随机性的种子。这包括但不限于：
random 模块示例代码：
import randomimport numpy as npimport torchdef set_seed(seed: int):random.seed(seed)np.random.seed(seed)torch.manual_seed(seed)if torch.cuda.is_available():torch.cuda.manual_seed(seed)torch.cuda.manual_seed_all(seed)
需要注意的是，固定种子只是消除随机数生成器层面的差异。如果模型推理中完全没有采样，种子的影响有限；但某些实现中的 Dropout、噪声注入等环节仍然可能依赖随机数，因此统一固定是必要的习惯。
主流框架通常提供了“确定性模式”的开关。开启后，框架会强制选择那些输出可复现的算子实现，代价是牺牲一部分性能。
import torchtorch.backends.cudnn.deterministic = Truetorch.backends.cudnn.benchmark = False
cudnn.benchmark 关闭后，框架不再根据输入形状动态搜索最快的卷积算法，而是使用确定的默认实现。cudnn.deterministic 开启后，框架只选择那些具有确定行为的算子。
对于某些场景，还可以进一步限制原子操作的执行方式。主流框架的相关文档中通常列出了可配置的选项，建议根据实际模型结构进行测试。
如前所述，优化器的决策依赖于输入形状和批次大小。如果你在推理时保持这些变量不变，优化器每次做出的选择就更有可能保持一致。
具体做法包括：
如果生成结果的稳定性对业务至关重要，那么在设计下游逻辑时，应该避免依赖“逐 token 完全一致”的假设。
一个更健壮的设计思路是：
如果条件允许，在需要最高可复现性的场景中，将推理任务固定在单一 GPU 型号和单一驱动版本上运行。不同架构的 GPU 会触发计算库中不同的执行路径，固定硬件可以消除这部分变量。
最后一个建议是：在技术方案中显式地记录这一限制。如果你的团队有多个成员，或者在交付前需要向客户做技术说明，提前明确“模型输出可能存在细微波动”这一点，可以避免后续大量的沟通成本。
temperature=0 只是消除了“采样”这个显式的随机性来源，但在它之下，还存在着浮点精度、GPU 算子调度、计算图优化、批次大小变化等大量隐式的非确定性因素。这些因素共同决定了：在实际工程中，完全确定性的 LLM 推理是难以达成的目标。
理解这些限制，不是为了否定大模型在生产环境中的可用性。恰恰相反，只有清晰地认识到不确定性的来源和边界，才能设计出更健壮、更可靠的系统。通过固定种子、启用确定性算法、规范输入形状、优化业务逻辑设计等一系列组合手段，你可以将输出波动降到足够低的水平，使其对实际业务的影响变得可控。