在大型 GPU 集群上訓練 AI 模型給模型構建者帶來了重大挑戰。隨著作業規模的增加，人工干預變得不切實際，因此自動化對于保持高 GPU 利用率和訓練生產力至關重要。卓越的訓練體驗需要具有彈性的系統，這些系統可提供低延遲錯誤歸因，并根據根本原因分析自動進行故障轉移。自動化并不新鮮。Health checks、preflight checks、syslogs 和 telemetry 都適用于各種硬件和軟件組件。遺憾的是，其中大多數對最終用戶來說是不透明的，并且難以訪問和用作一線工具。
在大多數情況下，模型構建器首先在訓練過程中遇到問題。他們必須與基礎設施和運營團隊合作，收集必要的數據來分類問題，例如，錯誤是否是由硬件或軟件引起的，或者是間歇性的還是持久性的。
這種昂貴的人工干預過程會拖慢整個開發周期，并阻礙快速實驗。隨著研究人員擴大實驗規模，所涉及系統的組合復雜性也加劇了這一問題。本文將介紹如何在 NVIDIA DGX Cloud 上實現可靠、高效的大語言模型 (LLMs) 訓練。我們介紹了我們的團隊在訓練 NVIDIA Llama Nemotron 和其他基礎模型時遇到的一些挑戰，重點介紹了提高彈性訓練的機會，并展示了 DGX Cloud 如何在 2K-10K GPU 規模的訓練中實現約 1% 的硬件機時間的一些想法。
更大限度地減少機時間
作為模型構建者，當您在訓練過程中遇到錯誤時，關鍵的挑戰是識別原因、找到問題并找到一種方法來保持工作進展以避免延誤。在需要工程師干預以進行恢復的環境中，這種延遲會進一步加劇，這通常會增加 triage 和 remediation 的時間。
由于這些干預和延遲會對工作效率產生重大影響，因此務必要有一個指標來反映您的實際體驗以及在將訓練重新上線時遇到的困難。傳統指標，例如主要反映硬件利用率的 MFU 和衡量平均故障間隔時間的 MTTF，側重于基礎設施效率，而非完整的訓練體驗。它們沒有完全考慮您的觀點，即不僅因崩潰而損失的時間，還包括 checkpoint、因錯誤而損失的工作以及 restart 所損失的時間。
為了捕捉這些真實世界的成本和痛點，我們專注于停機時間，即從模型構建器的角度來看，非生產性訓練的總時間。這包括以下內容：
- 檢查點時間：訓練循環被阻塞以保存檢查點。
- 丟失的工作 ：迭代在關閉前的最后一個檢查點后丟失。
- 關閉時間： 從上次迭代到系統停止。
- 重啟時間： 從作業啟動到重新開始富有成效的訓練
當硬件或基礎架構發生故障時，這些問題都會受到影響。因此，在我們尋求改善開發者的訓練體驗時，downtime 是嘗試最小化的關鍵指標。
在整個訓練過程中，減少機時間既需要反應靈敏的系統，也需要主動式系統。大規模出現錯誤是不可避免的，而檢測和恢復的速度至關重要。對于應用程序和硬件故障，錯誤屬性是關鍵。
系統必須確定問題是否需要用戶干預，或者是否可以自動解決，例如，通過排除不良節點并自動重啟，或在通知用戶之前多次重試。在本文中，我們主要側重于改進錯誤屬性，將恢復時間和特定自動化技術留待未來研究。
錯誤歸因
對于錯誤歸因，我們將研究人員遇到的錯誤大致分類為以下主要類別：
- 即時崩潰 ：起源于硬件故障，如 BIOS、電源或熱問題、不可糾正的 ECC 錯誤、無提示的數據損壞（中間結果中的 NaN）或網絡不穩定（鏈路抖動）。
- 通信庫中掛起 ：通常表現為 PyTorch NCCL watch dog 錯誤和 Transformer Engine 通信掛起。掛起通常是由于從文件系統 (例如，輸入數據) 和從張量 (例如，梯度、中間激活函數等) 傳輸數據時的級聯依賴性，特別是在東西向 (E/W) 網絡中。這凸顯了在庫和應用中對穩健的容錯、遏制和早期檢測機制的需求。
- 速度回歸 ：這些包括瞬時減速 (例如，臨時網絡或存儲問題) 和持續瓶頸 (例如，大型集群中的 GPU 持續緩慢)。這些回歸會顯著影響整體訓練速度和效率。
雖然此類故障可能源于底層硬件、基礎設施或軟件問題，但從您的角度來看，它們通常會顯示為訓練期間的突然中斷或嚴重減速。通過識別這些常見的故障模式，我們可以更好地開發解決方案和流程，使研究人員能夠保持勢頭并保持工作流程向前發展。
圖 1 突出顯示了 6K GPU 訓練運行中不同故障類型的分布。雖然研究人員通常會將這些故障視為單個錯誤，但要找出根本原因，還需要進行更深入的分析。我們發現，關聯集群、節點和應用程序遙測可提高速度和準確性，從而提供有效的補救策略
集群遙測
此遙測包括存儲服務器，涵蓋元數據操作、讀/寫操作和交換機。這種可見性至關重要，因為一個節點的故障通常會通過通信調用、傳遞損壞的梯度或使存儲系統過載而擴散到其他節點。
例如，如果單個作業因生成過多元數據操作而使存儲節點不堪重負，則其他作業或節點可能會因此遇到性能問題。
節點遙測
節點級別的定期健康檢查可確保關鍵的硬件和軟件組件（例如 GPU、CPU、內存、網絡、存儲和服務）正常運行。作業開始前的初步檢查還會驗證硬件狀態、驗證軟件依賴項以及為任務配置環境。
這種對潛在問題的早期檢測可縮短調試時間并提高整體可靠性。作業完成后，清理例程回收資源、存儲日志并將系統恢復到清理狀態。這些也稱為 prolog 和 epilog 腳本。
應用程序日志
應用對關鍵控制點、不變量和進度衡量標準（包括系統錯誤和性能模式）擁有關鍵知識。它們為錯誤屬性提供了最強大的信號之一，尤其是在與中央存儲庫中的歷史數據關聯以發現隨時間推移反復出現的故障時。
例如，這些日志有助于確定是否存在掉隊者、掛起，或者故障是否間歇性或反復發生。某些錯誤 (例如 NaN 錯誤) 在相同的迭代和秩中確定性地出現，但不同的物理節點可能是應用程序錯誤。但是，在無此類模式的節點上反復出現的相同錯誤可能表明硬件故障更加嚴重。
統一遙測
在 作業內部 (單個作業內) 和 作業間 (跨多個作業) 上下文中分析這些時間數據有助于識別反復出現的問題、檢測模式，并采取主動措施，而不是被動反應。
通過推薦、警報和可視化，運營團隊和研究人員可以共享這種統一的遙測數據，確保這兩個團隊對系統行為和故障模式有一個共同的看法。
這種遙測的交叉授粉意味著研究人員可以利用基礎設施數據來改進調試，而運營團隊則使用應用程序見解來改進系統自動化，以減少硬件停機時間。
雖然機時間是規模的函數，但對于使用約 1 萬個 GPU 運行的訓練，由于這些技術的硬件故障，我們實現了不到 1%的機時間。我們的結果是在 NVIDIA DGX Cloud 上針對 2024-2025 年運行的 Nemotron 模型系列訓練取得的。我們將硬件機時間計算為所有作業中可歸因于硬件故障的總機時間的百分比平均值。
結語
我們發現，端到端彈性需要一個整體的視角。長的正常運行時間取決于涵蓋基礎架構和開發者體驗的綜合方法。
這種方法可以連接應用程序和基礎設施，提高調試速度和準確性，同時實現更主動的系統。它可以幫助研究人員在發生故障時高效解決問題，并減少在診斷反復出現的問題時出現的摩擦。對于模型構建器而言，強大的錯誤歸因系統對于實現有效的自動化至關重要。借助這種自動化技術，研究人員無需全天候監控作業即可訓練模型。
除了充分利用 GPU 之外，這還可以幫助您和 DGX Cloud 上的其他研究人員專注于真正重要的事情：開發模型、推動科學發展，以及將繁重的工作交給我們。
如需了解有關在 DGX Cloud 上訓練彈性服務的更多信息，請報名參加 Cloud-Native Approach to Achieving Training Resilience and Efficiency at Extreme Scale GTC 會議。如需詳細了解我們如何加速您的預訓練和后訓練工作負載，請聯系我們。
?
?
