如何在Databricks AI中保持GPU的可靠性

在Databricks AI，大規模分佈式GPU訓練已成為常態。然而，隨着集羣規模的擴大，GPU故障變得頻繁且不可避免。本文將深入探討如何通過系統化的方法保持GPU在高負載下的可靠性。

GPU在大規模訓練中的失敗模式

大規模GPU訓練中的故障大致可分為三類。第一類是任務崩潰（Crashed Jobs），這是最直觀的故障，表現為訓練作業突然停止並出現NCCL看門狗超時錯誤。然而，超時本身通常無法揭示根本原因，需要跨硬件、網絡、文件系統和軟件層進行診斷。第二類是靜默降速（Silent Slowdowns），這種故障下訓練看似正常，損失函數也在下降，但整體吞吐量受限於最慢的GPU，導致計算資源和資金的浪費。靜默降速通常源於硬件在降級狀態下運行，例如熱傳感器觸發、互連鏈路降速或內存帶寬下降。第三類是數值錯誤（Numerical Corruption）。現代GPU使用ECC（錯誤校正碼）技術自動修正瞬時內存錯誤，但並非所有錯誤都能恢復。未恢復的錯誤可能導致NaN損失、不穩定的收斂或模型質量下降，甚至需要事後才能發現。

壓力測試與健康檢查系統

Databricks AI採用獨特的策略來應對這些挑戰。首先，通過運行多樣化的極端工作負載（如強化學習訓練、智能體編碼模型、文檔智能系統）來對平台進行壓力測試。這些工作負載以不同方式考驗平台，從而提前暴露網絡問題、熱熱點或集體通信的邊緣情況。例如，一次訓練運行在7小時後因NCCL超時而失敗，最終追溯到單個Infiniband端口的一次長時間中斷。這一發現促使團隊調整了NCCL_IB_TIMEOUT參數，使其更具韌性。

其次，團隊構建了名為gpu-monitor的多階段健康檢查系統，運行在每個GPU節點上，覆蓋節點整個生命週期。該系統包含三個層次：

• 主動引導檢查：在節點首次部署和工作負載啓動前執行，驗證GPU計算速度、GPU間點對點連接、節點內NCCL通信、RDMA帶寬、ECC內存健康、PCIe拓撲和NVIDIA DCGM診斷等。未通過檢查的節點立即從集羣中移除。
• 被動連續檢查：在節點運行期間持續監控，捕捉非確定性故障，如NVLink鏈路狀態、GPU時鐘降頻原因、RDMA端口狀態（基於累積停機時間而非抖動次數）、關鍵XID錯誤、PCIe AER錯誤、熱梯度和NVSwitch錯誤狀態。失敗的節點會被隔離並重新測試。
• 定期多節點主動檢查：在客户工作負載之間的空閒節點上運行，驗證節點間互連行為。這些檢查包括從8字節到2GB的NCCL集合通信帶寬探測，覆蓋不同算法路徑（小消息的延遲主導、中消息的樹/環切換、大消息的帶寬限制）。檢查標準根據有效載荷大小設定不同的延遲或帶寬閾值。

這三個層次協同工作：在啓動前驗證硬件，運行時監控狀態，在空閒時驗證整體網絡。隨着新故障模式的出現，團隊不斷更新gpu-monitor並部署到整個集羣。

結論

GPU可靠性是一個系統性工程。Databricks AI通過壓力測試和健康檢查系統的結合，將故障對訓練的影響降到最低。本文只是系列的第一篇，後續將涵蓋更高級的可靠性策略，如調度規避、優雅恢復等。對於任何運行大規模GPU訓練的組織，理解故障模式並建立多層次檢測機制是保障生產力的關鍵。