NVIDIAのAIファクトリー運用エージェント：クラスタ障害を横断分析するオンプレミス設計
AIファクトリー運用を、専門エージェントの協調で支援
NVIDIAは、自社のNVIDIA DGX SuperPOD運用を支援する「AI Factory Operations Agent」を開発した。目的は、学習ジョブの性能低下や障害を調べる際、SREが計算資源、ネットワーク、ハードウェア、スケジューリングの各ダッシュボードを個別に確認する作業を減らすことだ。エージェント群が複数レイヤーの情報を相関分析し、チャットインターフェースを通じて根本原因候補や推奨対応を提示する。
構成の中心は、NVIDIA NemoClawブループリントを基にしたユーザー向けエージェントランタイムである。SREからの自然言語の問い合わせを受け、適切なドメインエージェントやツールへ処理を振り分ける。ドメインごとの役割を分けることで、単一エージェントに広範な運用知識とツール操作を集中させず、調査対象と責任範囲を明確にする設計になっている。
専門エージェントは次のように分担される。
- Job Recovery Agent：学習ジョブの失敗やgoodputの低下を検知し、スケジューラ、アプリケーション、ハードウェア、ネットワークをまたいで原因を分析。原因が確認された場合に復旧手順を推奨する。
- Hardware Agent：PCIeエラー、ECCエラー、GPUの問題、NVMe障害、温度異常などをデバイス単位で調査し、症状を具体的なコンポーネントへたどる。
- Observability Agent：履歴を含むPrometheusメトリクス、テレメトリ、Grafana Lokiログを照会し、ダッシュボードを動的に作成してWeb UIに表示する。
- Research Agent：NVIDIA Mission ControlマニュアルやDGX SuperPODの参照アーキテクチャ、導入ガイドなどの事前ロード文書を検索する。運用側のrunbookやサイト固有のガイドも追加できる。
- Kubernetes Agent：Pod、Service、Deployment、GPUリソース、ノード状態、スケジューリング状態を読み取り専用で把握する。
- Cluster Management Agent：診断用MCPツールを通じてNVIDIA Base Command Manager APIと連携し、助言型のクラスタ管理・トラブルシューティングを支援する。
各エージェント間の連携にはModel Context Protocol（MCP）を用いる。Web検索、コード実行、Grafanaダッシュボードなどの横断ツールに加え、利用者が独自のMCPサーバーやAPIを接続できるため、既存のスケジューラ、監視基盤、クラスタ管理機能、運用手順に合わせて拡張できる。SREはWeb UIまたはAPI経由の既存コーディングエージェント用インターフェースから利用でき、調査の切り替えや操作履歴の追跡も行える。
オンプレミス実行とKubernetes上の権限境界
フレームワークはNVIDIA OpenShellを用いて構築され、オンプレミス実行に対応する。推論にはローカルで提供するNVIDIA Nemotronオープンモデルを使い、社内のNVIDIA DGX H100、NVIDIA DGX B200、NVIDIA DGX GB300の本番クラスタで稼働する構成が示されている。データを外部推論サービスへ送らずに運用できる選択肢は、データ主権や内部インフラ情報の取り扱いを重視する環境に関係する。
実装はKubernetesのコントロールプレーン上で動作するアプリケーションで、HelmによりUI、OpenClaw gateway、MCPツールサーバー、推論エンドポイント、OpenShellランタイムをKubernetesサービスとしてデプロイする。チャットUIからの要求はNemoClawへ渡され、そこから適切なドメインエージェントへルーティングされる。
シェルコマンドを実行する場合、OpenShellはgateway Pod内で直接処理せず、セッションごとにKubernetes sandboxを作成する。ランタイムにはAI Factory Operations Agentのworkspace、選択されたskills、コマンドポリシーが渡される。このライフサイクルは既存サービスや本番ワークロードを変更しない設計であり、調査用の実行環境を運用系から分離する。
Kubernetes情報の取得は、サーバー側のrun_kubectlツールを介して行う。ツールは固定されたkubectlバイナリを使い、登録済みの読み取り専用認証情報でAPIへアクセスする。OpenShellにはkubectlもKubernetes認証情報も渡さない。アクセス対象はKubernetes ServiceAccountとRBACで制限され、記事の例ではPodとConfigMapの取得は許可される一方、Secretの取得、Podの作成・更新は拒否される。つまり、エージェントが何を見られるかだけでなく、何を実行できないかも権限設計として確認できる。
大規模環境では、本番クラスタから分離されたGPUアクセラレーテッド・コントロールプレーンを推奨する。エージェントのオーケストレーションと推論を専用の制御系で扱い、本番クラスタはテレメトリを提供する。これにより、学習用GPUをエージェント推論に消費したり、運用エージェントが本番ワークロードを妨げたりすることを避ける構成をとれる。推論先はデータ主権、クラスタ規模、利用可能なGPU容量に応じてローカルまたはクラウドから選べ、小規模構成向けにはRTX PRO WorkstationやDGX Sparkも挙げられている。
マルチテナント環境では、エージェント、ツール、sandbox、Kubernetes権限をテナント単位でスコープする。テナントSREには自分のnamespace、ジョブ、ノードのみを見せ、中央運用チームにはより広いクラスタ可視性を残す。OpenShellはカーネルレベルの制約を持つ隔離sandboxでテナントごとのエージェントとツールを実行し、データや操作対象の境界を強制する。
本番利用で重視される設計原則と公開状況
NVIDIAは、本番利用を通じて根本原因分析（RCA）の正確性を測定し、SREとの見解一致を追跡しながら、エージェントのエコシステムを拡張している。記事が挙げる学びは、運用エージェントを単なる自然言語インターフェースとして扱わず、診断の信頼性と検証可能性を設計要件にする点にある。
- エージェント境界を明確にする：担当範囲の重複は有用な情報よりノイズを生む。ドメインごとに責務を定義し、ルーティング先を適切に選べるようにする。
- 読み取り専用から始める：まず調査の精度を高め、SREの信頼を築く。初期段階で変更操作を自動化するのではなく、証拠に基づく診断と推奨を優先する。
- レイヤーをまたいで相関させる：単一の監視ツールだけでは見つけにくい原因を、ワークロード、ハードウェア、ネットワークなどの信号を組み合わせて調べる。
- MCPツールを正確に定義する：ツールの入力・用途・対象を明確にし、エージェントのルーティングや選択の誤りを減らす。
- 推論過程を透明にする：SREがツール呼び出し、根拠、結論を確認してから行動できるようにする。
開発者向けの例とフレームワークのコードはGitHubで公開されており、オーケストレーションフレームワークは実験的なオープンソースソフトウェアとして提供される。API、設定、デプロイ要件はリリース間で変更される可能性がある。NVIDIAが開発したクラスタ運用エージェントの利用を希望する顧客は、担当アカウントマネージャーへの問い合わせが案内されている。
開発者・エンジニア視点での考察
-
まず「診断専用」の権限モデルを実装する：MCPツールを操作能力ごとに分割し、初期導入では読み取り系だけを公開する。RBACの許可・拒否を実際の実行経路で検証し、エージェントからSecret参照やPod変更ができないことをテストで確認する。書き込み操作を追加する場合も、読み取り用ツールに権限を継ぎ足すのではなく、承認・監査要件を備えた別のツールとして設計するのが安全である。
-
エージェントの品質評価を、ツール選択と根拠の再現性まで分解する：RCAの正解率だけでなく、どのMCPツールを選んだか、必要なレイヤーを調べたか、提示した証拠が結論を支えているか、SREが結論に同意したかを評価対象にする。障害事例を回帰テストとして蓄積すれば、ツール定義やルーティング変更による診断品質の劣化を把握しやすい。
-
テナント境界はプロンプトではなく実行基盤で強制する：エージェントへの指示だけに分離を依存させず、MCPサーバーの資格情報、ServiceAccountとRBAC、sandboxのスコープ、参照可能なテレメトリをテナント単位で制限する。中央運用向けの広い権限も別の実行主体として扱い、テナント用エージェントとの資格情報やツール構成の共有を避けることで、誤ったルーティングが発生しても影響範囲を抑えられる。
Source / 元記事
この記事について
この記事は、公開されているニュース、論文、公式発表、RSSフィードなどをもとに、AIが要約・補足調査・考察を行って作成しています。
元記事の完全な翻訳・逐語的な要約ではなく、AIによる背景説明や開発者向けの考察を含みます。
重要な技術仕様・価格・提供状況などは、必ず元記事または公式情報をご確認ください。
