2012 年 ImageNet 競賽中 AlexNet 的橫空出世，開啟了現代 AI 發展的新紀元。彼時我們不會想到，十年後支撐 AI 訓練的 GPU 叢集會從研究室裡的幾臺伺服器，發展成需要專門供電系統的萬卡級計算矩陣。在這個算力爆發式增長的過程中，訓練系統的穩定性管理正經歷著從「簡單運維」到「精密工程」的深刻變革。
2022 年之前的 AI 訓練，更像是手工作坊式的精雕細琢。大多數訓練任務只需十幾塊 GPU，利用 PyTorch 或 TensorFlow 的資料並行功能就能輕鬆應對。記得那時演算法工程師們有個共識：如果訓練遇到問題，重啟往往比排查更高效。
當時我們構建的監控系統就像汽車儀表盤，只能顯示最基本的任務狀態。當訓練意外中斷時，工程師們會像偵探一樣翻查日誌 —— 如果發現是 GPU 報錯，就聯絡運維同事。運維人員則帶著「NVIDIA 三件套」（nvidia-smi、dcgm、nsys）到機房巡檢，像老中醫把脈般透過溫度、功耗等指標判斷硬體狀態。這種工作模式雖簡單，但應對數十卡規模的叢集還算遊刃有餘。
ChatGPT 的登場如同開啟潘多拉魔盒，將 AI 訓練帶入新的紀元。當我們開始部署千卡 / 萬卡叢集時，才發現原有的運維體系就像用小漁網捕鯨魚 —— 完全無法匹配新需求。
讓我們透過百度百舸經歷過的一個真實案例來深入理解這個問題：
2024 年初，百度百舸幫助一家 AIGC 創業公司迅速將其訓練規模從百卡擴充套件到千卡級別。然而在訓練數天後的某個週末凌晨，訓練程序意外發生了 hang 死。由於當時缺乏有效的故障感知和容錯機制，直到第二天演算法工程師發現任務超時退出時，已經耽誤了數小時寶貴的訓練時間。更糟糕的是，任務日誌中除了簡單的 timeout 報錯外毫無線索，平臺監控也顯示所有訓練節點狀態正常。
著急恢復訓練的演算法工程師沒有立即上報問題，而是選擇直接重新提交任務。但不幸的是，新任務執行數小時後再次出現相同的超時退出。這時他們才不得不尋求技術支援，但值班工程師面對這種任務 hang 死的問題也缺乏診斷經驗，只能透過二分法慢慢定位。最終發現是某個節點的靜默故障（SDC）導致了訓練程序假死。等問題得到解決時，距離首次故障已經過去將近 30 小時，這意味著損失了價值巨大的千卡算力資源。
站在現在的時間點回望，AI 訓練穩定性已從輔助功能演變為核心基礎設施。就像現代建築中的抗震結構，它雖不直接參與空間構成，卻是萬丈高樓得以屹立的關鍵。當行業向著數萬卡叢集邁進時，這套隱形護甲的質量，將直接決定 AI 進化的速度與邊界。
在 2024 年百度百舸對訓練過程的生命週期進行了更細緻的拆分，提出了「無效訓練時間」這一關鍵指標，並致力於將其最小化。具體來說：
任務無效訓練時間 = 故障中斷次數 × 任務故障恢復時長 + 任務常態寫 Ckpt 總時長
其中，任務故障恢復時長 = 故障感知召回耗時（自動 / 人工定位）+ 任務排程耗時 + 任務初始化耗時 + 任務重算時長。
透過這個公式可以看出，要降低無效訓練時間，需要「圍繞基礎設施穩定性」、「任務容錯」兩個維度來系統展開，重點解決三個方面的問題：
-
提高基礎設施的交付質量。
-
提高任務故障容錯的召回率、準確率和時效性。
-
最佳化 checkpoint 機制，減少儲存時間和恢復時的重算時間。
經過容錯架構的整體變革，百度百舸形成了從 「任務負載 — 框架 — 通訊 — 基礎架構」全鏈路的自動異常感知、診斷、恢復能力，可覆蓋 90%+ 的訓練異常場景，時效性最快可以實現秒級異常感知、分鐘級定位，以及平均 3 分鐘的故障自愈能力。
基礎設施的交付質量保障是穩定性的基礎。
CPU 時代，機器的交付前可能僅會跑一些常規的 CPU 計算、網路的壓力測試，並不會從業務視角去評估基礎架構，機器交付後硬體異常的故障頻率相對較少。有硬體故障時，通常走工單系統人工換機使用者相對是可接受的。
而 GPU 時代，AI Infra 的交付則需要考慮 CPU、GPU、RDMA 網路、儲存，甚至機房的功率、溫度等各方面因素，遺漏任何一個環節都會成為後續穩定性的隱患。在交付給客戶後，機器也可能會由於長時間的高負載執行頻繁出現硬體故障，而 GPU 機器的高昂成本，使客戶對節點故障感知、換機的時效性提出了非常高的要求。
因此百度百舸對 GPU 機器交付前及交付後的穩定性質量進行了系統性管理：
-
交付前，百度百舸會對機器進行 200 多項指標檢測，然後進行 48 小時烤機，以及 NCCL-Test 的機內、機間的大環、同號卡通訊效能基準測試，端到端的大模型訓練、推理效能基準測試。
-
交付後，需要能夠即時的感知節點故障及定期巡檢，並具備分級處理的自愈能力，例如 Error 級別的故障實現自動排水、重啟，Fault 級別故障實現自動換機。
任務層面穩定性最核心的就是做好容錯，能夠讓業務在無論遇到何種故障時都能快速恢復。
那麼，首要的工作就是我們能夠準確的識別出異常，然後對故障進行診斷定位，最後能夠自動化的從異常中恢復。
因此，任務容錯需要能夠從端側（即每個訓練 worker）探測到程序與環境的各類異常，同時有個中心服務（Master）從任務全域性的視角去診斷、定位異常，最終做出相應的決策來使任務能夠快速從異常中恢復。
任務容錯最重要的就是提升故障的召回率與準確率，即如何能夠儘可能的準確識別、定位所有故障。我們將故障分類兩類：顯式故障和隱式故障。
-
顯式的故障通常比較容易召回，我們將實踐積累的各種程序異常狀態及各類報錯 pattern 形成專家知識庫，再結合硬體感知服務（HAS Agent）的硬體全鏈路 10 秒級監控能力，可以實現顯式故障的召回率達到 95%+。
-
隱式的異常則往往很難輕易的識別，例如訓練程序 hang、慢節點就是典型的隱式故障，需要豐富的經驗積累才能準確的識別出異常。
下面我們就以最典型的隱式故障場景 —— 訓練程序 hang 死為例，來看下如何能夠做好 hang 自動感知、診斷。
訓練任務發⽣ hang 之後，絕⼤多數情況都會以 timeout 的⽅式報錯並退出程序，最常⻅的就是在通訊過程中如果發⽣ hang，NCCL 的 watchdog 會中斷通訊，並有報如下 timeout 報錯，然後再由 pytorch 的 torchrun 程序感知並中斷訓練過程。
[] [Rank 1] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=15173, OpType=ALLREDUCE, Timeout(ms)=1800000) ran for1802710 milliseconds before timing out.[] [Rank 0] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=15173, OpType=ALLREDUCE, Timeout(ms)=1800000) ran for1802713 milliseconds before timing out.Pytorch 預設為 10 分鐘 NCCL 通訊超時，而 Megatron-LM 為 30 分鐘。在萬卡規模訓練場景中，意味著一萬張卡要至少浪費 30 分鐘才能被發現。這個時效性是不可接受的。而且當 30 分鐘超時後程式會立馬退出，很難有機會進行下一步定位，需要一些時效性更高的感知機制，並且在程式退出前獲取一些有效資訊供後續診斷分析。
很多公司、實驗室在面對 hang 的問題時，會在採用框架層插樁的方式來 trace 訓練程序，這種方式通常是比較直接且準確的，但是有比較強的侵入性，而且可能還會有一些效能開銷。對於雲廠商來說，需要尋找對使用者更透明、更無損的方式來感知、定位 hang 異常。
如何感知訓練 hang，以百度百舸的產品設計思路為例，我們可以從以下幾個方向去思考：
人工判斷一個任務是否 hang 了，最直接的方式就是看是否所有 worker 的任務日誌一段時間內都不輸出日誌了，所以 hang 自動感知的第一種方法就是採集所有 worker 的日誌，並判斷所有 worker 日誌中最後一行日誌是否為 x 分鐘前的（x 小於 Pytorch 的通訊超時時間，例如 8 分鐘），如果是則基本可以判定為 hang。
任務 hang 時，可能程序的呼叫棧都不在發生變化，程序的呼叫棧可以透過 py-spy/pystack 等工具進行探測，所以我們可以用此類工具對所有訓練任務進行一個定時取樣，當採集 n 個樣本所有程序棧都沒有變化時，可以判定一次 hang，這種方式通常可以將 hang 感知縮小至 3～5 分鐘。
訓練程序中的 CUDA 運算元計算、集合通訊操作通常都是在毫秒，甚至微秒、納秒內完成的，當任務在正常迭代過程中發生了 hang，我們常遇到的情況是所有 rank 的 RDMA 流量會降到 0，而 GPU 的利用率為 100%、SM 利用率則在很低的水位。如果持續幾分鐘都是這種狀態時，意味著訓練程序已經計算完成，在等著集合通訊完成，這種情況下基本可以判定為 hang。
通常單次集合通訊操作都是在 ms 級的，如果一次操作在 30 秒鐘都沒有完成，那就可以判定為通訊 hang 死了。百度自研的 BCCL 集合通訊庫層可以對每一次集合通訊操作都進行打點，來實現通訊 hang 感知。
上述幾種方法，我們可以分別實現一種探針，來抓取相應的特徵到中心端 master 元件進行下一步診斷和容錯決策。
百度集合通訊庫 BCCL 是百度智慧雲推出的一款面向大模型訓練場景最佳化的集合通訊庫。BCCL 基於開源的 NCCL 進行了功能擴充套件和能力增強，針對大模型訓練場景在可觀測性、故障診斷、穩定性等方面進行最佳化，進一步提升集合通訊庫的可運維能力。相比 NCCL，BCCL 的關鍵特性如下：
有了以上感知手段，我們需要進一步的診斷、定位，來確定是否真的發生了 hang，以及 hang 的具體位置。具體的來講，master 收集到各類 agent 的資料後，會做一些綜合分析：
感知階段各種探針只能探測到 hang 的一種特徵，並沒有辦法 100% 的確定是否真的 hang 住了，事實上不侵入使用者程序是很難做到 100% 確定 hang 的。因此，為了提高 hang 的判定準確率，我們需要將各種特種綜合起來判斷，探針上報到 master 後，由一個 hang 診斷模組，按照一個時間視窗（例如 5 分鐘），進行綜合判斷。如果在時間視窗內日誌、監控、程序呼叫棧、通訊庫中有 2 條以上都處於不處於活躍狀態時，我們判斷任務真正發生了 hang。
確定任務 hang 了之後，我們需要找到 hang 所在的節點來對它進行隔離。因此診斷模組需要在探針上報的資料中進一步找尋特徵，來確定 hang 發生的位置：
-
BCCL Tracehang 診斷：在感知階段，BCCL 可以在通訊庫層面對所有 rank 的通訊進行打點。如果有節點一直未完成通訊則是發生了 hang。但是此節點可能並非真正發生 hang 的源頭，有可能是在等待其他節點完成通訊。診斷模組可以根據 BCCL 列印的通訊組資訊，進行交叉判斷，如果某個節點在多個通訊組中都未完成通訊，那這個節點就是 hang 的源頭。
-
RDMA/GPU 指標診斷：上文中我們提到，通訊階段發生 hang 之後，所有 rank 的 RDMA 流量都會降到 0，而同時絕大部分 rank 的 GPU 利用率持續為 100%，只有某一兩個 rank 的 GPU 利用率為 0，那這個 rank 很有可能是 hang 的源頭。
-
程序呼叫棧診斷：程序呼叫棧也可以作為一個 hang 源頭診斷的重要參考。當發生 hang 之後，絕大部分的 rank 都要麼處於 barrier 等待狀態，要麼處於通訊等待階段。只有個別的 rank 卡在其他函式上，那麼透過對比分析，可以將呼叫棧與其他 rank 不同的節點初步判定為 hang 的源頭。
-
綜合診斷：上面 3 種特徵為我們提供了 hang 的診斷依據，將 3 者關聯起來分析後，我們基本上可以比較準確的確定一個具體的 hang 的源頭，再結合硬體故障感知的相關資訊可以進一步明確根因。
在複雜的大規模分散式訓練場景中，傳統使用者態監控往往難以捕獲系統核心層面的異常事件。
百度百舸基於 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 通訊庫監測體系聯動，百度百舸形成了覆蓋從硬體到系統核心再到應用層的立體化診斷能力。
故障恢復的時效性也是容錯能力的一個重要指標，反映的是任務從故障發生到再次重新進入訓練迭代的時間，恢復效率越高則算力浪費越少。影響到任務恢復效率有 2 個重要因素，一是任務平均中斷時間，二是訓練重算時間。
任務發生異常後，上文中我們提到需要經過故障自動感知、診斷和自愈等 3 個環節，那麼減少中斷時間的核心思想，就是儘可能的縮短這 3 個環節的時間，透過多維度的感知、診斷手段可以將故障發現、定位的時效性降低至分鐘級甚至秒級。自愈則需要能夠根據不同的診斷結果進行分級恢復和故障遮蔽的能力：
-
單點顯式故障：重排程異常節點（replace），對節點進行叢集級別遮蔽。
-
單點隱式故障：重排程異常節點，對節點進行任務級別遮蔽。
-
非單點故障：原地重啟嘗試恢復（restart），無法恢復時重新排程所有節點（resubmit）。
透過多級重啟策略，儘可能避免單點故障引發全部節點的重新排程。在萬卡級別的訓練場景中，百度百舸將大部分訓練異常場景恢復時間從過去的 30min 縮短至現在的 30s 內，成功率到 95%+。
除了上述的多級任務重啟策略外，另一個提高任務故障恢復效率的重要手段就是減少訓練重算時間。在探討具體技術方案之前，我們先來看看目前主流的 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 方案，比如基於預測的主動儲存策略、多級儲存架構的智慧排程等，這些都將為提高大規模訓練的可靠性提供新的可能。
AI 訓練的穩定性管理已經演變為智慧時代的精密工程。從最初靠人工重啟解決問題的摸索階段，到如今能自動感知異常、快速恢復的智慧系統，每一次進步都映照著算力規模的跨越式發展。
讓人不禁思考，在未來十萬卡叢集的算力洪流中，或許會出現更精妙的動態平衡方案：既能像鷹隼般敏銳捕捉故障徵兆，又能如雁群遷移般智慧排程資源，在秒級恢復與 PB 級儲存成本之間找到新的平衡支點。
目前百度百舸支援廠內千卡和萬卡叢集有效訓練時長已經可達 99.5%，為客戶大模型的預訓練保駕護航，比如國內第一個數學大模型——九章算術，國內第一個類 Sora 大模型 —— Vidu 等。