2026 年 11 月 5 日，NVIDIA 在技術博客發表文章，介紹 DSX AI Factory Platform 的開源軟件層 DSX OS，並以一間叢集的完整生命週期作示範，由配置配方、投產前認證、運行期監察，到維修後重新認證逐步說明[1]。三套工具分別是 AI Cluster Runtime（AICR）、Cluster Readiness Engine（NVCRE）與 NVSentinel，全部以 Apache 2.0 授權開源，並接受外部貢獻。
由配方取代人手調參
NVIDIA 指出，一張表現欠佳的 GPU 足以拖慢整個分散式訓練工作，但該節點往往通過基本健康檢查，使用率數字亦看似正常，營運人員要等負載真正跑起才發現問題。使用率之所以會掩蓋損失，是因為它只反映 GPU 有幾忙，而非有幾多工作真正完成，官方因此以 goodput 作為衡量叢集效率的指標。
AICR 的做法，是把驅動程式、網絡、儲存等元件的驗證組合寫成鎖定版本的配方。每項元件都釘住版本、宣告依賴關係，並附帶安裝後執行的健康檢查斷言。NVIDIA 舉例，一條指令即可按服務、加速卡、作業系統、用途與平台生成配方，再渲染成 Argo CD、Flux、Helmfile 或純 Helm 可用的部署產物，團隊毋須放棄現有工具鏈。
配方以檔案形式存在，意味可以納入版本控制與代碼審查。AICR 另提供差異比對功能，配合 --fail-on-drift 參數，可把配置漂移檢查變成持續整合的關卡，而非一份事後報告。官方又提到，健康斷言會檢查容器的等待原因，而非只看 Pod 階段，因為處於 CrashLoopBackOff 的 Pod 在 Kubernetes 眼中仍顯示為 Running。
認證回答跑不跑得動
配置正確不等於跑得動。NVCRE 以 NCCL 集合通訊測試與真實訓練工作負載驗證節點，並可設定頻寬等門檻，例如要求 bus bandwidth 不低於每秒 300GB。當一組節點的測試結果不理想，NVCRE 會把失敗的群組切開重測，逐步收窄範圍，直至找出可疑節點及其原因，避免一次過把幾十個節點全部當成故障。
在整個流程中，NVSentinel 負責管理驗證請求與排程閘門，NVCRE 只負責執行測試與記錄結果，不會改動節點狀態。認證結果寫入 Certification 資源，包含通過與否、失敗節點編號及原因，讓生命週期控制器判斷能否解除閘門。官方強調這種分工有實際作用：若兩套系統同時封鎖同一節點，會出現重複封鎖與清理不同步。
營運期持續監察與自動修復
NVSentinel 被動接收叢集本身已產生的訊號，包括 DCGM 健康檢查、Xid 錯誤、網絡介面狀態與雲端服務商的維護事件，因此不佔用 GPU 時間。預設以監察模式安裝，只把故障報告為節點狀況，不會封鎖、驅逐或修復；營運人員可按需要開啟自動處置。
開啟後，當節點加入叢集或維修後返回，生命週期控制器會建立驗證請求，以封鎖或污點限制排程，再交由 NVCRE 執行測試，測試通過才移除閘門。NVIDIA 稱這可以減少人手交接，仍未能通過驗證的節點不會無聲地重新投入服務。官方同時提醒，就地更換驅動程式、操作器或網絡結構等改動，不會自動觸發重新驗證，需要營運人員自行發起。
三套工具的設計取向是擴展而非分支：團隊可以撰寫規則集或策略去調整行為，不必自行維護一套分叉版本。對於把 GPU 叢集當成生產設施來經營的團隊，這種把配置、認證與修復串成閉環的做法，比單獨一個監察工具更貼近實際需要。
參考資料
[1] Configure, Certify, and Operate Kubernetes GPU Clusters with NVIDIA DSX OS（2026年11月5日）