如何在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訓練的組織，理解故障模式並建立多層次檢測機制是保障生產力的關鍵。