金贝街 AI本地部署不如官方版的元凶找到了：734个依赖包，每一个都可能坑

丸辣！辛辛苦苦本地部署的大模型，怎么就是比官方版更笨？？

即使是同一张显卡，一毛一样的权重，推理软件栈的微小差异就让模型在关键位置输出完全不同的 token，甚至导致工具调用彻底失败。

这种陷阱很容易触发，但很难排查，还以为三体人来智子封锁了呢。

Level1Techs 论坛用户 thr3e 做了一系列实验，用 Qwen3.6-27B 在 RTX PRO 6000 Blackwell 显卡上完成了超过 10 万 token 的全量 logit 捕获测试。

Logits 是为所有候选 token 计算的一组原始分数，再经过采样器（sampler）输出下一个 token。

关键在于 Logits 是纯粹的数学产物，矩阵乘法、注意力计算、激活函数层层叠加后的浮点数结果。如果两套系统跑同一份权重和同一段输入，理论上应该算出完全相同的 logits。

但现实中，浮点运算的精度、累加顺序、硬件指令集的差异，都会让最终数值产生微小偏移。

当这个偏移大到足以改变概率最高的那个 token 时，模型就会表现出差异。

虽然你的本地部署很烂，但别伤心，其他人部署的各有不一样的烂法。

权重不变，换个注意力后端就变傻

一个关键在推理流程中"注意力后端"这个环节。

vLLM 为 Qwen3.6-27B 提供了三种可选的全注意力后端：FlashAttention 2、Flash Inference 和 Triton Attention。

除了切换这一项配置，其余硬件、软件、权重、KV 缓存精度全部保持不变。

实验使用的输入是一段约 10 万 token 的真实工作场景，来自一个包含多次工具调用的 Agent 工作流。

thr3e 特别强调，这段数据不出现在任何公开基准或训练集中，没有人能针对它做过 benchmark 优化或量化校准。

测试方法是每隔 32 个 token 采样一次全词表 logit，事后用 FP64 精度计算 KL 散度和 Top-1 一致性。

结果观察到" Top-1 翻转"现象，也就是切换后端就会选出与基线不同的贪心解码 token。

比如具体追踪一个出错案例，模型执行一个工具调用，目标是 Cisco 路由器上的一个接口 GigabitEthernet0/0/1.201。

FlashAttention 2 搞错了，导致接口变成了 GigabitEthernet0/1/4，随后模型又在两次后续工具调用中执行了错误的命令。

为保持数学可比性，所有后端共享同一份强制 token 历史，翻转只记录"本来会选错"的情况，不让错误传播。

结果前几千个 token，三个后端的输出完全一致。但随着上下文增长，分歧开始出现，而且分布不均匀。

thr3e 同时做了同后端多次运行的重复性对照，仅仅是切换了 vLLM 的一个配置项，同一块 GPU、同一份操作系统和驱动、同一份权重、同一段 prompt，每一个隐藏状态的 logit 在多次运行间都是逐位相同的。

这意味着观察到的分歧完全来自不同 CUDA 核函数在 prefill 阶段执行矩阵乘法和累加时的数值差异。

KV 缓存量化导致智商断崖式下跌

接下来的实验设置成保持权重为 BF16 不动，注意力后端固定为 Triton，仅改变 KV 缓存的量化精度，分别测试 BF16、INT8 和 INT4 三种配置。

结果 INT4 KV 缓存在长上下文中的 Top-1 翻转率急剧攀升，最终导致工具调用无法恢复。INT8 KV 缓存虽然也出现了翻转，但模型最终设法回到了正确轨道。只有 BF16 KV 缓存全程保持稳定。

thr3e 让翻转后的生成自由运行而非拉回基线，观察实际后果。

BF16 正常完成所有调用，INT8 在出错后"最终挣扎着恢复了"，而 INT4 则彻底偏离了，工具调用失败且无法自我纠正。

这个问题专坑那些为了省显存而将 KV 缓存压到 INT4 的本地用户。

在短上下文中你可能感知不到差异，但一旦对话或 agent 工作流拉长到几万 token，累积的数值漂移足以让模型做出致命错误决策。

权重量化横评：英伟达官方 FP4 垫底

最后一组实验将 KV 缓存统一为 BF16，转而比较五种不同的权重量化方案。

参赛选手包括：Qwen 官方 BF16 基线、Qwen 官方 FP8（W8A8）、TheHouseOfTheDude 发布的 INT8（W8A16，无校准数据集的一次性量化）、英伟达官方 NVFP4、以及 cyankiwi 发布的 AWQ INT4（W4A16，使用 STEM 和 Agentic 数据集校准）。

五种方案各自调用不同的 CUDA 核函数完成矩阵运算。BF16 走标准 torch 线性层，FP8 走 CUTLASS 的 FP8 分块缩放核，INT8 和 AWQ 都走 Marlin 核。

NVFP4 则是混合路径，208 个目标走 FlashInfer 的 FP8 缩放核，193 个 MLP 投影走 Marlin 的 NvFp4 核。

在这次测试的 vLLM nightly 版本中，GPU 路径被判定为不支持原生 FP4 运算，NVFP4 实际执行的是通过 Marlin 内核的仅权重 FP4 解压缩，而非真正的 FP4 运算。

结果中最亮眼的是 TheHouseOfTheDude 的 INT8（W8A16），这是一个没有使用任何校准数据集、仅做了通道级对称量化的社区版本，其 Top-1 一致性碾压了 Qwen 官方 FP8 和英伟达官方 NVFP4。

经分析，这归功于 W8A16 保留了 BF16 激活精度，加上该量化排除了 Gated DeltaNet 投影和 lm_head 层。

英伟达 NVFP4 在这组测试汇总表现最差，到 88k 上下文时 Top-1 翻转率逼近 50%，相当于有一半的位置模型会选出不同的 token。

在实际工具调用测试中，NVFP4 和 AWQ W4A16 都未能正确关闭工具调用，并且搞错了 Cisco 命令行语法（执行了" show run "而非正确的" show arp "），而 FP8 和 INT8 均顺利完成。

thr3e 还展示了张量并行的诡异现象。同一份 BF16 权重，TP1 单卡能正确完成工具调用，切到 TP2 双卡反而失败，再切到 TP4 四卡又成功了。

经过进一步调试和 NCCL 通信图捕获，这通常是 NCCL 跨卡归约操作中的数值差异导致的。

734 个依赖包，每一个都可能有坑

thr3e 说他随手下载的 vLLM nightly 容器镜像里包含 734 个软件包，其中 252 个是 Python 的 uv/pip 包。

这 734 个代码库各有各的 bug 和未记录的行为特性，你的特定硬件和模型配置在这座代码山中走出的路径是独一无二的。

这也是为什么 HuggingFace 模型卡上标的极低的 KL 散度数字不能轻信。

除非作者完整披露了参考检查点、完整运行时环境、评估文本、校准数据、上下文长度、采样位置、KL 方向、词表截断方式以及聚合方法，否则那个数字根本无法解读。

thr3e 目前已经完成了不同权重、不同模型（包括 Qwen3.6 vs 3.8 的跨模型对比）、不同 KV 缓存量化、不同张量并行度、不同 NCCL 配置、不同注意力后端、不同显卡（RTX PRO 6000 vs RTX 5090，同属 SM120 架构）等维度的全量 logit 捕获与分叉追踪，正在将测试工具和数据集打包成可分发版本，供其他用户在自己的设备上运行并上报结果。