量化真的无损吗？Qwen3.6-35B-A3B-Quark-UINT4-G32-GGUF完整评测报告：PPL、GSM8K与OLLv2六项任务全解

• 人工智能
• 大模型
• 模型量化
• 本地部署
• 模型评测
• Qwen

大模型量化真的"无损"吗？🤔 这篇文章基于Qwen3.6-35B-A3B-Quark-UINT4-G32-GGUF的实测数据，用 PPL 困惑度、GSM8K 数学基准和 Open LLM Leaderboard v2（OLLv2）六项任务，带你完整看懂这款 Q4_1 量化 GGUF 模型到底损失了多少精度——结论可能会让你意外。

一、量化方案速览：这个模型是怎么来的？

在跑评测之前，先花 1 分钟了解这个量化模型的身世，这决定了后面所有数据的解读方式。

💡 注意两点细节：

1. 不是所有层都量化了——门控（gate）、共享专家等"敏感小模块"被特意保留为 FP16，这是控制精度损失的关键设计；
2. 导出路径经过优化——160 个张量直接从 Quark 原生打包进 Q4_1，另有部分张量（如linear_attn）需要先反量化再重排 V-head 后重新量化，这个"重排修复"对最终精度影响巨大（后文 PPL 部分会看到）。

完整的方案说明见 README.md，量化复现入口在 scripts/quantize_q4_1.py，其中PERF_EXCLUDE列表定义了哪些层不量化。

二、如何下载与快速上手推理

git clone https://gitcode.com/hf_mirrors/amd/Qwen3.6-35B-A3B-Quark-UINT4-G32-GGUF

仓库内 GGUF 模型位于gguf-q4_1/目录（3 个分片，单片约 7 GB），使用 llama.cpp 的 ROCm（build-hip）版本即可加载。实测数据：

• 单机冒烟测试：llama-cli加载成功，生成速度约45 tok/s
• GSM8K 评测全程：约33.1 tok/s（completion 吞吐），0.262 题/秒

也就是说，这套 Q4_1 量化 GGUF 在消费级 ROCm 硬件上就能跑出流畅的推理速度，这正是量化模型的核心价值之一。

三、评测一：PPL 困惑度测试——量化丢了多少精度？

困惑度（Perplexity，简称 PPL）是衡量语言模型"预测下一个 token 能力"的经典指标，数值越低越好。三项测试统一使用 llama.cpp 的llama-perplexity，在 wikitext-2 测试集上以相同参数（n_ctx=512、20 个 chunks）运行，完全可比。

📊 两个关键结论：

• Q4_1 相比浮点基线仅上升 1.8%，而体积压缩到约 30%，属于"接近无损"的量化；
• Q4_1 略优于 Q4_0——uint4_wo_32是非对称（仿射）量化，每个 32 权重组带独立的缩放因子，对分布不居中的权重更友好。

⚠️ 还有一个值得新手记住的"翻车"故事：在修复linear_attn的 V-head 重排问题之前，Q4_0 的 PPL 高达2,619,116（模型基本完全坏掉）；修复后降到 6.79。这说明：量化模型的异常表现，往往不是量化本身的问题，而是导出/打包环节出了错。

该部分数据详见 README.md 的 Perplexity 小节。

四、评测二：GSM8K 数学基准——真实任务表现如何？

GSM8K 是小学数学应用题基准（test 集 1319 题）。本次评测采用gsm8k_nothink对齐协议（对齐 lm-eval 标准），关键配置：

• 5-shot少样本提示，temperature=0，max_tokens=256
• 提示词注入空的think块抑制 Qwen3.6 默认的思考输出
• 用 lm-eval 的flexible-extract/strict-match两种规则判分

✅ 91%+ 的分数对一个 4bit 量化模型来说相当扎实。

更有意思的是"协议对比"：旧版未对齐的评测脚本（普通Answer:补全 + 取最后一个数字判分）只跑出70.66%。同样的模型，分数差了 21 个百分点——评测协议（提示词、判分规则）对结果的影响甚至可能超过量化本身。想复现的话，直接运行 scripts/run_gsm8k_nothink.sh，判分规则定义在 scripts/gsm8k_nothink.yaml：

# 完整评测（1319 题） ./scripts/run_gsm8k_nothink.sh # 快速冒烟测试（10 题） NUM_QUESTIONS=10 ./scripts/run_gsm8k_nothink.sh

五、评测三：OLLv2 六项任务——综合能力全面体检

Open LLM Leaderboard v2 包含 6 个任务，分两类判分方式，这也是本仓库最有技术含量的一处工作：

• 生成式任务（generate_until）：IFEval、MATH-hard。模型自由生成文本后与规则/参考答案匹配，任何能生成的后端都能测；
• 选择题任务（loglikelihood）：BBH、GPQA、MMLU-Pro、MuSR。需要把每个候选答案拼接到题干后，计算输入 token 的 logprob并取最高分。原版llama-server只返回生成 token 的 logprob，导致四个选择题任务最初无法在 GGUF 上评分——后来通过给llama-server打补丁（支持 prompt token 的 logprob 输出）彻底解决，6 项任务全部直接在 GGUF 文件上完成测量，无需 vLLM/safetensors 替代。

📌 如何解读这张表：

• 生成式任务（IFEval、MATH-hard）与 BF16 基线基本持平甚至略高（IFEval 超出约 2.8 个百分点，属正常波动范围）；
• 选择题任务略低于 BF16，差距普遍在 1~7 个百分点内，其中 GPQA 差值最大（约 3.2 个百分点），这是量化 + 后端差异的综合影响；
• 整体表现紧密跟随 BF16 基线，说明量化导出是忠实的，没有"偷偷"损伤能力。

测试细节与参考列说明见 README.md 的 OLLv2 小节。

六、结论：量化真的无损吗？

综合三组数据，给新手一个可以直接带走的答案：

1. 数学上不是无损：Q4_1 的 PPL 比 F16 高 1.8%，选择题任务有轻微下降，这些都是量化固有的信息损失；
2. 实用意义上"接近无损"：体积从 71 GB 压到约 21 GB（-70%），GSM8K 仍保持 91%+，OLLv2 六项任务紧贴基线，日常推理体验几乎无感——这是量化最理想的落点；
3. Q4_1 > Q4_0：同样 21 GB，非对称 uint4（仿射）方案 PPL 更低，同等显存预算下优先选仿射量化；
4. 警惕导出陷阱：本项目的linear_attn重排修复让 PPL 从 260 万回到 6.79，说明"量化后模型变笨"要先排查导出/打包正确性，再下结论。

🎯 一句话总结：4bit 量化不是魔法，但 1.8% 的 PPL 代价换来 70% 的体积缩减，这笔账非常划算。

延伸阅读与参考文件

想深入了解某项评测的原始配置，直接点开上表对应文件即可，所有参数（few-shot 数、判分正则、停止符等）都白纸黑字写在里面，可自行复现。

• 人工智能
• 大模型
• 模型量化
• 本地部署
• 模型评测
• Qwen