作者｜包永剛

編輯｜林覺民

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

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

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

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

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

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

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

這些經(jīng)驗(yàn)并非實(shí)驗(yàn)室結(jié)論，而是來自真實(shí)生產(chǎn)環(huán)境中反復(fù)驗(yàn)證后的工程積累，他希望摩爾線程的經(jīng)驗(yàn)?zāi)軌蚪o想要做萬卡訓(xùn)練的公司和機(jī)構(gòu)一些借鑒。

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

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

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

萬卡訓(xùn)練為何成為大模型的必要條件？

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

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

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

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

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

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

如何把萬卡訓(xùn)練集群「跑起來」？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

因?yàn)榉浅ｋy檢查，整個(gè)業(yè)界也還在探索，我們一方面在硬件驗(yàn)收階段和訓(xùn)練起飛檢查階段進(jìn)行壓力測試，盡早識別“體質(zhì)較弱”的卡；另一方面，壓測要多算子覆蓋，除了GEMM、Attention外，還會(huì)用一些執(zhí)行較少的算子，因?yàn)椴煌阕訒?huì)用到卡的不同部件，達(dá)到全面壓力測試的目的。同時(shí)，我們重點(diǎn)監(jiān)控溫度、電壓等關(guān)鍵硬件指標(biāo)，這些異常往往與錯(cuò)誤高度相關(guān)。

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

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

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

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

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

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

感謝大家。

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