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

Instella-MoE-16B-A3B-SFT-w8a8-llmcompressor 是面向 CPU 推理的 MoE 大模型 W8A8 量化检查点，由 AMD 使用 LLM Compressor 生成。本文讲解 MoE 模型量化中的关键取舍：为什么每层 64 个路由专家（routed experts）和 Router 都保留在 BF16，而不是压缩成 INT8，以及这一决定如何影响模型体积与推理性能。

📦 量化检查点一览

AMD 基于 BF16 原版模型，用 RTN（Round-to-Nearest，无需校准数据）算法做了一次量化，磁盘占用从29.6 GiB 降到 28.7 GiB，整体只压缩了约3%。

💡 3% 的压缩率看起来很小，但官方明说这是刻意设计（by design）——这个检查点的目标是「算得更快」，而不是「存得更小」。

量化参数直接写在 config.json 的quantization_config中：激活采用strategy: token的动态量化，权重采用strategy: channel的静态量化。

🔍 到底哪些模块被量化了？

在 model.safetensors.index.json 中搜索weight_scale（每个 INT8 张量都会多一个 scale 张量），就能看清量化范围：

这份「排除名单」由 recipe.yaml 中的targets: [Linear]加ignore正则列表决定。

⚡ 64 个路由专家为何留在 BF16：CPU 上没有 INT8 MoE 后端

先算一笔账：路由专家占到了全部 28.7 GiB 中的26.8 GiB，是模型体积的绝对大头。如果它们能被量化，体积几乎可以砍半。

但现实是：vLLM 的 CPU 推理路径没有 INT8 MoE 后端。换句话说，就算把专家权重压成 INT8，也没有对应的内核能高效执行 INT8 MoE 矩阵乘，量化等于白做。

于是取舍就清晰了（见 README.md）：

INT8 在这里买到的是注意力和 dense-MLP 矩阵乘的更快计算，而不是更小的内存占用。收益是 compute，不是 capacity。

模型内存占用因此与 BF16 版接近，但每步推理中高频执行的大矩阵乘（注意力投影、共享专家 FFN）跑在更高效的 INT8 路径上。

🧭 Router 为何留在 BF16：体积小，且路由错误代价极高

Router 模块mlp.gate是一个DeepseekV3TopkRouter（本质是一个nn.Linear），任务是从 64 个专家中为每个 token 挑出 Top-6。它保留 BF16 有两层原因：

1. 它太小了：单个小线性层，量化后省下的空间可以忽略不计；
2. 路由是离散决策，对数值误差极度敏感：INT8 引入的微小数值扰动可能让 Top-K 的排序发生翻转——token 被送进错误的专家，造成的精度损失远大于 8-bit 矩阵乘本身的舍入误差。

一句话总结：「开关」不量化，只量化「管道」。同理，embed_tokens、lm_head和各层 LayerNorm 也遵循量化领域的通行惯例保留 BF16。Router 的初始化逻辑可参见 modeling_instella_moe.py。

🎯 两条正则表达式：排除名单的精髓

recipe.yaml 的ignore列表只有 4 条规则，但每一条都「精准到字符」：

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

细节一：re:.*mlp\.gate$的结尾锚点。这个模型里 Router 模块名叫mlp.gate，而 SwiGLU 专家和 dense FFN 的门控投影叫mlp.gate_proj。如果正则不带结尾锚点$，会连专家的gate_proj一起误伤，把本该量化的模块也排除掉。

细节二：re:.*mlp\.experts\.的末尾点号。带尾随点号的experts.只会匹配mlp.experts.0.xxx这类路由专家权重，而不会匹配mlp.shared_experts——这样两个共享专家就能正常被量化。一个点的差别，决定了 26 层共享专家（INT8）与 26×64 个路由专家（BF16）的分野。

完整的逐层排除清单固化在 config.json 的ignore字段中，加载时由量化配置自动生效。

📊 效果如何？基准数字说话

用 lm-evaluation-harness + vLLM 对 GSM8K（5-shot）做了对比（README.md）：

精度基本无损甚至略有波动，说明「只量化计算密集模块、保护路由链路」的策略是稳妥的。

⚠️ 使用限制

• 版本锁定：仅兼容 ZenDNN v6.1.0 / ZenTorch v2.13.0 / PyTorch v2.13.0 / vLLM v0.28.0，其他版本可能无法加载；
• CPU Only：面向 AMD EPYC 优化，不用于 GPU 推理；
• 路由专家未量化：内存占用接近 BF16 版，收益是速度而非容量；
• 自定义建模代码：检查点自带 Instella 的 modeling 文件，加载需trust_remote_code=True。

📌 从这个检查点学到的 MoE 量化取舍清单

1. 先问推理引擎有没有对应内核：没有 INT8 MoE 后端，量化专家就是无效劳动；
2. 量化大且连续的矩阵乘模块：注意力投影、共享专家、dense FFN 是最佳标的；
3. 离散决策模块绝不量化：Router 的 Top-K 选择、LayerNorm、词表头，微小误差会被放大成路由错误；
4. 忽略正则要精准到字符：结尾锚点$与尾随点号.直接决定「刀」砍向谁；
5. 小压缩 ≠ 失败：在 CPU 场景下，W8A8 即便只省下 3% 空间，也换来了注意力与 dense-MLP 的计算加速。

这套「选择性量化 + 精准正则排除」的做法，是 MoE 模型在硬件后端不全时非常实用的工程范式，也适用于其他 CPU 推理场景下的量化方案设计。

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