Qwen3.8-27B 量化精度实测：4-bit 与 8-bit 差距悬殊

Reddit 用户 r/sadnessdevil 近日在 r/LocalLLaMA 发布了一组针对 Qwen3.8-27B 不同量化版本的系统性 KL 散度（KLD）对比结果。该模型被定位为编程与 STEM 方向的本地大模型，作者使用 codeparrot/github-code-clean、EleutherAI/proof-pile-2、allenai/peS2o 三类语料各占等比，构成长短两组测试集。所有模型在评测前均反量化到 BF16，并通过同一推理 kernel 运行，以保证对比公平。

测试规模与方法

• 测试数据规模：24 段 8192 token 序列 + 12 段 32768 token 序列，覆盖长上下文场景。
• 评测对象：24 个不同量化版本的 Qwen3.8-27B checkpoint。
• 评估指标：KL 散度（KLD），数值越小代表量化后输出分布与原始模型越接近。
• 公平性处理：所有模型先反量化回 BF16，再走相同 kernel，避免推理路径差异影响结论。

主要发现

4-bit 与 8-bit 差距显著

• 表现最好的 4-bit 量化 KLD 为 0.00835，而表现最差的 8-bit 量化 KLD 仅为 0.00071，两者相差超过一个数量级。
• 作者指出 vLLM 实际上支持 INT5–INT7 权重，但绝大多数用户并不了解这一选项。

4-bit 内部差异极大，不应只看文件大小

• 6 个 checkpoint 均为 group-size 128、量化 400–496 个模块，权重体积都在 11.7–11.8 GiB 之间，但 KLD 从 0.01364 到 0.02976 不等。
• 作者认为校准数据与舍入算法对结果影响很大，因此仅凭文件大小挑选 4-bit 量化版本并不可靠。

group_size 的影响大于选择性 BF16

• 使用 group_size 32 的量化方案普遍优于 group_size 128 + 部分模块保留 BF16 的方案。
• 选择性保留 BF16 只有在 group_size 已经较细的基础上叠加才有意义，但那样文件体积会膨胀到接近 6-bit 模型。

量化损伤集中在上下文起始处

• 在所有 24 个模型上，KLD 在序列前 500 token 显著高于后续位置，这一规律在长序列测试中保持稳定。

部分层量化影响极小

• 对 lm_head、embed_tokens、linear_attn 做量化在该测试中几乎不产生性能影响，可视为安全的低优先级量化目标。

实践建议

• 部署 27B 级别 Qwen3 模型时，若显存允许优先选择 8-bit 而非 4-bit，两者质量差距远大于一般认知。
• 在 4-bit 量化中，应关注具体算法与校准数据，而非仅看量化包体积。
• 若必须使用 4-bit，优先选择 group_size 更小的方案，再考虑是否叠加选择性 BF16。
• 关注长 prompt 起头的生成质量，必要时对前若干 token 做额外校验或重新采样。