Related Resources
Generative AI

NVIDIA Grove で Kubernetes 上の複雑な AI 推論を合理化する

NVIDIA Dynamo の新コンポーネントにより分散型推論の効率的なスケーリングが可能になる

2025 年 11 月 10 日
By , , and
Reading Time: 3 minutes

ここ数年間で AI 推論は単一モデル、単一ポッドのデプロイから複雑なマルチコンポーネント システムへと進化しました。現在では、プレフィル、デコード、ビジョン エンコーダー、キー バリュー (KV) ルーターなど、いくつかの異なるコンポーネントが協調して動作するモデルデプロイが一般的です。さらに、複数のモデル インスタンスが協調して推論、検索、マルチモーダル タスクのすべてを行うエージェント型パイプラインが登場しつつあります。

この変化により、スケーリングとオーケストレーションの課題が「1 つの pod を N 個複製して実行する」というものから「1 つの論理システムとして複数コンポーネントを調整する」というものに進化しました。このようなシステムを管理するには、それぞれのコンポーネントに異なる設定やリソース要件があることを理解したうえで 適切な pod を連携してスケーリングおよびスケジューリングし、想定された順序で起動し、さらにネットワーク トポロジーを考慮してクラスタ内に配置する必要があります。最終的な目標は、個々の pod を個別に扱うのではなく、コンポーネント間の依存関係を踏まえてシステム全体を統合的にオーケストレーションし、スケーリングすることにあります。 これらの課題に対処するために、Kubernetes クラスタ上で最新の ML 推論ワークロードを実行するための Kubernetes API である NVIDIA Grove が NVIDIA Dynamo 内でモジュール型コンポーネントとして利用できるようになったことを本日発表します。Grove は完全なオープン ソースであり、ai-dynamo/grove GitHub リポジトリで利用できます。

NVIDIA Grove が推論全体としてオーケストレーションする仕組み

Grove を導入すると、マルチノードの推論デプロイを単一レプリカからデータ センター規模までスケールし、数万台の GPU をサポート可能となります。Grove があれば、Kubernetes 内の推論サービング システム全体 (プレフィル、デコード、ルーティング、またはその他のコンポーネントなど) を単一のカスタム リソース (CR) として記述できます。

この仕様に基づき、階層的ギャング スケジューリング、トポロジー認識型配置、マルチレベル自動スケーリング、明示的な起動順序の制御などを実行します。これにより、スクリプトや YAML ファイル、カスタム コントローラーを組み合わせることなく、システムの動作を正確に制御できます。

Grove はもともとマルチノード分離型推論システムのオーケストレーションに伴う課題を解決するために開発されましたが、従来のシングルノード集約型推論から複数のモデルを用いたエージェント型パイプラインまで、実際のあらゆる推論アーキテクチャに柔軟に対応できます。Grove によって、開発者は複雑な AI スタックを簡潔で宣言的かつフレームワークに依存しない方法で定義できます。

マルチノード分離型サービングの前提条件は以下に詳述します。

相互依存コンポーネントのマルチレベル自動スケーリング

現代の推論システムはマルチレベルでの自動スケーリング、すなわち、個々のコンポーネント (トラフィック急増時のプレフィル ワーカー)、関連コンポーネント グループ (プレフィル リーダーとそのワーカー)、全体的処理能力に対するサービス レプリカ全体、というそれぞれのレベルにおけるスケーリングが求められます。これらのレベルは互いに影響し合います。プレフィル ワーカーをスケールさせるには、デコードの処理能力も増やす必要があり、新しいサービス レプリカには適切なコンポーネント比率が必要になります。従来の pod レベルの自動スケーリングでは、こうした相互依存関係を処理できません。

復旧とローリング アップデートを備えたシステムレベルのライフサイクル管理

復旧とアップデートは、個々の Kubernetes pod ではなく、完全なサービス インスタンス上で動作する必要があります。プレフィル ワーカーに障害が発生した場合、再起動後、そのリーダーに正しく再接続する必要があります。ローリング  アップデートの際には、低遅延を維持するためにネットワーク トポロジーを保持しなければなりません。このプラットフォームは、マルチコンポーネント システムを、性能と可用性の両面で最適化された単一の運用単位として扱わなければなりません。

柔軟な階層型ギャング スケジューリング

AI ワークロード スケジューラーは、従来の「イチかゼロか」で配置するやり方を超える、柔軟なギャング スケジューリングをサポートする必要があります。分離型サービングは新たな課題を生み出します。推論システムでは、必須のコンポーネントの組み合わせ (少なくとも 1 つのプレフィルおよびデコード ワーカーなど) を確保しつつ、各種コンポーネントの独立したスケーリングを可能にする必要があります。課題は、プレフィル コンポーネントとデコード コンポーネントを、 ワークロードのパターンに応じて異なる比率でスケーリングしなければならない点にあります。

従来のギャング スケジューリングでは、すべてのコンポーネントを同時にスケーリングしなければならないグループとして扱うため、このような独立したスケーリングができなくなってしまいます。このシステムには、柔軟なスケーリングを可能にしつつ、 最低限必要なコンポーネントの組み合わせを確保するポリシーが求められます。

トポロジー認識型スケジューリング

コンポーネントの配置はパフォーマンスに影響します。NVIDIA GB200 NVL72 などのシステムでは、関連するプレフィルとデコードの pod を同じ NVIDIA NVLink ドメイン上でスケジュールすることにより、KV キャッシュの転送レイテンシを最適化します。このスケジューラは物理的なネットワークのトポロジーを理解し、レプリカを分散させ可用性を確保しつつ、関連するコンポーネントを互いの近くに配置する必要があります。

ロール認識型オーケストレーションと明示的な起動順序

コンポーネントには、異なるジョブ、構成、起動要件があります。たとえば、プレフィルおよびデコードのリーダーはワーカーとは異なる専用の起動ロジックを実行します。リーダーの準備が完了する前にワーカーを起動することはできません。このプラットフォームは、信頼性の高い初期化のために、ロールに固有の構成と依存関係の強制を必要とします。

これらをすべて総合して考えると、全体像は次のようになります。推論チームは、実際の運用形態 (複数のロール、複数のノード、明確なマルチレベルの依存関係) を反映したシステムを記述し、自動的にスケジューリング、スケーリング、復旧および更新を行う、簡潔かつ宣言的な方法を必要としています。

Grove プリミティブ

高性能な推論フレームワークは、Grove の階層型 API を利用し、ロール固有のロジックやマルチレベルのスケーリングを表現します。これにより、多様なクラスター環境においても、一貫性のある最適化されたデプロイが可能になります。Grove は、Workload API の 3 つの階層的カスタム リソースを使用してマルチコンポーネント AI ワークロードをオーケストレーションすることで、これを達成します。

図 1 の例については、PodClique A はフロント エンドコンポーネントを表し、B と C はプレフィル リーダーとプレフィル ワーカーを表し、D と E はデコード リーダーとデコード ワーカーを表します。

NVIDIA Grove の主要コンポーネント (PodClique、ScalingGroup、PodCliqueSet) が相互に関連する仕組みを示す図。PodCliqueSet には 2 つのレプリカがあり、可用性のためにネットワークを分散させる外部境界を提供します。内部では、複数の PodClique が ScalingGroup にグループ化され、論理的なステージ「プレフィル」と「デコード」を表します。各 PodClique はそれぞれのレプリカ数と最小可用数を指定します。たとえば、「PodClique C」に 3 つのレプリカと最小可用数 2 を指定します。
図 1. NVIDIA Grove の主要コンポーネントである PodClique、ScalingGroup、PodCliqueSet と、その連携する仕組み
  • PodClique は、特定の役割を持つ Kubernetes pod グループを表します。たとえば、プレフィル リーダーまたはワーカー、デコード リーダーまたはワーカー、フロントエンド サービスにそれぞれ、独立した構成とスケーリング ロジックがあります。
  • PodCliqueScalingGroup は、密接に連携してスケーリングすべき PodClique をひとまとめにするものです。たとえば、プレフィル リーダーとプレフィル ワーカーが共に 1 つのモデル インスタンスを表します。
  • PodCliqueSet はマルチコンポーネント ワークロード全体を定義します。その中で、起動順序、スケーリング ポリシー、ギャング スケジューリング制約を指定し、すべてのコンポーネントが同時に起動または同時に失敗するようにします。追加の処理能力を確保するためにスケールする際、Grove は PodGangSet 全体の完全なレプリカを作成し、それらのレプリカをクラスター全体に分散配置するための分散制約を定義します。これにより、高可用性を維持しつつ、各レプリカのコンポーネントは最適なパフォーマンスを発揮できるようにネットワーク的に密接に配置されます。
Grove ワークフローを示す図。ユーザーが PodCliqueSet を定義し、それが Grove オペレーターによって処理されます。このオペレーターは、PodClique、ScalingGroup (プレフィルとデコード)、Secret、HPA、Service などのリソースを作成し、管理します。これらのリソースが組み合わされ、スケジュール可能な作業単位を表す PodGang が作られます。その後、PodGang は Advanced AI Scheduler (KAI スケジューラーなど) に渡されます。図の右側には、GPU 対応ノードで動作する複数の pod が示されています。
図 2. Grove ワークフロー

Grove 対応の Kubernetes クラスターは、次の 2 つの主要コンポーネントを組み合わせています。Grove オペレーターと、PodGang リソースを理解できるスケジューラーです。そのようなスケジューラーには、たとえば、NVIDIA Run:ai プラットフォームのオープンソース サブコンポーネントである KAI Scheduler があります。

PodCliqueSet リソースが作成されると、Grove オペレーターが仕様の有効性を検証し、それを実現するために必要となる基本的な Kubernetes オブジェクトを自動生成します。これには、構成要素となる PodClique、PodCliqueScalingGroup、および関連する pod、service、secret、自動スケーリング ポリシーが含まれます。このプロセスの一環として、Grove は PodGang リソースも作成します。これは Scheduler API の一部であり、ワークロードの定義をクラスターのスケジューラー用の具体的なスケジューリング制約に変換します。

各 PodGang は、最小レプリカ保証、コンポーネント帯域幅を最適化するためのネットワーク トポロジー設定、可用性を維持するための分散制約など、ワークロードの詳細な要件をカプセル化します。これらを組み合わせることで、トポロジーを意識した配置とクラスター全体での効率的なリソース利用が確保されます。

スケジューラーは継続的に PodGang リソースを監視し、ギャング スケジューリング ロジックを適用します。それにより、必要なすべてのコンポーネントが、リソースが利用可能になるまで「すべて同時にスケジュールされる」か「まったくされない」という動作を保証します。配置は GPU トポロジーの認識とクラスターの局所性を念頭に置いて決定されます。

その結果、マルチコンポーネント AI システムが統合的にデプロイされます。具体的には、プレフィル サービス、デコード ワーカー、ルーティング コンポーネントが 正しい順序で起動し、ネットワーク パフォーマンスのために近接配置され、さらにグループとして一貫した形で復旧されます。これにより、リソースの断片化が防止され、部分的なデプロイが回避され、大規模かつ複雑なモデル サービング パイプラインの安定的かつ効率的な運用が可能になります。

Dynamo で Grove を始める方法

このセクションでは、Dynamo と Grove を使用して KV ルーティング デプロイヤーを備えた分離型サービング アーキテクチャをデプロイする方法を説明します。このセットアップでは、Qwen3 0.6B モデルを使用し、Grove が分散型推論ワークロードを別々のプレフィル ワーカーとデコード ワーカーで管理する機能を示しています。

注: これは中心的な概念を理解するための基本的な例です。より複雑なデプロイについては、ai-dynamo/grove GitHub リポジトリを参照してください。

前提条件

まず、Kubernetes クラスターに次のコンポーネントが準備されていることを確認します。

  • GPU 対応の Kubernetes クラスター
  • クラスターにアクセスするように設定された kubectl
  • インストール済みの Helm CLI
  • Hugging Face トークン シークレット (hf-token-secret として参照される)。これは次のコマンドで作成できます。
kubectl create secret generic hf-token-secret \
  --from-literal=HF_TOKEN=<insert_huggingface_token>

注: このコードで、<insert_huggingface_token> を実際の Hugging Face トークンに置き換えます。このトークンは安全な場所に保管してください。ソースコード管理システムなどにコミットしないでください。

ステップ 1: 名前空間を作成する

kubectl create namespace vllm-v1-disagg-router

ステップ 2: Dynamo CRD と Dynamo Operator を Grove と共にインストールする

# 1. Set environment
export NAMESPACE=vllm-v1-disagg-router
export RELEASE_VERSION=0.5.1
 
# 2. Install CRDs
helm fetch https://helm.ngc.nvidia.com/nvidia/ai-dynamo/charts/dynamo-crds-${RELEASE_VERSION}.tgz
helm install dynamo-crds dynamo-crds-${RELEASE_VERSION}.tgz --namespace default
 
# 3. Install Dynamo Operator + Grove
helm fetch https://helm.ngc.nvidia.com/nvidia/ai-dynamo/charts/dynamo-platform-${RELEASE_VERSION}.tgz
helm install dynamo-platform dynamo-platform-${RELEASE_VERSION}.tgz --namespace ${NAMESPACE} --create-namespace --set "grove.enabled=true"

ステップ 3: Grove のインストールを確認する

kubectl get crd | grep grove

期待出力:

podcliques.grove.io                             
podcliquescalinggroups.grove.io                  
podcliquesets.grove.io                           
podgangs.scheduler.grove.io                      
podgangsets.grove.io

ステップ 4: DynamoGraphDeployment 構成を作成する

フロントエンド 1 つ、デコード ワーカー 2 つ、プレフィル ワーカー 1 つの分離型サービング アーキテクチャを定義する DynamoGraphDeployment マニフェストを作成します。

apiVersion: nvidia.com/v1alpha1
kind: DynamoGraphDeployment
metadata:
  name: dynamo-grove
spec:
  services:
    Frontend:
      dynamoNamespace: vllm-v1-disagg-router
      componentType: frontend
      replicas: 1
      extraPodSpec:
        mainContainer:
          image: nvcr.io/nvidia/ai-dynamo/vllm-runtime:0.5.1
      envs:
        - name: DYN_ROUTER_MODE
          value: kv
    VllmDecodeWorker:
      dynamoNamespace: vllm-v1-disagg-router
      envFromSecret: hf-token-secret
      componentType: worker
      replicas: 2
      resources:
        limits:
          gpu: "1"
      extraPodSpec:
        mainContainer:
          image: nvcr.io/nvidia/ai-dynamo/vllm-runtime:0.5.1
          workingDir: /workspace/components/backends/vllm
          command:
          - python3
          - -m
          - dynamo.vllm
          args:
            - --model
            - Qwen/Qwen3-0.6B
    VllmPrefillWorker:
      dynamoNamespace: vllm-v1-disagg-router
      envFromSecret: hf-token-secret
      componentType: worker
      replicas: 1
      resources:
        limits:
          gpu: "1"
      extraPodSpec:
        mainContainer:
          image: nvcr.io/nvidia/ai-dynamo/vllm-runtime:0.5.1
          workingDir: /workspace/components/backends/vllm
          command:
          - python3
          - -m
          - dynamo.vllm
          args:
            - --model
            - Qwen/Qwen3-0.6B
            - --is-prefill-worker

ステップ 5: 構成をデプロイする

kubectl apply -f dynamo-grove.yaml -n ${NAMESPACE}

ステップ 6: デプロイを確認する

operator と Grove pod が作成されたことを確認する:

kubectl get pods -n ${NAMESPACE}

期待出力:

NAME                                                              READY   STATUS    RESTARTS      AGE
dynamo-grove-0-frontend-w2xxl                                     1/1     Running     0           10m
dynamo-grove-0-vllmdecodeworker-57ghl                             1/1     Running     0           10m
dynamo-grove-0-vllmdecodeworker-drgv4                             1/1     Running     0           10m
dynamo-grove-0-vllmprefillworker-27hhn                            1/1     Running     0           10m
dynamo-platform-dynamo-operator-controller-manager-7774744kckrr   2/2     Running     0           10m
dynamo-platform-etcd-0                                            1/1     Running     0           10m
dynamo-platform-nats-0                                            2/2     Running     0           10m

ステップ 7: デプロイをテストする

まず、フロントエンドをポートフォワードする:

kubectl port-forward svc/dynamo-grove-frontend 8000:8000 -n ${NAMESPACE}

次に、エンドポイントをテストする:

curl http://localhost:8000/v1/models

任意で PodClique リソースを調べ、Grove によって、レプリカ数を含め、pod がグループ化される仕組みを確認できます。

kubectl get podclique dynamo-grove-0-vllmdecodeworker -n vllm-v1-disagg-router -o yaml

さらに続ける準備はできていますか?

NVIDIA Grove は完全にオープン ソースであり、ai-dynamo/grove GitHub リポジトリで利用できます。Dynamo と組み合わせて、スタンドアロン コンポーネントとして、あるいは高性能 AI 推論エンジンと併用して独自の Kubernetes 環境で Grove をお試しください。

Grove Deployment Guide を参照したり、GitHub や Discord で質問したりできます。アトランタで行われる KubeCon 2025 の NVIDIA ブース #753 にお越しいただくと、Grove の動作を実際にご覧いただけます。コミュニティからの貢献、プル リクエスト、フィードバックを歓迎しております。

詳細については、以下の追加リソースをご覧ください。

謝辞

NVIDIA Grove プロジェクトは、開発に参加したすべてのオープンソース 開発者、テスター、コミュニティ メンバーの貴重な貢献に感謝しています。また、SAP (Madhav Bhargava 氏、Saketh Kalaga 氏、Frank Heine 氏) の優れた貢献とサポートに特別な感謝を表します。オープン ソースは協働で繁栄します。Grove へのご参加に感謝します。

Tags

Data Center / Cloud / Edge | Developer Tools & Techniques | Generative AI | Networking | General | Dynamo | GB200 | NVLink | Run:ai | Intermediate Technical | News | Tutorial | AI Inference | Dynamo-Triton | featured | Inference Performance | Kubernetes

About the Authors

About Sanjay Chatterjee
Sanjay Chatterjee は NVIDIA のエンジニアリング マネージャーです。 GPU コンピューティング インフラストラクチャを担当しており、特に、Kubernetes で AI および HPC ワークロードをスケールできるようにする GPU スケジューリングに注力しています。 オープンソース NVIDIA Grove プロジェクトのクリエイター兼アーキテクトです。 以前は、DoE/DARPA が資金提供した複数の高度な技術プロジェクトに関わっており、最初のエクサスケール システムの設計に取り組んでいました。 新しいプログラミング モデル、並列言語、ランタイム システムなどに関心を持っています。
About Anish Maddipoti
Anish Maddipoti は、NVIDIAのプロダクト マネージャーです。現在は NVIDIA Dynamo や NVIDIA Grove といった AI/ML フレームワークの構築に携わっています。以前はBrev.dev (NVIDIAにより買収) の創業メンバーであり、Agora Labs の共同創業者でもありました。テキサス大学オースティン校でPlan IIプログラムを習得。
About Ekin Karabulut
Ekin Karabulut はデータ サイエンティスト兼デベロッパー アドボケートであり、以前は Run:ai に在籍し、現在は NVIDIA に所属し、様々な実稼働シナリオにおける大規模モデルの効率的な活用を研究しています。以前は連合学習のプライバシーへの影響に関する研究に従事し、分散学習技術に焦点を当て、研究や産業環境における GPU 利用の非効率性に強い関心を抱いていました。AI Infrastructure Club を設立し、ドイツのミュンヘンを拠点としています。
About Rohan Varma
Rohan Varma は NVIDIA の AI DevTech エンジニアです。Dynamo、Grove、TensorRT-LLM などの NVIDIA 推論ソリューションの最適化を中心に取り組んでいます。ミシガン大学アナーバー校でコンピューター サイエンスの修士号を取得しました。趣味はレーシング ゲーム、ピアノ、そしてラケットを使うほとんどのスポーツです。