Qwen3.8-Flash-Next-NVFP4 的 NVFP4 量化是怎么做的？W4A4 双级缩放机制与为什么只量化专家路由

Qwen3.8-Flash-Next-NVFP4 是一个用NVFP4 量化（W4A4、双级缩放）处理过的开源大模型检查点。它把约 180B 参数、360 GB 的 BF16 源模型，压缩到 135 GB（约 2.7 倍瘦身），同时把精度稳稳留在 BF16 参考区间内。本文带你用"新手友好"的方式，拆解三件事：NVFP4 量化具体动了哪些权重、W4A4 的双级缩放到底怎么工作，以及为什么只量化 MoE 的 routed experts（专家路由）。

一句话结论：这是一次"外科手术式"量化——只切掉体积最大的专家权重，其余关键部分逐字节保留原样，并用真实激活做校准，最后用多层审计证明"没搞坏"。

📦 先看结果：360 GB 怎么变成 135 GB

在深入细节前，先看这张"前后对比"表，心里有个底：

模型本体是一个混合架构多模态 MoE：48 个 decoder 层，每层 512 个 routed experts（top-10 路由）+ 1 个 shared expert，外加 1 层 MTP（multi-token prediction）。完整介绍见 README.md。

🎯 第一步：NVFP4 量化到底"动了谁"

量化最怕"一锅端"把不该动的也动坏。这个检查点用了一份显式的排除清单（ignore / exclude_modules），把"不动的部分"白纸黑字写进了 hf_quant_config.json 和 config.json。

✅ 被量化成 NVFP4 的（唯一的"主角"）：

• 48 个主模型 MoE 层的routed experts，即融合后的gate_up_proj/down_proj，共294,912 个量化张量条目。

🛡️ 保持 BF16、逐字节与源一致的（配角，一个都不动）：

• 注意力（self_attn/linear_attn，含 GDN 线性注意力）
• 稀疏注意力 QSA、多流 mHC（hyper_connection）
• shared expert（共享专家）与 router（mlp.gate、shared_expert_gate）
• 词嵌入embed_tokens、输出头lm_head
• 视觉塔model.visual、PLE n-gram 相关（部分）
• 全部 31 个 MTP 张量

🟡 特殊处理（取中间值）：

• PLE n-gram 嵌入表：直接采用上游Qwen/Qwen3.8-Flash-Next-FP8的FP8（F8_E4M3）版本，128 个分片 + 每表一个标量 scale，加载时反量化回 BF16。

这份排除清单就是"只量化专家路由"这句话的落地配置：*.mlp.gate*、*.mlp.shared_expert.*、*.self_attn.*、*.linear_attn.*、*hyper_connection*、*.ple.*、lm_head、mtp.*等全部被ignore掉。

🔬 核心：W4A4 双级缩放机制拆解

"W4A4" 指权重 4-bit（W4）+ 激活 4-bit（A4），两者都用 NVFP4 数值格式（E2M1）。而"双级缩放"是 NVFP4 的精髓：一个数值不是一刀切地缩放，而是分两级、粗细搭配地缩放。

分片元数据 layer-00000-experts-0000-0127.complete.json 里的quantization_recipe把这套配置写得很清楚（num_bits: [2,1]、block_sizes: {"-1": 16, "scale_bits": [4,3], "type": "dynamic"}、effective_bits: 4.5）。

第 1 级：微缩放（block scale）——每 16 个元素一个 FP8

• 把张量沿最后一维每16 个元素切成一组；
• 每组共享一个 FP8（E4M3）块缩放因子（scale_bits [4,3]= 4 位指数 + 3 位尾数）；
• 组内每个元素则用4-bit 的 E2M1（FP4）表示。

作用：4-bit 数值动态范围极小，靠"每组一个更精细的缩放"去贴合局部幅度，避免大数值溢出、小数值被抹平。

第 2 级：全局缩放（global scale）——每个张量一个 FP32

• 在整个张量层面，再放一个 FP32 全局缩放因子，把整体分布"搬"进 FP4 能稳定表示的区间；
• 审计报告显示全部221,184 个缩放因子都是有限正数，最小约2.13e-05、最大448.0，见 validate_scales_report.json。

为什么叫 "4.5 bit"？

这就是"双级"的代价账：

每 16 个元素：16 × 4-bit 数据 = 64 bit，再加 1 个 8-bit(FP8) 块 scale 平均 = (64 + 8) / 16 = 4.5 bit / 元素

所以effective_bits: 4.5。比纯 4-bit 多一点点开销，换来的是精度上对 BF16 几乎无损。

A4 这一端：动态激活

• 权重是静态量化（离线算好，存盘）；
• 激活是动态量化（type: dynamic）——推理时把输入激活按同样的"16 一组 + scale"规则现算现压到 FP4。

校准（calibration）用的是真实激活，而不是拍脑袋：取cnn_dailymail训练集 128 篇（seed 1234、截断到 512 token），从线上 SGLang 推理服务的 prefill 阶段钩住每个 MoE block 的输入，逐层采集62,139 行/层激活，再对每个分片跑 8 个带种子的采样 batch 取 max 校准。详见各分片的calibration_contract与 qualification-notes.md。

🧠 为什么"只量化专家路由"？

这是全篇最值得琢磨的设计决策。一句话：挑"体积最大、又最耐压缩"的部分下手，其余的要么太小、要么太娇气。

1. 收益最大——专家是体积大头。每层 512 个 routed experts、48 层，融合gate_up_proj/down_proj后就是那 294,912 个条目，占了模型内存的绝对主力。把它压掉，整体瘦身立竿见影。

2. 专家是"稀疏使用"的，天然耐压缩。每个 token 只激活10/512个专家（top-10 路由）。单个专家的权重对某条 token 的影响被路由"摊薄"了，量化误差对最终输出的冲击小——这是敢下 FP4 的底气。

3. router（门控）又小又关键，保 BF16。router 负责决定"选哪 10 个专家"，一旦出错会带偏整条计算路径。它体量极小，不值得、也不该拿它冒险。

4. shared expert 每 token 都过，保高精度。共享专家不像 routed experts 那样稀疏，它对每个 token 都生效，属于"热路径"，所以留在 BF16。

5. 注意力 / 嵌入 / 输出头 / 视觉塔 / MTP 都精度敏感，全部不动。线性注意力（GDN）与全注意力、词嵌入、lm_head、视觉塔，以及服务于投机解码的 31 个 MTP 张量，统统逐字节保留，把风险隔离在"只影响专家"的范围里。

这种"只切专家"的策略，配合下面的字节级审计，能做到：压缩收益最大、回归风险最小。

✅ 证据链：怎么确认"没搞坏"

发布前跑了一整套"体检"，全部通过：

• 结构审计：294,912 routed + 1,562 个未改动 + 31 个 MTP 张量，dtype 分布为 73,728×U8、73,856×FP8、147,456×FP32、1,432×BF16、3×I64（见 validate_checkpoint_report.json）。
• 缩放因子审计：221,184 个 scale 全部有限为正，min2.13e-05/ max448.0（validate_scales_report.json）。
• 未改动内容字节级一致：1,562 个张量、118.4 GB逐字节比对源模型，含 31 个 MTP 张量，全部pass（audit_unchanged_report.json）——直接证明"没动的部分真的一点没动"。
• 确定性服务冒烟：真实推理返回正常、finish_reason=stop、logprobs 全部有限（smoke_report.json）。

环境可复现性也留档了：nvidia-modelopt v0.46.0、固定 commit、CUDA 13.0、PyTorch 2.13.0+cu130，见 conversion_environment.json。

🚀 怎么跑起来（SGLang）

需要支持qwen4_exp的 SGLang 构建 +Blackwell（GB300 / B300），关键参数是--quantization modelopt_fp4和--fp4-gemm-backend flashinfer_cutlass：

python -m sglang.launch_server \ --model-path RadixArk/Qwen3.8-Flash-Next-NVFP4 \ --tp 2 \ --quantization modelopt_fp4 \ --fp4-gemm-backend flashinfer_cutlass \ --page-size 64 \ --mamba-scheduler-strategy extra_buffer \ --mamba-track-interval 64 \ --chunked-prefill-size 4096 \ --max-running-requests 36 \ --context-length 262144 \ --mem-fraction-static 0.80 \ --allow-auto-truncate \ --port 30000

⚠️ 加载侧注意：PLE 的 FP8 表必须用其weight_scale做带 scale 的反量化，不能只把 FP8 字节往上抬精度，否则 PLE 嵌入会"静默出错"。

📊 量化后精度掉多少？

实测落在 BF16 参考区间内，单轮任务基本无损：

原始数据见 gsm8k_metrics.json 与 aime26_metrics.json。

行为提示：单轮精度（GSM8K / AIME）保持在区间内；但长程 agentic 生成倾向比 BF16 跑得更长，这是使用时的主要体感差异。

小结

• 怎么做的：NVIDIA Model Optimizer 的 NVFP4 配方，只切 48 层 MoE 的 routed experts，其余逐字节保留。
• W4A4 双级缩放：16 元素一组的FP8 块 scale（第 1 级）+ 每张量一个FP32 全局 scale（第 2 级），平均 4.5 bit，激活走动态量化。
• 为什么只量化专家路由：专家是体积大头且稀疏使用，最耐压缩；router/共享专家/注意力/MTP 要么太小、要么太娇气，保 BF16 隔离风险。
• 可信度：字节级一致审计 + 缩放审计 + 冒烟测试全过，精度稳定落在 BF16 参考带内。