企业官网建设流程全解析

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

本文将带你用lm-evaluation-harness验证Instella-MoE-16B-A3B-SFT-w8a8-llmcompressor的量化质量。这是 AMD 用 LLM Compressor（compressed-tensors）对 Instella-MoE-16B-A3B-SFT 做 W8A8（8-bit 权重 + 8-bit 动态激活）量化后的模型，面向 AMD EPYC CPU 推理，通过复现 GSM8K 5-shot 评测，即可判断这次量化是否"保住了精度"。

为什么要先验证量化质量？

量化模型最怕的不是"跑不起来"，而是"跑起来但变笨了"。💡

这个 checkpoint 有个很特别的设计取向：

• 体积只减了约 3%：从 29.6 GiB 降到 28.7 GiB
• 收益在算力不在容量：每层的 64 个 routed experts 保持 BF16（vLLM 的 CPU 路径没有 INT8 MoE 后端），INT8 主要加速的是注意力和稠密 MLP 的矩阵乘法
• 精度风险集中在被量化的部分：MLA gated attention、layer-0 稠密 MLP、两个 shared experts

所以验证思路很直接：用和官方相同的 GSM8K（5-shot）基准，对比 BF16 基线。官方评测结果如下：

✅ 恢复率 ≈ 100% 以上，说明量化没有造成可感知的精度损失。下面就来复现这个结论。

三分钟看懂 W8A8 量化方案

先看 recipe.yaml，整个量化配方其实只有几行：

• 量化目标：所有Linear层，方案为 W8A8（权重 INT8 对称逐通道静态，激活 INT8 对称逐 token 动态）
• 跳过名单（ignore）：

ignore: [lm_head, 're:.*lm_head', 're:.*mlp\.gate$', 're:.*mlp\.experts\.']

这里有两个容易踩坑的细节，值得新手理解：

1. 路由器的正则锚点是mlp\.gate$：MoE 路由模块叫mlp.gate，而不是mlp.gate_proj（那是 SwiGLU 专家的权重）。路由器参数量极小、但对路由结果极其敏感——路由分错专家，损失远大于 8-bit 权重带来的损失，所以必须跳过
2. routed experts 用mlp\.experts\.（末尾带点）匹配：这样shared_experts不会被误伤，shared experts 仍可量化

被保留在 BF16 的还有lm_head、embed_tokens和所有 layer norms。这些配置同样记录在 config.json 的quantization_config字段中，format: "int-quantized"一眼就能确认量化格式。

💡 W8A8 用的是 RTN（Round-to-Nearest）算法，属于data-free 量化——不需要校准数据集，这也是 recipe 中requires_calibration_data: false的原因。

三步复现 GSM8K 评测

第一步：准备 AMD CPU 环境

该模型对版本有严格要求（版本锁）：

torch==2.13.0 zentorch==2.13.0 vllm==0.28.0 llmcompressor==0.13.0

运行前还需要设置 OpenMP 环境变量，且必须在启动 vLLM 之前设置：

# LLVM OpenMP export LD_PRELOAD=$(find /path/to/env -name "libomp.so" | head -1)

另外注意：该 checkpoint 自带 Instella 的自定义建模代码（modeling_instella_moe.py），加载时必须开启trust_remote_code。

第二步：执行 lm-evaluation-harness 评测命令

完整的官方评测命令如下（来自 README.md 的 Evaluation 一节）：

lm_eval \ --model vllm \ --model_args pretrained=amd/Instella-MoE-16B-A3B-SFT-w8a8-llmcompressor,dtype=bfloat16 \ --tasks gsm8k \ --batch_size auto \ --trust_remote_code \ --num_fewshot 5 \ --apply_chat_template \ --log_samples \ --gen_kwargs "max_gen_toks=2048" \ --output_path .

关键参数速览：

第三步：对比 BF16 基线，判断恢复率

拿到结果后，用官方口径计算：

恢复率 = W8A8 得分 ÷ BF16 基线得分

判读标准：

• ≈ 100%（如官方的 102.03%）：量化质量合格，精度无损
• 略低于 100%（差 1~2 个点内）：可接受，属常见波动范围
• 明显下降（超过 5 个点）：需要回头检查 ignore 名单是否漏配，是否误量化了mlp.gate、lm_head等敏感模块

常见疑问

问：W8A8 分数（0.8324）为什么反而比 BF16（0.8158）高？

GSM8K 是开放式生成任务，单次运行分数本身存在波动。恢复率略高于 100% 的准确解读是"没有可感知的精度损失"，而不是量化让模型变强了。

问：为什么体积只省 3% 还要做量化？

因为收益是计算加速而非显存/内存节省——routed experts 占了 26.8 GiB 的大头且保持 BF16。对 AMD EPYC CPU 推理场景，INT8 的注意力和稠密 MLP 矩阵乘法更快，这才是这个 checkpoint 的主要价值。

问：想自己复现量化过程，看哪些文件？

• 量化配方：recipe.yaml
• 量化配置详情：config.json
• 权重分布：model.safetensors.index.json

总结

📌 验证量化质量的完整流程其实只有三步：

1. 读懂量化配方：确认哪些层被量化、哪些层（router、lm_head、routed experts）被刻意保留
2. 用 lm-evaluation-harness 跑 GSM8K 5-shot：与官方保持相同参数
3. 对比 BF16 基线：Instella-MoE-16B-A3B-SFT-w8a8-llmcompressor 的 GSM8K 得分为 0.8324，恢复率 102.03%，量化质量达标 ✅

最后提醒：该模型仅面向 AMD EPYC CPU 推理，且绑定 ZenDNN v6.1.0 / ZenTorch v2.13.0 / PyTorch v2.13.0 版本栈，其他版本可能无法正确加载。

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