【免费下载链接】Model-OptimizerA 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 DistillationQAD完整研究记录系统讲解为什么权重仅量化的 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-bitW4A4才能解锁这些内核并在 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 GiB3.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 学生x0经 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-ProGPQA-DSciCodeAA-LCRIFBenchtau2-benchBF16教师74.6 ± 0.284.739.9 ± 0.669.1 ± 0.860.0 ± 0.594.2 ± 1.0W4A4 NVFP4 PTQ73.4 ± 0.284.739.1 ± 0.770.0 ± 1.157.9 ± 0.594.2 ± 1.2 QAD 500 迭代73.9 ± 0.284.240.2 ± 0.669.4 ± 1.559.6 ± 0.593.4 ± 0.4教程中另有一行对照已发布的 W4A16 NVFP4 检查点README 结果表在相同评测框架下为 69.8 平均分低于 QAD 后的 W4A470.1这进一步印证了 W4A4 QAD 的组合优势。QAD 究竟在哪里起作用只有 IFBench 和 MMMU-Pro 的 W4A4 缺口大于 run-to-run 噪声其余四个基准上 W4A4 基本无损QAD 既不增也不损基准W4A4 PTQ vs BF16500 次 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.62p0.017500 次 QAD 后为 −0.29p0.79说明完全恢复而 MMMU-Pro 在 QAD 后仍为 −0.72p0.023缺口有统计学意义。GPQA、SciCode、AA-LCR、tau2-bench 四个基准的差距均落在 ±1.2 pp 噪声带内属于测量噪声。吞吐量W4A4 在 Blackwell 上击败 BF16吞吐量使用 AIPerf 对 4x GB200 上已服务的 vLLM 端点实测三种 ISL/OSL 形状 × 四种并发输出 tokens/s形状ISL/OSL并发BF16W4A16 NVFP4W4A4 NVFP4W4A4 / BF16decode 128/204812817,63615,22220,0761.14xchat 8000/1000323,6492,3734,0791.12xprefill 32000/4001288541,0921,1071.30x教程的完整 12 形状表README 第 6 节显示W4A4 在 12 种形状中的 9 种击败 BF16、在全部 12 种中击败 W4A16。值得注意的是 decode 128/2048 在并发 1 时 W4A16 只有 225 tokens/s而 W4A4 为 3070.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-hoursEP8HF 导出再多几分钟。而一个检查点在上述重复次数下跑完全部六个基准约需 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.8GB200aarch64NVFP4 检查点的部署与评测需要 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_dirSplitTokensWeightchat9.73B56.2math3.65B21.1science1.89B10.9instruction_following0.57B3.3conversational_agent0.57B3.3terminal_agent0.57B3.3swe0.31B1.8safety0.003B0.02权重是各 split 在其自身 token 数中的占比——即对自然混合做单次遍历而非调优后的混合。500 次迭代的调度仅消耗 8.4B tokens约半个 epoch因此不会有样本被重采样。注意 agent/SWE split 合计不足 9%这对后面讨论的 agentic 覆盖度很关键。2. PTQW4A4 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 --nodes2 --ntasks-per-node4 --gpus-per-node4 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_projNVFP4 W4A4block 1630,720共享专家NVFP4 W4A4120lm_headNVFP4 W4A41线性注意力in_proj_qkv/in_proj_z/out_proj30 层FP8 W8A890全注意力q/k/v/o_proj10 层FP8 W8A840KV cacheFP8静态—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 GB200128 GPU500 次迭代。命令如下srun每 GPU 一任务跨 32 节点共 128 ranks在srun体内从SLURM_PROCID/SLURM_NTASKS/SLURM_LOCALID设置RANK/WORLD_SIZE/LOCAL_RANKpython -u保持多节点日志不缓冲# SBATCH --nodes32 --ntasks-per-node4 --gpus-per-node4 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。统一导出器以 TP1 加载因此用流水线并行切分跨 GPUtorchrun --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-Prommmu_pro.yaml1.082:30mmmu-pro_pass_at_1_symbolic_correctGPQA Diamondgpqa.yaml1.0116 次取平均4:00gpqa_pass_at_1_avg-of-16_symbolic_correctSciCodeSubtaskscicode.yaml0.682:00scicode_pass_at_1_subtask_accuracyAA-LCRaa_lcr.yaml1.082:00aalcr_pass_at_1_judge_correctIFBenchifbench.yaml1.081:30ifbench_pass_at_1_average_scoretau2-bench Telecomtau2_telecom.yaml1.031:30tau2_bench_telecom_pass_at_1_pass_at_1采样遵循模型卡片T1.0, top_p0.95, max_new_tokens131072SciCode 例外按卡片用T0.6。同一个配置可直接服务 BF16 与 NVFP4——vLLM 从检查点自身的quantization_config读取 FP8 KV-cache 设置例如 ifbench.yaml 中vllm serve命令对两种模型原样可用。运行方式pip install nemo-evaluator-launcher[all]0.2.6 # 每个配置都需要 export HF_TOKENyour_huggingface_token export SLURM_JOB_DIRpath_to_slurm_job_output_dir # 仅 AA-LCR评判模型与 tau2-bench用户模拟器需要 export INFERENCE_API_KEYkey_for_those_endpoints export NS_JUDGE_URLjudge_endpoint_url export LCR_JUDGE_MODEL_IDjudge_model_id export TAU2_ENDPOINT_URLuser_simulator_url export TAU2_USER_MODEL_IDuser_simulator_model # 先小规模验证流水线 # nemo-evaluator-launcher run --config eval_configs/mmmu_pro.yaml -o evaluation.nemo_evaluator_config.config.params.limit_samples8 # 六基准按各自重复次数全部启动 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_IDtau2-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 个独立pass1值这正是mean ± sem与配对检验所需的num_repeats: N只会得到单一无离散度的pass1[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基准BF16W4A16 NVFP4W4A4 NVFP4 PTQ QAD 500 迭代runs/侧SciCodeSubtask5,34822.9%25.5%90.9%8IFBench12,1777.0%9.3%17.4%8AA-LCR2,5607.1%6.9%9.8%8MMMU-Pro9,3823.0%6.2%−3.8%8GPQA Diamond13,56117.1%6.6%−8.5%14-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 pp500 时为 2.33 ppMMMU-Pro 仍在爬升0.51 ppp0.078。训练只用了混合中 17.3B tokens 的 8.4B重复样本前还可约翻倍。按每 500 迭代约 735 GPU-hours 计这是最直接的实验且仅 IFBench MMMU-Pro约 55 GPU-hours就足以读出结果。更长的序列长度64K。模型服务上下文为 262K32K 只覆盖了其中一部分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 实验结论可信的前提。赞分享【免费下载链接】Model-OptimizerA 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点击查看免费下载相关推荐Qwen3.6-35B-A3B W4A4 NVFP4 全流程实战从 PTQ、量化感知蒸馏QAD到 vLLM 部署Model Optimizer Megatron-Bridge 教程Qwen3.6 35B A3B W4A4 NVFP4 全流程实战从 PTQ、量化感知蒸馏QAD到 vLLM 部署Model Optimizer MegaModel-Optimizer 与 LLaMA-Factory 集成实战基于 NVFP4 的 QAT/QAD 量化感知训练指南Model Optimizer 与 LLaMA Factory 集成实战基于 NVFP4 的 QAT/QAD 量化感知训练指南 本指南以仓库中的 LLaMA使用 NVIDIA Model Optimizer 对 LTX-2 DiT 进行量化感知蒸馏训练QAD完整指南使用 NVIDIA Model Optimizer 对 LTX 2 DiT 进行量化感知蒸馏训练QAD完整指南 本篇技术指南聚焦 NVIDIA Model创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Model-Optimizer 实战：用量化感知蒸馏（QAD）恢复 Qwen3.6-35B-A3B 的 W4A4 NVFP4 精度
【免费下载链接】Model-OptimizerA 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 DistillationQAD完整研究记录系统讲解为什么权重仅量化的 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-bitW4A4才能解锁这些内核并在 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 GiB3.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 学生x0经 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-ProGPQA-DSciCodeAA-LCRIFBenchtau2-benchBF16教师74.6 ± 0.284.739.9 ± 0.669.1 ± 0.860.0 ± 0.594.2 ± 1.0W4A4 NVFP4 PTQ73.4 ± 0.284.739.1 ± 0.770.0 ± 1.157.9 ± 0.594.2 ± 1.2 QAD 500 迭代73.9 ± 0.284.240.2 ± 0.669.4 ± 1.559.6 ± 0.593.4 ± 0.4教程中另有一行对照已发布的 W4A16 NVFP4 检查点README 结果表在相同评测框架下为 69.8 平均分低于 QAD 后的 W4A470.1这进一步印证了 W4A4 QAD 的组合优势。QAD 究竟在哪里起作用只有 IFBench 和 MMMU-Pro 的 W4A4 缺口大于 run-to-run 噪声其余四个基准上 W4A4 基本无损QAD 既不增也不损基准W4A4 PTQ vs BF16500 次 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.62p0.017500 次 QAD 后为 −0.29p0.79说明完全恢复而 MMMU-Pro 在 QAD 后仍为 −0.72p0.023缺口有统计学意义。GPQA、SciCode、AA-LCR、tau2-bench 四个基准的差距均落在 ±1.2 pp 噪声带内属于测量噪声。吞吐量W4A4 在 Blackwell 上击败 BF16吞吐量使用 AIPerf 对 4x GB200 上已服务的 vLLM 端点实测三种 ISL/OSL 形状 × 四种并发输出 tokens/s形状ISL/OSL并发BF16W4A16 NVFP4W4A4 NVFP4W4A4 / BF16decode 128/204812817,63615,22220,0761.14xchat 8000/1000323,6492,3734,0791.12xprefill 32000/4001288541,0921,1071.30x教程的完整 12 形状表README 第 6 节显示W4A4 在 12 种形状中的 9 种击败 BF16、在全部 12 种中击败 W4A16。值得注意的是 decode 128/2048 在并发 1 时 W4A16 只有 225 tokens/s而 W4A4 为 3070.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-hoursEP8HF 导出再多几分钟。而一个检查点在上述重复次数下跑完全部六个基准约需 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.8GB200aarch64NVFP4 检查点的部署与评测需要 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_dirSplitTokensWeightchat9.73B56.2math3.65B21.1science1.89B10.9instruction_following0.57B3.3conversational_agent0.57B3.3terminal_agent0.57B3.3swe0.31B1.8safety0.003B0.02权重是各 split 在其自身 token 数中的占比——即对自然混合做单次遍历而非调优后的混合。500 次迭代的调度仅消耗 8.4B tokens约半个 epoch因此不会有样本被重采样。注意 agent/SWE split 合计不足 9%这对后面讨论的 agentic 覆盖度很关键。2. PTQW4A4 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 --nodes2 --ntasks-per-node4 --gpus-per-node4 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_projNVFP4 W4A4block 1630,720共享专家NVFP4 W4A4120lm_headNVFP4 W4A41线性注意力in_proj_qkv/in_proj_z/out_proj30 层FP8 W8A890全注意力q/k/v/o_proj10 层FP8 W8A840KV cacheFP8静态—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 GB200128 GPU500 次迭代。命令如下srun每 GPU 一任务跨 32 节点共 128 ranks在srun体内从SLURM_PROCID/SLURM_NTASKS/SLURM_LOCALID设置RANK/WORLD_SIZE/LOCAL_RANKpython -u保持多节点日志不缓冲# SBATCH --nodes32 --ntasks-per-node4 --gpus-per-node4 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。统一导出器以 TP1 加载因此用流水线并行切分跨 GPUtorchrun --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-Prommmu_pro.yaml1.082:30mmmu-pro_pass_at_1_symbolic_correctGPQA Diamondgpqa.yaml1.0116 次取平均4:00gpqa_pass_at_1_avg-of-16_symbolic_correctSciCodeSubtaskscicode.yaml0.682:00scicode_pass_at_1_subtask_accuracyAA-LCRaa_lcr.yaml1.082:00aalcr_pass_at_1_judge_correctIFBenchifbench.yaml1.081:30ifbench_pass_at_1_average_scoretau2-bench Telecomtau2_telecom.yaml1.031:30tau2_bench_telecom_pass_at_1_pass_at_1采样遵循模型卡片T1.0, top_p0.95, max_new_tokens131072SciCode 例外按卡片用T0.6。同一个配置可直接服务 BF16 与 NVFP4——vLLM 从检查点自身的quantization_config读取 FP8 KV-cache 设置例如 ifbench.yaml 中vllm serve命令对两种模型原样可用。运行方式pip install nemo-evaluator-launcher[all]0.2.6 # 每个配置都需要 export HF_TOKENyour_huggingface_token export SLURM_JOB_DIRpath_to_slurm_job_output_dir # 仅 AA-LCR评判模型与 tau2-bench用户模拟器需要 export INFERENCE_API_KEYkey_for_those_endpoints export NS_JUDGE_URLjudge_endpoint_url export LCR_JUDGE_MODEL_IDjudge_model_id export TAU2_ENDPOINT_URLuser_simulator_url export TAU2_USER_MODEL_IDuser_simulator_model # 先小规模验证流水线 # nemo-evaluator-launcher run --config eval_configs/mmmu_pro.yaml -o evaluation.nemo_evaluator_config.config.params.limit_samples8 # 六基准按各自重复次数全部启动 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_IDtau2-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 个独立pass1值这正是mean ± sem与配对检验所需的num_repeats: N只会得到单一无离散度的pass1[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基准BF16W4A16 NVFP4W4A4 NVFP4 PTQ QAD 500 迭代runs/侧SciCodeSubtask5,34822.9%25.5%90.9%8IFBench12,1777.0%9.3%17.4%8AA-LCR2,5607.1%6.9%9.8%8MMMU-Pro9,3823.0%6.2%−3.8%8GPQA Diamond13,56117.1%6.6%−8.5%14-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 pp500 时为 2.33 ppMMMU-Pro 仍在爬升0.51 ppp0.078。训练只用了混合中 17.3B tokens 的 8.4B重复样本前还可约翻倍。按每 500 迭代约 735 GPU-hours 计这是最直接的实验且仅 IFBench MMMU-Pro约 55 GPU-hours就足以读出结果。更长的序列长度64K。模型服务上下文为 262K32K 只覆盖了其中一部分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 实验结论可信的前提。赞分享【免费下载链接】Model-OptimizerA 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点击查看免费下载相关推荐Qwen3.6-35B-A3B W4A4 NVFP4 全流程实战从 PTQ、量化感知蒸馏QAD到 vLLM 部署Model Optimizer Megatron-Bridge 教程Qwen3.6 35B A3B W4A4 NVFP4 全流程实战从 PTQ、量化感知蒸馏QAD到 vLLM 部署Model Optimizer MegaModel-Optimizer 与 LLaMA-Factory 集成实战基于 NVFP4 的 QAT/QAD 量化感知训练指南Model Optimizer 与 LLaMA Factory 集成实战基于 NVFP4 的 QAT/QAD 量化感知训练指南 本指南以仓库中的 LLaMA使用 NVIDIA Model Optimizer 对 LTX-2 DiT 进行量化感知蒸馏训练QAD完整指南使用 NVIDIA Model Optimizer 对 LTX 2 DiT 进行量化感知蒸馏训练QAD完整指南 本篇技术指南聚焦 NVIDIA Model创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
