はじめに
LLMの推論コストは、モデルの大規模化に伴い急速に増大している。DeepSeek-R1（671Bパラメータ）のような推論特化モデルを本番環境で運用するには、複数GPUにまたがる分散推論基盤が不可欠になった。
NVIDIA Dynamoは、この課題に正面から取り組むオープンソースの分散推論フレームワークである。GTC 2025で発表され、2026年に入ってGcore、AWS、Moonshot AIなどが本番採用を進めている。GTC 2026（2026年3月16〜19日）の開幕に合わせ、エコシステムの拡大が加速している。
この記事では、NVIDIA Dynamoのアーキテクチャ、主要機能、セットアップ手順、そしてパフォーマンスの実績を解説する。
この記事で学べること
- NVIDIA Dynamoの4コンポーネントアーキテクチャ
- disaggregated serving（プリフィル・デコード分離）の仕組みと効果
- vLLM / SGLang / TensorRT-LLM との統合方法
- ローカル開発からKubernetesデプロイまでのセットアップ手順
対象読者
- LLM推論コストの削減を検討しているMLエンジニア
- 分散推論基盤を構築するプラットフォームエンジニア
- vLLM / SGLang を本番運用しているチーム
TL;DR
- NVIDIA DynamoはRust + Pythonで構築された分散LLM推論フレームワーク（OSS）
- プリフィルとデコードを異なるGPUに分離する「disaggregated serving」で、DeepSeek-R1 671Bにおいて最大30倍のスループット向上を達成
- vLLM・SGLang・TensorRT-LLMの3バックエンドに対応し、OpenAI互換APIを提供
- DockerまたはPyPI（
ai-dynamoパッケージ）でインストール可能
NVIDIA Dynamoのアーキテクチャ
NVIDIA Dynamoは4つのコアコンポーネントで構成される。それぞれが独立した役割を担い、分散推論の各段階を最適化する設計になっている。
1. Planner（動的GPU割り当て）
Plannerは、GPUの使用率・キュー長・SLA要件をリアルタイムで監視し、ワークロードに応じてGPUリソースを動的に配分する。具体的には、リクエストの特性に基づいて「disaggregated serving（プリフィルとデコードを分離）」と「aggregated serving（単一GPUで処理）」を自動で切り替える。
短いプロンプトが中心のワークロードでは aggregated が効率的で、長文プロンプトが多い場合は disaggregated が有利になる。Plannerがこの判断をSLAベースで自動化する点が特徴である。
2. Smart Router（KV-aware ルーティング）
Smart Routerは、Radix Tree構造でクラスタ全体のKVキャッシュ位置を追跡する。新しいリクエストが到着すると、プロンプトのプレフィックスとキャッシュ済みデータの重なり度合い（overlap score）を計算し、KVキャッシュの再計算を最小化するGPUにルーティングする。
公式ブログによると、この仕組みにより TTFT（Time-to-First-Token）と平均レイテンシの両方が改善される。
3. Distributed KV Cache Manager（階層型キャッシュ）
KV Cache Managerは、以下の4階層でキャッシュを管理する。
| 階層 | ストレージ | 特徴 |
|---|---|---|
| L1 | GPUメモリ（HBM） | 最高速・容量限定 |
| L2 | CPUホストメモリ | 大容量・中速 |
| L3 | ローカルSSD | 大容量・低速 |
| L4 | ネットワークストレージ | 超大容量・最低速 |
トークン単価の高いGPUメモリの使用量を抑えながら、キャッシュヒット率を維持する設計になっている。推論コスト削減の中核を担うコンポーネントである。
4. NIXL（NVIDIA Inference Transfer Library）
NIXLは、GPU間の高スループット・低レイテンシなポイントツーポイント通信を実現するライブラリである。NVLink、InfiniBand、RoCE、Ethernetなど異種ネットワーク環境に対応し、disaggregated servingにおけるプリフィルGPUからデコードGPUへのKVキャッシュ転送を高速化する。
Disaggregated Serving の仕組み
NVIDIA Dynamoの最大の特徴は「disaggregated serving」 — プリフィルフェーズとデコードフェーズを異なるGPUグループに分離して実行する仕組みである。
なぜ分離が有効なのか
LLMの推論は2つのフェーズで構成される。
| フェーズ | 処理内容 | ボトルネック |
|---|---|---|
| プリフィル | 入力トークン全体を一括処理しKVキャッシュを生成 | 計算量（compute-bound） |
| デコード | トークンを1つずつ生成 | メモリ帯域（memory-bound） |
従来の推論サーバーでは、1つのGPUが両フェーズを逐次処理するため、計算リソースとメモリ帯域のどちらかが常にアイドル状態になる。Dynamoはこれを分離し、プリフィルGPUには高い計算並列度（Tensor Parallelism）を、デコードGPUにはメモリ帯域最適化をそれぞれ独立して適用する。
パフォーマンス実績
NVIDIAの公式ブログおよびパートナー企業の報告に基づく実績値を以下に示す。
| モデル | 環境 | 改善内容 |
|---|---|---|
| DeepSeek-R1 671B | GB200 NVL72 | スループット最大30倍向上 |
| Llama 70B | Hopper GPU | スループット2倍以上 |
| Moonshot AI Kimi K2 | GB200 NVL72 vs H200 | フルスタック（Dynamo + NVFP4）で推論性能10倍 |
| Gcore本番環境 | - | スループット6倍・レイテンシ2倍改善 |
対応バックエンドと機能マトリクス
NVIDIA Dynamoは3つの推論エンジンをバックエンドとしてサポートする。いずれもOpenAI互換APIを通じてアクセスできる。
| 機能 | vLLM | SGLang | TensorRT-LLM |
|---|---|---|---|
| Disaggregated Serving | ✅ | ✅ | ✅ |
| KV-aware Routing | ✅ | ✅ | ✅ |
| SLA-based Planning | ✅ | ✅ | ✅ |
| マルチモーダル | ✅ | ✅ | ✅ |
| Tool Calling | ✅ | ✅ | ✅ |
既存のvLLMやSGLang環境をDynamoに移行する場合、バックエンドの推論ロジック自体はそのまま活用でき、Dynamoがオーケストレーション層として動作する。
セットアップガイド
方法1: Dockerコンテナ（推奨）
依存関係の管理が不要な最も簡単な方法である。
docker run --gpus all --network host \
nvcr.io/nvidia/ai-dynamo/sglang-runtime:1.0.0
vLLMバックエンドの場合:
docker run --gpus all --network host \
nvcr.io/nvidia/ai-dynamo/vllm-runtime:1.0.0
方法2: PyPIからインストール
uv パッケージマネージャーが推奨されている。
# SGLangバックエンドの場合
uv pip install "ai-dynamo[sglang]"
# vLLMバックエンドの場合
uv pip install "ai-dynamo[vllm]"
システム要件:
- OS: Ubuntu 24.04
- CPU: x86_64
- GPU: CUDA対応NVIDIA GPU
ローカル開発でのクイックスタート
外部依存なしでローカル環境で起動する手順を示す。
1. フロントエンド（OpenAI互換APIサーバー）を起動:
python3 -m dynamo.frontend \
--http-port 8000 \
--discovery-backend file
2. SGLangワーカーを起動:
python3 -m dynamo.sglang \
--model-path Qwen/Qwen3-0.6B \
--discovery-backend file
vLLMの場合は以下のコマンドになる。
python3 -m dynamo.vllm \
--model Qwen/Qwen3-0.6B \
--discovery-backend file \
--kv-events-config '{"enable_kv_cache_events": false}'
--discovery-backend file フラグにより、NATSなどの外部サービスなしでローカル開発が可能になる。vLLMでは追加で --kv-events-config によるKVイベント無効化が必要である。
3. リクエスト送信:
curl http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "Qwen/Qwen3-0.6B",
"messages": [
{"role": "user", "content": "Explain NVIDIA Dynamo in one sentence."}
]
}'
OpenAI互換APIのため、既存のOpenAI SDKクライアントコードをそのまま利用できる。
Kubernetesデプロイ
本番環境ではKubernetes上にデプロイするのが一般的である。DynamoはネイティブのKubernetesリソース（CRDおよびEndpointSlice）をサービスディスカバリに活用する。
公式リポジトリには以下のモデル向けのデプロイレシピが用意されている。
| モデル | バックエンド | レシピ |
|---|---|---|
| Llama-3-70B | vLLM | deploy/k8s/llama-3-70b-vllm/ |
| DeepSeek-R1 | SGLang | deploy/k8s/deepseek-r1-sglang/ |
| Qwen3-32B-FP8 | TensorRT-LLM | deploy/k8s/qwen3-32b-fp8-trtllm/ |
AWS EKSでの構築手順は、AWSの公式ブログ「Accelerate generative AI inference with NVIDIA Dynamo and Amazon EKS」にも記載されている。
Triton Inference Server との関係
NVIDIA Dynamoは、NVIDIA Triton Inference Serverの後継として位置づけられている。Tritonが汎用的なモデルサービング（画像分類、音声認識など含む）を担ってきたのに対し、DynamoはLLM/生成AIの推論に特化している。
主な違いは以下の通りである。
| 観点 | Triton Inference Server | NVIDIA Dynamo |
|---|---|---|
| 対象ワークロード | 汎用（CV、NLP、音声） | LLM・生成AI特化 |
| 分散推論 | 手動構成 | 自動（disaggregated serving） |
| KVキャッシュ管理 | なし | 階層型キャッシュ + ルーティング |
| 実装言語 | C++ | Rust + Python |
| APIインターフェース | gRPC / HTTP | OpenAI互換API |
既存のTriton環境からの移行では、OpenAI互換APIを通じたクライアント側の変更が最小限で済む点がメリットとなる。
エンタープライズ採用事例
2026年に入り、以下の企業・クラウドプロバイダーがNVIDIA Dynamoを本番環境に採用している。
Gcore: NVIDIAのDynamo推論フレームワークをAIスタックに統合し、フルマネージドサービスとして提供。スループット最大6倍、レイテンシ最大2倍の改善を報告している。
AWS: Amazon EKS上でのDynamoデプロイガイドを公式ブログで公開。EKS + Dynamoの組み合わせにより、マネージドKubernetes上で分散推論を即座に展開できる。
Moonshot AI: 自社モデルKimi K2のGB200上での推論速度を10倍に向上させた事例を報告している。
Mistral AI: Mistral Large 3の推論高速化にDynamoを活用。
まとめ
NVIDIA Dynamoは、LLM推論のコストとレイテンシを根本から改善する分散推論フレームワークである。
- disaggregated serving でプリフィルとデコードを分離し、GPU利用効率を最大化する
- KV-aware routing と 階層型キャッシュ で冗長な再計算を排除する
- vLLM・SGLang・TensorRT-LLM の3バックエンドに対応し、既存環境からの移行障壁が低い
- OpenAI互換API を提供するため、クライアントコードの変更が最小限で済む
GTC 2026の開幕とともに、NVIDIA推論エコシステムの中核として注目度が高まっている。LLMの推論コスト削減を検討しているチームにとって、最初に評価すべきフレームワークの一つである。