公開：2026年10月11日, 最終更新：2026年10月11日
プリフィル・デコード分離推論（Prefill-Decode Disaggregation）は、大規模言語モデル（LLM）の推論処理を構成する2つのフェーズを、異なるGPUリソース上に物理的に分離して実行するサービングアーキテクチャである。従来の単一GPU上での混在処理に起因するパフォーマンス上の干渉を排除し、レイテンシの個別最適化を実現する技術として注目されている。
概要
LLMの推論処理には、入力プロンプトを並列処理して最初のトークンを生成する「プリフィル（Prefill）」フェーズと、後続のトークンを1つずつ自己回帰的に生成する「デコード（Decode）」フェーズという、特性の異なる2段階が存在する。プリフィル・デコード分離推論とは、この2フェーズをそれぞれ専用 of GPUプールに割り当て、独立して実行させるアーキテクチャである。
北京大学・UCサンディエゴなどの研究者による論文「DistServe」（2024年1月arXiv公開、OSDI ’24発表）において初めて提唱・定式化された。LLM推論の遅延評価指標である「TTFT（Time to First Token）」と「TPOT（Time per Output Token）」を個別に最適化するための重要な技術として位置づけられている。
仕組み・ポイント
2つのフェーズは根本的に特性が異なる
プリフィルフェーズはプロンプト全体を並列処理するため計算集約型（Compute-bound）であり、高い演算性能（FLOPS）を要求する。一方、デコードフェーズはKVキャッシュを参照しながらトークンを逐次生成するためメモリ帯域幅がボトルネックとなりやすい（Memory-bound / I/O-bound）。
従来アーキテクチャの課題
vLLMやOrcaの初期実装のように同一GPU上で両フェーズを混在させてバッチ処理する場合、計算負荷の高いプリフィル処理がデコード処理をブロックし、トークン間レイテンシ（TPOT）を増大させる干渉が発生する。また、フェーズごとに異なる並列化戦略やリソース割り当てを適用することも困難だった。
分離による解決
- プリフィル専用GPUプールが入力プロンプトを処理し、初期KVキャッシュを生成する
- 生成されたKVキャッシュをデコード専用GPUプールへ転送する
- デコードサーバーがKVキャッシュを受け取り、トークン生成を継続する
この構成により、フェーズ間の干渉が排除され、それぞれに最適な並列化戦略・スケールを個別に設定できる。
実装上の要件と課題
KVキャッシュのサーバー間転送が必要となるため、RDMAなどの高速ネットワーク帯域が不可欠である。高速ネットワークが確保できない環境では、転送遅延により分離のメリットが相殺される可能性がある点に留意が必要である。
なぜ今注目されているのか
LLMの本番運用（プロダクション）が拡大するにつれ、推論コストとレイテンシの最適化が経営上の優先課題となっている。この流れを受け、主要なオープンソース推論フレームワークへの実装が急速に進んでいる。vLLMが実験的機能としてDisaggregated Prefillingをサポートし、SGLangやRayもドキュメントレベルで対応を明示している。さらにNVIDIA Dynamo、LMCache、Mooncake、Alibaba Cloudのサービスといった商用・クラウド環境への導入事例も広がっている。
派生技術の展開も活発で、マルチモーダルモデル向けにビジョンエンコーダステージも分離するEPD（Encode-Prefill-Decode）disaggregationの提唱や実装も進んでいる。2025年8月には分離と集約を動的に統合・制御するアーキテクチャ「TaiChi」も提案されており、技術の深化が続いている。
日本企業への示唆
LLMを社内システムやサービスに組み込む際、応答速度（TTFTとTPOT）は利用者体験と業務効率の両面に直結する。プリフィル・デコード分離推論は、特に長いプロンプトを処理しながらリアルタイム性も求められるユースケース——例えばRAGを用いた問い合わせ対応や文書解析——において有効な選択肢となりうる。一方、RDMAに対応した高速ネットワークインフラが前提となるため、オンプレミス環境での導入にはインフラ投資の見極めが必要である。vLLMやSGLangなどのOSSフレームワーク上で実験的に試せる段階に来ていることから、推論基盤の内製・最適化を検討する企業はPoC（概念実証）として評価する価値がある。
※ 本ページはAI News JAPAN編集部が最新の動向を踏まえて解説したものです。内容は随時見直します。
