微软MAI-Base-1 的 MFU ，为什么看上去仅有DeepSeek-V3的一半 | 笔记

微软 MAI-Base-1 技术报告，在万亿参数模型级别，达到了非常罕见的透明度，披露了大量的技术细节，得到了研究人员的称赞。其中，有一个数据很有意思，它的最终 MFU 大约只有 20%。

MFU即模型算力利用率（Model FLOP Utilization），衡量的是训练过程中有多少硬件理论峰值算力真正转化成了模型主导计算。它不是普通的 GPU 利用率，也不是模型能力指标，而是模型架构、并行策略、通信、内核、内存管理和硬件拓扑共同作用后的系统效率指标。

（说明：在 GB200s 上训练的不同预训练配置中，模型浮点运算利用率（MFU） 和 估算的有效吞吐量（EG） 的演变过程。从 v2 开始，每一次模型变更都提升了 EG，但在部署优化之前，若沿用之前的配置运行，最初会导致 MFU 下降。总体而言，我们添加了 20 多项优化措施，使得每次预训练运行的 MFU 都超过了 20%。请注意，这里我们仅列出了对基础设施有显著影响的模型变更；它们并不是促成 EG 提升的唯一模型版本变更。来源：微软技术报告）

更难得的是，这份报告详细社披露了不同版本系统效率和模型效率的演进细节，说明了前沿模型训练的真实难度。

如果把它和一些公开的大模型训练效率相比，20%这个数字似乎不高。Google PaLM 540B 曾报告过 46% 左右的 MFU，英伟达的Megatron-LM 在高度优化的 H100 集群上也曾给出接近 47% 的 MFU。DeepSeek-V3 后续披露的 MFU 更高，causal 口径约 39%，non-causal 口径约 44%。相比之下，MAI-Base-1 在 GB200 这样先进硬件上只有 20% 到 22%，看起来似乎没有充分发挥硬件能力。

MAI-Base-1 的演进很能说明这一点。微软报告披露，它经历了 v1 到 v5 五个主要版本，其中 v2 开始在 GB200 NVL72 集群上训练。v2 使用 4096 颗 GPU，23B 激活参数，采用更深、更窄的设计，并选择 EP64、TP1，使专家 all-to-all 通信留在 NVL64 域内。这个版本初始 MFU 为 18%。随后微软通过 GPU直接远程内存访问（Direct RDMA） 改善通信与计算重叠，开发自定义块稀疏注意力后端，采用 ZeRO-2 减少梯度内存压力，并用 Triton 重写低效的专家编码内核，最终把 MFU 从 18% 提高到 22%。

v3 的整体架构变化不大，但从容量受限路由切换到无丢弃 （dropless） MoE 路由。这样可以消除专家容量填充，减少通信量和专家 GEMM 计算量，理论效率更好。但 dropless routing 又带来动态 token 计数、动态 张量形状和同步开销。微软通过将专家数量通信与其他运行时操作重叠，把同步点移到专用执行流，才让 v3 在获得路由效率收益的同时，维持了与 v2 相近的 MFU。

真正的挑战出现在 v4。这个版本把专家数从 192 增加到 512，路由从 top-4 扩展到 top-8，并引入 LatentMoE，同时训练规模从 4096 颗 GPU 扩展到 8192 颗 GPU。架构上，这意味着模型容量和稀疏效率提高了；系统上，却意味着专家 GEMM 变小、CPU 启动开销更显著、内核效率更敏感、all-to-all 通信更复杂。结果是，初始 MFU 从 22% 掉到约 16%。后来微软使用 FlashAttention4 确定性内核，并减少 CPU 开销、提高运行时批处理效率，才把 MFU 拉回约 20%。

v5 又进一步把激活参数从 23B 提高到 35B，总参数从 600B 提高到 1T。更大的模型带来更高的参数和激活内存压力。初始部署使用 ZeRO-3，但额外的参数 all-gather 让反向传播变成通信受限。微软随后通过激活值卸载降低 GPU 内存压力，重新回到 ZeRO-2，去掉 ZeRO-3 的参数全收集，恢复通信与计算的重叠，最终使 v5 维持约 20% 的 MFU。

（来源：微软技术报告）

所以，MAI-Base-1 的 20% 并不只是低利用率的结果，而是一个前沿 MoE 架构在不断变复杂后，系统工程努力把效率追回来的结果。它反映的是：理论效率提高，经常会带来系统效率下降。MoE 的优势是总参数巨大、每个 token 只激活部分专家，可以用较少激活 FLOPs 获得更强能力；但代价是路由、分发、合并、全到全（all-to-all） 通信、小 GEMM、动态同步和负载均衡都会增加。稠密模型虽然计算量大，但大矩阵乘多、形状规整，更容易打满硬件。MoE 理论上更省算力，系统上却更难跑满。

行业 MFU 的差异，主要受几个因素影响。第一是模型形态：稠密模型通常更容易获得高 MFU，复杂 MoE 更难。第二是 GPU 数量和网络拓扑：规模越大，通信和同步越复杂，MFU 越容易下降。第三是并行策略：张量并行、数据并行、专家并行、流水线并行、上下文并行如何组合，决定通信是在 NVLink 域内完成，还是跨机架、跨 IB 网络。第四是精度格式：FP8、BF16、FP16 会改变吞吐、内存和通信压力，但不同报告的分母口径不同，不能机械比较。第五是软件栈成熟度：FlashAttention、Triton内核、通信重叠、零冗余优化器（ZeRO）、激活检查点/卸载（activation checkpointing/offloading ）都会显著改变 MFU。

这也解释了为什么 DeepSeek-V3 的 MFU 看起来明显高于 MAI-Base-1。DeepSeek-V3 同样是大规模 MoE，但其 causal MFU 约 39%，non-causal MFU 约 44%，是非常突出的系统效率表现。它说明 DeepSeek 在模型架构、FP8 混合精度、MoE 路由、并行策略、通信拓扑和硬件适配上做了极致优化。尤其在无法获得最先进 GPU 的约束下，中国团队必须把 H800 这样的受限硬件榨到极致：减少通信浪费，压低内存开销，提高 kernel 效率，让模型结构尽量贴合硬件约束。这种约束驱动的系统优化，确实是 DeepSeek-V3 高 MFU 背后的重要原因之一。

DeepSeek-V3 更彻底的 H800 软硬件协同，很可能帮助它取得更高 MFU；而 MAI-Base-1 的 GB200 优化更多是平台适配和训练栈优化，不是同等意义上的硬件约束驱动式重构。

但也不能简单说 DeepSeek 的系统能力就是微软的两倍。MFU 口径、硬件平台、模型阶段和统计方式都不同。DeepSeek-V3 的数字基于 BF16 峰值，并区分 causal 与 non-causal 口径；MAI-Base-1 的数字则来自一个在 GB200 上连续演进的前沿实验模型，微软披露的是每次架构升级如何损失系统效率、又如何追回效率的过程。

前沿模型竞争不只是模型能力之争，也是系统效率之争。真正困难的不是让硬件忙起来，而是让模型架构、数据精度、通信拓扑、内核优化和训练策略一起工作，把有限算力尽可能多地转化为有效模型能力。

参考：

https://microsoft.ai/wp-content/uploads/2026/06/main_20260602_2.pdf