# Prefill/Decode分離で推論基盤を設計する

> 自社ホスティングLLM推論のPrefill/Decode分離アーキテクチャを解説。vLLM・SGLang・NVIDIA DynamoのKVキャッシュ転送方式とTTFT/ITL最適化のトレードオフを整理します。

- Canonical: https://kuucorp.com/blog/prefill-decode-disaggregation-llm-inference-design/
- Date: 2026-09-27
- Last modified: 2026-09-27
- Publisher: Kuu株式会社 (https://kuucorp.com)

---
自社ホスティングのLLM推論で、応答の出だし（TTFT: Time To First Token）が不安定になっていないでしょうか。長い入力を処理するPrefillリクエストが割り込むたびに、他の利用者への1トークンずつの生成（Decode）が止まる——単一エンジンで両方を捌く構成には、この構造的な問題があります。

## Prefill/DecodeはなぜGPU上で衝突するのか

> Prefillは計算律速、Decodeはメモリ帯域律速という性質の異なる処理が、単一エンジンのバッチ内で衝突します。

LLM推論はPrefill（入力プロンプト全体を並列処理し、最初の1トークンを生成する段階）とDecode（KVキャッシュを参照しながら1トークンずつ逐次生成する段階）に分かれます。vLLMやSGLangの公式ドキュメントが指摘する通り、Prefillは行列演算が密でGPU計算資源を使い切る計算律速の処理である一方、Decodeはメモリ帯域が制約になる処理です。両者を同一エンジンの同一バッチで混在実行すると、新規リクエストのPrefillが実行中のDecodeバッチに割り込み、ステップの周期が乱れて他リクエストの推論間トークン間隔（ITL: Inter-Token Latency）が不安定になります。SGLangのドキュメントはこれを「Prefill割り込み問題」と「データ並列時の不均衡問題」の2つとして整理しています。

## Prefill/Decode分離アーキテクチャとは何か

> PrefillとDecodeを別インスタンス群に物理的に分離し、KVキャッシュだけをネットワーク越しに転送する設計です。

Prefill/Decode分離（PD Disaggregation）は、PrefillワーカーとDecodeワーカーを別々のGPUインスタンスプールとして構成し、Prefillで計算したKVキャッシュを転送してDecode側で生成を続ける方式です。vLLMの実装ではConnector（KVキャッシュの授受）・LookupBuffer（キャッシュの登録と取得）・Pipe(単方向のテンソル転送)という3つの抽象で構成され、`--kv-transfer-config`にコネクタ種別を指定して有効化します。SGLangではPrefillワーカーがブートストラップサーバーを兼ね、Decode側とのハンドシェイク後にKVキャッシュを転送し、`sglang_router`がPrefill/Decode双方への振り分けとヘルスチェックを担います。分離により、Prefill側は高いテンソル並列度で計算スループットを、Decode側はレプリカ数を増やしてメモリ帯域と同時実行数を、それぞれ独立にチューニングできます。

## KVキャッシュ転送はどう実装されているか

> NIXL・Mooncake・UCXなど複数のバックエンドがRDMAベースの高速転送でPrefill/Decode間のKVキャッシュを渡します。

KVキャッシュの転送性能が分離アーキテクチャ全体のボトルネックになるため、各実装は専用の転送層を持ちます。vLLMはNixlConnector・LMCacheConnectorV1・MooncakeConnector・ROCm向けMoRIIOConnectorなど9種のコネクタを提供し、NVIDIA NIXL（NVIDIA Inference Xfer Library）やUCXを介してRDMAで転送します。SGLangも同様にMooncake（NVLink/EFA向け）・NIXL（UCX/LibFabric）・Ascend向けバックエンドを選択でき、`SGLANG_DISAGGREGATION_THREAD_POOL_SIZE`でTPランクあたりの転送スレッド数を制御します。NVIDIA Dynamoはこの転送層をNIXLとNVLinkで最適化した専用プラットフォームとして提供し、NVIDIA公式ブログはBlackwell上でSemiAnalysis InferenceXベンチマークにより最大7倍のリクエスト捌き量を報告しています。ただし、vLLMの公式ドキュメントは「Disaggregated Prefillはスループットを改善しない」と明記しており、狙う効果はTTFT・ITLの安定化であってスループット向上ではない点に注意が必要です。

## 導入判断と運用設計の勘所

> vLLMは2026年時点でも実験的機能と位置付けており、TTFT/ITLのSLOが厳しい対話用途から段階導入するのが妥当です。

vLLM公式ドキュメント（2026年7月更新版）はDisaggregated Prefillingを依然「experimental」と位置付けています。一方でMeta・LinkedIn・Mistral・HuggingFaceが本番導入済みという事例も報告されており、成熟度は用途によって判断が分かれる段階です。導入を検討する際は、まず対話型エージェントのようにTTFT・ITLのSLOが厳しいワークロードに限定し、[GPU推論キャパシティの調達戦略](/blog/gpu-inference-capacity-procurement-strategy/)と合わせてPrefill用・Decode用のGPUプールを別枠で確保することが前提になります。またKVキャッシュ転送はネットワーク帯域とRDMA対応ハードウェアに依存するため、[セルフホストLLM推論スタック](/blog/self-hosted-llm-inference-stack-vllm-sglang/)の選定段階でNIXL・Mooncakeいずれかのバックエンドがハードウェア構成と適合するかを確認する必要があります。[投機的デコーディング](/blog/speculative-decoding-llm-inference-production-design/)のようなDecode側の高速化技術とは独立に組み合わせ可能なため、両者を併用する設計も検討に値します。

## 参考

- [Disaggregated Prefilling (experimental) | vLLM Documentation](https://docs.vllm.ai/en/stable/features/disagg_prefill/)
- [PD Disaggregation | SGLang Documentation](https://docs.sglang.io/advanced_features/pd_disaggregation.html)
- [How NVIDIA Dynamo 1.0 Powers Multi-Node Inference at Production Scale | NVIDIA Technical Blog](https://developer.nvidia.com/blog/nvidia-dynamo-1-production-ready/)
- [KV Cache Transfer in Disaggregated Serving | NVIDIA Dynamo Documentation](https://docs.nvidia.com/dynamo/latest/backends/trtllm/kv-cache-transfer.html)

## まとめ

Prefill/Decode分離は、性質の異なる2つの処理をGPU単位で切り離し、KVキャッシュ転送だけで繋ぎ直すことでTTFT・ITLを安定させるアーキテクチャです。

設計時のポイントをまとめます。

1. スループット改善ではなくTTFT/ITL安定化が目的であることを前提に、対話型SLOが厳しいワークロードから適用する
2. vLLMは2026年時点でも実験的機能であるため、本番導入は自社の可観測性・ロールバック体制と合わせて段階的に進める
3. KVキャッシュ転送バックエンド（NIXL・Mooncake・UCX等）はハードウェアのRDMA対応状況に依存するため、選定前に自社インフラで検証する
4. Prefill用・Decode用GPUプールを独立してスケーリングし、GPU調達戦略と合わせて容量計画に組み込む

自社ホスティング推論基盤のアーキテクチャ設計については、Kuuの[RDEサービス](https://kuucorp.com/services/rde/)にご相談ください。