背景
隨著分散式 AI 訓練規模擴大，硬體與軟體依賴的故障日益頻繁，導致訓練進度中斷。單一處理程序失敗、集合通訊停滯或掉隊者（straggler，指拖慢整體訓練進度的慢速工作節點）都可能打斷整個 GPU 資源池的進度。傳統上，恢復過程需要工程師手動分析日誌、隔離故障並從檢查點（checkpoint）重啟，這在叢集規模下難以全天候維持，且會造成 GPU 閒置與計算成本增加。 官方原文・NVIDIA Developer Blog 官方原文・github.com
發生什麼事
NVIDIA 於 2026 年 11 月 2 日發布 NVIDIA Recovery，這是 NVIDIA DSX OS 的一部分，屬於開源的工作負載層級服務。該工具旨在自動化叢集中訓練工作的恢復流程，透過偵測中斷、歸因故障並協調隔離與重啟，來維持訓練的有效產出（goodput，指系統將實際時間轉化為有效訓練進度的效率）。 官方原文・NVIDIA Developer Blog
重點內容
NVIDIA Recovery 的自動化迴圈包含四個階段：偵測（Detect）、歸因（Attribute）、隔離（Isolate）與重啟或停止（Restart or Stop）。偵測階段結合應用程式日誌、GPU 指標與排程器信號，識別崩潰（crashes）、掛起（hangs）與掉隊者（stragglers）。歸因階段利用 NVIDIA Attribution 區分硬體故障、系統軟體問題或應用程式錯誤，以指導恢復動作。隔離階段會將受影響的節點從後續重啟嘗試中排除，並透過看門狗服務（watchdog service）防止工作負載無限等待。重啟階段則透過排程器整合，從最後儲存的檢查點恢復訓練。 官方原文・github.com 官方原文・NVIDIA Developer Blog
該工具支援 NVIDIA GPU 叢集，涵蓋從 Ampere、Hopper 到 Blackwell 架構，並整合 Slurm 排程器（包括透過 Slinky 專案在 Kubernetes 上運行的 Slurm）。目前尚未實作原生 Kubernetes 工作負載恢復。部署時，使用者需安裝 Helm chart，並透過在 sbatch 提交腳本中添加註解指令來啟用監控或行動模式。新部署預設為監控模式（monitor mode），僅發布建議而不執行動作，待驗證後可切換至行動模式。 官方原文・github.com 官方原文・NVIDIA Developer Blog
對使用者的意義
對於管理大型分散式訓練的開發者與企業，NVIDIA Recovery 可減少凌晨人工處理故障的需求，並降低因故障導致的 GPU 閒置時間。根據 NVIDIA 在一個訓練叢集的觀察，該工具每日監控近 200 個工作，記錄約 8,550 次異常偵測，平均偵測延遲為 69 秒，平均恢復動作延遲為 94 秒。使用者可透過 GitHub 取得原始碼與 Helm charts，並利用本地快速入門指南在無需實體 GPU 的情況下測試。 官方原文・NVIDIA Developer Blog
限制與未定事項
NVIDIA Recovery 目前處於實驗階段，尚未準備好用於生產環境，其 API、配置與行為可能會變更。NVIDIA Attribution 預設啟用，但其原始碼尚未公開可抓取，本地演示需明確選擇關閉該功能。此外，該工具管理工作負載，但不負責硬體維修或檢查點儲存。原生 Kubernetes 恢復功能仍在開發路線圖上，未來將支援 JobSet 與 Kubeflow PyTorchJob。 官方原文・github.com 官方原文・NVIDIA Developer Blog
