NVIDIA Mission Control 2.5 擴展自主恢復引擎至 Kubernetes 工作負載

背景

AI 工廠（AI Factory，專為處理 AI 生命週期而設計的運算基礎設施）的核心產品是透過 Token 吞吐量來衡量的智慧產出。隨著現代 AI 工廠在數百個節點上執行分散式訓練工作負載，硬體異常、軟體錯誤與網路超時等問題必須被主動管理，以維持工作負載的穩定性。傳統依賴人工介入與靜態檢查點的反應式監控，在共享基礎設施上同時執行數十個多節點工作負載時，已無法有效擴展。 官方原文・NVIDIA Developer Blog 官方原文・nvidia.com

發生什麼事

NVIDIA 於 10 月 26 日發布 Mission Control 2.5 版本。此次更新的核心變更，是將原本僅限於使用 Slurm 的高效能運算（HPC）工作負載的自主恢復引擎（Autonomous Recovery Engine，能偵測、診斷並從堆疊中的異常進行恢復的服務），擴展至由 NVIDIA Run:ai 管理的 Kubernetes 工作負載。這意味著 Kubernetes 使用者現在也能利用該引擎進行異常偵測、診斷與恢復。 官方原文・NVIDIA Developer Blog

重點內容

自主恢復引擎由兩個服務組成：自主工作負載恢復（Autonomous Job Recovery，監控工作並根據上下文決定恢復路徑）與自主硬體恢復（Autonomous Hardware Recovery，監控節點與 GPU 並執行診斷或修復）。在 Kubernetes 環境中，NVIDIA Run:ai 作為預設排程器，負責管理工作負載佇列與政策。自主工作負載恢復服務監控執行中的工作，利用失敗歷史與工作拓撲來分類恢復路徑；自主硬體恢復服務則監控節點與 GPU，將異常從排程中移除並執行診斷。 官方原文・NVIDIA Developer Blog

該系統透過三種情境展現其運作邏輯。首先，當訓練期間發生硬體故障（如 ECC 錯誤（記憶體錯誤校正錯誤）或通訊超時），系統會平行處理：工作負載恢復服務識別可疑節點並重新排程工作，同時硬體恢復服務隔離該節點並啟動診斷，減少停機時間。其次，面對暫時性軟體故障，系統會根據工作上下文避免過度反應，僅依排程政策重試，而不隔離健康的硬體。最後，系統能提前偵測硬體退化，在故障影響工作負載前主動將節點從排程資格中移除。 原文

除了自主恢復功能的擴展，Mission Control 2.5 的其他亮點包括：新增 AI 驅動的網路異常偵測服務（僅限 Beta 測試）、透過中央 Keycloak（開源身分與存取管理解決方案） 改善跨服務的認證使用者體驗、額外的安全性與 Kubernetes 強化更新，以及提供 NVIDIA Vera Rubin NVL72 的早期存取支援。此外，對 NVIDIA GB200 NVL72、GB300 NVL72 及基於 Blackwell 架構的 DGX 系統持續提供增強與錯誤修復。 原文

對使用者的意義

對於平台團隊而言，Mission Control 2.5 提供了跨 Kubernetes 與 Slurm 環境的一致恢復模型，確保故障節點被隔離、記錄與診斷，僅在準備好時才重新投入服務。對於 AI 從業者，無論使用 Slurm 或 Kubernetes，工作負載皆可依現有排程器進行重啟、重試或重新排隊，同時利用自主恢復引擎提供的上下文資訊，避免在需要維護的基礎設施上重複失敗。這有助於企業更有效地利用昂貴的加速器容量，減少因不確定性而導致的停滯。 官方原文・NVIDIA Developer Blog

接下來要看的事

• NVIDIA Vera Rubin NVL72 的正式發布時間與規格細節
• AI 驅動的網路異常偵測服務從 Beta 轉為正式版的時間表
• Mission Control 2.5 在實際生產環境中的故障恢復時間（MTTR）數據