NVIDIA、OpenShellをCNCFに寄贈し、オープンソースのAIファクトリーツールを追加

2026年11月10日、KubeCon + CloudNativeConで、NVIDIAは発表し、エージェントのセキュリティを担うランタイムOpenShellをCloud Native Computing Foundation（CNCF）のSandboxに寄贈するとともに、DSX AI Factory Platform向けの3つのオープンソースコンポーネントを公開することを明らかにした。

今回の発表は、エージェントのガバナンスと、エージェントを効率よく実行するために必要なインフラを結び付けるものだ。NVIDIAは、Google発のAgent Substrateプロジェクトにも貢献し、セッションの実行、クラスター管理、推論の復旧を担うKubernetes Engine、Kubernetes Recipes、SnapshotをDSXに追加する。

OpenShell、コミュニティ主導のガバナンスへ

OpenShellは、自律型エージェントがツールを使い、推論サービスにアクセスし、ワークロードを実行する際に、決定論的な制御を適用する。エージェントはカーネル分離型サンドボックス内で動作し、ファイルシステム、ネットワーク、プロセス、プロバイダー認証情報へのアクセスを対象とする宣言型YAMLポリシーが適用される。認証情報が挿入されるのは、承認済みのエンドポイント宛てのリクエストに限られる。また、形式検証により、提案されたポリシー変更が承認前に新たな危険なアクセスを許可するかどうかを確認する。

このランタイムのライセンスはApache 2.0だ。NVIDIAによると、数百の組織が利用しており、1年足らずで数万件の貢献が寄せられた。また、製品に組み込む組織がSandboxのガバナンスに携わるという。移行は現在も進行中だ。プロジェクトのお知らせによると、開発はai-openshell組織に移るが、移行中もコード、課題、プルリクエストはNVIDIA/OpenShellに置かれる。

Agent Substrate、アイドル状態の計算資源を有効活用

Agent Substrateは、エージェントのセッションを維持するコストに対処する。エージェントは、プロンプトやツールの実行結果、モデルの応答を待つことが多い。その待機中も専用の稼働中Kubernetes Podはリソースを保持する一方、Podを作り直すと状態が失われ、再びコールドスタートが発生する。NVIDIAとGoogleは、クラウド環境とオンプレミス環境の両方で動作するエージェント向けに、OpenShellとの統合にも取り組んでいる。

Agent Substrateの設計では、多数のステートフルなセッションを、より少数の稼働中ワーカー群に割り当てる。アイドル状態のセッションは、メモリやファイルシステムの状態も含めてチェックポイントを作成し、使用中のワーカーを解放したうえで、通常のKubernetes Pod作成手順を繰り返すことなく、利用可能なワーカー上に復元する。ワーカーは通常のKubernetes Podのままであるため、クラスターのスケジューリング、クォータ、配置ポリシーは引き続き適用される。対象となるワークロードには、コーディングアシスタント、強化学習環境、短時間だけ稼働するGPU研究用サンドボックスが含まれる。

NVIDIAは、推論向けのDynamoおよび共有クラスターリソース向けのKAI Schedulerとの相互運用性を開発している。Dynamoは、初回トークン生成までの予測時間とGPUプールの飽和度を提供でき、Agent Substrateはそれらの情報をもとに、エージェントを常駐させるか、一時停止するか、再開するかを判断できる。APIはまだ変更が続いており、GPUサポートはKubernetes Dynamic Resource Allocationを基盤に再構築中で、Dynamo統合の一部は実験段階にある。

DSX、クラスター管理と高速な復元機能を追加

NVIDIA Kubernetes EngineとNVIDIA Kubernetes Recipes（NVKEおよびNVKR）は、Apache 2.0の下でパブリックプレビューとして提供されている。NVIDIAは、API、設定、動作が変更される可能性があるとしており、現時点では本番ワークロードへの利用を推奨していない。NVKRは、バージョンを固定したソースから再現可能なノードイメージ、コンテナイメージ、バイナリ、Helmチャートをビルドし、その入力情報を記録する。NVKEはこれらの成果物を使い、REST APIとコントローラーを通じてクラスターをプロビジョニングし、運用する。ただし、両プロジェクトはそれぞれ単独でも導入できる。

NVKEは、Kubernetesコントロールプレーン、etcdインスタンス、ノードプールをそれぞれ分離した顧客ワークロード用クラスターを作成する。ベアメタルのキャパシティは、NVIDIA Infra Controllerと、そのCluster APIプロバイダーであるCAPNICoを通じて取得する。ノードは、参加用認証情報を受け取る前に、証明済みのSPIFFE IDを提示しなければならない。FirmusとSK Telecomは両プロジェクトを自社のAIファクトリーに統合している。一方、Mirantis、Netris、OpenNebula Systems、Rafay、Spectro Cloud、vClusterは、それぞれのインフラストラクチャープラットフォーム、マネージドKubernetesサービス、またはネットワーク自動化に関連する統合を計画している。

NVIDIA Snapshotは、完全に初期化されたワークロードのCPUメモリとGPUメモリをチェックポイント化し、推論のコールドスタートに対処する。復元には、同じGPUモデルとドライバーが必要であり、重みの再読み込み、コンパイル、CUDAグラフのキャプチャを省略できる。

VAST NFSストレージを使用したB200 GPUで、NVIDIAはvLLM、SGLang、TensorRT LLMの各構成において、3.6～42.7秒で復元できたと報告している。コールドスタートと比べた高速化は8～36倍だった。テスト対象は、パラメーター数6億のモデルから、チェックポイントのサイズが1 TB近くに達する8基のGPU構成までに及んだ。チェックポイントの作成にかかった時間は15秒～5.5分で、テストしたすべての構成で、チェックポイント作成と復元にかかる時間の合計はコールドスタート1回分より短かった。

これらの数値は、マシン全体の起動時間を測定したものではない。インフラストラクチャーのプロビジョニングとコンテナイメージの読み込みは、計測対象となる復元処理に含まれていない。また、チェックポイントごとに、その作成前にキー・バリューキャッシュを解放しており、成果物には保持していない。そのため、これらの結果が示すのは、互換性のあるインフラストラクチャー上で初期化済みワークロードを復元する場合の性能である。

CrusoeがNVIDIA HGX B300で実施した独自のGLM-5.3テストでは、GPUの状態を594 GB含むチェックポイントを使用しました。Crusoeの測定では、GPU状態の復元にかかった時間は、ローカルNVMeからの場合は15.0秒、NFSからの場合は33.3秒でした。アーティファクトをNVMeに置いた場合、Podの作成から準備完了までにかかった時間は31秒で、コールドスタート時の約8分と比べて大幅に短縮されており、ストレージが復元性能を左右する大きな要因であることが示されました。Crusoeは、パフォーマンスと診断に関する変更も上流に貢献しています。

これらのプロジェクトにより、AIファクトリーのコントロールプレーンと復旧経路のより多くの部分がオープンなリポジトリで公開されるようになっていますが、成熟度はそれぞれ異なります。OpenShellのガバナンス移行は未完了で、Agent Substrateは進化を続けており、NVKEとNVKRはプレビュー段階にあります。測定された運用上の改善が最も明確に示されているのはSnapshotのベンチマークです。一方、互換性要件とCrusoeのストレージに関する結果からは、復旧の高速化には、再利用可能なワークロードの状態と、それを支えるインフラの両方が必要であることが分かります。