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レシピ

Amazon EKS向けDynamo推論レシピのHelmチャートのバージョン
コンポーネントバージョン
NVIDIA GPU Operatorv26.7.1
Node Feature Discovery0.19.0
cert-managerv1.20.2
AWS EBS CSI Driver2.59.0
AWS EFAv0.5.29
NVSentinelv1.25.0
NodeWright Operatorv0.19.0
NVIDIA DRA GPU Driver0.5.0
KAI Schedulerv0.16.9
Grovev0.1.0-alpha.13
Dynamo Platform1.4.2
Agent Gatewayv1.5.0
Agent Gateway CRDsv1.5.0
Kube Prometheus Stack84.4.0
Prometheus Operator CRDs28.0.1
Prometheus Adapter5.3.0
Kubernetes Ephemeral Storage Metrics1.19.2

この組み合わせをデプロイ用バンドルにしてインストールした後、デプロイ検査と適合性検査を実行する。検査に合格したら、アプリケーション構成をインストールし、推論の接続先を試験する。インストールにはHelmfileを使用でき、AICRはリポジトリの設定に沿ってデプロイを管理するGitOps向けのバンドルも生成する。

4. 検査結果でアプリのデプロイ前に基盤を確認する

検査項目はレシピごとに異なり、Dynamo向けの検査では通常、クラスターのリソースとGPUの利用可能状況、プラットフォームコンポーネントの状態、GPUへのアクセス、ジョブの配置と自動スケーリング、監視指標を確認する。ゲートウェイを使うレシピは、リクエストの入口の準備状態も点検する。

オフライン検査は、別のクラスターのスナップショットとレシピの条件を照合し、実際の動作検査は省略する。性能検証は、一時的なサービングジョブが検査対象のGPUを使うため、別途実行する。

レシピと事前検査は、インフラの組み合わせを繰り返し調整する負担を減らす一方で、バージョンが固定されたコンポーネント群をまとめて運用・管理する課題を残す。共有の入口を選べば、リクエストの転送ポリシーを中央で管理できるが、ゲートウェイやワーカー選択器、補助プロセスなど、運用対象も増える。

AICRの核心は、Dynamoの推論機能よりも、その下のランタイムを標準化し、アプリのデプロイ前に適合性を確認することにある。