NVIDIA AI Cluster Runtime（AICR）は、NVIDIAが2026年10月30日に公開した技術ブログで実践手順が示された、GPU加速Kubernetesクラスタ向けの構成生成ツールです。環境を記述すると、検証済みでバージョン固定されたレシピからHelmやTerraformなどのデプロイ成果物を生成でき、分散推論フレームワーク「NVIDIA Dynamo」をKubernetesで動かす際の依存関係の解決を肩代わりします。
室谷代表取締役NVIDIA AI Cluster Runtime、略してAICRですね。これ、NVIDIAがKubernetes上でDynamoを動かすための「検証済みレシピ」を配るという話なんですけど、地味に見えてかなり効くやつなんですよ。
テキトー教師DotAI 認定講師そうなんですよね。単に「Dynamoのデプロイ手順を公開しました」という話じゃないんですよ。
下回りのGPUドライバからスケジューラ、監視まで含めてバージョンを固定して再現可能にする、というのが本質で。まず何が発表されたかを整理しましょうか。
下回りのGPUドライバからスケジューラ、監視まで含めてバージョンを固定して再現可能にする、というのが本質で。まず何が発表されたかを整理しましょうか。
室谷代表取締役はい。NVIDIAがKubeCon North Americaを前に、AICRでDynamoのランタイムを構成・デプロイ・検証するウォークスルーを公開した、というのが今回のニュースです。
GPUをKubernetesで使っているチームに向けた実践ガイドですね。
GPUをKubernetesで使っているチームに向けた実践ガイドですね。
テキトー教師DotAI 認定講師公式の投稿でも「GPUをKubernetesで使っているなら、AICRがDynamoとその必要なインフラを、テスト済みのコンポーネントバージョンと検証チェック付きでまとめる」という言い方をしています。ここが要点なんですよ。
室谷代表取締役つまりDynamo単体じゃなくて、その下のレイヤーまで面倒を見るよと。MYUUUでもGPUクラスタの構成は毎回けっこう消耗するので、これは刺さる話ですw
NVIDIA AI Cluster Runtime（AICR）とは？DynamoをKubernetesで動かす検証済みレシピ集
AICRが検証済み構成アーティファクトを生成する流れ
- 01環境を記述クラウド、アクセラレータ、OS、用途を指定する
- 02レシピを適用バージョン固定されたコンポーネント、互換性の制約、検証チェックを含むレシピを重ねる
- 03レイヤーを合成ベース層→環境層→用途層→ハードウェア層の順に、より具体的な値が優先される
- 04成果物を出力Helm、Argo CD、Flux、Helmfile、Terraform、Fleetなど利用中のデプロイツールが消費する成果物を生成
室谷代表取締役あらためて定義からいきましょう。AICRは、GPU加速Kubernetesクラスタ向けに、検証済みで再現可能な構成アーティファクトを生成するツールです。
環境、つまりクラウド、アクセラレータ、OS、用途を記述すると、Helm、Argo CD、Flux、Helmfile、Terraform、Fleetといった、利用中のデプロイツールが消費する成果物を出力するんですよね。
環境、つまりクラウド、アクセラレータ、OS、用途を記述すると、Helm、Argo CD、Flux、Helmfile、Terraform、Fleetといった、利用中のデプロイツールが消費する成果物を出力するんですよね。
テキトー教師DotAI 認定講師ここで大事なのが「レシピ」という概念です。レシピは特定の環境とワークロード向けの構成を定義したもので、バージョン固定されたコンポーネント、互換性の制約、検証チェックが含まれる。
公式ドキュメントでは、ハードウェアを認識し、バージョンをロックし、SLSA Build Level 3のイメージ来歴で裏付けられている、と説明されています。
公式ドキュメントでは、ハードウェアを認識し、バージョンをロックし、SLSA Build Level 3のイメージ来歴で裏付けられている、と説明されています。
室谷代表取締役出力がハードウェア認識でバージョンロック済み、というのがポイントです。適当なYAMLを人が寄せ集めるのではなく、NVIDIAが実際に組み合わせを検証した結果が出てくる。
テキトー教師DotAI 認定講師しかもレシピは単一の巨大な設定ファイルではなく、レイヤーを重ねて構成されるんですよ。ベース層が共通コンポーネントと既定バージョンを定義し、環境層がEKS固有のコンポーネントを足し、用途層がトレーニング向けの設定を入れ、ハードウェア層が特定アクセラレータ向けにドライバを固定する。
より具体的な値が優先される仕組みです。
より具体的な値が優先される仕組みです。
室谷代表取締役なるほど、オーバーレイを重ねていくイメージですね。ちなみに公式ブログでは、Blackwell＋EKS＋Ubuntu＋トレーニング＋Kubeflowのような完全に特化したレシピだと、16コンポーネントにまたがる最大268個の設定値を持つ、という規模感も示されています。
テキトー教師DotAI 認定講師そうなんです。しかもトレーニングと推論で用途を変えるだけで、5コンポーネントが入れ替わり41個の設定値が変わる。
同じベースからまったく別のデプロイスタックになる。これが手作業のチューニングを生む原因でもあるわけです。
同じベースからまったく別のデプロイスタックになる。これが手作業のチューニングを生む原因でもあるわけです。
AICRでできること――GPUドライバからスケジューラ、監視まで依存をまとめて固定
まとめ
AICRがまとめて固定するコンポーネント
- GPUドライバスタック → NVIDIA GPU Operator
- GPUの検出（ノードのラベル付けと発見） → Node Feature Discovery
- GPU割り当て（Dynamic Resource Allocation） → DRA Driver for NVIDIA GPUs
- スケジューリング（トポロジとギャングスケジューリング） → KAI Scheduler
- 推論ワークロードのオーケストレーション → Grove
- ノードヘルス（劣化ノードに載せる前のシグナル） → NVSentinelとNodewright（選択したレシピが対応する場合）
- メトリクス → Prometheusスタック
- イングレス（Kubernetesネイティブな場合のGateway/EPP経路） → agentgatewayとGateway APIリソース
- レシピはバージョンだけでなく設定値・ノードセレクタ・トレラーション・チェックサム・検証の期待値まで記録し再現性を持たせる
- Dynamo 1.4でfrontendとworkerがKubernetesリソース経由で発見するようになり、既定経路ではNATS不使用（dynamo-platformチャートも既定でNATSを入れず、必要ならオプトインで残せる）
室谷代表取締役で、具体的に何をまとめてくれるのか。ここが一番知りたいところですよね。
テキトー教師DotAI 認定講師公式ブログの表に、Dynamoの下に必要なランタイム前提と、AICRのレシピが入れるコンポーネントが対応付けて整理されています。整理するとこうです。
- GPUドライバスタック → NVIDIA GPU Operator
- GPUの検出（ノードのラベル付けと発見） → Node Feature Discovery
- GPU割り当て（Dynamic Resource Allocation） → DRA Driver for NVIDIA GPUs
- スケジューリング（トポロジとギャングスケジューリング） → KAI Scheduler
- 推論ワークロードのオーケストレーション → Grove
- ノードヘルス（劣化ノードに載せる前のシグナル） → NVSentinelとNodewright（選択したレシピが対応する場合）
- メトリクス → Prometheusスタック
- イングレス（Kubernetesネイティブな場合のGateway/EPP経路） → agentgatewayとGateway APIリソース
室谷代表取締役これ、全部を個別にバージョン合わせしてたら日が暮れるやつですよ。しかもレシピはコンポーネントのバージョンだけでなく、設定値、ノードセレクタ、トレラーション、チェックサム、検証の期待値まで記録して再現性を持たせる、と。
テキトー教師DotAI 認定講師そこが「単にインストール手順をまとめた話じゃない」ところなんですよ。再現性と検証可能性がセットになっている。
受講生さんでも「クラスタは動いたけど、もう一回同じものを作れない」という悩みはよく聞きますからね。
受講生さんでも「クラスタは動いたけど、もう一回同じものを作れない」という悩みはよく聞きますからね。
室谷代表取締役あと地味に大きいのが、Dynamo 1.4でfrontendとworkerがKubernetesリソース経由でお互いを発見するようになったので、AICRの既定経路ではNATSを使わなくなり、dynamo-platformチャートも既定でNATSを入れなくなった点です。必要ならオプトインで残せる、と。
テキトー教師DotAI 認定講師依存が一つ減るのは運用上ありがたいですよね。構成要素が減れば壊れる箇所も減る。
AICRの使い方・始め方――スナップショット→レシピ生成→検証→バンドルの4段階
AICRの4段階ワークフロー
- 01スナップショット既存クラスタの状態を取得。OSリリース、カーネル、GPUハードウェアとドライバ、Kubernetesバージョン、導入済みオペレータなどを収集。フラグ未指定時はnvidia.com/gpu.present=trueのノードを対象にしGPUノードのテイントを許容（--node-selector/--tolerationで詳細指定可）
- 02レシピ生成スナップショットからKubernetesディストリビューション、GPUアクセラレータ、GPUノードOSを識別し、用途(--intent)とプラットフォーム(--platform)を指定。固定コンポーネントバージョン、環境固有設定、互換性制約、検証チェックを記録
- 03検証レシピ選択が既にsnapshot.yamlを使うため同一スナップショットへの検証は追加情報が少ない。オフライン検証はKubernetesに接続せず別スナップショットに対して試すときに使用。宣言的制約を評価し振る舞いチェックはスキップ報告
- 04バンドルレシピをデプロイ可能なHelm valuesやマニフェストにレンダリング。コンポーネントごとにフォルダ分割されvalues.yaml、整合性チェックサム、README、任意のカスタムマニフェストを含む。依存グラフ順に並び、deploy.shまたは--deployer argocdでArgo CDマニフェスト生成、エアギャップ向けOCIイメージ公開も可能
室谷代表取締役ここからが実践パートですね。ワークフローは4段階と。
テキトー教師DotAI 認定講師はい、スナップショット→レシピ生成→検証→バンドルです。各段階は独立して実行できて、成果物はファイルや標準出力、KubernetesのConfigMap（cm://namespace/name）で受け渡せる。
順番に追うとこうです。
順番に追うとこうです。
室谷代表取締役まずスナップショット。既存クラスタの状態を取得します。
code
aicr snapshot \
--namespace aicr-validation \
--output snapshot.yaml配置のフラグを指定しない場合、AICRは自動的にnvidia.com/gpu.present=trueのラベルが付いたノードを対象にして、GPUノードのテイントを許容するんですよね。より細かく指定したいときは--node-selectorや--tolerationを使う。
スナップショットではOSリリース、カーネルバージョン、GPUハードウェアとドライバ、Kubernetesバージョン、導入済みオペレータなどが取得されます。
スナップショットではOSリリース、カーネルバージョン、GPUハードウェアとドライバ、Kubernetesバージョン、導入済みオペレータなどが取得されます。
室谷代表取締役次がレシピ生成。スナップショットからKubernetesディストリビューション、GPUアクセラレータ、GPUノードのOSを識別して、用途とプラットフォームを指定します。
code
aicr recipe \
--snapshot snapshot.yaml \
--intent inference \
--platform dynamo \
--output recipe.yaml生成されたレシピには、固定されたコンポーネントバージョン、環境固有の設定、互換性の制約、検証チェックが記録されます。たとえばAmazon EKSのDynamo推論レシピ（GB200 NVL72やGB300 NVL72向け）では、AICR v1.0.0が次のHelmチャートのバージョンを選ぶ、と公式ブログに表で示されています。
整理するとこうです。
整理するとこうです。
| コンポーネント | バージョン |
|---|---|
| NVIDIA GPU Operator | v26.7.1 |
| Node Feature Discovery | 0.19.0 |
| cert-manager | v1.20.2 |
| AWS EBS CSI Driver | 2.59.0 |
| AWS EFA | v0.5.29 |
| NVSentinel | v1.25.0 |
| NodeWright Operator | v0.19.0 |
| NVIDIA DRA GPU Driver | 0.5.0 |
| KAI Scheduler | v0.16.9 |
| Grove | v0.1.0-alpha.13 |
| Dynamo Platform | 1.4.2 |
| Agent Gateway | v1.5.0 |
| Agent Gateway CRDs | v1.5.0 |
| Kube Prometheus Stack | 84.4.0 |
| Prometheus Operator CRDs | 28.0.1 |
| Prometheus Adapter | 5.3.0 |
| Kubernetes Ephemeral Storage Metrics | 1.19.2 |
室谷代表取締役こうして並ぶと、いかに普段手でバージョンを合わせているか分かりますよね。これを人がやると、どこかで必ずズレる。
テキトー教師DotAI 認定講師で、検証です。レシピ選択自体がすでにsnapshot.yamlのクラスタ情報を使っているので、同じスナップショットに対する検証は追加情報が少ない。
オフライン検証は、Kubernetesに接続せず別のスナップショットに対してレシピを試したいときに使います。宣言的な制約を評価し、振る舞いのチェックはスキップとして報告される。
オフライン検証は、Kubernetesに接続せず別のスナップショットに対してレシピを試したいときに使います。宣言的な制約を評価し、振る舞いのチェックはスキップとして報告される。
code
aicr validate \
--recipe recipe.yaml \
--snapshot candidate-snapshot.yaml \
--no-cluster \
--output dry-run.jsonそして最後がバンドル。レシピをデプロイ可能なHelm valuesやマニフェストにレンダリングします。
code
aicr bundle \
--recipe recipe.yaml \
--accelerated-node-selector n...すみません、ここは抜粋が途中で切れているので、詳細なフラグは公式ドキュメントの「Generating Bundles」を確認するのが確実です。ただ、別の公式ブログでは--system-node-selectorや--accelerated-node-toleration、--outputを指定する例が示されていて、出力はコンポーネントごとにフォルダが分かれ、values.yaml、整合性チェックサム、README、任意のカスタムマニフェストが入る構成だと説明されています。
室谷代表取締役コンポーネントは依存グラフの順に並ぶんですよね。cert-managerがGPU Operatorより先、GPU OperatorがKubeflow Trainerより先、というように。
付属のdeploy.shでデプロイするか、--deployer argocdでArgo CDのApplicationマニフェストを生成するか、エアギャップ環境向けにOCIイメージとして公開する、と。
付属のdeploy.shでデプロイするか、--deployer argocdでArgo CDのApplicationマニフェストを生成するか、エアギャップ環境向けにOCIイメージとして公開する、と。
テキトー教師DotAI 認定講師インストール自体はHomebrewやインストールスクリプト、手動ダウンロード、ソースからのビルドが用意されています。macOS、Linux、Windows（WSL経由）に対応していて、クラスタやGPUは必須ではない。
まずCLIを触ってみる、という入り方ができるわけです。
まずCLIを触ってみる、という入り方ができるわけです。
AICRが解決する課題――Kubernetes上のDynamo運用で何がつらかったのか
室谷代表取締役ここが今回の記事の核心ですよね。何がつらかったのか。
テキトー教師DotAI 認定講師公式ブログが分かりやすくて、「1つのクラスタを動かしても、次のクラスタを同じ状態にするのに数日かかる」「コンポーネントを更新すると別が壊れる」「新しいクラウドに移るとやり直し」という声を挙げているんですよ。まさに現場の悲鳴です。
室谷代表取締役DynamoをKubernetesに載せるだけでは不十分で、GPUドライバ、リソース割り当て、スケジューリング、ネットワーク、監視が全部噛み合う必要がある。この依存解決に時間を取られて、モデルの挙動や性能、アプリ統合の検証ができない、というのがNVIDIAの問題意識です。
テキトー教師DotAI 認定講師単に面倒という話じゃなくて、本来やりたい検証の時間を奪っているのが問題なんですよね。AICRは構成をクリティカルパスから外す、という表現をしています。
室谷代表取締役あと再現性の話も効きます。レシピはバージョン管理されているので、今のデプロイと最新の検証済み構成をdiffして、何が変わったかを確認してからアップグレードできる。
これは運用がかなり楽になりますよ。
これは運用がかなり楽になりますよ。
テキトー教師DotAI 認定講師レシピはNVIDIAの内部検証パイプラインが回るたびに更新され、新しいコンポーネントのリリースやドライバ更新、カーネルパラメータの変更がテストを経て反映される。たとえばBlackwellのスループットを改善するNCCL設定があれば、次のレシピバージョンに入る、という流れです。
室谷代表取締役検証済みの知見がレシピとして降ってくるわけですね。ありがたい。
Dynamoレシピに含まれる構成コンポーネントとv1beta1への移行ポイント
テキトー教師DotAI 認定講師Dynamo側の構成も見ておきましょう。AICRはdynamo-platformチャートのバージョン1.4.2を同梱していて、これにはDynamoオペレータ、Dynamoランタイムイメージ、そしてnvidia.com/v1beta1のDynamoGraphDeployment CustomResourceDefinition（CRD）が含まれます。
v1beta1は以前のv1alpha1 APIバージョンを置き換えるものなんですよ。
v1beta1は以前のv1alpha1 APIバージョンを置き換えるものなんですよ。
室谷代表取締役ここは移行でハマるポイントなので、既存でv1alpha1を使っている人は要チェックですね。DynamoGraphDeploymentでは、vLLM、SGLang、NVIDIA TensorRT LLMをポッド上でどう動かすかを指定します。
テキトー教師DotAI 認定講師ルーティング経路も2つあって、AICRはどちらのトポロジでもDynamoランタイムを同梱して検証する、と。1つはDynamo Frontendルーターで、DYN_ROUTER_MODE=kvで動かし、リクエストをトークン化してプレフィックスの重なりと現在の負荷でワーカーをスコアリングして振り分ける。
もう1つはGateway APIとGateway API Inference Extension（GAIE）、Dynamo EPPを使う経路です。
もう1つはGateway APIとGateway API Inference Extension（GAIE）、Dynamo EPPを使う経路です。
室谷代表取締役1つ目はモデル専用のエンドポイントを持ち、最小のトポロジで済ませたい場合。2つ目はプラットフォームチームが共有Kubernetesイングレスを管理し、タイムアウトやリトライ、フォールバックをGateway APIの仕組みで設定したい場合。
どちらもGateway APIのHTTPRouteの背後で動かせるけれど、ワーカーへの転送をどちらが管理するかが違う、と。
どちらもGateway APIのHTTPRouteの背後で動かせるけれど、ワーカーへの転送をどちらが管理するかが違う、と。
テキトー教師DotAI 認定講師リクエストのプレーンとKVキャッシュのイベントプレーンは分かれていて、Dynamo 1.4.2の既定のAICR Kubernetes経路では、リクエストにTCP、KVキャッシュイベントにZMQを使う。vLLMのワーカーエンジンがローカルのZMQパブリッシャーでイベントを出し、Dynamoのワーカーランタイムがそれを購読して正規化し、Dynamoのイベントプレーンに再公開する、という流れです。
室谷代表取締役このへんは実装寄りなので、必要な人が公式ブログの図と設定例を見るのが早いですね。vLLMの--enable-prefix-cachingや--kv-transfer-configの例も載っています。
テキトー教師DotAI 認定講師将来の話も書かれていて、Dynamo 1.5からはRust製のネイティブEPPがGo/CGOブリッジを置き換える予定とされています。GAIEのLightweight Endpoint Picker（ext_proc）インターフェースを直接実装し、Dynamoルーターをインプロセスで動かし、eppConfigプラグインとスケジューリングプロファイルの代わりにDYN_*環境変数を使う。
Kubernetes側のトポロジは変わらない、と。
Kubernetes側のトポロジは変わらない、と。
室谷代表取締役GoプラグインフレームワークとCGOの境界がなくなることで、リクエストごとのEPPオーバーヘッドも減る、と。これは今後に効いてきますね。
料金・提供範囲――オープンソースalpha版の入手方法と対応環境
室谷代表取締役で、いくらで、どこまで使えるのか。ここは誤解がないようにしておきたいです。
テキトー教師DotAI 認定講師AICRはGitHubでalpha版として公開されているオープンソースプロジェクトです。料金については公式に有料という記載はなく、オープンソースとして提供されている、というのがソースで確認できる範囲です。
室谷代表取締役対応環境は、H100とBlackwell、Ubuntu 24.04、Amazon EKSなどの学習・推論レシピが提供されている、と。学習レシピはKubeflow Trainer、推論レシピはNVIDIA Dynamoを対象にしています。
テキトー教師DotAI 認定講師ドキュメント側ではさらに、AKS、GKE、OKE、CoreWeaveのH100やRTX PRO 6000、NebiusのB300、EKSのネットワーキング、GKEのTCPXOやGB200、A4X Maxのネットワーキング、Talos、OpenShift、RKE2のVR200、k0sのH200といったプラットフォーム別のGPUセットアップのページが用意されています。ただしこれはドキュメントの索引に載っている範囲なので、各環境の対応状況の詳細は公式ドキュメントで確認してください。
室谷代表取締役サプライチェーンも見ていて、すべてのリリースにSLSA Level 3の来歴、署名済みSBOM、イメージのアテステーションが含まれる、と。alpha版だけど、そこはちゃんとしている。
テキトー教師DotAI 認定講師成熟度については、ドキュメントに「Supported」と「Preview」の区別があります。Supportedは、上流のレシピが解決・バンドルでき、実ハードウェアでデプロイでき、宣言した検証フェーズを通り、公開された検証可能なエビデンスがある状態。
Previewは早期採用には有用だが、AICRが完全な本番サポートとライフサイクルのコミットメントをする段階ではない、という位置づけです。
Previewは早期採用には有用だが、AICRが完全な本番サポートとライフサイクルのコミットメントをする段階ではない、という位置づけです。
室谷代表取締役なので、いきなり本番の全クラスタを置き換えるというより、まずは検証環境でレシピを試して、diffを見ながら適用していくのが現実的ですね。
テキトー教師DotAI 認定講師プロジェクトは追加のプラットフォーム、アクセラレータ、ワークロードタイプへ拡大する計画が進行中とされています。今後の広がりは公式のロードマップを見るのが確実です。
よくある質問
室谷代表取締役最後に、よく聞かれそうなところを整理しておきましょう。
テキトー教師DotAI 認定講師まず「AICRとは何か」ですが、GPU加速Kubernetesクラスタ向けに、検証済みで再現可能な構成アーティファクトを生成するツールです。環境を記述すると、Helm、Argo CD、Flux、Helmfile、Terraform、Fleetなどの成果物を出力します。
室谷代表取締役「Dynamoとは何か」も確認しておくと、複数のGPUワーカーにまたがるモデル配信を調整する分散推論フレームワークで、vLLM、SGLang、TensorRT LLMをポッド上で動かすDynamoGraphDeploymentを指定する、というものでした。
テキトー教師DotAI 認定講師「料金はかかるのか」については、GitHubでalpha版として公開されているオープンソースプロジェクトで、有料という記載はソースにはありません。
室谷代表取締役「どうやって始めるのか」は、Homebrew、インストールスクリプト、手動ダウンロード、ソースからのビルドでaicr CLIを入れて、スナップショット、レシピ生成、検証、バンドルの順に進む、でしたね。
テキトー教師DotAI 認定講師「本番で使えるのか」は、成熟度がSupportedとPreviewに分かれていて、alpha版である点は押さえておくべきです。検証環境から始めるのが無難でしょう。
室谷代表取締役「既存のクラスタ運用ツールとの違いは」という点は、今回のソースでは他ツールとの比較までは明らかにされていません。AICRがやることは、レシピという形でバージョン固定と検証チェックをまとめて提供する点だ、という理解でいいと思います。
テキトー教師DotAI 認定講師そうです。憶測で比較を語るより、まず公式のレシピとドキュメントを見るのが早い。
KubeCon North Americaでもセッションがあるようなので、続報が出たらまた追いかけましょう。
KubeCon North Americaでもセッションがあるようなので、続報が出たらまた追いかけましょう。
室谷代表取締役はい、GPUクラスタの構成管理はこれから間違いなくレシピ化が進みますよ。MYUUUでもまずは検証環境で試してみますw
