NVIDIA Mission Control（ミッションコントロール）2.5が提供開始障害の自動復旧エンジンがKubernetes（Run:ai）のジョブにも対応、Vera Rubin NVL72では未対応

NVIDIAは2026年10月26日（米国時間）、AI基盤の運用ソフト「NVIDIA Mission Control（ミッションコントロール）2.5」が提供中だと技術ブログで発表しました。これまでHPC向けジョブ管理のSlurmに限られていた「自動復旧エンジン」が、NVIDIA Run:ai（ランエーアイ）で管理するKubernetes（クバネティス）上のワークロードにも使えるようになった、というのが中心の変更です。ブログの公開時刻はページのメタデータで2026年10月26日15:00（UTC）、日本時間では10月27日0時にあたります。

3行まとめ

1. NVIDIAは10月26日、Mission Control 2.5が提供中と発表。Slurm限定だった自動復旧エンジンがRun:ai管理のKubernetesにも広がった
2. 障害時は、ジョブの再起動とノードの隔離・診断を並行して進める。一時的なソフトウェア障害ではハードウェア修復を起こさず再試行する、と説明している
3. リリースノートでは、Vera Rubin NVL72の早期アクセスはRun:aiと自動復旧エンジンに非対応。ブログの「早期アクセス」だけを読むと見落としやすい

本記事の内容は、日本時間10月27日0時台に公式ページで確認したものです。

何ができるようになったのか

NVIDIAの技術ブログ（著者はRyan Prout氏とCasey Dugas氏）は、数千GPUで大規模モデルを学習する運用では、手作業での対応や静的なチェックポイント、後追いの監視では追いつかないと述べています。そのうえで、Mission Controlに含まれる自動復旧エンジンを、Kubernetes上のワークロードにも広げたと説明しています。

ブログによると、エンジン自体はジョブ復旧とハードウェア復旧の2つのサービスで構成され、ワークロードのスケジューラーと組み合わさって3層の仕組みとして動きます。

ブログは、この3者の役割を分けているため、ジョブ復旧はハードウェアの修理を担わず、ハードウェア復旧は学習フレームワークの細部を理解しなくてよい、と説明しています。

障害の種類で、動きはどう変わるのか

ブログは3つの場面を挙げています。

• ハードウェア障害: GPUの異常が、ECCエラー、ワーカーの停止、通信タイムアウトなどの形で現れる場面です。ジョブ復旧サービスが疑わしいノードやGPUを特定し、スケジューラー連携がジョブを再起動または再配置します。同時にハードウェア復旧サービスがそのノードを隔離し、理由を記録して診断を始めます。ブログは「根本原因の分析を待たずに復旧が始まり、壊れたノードが次のジョブに渡されることもない」と説明しています。
• 一時的なソフトウェア障害: ノード自体は健全なまま、ワーカーが終了したり、一時的に協調が途切れたりする場面です。失敗の履歴が一時的に見えるなら、スケジューラーのポリシーに沿って再試行し、ハードウェアを隔離しません。繰り返し失敗する場合は、その事実が表に出されるとFigure 5の説明にあります。
• ハードウェアの劣化を早期に検知: GPUの健全性警告や接続の問題が繰り返されるノードを、ジョブが載る前にスケジューラーの対象から外し、診断を始めます。この場合、ジョブ復旧サービスの出番がないこともあるとしています。

対応する環境と条件は？

リリースノート（2.5.0）には、ブログより細かい条件が書かれています。

• 自動復旧エンジンはRun:aiのKAIスケジューラーに統合され、kubeflowのPyTorch学習オペレーターを使う場合が対象と書かれています。ジョブを投入すると、Mission Controlがジョブの出力を監視し、システムログやテレメトリーと突き合わせて、原因がハードウェアかソフトウェアかを判定します。ジョブは再キューされ、直近の異常に関与したノードを除外するようジョブ仕様が更新される、という説明です。
• 自動復旧エンジンは、ジョブ復旧、ハードウェア復旧、NVIDIA Resiliency Extensions（NVRx）の3つで構成されます。NVRxはMission Controlと一緒にはインストールされず、別途入れる必要があると注記されています。
• 学習アプリ側には、PyPIのクライアントライブラリ（aidot_training_telemetry）を組み込むと、スループット、チェックポイント、ハングの検知に使うログが自動で出る、とあります。
• 対応表では、DGX B200・B300、DGX GB200・GB300、OEMのGB200・GB300 NVL72で、Run:ai・ジョブ復旧・ハードウェア復旧がいずれも「Yes」です。

Vera Rubin NVL72の「早期アクセス」には何が含まれるか

ブログはリリースの目玉の一つに「Vera Rubin NVL72の早期アクセス」を挙げています。一方、リリースノートの冒頭には次のようにあります。

Early access support for Vera Rubin NVL72 is limited to essential bring-up support with NVIDIA Base Command Manager. NVIDIA Run:ai and Autonomous Resiliency Engine are not supported on Vera Rubin NVL72 in this release. （Vera Rubin NVL72の早期アクセスは、NVIDIA Base Command Managerによる基本的な立ち上げ支援に限られる。今回の版では、Vera Rubin NVL72でNVIDIA Run:aiと自動復旧エンジンは非対応）

対応表も同じで、DGX VR NVL72とOEM VR NVL72の列は、Run:ai・ジョブ復旧・ハードウェア復旧がすべて「No」、NetQもNoです。リリースノートの記載どおりなら、今回の目玉であるKubernetes向けの自動復旧は、2.5の時点ではVera Rubin NVL72と組み合わせて使えないことになります。

前の版と何が違い、ほかに何が入ったか

ブログが挙げる、自動復旧のKubernetes対応以外の変更は次の4点です。

リリースノートには、Run:ai 2.26への更新、読み取り専用のRun:ai MCPサーバー、NetQ 5.2.1なども載っています。Run:aiの旧GPU分割エンジンをCUDAベースへ移す予告もありますが、v2.26では変更なしと書かれています。

筆者が公式ページで確認した範囲での気づき

日本時間10月27日0時台に3つのページを取得して読み比べた時点で、気づいたことが2つあります。1つは、ブログの「AI対応のネットワーク異常検知サービス（ベータのみ）」という表現が、リリースノートでは同じ名前で出てこないことです。リリースノートでネットワークの異常をたどる機能として説明されているのはMinervaで、これは「リリースに含まれず、限定参加のみ」とされています。ただし、ブログの項目がMinervaを指すのかは、取得した3ページからは断定できません。そのため本記事では、両者を同一とは書いていません。もう1つは、前節のVera Rubin NVL72の範囲です。ブログの一覧は「Early access for NVIDIA Vera Rubin NVL72」の1行だけで、Run:aiと自動復旧エンジンが対象外であることには触れていません。なお、取得した3ページはいずれも英語版で、日本語のページは確認していません。

NVIDIAの関連記事は、サイト内のNVIDIA Minerva（AIファクトリーの障害を予兆から原因特定まで見るAIOps基盤）と、Run:aiのオープンソース化でも扱っています。

この発表だけでは分からないこと

• 今回取得した技術ブログ、リリースノート、製品ページには、料金、ライセンス条件、日本での提供条件の記載は見つかりませんでした。製品ページには「Talk to Us」の問い合わせ窓口と、NVIDIA Enterprise Supportの案内があります。
• 復旧にかかる時間や成功率などの実測値は、ブログに載っていません。製品ページには自動復旧エンジンについて「10x faster」（10倍速く）という記載がありますが、これは製品全体の説明で、Kubernetes対応の2.5について測定したものとは書かれていません。比較の基準も示されていません。
• ブログの動画（Video 1）と図は、本文のテキスト取得では中身を確認できていません。
• 筆者は製品を試していません。以上はすべてNVIDIAの公式説明です。

読み比べた3ページと取得時刻

• How NVIDIA Mission Control 2.5 Brings Autonomous Recovery to Kubernetes — NVIDIA Technical Blog（2026年10月27日0時5分、日本時間に確認）
• NVIDIA Mission Control 2.5.0 Release Notes（同0時6分に確認）
• NVIDIA Mission Control（製品ページ）（同0時6分に確認）

本記事は続報があり次第更新します。