メインコンテンツにスキップ

NVIDIA DSX OSとは？エラーを出さずに分散学習を遅くするGPUノードを検出する、構成管理・認定・運用の仕組み

技術
解説
NVIDIA
AIインフラ
結論：NVIDIA DSX OSは、GPUクラスタの構成をバージョン固定のレシピでそろえる（AICR）、通信と学習の試験で性能を認定する（NVCRE）、運用中の異常ノードを検出して隔離する（NVSentinel）の3つのコンポーネントで…
作者

obelos

公開

2026年11月12日

更新日

2026年11月12日

結論：NVIDIA DSX OSは、GPUクラスタの構成をバージョン固定のレシピでそろえる（AICR）、通信と学習の試験で性能を認定する（NVCRE）、運用中の異常ノードを検出して隔離する（NVSentinel）の3つのコンポーネントで、分散学習を遅くするGPUノードを見つけて外す、オープンソースのソフトウェア層です。

ポイントは次の3つです。

  1. 問題：同期型の分散学習は、最も遅いGPUの速度で全体が進む。しかもその遅いGPUは、エラーを出さず、監視のしきい値も超えないことがある
  2. 解決：GPU間の通信帯域を実測する試験に合格基準を設け、不合格のグループを分割して再試験することで、原因のノードを特定する
  3. 運用：ノードの追加時や修理からの復帰時に自動で試験し、合格するまでワークロードを割り当てない

2026年11月5日にNVIDIAの技術ブログで紹介されました。3つのコンポーネントはApache 2.0ライセンスのオープンソースです。

前提1：同期型の分散学習

大規模なAIモデルの学習は、数十〜数千枚のGPUに処理を分けて並行して行います。これを分散学習と呼びます。

多くの分散学習では、各GPUが自分の担当分の計算を終えるたびに、全GPUの計算結果（勾配）を集約して平均をとり、全GPUに配り直す処理を行います。これを All-Reduce と呼びます。全GPUの計算が終わらないと、次のステップに進めません。

そのため、1枚のGPUの処理が遅いと、他のGPUはそのGPUを待つことになり、学習全体がそのGPUの速度で進みます。

前提2：エラーを出さずに遅いGPU

問題は、遅いGPUが必ずしも故障として検出されないことです。NVIDIAは、そうしたGPUについて、Xidエラー（NVIDIAドライバーが記録するGPUのエラー）を出さず、監視のしきい値も超えず、ノードのメトリクスでも異常に見えない場合があると指摘しています。

メトリクスの監視だけでは検出できず、実際に通信や学習の負荷をかけて性能を測る必要があります。

DSX OSの3つのコンポーネント

コンポーネント 正式名 役割
AICR AI Cluster Runtime ドライバー、ネットワーク、ストレージなどのバージョンを固定した構成レシピを作る（Configure）
NVCRE Cluster Readiness Engine 通信試験や学習の試験を実行し、合否を判定する（Certify）
NVSentinel ― GPU、ノード、ネットワークの状態を監視し、異常なノードを隔離する（Operate）

1. AICR：構成のずれをなくす

AICRは、ネットワーク、ストレージ、ドライバーなどのコンポーネントごとに、バージョンを固定した構成レシピ を定義します。各コンポーネントは依存関係と、正常に動作していることを確認する条件（healthCheckAsserts）を持ちます。

レシピは、対象の環境（例：EKS、H100、Ubuntu、推論用途）に合わせて生成します。生成したレシピは、Argo CD、Flux、Helmfile、Helmのバンドルとして出力できます。さらに、aicr diff --fail-on-drift コマンドで、実際のクラスタとレシピの差分（ドリフト）を検出したら失敗させられるため、CIのゲートとして「構成がずれていたらデプロイを止める」運用ができます。

2. NVCRE：実際に負荷をかけて合否を判定する

NVCREは次の3種類の試験を実行し、結果を Certification というKubernetesのリソースに記録します。

  • NCCLの通信試験：GPU間の通信帯域を測る（NCCLはNVIDIAのGPU間通信ライブラリ）
  • NeMoによる学習の試験：実際にモデル（例：80億パラメータ）を学習させる
  • DCGMのレベル4診断：NVIDIAのGPU管理ツールDCGMの最も詳細な診断

試験の対象ノード、試験の種類、合格基準は、Certification のマニフェストで指定します。結果のレポートには、状態、実行時間、測定した帯域、失敗の理由が表示されます。独自のコンテナ化した試験を WorkloadRun リソースとして組み込むこともできます。

ここで重要なのが 合格基準の設定 です。たとえば busBandwidthGBps: "value >= 300"（GPU間の通信帯域が毎秒300GB以上）と設定すれば、エラーは出さないが帯域が低いノードを不合格にできます。

ただし、合格基準は初期状態では設定されていません。設定しないと、目標を下回るノードも合格になります。

原因ノードの特定：グループの分割と再試験

NCCLの試験は複数のノードをまとめて測定するため、不合格になっても、どのノードが原因かはすぐには分かりません。NVCREは、不合格のグループを分割して試験をやり直し、最小のグループサイズに達するまで繰り返して、原因の疑いがあるノードを理由とともに報告します。

3. NVSentinel：運用中に監視し、異常なノードを隔離する

NVSentinelは、運用中のクラスタを継続的に監視します。GPUの計算時間は消費しません。監視する信号は、DCGMのヘルスチェック、Xidエラー、NICの状態、クラウド事業者のメンテナンスイベントなどです。

異常を検出すると、設定に応じて次の対応をとります。

対応 内容
cordon ノードに新しいPodを割り当てないようにする
taint 特定の条件を満たすPodだけを割り当てるようにする
drain ノード上のPodを他のノードへ退避させる
修復 自動で修復できるものを修復する

安全のための仕組みもあります。

  • 初期状態は監視のみのモードで動作する
  • Fault Quarantine（障害隔離）はCEL形式のルールで定義し、一定期間内に隔離できるノード数に上限を設けるサーキットブレーカーで、誤検知による大量隔離を防ぐ
  • 繰り返し障害を起こすノードを検出する分析機能がある
  • CONTACT_SUPPORT（サポートへの連絡）を推奨するイベントは、人による対応が必要

ライフサイクルの自動化

ノードの追加時や修理からの復帰時の流れは次のとおりです。

  1. ライフサイクルコントローラーが ValidationRequest（検証要求）を自動で作成する
  2. 試験に合格するまで、cordonまたはtaintでノードへの割り当てを止める
  3. NVCREで試験を実行し、合格したら解除する

検証の状態は nvsentinel.nvidia.com/validation-state ラベルとして付与されるため、kubectl で確認できます。

一方、ドライバー、オペレーター、ネットワークファブリックの変更では、自動で検証が実行されません。影響を受けるノードをcordonして検証要求を作成するか、パイプラインにドリフト検出を組み込む必要があります。

制約と注意点

  • 合格基準は初期状態では未設定です。クラスタの期待性能に合わせて設定する必要があります
  • ドライバーなどの変更は、自動検証の対象外です
  • NVIDIAの記事には、導入による性能改善の数値は示されていません。効果は各環境で測定する必要があります
  • サーキットブレーカーの上限値の初期値は示されていません

まとめ

  • 同期型の分散学習は最も遅いGPUの速度で進むため、エラーを出さずに遅いGPUが大きな損失になる
  • DSX OSは、AICRで構成をそろえ、NVCREで通信と学習の試験を行い、NVSentinelで運用中の異常ノードを隔離する
  • 不合格のグループを分割して再試験することで、原因のノードを特定できる
  • 合格基準の設定と、構成変更時の再検証の組み込みは、運用者が行う必要がある

あわせて読みたい

参考