Prefill-Decode分離 - yuuk1's Digital Garden

# Prefill-Decode分離 ## 定義 Prefill-Decode分離とは、LLM 推論の入力処理段階(Prefill)と逐次生成段階(Decode)を、同一 GPU 上の同居実行から切り離し、別 GPU・別インスタンス・別資源プールで実行するサービング設計である。Prefill は TTFT、Decode は TPOT/ITL を支配し、計算バウンドとメモリ帯域バウンドという資源特性が異なるため、分離により段階別に資源割当・並列化・スケジューリングを最適化できる。(Source: [[@2024__OSDI__DistServe - Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving]], [[@2025__INLG__Taming the Titans - A Survey of Efficient LLM Inference Serving]]) ## 横断的知見 - **PD 分離は Goodput 指標の導入で意味が明確になる**: DistServe は TTFT と TPOT の両 SLO を 90% 超のリクエストで満たす per-GPU レートを Goodput として最大化する。さくらのナレッジおよび SpeakerDeck の実測も、単なる TPS/RPS ではなく ITL/TTFT SLO を満たす有効スループットとして評価する必要を示す。(Source: [[@2024__OSDI__DistServe - Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving]], [[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]], [[@2026__SpeakerDeck__推論基盤のパフォーマンス検証と最適化戦略]]) - **PD 分離の中心課題は KV キャッシュ転送の扱いに収束する**: DistServe はノード内 NVLINK を使う配置制約で OPT-175B でも転送を総レイテンシ 0.1% 未満に抑えた。一方、さくらのナレッジは Llama-3.1-405B・8k 入力で約 4 GB/リクエストの KV キャッシュ転送が生じるとし、分散推論基盤では KV キャッシュを設計中心に据える必要を強調する。両者は矛盾ではなく、モデル規模・入力長・ネットワーク配置により転送が無視可能にも律速にもなることを示す。(Source: [[@2024__OSDI__DistServe - Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving]], [[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]]) - **サーベイ上の PD 分離は、単発システムからサービング設計カテゴリへ昇格した**: INLG 2025 サーベイは DistServe、Splitwise、Mooncake、P/D-Serve、TetriInfer、FlowKV などを同じ分離パラダイムとして整理しており、PD 分離は LLM 推論サービングの一実装ではなく、インスタンス内最適化の主要カテゴリになっている。(Source: [[@2025__INLG__Taming the Titans - A Survey of Efficient LLM Inference Serving]], [[@2024__OSDI__DistServe - Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving]]) - **本番規模では PD 分離は pool 分割だけでなく、scenario 単位の組織化と gateway 制御を要求する**: DistServe は段階別 GPU 割当と配置探索で Goodput を最大化するが、P/D-Serve は数万 NPU 規模で、prompt prefix の多様性、P/D ratio mismatch、不正確な Prefill queue 推定により、固定 pool だけでは TTFT SLO を守れないことを示す。P/D-Serve の細粒度 P/D group と on-demand forwarding は、PD 分離をクラスタ scheduler だけでなく MLOps と gateway の問題として扱う。(Source: [[@2024__OSDI__DistServe - Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving]], [[@2024__arXiv__P-D-Serve - Serving Disaggregated Large Language Model at Scale]]) - **PD 分離の KV 転送層は、GPU 内ページ管理と別の転送粒度を必要とする**: LMCache は cross-engine/GPU KV cache transfer を PD 分離の基本機能として扱い、vLLM/SGLang の小さな page をそのまま送るのでなく chunk 化と計算 I/O 重畳を使う。P/D-Serve も PageAttention の離散ブロックを連続バッファとして送って RecvScatter で戻す。PD 分離では「KV キャッシュを送る」だけでは不十分で、GPU 内メモリ管理とネットワーク転送の粒度変換が性能を左右する。(Source: [[@2025__arXiv__LMCache - An Efficient KV Cache Layer for Enterprise-Scale LLM Inference]], [[@2024__arXiv__P-D-Serve - Serving Disaggregated Large Language Model at Scale]], [[@2023__SOSP__Efficient Memory Management for Large Language Model Serving with PagedAttention]]) - **PD 分離は転送データ面と制御面の分離も要求する**: LMCache + NIXL の資料では、PD 分離を「Prefiller と Decoder の間で 1 クエリ内の KV キャッシュを転送する」形として説明する。NIXL の UCX 例では、制御面として agent/backend 初期化、GPU HBM 登録、Remote metadata と受信バッファリスト交換があり、データ面として NIXL Xfer request の非同期投稿・完了確認・再投稿がある。PD 分離を安定に運用するには、単に KV データを高速転送するだけでなく、相手側メモリ領域の識別子とバックエンド接続情報をどう配布・失効・最小公開するかが設計対象になる。(Source: [[@2025__PyTorchConference__Scaling KV Caches for LLMs - How LMCache + NIXL Handle Network and Storage Heterogeneity]], [[@2025__arXiv__LMCache - An Efficient KV Cache Layer for Enterprise-Scale LLM Inference]]) - **CPU/DRAM を KVCache 主記憶にする 3 プール分離は、長コンテキストで過負荷 MaaS に固有の問題を解く**: Mooncake は Prefill Pool・KVCache Pool・Decoding Pool の 3 プールを分離し、CPU DRAM を KVCache の主記憶とする。この設計により(1)Prefill の VRAM 占有が Layer-wise 非同期転送で最小化、(2)CPP が長コンテキストを複数ノードで並列 Prefill、(3)過負荷時の Early Rejection が Prefill/Decode を独立した負荷評価対象として扱える。DistServe・P/D-Serve の 2 プール(P+D)に対して KVCache を独立プールに分けることで、長コンテキストと本番過負荷という 2 つの問題を同時に扱う。(Source: [[@2024__arXiv__Mooncake - A KVCache-centric Disaggregated Architecture for LLM Serving]]) - **PD 分離固有の負荷変動(振動)問題は、予測なしでは解消できない**: Mooncake は Early Rejection を単純実装すると Prefill/Decode 間で逆位相振動が生じることを 20 分の実測で示す(図 9)。原因は「Decode 負荷の現在値に基づくスケジューリング」の本質的な時間遅れであり、3〜4 ステップの Accept/Reject サイクルで収束しない。このダイナミクスは非分離システムには存在しない分離固有の課題。システムレベルの将来負荷予測(均一デコード時間 t_d を仮定した batch count 推定)で振動を緩和できる。(Source: [[@2024__arXiv__Mooncake - A KVCache-centric Disaggregated Architecture for LLM Serving]]) - **クラウドネイティブ PD 分離は Kubernetes のオートスケーリングと推論エンジンの協調設計を要求する**: [[AIBrix]] は PD 分離を Kubernetes CRD レベルで扱い、LLM 固有メトリクス（KV キャッシュ利用率等）に基づく second-level オートスケーリングで Prefill/Decode の資源割当を動的に調整する。DistServe（段階別 GPU 割当探索）や Mooncake（3 プール静的比率）が研究志向の分離設計であるのに対し、AIBrix は既存の Kubernetes エコシステム上で異種 GPU を混在させたコスト最適化分離を実現する。低トラフィック条件で 4.7 倍のコスト削減を報告し、PD 分離の運用経済性を示す。(Source: [[@2025__arXiv__AIBrix - Towards Scalable, Cost-Effective Large Language Model Inference Infrastructure]]) ## 未解決の問い - PD 分離の最適粒度は、GPU 単位、パイプライン段階単位、ストリーミングマルチプロセッサ単位のどこに置くべきか。Semi-PD のような同一 GPU 内分離は KV 転送を避ける一方、資源独立性をどこまで保てるか。 - 長コンテキスト・RAG・マルチターンエージェントの共有プレフィックスでは、KV キャッシュ転送、再利用、圧縮、永続化のどの組み合わせが TTFT と ITL の双方を最小化するか。 - PD 分離された Decode インスタンスが障害になった場合、複数 Prefill インスタンスへ障害が波及する。分離型推論サービングの耐障害性は、複製型同居システムとどう比較すべきか。 - P/D-Serve の scenario 単位 P/D group と、LMCache/Dynamo 型のグローバル KV cache store はどこで組み合わせるべきか。prefix locality を優先すると負荷分散が崩れ、負荷分散を優先すると cache hit が落ちる可能性がある。 - block-free / chunked KV 転送は平均転送時間を下げるが、tail latency と障害時再送の粒度にはどのような影響があるか。 - NIXL 型の非同期 Xfer request 再投稿モデルでは、Prefiller/Decoder の動的スケールイン、失効した remote metadata、部分転送失敗をどの粒度で扱うべきか。 - Mooncake の Prefill/Decode 比率は静的設定。長コンテキスト比率やトラフィックパターンの変化に動的適応する手法はどう設計すべきか。Prefill/Decode 間の弾力的変換を実現した場合に Conductor の設計はどう変わるか。 - 予測ベース Early Rejection でシステムレベル均一 t_d 仮定を使っているが、出力長分布が重い尾を持つ場合(Kimi の出力は max >2,000 tokens)にどう補正すべきか。 ## 関連 - ソース: [[@2024__OSDI__DistServe - Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving]] / [[@2025__INLG__Taming the Titans - A Survey of Efficient LLM Inference Serving]] / [[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]] / [[@2026__SpeakerDeck__推論基盤のパフォーマンス検証と最適化戦略]] / [[@2024__arXiv__P-D-Serve - Serving Disaggregated Large Language Model at Scale]] / [[@2025__arXiv__LMCache - An Efficient KV Cache Layer for Enterprise-Scale LLM Inference]] / [[@2025__PyTorchConference__Scaling KV Caches for LLMs - How LMCache + NIXL Handle Network and Storage Heterogeneity]] / [[@2024__arXiv__Mooncake - A KVCache-centric Disaggregated Architecture for LLM Serving]] - エンティティ: [[DistServe]] / [[vLLM]] / [[Mooncake]] / [[LMCache]] / [[P-D-Serve]] / [[AIBrix]] - 関連 MOC: [[LLM4SRE - MOC]] ## 出典 - [[@2024__OSDI__DistServe - Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving]] - [[@2025__INLG__Taming the Titans - A Survey of Efficient LLM Inference Serving]] - [[@2025__さくらのナレッジ__分散推論基盤やその前提の考え方]] - [[@2026__SpeakerDeck__推論基盤のパフォーマンス検証と最適化戦略]] - [[@2024__arXiv__P-D-Serve - Serving Disaggregated Large Language Model at Scale]] - [[@2025__arXiv__LMCache - An Efficient KV Cache Layer for Enterprise-Scale LLM Inference]] - [[@2024__arXiv__Mooncake - A KVCache-centric Disaggregated Architecture for LLM Serving]] - [[@2025__arXiv__AIBrix - Towards Scalable, Cost-Effective Large Language Model Inference Infrastructure]] - [[@2025__PyTorchConference__Scaling KV Caches for LLMs - How LMCache + NIXL Handle Network and Storage Heterogeneity]]