Model-Optimizer 实战：用量化感知蒸馏（QAD）恢复 Qwen3.6-35B-A3B 的 W4A4 NVFP4 精度-平芜编程栈

【免费下载链接】Model-Optimizer

A unified library of SOTA model optimization techniques like quantization, distillation, pruning, neural architecture search, speculative decoding, etc. It compresses deep learning models for downstream deployment frameworks like TensorRT-LLM, TensorRT, vLLM, etc. to optimize inference speed.

项目地址：https://gitcode.com/GitHub_Trending/te/Model-Optimizer

点击查看免费下载

本篇技术指南基于 Model-Optimizer 仓库中发布的 Qwen3.6-35B-A3B W4A4 NVFP4 量化与量化感知蒸馏（Quantization-Aware Distillation，QAD）完整研究记录，系统讲解为什么权重仅量化的 W4A16 NVFP4 在 Blackwell 上反而比 BF16 更慢、W4A4 如何解锁 FP4 张量核心并带来最高 1.30x 的吞吐提升，以及 500 次 QAD 迭代如何把 PTQ 丢失的精度恢复到与 BF16 统计等价。读者将掌握完整的端到端复现链路：token 预算数据混合 → Megatron-Core W4A4 NVFP4 PTQ → QAD 蒸馏 → HuggingFace 统一导出 → NeMo Evaluator 六项基准评测 → vLLM 吞吐压测。

为什么目标是 W4A4 而不是 W4A16

公告（docs/source/announcements/qwen36-w4a4-qad.rst）给出了一个反直觉的起点：纯权重量化 NVFP4 并不会让这个模型变快。在 Blackwell 上，BF16 激活会迫使 vLLM 落入 Marlin 的 dequant-to-BF16 回退路径，永远无法触及 FP4 张量核心——实测中 W4A16 在 12 种形状里有 10 种比 BF16 更慢。只有把激活也量化为 4-bit（W4A4），才能解锁这些内核，并在 12 种形状中的 9 种里击败 BF16。但代价是 PTQ 单独无法恢复的精度损失，这正是 QAD 存在的理由。

从仓库源码可以验证这一设计动机。Megatron-Core 的 W4A4 配方 w4a4_nvfp4-fp8_attn-kv_fp8_cast_mcore.yaml 的文件头注释明确写道："W4A4 rather than W4A16 because a BF16 activation forces vLLM onto the Marlin dequant fallback, which measured 0.64-0.86x BF16 throughput; only FP4 activations reach the Blackwell FP4 tensor cores"，并且lm_head被纳入 W4A4 量化是因为它占了每 token 权重流量的 34.6%。

该研究的实验对象是 Qwen/Qwen3.6-35B-A3B，通过 Megatron-Bridge 完成全流程：W4A4 NVFP4 PTQ → 以 BF16 模型为教师做 500 次 QAD 迭代 → 在六个基准上评测。完整复现步骤、配置与配方位于仓库教程 examples/megatron_bridge/tutorials/Qwen3.6-35B-A3B/README.md。

核心亮点

W4A4 是值得瞄准的配置：在 12 种实测形状中 9 种击败 BF16（最高 1.30x），并将检查点从 67 GiB 压缩到 22 GiB（3.1x）。而纯权重量化的 W4A16 在 12 种形状中有 10 种慢于 BF16。
六个基准中只有 2 个因 W4A4 损失了可测精度，因此也只有这 2 个需要 QAD 去恢复。
IFBench 完全恢复：PTQ 损失 2.6 个百分点；500 次 QAD 迭代使模型与 BF16 达到统计等价。
MMMU-Pro 恢复约 40%的缺口，仍保留可测差距——因为数据混合是纯文本的，而 MMMU-Pro 是多模态基准。
重复次数比预期更重要：在 3 次重复时，一个基准出现了 3 个百分点的波动，到 8 次重复时该波动消失；IFBench 的真实增益直到 8 次重复才显现。

结果：六基准精度随 QAD 迭代的变化

下图展示了每个基准上 PTQ 学生（x=0）经 500 次 QAD 迭代的精度轨迹，虚线为 BF16 教师，点线为 PTQ 起点，误差条为 ±1 sem（标准误）。

图 1. Qwen3.6-35B-A3B 的 W4A4 NVFP4 精度 vs. QAD 训练迭代。（该图同时保存在教程目录 figures/qad_learning_curves.png 与公告目录 docs/source/announcements/assets/qwen36-w4a4-qad-learning-curves.png）

精度数据（跨重复的mean ± sem）：

模型	MMMU-Pro	GPQA-D	SciCode	AA-LCR	IFBench	tau2-bench
BF16（教师）	74.6 ± 0.2	84.7	39.9 ± 0.6	69.1 ± 0.8	60.0 ± 0.5	94.2 ± 1.0
W4A4 NVFP4 PTQ	73.4 ± 0.2	84.7	39.1 ± 0.7	70.0 ± 1.1	57.9 ± 0.5	94.2 ± 1.2
+ QAD 500 迭代	73.9 ± 0.2	84.2	40.2 ± 0.6	69.4 ± 1.5	59.6 ± 0.5	93.4 ± 0.4

教程中另有一行对照：已发布的 W4A16 NVFP4 检查点（README 结果表）在相同评测框架下为 69.8 平均分，低于 QAD 后的 W4A4（70.1），这进一步印证了 W4A4 + QAD 的组合优势。

QAD 究竟在哪里起作用

只有 IFBench 和 MMMU-Pro 的 W4A4 缺口大于 run-to-run 噪声；其余四个基准上 W4A4 基本无损，QAD 既不增也不损：

基准	W4A4 PTQ vs BF16	500 次 QAD 迭代后	结果
IFBench	−2.6 pp	−0.3 pp	恢复到 BF16 等价
MMMU-Pro	−1.2 pp	−0.7 pp	恢复约 40%，缺口仍在

教程 README 提供了更严格的统计细节（可折叠小节）：比较采用逐题配对 t 检验（同一问题在两个模型上的回答直接对比，抵消题目难度方差），p < 0.05视为"真实差距"。例如 IFBench 的 PTQ vs BF16 差距为 −2.62（p=0.017），500 次 QAD 后为 −0.29（p=0.79），说明完全恢复；而 MMMU-Pro 在 QAD 后仍为 −0.72（p=0.023），缺口有统计学意义。GPQA、SciCode、AA-LCR、tau2-bench 四个基准的差距均落在 ±1.2 pp 噪声带内，属于测量噪声。

吞吐量：W4A4 在 Blackwell 上击败 BF16

吞吐量使用 AIPerf 对 4x GB200 上已服务的 vLLM 端点实测，三种 ISL/OSL 形状 × 四种并发（输出 tokens/s）：

形状（ISL/OSL）	并发	BF16	W4A16 NVFP4	W4A4 NVFP4	W4A4 / BF16
decode 128/2048	128	17,636	15,222	20,076	1.14x
chat 8000/1000	32	3,649	2,373	4,079	1.12x
prefill 32000/400	128	854	1,092	1,107	1.30x

教程的完整 12 形状表（README 第 6 节）显示W4A4 在 12 种形状中的 9 种击败 BF16、在全部 12 种中击败 W4A16。值得注意的是 decode 128/2048 在并发 1 时 W4A16 只有 225 tokens/s，而 W4A4 为 307（0.88x vs BF16 的 351）。

W4A4 仅在并发 1 时输给 BF16，三个形状均为近恒定的 0.87–0.88x。公告解释这属于 FP4 内核路径的每调用固定开销——batch-1 decode 没有足够的算术强度去摊销它，这不是配方旋钮能解决的问题。教程给出的服务命令（vLLM 0.28.0，--tensor-parallel-size 4 --enable-expert-parallel --max-model-len 262144 --reasoning-parser qwen3等）与 AIPerf 压测循环（--synthetic-input-tokens-mean、--output-tokens-mean、--concurrency）都可在教程 README 中直接复刻。

成本：QAD 主导整个流程

QAD 是成本大头：在 32 节点（128 GB200）上以 32K 序列长度跑 500 次迭代耗时 5.7 小时，约 735 GPU-hours。其中稳态训练约 37 秒/迭代（占总时长的约 5.1 小时），其余约 35 分钟是任务启动与加载 67 GiB 教师和学生模型的开销（该运行被拆分为两个 4 小时作业，因此该开销支付了两次）。PTQ 只需 9 分钟（2 个 GB200 节点上约 1.2 GPU-hours，EP=8），HF 导出再多几分钟。而一个检查点在上述重复次数下跑完全部六个基准约需 100 GPU-hours。

从内存角度看，QAD 的最低硬件需求是：学生与教师模型同时驻留，加上 fp32 梯度缓冲和优化器状态——在上述设置下约占 GB200 的 185 GiB 显存中的 124 GB/GPU。

端到端复现链路

以下各步骤的命令、参数与配方均来自仓库教程 Qwen3.6-35B-A3B README，并可由 megatron_bridge 下的脚本直接执行。环境要求：容器nvcr.io/nvidia/nemo:26.08、ModelOpt 0.47.0、nemo-evaluator-launcher0.2.6（含nemo-evaluator0.2.8），GB200（aarch64）；NVFP4 检查点的部署与评测需要 Blackwell GPU。

1. 数据准备：token 预算混合

QAD 目前只支持纯文本的语言模型蒸馏，因此混合全部采用 SFT 文本：nvidia/Nemotron-Cascade-2-SFT-Data的 8 个 split，共 17.3B tokens。使用 dataset/MEGATRON_DATA_PREP.md 的 token 预算混合工作流，配置文件为 data_blend.yaml（需先设置其中的output_dir）：

Split	Tokens	Weight
chat	9.73B	56.2
math	3.65B	21.1
science	1.89B	10.9
instruction_following	0.57B	3.3
conversational_agent	0.57B	3.3
terminal_agent	0.57B	3.3
swe	0.31B	1.8
safety	0.003B	0.02

权重是各 split 在其自身 token 数中的占比——即对自然混合做单次遍历，而非调优后的混合。500 次迭代的调度仅消耗 8.4B tokens（约半个 epoch），因此不会有样本被重采样。注意 agent/SWE split 合计不足 9%，这对后面讨论的 agentic 覆盖度很关键。

2. PTQ：W4A4 NVFP4 量化

使用 examples/megatron_bridge/quantize.py 与配方model_type/qwen3_6_moe/ptq/w4a4_nvfp4-fp8_attn-kv_fp8_cast_mcore（文件位于 modelopt_recipes/model_type/qwen3_6_moe/ptq/）。--ep_size 8需要 8 个 rank，即 2 个 GB200 节点（每节点 4 GPU），用srun每 GPU 一个任务启动；8-GPU 节点上等价于单节点torchrun --nproc_per_node 8：

# SBATCH --nodes=2 --ntasks-per-node=4 --gpus-per-node=4 srun ... python /opt/Model-Optimizer/examples/megatron_bridge/quantize.py \ --hf_model_name_or_path Qwen/Qwen3.6-35B-A3B \ --recipe model_type/qwen3_6_moe/ptq/w4a4_nvfp4-fp8_attn-kv_fp8_cast_mcore \ --tp_size 1 --ep_size 8 --pp_size 1 \ --calib_dataset_name cnn_nemotron_v2_mix \ --calib_num_samples 1024 \ --calib_batch_size 1 \ --seq_length 8192 \ --export_megatron_path /path/to/qwen36_w4a4_megatron \ --skip_generate

量化了什么（从导出检查点的quantization_config读取）：

组件	精度	张量数
MoE 路由专家（`down`/`gate`/`up_proj`）	NVFP4 W4A4（block 16）	30,720
共享专家	NVFP4 W4A4	120
`lm_head`	NVFP4 W4A4	1
线性注意力（`in_proj_qkv`/`in_proj_z`/`out_proj`，30 层）	FP8 W8A8	90
全注意力（`q`/`k`/`v`/`o_proj`，10 层）	FP8 W8A8	40
KV cache	FP8（静态）	—
MTP 头、MoE 路由器、`conv1d`、`in_proj_a`/`in_proj_b`、嵌入、视觉塔	BF16	—

99.2% 的量化张量是 MoE 专家——FP4 吞吐收益正来自此处。注意力保持 FP8：只有 130 个张量，且数值上更敏感。从配方源码看，选择器使用Megatron-Core 叶子名（如mlp.experts.linear_fc1、self_attention.linear_qkv），并通配local_experts.<N>.段以同时覆盖 TEGroupedMLP 与 SequentialMLP 两种专家布局；_mcore后缀是承重的——该配方在 hf_ptq.py 流程下不会匹配任何权重量化器，HuggingFace 流程请改用qwen3_5_moe的 w4a16 配方。此外in_proj融合了 HF 的 [query, key, value, z, beta, alpha]，导出时由unified_export_megatron.py重新拆分并将in_proj_a/in_proj_b以 BF16 写出。

重要：--ep_size必须设为后续 QAD 将使用的专家并行度。QAD 直接加载该检查点，EP 必须匹配——专家布局已固化在分布式检查点中；之后以不同 EP 重新导出等于重跑 PTQ。

3. QAD：量化感知蒸馏

QAD 用 examples/megatron_bridge/distill.py 对量化学生做微调，目标函数来自 BF16 教师，让学生学到能挺过 4-bit 舍入的权重。脚本同时支持 HuggingFace 检查点与 Puzzletron AnyModel 检查点作为学生/教师输入；当学生权重位于 Megatron 检查点（如这里量化过的检查点）时，额外传--student_megatron_path，--student_hf_path仍用于构建学生架构。教师与学生必须共享 tokenizer——蒸馏以学生的 token id 给教师打分，KD 损失在 vocab 维上逐元素比较两者的 logits。

实验配置：32 节点 × 4 GB200（128 GPU），500 次迭代。命令如下（srun每 GPU 一任务，跨 32 节点共 128 ranks；在srun体内从SLURM_PROCID/SLURM_NTASKS/SLURM_LOCALID设置RANK/WORLD_SIZE/LOCAL_RANK；python -u保持多节点日志不缓冲）：

# SBATCH --nodes=32 --ntasks-per-node=4 --gpus-per-node=4 srun ... python -u /opt/Model-Optimizer/examples/megatron_bridge/distill.py \ --teacher_hf_path Qwen/Qwen3.6-35B-A3B \ --student_hf_path Qwen/Qwen3.6-35B-A3B \ --student_megatron_path /path/to/qwen36_w4a4_megatron \ --tp_size 1 --pp_size 1 --cp_size 1 --ep_size 8 \ --data_paths "${DATA_BLEND}" \ --data_path_to_cache /path/to/cache \ --seq_length 32768 \ --mbs 1 \ --gbs 512 \ --train_iters 500 \ --lr 1e-5 --min_lr 1e-6 --lr_warmup_iters 50 \ --logit_kl_topk 4096 \ --recompute_granularity full --recompute_method uniform --recompute_num_layers 1 \ --no_async_save \ --eval_iters 0 \ --save_interval 50 \ --output_dir /path/to/qad_output

非默认参数的含义（教程 README 的说明，distill.py 源码中均有对应解析，如--ep_size、--logit_kl_topk、--lr、--recompute_granularity等）：

--student_megatron_path：第 2 步的量化检查点；--student_hf_path仍指向 BF16 模型以提供架构。
--tp_size 1 --pp_size 1 --cp_size 1：必需而非可选（见下方约束）。--ep_size 8必须与 PTQ 检查点一致。
--seq_length 32768 --gbs 512：每迭代 16.8M tokens，每 100 迭代 1.7B。
--lr 1e-5 --min_lr 1e-6：比典型蒸馏学习率低一个数量级——任务是让权重适应量化，而不是学习任务本身（distill.py 中--lr默认值为 1e-4，这里大幅下调）。
--logit_kl_topk 4096：将 KD 损失限制在教师 top-4096 词表条目上。在 248,320 token 词表下，32K 序列的稠密[seq, vocab]fp32 logits 每个张量达30.31 GiB，单独就会 OOM。
--recompute_*/--no_async_save/--eval_iters 0：均为适配显存所必需。异步保存会派生一个需要自有 CUDA context 的 worker；验证路径计算全词表 LM 与 MTP 交叉熵（top-k 仅作用于训练），因此即使训练能跑通，32K 下的验证也会 OOM。

4. 导出到 HuggingFace

将量化后的 Megatron 检查点转为可直接部署的统一 HuggingFace 检查点（1 节点约 7 分钟，0.5 GB200 GPU-hours）。统一导出器以 TP=1 加载，因此用流水线并行切分跨 GPU：

torchrun --nproc_per_node 4 /opt/Model-Optimizer/examples/megatron_bridge/export_quantized_megatron_to_hf.py \ --hf_model_name_or_path Qwen/Qwen3.6-35B-A3B \ --megatron_path /path/to/qad_output/checkpoints/iter_0000500 \ --pp_size 4 \ --export_unified_hf_path /path/to/qwen36_w4a4_qad_hf

导出检查点可直接用 vLLM、TensorRT-LLM 和 SGLang 部署，可先用 generate_vllm.py（--model <path>）做冒烟验证。值得注意：QAD 检查点保留量化状态，因此使用export_quantized_megatron_to_hf.py而非普通蒸馏导出路径。

5. 评估：NeMo Evaluator 六基准

每个基准一个配置，位于 eval_configs/，可独立启动：

基准	配置	温度	运行数	墙钟时间	指标名
MMMU-Pro	mmmu_pro.yaml	1.0	8	2:30	`mmmu-pro_pass_at_1_symbolic_correct`
GPQA Diamond	gpqa.yaml	1.0	1（16 次取平均）	4:00	`gpqa_pass_at_1_avg-of-16_symbolic_correct`
SciCode（Subtask）	scicode.yaml	0.6	8	2:00	`scicode_pass_at_1_subtask_accuracy`
AA-LCR	aa_lcr.yaml	1.0	8	2:00	`aalcr_pass_at_1_judge_correct`
IFBench	ifbench.yaml	1.0	8	1:30	`ifbench_pass_at_1_average_score`
tau2-bench Telecom	tau2_telecom.yaml	1.0	3	1:30	`tau2_bench_telecom_pass_at_1_pass_at_1`

采样遵循模型卡片（T=1.0, top_p=0.95, max_new_tokens=131072），SciCode 例外按卡片用T=0.6。同一个配置可直接服务 BF16 与 NVFP4——vLLM 从检查点自身的quantization_config读取 FP8 KV-cache 设置，例如 ifbench.yaml 中vllm serve命令对两种模型原样可用。运行方式：

pip install "nemo-evaluator-launcher[all]==0.2.6" # 每个配置都需要： export HF_TOKEN=<your_huggingface_token> export SLURM_JOB_DIR=<path_to_slurm_job_output_dir> # 仅 AA-LCR（评判模型）与 tau2-bench（用户模拟器）需要： export INFERENCE_API_KEY=<key_for_those_endpoints> export NS_JUDGE_URL=<judge_endpoint_url> export LCR_JUDGE_MODEL_ID=<judge_model_id> export TAU2_ENDPOINT_URL=<user_simulator_url> export TAU2_USER_MODEL_ID=<user_simulator_model> # 先小规模验证流水线： # nemo-evaluator-launcher run --config eval_configs/mmmu_pro.yaml -o ++evaluation.nemo_evaluator_config.config.params.limit_samples=8 # 六基准按各自重复次数全部启动 for cfg_runs in mmmu_pro:8 gpqa:1 scicode:8 aa_lcr:8 ifbench:8 tau2_telecom:3; do cfg=${cfg_runs%%:*}; runs=${cfg_runs##*:} for i in $(seq 1 "$runs"); do nemo-evaluator-launcher run --config "eval_configs/${cfg}.yaml" done done

关键注意事项（教程 README 中以 IMPORTANT 标注）：

AA-LCR 与 tau2-bench 需要第二个模型端点。AA-LCR 用评判模型打分（NS_JUDGE_URL/LCR_JUDGE_MODEL_ID），tau2-bench 驱动模拟用户（TAU2_ENDPOINT_URL/TAU2_USER_MODEL_ID），两者都读取INFERENCE_API_KEY。端点必须用https://——key 随每个请求传递，重定向可能降级为http或转发到其他源。tau2-bench 还需独立部署（--enable-auto-tool-choice --tool-call-parser qwen3_coder --max-num-seqs 16），故无法与其他基准共用配置；qwen3_coder是模型卡片指定的解析器，模板的<tool_call>标记看似hermes风格，误用会导致工具调用解析失败而静默使基准失效。
每个任务设num_repeats: 1；表格中的重复次数来自多次启动同一配置。N 次启动给出 N 个独立pass@1值，这正是mean ± sem与配对检验所需的；num_repeats: N只会得到单一无离散度的pass@1[avg-of-N]。GPQA 是刻意的例外。
重复次数必须足够。这些基准噪声很大，3 次不足以区分信号与噪声：3 次重复时 AA-LCR（仅 100 题）出现了一个看似真实、到 8 次完全消失的 3 pp 波动；IFBench 真实的 +2.3 pp 增益在 3 次时不可见，直到 8 次才显现。3 次还会低估基准的噪声程度，使测得的离散度看起来比实际更紧。

输出长度：精度之外的另一半服务成本

模型在输出更多 token 时即使分数相同，端到端也会更慢。各基准的平均完成 token 数（response_stats.avg_completion_tokens）：

基准	BF16	W4A16 NVFP4	W4A4 NVFP4 PTQ	+ QAD 500 迭代	runs/侧
SciCode（Subtask）	5,348	+22.9%	+25.5%	+90.9%	8
IFBench	12,177	+7.0%	+9.3%	+17.4%	8
AA-LCR	2,560	+7.1%	+6.9%	+9.8%	8
MMMU-Pro	9,382	+3.0%	+6.2%	−3.8%	8
GPQA Diamond	13,561	+17.1%	+6.6%	−8.5%	1

4-bit 权重本身就让 SciCode 输出增长约 23–25%（已发布的 W4A16 检查点同样如此，不是 QAD 或 W4A4 引入的）；QAD 再将其推至 +90.9%，但分数不变（40.2 vs 39.9），同时把 GPQA 与 MMMU-Pro 拉回 BF16 水平。吞吐表在固定输出长度下测量，因此未捕捉到这一效应。

教程还深入剖析了 SciCode 数字的本质——不是冗长，而是一小部分子步骤未能终止：命中 131,072 token 上限的<think>子步骤从 BF16 的 0.7%（20/2704）升至 QAD 500 的 3.6%（96/2704），其中 93 个几乎返回零答案 token（模型写完完整解答、说"我好像绕圈子了"然后重写一遍；检查的案例中一个 20 词窗口重复 352 次，97.7% 的 20 词窗口是重复的）。这些 3.6% 的子步骤消耗了全部完成 token 的 45.7%；剔除后是 +30.4% 而非 +90.9%。中位数也大致翻倍（+91.6%），说明整个分布右移，不仅是尾部效应。作者排除了"--logit_kl_topk 4096把停止 token 排除在损失外"的猜测（教师对</think>的中位排名约 570、<|im_end|>约 5，均落在 top-k 内），更可能的解释是混合数据中"答案已写完、现在停止"这类位置太少，而教师强制的损失从未演练 10K+ token 深处的自由生成。对下一次 QAD 运行的建议：把长度上限率作为与精度并列的一等公民指标；考虑用 top-p 替代 top-k 覆盖教师熵；显存允许时用全词表 KL。

6. vLLM 吞吐压测

用 AIPerf 对 4x GB200 上已服务的 vLLM 端点测量，三种 ISL/OSL 形状 × 四种并发 = 12 种形状。同一个vllm serve命令对 BF16 与 NVFP4 均适用：

vllm serve <checkpoint_path> --served-model-name bench \ --host 127.0.0.1 --port 8000 \ --tensor-parallel-size 4 --data-parallel-size 1 --enable-expert-parallel \ --max-model-len 262144 --reasoning-parser qwen3 \ --model-loader-extra-config '{"enable_multithread_load": true, "num_threads": 128}' \ --max-num-batched-tokens 8192 --enable-chunked-prefill # decode-bound、chat、prefill-bound 三种形状 × 四种并发 for shape in "128 2048 decode" "8000 1000 chat" "32000 400 prefill"; do set -- $shape; ISL=$1; OSL=$2; NAME=$3 for C in 1 8 32 128; do aiperf profile -m bench --endpoint-type chat --streaming -u localhost:8000 \ --synthetic-input-tokens-mean $ISL --output-tokens-mean $OSL \ --concurrency $C --request-count $(( C * 5 )) \ --tokenizer <checkpoint_path> \ --extra-inputs ignore_eos:true --random-seed 42 \ --artifact-dir bench/${NAME}_isl${ISL}_osl${OSL}/c${C} done done

教程给出了两条实用建议：压测前先用一个可验证答案的短提示确认端点回答正确——KV dtype 配错或内核意外时模型仍会以看似合理的速率产 token，吞吐数字好看但毫无意义；以及将 vLLM 部署细节参考 vLLM Quickstart 文档。

潜在改进方向：三个未探索的杠杆

这是一次 500 迭代、32K、纯文本混合的单次运行，这三个选择各自都是未探索的杠杆：

继续延长 QAD。恢复尚未饱和：IFBench 的增益来得晚（迭代 300 时相对学生为 −0.11 pp，500 时为 +2.33 pp），MMMU-Pro 仍在爬升（+0.51 pp，p=0.078）。训练只用了混合中 17.3B tokens 的 8.4B，重复样本前还可约翻倍。按每 500 迭代约 735 GPU-hours 计，这是最直接的实验，且仅 IFBench + MMMU-Pro（约 55 GPU-hours）就足以读出结果。
更长的序列长度（64K）。模型服务上下文为 262K，32K 只覆盖了其中一部分；AA-LCR 这个唯一的长上下文基准没有表现出任何方向性变化。32K 下已需要 top-k KD 加全重算，且显存主要由驻留的学生 + 教师 + fp32 梯度缓冲决定而非序列长度——64K 需要不同的显存杠杆。
更好的数据混合。研究中信号最清晰的发现是：MMMU-Pro 是多模态的，混合是纯文本的，而 MMMU-Pro 正是 QAD 唯一未闭合的缺口。既然 QAD 只支持纯文本蒸馏，用这种方式恢复多模态基准是让方法做它未被设计的事情。Agentic 覆盖也偏薄（agent/SWE split 不足 9%，tau2-bench 还出现过瞬时 8x 的agent_error尖峰），且这里的权重仅与 token 数成正比——可对照 Nemotron-3-Nano 教程中针对目标基准精心设计并做过消融的数据混合。

如果只跑一个实验，跑(1)：没有工程风险，轨迹表明增益仍在到来，且它产出的证据足以判断 (2)、(3) 是否值得其成本。

总结

这条公告与研究教程给出的核心结论是：在 Blackwell 上，W4A4 NVFP4 相比 W4A16 是正确目标——它解锁 FP4 张量核心，在多数实测形状上击败 BF16 并将检查点缩小 3.1x；代价是部分基准的精度缺口，而 500 次 QAD 迭代以约 735 GPU-hours 的成本把 IFBench 完全恢复到 BF16 等价、MMMU-Pro 恢复约 40%。从源码可以确认，这套流程在 Model-Optimizer 中已形成可复现的工程闭环：PTQ 配方（Megatron-Core 叶子名选择器）、quantize.py、distill.py（含--logit_kl_topk等显存关键参数）、export_quantized_megatron_to_hf.py与六套 NeMo Evaluator 配置全部随仓库发布，任何一个具备 GB200 环境的团队都可以按教程完整重跑。文中反复强调的方法论也值得单独记住：多基准独立重复、配对统计检验、以及把"输出长度上限率"纳入跟踪——这些才是让一次 QAD 实验结论可信的前提。