你买了一台火力很猛的灶，却发现备菜、装盘和洗锅占了大半时间。只看炉火有多旺，并不能判断一顿饭多久上桌。FP4预训练也有类似问题：GPU里的Tensor Core——专门加速神经网络矩阵运算的计算单元——能用四比特浮点数快速计算，但训练还要缩放数值、转换格式、调整内存布局，并保存反向传播所需的中间状态。这些外围工作一多，理论上的加速就可能被吃掉。
Robert Hu的论文《Format-Aware Fusion for Fast FP4 Pretraining》研究的正是这笔“系统账”。它没有把FP4——用4个二进制位近似表示数值的一类浮点格式——当成换一种数据格式那么简单，而是把量化方式、缩放范围、数据布局和后续计算放到一起设计。以下性能与训练结果均为论文作者在单一研究中的报告，尚无独立复现。
四比特只是起点
预训练是模型从海量文本中学习通用语言规律的阶段。计算规模很大，因此每次矩阵运算节省一点时间，累积起来都可能可观。问题在于，FP4能表示的数值很有限。模型必须先给一组数配上“刻度”，再把数压进四比特格式。刻度选得不合适，小数值会丢失，大数值则可能被截断。
论文比较了三种缩放契约。MXFP4让每32个值共享一个尺度，尺度可在局部算完，但刻度只能按二的幂次变化，比较粗。全局NVFP4让每16个值使用更细的局部尺度，同时再参考整个张量的最大绝对值；精度安排更细，却必须等待一次全局汇总。CTA-local NVFP4则把外层缩放限制在CTA内部。CTA可以理解为GPU里协作处理一小块数据的线程组。这样，各块不必等整张量的最大值都算完，就能继续工作。
这说明，同样把数送进FP4 Tensor Core，准备工作的等待方式也可能完全不同。位数相同，不代表执行成本相同。
关键不是少算一步，而是少搬一次
论文提出format-aware fusion，即“格式感知融合”。算子融合原本就是把缩放、格式转换和计算并到一次执行里，像让同一个工位完成备料和装配，减少中间搬运。这里又多了一层要求：融合边界必须跟着FP4格式走。
每个生产端不仅要算出共享尺度，还要直接生成下一次矩阵乘法需要的数据排列，并保留反向传播所需的状态。MXFP4的尺度可在32个值内完成，因此适合局部融合；全局NVFP4仍需尽早启动整张量最大值的计算，并设法与其他工作重叠；CTA-local NVFP4则把依赖收进一个线程块，但要把行、列两个外层尺度一直带到矩阵计算结束。
为什么连“排列”也重要？一层模型训练时，同一份数据会参加三类矩阵运算：前向计算、输入梯度计算和权重梯度计算。它们需要的数据朝向不同。若先量化一次，再另外转置、重排或重新量化，就会多读写显存。论文让权重生产端只读取一次BF16数据，完成尺度计算和量化后，同时吐出两种物理布局。两份数据在内存中的顺序不同，但在纯格式路线中代表同一组量化后的权重。
BF16，即bfloat16，是一种常见的16位浮点格式。它精度高于FP4，但计算和存储成本也更高。论文并没有把训练全流程都改成FP4：所有主要自定义路线都保留BF16参数、FP32优化器状态和BF16输出投影，交叉熵损失则采用编译后的实现。
反向传播不能一刀切
论文还把反向传播中的两类误差分开处理。对输入梯度，它只在特定的行向表示上使用随机舍入——不总是机械地舍到最近值，而是按距离以一定概率选择相邻的可表示值，用来减少固定方向的舍入偏差。
对权重梯度，它采用Hadamard预处理。直观地说，如果一组数里有一个特别大的离群值，共享尺度会被它拉走，其余小数可能挤在过粗的刻度上。Hadamard变换用加减法把离群值的影响摊开，再进行量化。论文的MXFP4路线采用固定符号、每32个值一组的H32变换，而且只用于权重梯度；它没有把这一做法宣传成完整量化器“无偏”。
这种按操作数分别安排格式、舍入和预处理的做法，是论文的重要判断：FP4训练的基本单位不是某个四比特数据类型，而是一整条数值与执行路线。
快了多少，代价是什么
实验使用Llama-3-family 8B模型，序列长度为8,192，全局批量为512，最长训练到1600亿个token。token可理解为模型处理文本时使用的基本片段。
在同类加速器上的匹配探测中，作者报告BF16达到每张GPU每秒18.8K token，Transformer Engine的NVFP4路线达到27.6K，最快的自定义路线达到37.9K。也就是说，最快路线约为BF16的两倍，相比Transformer Engine NVFP4高约37%。不过，这比较的是完整端到端配置，各路线可采用各自选择的本地批量、激活检查点和分布式调度，并非只替换一个算子后的孤立对照。
更值得看的是速度与训练质量的交换。MXFP4配合输入梯度随机舍入和固定符号H32权重梯度预处理，达到37.2K token/s/GPU。作者按BF16峰值计算的模型FLOP利用率为86.3%。但训练结束时，它的原始训练损失比BF16基线高2.11%。损失更高通常意味着更差，而不是“提升2.11%”。
另一条Transformer Engine路线把最后四个Transformer block保留为BF16，速度为27.1K token/s/GPU，最终训练损失只比BF16高0.87%。它更接近基线，却放弃了相当一部分速度。这组结果把选择题摆得很清楚：最低损失和最高吞吐并不来自同一方案。
为什么值得关注
这项工作的价值，不只是把一个FP4内核做快。它提醒我们，芯片标称的峰值吞吐只是局部能力。真实训练速度还取决于数据何时能被量化、要搬几次、需不需要全局等待，以及反向传播保存了什么。
论文还发现，下游任务的方案排名与训练损失排名并不一致。材料没有给出具体任务、指标和数值，因此不能据此说某条FP4路线的下游效果优于BF16。但这一现象至少说明，单看训练损失也不足以选方案。缩放契约、被量化的操作数和实际执行路径会共同影响结果。
局限与未知
- 所有长训练方案各只有一条轨迹，没有估计不同随机种子带来的波动；性能和质量结论也尚无独立机构复现。
- 37.9K、37.2K token/s/GPU和86.3% MFU均为作者自报结果。论文比较的是特定模型、序列长度、批量和完整执行配置，不能直接外推到其他训练任务。
- 下游评测只披露了排名不一致，供稿材料未给出任务、指标和分数。现有信息不足以判断这些路线在实际能力上的差异。