本記事はAIを利用して作成した技術解説・実装例です。掲載するコードや手順は一次情報を基に構成していますが、筆者による実機での動作確認は行っていません。環境やバージョンによって動作が異なる場合があります。
大規模なAIワークロードの稼働前には、GPUクラスターの稼働準備状況を安全かつ実用的に検証することが求められます。本記事では、NVIDIAが提供するオープンソースのKubernetesコントローラー「NVIDIA Cluster Readiness Engine (NVCRE)」の公式情報をもとに、その仕組みや構成要素、利用時の注意点を整理して解説します。
NVIDIA Cluster Readiness Engine（NVCRE）の目的
GPUクラスターは、すべてのGPU、ネットワークリンク、ポッドが正常と報告されていても、大規模な分散トレーニングの実行時に予期せぬパフォーマンス低下や失敗を引き起こすことがあります。原因としては、性能の劣化している単一のGPUや、負荷がかかった際に劣化するネットワークリンクなどが挙げられます。
NVCREは、本番ワークロードの稼働前に、トポロジーを考慮したノードグループ上で実際の分散ワークロードを実行し、結果を測定して、テストに失敗したノードを特定するオープンソースのKubernetesコントローラーです。オペレーターが手動でマニフェストを作成したり、ラックを個別に切り分けたりする手間を削減し、クラスターの「準備完了状態」を客観的な事実として証明します。
flowchart TD
A[Certification] --> B[Workflow: コミュニケーション / トレーニング]
B --> C[Job: ターゲットノードグループのワークロード実行]
C --> D[結果の集約・特定ノードの障害判定]
D --> E[NVSentinel 連携による隔離・検知]
3階層のAPI構造
NVCREの操作面は、カスタムリソース定義（CRD）によって構成される3つの階層化されたAPIを通じて行われます。
Certification: 最上位のリソースであり、テスト対象となるノードや実行するカテゴリーを指定します。
Workflow: 1つのカテゴリーを管理します。カタログ、プラットフォーム、GPUのオーバーライド適用、イテレーション回数の管理、オーケストレーションターゲットの設定、子ジョブの作成を行います。
Job: ターゲットノードグループに対するワークロードの実行、ノードの健康状態の監視、測定値や障害の記録を行います。
これら階層構造により、失敗した原因がどのノードのどのカテゴリーに起因するのかを明確に紐付けることが可能です。
カタログとPass条件の式評価
ビルドインのカタログは、NCCL通信バリアント（all-reduce、all-gather、all-to-all、loopback、NVSwitch間loopback）、NVIDIA DCGMレベル4診断スイート、NVIDIA NeMo事前学習（Nemotron 5モデルの8Bおよび56Bパラメータ）の3つのドメインをカバーしています。
合否（Pass / Fail）の判定には Common Expression Language (CEL) が使用され、測定されたメトリックに対して評価されます。閾値はデフォルトでは同梱されていません。例えば、以下のような設定構造が示されています。
categories:
- domain: communication
variant: nccl-all-reduce
options:
thresholds:
busBandwidthGBps: "value >= 900"
- domain: training
variant: nemotron5-8b
options:
thresholds:
goodputRatio: "value >= 0.9"
avgTFLOPsPerGPU: "value >= 800"
目標値に満たなかった場合、NVCREは「ValidationFailed」条件を設定し、実行自体の成功・失敗とは別個に記録します。
テストスケールと適応型障害隔離
障害が特定のスケールでのみ可視化されるケースに対応するため、testScale フィールドでグループ化戦略を指定できます。
Intra-node: 各ノードを個別にテストします。
Intra-rack:
nvidia.com/gpu.cliqueラベルを使用して、トポロジードメインごとにノードを分割します。Full-scale: すべてのノードを単一のグループにまとめます。
Diagnose: 適応型障害隔離を実行します。
複数ノードの検証における最大の課題は、単一のノードに起因しない帯域低下などの障害ですが、testScale: diagnose を設定すると、トポロジーを意識した階層型グループテストが実行されます。エンジンは失敗したグループを分割し、最小グループサイズ（minGroupSize）に到達するまで再実行を繰り返し、影響範囲全体ではなく少数の疑わしいノードを特定します。
WorkloadRun APIによる柔軟な実行
複数ノードのGPUワークロードをKubernetes上で実行する際の設定負担を軽減するため、WorkloadRun APIが用意されています。
apiVersion: nvcre.nvidia.com/v1alpha1
kind: WorkloadRun
metadata:
name: nccl-all-reduce
spec:
image: nvcr.io/nvidia/pytorch:26.01-py3
framework:
mpi:
binary: /usr/local/bin/all_reduce_perf_mpi
args: ["-b", "8", "-e", "32G", "-f", "2", "-n", "100"]
mpirunPath: /usr/local/mpi/bin/mpirun
numNodes: 4
bandwidthMeasurement:
logProfileRef: nccl-bandwidth
testType: all_reduce
framework フィールドは、torch、mpi、exec のいずれかを選択可能です。また、ビジーなクラスターでのデッドロックを防ぐため、ガングアウェアスケジューラー（KAI Schedulerなど）の利用が推奨されています。
NVIDIA DSX OSエコシステムにおける位置づけ
NVCREは、NVIDIA DSX OSの運用レイヤーを構成する要素の一つであり、他のコンポーネントと連携します。
NVIDIA AI Cluster Runtime (AICR): ドライバー、演算子、カーネル、システム設定などのバージョン固定レシピを通じて、検証済みのクラスター構成を維持します。
NVIDIA Cluster Readiness Engine (NVCRE): 実際に負荷を生成し、テレメトリーに現れない障害を能動的に検証します。
NVSentinel: DCGMメトリックやXidエラーなどをパッシブに監視し、継続的な健康状態のトラッキングを行います。
NVCRE自体はノードのコードンやテイントを行わない設計ですが、NVSentinel NVCRE Certification Monitorを介して、失敗した検証結果を健康イベントへ翻訳し、隔離やドレインワークロードへ繋げることが可能です。
前提条件と利用時の注意点
公式情報における前提条件および留意事項は以下の通りです。
環境要件: Kubernetes 1.29以降、
kubectl、Helm 3.x、およびターゲットクラスター上のNVIDIA GPU Operatorが必要です。特定ハードウェア要件: NVIDIA GB200 NVL72およびGB300 NVL72のカタログエントリでは、ComputeDomainリソースを作成するためNVIDIA DRA Driver for GPUsが必要です。
DCGM要件: DCGMレベル4カテゴリーには、スタンドアロンのDCGMサービスが必要です。
実機確認に関する注意: 本記事で紹介した構成やコマンドは一次情報に基づく解説であり、【実機確認前】の調査情報です。実際の導入時はターゲット環境のバージョンやネットワーク構成に依存するため、公式ドキュメントを参照してください。
まとめ
、Validate GPU Cluster Readiness Before AI Workloads Landの一次情報に基づき、NVCREの概要、API階層、CELによる評価式、テストスケール、WorkloadRun API、およびエコシステムの役割を整理しました。
実行前に確認すべき点と制約事項は以下の通りです。
クラスターのKubernetesバージョンやGPU Operator、必要に応じた専用ドライバーの導入状況を確認する。
アクティブな負荷テストが本番稼働前のクラスター性能やネットワークファブリックに与える影響を考慮する。
失敗ノードの特定結果を受け取るためのNVSentinel等との連携方針を設計する。
