01 AI 訓練穩定性的演進歷程

2012 年 ImageNet 競賽中 AlexNet 的橫空出世，開啓了現代 AI 發展的新紀元。彼時我們不會想到，十年後支撐 AI 訓練的 GPU 集羣會從研究室裏的幾台服務器，發展成需要專門供電系統的萬卡級計算矩陣。在這個算力爆發式增長的過程中，訓練系統的穩定性管理正經歷着從「簡單運維」到「精密工程」的深刻變革。

1.1 標早期的小模型時代：手動運維的黃金年代

2022 年之前的 AI 訓練，更像是手工作坊式的精雕細琢。大多數訓練任務只需十幾塊 GPU，利用 PyTorch 或 TensorFlow 的數據並行功能就能輕鬆應對。記得那時算法工程師們有個共識：如果訓練遇到問題，重啓往往比排查更高效。

當時我們構建的監控系統就像汽車儀表盤，只能顯示最基本的任務狀態。當訓練意外中斷時，工程師們會像偵探一樣翻查日誌 —— 如果發現是 GPU 報錯，就聯繫運維同事。運維人員則帶着「NVIDIA三件套」（nvidia-smi、dcgm、nsys）到機房巡檢，像老中醫把脈般通過温度、功耗等指標判斷硬件狀態。這種工作模式雖簡單，但應對數十卡規模的集羣還算遊刃有餘。

1.2 大模型風暴：從量變到質變的衝擊

ChatGPT 的登場如同打開潘多拉魔盒，將 AI 訓練帶入新的紀元。當我們開始部署千卡/萬卡集羣時，才發現原有的運維體系就像用小漁網捕鯨魚 —— 完全無法匹配新需求。

讓我們通過百度百舸經歷過的一個真實案例來深入理解這個問題：

2024 年初，百度百舸幫助一家 AIGC 創業公司迅速將其訓練規模從百卡擴展到千卡級別。然而在訓練數天後的某個週末凌晨，訓練進程意外發生了 hang 死。由於當時缺乏有效的故障感知和容錯機制，直到第二天算法工程師發現任務超時退出時，已經耽誤了數小時寶貴的訓練時間。更糟糕的是，任務日誌中除了簡單的 timeout 報錯外毫無線索，平台監控也顯示所有訓練節點狀態正常。

着急恢復訓練的算法工程師沒有立即上報問題，而是選擇直接重新提交任務。但不幸的是，新任務運行數小時後再次出現相同的超時退出。這時他們才不得不尋求技術支持，但值班工程師面對這種任務 hang 死的問題也缺乏診斷經驗，只能通過二分法慢慢定位。最終發現是某個節點的靜默故障（SDC）導致了訓練進程假死。等問題得到解決時，距離首次故障已經過去將近 30 小時，這意味着損失了價值巨大的千卡算力資源。

02 百度百舸集羣訓練穩定性全景圖

站在現在的時間點回望，AI 訓練穩定性已從輔助功能演變為核心基礎設施。就像現代建築中的抗震結構，它雖不直接參與空間構成，卻是萬丈高樓得以屹立的關鍵。當行業向着數萬卡集羣邁進時，這套隱形護甲的質量，將直接決定 AI 進化的速度與邊界。

在 2024 年百度百舸對訓練過程的生命週期進行了更細緻的拆分，提出了「無效訓練時間」這一關鍵指標，並致力於將其最小化。具體來説：

任務無效訓練時間 = 故障中斷次數 × 任務故障恢復時長 + 任務常態寫 Ckpt 總時長

其中，任務故障恢復時長 = 故障感知召回耗時（自動/人工定位）+ 任務調度耗時 + 任務初始化耗時 + 任務重算時長。

通過這個公式可以看出，要降低無效訓練時間，需要「圍繞基礎設施穩定性」、「任務容錯」兩個維度來系統展開，重點解決三個方面的問題：

• 提高基礎設施的交付質量。
• 提高任務故障容錯的召回率、準確率和時效性。
• 優化 checkpoint 機制，減少保存時間和恢復時的重算時間。

經過容錯架構的整體變革，百度百舸形成了從 「任務負載 — 框架 — 通信 — 基礎架構」全鏈路的自動異常感知、診斷、恢復能力，可覆蓋 90%+ 的訓練異常場景，時效性最快可以實現秒級異常感知、分鐘級定位，以及平均 3 分鐘的故障自愈能力。

03 基礎設施交付質量保障

基礎設施的交付質量保障是穩定性的基礎。

CPU 時代，機器的交付前可能僅會跑一些常規的 CPU 計算、網絡的壓力測試，並不會從業務視角去評估基礎架構，機器交付後硬件異常的故障頻率相對較少。有硬件故障時，通常走工單系統人工換機用户相對是可接受的。

而 GPU 時代，AI Infra 的交付則需要考慮 CPU、GPU、RDMA 網絡、存儲，甚至機房的功率、温度等各方面因素，遺漏任何一個環節都會成為後續穩定性的隱患。在交付給客户後，機器也可能會由於長時間的高負載運行頻繁出現硬件故障，而 GPU 機器的高昂成本，使客户對節點故障感知、換機的時效性提出了非常高的要求。

因此百度百舸對 GPU 機器交付前及交付後的穩定性質量進行了系統性管理：

• 交付前，百度百舸會對機器進行 200 多項指標檢測，然後進行 48 小時烤機，以及 NCCL-Test 的機內、機間的大環、同號卡通信性能基準測試，端到端的大模型訓練、推理性能基準測試。
• 交付後，需要能夠實時的感知節點故障及定期巡檢，並具備分級處理的自愈能力，例如 Error 級別的故障實現自動排水、重啓，Fault 級別故障實現自動換機。

04 任務容錯的準召率保障

任務層面穩定性最核心的就是做好容錯，能夠讓業務在無論遇到何種故障時都能快速恢復。

那麼，首要的工作就是我們能夠準確的識別出異常，然後對故障進行診斷定位，最後能夠自動化的從異常中恢復。

因此，任務容錯需要能夠從端側（即每個訓練 worker）探測到進程與環境的各類異常，同時有個中心服務（Master）從任務全局的視角去診斷、定位異常，最終做出相應的決策來使任務能夠快速從異常中恢復。

任務容錯最重要的就是提升故障的召回率與準確率，即如何能夠儘可能的準確識別、定位所有故障。我們將故障分類兩類：顯式故障和隱式故障。

• 顯式的故障通常比較容易召回，我們將實踐積累的各種進程異常狀態及各類報錯pattern形成專家知識庫，再結合硬件感知服務（HAS Agent）的硬件全鏈路 10 秒級監控能力，可以實現顯式故障的召回率達到 95%+。
• 隱式的異常則往往很難輕易的識別，例如訓練進程 hang、慢節點就是典型的隱式故障，需要豐富的經驗積累才能準確的識別出異常。

下面我們就以最典型的隱式故障場景 —— 訓練進程 hang 死為例，來看下如何能夠做好 hang 自動感知、診斷。

4.1 訓練hang 的自動感知

訓練任務發⽣ hang 之後，絕⼤多數情況都會以 timeout 的⽅式報錯並退出進程，最常⻅的就是在通信過程中如果發⽣ hang，NCCL 的 watchdog 會中斷通信，並有報如下 timeout 報錯，然後再由 pytorch 的 torchrun 進程感知並中斷訓練過程。

[E ProcessGroupNCCL.cpp:828] [Rank 1] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=15173, OpType=ALLREDUCE, Timeout(ms)=1800000) ran for 1802710 milliseconds before timing out.
[E ProcessGroupNCCL.cpp:828] [Rank 0] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=15173, OpType=ALLREDUCE, Timeout(ms)=1800000) ran for 1802713 milliseconds before timing out.

Pytorch 默認為 10 分鐘 NCCL 通信超時，而 Megatron-LM 為 30 分鐘。在萬卡規模訓練場景中，意味着一萬張卡要至少浪費 30 分鐘才能被發現。這個時效性是不可接受的。而且當 30 分鐘超時後程序會立馬退出，很難有機會進行下一步定位，需要一些時效性更高的感知機制，並且在程序退出前獲取一些有效信息供後續診斷分析。

很多公司、實驗室在面對 hang 的問題時，會在採用框架層插樁的方式來 trace 訓練進程，這種方式通常是比較直接且準確的，但是有比較強的侵入性，而且可能還會有一些性能開銷。對於雲廠商來説，需要尋找對用户更透明、更無損的方式來感知、定位 hang 異常。

如何感知訓練 hang，以百度百舸的產品設計思路為例，我們可以從以下幾個方向去思考：

1. 訓練進程 hang 的最直觀表現是什麼？

   人工判斷一個任務是否 hang 了，最直接的方式就是看是否所有 worker 的任務日誌一段時間內都不輸出日誌了，所以 hang 自動感知的第一種方法就是採集所有 worker 的日誌，並判斷所有 worker 日誌中最後一行日誌是否為 x 分鐘前的（x 小於 Pytorch 的通信超時時間，例如 8 分鐘），如果是則基本可以判定為 hang。

2. 任務 hang 時進程有什麼樣的表現？

   任務 hang 時，可能進程的調用棧都不在發生變化，進程的調用棧可以通過 py-spy/pystack 等工具進行探測，所以我們可以用此類工具對所有訓練任務進行一個定時採樣，當採集 n 個樣本所有進程棧都沒有變化時，可以判定一次 hang，這種方式通常可以將 hang 感知縮小至 3～5 分鐘。

3. 任務 hang 時監控指標有哪些變化？

   訓練進程中的 CUDA 算子計算、集合通信操作通常都是在毫秒，甚至微秒、納秒內完成的，當任務在正常迭代過程中發生了 hang，我們常遇到的情況是所有 rank 的 RDMA 流量會降到 0，而 GPU 的利用率為 100%、SM 利用率則在很低的水位。如果持續幾分鐘都是這種狀態時，意味着訓練進程已經計算完成，在等着集合通信完成，這種情況下基本可以判定為 hang。

4. 是否能在通信庫中更快的感知通信 hang？

   通常單次集合通信操作都是在 ms 級的，如果一次操作在 30 秒鐘都沒有完成，那就可以判定為通信 hang 死了。百度自研的 BCCL 集合通信庫層可以對每一次集合通信操作都進行打點，來實現通信 hang 感知。

上述幾種方法，我們可以分別實現一種探針，來抓取相應的特徵到中心端 master 組件進行下一步診斷和容錯決策。

百度集合通信庫 BCCL是百度智能雲推出的一款面向大模型訓練場景優化的集合通信庫。

BCCL 基於開源的 NCCL 進行了功能擴展和能力增強，針對大模型訓練場景在可觀測性、故障診斷、穩定性等方面進行優化，進一步提升集合通信庫的可運維能力。相比 NCCL，BCCL 的關鍵特性如下：

* 可觀測性：新增集合通信帶寬實時統計能力；

* 故障診斷：新增集合通信 hang 時的故障診斷能力；

* 穩定性：增強網絡穩定性和故障容錯能力；

* 性能優化：提升大模型訓練主流 GPU 芯片的集合通信性能。

4.2 訓練 hang 的自動診斷

有了以上感知手段，我們需要進一步的診斷、定位，來確定是否真的發生了 hang，以及 hang 的具體位置。具體的來講，master 收集到各類 agent 的數據後，會做一些綜合分析：

1. 是否真的發生了 hang？

   感知階段各種探針只能探測到 hang 的一種特徵，並沒有辦法 100% 的確定是否真的 hang 住了，事實上不侵入用户進程是很難做到 100% 確定 hang 的。因此，為了提高 hang 的判定準確率，我們需要將各種特種綜合起來判斷，探針上報到 master 後，由一個 hang 診斷模塊，按照一個時間窗口（例如 5 分鐘），進行綜合判斷。如果在時間窗口內日誌、監控、進程調用棧、通信庫中有 2 條以上都處於不處於活躍狀態時，我們判斷任務真正發生了 hang。

2. hang 的具體發生的位置？

   確定任務 hang 了之後，我們需要找到 hang 所在的節點來對它進行隔離。因此診斷模塊需要在探針上報的數據中進一步找尋特徵，來確定 hang 發生的位置：

3. BCCL Tracehang 診斷：在感知階段，BCCL 可以在通信庫層面對所有 rank 的通信進行打點。如果有節點一直未完成通信則是發生了 hang。但是此節點可能並非真正發生 hang 的源頭，有可能是在等待其他節點完成通信。診斷模塊可以根據 BCCL 打印的通信組信息，進行交叉判斷，如果某個節點在多個通信組中都未完成通信，那這個節點就是 hang 的源頭。
4. RDMA/GPU 指標診斷：上文中我們提到，通信階段發生 hang 之後，所有 rank 的 RDMA 流量都會降到 0，而同時絕大部分 rank 的 GPU 利用率持續為 100%，只有某一兩個 rank 的 GPU 利用率為 0，那這個 rank 很有可能是 hang 的源頭。
5. 進程調用棧診斷：進程調用棧也可以作為一個 hang 源頭診斷的重要參考。當發生 hang 之後，絕大部分的 rank 都要麼處於 barrier 等待狀態，要麼處於通信等待階段。只有個別的 rank 卡在其他函數上，那麼通過對比分析，可以將調用棧與其他 rank 不同的節點初步判定為 hang 的源頭。
6. 綜合診斷：上面 3 種特徵為我們提供了 hang 的診斷依據，將 3 者關聯起來分析後，我們基本上可以比較準確的確定一個具體的 hang 的源頭，再結合硬件故障感知的相關信息可以進一步明確根因。

4.3 基於 eBPF 的隱式故障感知與診斷

在複雜的大規模分佈式訓練場景中，傳統用户態監控往往難以捕獲系統內核層面的異常事件。

百度百舸基於 eBPF（Extended Berkeley Packet Filter）技術的隱式故障感知體系，能夠在不侵入用户代碼的前提下，對訓練進程的系統調用、網絡通信、CPU 調度等內核態行為以及訓練框架關鍵函數運行時間建立立體觀測能力。

eBPF 探針部署原理通過在內核關鍵路徑注入輕量級探針，實現低開銷的系統級行為捕獲。針對訓練場景特點，主要聚焦 4 類事件跟蹤：

• 訓練關鍵函數跟蹤：微秒級跟蹤訓練過程中，前向計算、反向計算、集合通信操作等關鍵函數執行耗時，記錄函數間調用關係。
• 進程調度阻塞跟蹤：掛鈎 sched\_switch 事件，檢測進程在 TASK\_UNINTERRUPTIBLE 狀態持續時間，當單次持續超過閾值（如 5 秒）時捕獲調用棧。
• CUDA 運行時 API 監控：通過 uprobe 在 libcuda.so 等關鍵庫注入探針，記錄 CUDA API 調用耗時分佈。
• RDMA Verbs 級通信監控：在 ibv\_post\_send/ibv\_poll\_cq 等核心通信接口設置觀測點，統計通信時延分佈。

結合上面 4 類事件，完成以下 2 類數據分析：

• 單體異常探測基線與實時數據對比。
• 羣體一致性檢測。採用卡間對比算法，當某一 rank 的以下指標偏離集羣中位數超過閾值時判定異常，包括系統調用頻率、進程就緒隊列等待時長、NVLink/RDMA 帶寬利用率等。

基於以上所述方法，百度百舸針對以下 2 類典型的隱式故障進行診斷：

• 訓練 hang 根因定位。通過關聯 eBPF 捕獲的多維度數據進行如下操作：
• 當檢測到某 rank 的 GPU  Kernel 執行出現分鐘級空跑（SM 利用率 > 70% 但無有效計算輸出）。
• 同時伴隨該節點 RDMA QP 狀態停滯（ibv\_poll\_cq 無新完成事件）。
• 內核調度器顯示進程處於 D 狀態超過閾值。
• 性能抖動溯源。基於 eBPF 火焰圖、時序圖等進行分析：
• 抓取發生性能下降時段的 CPU on-cpu/off-cpu 堆棧。
• 對比正常時段數據，識別出異常的鎖競爭（futex 調用佔比上升）。
• 結合 NUMA 內存訪問統計，定位跨 NUMA 內存訪問導致的 TLB 顛簸問題。

此類技術已在百度百舸的萬卡規模訓練集羣中驗證，相比單純依賴應用層監控的方案，將隱式故障的平均檢測時間從分鐘級縮短至秒級，診斷準確率提升 40% 以上。

通過與既有硬件故障感知服務、BCCL 通信庫監測體系聯動，百度百舸形成了覆蓋從硬件到系統內核再到應用層的立體化診斷能力。

05 任務故障恢復的時效性保障

故障恢復的時效性也是容錯能力的一個重要指標，反映的是任務從故障發生到再次重新進入訓練迭代的時間，恢復效率越高則算力浪費越少。影響到任務恢復效率有 2 個重要因素，一是任務平均中斷時間，二是訓練重算時間。

5.1 多級重啓策略減少故障中斷時間

任務發生異常後，上文中我們提到需要經過故障自動感知、診斷和自愈等 3 個環節，那麼減少中斷時間的核心思想，就是儘可能的縮短這 3 個環節的時間，通過多維度的感知、診斷手段可以將故障發現、定位的時效性降低至分鐘級甚至秒級。自愈則需要能夠根據不同的診斷結果進行分級恢復和故障屏蔽的能力：

• 單點顯式故障：重調度異常節點（replace），對節點進行集羣級別屏蔽。
• 單點隱式故障：重調度異常節點，對節點進行任務級別屏蔽。
• 非單點故障：原地重啓嘗試恢復（restart），無法恢復時重新調度所有節點（resubmit）。

通過多級重啓策略，儘可能避免單點故障引發全部節點的重新調度。在萬卡級別的訓練場景中，百度百舸將大部分訓練異常場景恢復時間從過去的 30min 縮短至現在的 30s 內，成功率到 95%+。

5.2 觸發式 checkpoint 減少訓練重算時間

除了上述的多級任務重啓策略外，另一個提高任務故障恢復效率的重要手段就是減少訓練重算時間。在探討具體技術方案之前，我們先來看看目前主流的 checkpoint 保存策略。

傳統的 checkpoint 保存通常採用固定間隔策略，比如每隔 N 個 step 或每隔 T 小時保存一次，這種方式實現簡單但缺乏靈活性，可能會產生大量冗餘存儲，同時在故障發生時可能會損失較多訓練進度。

而觸發式 checkpoint 則是一種更智能的方案，它根據特定條件或異常事件（如故障、顯存不足、顯式指令等）動態觸發模型狀態保存。其核心目標是通過靈活的控制保存時機，減少不必要的存儲開銷和訓練中斷時間，從而降低因頻繁或冗餘保存導致的重算時間浪費。

隨着大模型訓練規模的擴大，還有一種更激進的「零重複 checkpoint」技術，即在每個訓練 step 都保存一次 checkpoint。這種方案的優勢在於可以將重算時間降到最低，確保故障發生時能夠從最近的 step 恢復，幾乎不會損失訓練進度。但其顯著的缺點是存儲開銷巨大，即使採用增量式存儲，仍然需要相當大的存儲空間和 I/O 帶寬。此外，頻繁的 checkpoint 操作也可能影響訓練性能。

相比之下，觸發式 checkpoint 走的是一條平衡之路。我們來看下它實現的幾個核心要點：

• 集成容錯：訓練進程集成容錯的故障感知與定位機制，在進程退出前自動觸發保存。這種主動感知機制能夠在故障發生的第一時間保存訓練狀態，最大限度減少進度損失。
• 高速轉儲：異步 checkpoint 保存機制會將 checkpoint 暫存到共享內存中，再由外部程序轉儲至磁盤。當某個節點異常時，容錯組件會拉起新節點，並在新節點訓練進程啓動前，利用 RDMA 技術實現 checkpoint 快速從故障節點轉儲至新節點，這大大減少了從遠程存儲拉取 checkpoint 的時間。
• 冗餘備份：觸發式 checkpoint 也並非完美無缺，例如在節點發生內核 crash 等嚴重故障時，可能無法觸發自動保存。因此，需要通過定期的冗餘備份機制進行兜底，確保 checkpoint 不會完全丟失。

實踐表明，當觸發式 checkpoint 與異步、增量式的 checkpoint 機制結合使用時，可以在保證數據安全性的同時，顯著提高 checkpoint 保存效率，減少訓練重算時間。

相比零重複 checkpoint 的重型方案，觸發式 checkpoint 提供了一個更實用的折中方案，在合理的存儲開銷下實現較好的容錯效果。當然，具體選擇哪種方案，還需要根據實際的訓練規模、硬件條件和可用資源來權衡。

隨着分佈式訓練規模的持續增長，相信未來會出現更多創新的 checkpoint 方案，比如基於預測的主動保存策略、多級存儲架構的智能調度等，這些都將為提高大規模訓練的可靠性提供新的可能。

06 業務發展對穩定性的要求

AI 訓練的穩定性管理已經演變為智能時代的精密工程。從最初靠人工重啓解決問題的摸索階段，到如今能自動感知異常、快速恢復的智能系統，每一次進步都映照着算力規模的跨越式發展。

讓人不禁思考，在未來十萬卡集羣的算力洪流中，或許會出現更精妙的動態平衡方案：既能像鷹隼般敏鋭捕捉故障徵兆，又能如雁羣遷移般智能調度資源，在秒級恢復與 PB 級存儲成本之間找到新的平衡支點。

目前百度百舸支持廠內千卡和萬卡集羣有效訓練時長已經可達 99.5%，為客户大模型的預訓練保駕護航，比如國內第一個數學大模型——九章算術，國內第一個類 Sora 大模型 —— Vidu 等。

----------END----------

推薦閲讀

LLM增強語義嵌入的模型算法綜述

持續推進“人工智能＋”行動，百度智能雲+DeepSeek為何成為國有企業首選？

GPU 雲服務器的軟件系統設計和實踐

基於Flink的配置化實時反作弊系統

百度智能雲xDeepSeek，最具性價比的DeepSeek一體機合集來了！