指數級增長的模型算力需求，宣告了大智算集群作為訓練基礎設施的“剛需”時代已然來臨。? 面對動輒10^26 FLOPS級的計算量和長達數十天的萬卡訓練周期，單純擴充集群規模已非良策。破局的關鍵在于多管齊下：?深挖低精度訓練（尤其是FP8）帶來的巨大潛力以提升單卡效率；同時，構建高可靠、高可用的集群環境以保障大規模訓練的持續穩定運行?。這不僅關乎成本，更決定著大模型研發的節奏與成敗。

7月25日，在WAIC2025期間舉辦的摩爾線程技術分享日上，摩爾線程副總裁王華以《基于FP8的國產萬卡訓練》為主題，分享了在大規模集群上用FP8做訓練的創新及思考。

以下為王華的演講實錄精華：

1、大智算集群成為訓練的剛需

從行業模型發展的角度看，從2020年到2025年包括GPT、Llama、Grok等主流模型所需要的計算算力資源，需要的計算算力是非常大的。

整個趨勢在往上漲，在2020年的時候，還有許多并不需要很多算力的模型。舉例來說，2020年大模型算力TOP需求是1023flops。但是到2025年左右，現在Grok-4的算力需求更高，而Grok-3的算力需求在1026flops，差不多是1000倍的增長。驅動增長的核心點是參數加數據。由于我們追求更好的模型效果，參數量在不斷增大，數據也在不斷增大，這是考慮到Scaling Law這兩個數值增大會帶來模型效果的提升，最終帶來算力需求接近指數型增長。

再從一些熟知模型的實際算力需求，以及我們用不同規模的集群訓練它們所需要的時間分析。從算力角度來講，因為考慮到橫向校正，全部拿英偉達的H100集群來做計算，這里有千卡集群、五千卡集群和萬卡集群。考慮到不同的計算效率，DeepSeek算力需求大概在3.4×1024flops，1024的千卡集群計算需要的時間大概是97天，五千卡集群需要22天，萬卡集群是13天。

最近剛剛發布的Kimi K2是萬億參數模型，它的計算量是2.98×1024flops，計算的時間分別是85天、19天、11天。

而對巨無霸模型GPT-4，它的訓練量是1025flops，又高了一個數量級，我們看到的時間也是高了一個數量級，千卡需要602天，五千卡集群需要137天，萬卡集群需要80天。早期運行比較小的GPT-3等，參數并不少，但是數據量小，所以算得很快。

由上可以看到，數據和模型這兩個因素推動著整個訓練的算力需求在大幅度增長。

第二個是精度的變化，從開始的FP32到FP16，再到現在的FP8。精度下降帶來的好處是算力提升，精度每下降一半，算力會翻一倍，因為它需要的顯存、緩存速度都在下降。另外精度下降會導致模型效果下降，主要由于精度下降會導致一些數值的損失。

2、低精度訓練會帶來大規模訓練效率提升

如何在其中找到平衡點？回到Scaling Law，這里有兩個參數，模型的loss值我們希望越小越好，參數量、數據量越大，loss值就會越小。引入精度之后，我們得到一個新的Scaling Law，除了參數量、數據量還會有一個P（精度），隨著精度上升L更小，但是我們需要在P和N之間取一個平衡，變成在總的計算量固定的情況下，怎么樣合理配置這三個值。這一塊有一些研究，做了一系列的試驗去擬合這個工具，最后我們得到一個結果。我們拿FP32、FP16、FP8、FP6以及FP4來對比。我們看到FP32對應的是220M，精度下降一半這塊就會變成440M，整個loss值在FP6、FP8是一個最佳的"甜點區域"，到FP4反而會上升。我們從近期研究的結果來看，引入精度這個Scaling Law之后，比較合理的值是在FP8，所以我們現在用FP16做訓練，用FP8替換之后有了很大的提升空間。

但是用低精度做訓練也遇到了很多的挑戰。這是低精度的表達范圍，當中包含我們取的最大值、最小值，另外在每一個區間上，它表達的尾數位數少，整體的數量會少。這兩個限制會導致的問題，第一個是我們的取值范圍小，它就容易上溢和下溢，上溢是梯度爆炸的錯誤，下溢會導致數據丟失，從而梯度消失。我們在整個訓練過程當中會有不同的操作，不同操作對精度的需求和敏感度不同，我們可以做一個大致的分類。這里面按照精度不敏感到中度敏感到高度敏感進行排列，不敏感的部分比如說矩陣乘，矩陣乘一般兩個數直接相乘，操作次數不會太多，它的精度敏感度相對比較低。像累加/歸約類，會把很多數放在一起操作，精度要求是中等的，非線型函數則可能是指數級增長，對精度要求是高的。我們針對不同的精度需求，有一個比較直白的做法就是混合精度訓練，在FP32、FP16的時代就已經采用這種技術了，FP8引入之后我們也可以用類似的方式，對非敏感的部分采用FP8去做計算。

FP8出現之后，FP8技術有了很大的發展，有很多技術點支持FP8的訓練。比如說硬件上就是Tensor Core，新的Tensor Core都是支持FP8的，比如說英偉達的，在輸入上可以用FP8輸入，輸出是高精度矩陣。

另外是權重Backup，我們把權重更新部分用FP32去表達。而Tensor Scaling，在縮放的時候，先把它縮放到一個合理的值。在縮放因子的選擇上，包括選擇的時間點上和顆粒度上都會有不同的方式方法，有很多相關的研究。

FP8走進現實很重要的一個點就是，我們使用FP8技術真的可以訓出效果很好的模型。DeepSeek在訓練過程當中，不同的操作對精度的要求不一樣。DeepSeek在訓練當中以矩陣乘操作，DeepSeek前向和反向傳播的3次矩陣乘都使用了FP8去做，還有激活值的緩存和傳輸也使用 FP8來做。但是對于一些精度相對來說比較敏感的部分，DeepSeek里面還是繼續用高精度來運算。但是從整個訓練過程來講，已經帶來很大的收益，因為這里面很大一部分計算量是矩陣乘帶來的。

摩爾線程對 FP8 的訓練提供了軟硬件全棧的完整支持。硬件方面，我們的GPU是一個全功能GPU，算力精度上支持從FP64、FP32到FP8的全精度算力。

從軟件棧上講，我們有三個開源框架，一個是Torch-MUSA，這是我們在Torch棧上構建的MUSA底層插件，可以在MUSA上把整個Torch跑起來。這里面我們已經實現了對FP8數據類型的完整支持。

二是MT-MegatronLM，這里面支持FP8混合并行訓練。框架，支持Dense、多模態、MoE 模型的高效訓練，支持FP8混合精度訓練、高性能muDNN庫和MCCL通信庫。

三是MT-TransformerEngine。主要用于Transformer的高效訓練和推理優化，支持FP8混合精度訓練，通過算子融合、并行加速等技術，提升訓練和推理的效率。

經過這些軟件棧，成功復現了DeepSeek-V3整個訓練過程，因為大家知道DeepSeek最開始并沒有開源，即便開源只是開一部分。我們是在這個軟件棧基礎上，實現了它一系列的相關技術，比如說MT FlashMLA和DeepGEMM庫等等。我們是行業里到率先能復現DeepSeek滿血版訓練的廠商，其他家都在嘗試做推理的復現。

我們在FP8訓練上也做了很多的探索和實驗。主要做了兩個探索性的工作，第一個是在scaling factor的選擇上面，像我們有不同顆粒度的Per-Tensor或者是Per-Block。根據我們的觀察，像AMX這個值，如果說在Per-Tensor這個維度上，它的最小值在200左右，它并不是特別小。我們最大值大概是在2000左右，所以我們做scaling factor的時候，用最大值去除的話，不會把這個值除的非常小，所以我們在Tensor這個維度上，可以Per-Tensor的一個scaling factor。但是對Per-Block，它的最小值非常小是0，除的話容易把結果除得很大，所以在這個維度上，我們就會用JIT動態的scaling factor的選擇。

另外一個是outlier的影響，因為FP8取值范圍比較小，所以出現一些異常值的時候，一旦數值增大，容易把FP8取值范圍上限給超了，從而導致訓練不穩定。一個比較有效的技術就是Smooth SwiGLU，也是在我們的框架里面復現了本身帶來的問題，用Smooth SwiGLU怎么去降低這個問題，核心點我們在量化之后，先去乘一個縮放因子，第二次量化之后再把這個縮放因子再給恢復回來，去降低FP8階段的時候，出現上溢的這種風險。

在集群訓練方面的技術考慮點。首先在大規模訓練上，一些數值估算的東西，我們不可能所有東西都靠實驗性來做，因為資源消耗太大，很多工作都是通過模擬器方式來做的。我們有Simumax這樣一個軟件，這個已經開源了，大家可以在GitHub上下載到。

它解決的問題一個是理論與仿真結合去估算我們一系列感興趣的開銷，我們可以支持各種不同的并行策略，優化策略等等。在一些主流模型上都可以用理論分析以及各種策略的設置去得出它大概的資源消耗。一方面可以估算我們需要的資源，如果說我們出現一些性能偏差，我們比較容易找到這其中出現的性能問題。

做法是我們會在計算圖上去根據SPEC整個計算過程，根據經驗數據或者是理論分析的數據去跑一下計算圖，去收集各種各樣的開銷，匯總起來得到最后的結果，這需要我們對整個計算圖的各種模擬做到比較全的覆蓋。

3、集群可靠性對大規模訓練至關重要

大規模集群訓練的可靠性非常重要，因為集群規模大了之后，單機故障率不會那么高。但是我們一個節點出問題，這個訓練就掛掉了，數量大了之后，這將是很恐怖的故障率。我們做了很多可靠性相關的工作。

首先，我們的訓練生命周期的管理，包括它的監控、故障檢測，我們引入了大規模訓練的起飛檢查、飛行檢查和落地檢查。起飛檢查就是訓練開始之前我們它用到的硬件做全面檢查，不是一個單點的檢查，我們會做包括網絡的，甚至會跑一些小負載看整個棧是不是有問題。另外在檢查過程當中，一旦發現有異常節點我們會自動給踢掉，這樣會降低人工排查帶來的時間成本和人力成本。

在飛行檢查過程與訓練過程當中，可能會出現hang、異常退出、訓練亞健康等問題，我們要檢測到這些問題，然后做相應的處理。最后是落地檢查，在過程中出現亞健康或者是故障的情況，我們在訓練停掉的時候，能夠找到故障點，以及自動抓取故障的上下文，然后做分析。

在同步訓練模式下，一個節點變慢之后，整個訓練會拖慢，那我們怎么抓到這些慢節點，避免我們整個訓練的過程會變慢？其實慢節點是我們遇到一個比較常見的問題，通過解決慢節點，我們經常會有10%、20%的性能提升。這一塊的解決包括兩方面檢查，第一是在起飛檢察階段，我們會做一些小工作負載的測試，我們找到它明顯比其他節點慢的節點；二是在訓練過程當中，如果說它的通信執行時間和其他節點不一樣，我們就把這樣的節點挑出來。

容錯訓練方面，在大規模集訓上，尤其到萬卡、十萬卡這樣的規模上，完全靠現有的方式是不可行的，到這種級別，我們的模式就是發現一個節點之后，這個節點可能是一個DP，如果說出了故障之后，我們就把這個DP從通信組上摘出去，這個通信組可以繼續工作。對于大DP，我去摘一個DP成本很高，還可以在一個DP里去摘一個節點，這種情況下對這一部分參數的計算或者更新，我們會把它Skip，但對這種大規模的海量數據來說，這么一點點的數據對它整體性能影響并不大，但是我們省掉了停掉整個集群重新拉起的開銷。

最后做一個總結，我的分享主要是三點：

第一，算力需求的發展趨勢，使得大智算集群成為訓練的剛需。

第二，低精度的訓練，會帶來大規模訓練效率的提升。

第三，集群的可靠性對大規模訓練至關重要。

大家可以關注一下今年10月摩爾線程MUSA開發者大會，我們也會在MUSA開發者大會上為大家帶來更多技術上的探索。