Qwen3.8 27B 量化基准测试：4 位与 BF16 相当，1 位失败

概要

Qwen3.8 27B 量化至 4 位（Q4_K_M，17 GB）在 GPQA Diamond、IFBench 和 Terminal‑Bench 2.1 上的表现几乎与完整 BF16 模型一致，可轻松运行在 24 GB GPU 上。低于 4 位的量化会降低性能，其中 1 位（UD‑IQ1_S，6.2 GB）在 GPQA Diamond 上降至随机猜测水平，并在编码任务中失败。

4 位量化表现良好

结论： 4 位 Q4_K_M 量化（17 GB）在 GPQA Diamond、IFBench 和 Terminal‑Bench 2.1 上与 BF16 表现一致，是消费级 GPU 的最佳选择。

完整的 BF16 模型需要约 55 GB VRAM，超出大多数桌面显卡的容量。
Q4_K_M 可在 RTX 4090（24 GB）上运行，同时保留约 64 k tokens 的 KV 缓存。
在 GPQA Diamond 上，BF16、8 位、4 位甚至 2 位的得分在统计上无法区分（Wilson 95 % 置信区间重叠）。只有 2 位 UD‑Q2_K_XL 显示出轻微下降。
IFBench 显示 BF16 与 2 位模型之间无显著差异，尽管上下文窗口限制在约 4 k tokens。
Terminal‑Bench 2.1（89 个代理式编码任务，3 小时超时，xhigh 策略，98 k 上下文）中，BF16 与 Q4_K_M 的成功率完全相同。2 位模型略有下降，但仍与中端商业代理（如 Opus 4.7、Gemini 3.1 Pro）相当。

“17 GB 的 Q4_K_M 在流行的代理式编码基准 Terminal‑Bench 2.1 上与完整模型表现一致。它可运行在 RTX 4090 等 24 GB 显卡上，同时仍保留约 64k tokens 的上下文空间。” – Quesma 博客

为何 4 位有效

量化方法 Q4_K_M（Unsloth v2）比朴素的 4 位方案更好地保留了权重分布。
作者使用了固定的 F16 KV 缓存（每 32 k tokens 约 2.3 GB），因此内存节省完全来自权重压缩。
更高的推理努力（xhigh）可弥补量化引入的微小概率偏移，正如评论者所指出的。

2 位量化可用但较弱

结论： 2 位 UD‑Q2_K_XL（10.7 GB）在大多数基准测试中仍可运行，但性能略有下降。

与 4 位相比，GPQA Diamond 得分略有下降。
IFBench 仍显示无显著下降，表明许多指令遵循任务对 2 位噪声具有容忍性。
在 Terminal‑Bench 2.1 上，成功率下降几个百分点，但仍处于旧版商业代理的范围内。
Token 使用量增加：对于成功完成的任务，2 位模型比 BF16 多输出约 25 % 的 token，而推理轮次数量大致保持不变。

1 位量化彻底崩溃

结论： 1 位 UD‑IQ1_S（6.2 GB）表现严重失败，在 GPQA Diamond 上得分接近随机猜测，编码基准表现也极差。

得分低于随机猜测基线，尤其在高推理努力（xhigh）下，更长的生成导致空答案。
作者的测量结果与 Unsloth 声称的“72 % top‑1 准确率”相矛盾——缺失的 28 % 对任务成功至关重要。
社区报告（如 r/LocalLLaMA）也描述了相同的失败模式，称该模型为“脑损伤量化”。

“尽管 2 位量化在某种程度上可行，但即使是最好的 1 位模型对这些基准也毫无用处。” – Quesma 博客

技术洞察

在预训练稠密模型上进行 1 位量化本质上是不稳定的；若未在大规模数据上进行量化感知训练（QAT），权重表示会崩溃。
一位评论者指出：“在现有预训练模型上进行量化几乎总是会在 1 位时崩溃。”（HN 评论）

基准测试方法

结论： 作者在测试量化前复现了官方 BF16 得分，确保了可靠的基线。

使用的基准：GPQA Diamond（研究生级科学问答）、IFBench（指令遵循）、Terminal‑Bench 2.1（代理式编码）。
推理努力等级：low、medium、xhigh（默认）。更高努力通常提升得分，但也增加 token 消耗。
硬件：NVIDIA L40S（48 GB）、H100（80 GB）、H200（141 GB）。使用了模态 GPU 租赁，全套测试成本约 3 千美元。
模型加载使用 llama.cpp（2026 年 8 月 16 日构建版本），无论权重量化如何，均采用 F16 KV 缓存。
所示置信区间为 Wilson 95 % 区间；HN 上的一条评论指出，这些区间较为保守，与运行间方差无直接关联。

社区观点

结论： 评论者基本确认了研究结果，补充了关于推理努力的细节，并对 KV 缓存量化和 GPU 内存限制提出了疑问。

推理努力很重要： 一位评论者指出，更长的思考时间可以抵消量化噪声，尽管代价是更多 token。
GPU 内存上限： 用户指出，即使 4 位模型在长上下文下仍超过 16 GB 显卡容量；3 位或混合精度方案可填补这一空白。
KV 缓存量化： 有请求希望进行结合模型量化、KV 缓存量化和上下文大小的基准测试，这仍是一个未探索的维度。
硬件实用性： 多条评论指出，许多消费者使用 8‑12 GB GPU，即使 4 位模型也可能因上下文长度过短而无法有效使用。

成本考量

结论： 在云 GPU 上运行全规模基准测试成本高昂；4 位量化虽降低内存和计算成本，但与大型 MoE 模型的 API 定价相比，节省有限。

使用了 Modal GPU 租赁；总支出约 3 000 美元。
参考：DeepSeek V4 Flash 0731（284 B MoE）在 OpenRouter 上每百万输出 token 仅约 0.10 美元，远低于本地运行稠密 27 B 模型的成本。
4 位量化节省的内存（约 38 GB 对比 55 GB）意味着可在单张 RTX 4090 上运行，避免多 GPU 配置。

实用建议

结论： 对于大多数本地工作负载，使用 4 位 Q4_K_M 量化；2 位适用于资源受限场景；完全避免 1 位量化。

选择适合你 GPU 的最高量化级别，同时保留所需 KV 缓存大小以支持你的上下文窗口。
若发现轻微准确率下降，将推理努力设为 xhigh；预期 token 使用量会增加。
监控 KV 缓存内存——即使使用 4 位模型，32 k token 缓存也消耗约 2.3 GB；更长上下文可能需要更大显存的 GPU。
若需在 16 GB 显卡上支持 >64 k token，考虑混合精度或 3 位方案（本基准未涵盖）。
除非在大规模数据集上进行量化感知训练，否则避免 1 位量化，这对大多数用户目前不切实际。

最后思考

Qwen3.8 27B 的量化在4 位以下仍具实用性，在多种任务上提供与 BF16 相当的性能，同时可运行在消费级 GPU 上。性能曲线呈非线性：从 BF16 到 4 位变化极小，2 位略有下降，1 位则彻底崩溃。拥抱量化——尤其是经过精心设计的 Q4_K_M 变体——使本地部署大型语言模型成为可能，而无需牺牲能力。