一、背景

本文中我們將具體介紹 Meta 對其萬卡 AI 集群穩定性的剖析和刻畫，以及在其中遇到的各種挑戰，并在其中補充了一些真實場景中遇到的 Case，便于理解。

對應的論文為：[2410.21680] Revisiting Reliability in Large-Scale Machine Learning Research Clusters [1]（文末附下載）

二、摘要

可靠性是運維大規模機器學習基礎設施的重要挑戰，尤其是 ML 模型和訓練集群的規模在不斷擴大，這一挑戰更加明顯。盡管對基礎設施故障的研究已經有數十年歷史，但不同規模下作業故障的影響仍然不是特別明確。

本文中，作者從管理兩個大型多租戶 ML 集群的視角，提供了相應的定量分析、運維經驗以及在理解和應對大規模可靠性問題上的見解（PS：我們也會重點標記其對應的 12 個見解）。分析表明，盡管大型作業最容易受到故障影響，但小型作業在集群中占大多數，也應納入優化目標。作者識別了關鍵工作負載的屬性，進行了跨集群比較，并展示了擴展大規模 ML 訓練所需的基本可靠性要求。

本文中，作者引入了一種故障分類法和關鍵可靠性指標，分析了兩個最先進的 ML 集群 11 個月內的數據，涉及超過 1.5 億 GPU 小時和 400 萬個作業?；跀祿?，作者擬合了一個故障模型，以預測不同 GPU 規模下的平均故障時間。作者也進一步提出了一種方法，根據作業參數估計相關指標——有效訓練時間比（Effective Training Time Ratio，ETTR），并利用該模型評估潛在的緩解措施在大規模環境中的有效性。

三、Infra 系統

本節中作者闡述了工作負載如何影響集群的設計。盡管集群可以特化以針對特定工作負載進行優化，但集群會面對持續變化并且可能難以預見潛在的工作負載需求。因此，作者認為集群應該具備通用性，以最大化生產力，并最小化附帶復雜性。作者重點關注早期的兩個 A100 集群（PS：Meta 后續又搭建了 2 個 24K H100 GPU 的集群），RSC-1 和 RSC-2，它們遵循相同的設計模板。

RSC-1 是一個通用 ML 集群（例如，訓練一些 LLM），規模為 16,000 個 A100 GPU；

RSC-2 專注于計算機視覺應用，規模為 8,000 個 A100 GPU。

后續章節也會具體介紹，工作負載的差異體現在不同的使用模式中，例如，RSC-2 上的工作負載顯著傾向于 1-GPU 的作業，同時也有高達 1,000 個 GPU 的作業。

3.1 調度和存儲 Infra

RSC-1 和 RSC-2 集群設計以易用性為優先考量，同時追求簡潔性。其優勢在于整個技術棧相對成熟，無需大規模定制相關數據中心設計。此外，設計也力求在不附加任何條件的情況下為用戶提供所需數量的 GPU，以最大化生產力——用戶無需應對新型硬件或虛擬化帶來的復雜性。如下圖 Fig 1 展示了用戶如何與集群進行交互，用戶提交包含多個任務的作業，每個任務均可運行于節點的 GPU 上：

調度器（Scheduler）：依托高性能計算（HPC）技術棧，作者的機器采用基于裸金屬分配的 Slurm 調度器（Slurm Workload Manager [2]）。用戶通過 Shell 腳本（sbatch）或 Python 裝飾器（submitit）提交作業。Slurm 則根據物理網絡拓撲放置任務。作業運行 2 小時后可以被搶占，并且最長生命周期為 7 天。Scheduler 根據優先級順序安排任務，優先級受多種變量影響，包括項目配額以及任務時長。

ML工作負載遵循 Gang Scheduling 語義。Gang Scheduling 確保同一作業的多個任務所需的資源同時分配，這對于大規模 ML 工作負載的性能和效率優化至關重要。然而，如上圖 Fig 1 所示，單個任務失敗可能導致整個作業的重新分配。針對這種情況，通常會采用容錯策略，比如 Checkpointing 和冗余計算，以支持集群的容錯調度。Checkpointing 確保作業可以從保存的狀態恢復，減少對整體作業的影響，而冗余計算則降低作業失敗的概率。基礎設施會為用戶提供這種保障機制——若健康檢查導致作業終止，系統會自動將作業重新排隊，且保留相同的作業 ID。整體而言，RSC-1 集群平均每日提交 7.2k 作業，RSC-2 集群平均每日提交 4.4k 作業，并分別實現 83% 和 85% 的集群利用率。

存儲（Storage）：輸入、輸出數據以及作業的 Checkpoint 需要具備持久性，并獨立于特定作業的生命周期。作者的集群提供了 3 種存儲服務，使用戶能夠在易用性和性能之間進行權衡選擇：

基于閃存存儲，采用 NFS 協議并兼容 POSIX 的存儲服務。便于使用，為用戶提供主目錄、Python 環境及執行常見操作（如 Checkpointing）的讀寫能力。

AirStore，自定義、高帶寬的存儲服務。通過自定義的高性能只讀緩存服務 AirStore 加速數據集訪問，同樣依托于大規模閃存存儲。

ObjectStore，高容量與高吞吐量的對象存儲服務。用于 Checkpoint 和文件存儲，應對 NFS 存儲有限的問題。

3.2 計算和網絡 Infra

高性能計算集群的核心硬件組件包括計算、網絡和存儲。用戶通過提交給 Scheduler 的作業來提供使用這些組件的指令。集群的拓撲結構如下圖 Fig 2 所示，其中展示了節點系統的布局以及單個節點的內部結構：

計算（Compute）：RSC-1 和 RSC-2 兩個集群均為基于 DGX 的裸金屬集群，每個節點配備雙 AMD Rome 7742 CPU 和 8 塊 NVIDIA A100 80GB GPU。GPU 之間通過高帶寬的 NVLink + NVSwitch 互聯。

網絡（Networking）：在實際應用中，一個作業可能使用數百個節點，這些節點通過前端（Frontend）和后端（Backend）兩種方式互聯。前端網絡主要用于以太網管理平面（即調度和 TCP 連接）和存儲流量。同時，如上圖 Fig 2 所示，節點后端網絡通過 IB 鏈接，在模型訓練期間可以實現低延遲的梯度交換。通信被劃分為邏輯域：每個機架包含 2 個節點，10 個機架通過優化的網絡連接，形成一個 Pod，Pod 內的通信只用通過 Leaf 交換機，Pod 間的通信需要通過 Spine 交換機。

Scheduler 和模型訓練框架（如 Pytorch）應抽象出網絡的大部分復雜性，提供基于傳統集合通信的模型，該模型應具備跨多種作業分配的可移植性和高效性。關鍵在于，后端網絡軟件能夠利用存在的局部性（例如，可能的話，優先使用高帶寬的 NVSwitch，而非同構機架頂部的 Tor Switch 連接）。

3.3 集群 Infra 的見解

見解 1：集群正常運行時間至關重要。作者的集群處于滿負載狀態，任何停機都會導致過度排隊，并被視為重大事件。集群應該能夠實時適應故障，理想情況下應自動重新排隊與 Infra 相關的故障。

健康檢查：由于機器學習作業的 Gang Scheduling 調度語義，故障對整個作業的可靠性影響巨大——系統組件的單一故障可能導致數千個 GPU 閑置。此外，在大規模集群中，組件故障之間的間隔時間可能很短。為此，作者的 Infra 設計側重于檢查作業是否在健康硬件上運行，并在發生故障時將作業在不同節點重啟。

為了發現、檢測并移除故障節點，Scheduler 相應會接收集群中每個節點定期執行的一系列健康檢查的結果，通過這些健康檢查也可以分析作業故障。作者的訓練集群設計的核心理念是力求避免異常節點導致的二次作業失敗——故障節點不是一個好的調度候選。

Slurm 可以在作業運行前后執行健康檢查。此外，也會每 5 分鐘執行一次健康檢查，并返回表示成功、失敗和警告的 Code。每個健康檢查都會檢查節點的幾個方面，涵蓋從 GPU 錯誤（如 XID 錯誤）到文件系統掛載錯誤及服務狀態（例如，Scheduler）。需要注意的是，檢查可能具有重疊的故障域信號，例如，即使 GPU 本身未發生相應的 XID 事件，PCIe 故障也可表明 GPU 不可用。這種情況在 RSC-1 上出現的頻率為 57%，在 RSC-2 上為 37%。因此，即使某一檢測未能如期觸發，另一重疊的檢測也有望捕捉到這一問題。此種情況最極端的例子是 NODE_FAIL，用于當節點未能對其他檢測做出響應時，通過 Slurm 的心跳機制實現的全面捕獲手段。

定期健康檢測對于防止同一異常節點導致的重復作業失敗至關重要。此外，這些檢測也經過一系列調整，以降低誤報率，這使得成功完成的作業中觀察到健康檢查失敗的比例低于 1%，當然，也只是觀察到相關性而非因果關系。

不同檢測的嚴重程度各異。當節點健康檢查失敗時，節點將進入修復狀態，直到修復完成且所有檢測通過前，無法再進行作業調度。

高嚴重性檢測異常會立即向 Scheduler 發出信號，移除該節點并重新調度所有在該節點上執行的作業。包括 GPU 不可訪問，NVLink 錯誤，不可糾正的 ECC 錯誤，行重映射（failed row-remaps），PCIe 或 IB 鏈路錯誤，塊設備錯誤或掛載點缺失。

而較低嚴重性的檢測異常則會等節點上的作業完成（無論成功與否）再向 Scheduler 發送移除節點信號并進行修復。

未觸發任何健康檢查異常的節點可用于作業調度。

健康檢查的重要性也可以通過反向實驗驗證，比如在可能存在異常的節點上調度。即使只有一小部分節點異常，隨著規模的擴大，作業調度到異常節點的概率會呈指數級增加。需要強調的是，健康檢查是確?？煽?Infra 的第一道防線。

見解 2：一顆老鼠屎壞了一鍋湯。健康檢查機制能夠防止因反復調度到故障節點而引起的關聯性故障（也就是“循環重啟”）。若無法將此類節點移除，將導致無法有效運行大規模作業，并嚴重削弱集群效率，唯有確保故障節點能夠可靠地移除，從隨機故障中恢復才會有實際效果。

3.4 指標

有三個關鍵指標可以幫助理解機器學習集群性能：有效訓練時間比（Effective Training Time Ratio，ETTR）、模型浮點運算利用率（Model Flops Utilization，MFU）和 有效產出（Goodput）。

有效訓練時間比（ETTR）：ETTT 定義為生產性運行時間與作業運行時間的比值。一個作業運行包含一個或多個與同一邏輯任務相關的調度任務。例如，一個為期數周的 LLM 預訓練作業可能包含多個不同的任務，這些任務因為搶占、中斷或 Infra 異常而切分（忽略用戶空間故障對 ETTR 的影響）。作業運行時間定義為多任務運行中某個任務被調度或符合調度條件但正在隊列中等待的總時間。生產性運行時間為工作負載取得實質性進展的時間（比如，模型在真正訓練的時間）。生產性運行時間的精確定義因上下文而異，作者認為其存在兩種非生產性調度時間：1）從上次 Checkpoint 加載后的追趕時間：在最新 Checkpoint 和作業中斷之間重新訓練；2）重啟開銷：重啟后需要執行所有初始化操作，這些操作在正常情況下是不必要的。這兩者高度依賴具體的作業，目前缺乏可靠的大規模追蹤方法，作者根據和各團隊合作找那個遇到的合理值進行填充。

ETTR 的取值范圍從 0（作業從未取得實質性進展）到 1（100% 的時間用于實際訓練，沒有排隊或非生產性時間）。ETTR 類似于經典的作業延遲指標，然而，ETTR 額外考量了非生產性時間，并反轉了比例，以期獲得更好的可解釋性。

模型浮點運算利用率（MFU）：業界普遍采用的指標。對應于模型理論上利用的浮點運算次數與硬件峰值浮點運算次數的比值，MFU 可用于捕獲性能下降或次優實現的情況。兩者雖然不同，但是在測量運行時間與理想狀態的比例方面是可比的，且都介于 0 到 1 之間，不過 MFU 往往更低，比如 LLaMA 3 在 H100 訓練，MFU 只有 38%-43%，而 ETTR 可以超過 80%。

有效產出（Goodput）：上述兩個指標主要用于衡量每個作業，而 Goodput 可以用于衡量整個集群，即單位時間內完成的有成效工作的總量。Goodput 可以通過最大可能有效產出進行歸一化，介于 0-1 之間。本文中討論的集群在高負荷下運行（潛在 Goodput 僅受容量限制而非可用工作量），因此，任務搶占，資源碎片化和故障是 Goodput 損失的主要來源。

3.5 故障分類

故障分類是指將作業失敗的責任歸咎于某一原因的過程。作者的經驗表明，故障歸類是一個充滿挑戰且復雜的過程。例如，NCCL 超時現象相對常見。在 Pytorch 中，當某個節點觀察到集合操作在幾分鐘內未完成時，將發生 NCCL timeout。這可能意味著網絡問題，但也可能是其他節點因為故障未能啟動相同的操作，例如，加載下一個 Step 數據時阻塞。在此情況下，超時的節點功能完好，而故障節點可能因為用戶軟件問題或基礎設施錯誤而無法響應。從用戶堆棧 Trace 中追溯根因，需要跨越多層次、精確的分布式日志記錄，包括從 ML 應用到分布式集合通信操作以及底層 Infra 的各個方面。

因此，如下圖 Table 1 所示，作者的故障分類法基于以下原則：任何給定癥狀可能存在多種潛在根因，限制假設空間的唯一途徑是排除不太可能的原因。作者因此提出了通過故障域的差異診斷來診斷并根除錯誤——利用多種性能指標標記錯誤可能發生的區域，從而將特定故障限定于少數可能的原因。

作者的故障域涵蓋用戶代碼、系統軟件（如驅動程序、Pytorch、操作系統）以及硬件。正常情況下，用戶應確保其程序無明顯錯誤。從集群運維角度考慮，硬件錯誤需進一步分類為瞬態錯誤（如 ECC 錯誤、鏈路抖動）或永久性錯誤（如需要供應商維修或更換硬件）。與故障分類相關的信息追蹤必須實現自動化管理（例如，通過健康檢查），原因在于：1）程序與機器的配對具有不確定性；2）故障通常是罕見事件。

作者發現，擁有涵蓋硬件和系統軟件多個方法的豐富信息，有助于更快地確定特定癥狀集合的成因。在某些情況，多個同時觸發的健康檢查可能指向同一錯誤（例如，PCIe 異常可能影響 GPU）。

如下圖所示，以我們的一個 Case 為例，訓練時遇到過 Pytorch 拋出 CUDA error: an illegal memory access was encountered 錯誤：

同時查看相關系統信息發現 GPU 有 Xid 31 的錯誤：

進一步根據 NVIDIA Xid 文檔（1. Introduction — XID Errors r555 documentation [3]）可知，Xid 31 大部分為用戶程序問題，比如訪存越界等，但也有一定可能是驅動 Bug 或硬件 Bug：

見解 3：警惕誤導性線索。具有多種潛在成因的錯誤難以診斷，例如，NCCL 超時錯誤可能被簡單歸咎于近因（proximal cause），比如網絡問題而非死鎖。網絡具有更廣泛的影響范圍，導致可能橫跨整個系統堆棧。其他錯誤則與特定節點硬件相關，隨著其發生頻率增加，可能性也隨之上升，如上圖 Table 1 是作者總結的分類法和相關經驗。

同樣以我們自己的一個 Case 為例，如下圖所示，訓練中可能會遇到 NCCL timeout 的錯誤，由于缺乏有用的信息，通常很難穩定復現這類異常，調試起來非常困難。

為了解決這個問題，常見的方式是 Fork NCCL 代碼，添加相應的時間戳信息，以便更好地顯示崩潰發生時正在執行的消息或操作，從而確定哪個 Node 或 GPU 可能阻塞了，如下圖所示為 ImbueAI 在解決類似問題時的方案（https://github.com/boweiliu/nccl/commit/0966031bdb5905b8ea5aef3fb2a8ce6317040234）。

Meta 在 LLaMA 3 的技術報告（The Llama 3 Herd of Models | Research - AI at Meta [4]）也提到相關的解決方案。具體來說，為了增加有效訓練時間，減少作業啟動和 Checkpointing 時間，LLaMA 3 作者開發了用于快速診斷和解決問題的工具。其主要是利用 Pytorch 內置的 NCCL flight recorder（參考 PyTorch 2: Faster Machine Learning Through Dynamic Python Bytecode Transformation and Graph Compilation [5]），將集合通信的元數據以及堆棧信息捕獲到 ring buffer 中，基于此可以快速診斷 Hang 以及性能相關問題，尤其是與 NCCLX（Meta 的內部 NCCL 版本） 相關的問題。利用此功能，可以有效地記錄每個通信事件以及每個集合通信操作的持續時間，并且可以自動將 Trace 信息轉存到 NCCLX Watchdog 或 Heart timeout。也可以在生產環境中在線修改配置，以便根據需要選擇性地實現計算密集型的跟蹤操作和元數據收集，而無需發布代碼或重新啟動作業。

四、理解大型 ML 訓練集群的現狀

這里的分析基于上述的兩個集群，涵蓋 11 個月的觀察數據。分析建立在 Slurm Scheduler 和前面介紹的健康檢查的基礎上。需要說明的是，這里討論的集群存在過度配置現象，因此項目級的 QoS 和服務分配是決定哪些作業可以運行的主要因素。

Scheduler 作業狀態細分：Slurm 作業可能處于以下狀態之一：Cancelled（取消）、Completed（完成）、Out_of_Memory（內存不足）、Failed（應用返回非零退出碼）、Node_Fail（節點故障）、Preempted（為更高優先級作業讓位）、Requeued（重新排隊）或 Timeout（超時）。如下圖 Fig 3 展示了 RSC-1 集群的 Scheduler 作業狀態細分。60% 的作業成功完成，24% 和 0.1% 的作業分別有 Failed 和 Node_fail 失敗，10% 的作業被搶占，2% 的作業重新排隊，0.1% 的作業內存不足失敗，0.6% 的作業超時。

如上圖 Fig 3 所示，其中 Infra 故障（HW）只影響了 0.2% 的作業，但影響了 18.7% 的運行時間。鑒于預期 Infra 故障會影響大型作業（這類作業數量很少，但占用大量運行資源），這一現象也并不意外（可以參考后文 Fig 6）。

見解 4：由于健康檢查機制，硬件故障構成了一組罕見的結果。硬件故障只影響了不到 1% 的作業，但影響了 19% 的 GPU 運行時間。一旦考慮 Checkpointing 機制，這種影響顯著減小，因為 Checkpointing 緩解了這種損失。

作業級故障刻畫：歸因于硬件的故障可根據歸因進一步細分。這些原因可以按照節點級組件細分，如 GPU、網絡及各種系統組件，如文件系統。如下圖 Fig 4 中展示了 RSC-1 和 RSC-2 集群每小時每 GPU 的故障率。若故障原因在作業失敗前 10 分鐘內或失敗后 5 分鐘內被檢測到（Failed 或 Node_Fail），則將故障歸因于該原因。需要注意的是，作者根據所開發的啟發式方法報告了最可能的故障原因，該方法指示節點是否應被隔離以進行相關修復。某些故障可能有多重原因。一些 Node_Fail 事件并未與任何健康檢查相關聯，這可能是節點本身變得無響應。其中 IB 鏈路、文件系統掛載、GPU 內存錯誤和 PCIe 錯誤占比最大。

對于 IB 鏈路而言，似乎主要由 2024 年夏季少數節點在短時間內發生的眾多 IB 鏈路故障相關，如下圖 Fig 5 的黃色部分。其中 GSP 超時是由代碼回退引起，該問題通過驅動補丁得以修復。

我們在 A100 中也遇到過 GSP（GPU System Processor） 相關問題，通過關閉 GSP 可以解決。阿里云的 FAQ 中也有相關介紹，如下所示，具體可以參考 ACK集群GPU使用常見問題和解決方法- 容器服務Kubernetes 版 ACK - 阿里云 [6]：

故障可能同時發生：RSC-1/RSC-2 上 3% 和 5% 的硬件故障伴隨著類似優先級的共現事件，例如，作者觀察到 PCIe 錯誤常與 XID 79（通常意味著掉卡，比如從 PCIe 總線上斷開鏈接）和 IPMI “Critical Interrupt” 同時發生。在 RSC-1（及 RSC-2）上，作者觀察到 43%（63%）的 PCIe 錯誤與 XID 79 共現，21%（49%）則同時包含所有上述 3 種事件類型。這是預料之中的，因為所有這些檢查都與 PCIe 總線健康狀況有重疊。此外，作者還觀察到 2%（6%）的 IB 鏈路故障與 GPU 故障（如與總線斷開連接）同時發生，這可能表明與 PCIe 存在關聯。

同樣以我們的一個 Case 為例，如下圖所示，使用 Pytorch 訓練時遇到 CUDA error: unknown error 的問題：

進一步排查發現系統中同時出現了 pciehp Link Down，Xid 79（GPU fallen off the bus）以及 NVSwitch timeout 的錯誤，與此同時還在后續出現 Xid 45 的錯誤，這個就是常見的掉卡問題。

其實 Xid 也經常會一起出現，如下圖所示，一個 uncorrectable 的 ECC Error 往往會伴隨多個不同的 Xid 同時出現：

見解 5：許多硬件故障未被歸因，而最常見的故障歸因于后端網絡、文件系統和 GPU。GPU 有細粒度的 Xid，也有豐富的錯誤類別，不過主要的錯誤都與內存相關。PCIe 總線錯誤和 GPU 脫離總線也非常常見并且相關聯。CPU 內存和 Host 服務對應用影響較小。

故障率隨著時間演變：進一步將剖析轉向更大規模的作業，相應也切換到節點級（而非 GPU 級）剖析。如上圖 Fig 5 所示，作者展示了 RSC-1 在過去一年中的故障率情況，揭示了如下幾點：

故障率持續波動。

故障模式起伏不定：比如 23 年末，驅動程序錯誤導致 Xid 錯誤成為 RSC-1 上作業失敗的主要來源；24年夏季，IB 鏈路故障激增同樣推高了兩個集群的故障率。

新的健康檢測揭示新的故障模式：圖中標識了新的健康檢查（之前就在發生，但未被準確識別）添加到集群的時間點，這也會導致故障率看似增加。

如下圖所示，上海 AI Lab 等團隊在 [2403.07648] Characterization of Large Language Model Development in the Datacenter [7] 中提到一個類似的故障，其 AI 集群在 2023.07（最熱的月份） 時，機房溫度升高了 5 度，導致故障率明顯增加：

見解 6：集群故障具有動態性，集群故障是一場持續戰斗，新的軟件更新也就意味著集群在不斷變化，工作負載和性能也在持續調整。

訓練任務多樣性：必須考慮任務規模和時間，以在整體多樣性和訓練 GPU 小時數之間取得平衡。Scheduler 需要權衡單個訓練作業的公平性、整體集群利用率及訓練性能。如下圖 Fig 6 所示，描繪了 RSC-1 集群中作業規模的分布，超過 40% 的訓練作業使用單個 GPU 進行開發或者模型評估，僅有少數大模型作業，比如超過 1000 GPU。在同一個圖中，作者還展示了相對于單個 GPU 作業的 GPU 時長的歸一化結果。雖然有眾多單 GPU 作業，但是 RSC-1 和 RSC-2 中分別有 66% 和 52% 的總 GPU 時間來自 256+ GPU 的作業。

見解 7：超過 90% 的作業規模小于一臺機器（包含 8 個 GPU），但僅占不到 10% 的 GPU 時間。RSC-1 集群傾向擁有更多 8 GPU 作業，而 RSC-2 則更傾向于 1 GPU 作業。RSC-1 集群往往包含規模最大的作業。

MTTF 隨規模減?。喝缦聢D Fig 7 所示，1024 GPU 作業的平均故障時間（MTTF）為 7.9 小時，比 8 個 GPU 作業（47.7 天）低約兩個數量級。這也符合預期，經驗上，硬件可靠性與 GPU 數量成反比，且在 32 個 GPU 以上時趨勢更為一致。圖 Fig 7 還展示了從集群節點故障率推導出的理論預期 MTTF（MTTF ∝ 1/Ngpus）：MTTF=(Nnodesrf)-1，其中 rf 根據所有超過 128 個 GPU 作業的總故障數和節點運行天數計算，與較大作業（>32 GPU）的實際 MRRF 數據吻合：

基于在上述集群中大規模訓練任務所觀測到的故障概率，作者預測 16384 個 GPU 任務的 MTTF 為 1.8 小時，131072 個 GPU 任務的 MTTF 為 0.23 小時。為了在故障發生時最大化 ETTR，必須加快故障檢測與恢復過程。

如下圖 Table 5 所示，Meta 在 LLaMA 3 的技術報告（The Llama 3 Herd of Models | Research - AI at Meta [4]）中也描述了相關故障率，其提到在 54 天的訓練中，共遇到 466 個任務中斷，包括 47 次的有計劃中斷，以及 419 次的預期外中斷。在這些非預期中斷中，78% 是硬件問題，例如 GPU 或物理機其他組件的異常，其中 GPU 相關問題占到 58.7%。其訓練使用了 16384 H100 GPU，對應的平均故障時間為 54*24/419=3 小時，也就是平均每 3 小時出現一次故障。當然，組著通過自動化運維手段仍然可以獲得超過 90% 的有效訓練時間。

見解 8：盡管故障并不直接影響多數作業，但大型作業受其影響顯著，故障率與理論趨勢相符。在 4K 規模下，MTTF 約為 10 小時，并預計在 RSC-1 的更大規模下會進一步下降。MTFF 預測與 RSC-1 的 4-512 節點實測 MTTF 吻合。對于 RSC-2，預測趨勢類似，但是 16 個 GPU 的實測 MTTF 數據波動較大，部分原因是一組相關任務引發多次 Node_Fail。總體上 RSC-1 和 RSC-2 趨勢類似，部分差異可以歸因于兩個集群工作負載稍有不同觸發了不同的故障。

搶占與故障級聯：作業失敗的次級效應之一是：對其他優先級較低且可能規模較小的作業的影響，從而導致級聯效應。在實際操作中，大型作業往往具有較高的優先級，而小型作業優先級最低，這樣大型作業通過搶占低優先級作業得以快速調度。當一個大型高優作業因硬件不穩定而失敗時，Slurm 會重新調度該作業，在這個過程中可能搶占數百個作業。最糟糕的情況是循環崩潰，也就是配置為作業失敗時重新排隊。作者發現一個 1024 GPU 作業發生 Node_Fail 后重新排隊 35 次，總共導致 548 次搶占，共涉及 7000 個 GPU。此類情況應盡可能的避免，不然會造成集群 Goodput 的損失。

在考慮作業失敗時，搶占是一個次級效應。作者集群中，為了確保即使是最低優先級的作業也能取得進展，搶占只能在運行兩個小時后發生。然而，如果沒有精確的 Checkpointing 機制，作業被搶占時相應的工作進度也會丟失。關鍵在于，大型作業 1) 預計會損失大量工作，2) 失敗頻率更高，導致作業規模與 Goodput 吞吐之間呈二次函數關系。為了估計各種 Goodput 損失來源對整個集群 Goodput 的影響（包括重新調度失敗作業發生的搶占），作者假設所有作業每個小時進行一次 Checkpointing，平均損失半個小時的工作量。通過 Slurm 日志可以確定相應作業 1）收到 Node_Fail（集群相關問題）或歸因于硬件問題的 Failed 狀態的作業，2）因引發 Node_Fail 或 Failed 而被搶占的作業，并估計損失的 Goodput（作業運行時間與 30 分鐘的最小值，乘以分配給該作業的 GPU 數量）。

如下圖 Fig 8 所示，RSC-1 因故障和二次搶占導致的大部分 Goodput 損失（y 軸），主要源自規模在 2K-4K 個 GPU （x軸）的大型作業。在 RSC-2 集群，由于作業構成的差異，中等規模作業占據 Goodput 損失的比例更高。此外，RSC-2 上 Goodput 損失比 RSC-1 上小一個數量級，這是作業構成和故障率差異的結果。盡管優化大型作業至關重要，但硬件故障導致的 Goodput 損失中，依然有 16% 源于二次搶占。

見解 9：大型、高優先級作業在故障時會使 Scheduler 產生波動。雖然 1K+ GPU 作業故障的一級效應顯著，但總故障開銷的 16% 來自于搶占其他作業。因此，作業多樣性的增加為優化提供了額外的途徑。

量化大規模訓練的 ETTR：ETTR 提供了一個可解釋性的指標，用于量化中斷、排隊時間和開銷對訓練進度影響的程度。理解 ETTR 如何隨著配置、調度及故障等不同因素的變化而變化，有助于評估各種措施的影響規模。

這個部分，作者提供了：

基于作業訓練參數、作業優先級和集群資源可用性作為輸入的 ETTR 期望值公式。這里，公式通過假設 Checkpointing 頻率和重啟開銷，使得能夠模擬作業的可靠性特征。需要注意的是，期望 ETTR（E[ETTR]） 對于較長的訓練最為有效——根據大數定律，較長的訓練趨向于使觀測到的 ETTR 值更接近這一期望值。利用對期望 ETTR 的解析公式，可以幫助快速估算并理解優化措施的影響，例如將故障率減半的影響是什么？

利用作業級數據對 RSC-1 和 RSC-2 集群進行 ETTR 估計的設計空間探索研究。繼續使用先前的參數作為工具，探索不同因素對作業開銷的相對重要性——探討在之后大規模 GPU 訓練中，實現合理 ETTR（>=0.90）所需的必要條件。

解析近似 E[ETTR]：首先，定義 Q 為符合調度條件但處于排隊等待的作業的時間，R 為有效運行時間，U 為無效運行時間?？倳r間為 W=Q+R+U。Checkpointing 之間的間隔為 Δtcp，初始化任務所需時間（如加載 Checkpoint）為 u0，提交后及每次中斷后的期望排隊時間為 q（假設排隊時間服從獨立正態分布 i.i.d，且在遭遇中斷后并未系統性地縮短）。作業需要的節點數為 Nnodes，集群故障率 rf 表示每節點、每天內預期發生的故障次數。如下圖所示可以得出期望 ETTR 的解析公式：

對于 RSC 集群，每個 GPU 節點（8 GPU）每天的故障率 rf 約為 5x10-3，tcp 約為 1 小時，也就是 0.04 天，u0 約為 5-20 分鐘，而 (Nnodesrf)-1 >= 0.1 天。與預測各種期望值的蒙特卡洛方法相比，即便對于大型、長時間運行的假設性任務（例如 8000 GPU），上述近似值的誤差也在 5% 以內。

與實際作業對比：作者將上述期望值公式與兩個集群上實際作業的觀察結果進行了比較。一個作業運行多個任務（可能具備不同的任務 ID），它們都屬于同一訓練作業。假設 Δtcp 為 60 分鐘，u0 為 5 分鐘。這里重點關注總訓練時間為 24 小時的長時間作業，并針對以最高優先級運行的作業，以理解最高優先級作業的 ETTR。需要說明的是，這里計算作業 ETTR 時，不考慮健康檢查，并且假設每個作業都因基礎設施故障而中斷，意味著對 ETTR 的數據估計應為低估。

為了獲取計算 E[ETTR] 所需的機器級故障率 rf，作者將所有使用超過 128 個 GPU 且被標記為 Node_Fail 狀態的作業以及那些因關鍵健康檢查在作業最后 10 分鐘（或完成后 5 分鐘內）觸發而狀態變為 Failed 的作業，均計為故障。然后，將故障次數除以節點運行天數（節點運行天數乘以節點數的總和）。作者發現，RSC-1 的 rf 為每千節點日 6.5 次故障，而 RSC-2 的 rf 顯著低于 RSC-1，為每千節點日 2.34 次故障。這一發現通過觀察集群中 GPU 的交換率也可以得到印證，RSC-1 的 GPU 交換率為 RSC-2 的 3 倍。GPU 交換率和故障率的差異可能源于 RSC-1 上更為繁重的工作負載。

ETTR 結果分析：如下圖 Fig 9 展示了作者的研究結果。除較小任務（< 64 GPU）外，E[ETTR] 與實際測量的任務運行平均 ETTR 相吻合，在 RSC-1 上，超大任務（> 1024 GPU）的 ETTR 高于 E[ETTR] 預測值（>0.9），原因在于這些大型任務運行的實際等待時間小于平均值。

在假設情景中，若 RSC-1 集群用于單一 16,000 GPU 訓練任務，占據整個集群，60 分鐘 Checkpointing 間隔下的期望 ETTR 為 0.7，縮短為 5 分鐘 Checkpointing 間隔，期望 ETTR 增至 0.93，凸顯了頻繁 Checkpointing 對抵御中斷的價值（PS：假設 Checkpointing 寫入為非阻塞，可以通過異步、分布式存儲實現，當前很多框架已經提供該能力）。

展望未來：對于未來需要 O(105) GPU 的其他集群，基于類 RSC-1 故障率（每千節點日 6.50 次故障）推導的 MTTF 為 15 分鐘。這意味著 1 小時的 Checkpointing 間隔不可行。如圖 Fig 10 展示了故障率與 Checkpointing 間隔的權衡，例如，對于類 RSC-1 故障率，需要 7 分鐘的 Checkpointing 間隔才能實現 E[ETTR]=0.5，若故障率接近 RSC-2，則需 21 分鐘。在類 RSC-2 故障率下要達到 E[ETTR] 0.9，需 2 分鐘的 Checkpointing 間隔和 2 分鐘的重啟開銷。

見解 10：RSC 集群對最大及最高優先級作業極為高效（ETTR > 0.9）。盡管 RSC-1 集群資源緊張且共享，在其上運行 2048-4096 GPU 且超過 1 天的作業，假設 1 小時的 Checkpointing 間隔，可以實現 ETTR 超過 0.9。若每次故障后的排隊時間為 1 分鐘， Checkpointing 間隔為 30 分鐘，在 RSC-1 上可以實現最大可行訓練（8,000 GPU，占 RSC-1 一半資源）ETTR 達到 0.9。在假設具有類 RSC-2 類故障率的集群上進行 100,000 GPU 訓練時間，要達到 ETTR 0.9，Checkpointing 間隔和 Restart 開銷需要為 2 分鐘。（PS：如上所示，Meta 在 LLaMA 3 技術報告中也提到，其 LLaMA 3 在 16K H100 GPU 集群實現了 90% 的有效訓練時間）

五、提升集群穩定性和效率

這個章節作者介紹了為提升集群可靠性所實施的緩解措施。健康檢查只是其中之一，尤其擅長發現隨機節點故障。然而，故障可能與特定節點（作者稱為 lemon node）相關聯，這可能是由于配置錯誤，老化或硬件缺陷所致。因此，健康檢查工具也可以用以識別反復出現問題的節點。此外，作者也將其拓展到節點外，包括針對網絡路由不可靠時的網絡層緩解措施。最后，作者也概述了集群設計和工作負載本身如何影響集群級指標。

5.1 識別和修復故障節點

盡管健康檢查機制在初始階段可以幫助避免同一故障導致多個作業失敗的情況，實踐中作者也發現某些節點的作業失敗率顯著高于平均水平。因此，可以懷疑硬件可能正在退化或節點運行了錯誤配置的軟件。遺憾的是，快速識別此類節點非常困難，需要長時間觀察其故障行為以獲得統計顯著性。更糟糕的是，這些節點失敗恢復后仍會導致新作業的不斷失敗，最終導致作業失敗并延長整體恢復時間。

在存在故障節點的情況下，無論是由于訓練集群中不同硬件組件的瞬時或永久性故障，研究人員通常會根據過往經驗手動排除導致任務失敗的節點。然而，這種做法難以擴展，且過度排除節點可能導致容量枯竭。

為提升 ETTR，作者設計了 lemon node 檢測機制，以主動識別、隔離并替換 lemon node。lemon node 是指那些反復導致作業失敗但無法通過現有健康檢查和修復流程識別的節點。如前所示，導致訓練作業失敗的最重要因素之一是節點故障（Node_Fail），這凸顯了主動處理 lemon node 的重要性。

lemon 檢測信號：在每個節點上可用的數十種檢測信號中，以下幾種與 lemon node 最相關，盡管報告的結果是基于預測 lemon node 準確率和誤報率人工調整的，依然可以將這些信號視為二分類模型的潛在特征。

excl_jobid_count：驅逐節點上的作業數量。

xid_cnt：節點上單一 Xid 錯誤數量。

tickets：為某節點創建的修復工單數量。

out_count：節點從 Scheduler 中移除的次數。

multi_node_node_fails：由單節點引起的多節點作業失敗次數。

single_node_node_fails：由節點引起的單節點作業失敗數量。

single_node_node_failure_rate：節點上單節點作業失敗的比例。

如下圖 11 所示，展示了基于 RSC-1 的 28 天數據快照信號分布情況，可以據此設定檢測標準的閾值。x 軸表示每個 GPU 節點信號出現的歸一化次數。y 軸表示經歷每種信號的 GPU 節點的累積數量，同樣進行歸一化處理。作者發現，excl_jobid_count 信號與節點故障之間并無顯著相關性，大量節點因至少一個作業而被排除。這促使作者主動檢測 lemon node，而非將其留給用戶。超過 85% 的已識別 lemon node 在某一測試中失敗，失敗類型詳見 Table II。

作者設計、實施并評估了 lemon 檢測機制，成功識別出 RSC-1（24 個節點）和 RSC-2（16 個節點）中的 40 個故障節點，準確率超過 85%。這些被識別的 lemon node 占 RSC-1 總規模的 1.2%，每日作業的 13%。這種 lemon 檢測機制使得大規模作業（512+ GPU）的失敗率降低 10%，從 14% 降低至 4%。

見解 11：歷史數據對于識別缺陷節點至關重要。實施 lemon node 檢測技術可將大型任務完成率提升超過 30%。

5.2 通過自適應路由增強網絡結構韌性

故障特征分析揭示了 IB 鏈路錯誤引發的故障的重要性。正如節點可能在不同階段由于瞬時或永久性組件退化而異常，網絡鏈路也可能因物理或電氣特征的變化而表現出類似行為。大規模并行模型訓練不可避免會遭遇故障鏈路，這些鏈路可能具有高錯誤率、在上下行狀態間頻繁切換的抖動行為、永久性斷開或在高密度租戶環境中出現嚴重擁塞。所有這些情況都會導致跨節點的通信性能下降。

大規模物理鏈路更換操作繁瑣，因此 IB 網絡結構配備了交換機級別的鏈路問題容錯技術，其中一種自我修復技術稱為 SHIELD，允許交換機在鏈路故障時進行協調。然而，即使啟動了此功能，將鏈路視為斷開的閾值可能過于保守，導致協議層面的重傳及潛在的網絡性能下降。特別是在 RSC-1 的啟動階段，作者觀察到了 50%-75% 的帶寬損失。

另一種更為先進的功能是自適應路由（AR），它根據實時網絡狀況動態調整路由決策。AR 平衡了所有網絡鏈路上的流量，提高了整體鏈路利用率。通過允許數據包避開擁塞區域和不健康鏈路，自適應路由提升了網絡資源利用率和效率，從而減少因網絡問題導致的訓練作業性能波動。作者在集群中啟用了 AR 以提升性能的可預測性。

為了展示 AR 在作者集群中的重要性，作者進行了兩項實驗。

第一個實驗中，使用 mlxreg 工具修改網絡中的端口寄存器，引入位錯誤（BER）。隨后，針對 512 GPU，在啟用與未啟用 AR 的情況下，運行 nccl-tests 中的 AllReduce 基準測試。如下圖 Fig 12a 所示，在鏈路錯誤條件下，AR 能夠維持更高的帶寬。

第二個實驗中，在 64 個節點上分組進行 AllReduce 的多輪迭代，每組包含兩個節點（16 個 GPU），以展示 AR 在資源競爭環境下的表現。如下圖 Fig 12b 所示，網絡中充斥著多個 NCCL 環路時，使用 AR 的性能波動較小，且 AR 能實現更高的性能。這是因為 AR 能夠保護 GPU 免受擁塞鏈路的瓶頸效應。通過使用交換機根據端口負載選擇的輸出端口，AR 將不良鏈路的影響分散到各個任務中，而非僅懲罰恰好映射到這些不良鏈路的訓練任務。

見解 12：網絡必須具備故障排除和繞行能力，若缺乏彈性機制，可能會損失超過 50% 的帶寬。

六、關鍵教訓和研究機會

在介紹了集群運維和優化方面的經驗后，作者認為有多個機會可以提升可靠性、管理日益增長的 Infra 復雜性，并與框架和算法共同設計解決方案。

訓練可靠性：作者展示了如何通過運行監控檢測和歷史分析來發現瞬態故障，這些故障阻礙了可靠性的保障；作者也介紹了 lemon node 檢測，通過移除 lemon node 可以將大型作業完成率提高 30%。展望未來，也看到了進一步給 Scheduler 和分布式算法暴露可靠性信息的重要機會，以便工作分配可以最大化可靠性和 Goodput。此外，作者也注意到網絡結構本身在彈性方面的潛在改進機會，例如，能夠重新調整拓撲以繞過故障，這也與上述的 AR 部分相對應。因此，作者設想未來的 Infra 系統應試圖使不可靠不那么明顯，而不是試圖完全消除。此外，當未來的 GPU 系統，比如 NVIDIA GB200，將修復單元從單個節點轉為整個機架時，可能需要重新思考整個系統。

更接近應用層面：訓練作業的預期訓練恢復時間是與故障相關的延遲開銷的函數。提高 ETTR 的有效方式之一是盡量減少重啟延遲成本，同時降低重啟的概率。如之前工作（字節 [2402.15627] MegaScale: Scaling Large Language Model Training to More Than 10,000 GPUs [8]）介紹，像 NCCL 初始化等操作可能會隨著 GPU 節點數量的增加而表現不佳。因此，未來的軟件系統支持快速且可靠的程式（優化重啟的延遲開銷）顯得尤為重要。作者認為，完全替代類似 MPI 的集合通信機制以及提升硬件預檢測效率等措施將成為未來的關鍵發展方向。

調試工具：在通過健康檢查排除大量且顯著故障后，剩余的故障通常表現為近端故障，這些故障并不立即提示根本原因。NCCL 超時是此類故障中最常見的癥狀之一，其根本原因可能涉及網絡基礎設施、有缺陷的模型代碼或其他組件。

定期檢查硬件基礎設施的健康狀況可以幫助主動發現網絡或硬件問題，減少 NCCL 超時的頻率，這樣這些問題可以在表現為 NCCL 內核卡住之前就被發現。然而，識別剩余超時的根本原因則需要引入新的健康檢查或進行錯誤修復。通過回溯性識別 NCCL 超時的根本原因，可以提高訓練的成功率，比如，通過比較參與集合通信的不同 Rank 記錄的數據來實現。例如，記錄每個集合通信的啟動 Rank 及其之間的關系，可以找到某些 Rank 啟動而其他 Rank 未啟動的第一個集合通信操作，并進一步調查缺失的 Rank。如果所有集合通信 Rank 都進行通信但未退出，可以進一步檢查集合通信內的網絡流量，以識別哪個組件未發送或接收預期的 Message。從未來的作業中刪除所有有問題的 Rank 或網絡組件，將降低這些作業遇到相同問題的可能性。為了實現高效且可靠的大規模分布式訓練，需要更完善的診斷和調試工具?？梢詳U展現有的管理工具，如 IPMI，以通過帶外網絡提供機器調試信息，并縮小歸因差距。

編程模型：診斷 NCCL 超時的一個復雜因素是 Pytorch 中實現的 SPMD 編程模型，如果不同 Rank 意外的以錯誤順序發出集合通信指令，如 AllReduce，任務將陷入死鎖，導致 NCCL 超時。因此，調試 NCCL 超時的第一步是確定訓練腳本是否存在缺陷，這為追蹤 Infra 的不穩定性增加了復雜性。動態檢測錯誤程序并引發異常而非死鎖，有助于提升系統穩定性。或者，可以完全消除集合通信操作不匹配的可能性，例如，Pathways 引入了單一的通信調度入口，確保每臺機器的通信調度一致。

七、參考鏈接

https://arxiv.org/abs/2410.21680

https://slurm.schedmd.com/overview.html

https://docs.nvidia.com/deploy/xid-errors/index.html

https://ai.meta.com/research/publications/the-llama-3-herd-of-models/

https://pytorch.org/assets/pytorch2-2.pdf

https://www.alibabacloud.com/help/zh/ack/ack-managed-and-ack-dedicated/user-guide/gpu-faq#55a6b327214cg

https://arxiv.org/abs/2403.07648

https://arxiv.org/abs/2402.15627