自社ホスティングの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推論キャパシティの調達戦略と合わせてPrefill用・Decode用のGPUプールを別枠で確保することが前提になります。またKVキャッシュ転送はネットワーク帯域とRDMA対応ハードウェアに依存するため、セルフホストLLM推論スタックの選定段階でNIXL・Mooncakeいずれかのバックエンドがハードウェア構成と適合するかを確認する必要があります。投機的デコーディングのようなDecode側の高速化技術とは独立に組み合わせ可能なため、両者を併用する設計も検討に値します。
参考
- Disaggregated Prefilling (experimental) | vLLM Documentation
- PD Disaggregation | SGLang Documentation
- How NVIDIA Dynamo 1.0 Powers Multi-Node Inference at Production Scale | NVIDIA Technical Blog
- KV Cache Transfer in Disaggregated Serving | NVIDIA Dynamo Documentation
まとめ
Prefill/Decode分離は、性質の異なる2つの処理をGPU単位で切り離し、KVキャッシュ転送だけで繋ぎ直すことでTTFT・ITLを安定させるアーキテクチャです。
設計時のポイントをまとめます。
- スループット改善ではなくTTFT/ITL安定化が目的であることを前提に、対話型SLOが厳しいワークロードから適用する
- vLLMは2026年時点でも実験的機能であるため、本番導入は自社の可観測性・ロールバック体制と合わせて段階的に進める
- KVキャッシュ転送バックエンド（NIXL・Mooncake・UCX等）はハードウェアのRDMA対応状況に依存するため、選定前に自社インフラで検証する
- Prefill用・Decode用GPUプールを独立してスケーリングし、GPU調達戦略と合わせて容量計画に組み込む
自社ホスティング推論基盤のアーキテクチャ設計については、KuuのRDEサービスにご相談ください。