🧪 想做一次靠谱的量化 A/B 测试，但苦于不知道怎么搭对照实验？本文以 grug-27b（Qwen3.6-27B 的 token 高效推理模型）仓库中自带的 eval/qat_bench.py 为蓝本，手把手教你用llama.cpp在同一张 GPU 上对比三组 Q4 量化权重：普通 post-training 量化的Q4_K_M对照组、QAT 全程训练的 qatfull，以及混合训练的 blend25，一套脚本跑完五类探针，结论一目了然。

为什么需要量化A/B测试

grug-27b 基于 Qwen3.6-27B（可参考仓库根目录的 config.json 与 model.safetensors.index.json 查看模型结构），大多数用户会以 Q4 精度部署。仓库作者专门发布了 QAT 版本：训练时就"感受"4-bit 舍入误差，因此 Q4 质量优于普通量化。

但"更优"不能只靠嘴说，必须用受控对照实验来证明。qat_bench.py的做法非常值得借鉴：

三组权重使用同一 llama.cpp 构建、同一 GPU、同一批 prompt，只改变量化方式这一个变量——这就是 A/B 测试的核心：控制变量。组名与权重定义见 eval/qat_bench.py#L25-L29。

环境准备：编译带CUDA的llama.cpp推理服务

qat_bench.py的设计是在带有 CUDA 工具链的容器内完成（作者选用 vllm/vllm-openai 镜像），流程是"先编译、再逐组起服务、逐组测试"。你只需要关注两条命令：

# 1. 编译带 CUDA 加速的 llama-server cmake -B build -G Ninja -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=native -DLLAMA_CURL=OFF cmake --build build --target llama-server -j # 2. 启动推理服务（每组权重都这样起） ./build/bin/llama-server -m 你的gguf路径 -ngl 99 -c 65536 --parallel 4 --port 8123

参数说明：-ngl 99让全部层跑在 GPU 上；-c 65536是上下文长度；--parallel 4开启 4 路并发，正好匹配脚本里的 4 线程探针池（见 eval/qat_bench.py#L179）。服务就绪后脚本会轮询http://localhost:8123/health，最多等待 6 分钟（eval/qat_bench.py#L305-L311）。

💡 提示：GPU 显存至少需要装下 27B 的 Q4_K_M 权重（约 16GB+），建议 24GB 起步，与仓库 requirements.txt 描述的 bf16 部署环境（≥60GB 显存的 A100/H100）相比门槛低很多。

一键运行：复现qat_bench对照实验

整个实验的入口就是 eval/qat_bench.py，它会依次执行四步：

1. 装依赖：pip install cmake ninja datasets
2. 编译llama.cpp 的llama-server
3. 循环三组权重：下载 gguf → 起服务 → 跑五类探针 → 停服务
4. 汇总：结果写入 JSON 并打印FINAL汇总

运行方式（先 clone 仓库获得脚本）：

git clone https://gitcode.com/hf_mirrors/ProCreations/grug-27b cd grug-27b && python eval/qat_bench.py

每组测试完成后，脚本会把中间结果上传到 QAT 仓库的results/bench.json（eval/qat_bench.py#L322-L324），即使中途崩溃也会留痕（BENCH_CRASHED），方便排查——这是做长耗时 A/B 测试的好习惯。

五类探针：qat_bench如何量化对比

这套实验最可贵的部分，是覆盖了能力、稳定性、长文生成三个维度共 5 个探针（定义见 eval/qat_bench.py#L176-L282）：

其中循环检测由loop_score实现：检查文本尾部 8/15/30 词短语是否连续重复 3 次以上（eval/qat_bench.py#L142-L155）——这正是大模型量化后最容易出现、也最伤体验的"复读机"问题。

采样参数值得注意：非贪心探针统一用temperature 0.6 / top_p 0.95 / top_k 20，与 generation_config.json 和 README 推荐的推理参数一致；贪心探针则用temperature 0.0 / top_k 1（eval/qat_bench.py#L122-L132）。同参数、同 prompt 模板由render_prompt统一渲染，保证三组"看到"的输入完全一致。

如何解读对照实验结果

跑完后你会得到类似bench.json的三组指标，阅读时建议关注四点：

• 📊能力指标看差距是否显著：mbpp_pass_pct、gsm8k_pass_pct若 QAT 组只领先 1 个百分点以内，大概率是噪声，需要加大样本量复测；
• 📊工具调用看三项分开：agent_valid_pct（格式合法）→agent_match_pct（选对工具）→agent_args_pct（参数符合 schema），三层指标能定位量化到底伤在哪一层；
• 📊稳定性指标看红线：identity_loop_pct与longform_loops越接近 0 越好，这两项往往比 1 分的 benchmark 差距更影响实际体验；
• 📊别忘了 token 花费：mbpp_words_mean、longform_words_mean反映输出冗长度——grug-27b 的主打卖点就是少想废话，量化后若输出暴涨，A/B 结论要打折扣。

这套思路与仓库里另一套 vLLM 全流程评测 eval/eval_harness.py（HumanEval / GSM8K / MATH-500 / 重复压力测试）互为补充：前者管"量化方式对比"，后者管"模型版本对比"。

相关文件清单

🎯小结：量化 A/B 测试的关键不是跑得多快，而是"只变一个变量"——同一构建、同一 GPU、同一 prompt、同一采样参数。照qat_bench.py的三组对照 + 五类探针搭一套，你也能给出"QAT 到底值不值"的硬核答案。