NVIDIA AICR、Kubernetes上でのDynamoデプロイを簡素化

NVIDIAは、Kubernetes上での分散推論フレームワーク「Dynamo」のデプロイを効率化するため、NVIDIA AI Cluster Runtime（AICR）を導入しました。DSX AI Factory Platformの一部としてリリースされたこのツールは、GPUドライバ、リソース割り当て、監視などの複雑な依存関係を処理する検証済みのインフラストラクチャレシピをパッケージ化しています。プラットフォームチームに対し、大規模言語モデルを提供するための再現性が高く一貫した基盤を提供することを目的としています。

何が起きたか

Kubernetes上でAI推論モデルをデプロイするには、コンテナを実行する以上の作業が必要です。エンジニアは、GPUドライバ、ノードの健全性シグナル、動的リソース割り当て、ネットワークルーティングがすべて正しく連携していることを確認しなければなりません。従来、これらの依存関係の解決には多大な時間がかかり、環境間での差異が生じる原因となっていました。NVIDIAは、Dynamo 1.4.2とそのサポートインフラストラクチャをAICRにバンドルすることでこの課題に対応しており、特定のハードウェアおよびクラウド環境向けに事前検証済みの構成を提供します。

ランタイムは、ギャングスケジューリングセマンティクス、Prometheusメトリクス統合、GPU検出メカニズムなどの重要な要件を捕捉します。コンポーネントのバージョンを固定し、互換性の制約を定義することで、AICRは基盤となるクラスタの状態が推論ワークロードの期待値と一致することを保証します。このアプローチにより、ランタイムセットアップの複雑さをアプリケーションデプロイプロセスから分離し、開発者はインフラストラクチャのデバッグではなく、モデルの挙動に集中できるようになります。

AICRは、Dynamoに対して2つの主要なルーティングパスをサポートしています。ネイティブのDynamo Frontendルーターと、Endpoint Picker Plugin（EPP）を組み合わせたGateway API Inference Extension（GAIE）です。どちらを選ぶかは、チームがモデル固有のエンドポイントを管理するのか、それとも共有Kubernetes ingressを使用するのかによって決まります。両方のパスともKVキャッシュ認識を活用してトークン生成を最適化しますが、クラスタトポロジー内でのトラフィックの転送および管理方法が異なります。

仕組み

Dynamo 1.4.2は、リクエストプレーンをKVキャッシュイベントプレーンから分離しています。標準的なリクエストにはTCPを、KVキャッシュイベントにはZeroMQ（ZMQ）を使用します。各vLLMワーカーはローカルで生のキャッシュイベントを発行し、Dynamoランタイムがこれを正規化して再発行します。これにより、両方のルーティングパスがキャッシュ認識型の判断を下せるようになり、関連するプロンプトプレフィックスをすでにメモリに保持しているワーカーへリクエストを送信できます。このメカニズムにより、トークンの再処理が必要なくなり、エージェント型ワークフローにおけるレイテンシとスループットが向上します。

AICRのデプロイフローは5つの明確なステップに従います。まず、エンジニアは現在のクラスタ状態のスナップショットを取得し、ノードラベルとテイントを記録します。次に、AICRは検出されたハードウェアとKubernetesディストリビューションに基づいてDynamo推論レシピを生成します。3番目に、バージョンを固定したデプロイメントバンドルをレンダリングします。4番目に、HelmfileやGitOpsツールを使用してランタイムをデプロイします。最後に、システムはインストールされたランタイムを検証し、アプリケーションワークロードがスケジュールされる前にインフラストラクチャが本番トラフィックに対応できる状態であることを確認します。

主要な詳細

• AICRはdynamo-platformチャートとともにDynamo 1.4.2をパッケージ化しており、従来のv1alpha1 APIをv1beta1に置き換えています。
• デフォルトのルーティングパスはDynamo Frontendルーターを使用しますが、GAIE/EPPパスはGateway APIリソースを介して共有Kubernetes ingressと統合されます。
• NATSはdynamo-platformチャートではデフォルトでインストールされなくなりましたが、特定のデプロイメント向けにオプトインコンポーネントとして引き続き利用可能です。
• サポートされているインフラストラクチャコンポーネントには、NVIDIA GPU Operator、KAI Scheduler、オーケストレーション用のGrove、ノードヘルスチェック用のNVSentinelが含まれます。
• Dynamo 1.5では、現在のGo/CGOブリッジを置き換えるネイティブRust EPPが導入され、GAIEパスにおけるリクエストごとのオーバーヘッドが削減されます。
• 検証レシピは特定のバージョンを固定しており、例えばAmazon EKSセットアップではNVIDIA GPU Operator v26.7.1およびKube Prometheus Stack 84.4.0などが指定されています。

なぜ重要なのか

インフラストラクチャエンジニアにとって、主な利点は再現性です。GPUオペレーター、スケジューラー、監視スタックを手動で設定すると、しばしばドリフトや微妙な非互換性が生じます。AICRの検証済みレシピは、NVIDIA GB200 NVL72などの特定ハードウェア向けに既知の良い構成を提供することで、こうした推測を排除します。これにより運用負荷が軽減され、クラスタのプロビジョニングからモデル提供までの時間が短縮されます。

開発者は、一貫したパフォーマンス特性の恩恵を受けます。KVキャッシュイベントが適切にルーティングされ、ギャングスケジューリングが強制されることを保証することで、ランタイムはキャッシュミスやリソース競合によるレイテンシスパイクを最小限に抑えます。この信頼性は、特にコンテキスト保持が重要な長時間実行されるエージェント型セッションを含む、レスポンシブなAIアプリケーションの構築において不可欠です。

実施可能なこと

• NVIDIA AI Cluster Runtimeをインストールし、特定のKubernetes環境向けに検証済みレシピを生成してください。
• ユースケースがDynamo Frontendルーターのシンプルさを必要とするのか、それともGAIE/EPPの共有ingress機能を必要とするのかを評価してください。
• 最新のオペレーター標準に合わせて、既存のDynamoデプロイメントをv1beta1 APIバージョンに更新してください。
• ルーティングパフォーマンスを最適化するために、vLLMワーカーでプレフィックスキャッシュとZMQベースのKVキャッシュイベントを有効に設定してください。
• 新しい推論レシピを生成する前に、AICRのスナップショット機能を使用して現在のクラスタ状態を監査してください。
• ゲートウェイオーバーヘッドの削減を実現する予定のネイティブRust EPPを活用するために、Dynamo 1.5への移行を監視してください。