我们知道，大模型接口参数中，temperatue 是控制温度的，按理说，当temperature = 0时，温度最低，每次都取概率最大的那个，输出应保持一致。但在实际时，这种情况很少发生，每次输出还是不一样，是为什么？
temperature 的作用
模型在生成下一个词时，会计算一个包含所有可能词汇的概率分布（logits）。Temperature 不改变这些原始分数（logits）的相对顺序，而是改变它们被转换成最终选择概率的方式。
其核心公式为：
调整后的概率 = softmax(logits / temperature)
- logits：模型为每个候选词生成的原始分数，可以理解为“模型对该词的置信度”。
- softmax：函数，将分数转换为所有词汇的总和为1的概率分布。
当 T = 0.1 ~ 0.5 将 logits 的差异放大。高分词的相对概率变得更高，低分词的相对概率被进一步压低。
当 ## T = 0.8 ~ 1.2 将 logits 的差异缩小。高分词的概率优势被减弱，低分词的概率被相对提升。
当temperature = 0 时，每次都取概率最高的那个，这样每次输出应该是一致的。
输出不一致的原因
-
浮点数非结合性：
首先我知道，在计算机中，因为浮点数的存储方式，存在精度问题，1 + 0.000001 - 0.000001 <> 1 + (0.000001 - 0.000001). 这种差异虽然很小，在大模型计算中，数以亿次的并行计算，这就让 1 + 0.0001 - 0.0001 <> 1 + (0.0001 - 0.0001) 这种问题经常发生，从而导致输出随机。
在实际环境下，还有其它以下因素：
-
MOE架构批次效应：
MoE模型由多个专家网络组成，Gate机制决定Token路由到哪个专家。在API服务中，多个用户请求打包批处理时，Token竞争专家会受批次构成影响。不同批次可能导致同一Token被路由到不同专家，进而产生不同输出。API用户无法控制批次，因此输出显得随机
-
硬件异构性：
云服务商异构的GPU集群（如H100与A100）在架构、CUDA实现和驱动版本上的差异可能导致计算结果略有不同。此外，超大规模模型（如GPT-4）的分布式推理涉及跨设备通信，数据聚合顺序和通信时延差异也会引入额外的非确定性。
-
Tie-Breaking与API自适应机制：
当两个Token概率几乎相等时，argmax的tie-breaking规则可能因上述因素而不稳定。更重要的是，一些API服务（如OpenAI）在极端情况下可能会自动微调或悄悄提高Temperature，以避免生成卡死或进入重复循环，这种自适应机制进一步削弱了输出的确定性。
解决方案
问题知道了，解决方法也出来了，并行有问题，那就不并行，改成串行。
- 参数修改：temperatue = 0(将模型转换为"贪婪解码"，每次选择概率最高的词), seed= 固定（如10 ,保证可重复性的核心）
- 不用线上模型，改为自己布署模型，解决计算的并行性问题，但会影响性能。
- 不用moe 架构的模型
实际效果
在本地模型 qwen3:32b 基础上测试，设置参数，temperatue = 0, seed= 10,测试10次，每次结果都一致。
