作者｜包永剛

編輯｜林覺民

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

作為AI 產(chǎn)學研投界的標桿盛會，GAIR自2016年創(chuàng)辦以來，始終堅守“傳承+創(chuàng)新”內(nèi)核，始終致力于連接技術(shù)前沿與產(chǎn)業(yè)實踐。

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

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

當海外頭部公司已經(jīng)建設十萬卡、甚至二十萬卡規(guī)模的 GPU 集群，萬卡訓練正在從“前沿探索”轉(zhuǎn)變?yōu)榇竽Ｐ脱邪l(fā)的基礎設施能力。模型參數(shù)規(guī)模進入萬億級之后，真正拉開差距的，已不再只是單卡性能，而是訓練周期能否被壓縮、系統(tǒng)是否長期穩(wěn)定、工程效率能否支撐高頻迭代。

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

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

這些經(jīng)驗并非實驗室結(jié)論，而是來自真實生產(chǎn)環(huán)境中反復驗證后的工程積累，他希望摩爾線程的經(jīng)驗能夠給想要做萬卡訓練的公司和機構(gòu)一些借鑒。

以下是王華演講的精彩內(nèi)容，雷峰網(wǎng)(公眾號：雷峰網(wǎng))作了不改變原意的整理與編輯：

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

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

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

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

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

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

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

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

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

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

圍繞大規(guī)模訓練，摩爾線程從底層到頂層系統(tǒng)性地研發(fā)了軟件棧。

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

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

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

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

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

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

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

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

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

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

為此，我們實現(xiàn)了異步checkpoint：先將checkpoint寫入本地內(nèi)存，后續(xù)再異步寫入存儲系統(tǒng)，將checkpoint時間壓縮到秒級。這么做對于幾千億參數(shù)規(guī)模的模型來說，checkpoint 寫入只需幾秒即可，訓練可以立即繼續(xù)執(zhí)行。

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

萬卡訓練的挑戰(zhàn)：穩(wěn)定性與可控性

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

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

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

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

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

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

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

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

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

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

以上是我們做的一部分工作，在過去的時間里，我們積累了很多經(jīng)驗，很多都落到來我們產(chǎn)品里?，F(xiàn)在我們也在萬卡級別的集群上做一些訓練工作，這方面的經(jīng)驗以及積累的內(nèi)容我們分享給大家，希望對于后續(xù)想做大規(guī)模訓練的公司和機構(gòu)有一定的借鑒意義。

感謝大家。

雷峰網(wǎng)原創(chuàng)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。