一份完全相同的模型权重,换一个推理后端或换一种量化方案,就能在长文本任务里给出不同的答案。这不是玄学,是Level1Techs论坛最近一篇实测长文给出的确定性结论。作者用Qwen3.6-27BRTX PRO 6000 Blackwell上跑了一组受控实验,发现权重量化成NVFP4之后,处理到大约88000个token时,近一半的下一个token预测和BF16基线不一致。更麻烦的是,NVFP4和AWQ的INT4版本还生成了格式错误的工具调用,写错了Cisco CLI命令。换句话说,"量化模型变笨"不是错觉,它在某个具体的token量级上有一个可复现的阈值,而这个阈值,几句话的短基准测试根本测不出来。

同一份权重,为什么会跑出不同答案

本地部署LLM的生态本来就碎片化。有人混用几代不同的GPU,指令集不一样;有人换着用vLLM、llama.cpp、ollama,内部的attention后端和kernel实现各不相同;还有人图省事随手挑一个量化版本,GGUF、AWQ、GPTQ、FP8、NVFP4混着用。社区里长期流传一句抱怨——"同一个模型,别人跑得挺聪明,我这边跑起来就是笨",但通常被一句"量化损失"打发过去,没人真正拆开看过。

这篇长文做的事情,是把这句笼统的抱怨拆成可测量的实验。作者选了一段约10万token的真实agentic工作流作为测试样本,里面包含多次工具调用,刻意挑了一个不在任何公开基准或训练集里出现过的场景——没人能提前针对它"刷分",量化校准也不可能专门优化过这段内容。每隔32个token采样一次全词表logits,再用FP64精度比较分布差异,同一后端反复跑,输出是逐比特相同的,这排除了随机噪声,证明后面看到的分歧全部来自计算路径本身。

第一组实验只换attention后端,权重和KV缓存全部保持BF16不变。FlashAttention 2、FlashInfer、Triton三种后端,在prompt前几千个token里完全一致,但到后段开始出现成簇的分歧——不是随上下文长度线性递增,而是跟具体内容相关。这已经说明,"同一个模型"这四个字背后,光是硬件选的矩阵乘法kernel不同,就能让输出分道扬镳。

量化的隐藏阈值:88000个token处开始失控

真正的重头戏在KV缓存和权重量化上。作者把KV缓存单独量化成INT8和INT4,权重保持BF16不动:INT8的分歧最终能自己收敛回来,INT4没能收敛,直接导致一次可复现的工具调用失败。这类问题短基准测试测不出来,因为它只在长上下文、多轮工具调用的场景里才会暴露。

  • 风险.短平快的基准跑分和几条测试prompt,根本发现不了长上下文和工具调用场景下的量化失效。

接着是权重量化的横向对比,官方BF16、官方FP8、第三方INT8、NVIDIA的NVFP4、AWQ的W4A16,五个版本同台竞技。

五种量化格式,对同一权重的一致性 官方 BF16(基线) 一致 第三方 INT8 接近基线 官方 FP8 不及INT8 AWQ INT4 工具调用出错 NVFP4 88k token处约五成分歧 横轴长度代表与BF16基线的token一致程度,越短代表分歧越大

结果里最扎眼的两条:一是NVFP4在跑到约88000个token时,和BF16基线的top-token分歧率冲到约五成,NVFP4和AWQ的INT4版本都出现了格式错误的工具调用,写错了CLI命令,FP8和INT8能正确完成同样的调用;二是没有校准数据集的第三方INT8,一致性反而比官方发布的FP8更接近BF16基线。

官方量化不是金标准,基准测试也可能是伪科学

第二条结果值得多说一句。行业里长期有个默认假设——官方发布的量化版本更靠谱,第三方社区量化只是"能用就行"的替代品。这次实验里,情况反过来了。作者没有深究原因,可能是校准数据、量化算法、或者硬件适配的差异,但这个反差本身已经足够打破"官方=最优"的心理定式。

同一个模型的智能程度,取决于你选的推理栈,而不只是取决于权重本身。

模型卡上常见的KLD数字同样值得警惕。作者提醒,一个"低到不可思议"的KLD声称,如果不披露参照checkpoint、评测文本、上下文长度、采样位置、KL方向这些细节,这个数字就没法拿来跟别人比较——方法论和数字本身一样重要,很多人两头都没做对。

这次实验用的vLLM nightly容器镜像里有734个软件包,其中252个是Python包管理的,每一个都可能带着自己的bug和没写进文档的怪癖。这意味着,哪怕两个人用的都是"同一个vLLM",实际走的代码路径也可能完全不同。

这事对谁最有用

对把本地/私有化部署当成生产工具的开发者和运维人员来说,这篇实验给出了一个具体的排查方向:如果模型在长上下文任务里突然"抽风",先别急着换模型,先查KV缓存量化等级和权重量化方案,尤其是需要精确格式的工具调用、CLI自动化这类场景,INT4和NVFP4是目前看到的高风险选项。

  • 结论.量化选型不能只看文件大小和tokens/s,得用真实的长上下文agentic负载测过一遍,再决定用哪个版本。

作者自己也留了余地:这是单一模型、单一硬件组合下的案例研究,不能直接推广成"NVFP4普遍不可靠"。数据全部来自作者本人自测自报,没有第三方复现,外部有效性还有待验证。但它至少证明了一件事——本地LLM"感觉变笨",不是错觉,是可以被量化、被复现、被定位到具体token数量的工程问题。下一步该看的,是vLLM或NVIDIA官方会不会回应这组数据,以及社区会不会真的把"logit保真度测试"变成量化模型发布前的标准动作。