MXFP8、NVFP4 训练做到哪一步了？
full-iteration CUDA Graph 为什么 dense 可以、MoE 难？
先弄清楚：每个概念是什么
- MXFP8 和 NVFP4
- Blackwell 上的两种低精度格式，元素分别是 8 bit 和 4 bit，都按 block 配 scale（格式见 mixed precision）。
- Full-iteration CUDA Graph
- 把一整个 training iteration 录成一个 graph，之后每步一次 replay（见 CUDA Graph）。
看图：哪种 iteration 能录成一个 graph
30 秒回答
From the 0.19 and 0.20 release notes, Megatron has MXFP8 training paths and NVFP4 training for DeepSeek-V3. Selected tensors stay in FP32, optionally including the output logits. Communication is quantized too: FSDP v2 gathers MXFP8 parameters directly, and NCCL EP can dispatch in MXFP8, which is experimental. A whole dense training iteration can be captured in one CUDA Graph, I think because every step launches the same kernels with the same buffer sizes. MoE is harder: expert-dispatch buffers depend on routing, so they aren't capture-safe. NCCL EP's static mode keeps a fixed budget and replays the step on overflow.
低精度做到哪一步了
| 做了什么 | 细节 | 出处 |
|---|---|---|
| MXFP8 training path | release notes 指向 Nemotron 3 Super 的 MXFP8 示例配置 | 0.19.0 |
| NVFP4 training | DeepSeek-V3；active MTP layer 里也做 FP4 quantization | 0.20.0，#7328 |
| Selective FP32 | 打了标记的参数在模块转成低精度时留在 FP32，optimizer 和 checkpoint 跟着处理。PR 没有点名是哪些 tensor | 0.20.0，#5929 |
| FP32 output logits | LM output logits 可选用 FP32 算，--output-logit-dtype 默认 bf16 | 0.20.0，#6252 |
| Quantized parameter gather | weight 是 MXFP8 时 FSDP 直接 all-gather 它的 data 和 scale，不先还原成高精度。MFSDP v2 的 adapter 支持它和 MXFP8 compute | 0.20.0，#7588 |
| EP 通信用 MXFP8 | NCCL EP 的 dispatch forward 和 combine backward，标 experimental | 0.20.0，#6524 |
logits 留 FP32 的理由在 PR #6252 里。原来的路径内部用 FP32 累加，但每个 logit 在 cross entropy 之前被舍成 BF16，丢掉的 bit 找不回来。代价是 PR 的 kernel benchmark 在 GB300 上量到的 median overhead 5.4%。
按格式手算通信量。MXFP8 每个元素 8 bit，每 32 个元素再加一个 8 bit 的 scale，合 8.25 bit，约是 BF16 的 52%。NVFP4 每 16 个元素一个 scale，是 4 + 8/16 = 4.5 bit，约 28%。
Full-iteration CUDA Graph：dense 可以，MoE 难
CUDA Graph 要求每次 replay 的 kernel 序列、shape 和内存地址都不变（见 限制）。0.20.0 给 MFSDP v2 加了 full-iteration 的 capture 和 replay，范围限定在受支持的 dense 配置。PR #7075 的测试用一个 dense 的 Llama-3-shaped proxy，并写明有意排除 MoE，理由是 MoE 的 "data-dependent expert-dispatch buffers are not capture-safe"。
dense 为什么可以，PR 没有展开。按 CUDA Graph 的限制推，batch 和 sequence length 固定时，每个 iteration 发的 kernel 和用的 buffer 都一样。
对策是 NCCL EP 的 static mode，它用固定 budget，溢出就扩 budget 重放这一步（PR #6229，细节见 eager 和 static）。
必答点
- MXFP8、NVFP4 都按 block 配 scale；training path 分别写在 0.19.0 和 0.20.0 的 release notes 里
- 不是整个模型都低精度：selective FP32，output logits 可选 FP32
- 通信也量化：quantized parameter gather，NCCL EP 的 MXFP8 dispatch（experimental）
- full-iteration CUDA Graph 目前只覆盖 dense 配置；MoE 的 dispatch buffer 随数据变
- 对策是 static mode 的固定 budget，溢出就扩 budget 重放
追问
低精度一定更快吗？
不一定。NeMo-RL 0.8.0 在 Qwen3-30B-A3B-Base 上跑 NVFP4，rollout throughput 是 BF16 的 1.40×，end-to-end 是 1.15×，但 training throughput 只有 0.84×，refit 也更慢。同一段写 backward 目前走 Transformer Engine 的 dequantized path，release notes 没说这就是变慢的原因。
NeMo-RL 的 NVFP4 训练里，哪些部分没有量化？
只有 routed expert 的 MLP 在 forward 里用 NVFP4。持久保存的 weight、refit 传的数据、attention、router、shared expert 和部分 boundary layer 留 BF16，optimizer state 留 FP32。
Quantized parameter gather 有什么限制？
按 PR #7588，MFSDP v2 的 adapter 要求 fp8_param 和 fp8_param_gather 两个设置一致，其他 FP8 recipe 和 FP4 仍然被拒绝。
低精度的 checkpoint 要注意什么？
0.19.0 加了 streaming quantized checkpoint loading，FP8、MXFP8、NVFP4 的 tensor 逐步 dequantize，不再给整个模型分配 BF16 的临时空间。要求 bit-exact 时，determinism 的 blog 建议保留一份 full-precision 的 source of truth，并让重建路径完全一致（见 bitwise determinism）。
来源core 0.20.0 release notes（selective FP32、NVFP4、quantized parameter gather、NCCL EP 的 MXFP8 communication、MFSDP v2 CUDA graphs）· core 0.19.0 release notes（MXFP8 training paths、streaming quantized checkpoint loading）· PR #7075（排除 MoE 的原话）· PR #6229（static mode）· PR #5929、PR #6252、PR #7588、PR #6524 · Transformer Engine：Using FP8 and FP4（MXFP8 和 NVFP4 的 block 和 scale）· NeMo-RL v0.8.0 release notes（NVFP4 的 1.40×、1.15×、0.84×）· MegaMoE 状态页 #8427 · Q4 roadmap #9232 · ml-八股 06 第零节 · 全部原话见 更新笔记 3.1–3.3、3.6 节