NVIDIA、Dynamo向けAICRの検証済みKubernetes基盤を解説、モデル配備前にruntimeを検査

Published · AI Daily — AI-assisted deep research, methodology & disclosure

NVIDIAは2026年10月30日、AI Cluster Runtime(AICR)を使い、Dynamoによる推論のためのKubernetes基盤を検証可能な形で構築する手順を示した。DynamoGraphDeploymentはモデル提供の構成を記述するが、それだけでGPUドライバー、資源割り当て、スケジューリング、ネットワーク入口、監視まで整うわけではない。AICRはDynamoと周辺部品を版付きのrecipeにまとめ、対象クラスタが条件を満たすか調べる。

NVIDIAは2026年10月30日、AI Cluster Runtime(AICR)を使い、Dynamoによる推論のためのKubernetes基盤を検証可能な形で構築する手順を示した。DynamoGraphDeploymentはモデル提供の構成を記述するが、それだけでGPUドライバー、資源割り当て、スケジューリング、ネットワーク入口、監視まで整うわけではない。AICRはDynamoと周辺部品を版付きのrecipeにまとめ、対象クラスタが条件を満たすか調べる。話題はruntimeの配備と検証であり、新しいモデルの学習や業務アプリの性能向上を実測したという発表ではない。

記事は二つの要求ルーティング方式を区別する。簡単な方式ではDynamo FrontendをKubernetes Serviceの背後に置く。KVルーティング時、Frontendが要求をトークン化し、接頭辞の一致と現在の負荷を比べてworkerを選び、自ら要求を送る。モデル専用の入口や、Frontendへ転送するだけの既存プロキシに向く。もう一つはGateway APIとInference Extensionを使う方式である。HTTPRouteがInferencePoolを指し、Dynamo operatorがDynamoGraphDeploymentからプールとEndpoint Picker参照を作る。GatewayがDynamo EPPを呼び、EPPはKV情報でworkerを選んでルーティング情報を返す。実際にHTTP要求を選ばれたworkerのFrontend sidecarへ送るのはGatewayだ。選定と転送の担当を混同してはいけない。

どちらの方式もHTTPRouteの背後で動かせる。違いは単にゲートウェイの有無ではなく、workerへの転送、タイムアウト、再試行、fallbackをFrontendとGatewayのどちらが管理するかにある。第二方式には対応Gateway、InferencePool、EPP、worker sidecarが加わる。NVIDIAは第一方式を最小で実運用経験の多い構成と位置づける。記事が説明する第二方式はoperator管理のDynamoGraphDeployment連携で、実験的な独立vanilla vLLM導入とは別である。Dynamo 1.4のEPPはGoの枠組みにCGOでRustのKVルーターを埋め込み、ネイティブRust EPPは将来の1.5の見通しとして書かれている。現在の1.4.2 recipeの機能とは言えない。

エージェントの対話ではシステム指示、ツール定義、履歴など長い接頭辞が繰り返される。必要なKVキャッシュブロックを保持するworkerへ送れば、入力の再処理を避けられる。workerはローカルZMQでキャッシュイベントを発行し、Dynamoが正規化してイベント平面へ再配信する。要求平面は標準でTCP、キャッシュイベント平面はZMQで、同じ通信路ではない。両方の方式はworkerが発した実際のキャッシュ・負荷情報を使える。予測によるキャッシュ状態も設定できるが、退避を見落として実態からずれる可能性があるとNVIDIAは警告する。prefillとdecodeの分離も説明されるが、キャッシュミス率は負荷によるため構成図だけでは決まらない。

手順は順番が大切だ。aicr snapshotでクラスタを記録し、aicr recipeでその情報に合うDynamo推論recipeを選び、部品の固定バージョンと制約・検査を残す。文中のAICR v1.0.0におけるAmazon EKSのGB200 NVL72、GB300 NVL72向け例では、Dynamo Platformのchartは1.4.2に固定される。これは特定の環境で試した組み合わせであり、どの環境でも最新という意味ではない。別の取得済みsnapshotとのオフライン比較は可能だが、ライブクラスタがなければ動作検査はスキップされる。その後aicr bundleでHelm設定とマニフェストを出力し、runtimeを配備し、aicr validateで実クラスタのdeploymentとconformanceを確認してからアプリのDynamoGraphDeploymentを入れる。

検査対象にはGPU容量とnvidia-smi、GPU OperatorとDynamoの健全性、DRA、gang schedulingと自動スケール、Prometheusの指標、Kubernetes-nativeの入口を使う場合のGatewayの準備状況などがある。NVIDIAは性能検証を別段階と明記する。仮の提供ワークロードを立ててGPUを消費するためだ。配備・適合性の検査合格をアプリのスループット実証と取り違えてはいけない。recipeによって検査は変わり、この記事は当媒体や読者のクラスタが合格したことを示さない。クラスタの記録から選定、版固定、配備、ライブ検査へ進む順序がこの手順の核である。

Sources

FAQ

Frontend方式とGateway/EPP方式では誰が選択し誰が転送しますか?

Frontend方式ではDynamo Frontendが接頭辞キャッシュと負荷からworkerを選び、そのまま要求を転送する。Gateway/EPP方式ではGatewayがEPPを呼び、EPPは端点と情報を返すだけで、HTTP要求をworker sidecarへ実際に送るのはGatewayである。両方ともHTTPRouteの背後で使え、違いは転送の担当にある。

AICRはクラスタの記録からモデル配備までどの順序で進みますか?

まずaicr snapshotでクラスタを記録し、aicr recipeでDynamo推論設定と部品版を選ぶ。別のsnapshotとの任意のオフライン比較では動作検査は行われない。続いてaicr bundleでHelm資源を出力し、runtimeを配備し、ライブクラスタにaicr validateを実行する。配備と適合性が確認されてからアプリのDynamoGraphDeploymentを入れる。

配備と適合性の検査に合格すれば推論性能も証明されますか?

いいえ。配備と適合性の検査はGPU、ドライバー、DRA、スケジューリング、監視、入口などの基盤条件を調べ、細目はrecipeで変わる。NVIDIAは一時的な推論ワークロードとGPUを使う性能検証を別段階に置く。記事は読者のクラスタやアプリのスループットがその段階を通ったとは示さない。