一塊性能不達標的GPU就可能拖慢整個分布式訓練任務的速度。該節點可能通過了基本健康檢查，利用率顯示正常，導致運維人員只有在工作負載運行後才發現問題。
這類問題可能出現在集群生命周期的任何階段。一個在交付時通過就緒檢查的GPU集群，會隨著節點更換、驅動程式更新檔和容量擴充而發生變化。如果不進行反覆驗證，最初的認證結果將不再反映集群的實際狀況。
這種可見性缺口會導致故障節點浪費算力，也會使健康節點出于謹慎而閒置。利用率指標可能掩蓋這些損失。有效產出（Goodput，即成功完成的工作量）是衡量集群效率更有用的指標。要維持集群的就緒狀態，需要在整個運維生命周期中進行驗證——包括配置變更後、容量增長時，以及修復後的節點重新投入使用之前。
NVIDIA DSX AI工廠平台匯聚了用於設計、構建和運維高效、具備彈性的AI工廠所需的各項技術。其開源軟體層NVIDIA DSX OS包含了用於配置、認證以及維護加速型Kubernetes基礎設施健康狀態的工具。
配置：NVIDIA AI集群運行時（AICR）為GPU優化的Kubernetes基礎設施建立了一個可復現的基線。它為網路、儲存、驅動程式等組件定義了版本鎖定的配置方案，並將這些方案渲染為可供現有部署工具使用的軟體包。
認證：NVIDIA集群就緒引擎（NVCRE）驗證集群是否已準備好運行生產工作負載。它使用AI工作負載和診斷工具測試GPU、網路和儲存，記錄認證結果並幫助識別故障節點。
運維：NVSentinel負責監控集群健康狀況，並支持故障修復與重新驗證。它會根據GPU、節點和網路的健康狀況發布節點狀態資訊。在配置完成後，它可以隔離或標記不健康的節點、清空工作負載並修復故障，還能在節點重新投入使用前觸發NVCRE進行重新驗證。
以上三個項目均為基於Apache 2.0許可證的開源項目，歡迎外部貢獻。
在開始之前，請使用各自的安裝指南安裝並配置AICR、NVCRE和NVSentinel。以下示例假設您已擁有一個配置好所需CLI工具、控制器、依賴項和NVCRE測試提供者的Kubernetes GPU集群。
本文將跟隨一個集群走完其整個生命周期：從配方進行配置、生產使用前的認證、運行期間的監控，以及修復後的重新認證。每條命令都是這一流程中的一個步驟。
配置：可復現的基線
AICR以版本控制的文件形式定義集群的軟體基線，並將其渲染為現有部署工具可以應用的產物。它負責生成和驗證，部署工具負責應用和協調。聲明式模板有助於檢測因手動更改而產生的配置偏差，並在修復後保持節點配置的一致性。
您只需描述目標環境，AICR會根據已驗證的覆蓋層庫進行解析，並生成一份配方：
```
aicr recipe --service eks --accelerator h100 --os ubuntu --intent inference --platform dynamo -o recipe.yaml
```
生成的配方中每個組件條目都鎖定了版本號，並聲明了該組件安裝前必須處於健康狀態的依賴項：
```
apiVersion: aicr.run/v1alpha2 componentRefs: - name: dynamo-platform chart: dynamo-platform namespace: dynamo-system source: https://helm.ngc.nvidia.com/nvidia/ai-dynamo type: Helm version: 1.4.2 valuesFile: components/dynamo-platform/values.yaml dependencyRefs: - grove - cert-manager - kube-prometheus-stack - gpu-operator - kai-scheduler
```
該配方包含三個關鍵特性：
版本鎖定：版本號是固定的，有助於復現軟體配置並排查故障。相比之下，浮動標籤可能隨時間指向不同的軟體版本，使故障難以復現。
依賴關係圖：dependencyRefs聲明了必須先安裝並保持健康狀態的組件。AICR在渲染軟體包時會解析該依賴圖，因此部署順序已編碼在部署工具所應用的產物中。您無需指定cert-manager必須在NVSentinel之前安裝，後續添加組件也不需要重新編號。
逐組件的健康斷言：每個條目都包含一個healthCheckAsserts模組，該模組在安裝後運行，檢查組件是否滿足所配置的健康標準。Kubernetes可能會將處於CrashLoopBackOff狀態的pod報告為Running，因此僅基於pod階段的檢查可能會漏掉損壞的組件。隨附的斷言會基於容器的等待原因進行過濾，而非僅依賴pod階段。
渲染配方是一個獨立的步驟，用於將AICR與您現有的流水線連接起來：
```
aicr bundle --recipe recipe.yaml --deployer argocd --output ./bundles
```
--deployer參數接受helm、argocd、argocd-helm、flux或helmfile，因此同一份已驗證的配方可以轉化為Argo CD應用程式清單、Flux資源、Helmfile發布圖，或普通的Helm命令。您可以保留現有的部署工具，利用AICR生成其所需的配置產物。
由於配方是以文件形式存在的，您可以利用版本歷史記錄、代碼審查和偏差檢測來管理基線。
```
# 根據配方約束檢查實時集群 aicr validate --recipe recipe.yaml # 將黃金基線與實時集群進行比較，若存在偏差則以非零狀態退出 aicr diff --baseline ./golden.yaml --target cm://default/aicr-snapshot --fail-on-drift
```
--fail-on-drift參數將偏差檢測轉變為持續集成（CI）環節中的一道關卡，而不僅僅是一份報告。
認證：證明集群能夠勝任任務
此時集群已按照既定基線構建完成，但仍需進行工作負載驗證。標準健康檢查只能確認基礎服務正在運行，無法確認集群能否在其互連網路上順畸地運行要求苛刻的多節點任務而不發生停滯。NVCRE通過運行訓練任務和NVIDIA集合通信庫（NCCL）測試來驗證工作負載的就緒狀態。
NVSentinel負責管理驗證請求、調度門控、隔離和修復，而NVCRE負責運行測試並記錄結果。下表展示了這些職責在節點驗證生命周期中的分工。
一份認證文件指定了待測試的節點、要運行的測試類別以及決定測試通過或失敗的閾值：
```
apiVersion: nvcre.nvidia.com/v1alpha1 kind: Certification metadata: name: gpu-cluster-cert spec: target: nodeSelector: nvidia.com/gpu.present: "true" categories: - domain: communication variant: nccl-all-reduce - domain: training variant: nemotron5-8b options: thresholds: busBandwidthGBps: "value >= 300"
```
```
nvcrectl certification run --cert-file certification.yaml --wait nvcrectl certification report gpu-cluster-cert -n
```
該報告展示了每個測試類別的狀態、運行時間、測得的頻寬以及任何失敗節點的原因。
閾值使認證成為一道性能關卡。默認情況下未配置任何閾值。如果沒有上述的options.thresholds模組，運行結果只會報告測量數據，僅在測試無法啟動時才會判定失敗。表現略低於目標值的節點仍可能通過。閾值有助於捕捉性能下降的情況，而非僅僅是硬體故障。
測試目錄涵蓋了NCCL通信變體、NVIDIA數據中心GPU管理器（DCGM）四級診斷套件，以及使用NVIDIA NeMo框架的80億參數和560億參數模型進行的預訓練工作負載測試。WorkloadRun資源可以將您自己的容器化測試轉變為一項認證檢查。NVCRE會從目標節點推斷出其餘資訊，因此清單文件在任何受支持的平台上都能保持簡潔。
這些測試有助於識別在遙測數據中並不明顯的性能問題。一塊性能略低於目標值的GPU可能不會產生Xid錯誤、不會突破監控閾值，也不會使節點指標顯得異常。但正是這一塊GPU就可能將同步訓練任務拖慢到最慢的那個等級，而運維人員可能要等數小時後才發現，甚至要等到用戶投訴才知曉。NCCL頻寬測試可以揭示這種性能下降問題。
隔離故障原因同樣重要。如果一個64節點的all-reduce操作產生了較差的頻寬，每個節點都有嫌疑，而手動逐一排查可能相當耗時。NVCRE會將失敗的組進行拆分並重新運行測試，直到達到最小分組規模，然後報告出有嫌疑的節點並說明各自的原因。
應在將集群或新增容量交付給租戶之前，以及修復後的硬體重新加入資源池之前，運行NVCRE。
運維：負載下的檢測與修復
經過認證的集群現在正在運行工作負載，需要保持健康狀態。AICR和NVCRE提供的是時間點驗證。NVSentinel則在工作負載運行期間持續運行。
NVSentinel監控集群已經產生的各類信號：DCGM健康檢查、Xid錯誤、網路接口卡（NIC）狀態以及雲服務商的維護事件。它不消耗GPU時間，使GPU可持續用於工作負載。
NVSentinel默認以監控模式安裝：它會將故障報告為節點狀態，但不會隔離、驅逐或修復節點。您可以在實時集群上部署該工具，同時評估其報告內容。在確信所報告的信號可靠後，您可以啟用隔離、清空和修復功能。
檢測會發布一個健康事件；故障隔離規則集決定了該節點將面臨的處理方式。規則集在配置文件中使用通用表達式語言（CEL）表達式：
```
fault-quarantine: ruleSets: - enabled: true version: "1" name: "GPU fatal error ruleset" priority: 100 match: all: - kind: "HealthEvent" expression: "event.agent == 'gpu-health-monitor' && event.componentClass == 'GPU' && event.isFatal == true" - kind: "Node" expression: | !('k8saas.nvidia.com/ManagedByNVSentinel' in node.metadata.labels && node.metadata.labels['k8saas.nvidia.com/ManagedByNVSentinel'] == "false") cordon: shouldCordon: true taint: key: "nvidia.com/gpu-error" value: "fatal" effect: "NoSchedule"
```
隔離或標記操作會提供一個信號，供您的調度器、告警系統和生命周期管理工具使用，而無需直接與NVSentinel集成。
斷路器機制通過限制在一個滑動時間窗口內可被隔離的GPU節點數量來控制影響範圍。故障隔離配置指南詳細說明了限制範圍以及其餘的規則集選項。
並非每個故障都走相同的處理路徑。已知的致命錯誤會直接進入修複流程。健康事件分析器通過檢測節點故障歷史中的模式來處理其他情況，因此一個反覆發生故障的節點會基於累積的記錄（而非單一事件）被納入調查範圍。
帶有CONTACT_SUPPORT建議操作標籤的健康事件需要人工調查或技術支持介入。
閉環：就緒狀態如何實現持續化
一個節點發生故障、經過修復後需要重新加入資源池。節點重新投入使用前的驗證可以閉合這一運維環節，但人工交接可能會打斷這一流程。人工認證只能產生某一時間點的結果，而常規運維操作可能使其過時。必須有人注意到集群發生了變化，重新運行驗證，然後讀取輸出結果並採取相應行動。NVSentinel和NVCRE可以幫助實現這一流程的自動化。
兩類生命周期事件在配置完成後會自動觸發重新驗證。NVSentinel生命周期控制器會在節點加入集群時以及節點經過修復重新上線時創建一個ValidationRequest（驗證請求）。它會使用隔離或標記手段對該節點的調度進行門控，然後使用NVCRE運行測試並記錄結果。控制器會評估這些結果，並在測試通過後移除門控，因此一個仍未通過驗證的節點無法悄然重新加入資源池。當您將nvcre-provider配置為其測試提供者時，這些測試就是通過NVCRE運行的NCCL或NVIDIA Nemotron測試：
```
global: lifecycleManager: enabled: true fault-quarantine: validation: enabled: true lifecycle-manager: config: schedulingGate: cordon: remove: true
```
lifecycle-manager配置圖啟用了新節點驗證功能；fault-quarantine標誌則單獨選擇啟用修復後的驗證功能。schedulingGate.cordon將隔離設置為驗證的調度門控，而remove: true則會在節點測試通過後取消隔離。
對於就地驅動程式升級、運維工具升級或網路結構變更而言，處理流程有所不同。這些變更不會自動觸發驗證。由於基線是以文件形式存在的，aicr diff --fail-on-drift命令會在實時集群偏離其配方時使流水線階段失敗，從而在進行變更的同一流水線中觸發認證運行。
先隔離受影響的節點，然後創建一個指定這些節點及待運行測試的驗證請求：
```
apiVersion: nvsentinel.nvidia.com/v1alpha1 kind: ValidationRequest metadata: name: post-driver-upgrade spec: nodes: - name: node-a - name: node-b tests: - nccl-all-reduce - nemotron-5b
```
控制器同樣會根據結果採取行動。如果請求通過，一旦沒有其他測試占用該節點，控制器就會移除調度門控。如果測試在重試後仍失敗，該節點將保持隔離狀態。
故障也可能在驗證期間顯現：例如GPU可能在訓練測試過程中開始出現熱節流現象。此時NVSentinel會隔離該節點，控制器會在修復後重新運行測試。該節點將保持門控狀態，直至通過驗證。
驗證請求和節點都帶有可供查詢的狀態資訊：
```
kubectl get validationrequests kubectl get nodes -l nvsentinel.nvidia.com/validation-state=validation-failed
```
恢復過程無需手動編輯節點：之後一次通過相同測試的請求會清除失敗記錄並移除門控。刪除所有引用該節點的失敗驗證請求也可以釋放該節點，而無需重新運行驗證。
兩者之間的職責邊界十分清晰。NVCRE的職責止步于歸因，即記錄哪些節點失敗以及失敗的原因；而NVSentinel則負責隔離和修復。如果兩個系統同時對同一節點進行隔離，可能會導致重複隔離和清理不同步的問題。
這種職責分離同樣使您可以使用自己的節點生命周期管理工具。平台團隊可以使用相同的認證結果，並承擔起NVSentinel的角色。擴展這套技術棧只需編寫一個規則集或策略即可，而無需分叉（fork）整個項目。
這對運維人員意味著什麼
AICR、NVCRE和NVSentinel幫助運維人員使配置、驗證和恢復流程變得可復現。在啟用修復和生命周期驗證功能後，NVSentinel可以在節點重新投入使用前協調修復和測試工作，減少人工交接環節。下表概述了這些工具所涵蓋的工作範圍，以及仍需運維人員管理的內容。
開始使用
請參閱各項目倉庫中的安裝說明和示例以入手：
NVIDIA AI集群運行時（AICR）
NVIDIA集群就緒引擎（NVCRE）
NVSentinel
您還可以：
在與KubeCon + CloudNativeCon North America同期舉辦的NVIDIA DSX OS AI推理與貢獻者工作坊中親身體驗這些工具。需單獨註冊，座位有限。
訪問KubeCon展會上的NVIDIA 170號展位，了解更多Kubernetes深度解析內容並觀看現場演示。
加入DSX AI工廠Slack社區，繼續參與相關討論。
在NVIDIA DSX AI工廠GitHub頁面探索開源的模組化組件。
