輝達發布 NVIDIA Recovery，偵測 AI 訓練停滯並協調重啟

輝達（NVIDIA，NVDA）發布開源服務「NVIDIA Recovery」，可偵測分散式人工智慧（AI）訓練工作發生衝突、停滯或處理量下降，並協調重啟。這項服務依管理員設定和個別工作政策調整重啟，目前仍處於實驗階段。

輝達 DSX 官方文件將 Recovery 列為 DSX OS 的「狀態管理與韌性」元件。公開程式碼儲存庫和官方文件均標示採用 Apache 2.0 授權。

DSX OS 文件將其描述為用於建置、營運及擴展 AI 工廠基礎設施的模組化開源軟體。輝達在10月21日的公告中表示，DSX OS 可自動化基礎設施生命週期，並改善狀態自動化與韌性功能。

分散式訓練會把工作分配到多個 GPU 和節點執行。若其中一個程序失敗或工作停住，分配給該工作的所有 GPU 都可能無法繼續訓練。

排程器可以重新執行已結束的工作；若工作沒有結束、只是停止前進，就需要監測其進度訊號。Recovery 的設計用途之一，就是偵測這類停滯。

偵測機制會使用管理員設定的日誌模式和訓練進度訊號。衝突偵測會尋找 PyTorch、NCCL、CUDA 或 GPU 連線錯誤等跡象；停滯偵測則會檢查預期的進度訊號是否中斷。

處理量下降也列入偵測項目，但預設不會因此自動啟動復原。管理員必須另行啟用，系統才會依這項條件採取復原措施。

偵測到問題後，Recovery 會記錄失敗嘗試和重試政策。預設部署採觀察模式，不會變更排程器。管理員啟用動作模式和排程器工作核准設定，且工作政策允許重試後，系統才會將重啟建議傳給排程器整合元件。該元件會重新安排或重新啟動工作，並確認要求的狀態是否實際生效。

若有 NVIDIA Attribution 提供的診斷依據，系統可排除特定節點。重試次數則受個別工作設定和管理員政策限制。

目前已實作的排程器整合為 Slurm。輝達先前也公布 AI 叢集的 Kubernetes 設定範例；不過，Recovery 對 Kubernetes 的支援僅限於透過 Slinky 執行 Slurm，尚未實作 Kubernetes 原生工作的復原功能。

輝達文件列出的 GPU 叢集支援範圍從 Ampere 到 Blackwell。文件將這項支援範圍與產品的排程器整合範圍分開說明。

重新啟動工作不代表訓練進度會自動恢復。訓練應用程式必須先把模型狀態以檢查點形式存入持久性儲存，再由重啟後的工作載入。Recovery 不會建立檢查點檔案，也不會複製模型狀態。

重試工作可能需要等待 Slurm 分配資源。因此，檢查點是否備妥，以及排程器何時分配資源，都會影響訓練實際恢復的時間。

預設設定會啟用 NVIDIA Attribution；使用者須取得經核准的提供者來源存取權限。即使關閉 Attribution，依政策復原仍可運作，但無法使用非公開的根因診斷，也不能依據診斷結果排除節點。

輝達將 Recovery 列為實驗階段，並表示尚未準備好用於正式環境。介面和行為可能改變，產品也不保證能在正式環境規模下維持營運、可用性或復原時間。輝達未提供縮短復原時間的比例或實際營運成效數據。