NVIDIAは、AI推論サービスをKubernetes上で動かすチーム向けに、基盤ソフトウェアを一括でインストールして検査する方法を紹介した。プラットフォームチームが検証済みの構成レシピで実行環境を用意すれば、開発チームは基盤コンポーネントの調整ではなく、モデルの動作とアプリケーション統合により集中できる。
1. 推論グラフを支える基盤をまとめて整える
NVIDIA Dynamoは、複数のGPUワーカー、つまり作業プロセスにまたがるモデルサービングを調整する分散推論フレームワークだ。その運用には、GPUドライバーからリソース割り当て、ジョブの配置、ネットワーク、監視までが連携する必要がある。
NVIDIA AI Cluster Runtime(AICR)は、この基盤ソフトウェアをDynamoとともにレシピとして提供するオープンソースだ。レシピは、インストールするコンポーネントと設定、検査項目をまとめた、実行環境の組み立て説明書に相当する。
各レシピは、特定の環境と作業に合わせてコンポーネントのバージョンと互換性条件を固定する。設定値や実行先ノードの条件、検証の期待値も記録し、同じ環境の再構築を支援する。NVIDIAは、指定されたプラットフォームとハードウェアで、レシピのバージョンの組み合わせをまとめて試験したと説明した。
2. 2つのルーティング経路からインフラの運用主体に合わせて選ぶ
一方の経路では、Dynamo Frontendがリクエストをワーカーへ直接送る。以前のリクエストの計算結果を保存したKVキャッシュの再利用可能性と現在の負荷に基づき、ワーカーを選ぶ。モデルごとの接続先をアプリケーションチームが担当する場合や、リクエストを代わりに転送するサーバーである既存のプロキシへリクエストを送る場合に適しており、2つの方式のうち構成がより単純だ。
もう一方の経路は、リクエストの入口を管理するGateway APIと、ワーカー選択を担うDynamo EPPを組み合わせる。ゲートウェイが選択されたワーカーにリクエストを送ると、ワーカーに付随する補助プロセスがそれを当該ワーカーへ転送する。複数モデルへの入口とタイムアウト、再試行、フォールバックをプラットフォームチームが管理する場合に適している。
どちらの経路も、ワーカーが報告したKVキャッシュの状態を使う。同じ先頭部分を持つリクエストを、計算結果がすでにあるワーカーへ送り、中間計算の繰り返しを減らす仕組みだ。
3. レシピの選択からランタイムの検査まで進める
AICRは、ランタイムのインストールとアプリケーションのデプロイを分離する。まず構成状態を記録するクラスタースナップショットを作り、ディストリビューション、GPU、GPUノードのOSに適した推論レシピを生成する。
aicr snapshot \
--namespace aicr-validation \
--output snapshot.yaml以下の表は、特定のGPUシステムとクラウド環境向けのレシピが選んだコンポーネントのバージョンだ。個々のツールの最新版を集めるのではなく、その環境でまとめて試験した組み合わせの再現に重点を置く。
AICR v1.0.0のNVIDIA GB200 NVL72およびNVIDIA GB300 NVL72システム向けAmazon EKSレシピ
| コンポーネント | バージョン |
|---|---|
| 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 |
この組み合わせをデプロイ用バンドルにしてインストールした後、デプロイ検査と適合性検査を実行する。検査に合格したら、アプリケーション構成をインストールし、推論の接続先を試験する。インストールにはHelmfileを使用でき、AICRはリポジトリの設定に沿ってデプロイを管理するGitOps向けのバンドルも生成する。
4. 検査結果でアプリのデプロイ前に基盤を確認する
検査項目はレシピごとに異なり、Dynamo向けの検査では通常、クラスターのリソースとGPUの利用可能状況、プラットフォームコンポーネントの状態、GPUへのアクセス、ジョブの配置と自動スケーリング、監視指標を確認する。ゲートウェイを使うレシピは、リクエストの入口の準備状態も点検する。
オフライン検査は、別のクラスターのスナップショットとレシピの条件を照合し、実際の動作検査は省略する。性能検証は、一時的なサービングジョブが検査対象のGPUを使うため、別途実行する。
レシピと事前検査は、インフラの組み合わせを繰り返し調整する負担を減らす一方で、バージョンが固定されたコンポーネント群をまとめて運用・管理する課題を残す。共有の入口を選べば、リクエストの転送ポリシーを中央で管理できるが、ゲートウェイやワーカー選択器、補助プロセスなど、運用対象も増える。
AICRの核心は、Dynamoの推論機能よりも、その下のランタイムを標準化し、アプリのデプロイ前に適合性を確認することにある。
