訓練大模型嘅「AI 廠」，一次任務好幾百個節點跑上幾日甚至幾星期。呢種規模落，硬件異常、軟件錯誤、網絡超時、資源競爭，任何一個出錯都未必即時爆，但拖落去就係算力白燒。NVIDIA 話，靠人手介入、靜態 checkpoint（快照）同被動監控呢套舊做法，已經追唔上。
26 日 NVIDIA 喺技術博客（NVIDIA Technical Blog）出文，講 Mission Control 2.5 點樣把「自主恢復引擎」(autonomous recovery engine) 擴展到 Kubernetes 工作負載。之前呢個引擎只能用喺用 Slurm 排程嘅高性能計算 (HPC) 工作負載，而家由 Run:ai 管理嘅 Kubernetes 負載都涵蓋。
自主恢復引擎分兩層：
自主任務恢復：盯住跑緊嘅 job，跟佢喺邊度執行，再根據失敗歷史同 job 拓撲 (topology) 判斷應該走邊條恢復路徑；同資源管理器對接，決定係重啟、重試、重新排隊定重新排落邊度。
資料圖片：Pixabay
自主硬件恢復：監視節點同 GPU，需要時把異常硬件移出排程，跑診斷同修復，令硬件問題唔會繼續擴散去新嘅 job。
呢兩層同排程器（HPC 用 Slurm，Kubernetes 用 Run:ai）組成一個「三層框架」，各管各嘅份、協調行。NVIDIA 嘅説法係，呢個唔係單一恢復功能，而係一個控制迴圈 (control loop)：即時偵測失敗、按工作負載情境同故障類型做智能判斷、喺最小干預同最低浪費下自動復工。
講直白啲：之前係「出事先叫工程師救火」，而家目標係「火未起就滅咗、燒壞嘅自動換掉、job 自動返工」，將 AI 廠由「被動維修」轉做「主動自愈」。(示意圖)
資料圖片：Pixabay
幾點要留意：
- 呢篇係 NVIDIA 自己嘅技術博客，係產品功能推廣性質，唔係獨立實測。文中「即時偵測」「智能判斷」係廠商嘅描述，本站未實際運行 Mission Control 2.5。
- 無第三方效能數字、無 MTTR 實際數據，全部係功能説明，唔等同已獨立驗證。
- 自主恢復引擎之前已經存在（限 HPC/Slurm），呢次係擴展到 Kubernetes/Run:ai，唔係全新開發。
模姐驗嚇貨：Kubernetes 排程落 AI 廠，係而家好多數據中心嘅真實路線，唔係玩具案例。Mission Control 2.5 呢個版本，係把已有嘅 HPC 自愈能力，過數到更多人用嘅 Kubernetes 生態。問題唔係「有冇自修復」，而係邊個掌握排程同恢復嘅決定權——呢次答案係 NVIDIA 自家軟件。你嘅 AI 廠用邊套排程、邊套自愈，先決定成日嘅算力成本同穩定度。(示意圖)
模姐｜深度調教
