微軟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