NVIDIA DSX OSで実現するGPUクラスタの構成・認証・継続運用
DSX OSが提供する構成・認証・運用の統合モデル
NVIDIA DSX AI Factory Platformのオープンソースソフトウェア層であるNVIDIA DSX OSは、Kubernetes上のアクセラレーテッド・インフラを「構成」「認証」「運用」の3段階で管理する。対象となるのは、クラスタの導入時だけではない。ノード交換、ドライバー更新、容量追加、修理後の復帰といったライフサイクル上の変化に応じて、構成とワークロード適性を繰り返し検証する仕組みだ。
この設計が重視する指標は、GPU利用率だけではなく、完了した仕事量を表すgoodputである。分散学習では、正常に見えるGPUが1台だけ性能目標を下回っても、同期処理が最も遅いrankに引きずられ、ジョブ全体の進行が損なわれる可能性がある。基本的な稼働状態や利用率だけでは、この種の性能劣化を捉えられないことがある。
DSX OSの各コンポーネントは次のように役割を分ける。
- **NVIDIA AI Cluster Runtime（AICR）**は、GPU向けKubernetes基盤の再現可能なソフトウェアベースラインを定義し、既存のデプロイツール向け構成成果物を生成する。
- **NVIDIA Cluster Readiness Engine（NVCRE）**は、GPU、ネットワーク、ストレージを対象に診断やAIワークロードを実行し、本番ワークロードを動かせる状態かを検証する。
- NVSentinelは、GPU・ノード・ネットワークの健全性を継続監視し、設定に応じて障害ノードの隔離、ワークロードの退避、修復、再検証を支援する。
3つのプロジェクトはいずれもApache 2.0ライセンスのオープンソースとして公開され、外部からの貢献を受け付ける。
AICR：バージョン固定のレシピをデプロイ基盤へ接続する
AICRは、対象環境を指定して、検証済みオーバーレイのライブラリに基づくレシピを生成する。記事では、EKS、H100、Ubuntu、inference、Dynamoを指定する例が示されている。生成されるレシピでは、コンポーネントごとにバージョン、Helmチャートの取得元、namespace、valuesファイルなどを記述する。
このレシピの要点は3つある。
-
バージョン固定：コンポーネントのバージョンを固定することで、同じソフトウェア構成の再現や、障害発生時の条件比較をしやすくする。時間とともに参照先が変わる浮動タグと異なり、「同じレシピなのに実体が変わる」問題を避けやすい。
-
依存関係の明示：
dependencyRefsに、先に導入され、健全であるべきコンポーネントを記述する。AICRはバンドル生成時に依存グラフを解決するため、デプロイ成果物に適用順序を反映できる。 -
コンポーネント単位のヘルスアサーション：インストール後に各コンポーネントの健全性を確認する。Podのphaseが
Runningでも、コンテナがCrashLoopBackOffに陥っているケースを見落とさないよう、同梱アサーションはPod phaseだけでなくコンテナのwaiting reasonを確認する。
AICRは構成を生成・検証するが、クラスタへの適用と継続的な調整は利用者のデプロイツールが担う。aicr bundleは、helm、argocd、argocd-helm、flux、helmfileを出力先として指定できる。これにより、既存のデプロイ基盤を維持したまま、AICRで生成した構成成果物を利用できる。
また、レシピをバージョン管理されたファイルとして扱うことで、コードレビューや履歴管理が可能になる。aicr validateでライブクラスタをレシピの制約に照らして確認し、aicr diff --fail-on-driftでベースラインとの差分を検出すれば、ドリフトをCIの失敗条件にできる。
NVCREとNVSentinel：性能認証から復旧後の再参加まで
構成がベースラインに合致していても、実際の分散ワークロードに耐えられるとは限らない。NVCREはNCCL通信テストや学習ジョブを実行し、測定値と設定された性能しきい値に基づいてクラスタの準備状態を評価する。認証対象ノード、実行カテゴリ、合否のしきい値はCertificationリソースで指定する。
記事の例では、GPUを持つノードを対象に、通信カテゴリのnccl-all-reduceと学習カテゴリのnemotron5-8bを実行し、busBandwidthGBps: "value >= 300"というしきい値を指定している。しきい値は既定では設定されないため、明示しなければ測定値を報告しつつ、テストを開始できない場合に失敗するだけで、目標未達のノードを性能不足として落とす条件にはならない。したがって、クラスタの用途に即した性能ゲートを設けるには、運用側でしきい値を決める必要がある。
カタログには、NCCL通信テスト、DCGMのレベル4診断スイート、NVIDIA NeMo Frameworkを用いる8B・56Bパラメータの事前学習ワークロードが含まれる。独自のコンテナ化テストもWorkloadRunリソースとして認証に組み込める。テスト失敗時は、NVCREが不良グループを分割し、最小グループサイズに達するまで再実行することで、疑わしいノードと失敗理由の特定を支援する。ただし、NVCREの責務はテスト結果の記録と失敗ノードの帰属までであり、ノード状態を変更しない。
稼働中はNVSentinelが、DCGMヘルスチェック、Xidエラー、NIC状態、クラウドプロバイダーの保守イベントなど、クラスタが生成するシグナルを監視する。既定の監視モードではノード条件として障害を報告し、GPU時間を消費しない。隔離や修復を有効にする前に、実クラスタ上で報告内容を評価できる設計である。
有効化後は、Fault QuarantineのルールセットがHealthEventとNodeの条件を評価し、ノードのcordonやtaintを行える。記事の例では、GPUヘルス監視エージェントが通知したfatalイベントをCEL式で識別し、nvidia.com/gpu-error=fatal:NoScheduleのtaintを付与する。スライディングウィンドウ内で隔離できるGPUノード数を制限するサーキットブレーカーも用意され、障害対応がクラスタ全体へ波及するリスクを抑える。
NVSentinelのライフサイクルコントローラーは、新規参加ノードや修復後に戻るノードに対してValidationRequestを作成し、検証中はcordonまたはtaintでスケジューリングを抑止する。NVCREが結果を記録し、テスト合格後に他のテストによるゲートが残っていなければ、コントローラーがゲートを解除する。リトライ後も失敗したノードはcordonされたままとなる。
一方、インプレースのドライバー更新、オペレーター更新、ファブリック変更は、自動的な再検証のトリガーにはならない。変更を加えるパイプラインでAICRのドリフト検出を実行し、影響ノードを明示したValidationRequestを発行するなど、運用側が検証を起動する必要がある。障害の隔離・修復はNVSentinel、テストの実行・失敗ノードの帰属はNVCREという境界を保つことで、複数の仕組みが同じノードを二重にcordonし、解除処理が不整合になる問題を避けやすくなる。
開発者・エンジニア視点での考察
-
性能しきい値は「テスト設定」ではなくSLOに接続する。
busBandwidthGBpsのような条件は、認証結果を性能ゲートに変える。開発チームは、代表的な分散ジョブの通信要件を測定し、クラスタ用途ごとに合否しきい値を定義したうえで、認証マニフェストとCIの変更審査に含めるべきだ。既定でしきい値がない以上、単にテストを実行しただけでは性能劣化を不合格にできない点に注意が必要である。 -
責務境界をAPIと運用ポリシーで維持する。 NVCREは診断と失敗ノードの特定、NVSentinelは隔離・修復・再参加制御を担当する。独自のノードライフサイクル管理を接続する場合も、この分離を保ち、ValidationRequestやCertificationの結果を共通の契約として扱うと、既存の制御系との二重操作や状態不整合を減らせる。
-
変更イベントと再認証をパイプラインで結び付ける。 新規ノードや修復後はライフサイクルコントローラーが再検証を起動できる一方、ドライバー・オペレーター・ファブリックの変更は自動トリガーではない。変更を適用するCI/CDパイプラインに
aicr diff --fail-on-driftと、対象ノードを指定した認証要求を組み込み、合格前にスケジューリングゲートを解除しない構成が、手動引き継ぎによる見落としを防ぐ。
Source / 元記事
この記事について
この記事は、公開されているニュース、論文、公式発表、RSSフィードなどをもとに、AIが要約・補足調査・考察を行って作成しています。
元記事の完全な翻訳・逐語的な要約ではなく、AIによる背景説明や開発者向けの考察を含みます。
重要な技術仕様・価格・提供状況などは、必ず元記事または公式情報をご確認ください。
