最新テック活用事例とプロダクトアイデア #001
LLMをプロダクションで動かすとき、最初にぶつかるコストの問題はモデルの使用料ではなく「推論インフラ」だ。2026年3月、NVIDIAがオープンソースの推論フレームワーク「Dynamo 1.0」を正式リリースした3。中核となるのはdisaggregated serving（分離推論）──AIの処理を「準備フェーズ」と「出力フェーズ」に分けて別々のGPUで実行することで、Blackwell GPU上でスループットを最大7倍（SemiAnalysis InferenceXベンチマーク）まで引き上げる設計だ。GTC 2025の初期発表時にはGB200 NVL72上でDeepSeek-R1を最大30倍まで高速化した数字も報告されている。Perplexity AIが月間7億件超のクエリをこのアーキテクチャで捌き、PinterestとCursorが本番導入した実例を軸に、この技術が解く問題と事業応用の可能性を解説する。
LLMの処理は「準備」と「出力」の2ステップ──同じGPUに押しつけることの非効率
LLMへのリクエストは内部的に2つの段階で処理される。プリフィル（prefill）フェーズはユーザーが送ったプロンプト全体を一度に処理し、KVキャッシュ（後から参照できる中間データ）を生成する。デコード（decode）フェーズはこのキャッシュを繰り返し読み出しながら、出力トークンを1個ずつ生成する。
問題は、この2つのフェーズでGPUの「使い方」がまったく異なるという点だ。プリフィルは膨大な演算をまとめて行うため、GPUの計算速度そのものがネックになる。一方のデコードは大量のデータを高速に読み出す処理が繰り返されるため、メモリの読み出し速度がネックになる。
従来の構成では両フェーズを同じGPUで実行するため、デコードが多い時間帯にはプリフィル用の計算リソースが余り、逆にプリフィルが混雑すれば最初のトークンが返ってくるまでの時間（TTFT）が大きく跳ね上がる。いわば「高速計算が得意な人と、大量のファイル読み出しが得意な人を、同じ席に座らせて同じ仕事をさせている」ような非効率だ。
AI推論市場は2025年に1,060億ドルを超え、2030年には2,549億ドル（年成長率19.2%）に達するとMarketsandMarketsは予測する 1。同時にGartnerは2030年までに推論コストが現在比90%以上低下すると予測しており、単価は急落するが総量が爆発するというジレンマが続く 2。ハードウェアを買い増しするだけでは対応しきれず、アーキテクチャを根本から見直す必要があった。
「準備」と「出力」を別々のGPUで動かす──Dynamoを支える5つの仕組み
NVIDIA Dynamoは、vLLM・SGLang・TensorRT-LLMといった既存の推論エンジンを「置き換える」のではなく、その上に乗る調整レイヤーとして機能する 3。既存の推論システムをそのまま活かしながら、5つのコンポーネントを組み合わせることで分離推論を実現する。
① プリフィル/デコード分離エンジン
「計算速度重視のプリフィル専用GPUプール」と「メモリ読み出し速度重視のデコード専用GPUプール」を独立して動かす。実際のトラフィックの傾向に合わせて各プールのGPU台数を別々に増減できるため、「プリフィルは2台、デコードは6台」といった偏った構成が可能だ。
② NIXL（NVIDIA Inference Xfer Library）
プリフィルが完了したKVキャッシュをデコード用GPUへ高速転送するための専用ライブラリ。InfiniBandやRoCEなど高速ネットワーク経由のRDMA（メモリ間の直接コピー）と、NVMe-oFやS3互換ストレージまで複数の転送方式をサポートする。Perplexity AIが自社で実装してきたノウハウがこの設計に反映されている 4。
③ KVブロックマネージャー（KVBM）
KVキャッシュをGPUメモリ→CPUメモリ→NVMe SSD→オブジェクトストレージという階層に段階的に退避させる仕組み。GPU1台のメモリ容量を超える長い会話履歴や大量のドキュメントを扱えるようになる。
④ KV-Awareルーター
届いたリクエストの入力テキストと、各処理サーバーがすでに保持しているKVキャッシュの内容を照合し、「再計算が最も少なくなるサーバー」へ自動で振り分ける。同じドキュメントへの繰り返し問い合わせ（RAGやマルチターンチャット）で特に効果的で、BasetenのQwen3 Coder 480Bベンチマークでは最初のトークン返却を最大2倍高速化した 9。
⑤ SLAプランナー（SLA Planner、旧称: SLOプランナー）
「最初のトークンが返るまで300ms以内」「トークン間の間隔は40ms以内」といったSLO（サービス品質目標）をKubernetesのYAMLに宣言するだけで、プリフィル/デコードの比率と自動スケールを管理する。SLA達成とコスト最小化の均衡点を継続的に探索する 10。Alibaba APSARA 2025の事例では、SLAプランナー自動スケールによりSLA違反を最大80%削減し、TCOを5%低減した 9。
2024年1月に北京大学とUC San Diegoの共同研究グループ（第一著者: Yinmin Zhong, 北京大学／最終著者: Hao Zhang, UCSD）がarXivに公開した「DistServe」 6と、Microsoftの並行研究「Splitwise」 7がこの分離アーキテクチャの学術的な出発点だ。2025年にはPerplexity・Meta・Fireworks AIなどが独自実装を本番投入し、DynamoはそれをOSSとして標準化した形となる。
設定ファイルひとつで「分業」が始まる──実際のコードで確認する
プリフィル/デコード分離が、従来の構成と何が違うのかをコードで対比する。
# ---- 従来型: シングルノードvLLMデプロイ ----
# prefill（演算集中）とdecode（メモリ読み出し集中）が同一GPUで競合する
from vllm import LLM, SamplingParams
llm = LLM(model="Qwen/Qwen3-8B", tensor_parallel_size=4) # 4GPU同一ノード
outputs = llm.generate(
["非常に長いRAGコンテキスト ... (数千トークン)"],
SamplingParams(max_tokens=512)
)
# → 長プロンプトのprefillが混雑するとTTFTが劣化
# ---- Dynamo型: Zero-config deploy（概念的な記述例）----
# SLAだけ宣言すれば prefill/decode の配置と比率は Dynamo が自動決定する
apiVersion: nvidia.com/v1beta1
kind: DynamoGraphDeploymentRequest
metadata:
name: qwen3-disaggregated
spec:
model: Qwen/Qwen3-0.6B
backend: vllm
sla:
ttft: 200.0 # ⑤ SLAプランナーがこの目標を満たすよう自動調整(ms)
itl: 20.0 # トークン間の間隔の上限(ms)
autoApply: true
# 上記の宣言を受けて、Dynamoが内部で：
# - prefill/decodeを分離するか単一プールにするか判断
# - 各プールへのGPU割り当てを動的に決定
# - NIXL経由のKVキャッシュ転送と③KVBMの階層キャッシュを自動構成
# ローカルで試す（1コマンドでインストール）
uv pip install --prerelease=allow "ai-dynamo[sglang]"
python3 -m dynamo.frontend --http-port 8000 --discovery-backend file &
python3 -m dynamo.sglang --model-path Qwen/Qwen3-0.6B --discovery-backend file &
# OpenAI互換エンドポイントとして利用可能
curl localhost:8000/v1/chat/completions \
-d '{"model":"Qwen/Qwen3-0.6B","messages":[{"role":"user","content":"Hello"}]}'
slaブロックが「⑤ SLAプランナー」へのSLO宣言部分にあたり、prefill_pool/decode_poolの明示指定や disaggregation.enabled といったフィールドはなく、Dynamoがトラフィックを観測しながら自動で決める「Zero-config deploy」方式になっている。NIXL経由のKVキャッシュ転送もDynamo内部で自動処理される。実際の構成例は公式リポジトリ（ai-dynamo/dynamo）を参照。
月7億件をさばく企業が「なぜ分業に切り替えたか」──4社の事例
Perplexity AI（AI検索エンジン）
月間7億8,000万件のクエリを処理するPerplexityは、disaggregated servingを最も早く本番に持ち込んだ企業の一つだ 4。独自のKVメッセンジャー実装でEFA/ConnectX NIC経由のRDMAキャッシュ転送を行い、その設計経験をNVIDIAとのコラボレーションでDynamoに還元した。「検索クエリはプロンプトが長く、回答は短い」という偏ったワークロードが分離設計と相性が良く、プリフィル専用ノードを絞りながらデコードリソースを潤沢に確保することでコスト効率を最大化している。
Pinterest（画像SNS、NYSE: PINS）
PinterestのMLプラットフォームチームはNVIDIA Dynamo上に大規模推論スタックを構築し、「Pinterest AI Assistant」の基盤として2026年1月のNVIDIA Dynamo Dayで詳細を公開した 8。CTOのMatt Madrigalは「数億人規模のユーザーに直感的なマルチモーダルAI体験を届けるには、グローバル規模のリアルタイム推論が必要だ」とコメントしている。Dynamo一般のベンチマークでは、Qwen3-VL-30B-A3B-Instruct-FP8をマルチモーダル設定でNVIDIA GB200上で実行した際、画像エンコーディング・プリフィル・デコードを段階的に分離するE/P/D（Encode/Prefill/Decode）分離とembedding cacheによってTTFTを最大30%、スループットを最大25%改善している。
Baseten（AI推論APIプラットフォーム）
企業向けにフロンティアモデルのAPIエンドポイントを提供するBasetenは、NVIDIA Dynamo導入によってロングコンテキストのコード生成（Qwen3 Coder 480B、262Kトークンコンテキスト）で推論速度2倍・スループット1.6倍の向上を追加ハードウェアなしで達成した 5。DeepSeek-R1のサービングではレイテンシを最大38%削減した別のケーススタディもある。Qwen3 Coder 480Bのサービングでは、KVBMの階層オフロードが実用化のために不可欠だったとエンジニアリングブログで言及されている。
Cursor（AIコーディングアシスタント）
開発者100万人超が利用するCursorは、NVIDIA推論スタックを継続的に採用しているAIネイティブ企業の一つだ 3。コーディングアシスタントは「長いコードベースをコンテキストに取り込み（長いプリフィル処理）、コード補完を逐次生成（高頻度のデコード）」という典型的な偏ったワークロードで、分離設計との相性が良い。CEOのMichael Truellは2025年9月のNVIDIA Rubin CPX（大規模コンテキスト処理向けGPU）発表時に「Cursorはlightning-fast code generationを実現できる」とコメントしており、Dynamo以外のNVIDIAスタックとも一貫して連携している。
この仕組みで生まれる、3つのビジネスアイデア
アイデアA: 専門文書に特化した「ドキュメントQ&A SaaS」
参考にした事例: Perplexityが確立した「長プロンプト・短出力」ワークロードへの最適化
法律・医療・金融の専門家が扱う数百ページの契約書や財務報告書。これを従来のRAGシステムで処理すると、同じドキュメントへの問い合わせのたびに同じ前処理（プリフィル計算）を繰り返す。KV-Awareルーターを活用すれば、同一文書への2回目以降のクエリはキャッシュを再利用して最初のトークン返却をほぼゼロにできる。
クライアント企業はドキュメントをアップロードするだけで、キャッシュが「ウォームアップ」された状態が維持され、社員からの問い合わせが200ms以下で返ってくる体験を提供できる。同等の応答速度をDynamoなしで実現しようとすれば、GPU台数が3〜6倍必要になる。
収益モデルはドキュメントストレージ容量×クエリ数のクレジット課金（$1,000〜$30,000/月）。初期は法律事務所・会計法人への「契約書レビューAI」として導入し、「OpenAI API利用と比べて推論コストを70%以上削減できる」というROIを訴求できる。
アイデアB: 自社LLMを持つ企業への「推論最適化マネージドサービス」
参考にした事例: BasetenがDynamo導入で「2x推論速度・1.6xスループット、追加コストゼロ」をロングコンテキストのコード生成で達成したモデル
現在、企業が自社モデルをデプロイする場合、vLLM単体での構成が主流だ。しかし同一モデルを100社が個別に運用すると、各社がプリフィルとデコードを非効率に混在させた状態でGPUリソースを消費する。Dynamo的な調整レイヤーをマネージドサービスとして提供する「推論最適化PaaS」を作る。顧客企業はvLLMのDockerイメージをそのまま持ち込み、Dynamoの自動設定・監視・SLAチューニングを利用料として支払う。AWSマーケットプレイス上のEKS向けマネージドオペレーターとして配布すれば、顧客はコマンド1行でDynamo最適化済みの推論スタックを得られる。
収益モデルはプラットフォーム料（$2,000〜$15,000/月）＋GPUコスト転嫁。初期はvLLMユーザーが集まるSlackコミュニティやLangChainエコシステムへの無料トライアル展開が現実的で、「インフラ代の25〜40%削減」をROI保証として提示するとクロージングが早い。
アイデアC: 「AI推論コストの見える化」という新カテゴリ
参考にした事例: SLAプランナーの動的比率調整と、AI推論コストが爆発的に増大する市場構造
DatadogがITインフラの監視市場を定義したように、「AI推論コストの見える化と自動最適化」を専門とする新カテゴリのSaaSを作る。DynamoのメトリクスエクスポートをKubernetesクラスターとリアルタイムで統合し、「今プリフィルGPUを2台追加すれば月額$12,000削減できます」という具体的な提案を表示する。承認ワンクリックでGPU比率を自動変更するAuto-Remediation機能を加えれば、単なるダッシュボードを超えたアクション型ツールになる。
このカテゴリは現状ほぼ空白地帯だ。DatadogやGrafanaはインフラ全体の監視を提供するが、「推論フェーズ間の最適化提案」までは行わない。
収益モデルは成果報酬型（実証された推論コスト削減額の20%を月次請求）。初期顧客としては月間推論費用$100K超のAIスタートアップが最適で、ROI数字が明確なため法人契約が早く、獲得後の収益継続率（NRR）も安定しやすい。
自分のチームに向いているかを5分で判断する
Dynamoが効果を発揮するケース
- 8GPU以上のマルチノードクラスターを保有・計画している
- RAGや長いコンテキストで「同じドキュメントへの繰り返し問い合わせ」が多い
- プロンプトが長くて出力が短い、あるいは逆に短いプロンプトから長い出力を生成するような、処理の偏りが大きいワークロード
- 最初のトークンが返るまでの時間（TTFT p99）を1秒以下に抑えるSLAがある
Dynamoが向かないケース
- 1〜4 GPUのシングルノード環境: KVキャッシュのネットワーク転送コストがメリットを上回る
- プロンプトも出力もどちらも短い均質なリクエストが中心: 分離による恩恵が薄い
- プロトタイプ・開発フェーズ: vLLM単体で動かすほうが管理コストが低い
既存ツールとの比較
| 手法 | 強み | 弱み |
|---|---|---|
| vLLM単体 | 導入が簡単、ハードウェア互換性が高い | 単ノードで頭打ち、フェーズ分離不可 |
| SGLang | RadixAttentionでプレフィックス共有が強い | 複数ノード調整はDynamoで補完 |
| NVIDIA Dynamo | フェーズ分離の標準化、SLAプランナー | 8GPU未満では効果が薄い |
| MooncakeTransfer | Moonshot AI（Kimi）特化の高性能 | OSSとして公開済み（github.com/kvcache-ai/Mooncake) |
まず試すなら
uv pip install --prerelease=allow "ai-dynamo[sglang]"
公式チュートリアルのシングルノード構成で動作を確認し、自社の実トラフィックでTTFTとスループットを測定することから始めるのが現実的だ。
もっと深く学びたい人へ
- 公式GitHub: ai-dynamo/dynamo — コード・サンプル・Kubernetesデプロイ例
- NIXL公式GitHub: ai-dynamo/nixl — KVキャッシュ転送ライブラリ単体
- NVIDIA Dynamo 1.0 Production Ready Blog: nvidia-dynamo-1-production-ready — 1.0時点の機能・ベンチマーク詳説
- DistServe論文: arXiv:2401.09670 — disaggregated servingの学術的起点（北京大学・UCSD共同）
- Perplexity Research Blog: Disaggregated Prefill and Decode — 実装者の視点からの設計解説
- Baseten Engineering Blog: 2x faster with Dynamo — 具体的な性能数値と構成の詳細
LLMの「推論コスト問題」はモデルの大型化が続く限り構造的になくならない。NVIDIA Dynamoはその問題をアーキテクチャの「分業」で解く設計であり、Perplexity・Pinterest・Cursor・Baseteenといったトップ企業が本番採用したという事実は、この手法が実験段階を終えたことを示している。
同時に、このOSSが普及すれば「推論インフラを最適化できる企業」と「できない企業」の間にコスト格差が広がる可能性がある。あなたのシステムでは、最初のトークンが返るまでの処理と、その後の出力生成、どちらが遅くなっているだろうか。
事業面の深掘り・市場分析はnoteでも書いています。
https://note.com/qui123/membership
参考文献
- MarketsandMarkets – AI Inference Market Size, Share & Growth, 2025 To 2030
- Gartner – Predicts that by 2030, Inference on 1T-param LLM Will Cost 90%+ Less (March 2026)
- NVIDIA Newsroom – NVIDIA Enters Production With Dynamo 1.0 (March 16, 2026)
- Perplexity Research Blog – Disaggregated Prefill and Decode
- Baseten Engineering Blog – How Baseten achieved 2x faster inference with NVIDIA Dynamo
- arXiv:2401.09670 – DistServe: Disaggregating Prefill and Decoding for Goodput-optimized LLM Serving
- ResearchGate – Splitwise: Efficient Generative LLM Inference Using Phase Splitting
- NVIDIA On-Demand – Learnings From Dynamo Users Featuring Pinterest (January 2026)
- NVIDIA Dynamo GitHub – Benchmarks (KV-aware routing, Qwen3-Coder 480B, Baseten; SLAプランナー Alibaba APSARA 2025)
- NVIDIA Docs – SLA-based Planner