NVIDIA DSX OS、遅いGPUノードを性能テストで検出―初期設定ではしきい値の設定が必要
2026年11月7日 22:36
NVIDIAは2026年11月5日、オープンソースの運用ソフトウェア群「DSX OS」を使い、Kubernetes上のGPUクラスタを設定、認定、監視・修復する手順を公開した。基本的なヘルスチェックを通過しながら学習性能を低下させるGPUノードを、実際のワークロードで見つける仕組みが柱となる。性能に基づく合否判定や自動対応を利用するには、運用者によるしきい値の設定と各機能の有効化が必要だ。
■GPU使用率だけでは見えにくい性能低下
今回の解説で取り上げたのは、NVIDIA AI Cluster Runtime（AICR）、NVIDIA Cluster Readiness Engine（NVCRE）、NVSentinelの3つだ。それぞれ構成の設定、稼働準備の認定、運用中の健全性監視と障害対応を担う。いずれもApache 2.0ライセンスでGitHubに公開されている。
DSX OSは、NVIDIAが2026年5月31日に発表したDSX AIファクトリープラットフォームの運用レイヤーである。同社は10月13日、同じプラットフォームの一部として、GPUリソースの割り当てやワークロード管理を担うNVIDIA Run:aiのプラットフォーム全体をオープンソース化すると発表した。
NVIDIAが挙げる課題は、GPUのエラー情報であるXidや監視アラートが出ず、使用率も正常に見える一方で、目標の性能を下回るノードだ。同期型の分散学習では、計算結果を共有する段階で遅い処理の完了を待つため、1台の性能低下がジョブ全体を遅らせる。同社は、正常に完了した仕事量を示す「goodput」を、クラスタの効率を把握する指標として重視している。
大規模学習の運用上の課題は、MetaのLlama 3に関する技術報告にも表れている。H100 GPUを1万6384基使う学習環境について、事前学習中の54日間に419件の予期しない中断があり、その約78％を、確認済みまたは疑いのあるハードウェア関連の問題に分類した。
クラスタの状態は、導入時の検証後も変わる。ノード交換やドライバー更新、ネットワーク構成の変更を経た環境では、新しい構成に合わせて性能と健全性を検証し直すことが重要になる。
■NVCREは通信・診断・学習ジョブで検証
NVCREは、実際の分散ワークロードを実行してGPUクラスタを検証するKubernetesコントローラーだ。テストにはNCCLの通信処理、NVIDIA Data Center GPU Manager（DCGM）のレベル4診断、NeMo Frameworkを使う80億・560億パラメーター規模のモデルの事前学習が含まれる。GPUの演算やメモリに負荷をかけ、NVLinkやInfiniBandなどを使った通信性能も調べる。
運用者は対象ノード、テストの分類、合否を決める性能しきい値を指定する。通信テストで使うall-reduceは、参加する処理間で計算結果を集約し、共有する集団通信である。その性能を評価する指標の一つが、バス帯域幅だ。
NVIDIAのnccl-tests資料によると、all-reduceのバス帯域幅は、データ量を実行時間で割ったアルゴリズム帯域幅に2(n−1)/nを掛けて求める。nは通信に参加するrank数を表す。参加数による違いを補正し、ハードウェアの帯域と比較しやすくする指標で、公式の設定例は毎秒300GB以上を合格条件としている。実際の基準は、GPUや接続構成に合わせて決める必要がある。
複数ノードのテストで性能が低かった場合、NVCREは対象グループを分割して再試験する。例えば64ノードのall-reduceで問題が見つかると、失敗したグループを最小グループサイズまで段階的に分け、問題が疑われるノードと理由を報告する。検証結果を記録するNVCREと、ノードの隔離や修復を担う運用ツールの間で役割を分けている。
導入にはNVIDIA GPU Operatorが必要となる。標準のメトリクス設定ではPrometheus Operatorのカスタムリソース定義も必要で、DCGMのレベル4診断には独立したDCGMサービスを用意する。NVCREによる検証は、クラスタの引き渡し前や増設時、修復後など、必要な時点で実行する方式だ。
■性能しきい値と自動対応を段階的に設定
NVIDIAの11月5日の解説によると、NVCREの性能しきい値は初期状態では未設定である。この状態でも計測結果は報告され、テストの起動失敗などは検出されるが、目標を下回る帯域幅でも認定を通過する場合がある。性能低下を合否に反映するには、帯域幅の下限などの条件を指定する。
NVSentinelも標準では監視専用モードで導入される。検出した障害をKubernetesのノード状態として公開し、運用者が報告内容を評価した後で、隔離、ワークロードの退避、修復を段階的に有効化できる設計だ。
実務上は、まず健全な構成で性能を測って基準値を把握し、それを基に合否条件を決める。その後、監視結果を確認しながら自動対応を有効にする。帯域幅の下限が低すぎれば性能低下を見逃し、高すぎれば正常なノードまで不合格となるため、構成と用途に応じた調整が必要だ。
■AICRで構成を固定し、変更を検出
AICRは、GPUクラスタの再現可能なソフトウェア構成を定義する。Amazon EKSなどのデプロイ先、H100などのアクセラレーター、OS、用途、プラットフォームの構成要素を指定し、検証済みの構成情報からバージョンを固定した「レシピ」を生成する。
レシピには、各構成要素のバージョン、インストール順序を決める依存関係、導入後の健全性を確認する条件が含まれる。例えば、NVSentinelより先にcert-managerが利用可能になるよう依存関係を扱う。生成したレシピは、Helm、Argo CD、Helmと組み合わせたArgo CD、Flux、Helmfile向けの設定として出力できる。
運用中は、基準となる構成と稼働中クラスタのスナップショットを比較し、構成のずれを検出する。比較コマンドのfail-on-driftオプションをパイプラインに組み込むと、ずれを検出した際に非ゼロの終了状態を返し、処理を停止させられる。手作業の変更や通常の手順を経ない更新を把握し、再検証につなげるための仕組みとなる。
■NVSentinelで監視から隔離・修復へ
NVSentinelは、本番ワークロードと並行してGPU、ノード、ネットワークの状態を継続的に監視する。DCGMのヘルスチェック、Xidエラー、ネットワークインターフェースカードの状態、クラウド事業者のメンテナンス通知などを利用する。NVIDIAによると、監視用に別のGPUワークロードを動かす方式ではなく、既存のシグナルを利用する。
NVIDIAが2026年11月時点で公開している資料では、社内導入は約4万基のGPU規模とされている。社内では自動修復を有効にして運用しているという。
隔離を有効にすると、Common Expression Language（CEL）で記述したルールに従い、ノードへの新規配置を止めるcordonや、配置制御に使うtaintを設定できる。これらのKubernetes標準の状態を、スケジューラーやアラート、ライフサイクル管理ツールが利用する。
サーキットブレーカーは、一定の時間枠で隔離するGPUノード数に上限を設ける仕組みだ。障害が同時に広がった際に、自動隔離によって一度に失われる計算資源を抑える。
対応経路は障害の内容によって変わる。既知の致命的なGPUエラーは修復処理に進み、断続的な障害はヘルスイベントアナライザーがノードの障害履歴からパターンを調べる。CONTACT_SUPPORTという推奨アクションが付いたイベントは、人による調査やサポート対応の対象となる。
■修復後の再検証を運用に組み込む
NVSentinelとNVCREの連携を設定すると、新規ノードの参加時や修復後に、検証と復帰判断を自動化できる。NVSentinel側が検証要求を作成し、cordonやtaintでジョブの配置を制御する間に、NVCREがテストを実行して結果を記録する。
この連携にはライフサイクル管理機能の有効化が必要で、修復後の検証は別途有効にする。NCCL通信テストや学習テストをNVCRE経由で実行するには、nvcre-providerも設定する。検証に合格し、ほかのテストによる制限も解消すると配置制限が解除され、再試行後も失敗するノードは隔離された状態に保たれる。検証状態はノードラベルからも確認できる。
インプレースでのドライバー更新やネットワーク構成変更では、運用者が対象ノードをcordonし、検証要求を作成する。AICRの構成差分チェックを更新パイプラインに組み込めば、変更の検出を対象ノードの認定につなげられる。独自のノード管理基盤を持つチームも、NVCREの結果を読み取り、自ら隔離や復帰を制御できる。
■公開コードを活用するための導入条件
Apache 2.0は、条件に従ったコードの改変や再配布を認め、対象となる特許についても許諾を定めている。企業は公開コードを調べ、自社の運用基盤に合わせて利用・拡張できる。
技術面では、NVCREはGPU Operatorを前提とし、GPU診断にはDCGM、通信テストにはNCCLを利用する。採用時には、ライセンス条件に加え、NVIDIA製GPU向けの診断や通信基盤との依存関係を確認することになる。性能基準の選定、隔離ルール、修復の範囲、構成変更後の検証は、運用チームが設計する部分だ。
NVIDIAは、2026年11月9日から12日まで米ユタ州ソルトレークシティーで開催されるKubeCon + CloudNativeCon North Americaのブース170で、関連ツールのデモを行う予定だ。併催企画として、11月9日には午前にAI推論の技術解説とデモ、午後にDSX OSの開発参加者向けワークショップを開催する。参加には別途登録が必要で、定員には限りがある。
元記事: NVIDIA DSX OS Guide Says Slow GPU Nodes Pass Tests Until Operators Set Thresholds