“相比會引起訓練報錯甚至中斷的數據，靜默數據錯誤會對訓練產生更嚴重的影響。”

作者丨包永剛

編輯丨林覺民

2025年12月12-13日，第八屆GAIR全球人工智能與機器人大會在深圳·博林天瑞喜來登酒店正式啟幕。

作為AI 產學研投界的標桿盛會，GAIR自2016年創辦以來，始終堅守“傳承+創新”內核，始終致力于連接技術前沿與產業實踐。

在人工智能逐步成為國家競爭核心變量的當下，算力正以前所未有的速度重塑技術路徑與產業結構。13日舉辦的「AI 算力新十年」專場聚焦智能體系的底層核心——算力，從架構演進、生態構建到產業化落地展開系統討論，試圖為未來十年的中國AI產業，厘清關鍵變量與發展方向。

王華在「AI算力新十年」論壇發表了主題為《基于國產GPU集群的大規模訓練實踐》的演講。

當海外頭部公司已經建設十萬卡、甚至二十萬卡規模的 GPU 集群，萬卡訓練正在從“前沿探索”轉變為大模型研發的基礎設施能力。模型參數規模進入萬億級之后，真正拉開差距的，已不再只是單卡性能，而是訓練周期能否被壓縮、系統是否長期穩定、工程效率能否支撐高頻迭代。

在這樣的背景下，萬卡訓練所面臨的挑戰也發生了根本變化。節點故障、性能抖動、通信與存儲瓶頸，在集群規模被放大之后都會成為常態問題，很多在千卡規模下可以容忍的風險，在萬卡場景中都會被大幅放大。

王華在演講中將結合摩爾線程在國產 GPU 萬卡級真實集群上的訓練實踐，系統拆解這一過程中遇到的關鍵難題，以及相應的工程解法。從并行策略選擇、訓練前的模擬與起飛檢查，到異步 Checkpoint、慢節點治理，再到靜默數據錯誤、Hang 以及 Inf/NaN 等穩定性問題的應對，他重點分享如何通過軟件棧、自動化與可觀測體系，把萬卡訓練從“能跑”推進到“可持續穩定地跑”。

這些經驗并非實驗室結論，而是來自真實生產環境中反復驗證后的工程積累，他希望摩爾線程的經驗能夠給想要做萬卡訓練的公司和機構一些借鑒。

以下是王華演講的精彩內容，雷峰網作了不改變原意的整理與編輯：

我是王華，負責摩爾線程的AI與云計算相關業務。今天主要和大家分享，我們在大規模訓練實踐中遇到的一些問題，以及對應的解決方案。

萬卡訓練我們已經討論和推進了一段時間。從去年開始到今年，我們陸續在真實集群上推進相關工作，中間確實遇到了大量問題。客觀來看，大規模訓練的技術挑戰很大，但在這個過程中，我們也逐步把問題解決，并積累了很多經驗，今天與大家分享。

01

萬卡訓練為何成為大模型的必要條件？

首先需要回答的是，為什么萬卡，甚至更大規模的集群已經成為必要條件？

從模型算力需求趨勢來看，主流模型，像DeepSeek或國產的萬億模型，基本都到了10的24次冪的量級。而國外一些大的模型，雖然沒有公開資料明確給出規格，但根據市面上流傳的消息，像比較大的Grok4、GPT-5或者比較新的Gemini3，基本都會達到10的25~26次冪的算力需求，這是非常巨大的算力需求。

在國內，當前已經開源的兩個萬億參數模型，一個是 Kimi K2，另一個是螞蟻的百靈，它們的總計算量主要由兩個因素決定：一是模型參數規模，對于 MoE 模型來說，核心是激活參數；二是訓練數據量。

Kimi K2 的計算量大約是3×10的24次冪FLOPs，激活參數規模是 32B，訓練數據是15T；百靈的計算量大約是6×10的24次冪FLOPs，激活參數規模是50B，訓練數據是20T。

如果以我們當前這一代訓練卡做一個估算，對于3×10的24次冪FLOPs的算力需求來說，大概需要半年的時間；如果擴大到5000卡，需要40天；到了萬卡，就只需要23天。對于百靈來說，因為算力翻了一倍，對應的時間也翻了一倍。對大模型來說，訓練時間非常關鍵，現在模型的競爭非常激烈，而且我們經常會有一些新模型算法的實驗，希望快速看到結果，所以訓練時間越短越好，最好不要超過一個月。

在海外，頭部公司已經建設了十萬卡甚至二十萬卡規模的集群，更大規模的集群也在規劃中了，這一方向在未來基本是確定性的趨勢。

02

如何把萬卡訓練集群「跑起來」？

圍繞大規模訓練，摩爾線程從底層到頂層系統性地研發了軟件棧。

在最底層，除了硬件，主要是集群調度的部分；向上是MUSA平臺，它與CUDA兼容性，使得我們可以快速地遷移和運行模型；再往上是訓練套件，針對摩爾線程的平臺，我們對 MegatronLM、DeepSpeed、PyTorch、TransformerEngine 等主流框架進行了適配和優化，并且全部開源，在GitHub上就可以找到；更高一層，是Model Studio以及一系列自動化訓練和部署工具。

在整個訓練過程中，我們關注的核心是訓練效率。

從流程上看，大規模訓練通常包括起飛檢查、訓練拉起（建立通信組、加載數據等）、正式訓練、故障定位和處理、以及故障處理后進入下一個周期。

過去在千卡規模下，集群可能連續運行半個月甚至一個月都不出問題。但萬卡集群，單個節點出問題的概率會顯著上升。早期即便是英偉達的萬卡集群，也曾出現幾小時就出一次錯誤的情況，我們在實踐中同樣經歷了這一階段。

因此，在萬卡訓練中，要提升整體效率，一方面必須提升正常訓練階段的性能，另一方面則要盡可能壓縮所有非訓練環節的時間，包括起飛檢查、checkpoint、故障定位與恢復。只有把這些環節的時間壓到足夠短，訓練效率才有實質性提升。

在性能優化層面，在起飛訓練前，需要確定并行策略和超參。一種方法是可以通過實際拉起訓練反復嘗試不同配置，但在萬卡規模下，每一次拉起試驗的成本都非常高。為了降低成本，我們采用了模擬的方式。

我們開發并開源的SimuMax軟件（可以在GitHub上找到），用于對不同模型和不同集群規模下的訓練性能進行估算，幫助判斷策略的合理性，并預估整體訓練時間。這一模擬基于一系列理論計算，可以幫助判斷當前訓練是否已經達到速度上限。如果達到，說明性能基本到位；如果沒有達到，則意味著仍然存在優化空間。圍繞這一目標，我們在SimuMax中做了很多特性的支持，包括不同模型結構、并行策略、優化技術等。

在萬卡集群中，起飛檢查是非常有用的特性。訓練啟動時，調度系統會分配資源，而節點的故障、亞健康狀態，以及系統層面的網絡或存儲異常，都會導致訓練無法啟動。

因此，我們在訓練啟動前，會先運行一組特定的benchmark（基準測試），對計算節點、網絡、存儲以及調度節點進行全面檢查。更重要的是，當檢測出問題后，起飛檢查會自動剔除異常節點，不再依賴人工介入，實現真正的無人值守訓練啟動。

Checkpoint 是另一個對效率影響很大的環節。如果采用同步寫的方式，checkpoint 往往需要數分鐘時間，這期間無法進行訓練，整個集群處于閑置狀態。

為此，我們實現了異步checkpoint：先將checkpoint寫入本地內存，后續再異步寫入存儲系統，將checkpoint時間壓縮到秒級。這么做對于幾千億參數規模的模型來說，checkpoint 寫入只需幾秒即可，訓練可以立即繼續執行。

在DP并行策略的情況，并不需要每個節點都寫checkpoint，我們對checkpoint進行切片，由不同節點負責不同分片，避免重復寫入和資源浪費。如果某個負責分片的節點發生故障，則會分配其他節點完成寫入任務。在讀取階段，如果某個節點掛掉，完全從后端存儲讀取會非常慢，我們采用了P2P機制，直接從其他節點的內存中加載checkpoint，將加載時間壓縮到半分鐘以內。有了這些優化，我們可以用非常高的頻率來做checkpoint，例如每十分鐘做一次。

03

萬卡訓練的挑戰：穩定性與可控性

慢節點檢測在大規模訓練中同樣非常關鍵，因為慢節點會拖慢整個集群的訓練速度。慢節點的發現通常有兩個一類是節點或卡本身處于亞健康狀態，在起飛檢查階段可以發現；另一類是在運行過程中出現亞健康狀態，需要運行時的檢查。

我們的解決方案是在訓練過程中引入了整體監控機制。訓練包含前向傳播和反向傳播，中間包括多個通信與計算步驟，我們會監控這些步驟的執行時間。計算和通信步驟的執行時間整體上符合統計分布規律，但不能拿絕對值去看每個步驟的快慢，不同的模型時間不一樣，我們通過聚類分析識別某些異常的慢節點，并自動剔除，整個過程完全自動化。

靜默數據錯誤也是一個棘手的問題。與引起訓練報錯甚至中斷的問題不同，靜默數據錯誤不會觸發異常，也不會中斷訓練，數值看起來“正常”，但實際上已經發生錯誤。造成靜默數錯誤有幾種原因，一種是計算硬件有一定的故障率，在一定概率下可能會算錯，就會造成靜默數據；另外，內存或顯存上的ECC特性對性能的影響比較大，在訓練的過程可能沒有開啟；在傳輸的過程中，也會出現糾錯碼失效的情況，導致誤碼沒有被發現。

對于輕微的數值錯誤，在萬億參數規模下往往會被其他數值平均掉，影響不明顯，可以繼續訓練。有一類是嚴重錯誤，可能導致Loss值或梯度出現一個非常大的偏差，Loss曲線會出現異常尖峰，頻繁出現時會影響模型精度。如果這種問題經常發生，會導致訓練精度的下降。還有一種致命錯誤，數值異常傳遞并最終導致出現NaN 或Inf，導致訓練中斷，只能回退到之前的checkpoint進行回訓。

因為非常難檢查，整個業界也還在探索，我們一方面在硬件驗收階段和訓練起飛檢查階段進行壓力測試，盡早識別“體質較弱”的卡；另一方面，壓測要多算子覆蓋，除了GEMM、Attention外，還會用一些執行較少的算子，因為不同算子會用到卡的不同部件，達到全面壓力測試的目的。同時，我們重點監控溫度、電壓等關鍵硬件指標，這些異常往往與錯誤高度相關。

Hang 問題同樣是萬卡訓練中較為棘手的一類問題。一旦發生Hang，往往整個集群都會被Hang住。如果所有節點都Hang住，定位源頭非常困難。我們通過分布式分析的方式，結合通信庫的日志，對所有參與節點的Hang原因進行記錄和比對，從而定位異常節點。

一般情況下，Hang通過重啟即可恢復，但如果某個節點經常Hang，會導致訓練非常不穩定，此時需要將該節點剔除。解決Hang問題后，整體訓練穩定性會有明顯提升。

Inf（Infinity） 和 NaN（Not a Number）問題是業內普遍存在的難點，其難點在于傳播性， Inf加減任何正常值，都會把正常值“吃掉”。因此，我們重點關注 Inf/NaN 最早出現的位置和時間點，定位那些頻繁觸發異常的算子或階段。

在集群洞察方面，我們會持續監控前向傳播和反向傳播中的計算和通信時間，慢節點檢測正是基于這些數據做的分析。同時，我們引入了更全面的 Profiling 能力，可以在不中斷訓練的情況下，一鍵啟動或停止性能分析器，按需采集訓練數據，并進行火焰圖等算子級分析，甚至可以將多個節點的數據匯聚后進行聯合分析。

最后，是統一的可觀測系統。我們的可觀測平臺覆蓋了大量系統與訓練指標，即便前面的機制遺漏了問題，也可以在這里通過指標異常檢測和聯合分析被捕獲。此前我們也通過這一平臺，快速定位過由于個別節點超溫導致的異常問題，并進一步追溯到散熱層面的原因。

以上是我們做的一部分工作，在過去的時間里，我們積累了很多經驗，很多都落到來我們產品里。現在我們也在萬卡級別的集群上做一些訓練工作，這方面的經驗以及積累的內容我們分享給大家，希望對于后續想做大規模訓練的公司和機構有一定的借鑒意義。

感謝大家。