top of page

Miles Blackwell RL 以原生 MXFP8 和 NVFP4 取代统一 BF16

Miles Blackwell 现已支持两套原生低精度强化学习配方,并在八张 NVIDIA B200 GPU 上的六种配置中进行了测试。一套在 rollout 和训练中均使用 MXFP8;另一套则对 mixture-of-experts 权重采用逐 token NVFP4,同时在其他部分保留更高精度。

这一结果挑战了关于强化学习(RL)的一项常见假设:较低精度不一定意味着必须接受明显更弱的学习曲线。在 Miles 对 Qwen3-30B-A3B 的消融实验中,全部五种低精度配置的原始奖励都紧密跟随 BF16 基线。

这一发现附带重要限定:该实验是一次受控的配方消融,而非经过充分调优的训练基准测试,也不构成普遍准确性保证。Miles 还在敏感层中保留 BF16、维护了一份额外的 BF16 权重副本,并观察到偶发的 NVFP4 梯度尖峰。

因此,真正的较量并不只是四位与十六位之间的对比,而是保持一致、选择性应用的精度契约与统一 BF16 流水线之间的较量。Miles 认为,只有在训练、采样、转换和实时权重更新以相同方式量化相同张量时,Blackwell 原生格式才能发挥价值。

Miles Blackwell 支持现已覆盖完整 RL 闭环

Miles 通过将 MXFP8 和 NVFP4 串联到完整的强化学习流程中,使其不再局限于孤立的内核。

Miles 团队于 2026 年 7 月 29 日发布了这些配方。其低精度结果涵盖检查点转换、Megatron 训练、SGLang rollout 和实时权重导出。该实现还依赖 TransformerEngine、FlashInfer、cuDNN frontend 及相关项目贡献的组件。

第一套配方在主要计算路径中全面使用 MXFP8。MXFP8 是一种八位微缩放格式,每个由 32 个 E4M3 数值组成的块共享一个 E8M0 缩放因子。rollout、前向传播、权重梯度矩阵乘法和数据梯度矩阵乘法均可使用该格式。

这种广泛覆盖十分重要,因为 RL 系统包含两个紧密关联的策略:训练策略负责计算更新,而 rollout 策略负责生成用于计算奖励的回答。如果二者以不同方式量化权重,它们就不再精确表示同一个模型。

Miles 此前支持一种 DeepSeek-V3 风格的 FP8 设计,其基于更大的缩放块。该路线依然具有现实意义,尤其适用于 Hopper 硬件。不过,它是在 Tensor Core 路径周围通过软件应用缩放,而非使用 Blackwell 原生的微缩放硬件。

第二套配方采取了更有选择性的方案。它对 mixture-of-experts(MoE)层中经路由的专家权重和激活应用 NVFP4。NVFP4 以四位存储 E2M1 数值,并为每个 16 值块配备一个 E4M3 缩放因子。

另一个 FP32 缩放因子覆盖更大的范围。Miles 会针对每个 token 单独计算这一缩放因子,而不是让其在一个张量或 batch 内共享。此举旨在避免某个 token 的表示随 batch 组成变化。

除非配置规则选择其他格式,NVFP4 模型的其余部分仍保留 BF16。这一设计将四位计算集中于 MoE 模型存储大量权重数据的位置,同时避免将注意力机制及其他敏感组件强行压缩到最窄的可用表示中。

NVIDIA 将 NVFP4 scaling描述为一套面向 Blackwell Tensor Cores 的双层系统。与使用 32 值分组的格式相比,16 值块能提供更细粒度的局部适应能力;张量级 FP32 缩放因子则扩展了可用范围。

Miles 将较大缩放因子的作用范围从按张量改为按 token。这一选择使其 RL 配方区别于直接的推理部署方案,也说明仅仅增加一种 FP4 数据类型,并不足以构建稳定的 RL 系统。

两套配方都支持高精度和反量化反向传播模式。高精度反向传播会为反向矩阵乘法使用原始 BF16 操作数;反量化反向传播则从前向传播中实际使用的精确低精度数值重建 BF16 操作数。

后一种方案牺牲了一些数值细节,但能与前向策略保持更接近的一致性。两种 NVFP4 模式的反向矩阵乘法都不会在 FP4 中执行。因此,Miles 测试的是选择性低精度,而非宣称实现了通用的四位训练闭环。

奖励曲线转移了举证责任

最值得注意的结果并非 Tensor Core 峰值吞吐量,而是在测试工作负载中没有出现明显的奖励损失。

Miles 在 dapo-math-17k 数据集上评估了采用同步、GRPO 风格 RL 的 Qwen3-30B-A3B。系统使用八张 B200 GPU,在 rollout 和训练之间平均分配。每个 prompt 接收八个 rollout 样本,回答长度上限为 8,192 个 token。

该研究将一项 BF16 基线与五种低精度配置进行了比较。其中包括端到端 MXFP8,以及每种低精度格式各自的两种反向传播模式。NVFP4 变体将四位操作限定在 MoE 专家路径中。

全部五条低精度原始奖励曲线都紧密追踪 BF16 曲线。这并不能证明它们在不同任务、随机种子或更长训练运行中等价,但确实表明,在这一特定实验中,低精度 rollout 并未淹没学习信号。

这对 RL 而言是一个重要门槛。监督训练可以在规模庞大且相对稳定的数据集上平均优化信号;RL 往往处理噪声更大的奖励和更小的策略更新,因此额外量化误差更难与真实学习效果区分开来。

Miles 还报告称,相比 BF16,MXFP8 和 NVFP4 都缩短了 rollout 时间。已发布文章以图表形式展示了比较结果,但没有提供适合用于通用标题的单一百分比。结果方向比其可迁移性更明确。

rollout 改进之所以重要,是因为生成往往主导强化学习工作负载。策略必须先生成完整回答,才能计算奖励和更新;长上下文和多样本会让这一阶段尤其昂贵。

在测得的设置中,MXFP8 相比 BF16 也改善了训练时间。NVFP4 的训练端则呈现相反结果:尽管 rollout 更快,两种 NVFP4 反向覆盖变体在训练期间都慢于 BF16。

Miles 将这一差距归因于当前集成状况,而非 Blackwell 的 FP4 Tensor Cores。测得的 TransformerEngine 路径将逐 token FP32 缩放作为独立的 PyTorch 操作执行。融合的 cuDNN frontend 内核已经存在,但其 TransformerEngine 集成仍待完成。

这一分化结果让分析保持务实。NVFP4 并不会仅仅因为数值更小就自动变快。内核融合、数据布局、缩放操作和框架边界共同决定理论吞吐量能否体现在完整应用中。

低精度配置展现出的训练与 rollout 不匹配程度也高于 BF16。NVFP4 起始时的参考 KL 测量值更高,该指标用于比较策略分布。不过,Miles 是相对于一个 BF16 Megatron 参考模型计算这一诊断指标的。

因此,该指标从一开始就包含了格式差异。其系数被设为零,因此不会作为优化惩罚。Miles 警告,不应将该测量单独视为学习失败的迹象。

奖励曲线带来了一种有益的反转:精度不匹配增加了,但在这次消融实验中,观察到的奖励并未与 BF16 出现实质分离。这一组合支持进一步测试,同时也让长期稳定性问题保持开放。

共享量化器才是真正的机制

Miles 将低精度 RL 视为一个分布式一致性问题,而不只是对更小数值的需求。

RL 技术栈的每一部分都可能独立量化张量。Megatron 负责训练,而 SGLang 和 FlashInfer 处理 rollout 操作。检查点转换和实时权重更新又引入了两次可能导致数值或布局出现偏差的机会。

即使是微小差异,也可能在反复的策略更新中累积。训练 worker 可能在优化一种量化表示,而 rollout worker 则从另一种表示中采样。这样一来,奖励描述的行为便来自优化器从未精确看到的策略。

Miles 通过位精确的量化器契约来解决这一问题。FlashInfer 测试会将其输出与 TransformerEngine 风格参考实现逐字节比较。测试输入包括随机数值、边界情况、全零张量和最大可表示数值。

团队还针对相关 FP4 量化路径禁用了 FlashInfer 的一项快速数学选项。近似数学可以适用于普通服务场景,因为微小差异不会反馈到未来权重中;但 RL 会让这些差异成为学习闭环的一部分。

MXFP8 还带来另一个布局问题。Blackwell Tensor Cores 要求微缩放块遵循矩阵的归约维度。前向和反向操作可能采用不同方向,因此一份量化副本未必总能正确服务于两条路径。

MXFP8 文档说明,TransformerEngine 会从原始高精度输入创建按行和按列的副本。这会消耗更多内存,但可避免对现有低精度副本进行反量化后再量化。

Miles 在其完整 MXFP8 路径中接受了这一内存成本。其高精度和反量化反向传播替代方案则避免保留第二份量化副本。这一选择需要在数值一致性、内存使用、反量化开销和矩阵乘法速度之间权衡。

NVFP4 引入了另一种一致性问题:在多个 token 之间共享一个激活缩放因子,会使某个 token 的量化数值依赖于其邻居。rollout 调度、序列长度或 batch 打包的变化,随后都可能改变策略表示。

Miles 会在线为每个 token 计算一个 FP32 激活缩放因子。FlashInfer 将这一计算融合进 rollout 激活量化内核中;同一操作会输出打包后的 FP4 激活、块缩放因子和 token 缩放因子。

训练和 rollout 还必须使用匹配的专家张量并行分区。否则,各系统在计算逐 token 缩放因子时看到的张量片段不同。相同公式无法从不同输入中产生相同策略。

SwiGLU 专家层还增加了一种特殊情况。其 gate 和 up 投影通常会进入一次融合矩阵乘法,尽管检查点可能将它们分开存储。Miles 会将每一对 gate 和 up 一起量化,使二者获得一致的较大缩放因子。

这些实现细节解释了为何 Miles Blackwell 工作横跨多个代码仓库。从保存的检查点到生成的 rollout,没有单一库能控制中间的每一种表示。精度契约必须经受住每次交接。

这项系统工作也让该配方区别于训练后量化。静态推理检查点可以校准一次并反复服务;强化学习会持续改变权重,因此每次实时导出实际上都会形成一次新的量化事件。

评估类似系统的团队需要为这些事件保留可追溯证据。内部工程知识库可以关联配置、内核版本、评估曲线和事故记录。当数个更新后出现数值回归时,这些记录就变得尤为重要。

每 Token NVFP4 对统一 BF16 默认方案施压

Miles Blackwell 方法要求团队为“全程使用 BF16”作出充分论证,同时仍将选择性 BF16 视为稳定性工具。

BF16 仍是更简单的基线方案。它提供更宽的数值范围、更少的量化约束,并且更容易在训练和 rollout 之间进行比较。其弱点在于,每个专家权重和激活值消耗的内存带宽都高于更窄格式所需的水平。

MoE 模型让这种权衡更加明显。它们包含大量专家参数,但每个 token 只会激活其中一部分。在 rollout 期间通过内存搬运专家权重,可能比原始算力更具限制性。

因此,Miles 首先瞄准专家路径。这一策略更像是财务预算,而非对四比特训练的意识形态承诺:它将精度投入最可能影响稳定性的张量,同时压缩规模最大的重复结构。

在每种低精度配置中,该实验都将模型最后 15% 的层保留为 BF16。Miles 表示,这一选择降低了训练与推理之间的不匹配,并改善了梯度稳定性。将早期层保留为 BF16 并未带来同样显著的改善。

共享专家同样维持了更高精度。与路由专家不同,它们会处理每个 token。因此,其量化误差会在每个 MoE 块中传播,而不只是沿着被选中的路由传播。

某些多头潜在注意力投影也获得了 BF16 例外处理。它们的收缩轴会随执行模式变化,而 MXFP8 使用一维缩放块。轴发生变化后,数值可能会在不同缩放尺度下被重新分组。

这些例外是该方案的核心,而非附带的收尾修补。若标题将其描述为完全 FP4 的模型,将会误述这项工作。Miles 构建的是细粒度控制机制,确保每项例外都能贯穿转换、训练、rollout 和在线更新。

这从两方面对传统 BF16 流水线形成压力。第一,奖励消融实验表明,Blackwell 上值得评估更窄的 rollout 路径。第二,该配置系统提供了另一种选择:不必为每一层指定同一种格式。

它也对围绕 Hopper 设计的早期 FP8 方案形成压力。DeepSeek-V3 对权重使用 128-by-128 块,对激活值使用 1-by-128 瓦片。Miles 认为该设计有效,但它无法以同样原生的方式使用 Blackwell 的微缩放硬件。

这一对比并不意味着旧方法已经过时。Hopper 集群仍被广泛部署,块缩放 FP8 也拥有更长的运行记录。Blackwell 原生格式还会为支持混合 GPU 世代的团队带来兼容性边界。

NVIDIA 的 TransformerEngine guide现已通过优化构建模块支持 FP8、MXFP8 和 NVFP4。然而,仅有框架支持并不能决定哪些层应使用何种格式。模型架构和工作负载形态仍是决定因素。

最直接的受益者是那些在 Blackwell 上运行大型 MoE 强化学习任务的组织。它们可以测试更快的 rollout,而无需立刻将所有反向传播操作迁移至低精度。这种分阶段路径降低了收集证据的成本。

较小团队则面临不同的计算。复现该配置需要八块 B200 GPU、多个协同库,以及谨慎保持配置一致性。对于中等规模而言,工程负担可能超过 rollout 节省的成本。

因此,主要竞争分界线在于选择性一致性与统一简洁性。Miles 提供了更多控制能力以及降低内存流量的路径。BF16 则减少了学习过程中可能悄然引入不匹配的接口数量。

Qwen3 消融实验未能证明什么

已发布的实验支持一套有前景的方案,但并未证明广泛的质量对等性或完整的四比特效率。

最直接的限制在于范围。Miles 测试了一个模型、一个面向数学的数据集、一种硬件配置和一种主要工作负载配置。在这些条件下紧密跟随的奖励曲线,无法预测其在编程、工具使用、对话或多智能体任务上的表现。

固定配置采用同步 RL,并将 rollout 和训练各分配到四块 GPU。异步系统可能会在数据生成与优化之间引入更大的策略滞后。这种滞后与量化不匹配的相互作用方式可能不同。

发布的奖励图也涵盖的是方案消融,而非经过完全调优的训练运行。Miles 明确如此描述。读者不应将该图解读为相对于优化 BF16 系统的基准胜利。

原始奖励可能掩盖行为变化。两项策略可能达到相近分数,却采用不同的推理模式、响应长度或失败模式。更有力的验证应包括留出评估、多个随机种子和任务特定的错误分析。

NVFP4 偶发的梯度尖峰仍是另一项担忧。高精度反向传播变体在报告运行中出现了尖峰。反量化反向传播减少了最大的尖峰,但并未消除它们。

这与围绕四比特训练的更广泛担忧一致。有关NVFP4 离群值的研究发现,特定架构组件中仍存在持续敏感性。该研究关注预训练,而非 Miles 的 RL 方案,但它强化了进行逐层监控的必要性。

当前的内存叙事也并不完整。尽管训练和 rollout 都通过低精度方案执行,Megatron 仍保留一份额外的 BF16 权重副本。这份副本限制了系统实际能够回收的模型内存。

Blackwell 原生低精度参数聚合仍在成熟过程中。Miles 指出,相关的 NVFP4 参数聚合路径尚不支持其一维 1-by-16 权重布局。能否移除 BF16 副本,部分取决于这套基础设施。

NVFP4 训练性能构成第二个尚未完成的领域。rollout 得到了改善,但在测试实现中训练变慢了。在 NVFP4 能够宣称更明确的端到端优势之前,待完成的融合 TransformerEngine 集成必须弥合这一差距。

在线权重迁移仍然复杂。服务后端通常会将权重填充、重排或 swizzle 成针对特定内核优化的布局。训练系统通常会维护另一种规范张量表示。

这些转换可能阻碍低延迟更新或远程直接内存访问。每种后端特定布局都会增加一个必须保持可验证性的步骤。如果每次策略更新都会触发昂贵的重新打包,快速内核的价值就十分有限。

硬件特异性带来商业风险。MXFP8 和 NVFP4 在 Blackwell 上获得原生加速,但许多组织仍在使用 Hopper 硬件。采用新方案可能会使基础设施支持分裂为多条精度路径。

已发布证据中也没有独立复现。结果来自设计并实现这些方案的团队。作为初步工程报告,这完全合适,但第三方复现将增强信心。

这些限制都不会抹去观察到的结果。它们界定了该结果的含义。Miles 已证明,在一项要求严苛的配置中,经过精心控制的低精度可以跟随 BF16 的奖励表现,同时缩短 rollout 时间。

下一项标准更为严苛。这些方案必须在更长时间的运行、多样任务、异步更新、更大模型和不同并行布局中保持稳定。它们还必须在所有框架开销纳入测量后保留其收益。

三个信号将决定该方案能否迁移

接下来三个信号是融合 NVFP4 训练、独立奖励复现,以及移除额外的 BF16 权重副本。

首先,关注待完成的 TransformerEngine 集成,它将实现融合的逐 token NVFP4 缩放。Miles 已在 FlashInfer 的 rollout 路径中使用融合缩放,但其测量的训练路径执行的是独立操作。该集成应能揭示 NVFP4 是否可以改善训练时间,而不仅是 rollout 时间。

更快的端到端结果将强化这一格式的论据。若训练持续变慢,其吸引力将局限于以 rollout 为主的工作负载。无论结果如何,都会厘清四比特计算在哪些场景能够产生实际价值。

其次,关注不同模型和任务上的独立复现。最有价值的测试应包括编程、长上下文推理、工具使用和异步 RL。多个随机种子将有助于区分格式行为与常规奖励方差。

如果这些工作负载上出现相似的奖励曲线,将支持 Miles 的一致性论点。反之,若特定层或任务出现分歧,则会指出 BF16 例外需要扩展的范围。无论结果如何,都将比单一的通用精度规则更有价值。

第三,关注 Megatron 是否能在支持该方案权重布局的同时移除额外的 BF16 权重副本。这一变化将显现目前被兼容性要求掩盖的内存收益。它还将检验低精度策略能否成为系统主要存储表示。

Miles Blackwell 工作已经跨越了一道重要的工程边界。MXFP8 和逐 token NVFP4 现在参与同一个连贯的 RL 循环,而不再只出现在孤立的推理或训练测试中。

更尖锐的问题已不再是 Blackwell 能否执行四比特和八比特操作,而是团队能否在每个接触这些数值的系统中保持同一套策略。在将 Qwen3 曲线视为普遍结果之前,应持续跟踪集成、复现和内存变化。

 
 

免费开始

一款本地优先的AI助手,具备个人知识管理功能

为了获得更好的人工智能体验,

remio 目前仅支持Windows 10+ (x64)M-Chip Mac

你的 AI 工作伙伴

remio 一起高效工作

规划、创作、交付

一站式完成

bottom of page