本文来自微信公众号： 未尽研究 ，作者：未尽研究，原文标题：《微软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