同一模型为何本地更“笨”？推理栈的数值差异才是关键

导语

为什么同一份模型权重，放在本地运行却像“降智”了？一项由Level1Techs论坛用户 thr3e 发起的实验，给出了一个更具体的答案：问题可能不在权重，而在推理软件栈。实验使用Qwen3.6-27B和RTX PRO 6000 Blackwell显卡，对超过10万Token的真实Agent工作流进行全量logit捕获，比较不同注意力后端、KV缓存精度、权重量化方案和张量并行配置。

Logit是模型为每个候选Token计算的原始分数。理论上，相同权重和输入应产生相同结果，但浮点精度、累加顺序、CUDA核函数以及跨卡归约方式的细微差异，都可能让排名靠近的Token发生翻转。短文本中，这种变化往往不易察觉；长上下文里，偏差可能逐渐累积，并改变后续决策。

核心要点

• 注意力后端会改变输出。 在其他条件不变时，FlashAttention 2、Flash Inference和Triton Attention在测试前几千个Token上基本一致，但随着上下文增长，开始出现Top-1选择分歧。一个工具调用案例中，接口名称被生成错误，随后又引发连续的错误命令。
• KV缓存压缩存在长上下文风险。 BF16缓存保持稳定；INT8出现翻转但在案例中仍能恢复；INT4的分歧明显增加，并最终导致工具调用无法自我纠正。省下的显存，可能换来Agent轨迹的不稳定。
• 量化格式不能只看名义精度。 测试中，一种社区INT8 W8A16方案的Top-1一致性优于官方FP8和NVFP4方案。分析认为，保留BF16激活并避开部分敏感层，可能比单纯追求更低位宽更重要。该结果并不意味着某种量化方案在所有模型和硬件上都更好。
• 多卡也可能带来差异。 同一份BF16权重在TP1、TP2和TP4配置下表现并不一致，实验将其与NCCL跨卡归约的数值差异联系起来。

意义与影响

这项实验提醒开发者：模型权重只是推理结果的一环。一个容器中可能包含大量Python、CUDA、通信库和编译组件，它们共同决定了实际执行路径。模型卡上单独报告的KL散度或一致性数字，如果没有说明参考检查点、运行时环境、上下文长度、采样位置、校准数据和统计方法，就很难直接用于比较。

对普通用户而言，不必因此放弃量化或本地部署，但应避免只用短问答判断模型质量。对工具调用、代码执行和长上下文Agent，更可靠的做法是固定版本与配置，记录注意力后端、KV精度、量化实现、并行度和驱动环境，并在自己的任务集上做logit或行为回归测试。未来，本地模型评测或许不仅要评估“模型是什么”，还要评估“模型在什么推理栈上运行”。

来源：量子位