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 分離の動機を計算特性の違いに単純化するが、ハードウェア調整という実務的帰結は学術論文と一致する**: LLM高速化の勉強会資料は PD 分離の動機を「Prefill と Decode の計算特性の違いにより混在させるとパフォーマンスが下がりうる」と簡潔に説明し、具体例として Prefill には Tensor Core の強い H200、Decode には A100 程度で十分という段階別ハードウェア選定を挙げる。これは DistServe が示す「段階別 GPU 割当・並列化探索による Goodput 最大化」という定式化の、実務者向けにかみ砕いた帰結であり、学術的定式化と教育的説明が同じ結論(段階ごとに異なる資源を割り当てる)に収束することを示す。(Source: [[@2024__OSDI__DistServe - Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving]], [[@2026__SpeakerDeck__LLM高速化(勉強会)]]) - **PD 分離は KV キャッシュ転送方式だけでなく、通信ライブラリのディスパッチモードを段階別に切り替える設計へ発展した**: DistServe・Mooncake・LMCache が KV キャッシュの転送・配置を PD 分離の中心課題として扱うのに対し、[[SGLang]] の 96 H100 GPU 展開([[@2025__LMSYS Blog__Deploying DeepSeek with PD Disaggregation and Large-Scale Expert Parallelism on 96 H100 GPUs]])は、PD 分離を [[DeepEP]] の通信モード選択そのものに拡張する——Prefill サーバーは長入力最適化の Normal Dispatch(CUDA Graph 非対応)、Decode サーバーは低遅延最適化の Low-Latency Dispatch(CUDA Graph 対応)を独立に選び、統一エンジンでは両立できない通信最適化を同時に実現する。RDMA ベースの非ブロッキング転送で KV キャッシュをハンドオフする点は DistServe/Mooncake と共通するが、PD 分離が MoE の Expert Parallelism 通信ライブラリの選択という、KV キャッシュ以外のシステムコンポーネントにも及ぶことを示す新しい事例である。(Source: [[@2025__LMSYS Blog__Deploying DeepSeek with PD Disaggregation and Large-Scale Expert Parallelism on 96 H100 GPUs]], [[@2024__OSDI__DistServe - Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving]]) - **PD 分離間の KV 転送は、性能最適化研究だけでなく標準化されたトレース計測の対象にもなっている**: [[MLCommons Chakra]] は vLLM v1 の prefill/decode disaggregation 構成で、prefill GPU から decode GPU への per-layer KV 転送(Llama3-8B、32 層)を実測し、Send(prefill 側)が約 143〜187µs、Recv(decode 側)が約 108〜145µs で、Send が Recv より一貫して高いレイテンシを示すことをトレースとして可視化した。DistServe・Mooncake・LMCache が「KV 転送をどう設計・最適化するか」を扱うのに対し、Chakra は「既存の PD 分離実装の KV 転送挙動をベンダー非依存の標準形式でどう計測・比較するか」という補完的な観点を提供する。(Source: [[@2026__MLSys2026__MLCommons Chakra - Advancing Performance Benchmarking and Co-design using Standardized Execution Traces]]) - **同居(co-location)を維持したまま QoS 差別化で効率化する路線が、分離路線と並立する**: [[@2025__arXiv__Niyama - Breaking the Silos of LLM Inference Serving]] は Prefill/Decode を同一レプリカに同居させたまま([[Sarathi-Serve]] の chunked-prefill を拡張)、複数 QoS クラスを共有インフラで co-schedule することで、interactive/batch のサイロ非効率を SOTA サイロ構成比 GPU 13〜32% 削減で解消した。DistServe・Mooncake・P/D-Serve が「Prefill と Decode を物理的に分離してそれぞれ最適化する」路線であるのに対し、Niyama は「分離せず、デッドラインスラックを動的に再配分する」路線であり、両者は KV キャッシュ転送コストを払うか(分離)、チャンクサイズ制御の複雑性を払うか(同居)というトレードオフの両極として並立する。(Source: [[@2025__arXiv__Niyama - Breaking the Silos of LLM Inference Serving]], [[@2024__OSDI__DistServe - Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving]]) - **PD 分離の有効性は普遍的ではなく、モデルアーキテクチャ・規模・トラフィックパターンの3軸で条件付けられることが、数十万規模のシミュレーションで定量化された**: [[@2026__MLSys2026__Beyond the Buzz - A Pragmatic Exploration of Prefill-Decode Disaggregation in Large Scale Inference]](NVIDIA)は、disaggregation が最も有効なのは prefill-heavy トラフィック(ISL >> OSL)と大規模モデル(>10B パラメータ)であり、decode-heavy トラフィックや小規模モデルでは co-located serving(特に context chunking による piggybacking)が競争力を持つことを示した。これは DistServe・Mooncake・P/D-Serve が個別事例で示してきた「分離が有利」という主張に、モデル規模とトラフィック方向という2軸の定量的な適用条件を与えるものである。 - **co-location における context chunking の有効性は attention 機構(MLA vs. GQA)に依存し、PD 分離の要否判断はモデルアーキテクチャ単位で行うべきことが示された**: 同論文は、DeepSeek-R1 の Multi-Latent Attention(MLA)を持つ MoE モデルが、piggybacked co-location において prefill chunking のたびに down/up projection を再計算する追加オーバーヘッドを負うことを指摘した。これは Group Query Attention(GQA)ベースの Llama-3.1 系列には生じない、MLA 固有の不利益である。PD 分離を「するかどうか」の判断が、トラフィックパターンだけでなく attention 機構の選択にも依存することを示す新しい軸である。 - **PD 分離間のレートマッチングは、整数計画的な GPU 比率決定アルゴリズムとして定式化できる**: 同論文の Algorithm 1・2 は、FTL SLA を満たす prefill 構成の中でスループット/GPU を最大化したのち、decode 構成とのスループット比を整数比に丸めて Ctx:Gen GPU 数を決定する2段階手続きを与える。DistServe が Goodput 最大化として扱ってきたレートマッチング問題に、具体的な整数ソルバ的アルゴリズムという実装可能な形を与えた点で、既存の定性的な「段階別 GPU 割当探索」の記述を補完する。(Source: [[@2026__MLSys2026__Beyond the Buzz - A Pragmatic Exploration of Prefill-Decode Disaggregation in Large Scale Inference]]) - **本番規模の実測は「PD 分離が常に優位」ではなく、オンライン/オフラインで有効性が反転することを定量化した**: [[@2026__MLSys2026__Optimizing Deployment Configurations for LLM Inference]](Meta)は、厳格な SLO を持つオンライン推論では分離が継続的バッチング比 70B で1.5〜1.8倍・405B で1.8〜2.2倍の QPS を達成する一方、レイテンシ非制約のオフライン生成では両者の差がほぼ消失し、深いパイプライン並列 + 大バッチという同一構成に収束することを、数百万規模の構成探索シミュレーションで示した。これは DistServe・Mooncake・P/D-Serve が個別のオンラインシナリオで「分離が有利」と主張してきたのに対し、ワークロードのレイテンシ制約の有無という軸で有効性の境界を定量化した点で「Beyond the Buzz」(NVIDIA、prefill-heavy トラフィックとモデル規模で条件付ける)と補完的な——しかし異なる軸(SLO の有無 vs トラフィック方向)による——条件付け結果である。(Source: [[@2026__MLSys2026__Optimizing Deployment Configurations for LLM Inference]], [[@2026__MLSys2026__Beyond the Buzz - A Pragmatic Exploration of Prefill-Decode Disaggregation in Large Scale Inference]]) - **PD 分離の優位性は KV キャッシュ転送設計だけでなく、Prefill/Decode 独立の並列化選択にも由来する**: Meta の実測では、分離の QPS 優位は(1) Prefill/Decode の並列化(P)を独立に最適化できること(継続的バッチングでは単一の並列化設定を両フェーズで共有せざるを得ない)、(2) TTIT を犠牲にしない大きな Decode バッチサイズ(70B/GPU-A で112対28)、の2要因に分解できる。DistServe・Mooncake が KV キャッシュ転送・プール設計を中心課題として扱うのに対し、Meta の知見は「フェーズ別並列化の独立性」という、転送コストとは別の分離の便益を定量化する。(Source: [[@2026__MLSys2026__Optimizing Deployment Configurations for LLM Inference]]) - **本番運用では PD 分離の採否がインフラ移行の意思決定として実行され、約30%の容量削減として定量化された**: Meta はオンラインサービスの大半を分離ランタイムへ移行し、約30%の容量削減(GPU 削減率相当)を得たと報告する。これは AIBrix が低トラフィック条件で報告する4.7倍のコスト削減とは異なる文脈(AIBrix はオートスケーリングとの組み合わせ、Meta は静的な分離移行そのもの)での定量値であり、PD 分離の経済的便益が測定条件によって大きく異なることを示す一例である。(Source: [[@2026__MLSys2026__Optimizing Deployment Configurations for LLM Inference]], [[@2025__arXiv__AIBrix - Towards Scalable, Cost-Effective Large Language Model Inference Infrastructure]]) - **PD分離のKV Cache転送は、モデル規模と入力長に応じて数百MBから数百GBまでスケールし、転送先ネットワークの選択(Scale Up/Scale Out)がボトルネックを決める**: [[@2025__SpeakerDeck__AIインフラを考える]] は、7B MHAモデル・4Kトークンで約2.0GB、Llama3 405B・8Kトークン・同時100リクエストで420GBという段階的試算を示し、Scale Up(NVLink/PCIe、最大900GB/s)とScale Out(NIC/DPU、最大100GB/s)のどちらでKV Cacheを転送するかで性能特性が変わることを指摘した。DistServeがノード内NVLINKで転送レイテンシを総処理時間の0.1%未満に抑えた事例([[KVキャッシュ管理]])と、さくらのナレッジのLlama-3.1-405B・8k入力で約4GB/リクエストという実測値の両方と整合し、PD分離のKV Cache転送設計が「どのネットワーク経路を使うか」というインフラ構成の選択問題であることを、具体的な帯域数値とともに再確認する。(Source: [[@2025__SpeakerDeck__AIインフラを考える]], [[@2024__OSDI__DistServe - Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving]]) - **NIXLのパス選択(NVLink/NVSwitch vs GPUDirect RDMA)は既存のLMCache+NIXL資料が示す制御面/データ面分離の設計を、ノード内/ノード間という配置原則に結びつけて説明する**: 『AI Systems Performance Engineering』第15章は、ノード内配置ではCUDA peer access経由のNVLink/NVSwitch、ノード間配置ではGPUDirect RDMA over InfiniBand/RoCEv2を使うべきという配置指針を示し、フォールバック時のホスト経由パスが非最適である点を強調する。これは[[@2025__PyTorchConference__Scaling KV Caches for LLMs - How LMCache + NIXL Handle Network and Storage Heterogeneity]]が示すNIXLの制御面(agent/backend初期化・remote metadata交換)とデータ面(非同期Xfer request)の分離設計に、「どのトポロジでどのパスを選ぶか」という配置レベルの具体的な意思決定基準を追加する。さらに1GPUあたり1NICの配置がPD分離とMoE all-to-all性能の両方に推奨されるという実務的知見は、既存のKVキャッシュ転送コスト分析(さくらのナレッジ・DistServe)にネットワークインタフェース設計という新しい軸を加える。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 15 Multinode Inference, Parallelism, Decoding, and Routing Optimizations]], [[@2025__PyTorchConference__Scaling KV Caches for LLMs - How LMCache + NIXL Handle Network and Storage Heterogeneity]]) - **Kubernetesベースのllm-dは、DistServe・P/D-Serveが示す段階別資源割当の原則を、負荷特性(長プロンプト対長出力)に応じた動的プール再配分としてクラスタオーケストレーション層に実装する**: 第15章は、超長プロンプト・短出力(要約用途)ではPrefillプールへGPUを追加し、長い出力(推論チェーン)ではDecodeプールへGPUを追加するという、llm-dのvariant autoscalerによる動的シフトを紹介する。これはP/D-Serveが数万NPU規模で示した「固定poolだけではTTFT SLOを守れない」という知見と同じ問題意識だが、P/D-Serveがscenario単位のP/Dグループとon-demand forwardingで対処するのに対し、llm-dはKubernetes標準のオートスケーリング機構に統合する点で異なるレイヤーの解を提示する。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 15 Multinode Inference, Parallelism, Decoding, and Routing Optimizations]], [[@2024__arXiv__P-D-Serve - Serving Disaggregated Large Language Model at Scale]]) - **異種ハードウェア割当によるPD分離のコスト最適化は、Splitwiseの実証実験からHexGen-2の自動最適化問題へ発展した**: Splitwise研究([[@2025__OReilly__AI Systems Performance Engineering - Chapter 18 Advanced Prefill-Decode and KV Cache Tuning]]で紹介)は、4×H100(高計算)をprefillに、4×A100(高メモリ帯域)をdecodeに割り当てる具体的構成で、同一コスト・電力下で8GPU均一構成比最大2.35倍のスループットを達成した。これはAIBrixが低トラフィック条件で報告する4.7倍のコスト削減やMetaの約30%容量削減とは異なる軸(GPU世代の使い分けそのもの)での定量値であり、PD分離のコスト最適化が「分離するかどうか」だけでなく「各フェーズにどのGPU世代を割り当てるか」という設計変数を持つことを示す。HexGen-2はこの割当と段階別並列化戦略・通信効率を同時に解く最適化問題として定式化し、SOTA比最大2倍のスループット・約30%のコスト削減を達成した——これはSplitwiseが個別実験で示した効果を、探索アルゴリズムとして自動化した事例である。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 18 Advanced Prefill-Decode and KV Cache Tuning]], [[@2025__arXiv__AIBrix - Towards Scalable, Cost-Effective Large Language Model Inference Infrastructure]], [[@2026__MLSys2026__Optimizing Deployment Configurations for LLM Inference]]) - **フェーズ別モデル並列化(TP/PP)の独立選択は、KVキャッシュのTP形式変換という新たな転送コストを生む**: 第18章は、prefillでPP(パイプライン並列)、decodeでTP(テンソル並列)のように異なる並列化度を選ぶと、KVキャッシュのシャーディング形式が両フェーズで異なり、NVIDIA Dynamoのようなシステムがtransfer時に`[TP_p parts]`から`[TP_d parts]`へのトランスポーズ(変換)カーネルを実行する必要があることを具体的に示す。これはMetaの実測が示す「フェーズ別並列化の独立性がPD分離のQPS優位の一因」という知見に、その独立性が生むKV転送側の追加コスト(トランスポーズ)という裏面を補う。トランスポーズのオーバーヘッドはNVLinkスループットに比べれば小さいと第18章は述べるが、定量評価はNVIDIA Dynamoの実装依存であり独立検証がない。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 18 Advanced Prefill-Decode and KV Cache Tuning]], [[@2026__MLSys2026__Optimizing Deployment Configurations for LLM Inference]]) - **Mooncakeの早期拒否(Early Rejection)は、GPU-CPU協調のハイブリッドPrefillという第3の資源プールと組み合わせられる設計として第18章で再文脈化される**: 第17章で導入された早期拒否の概念を、第18章はGPU prefillワーカー・CPU prefillワーカー・decode GPUによるローカルprefillの3択スケジューリングという枠組みに拡張する。プロンプト長が閾値(例: 5,000トークン)を超えるとCPUワーカーへルーティングする方針は、Mooncakeの3プール分離(Prefill Pool・KVCache Pool・Decoding Pool)にさらに「低優先度・オフライン処理用のCPUプール」を追加する設計として読める。CPU offloadはTTFTを悪化させるため通常のレイテンシ重視リクエストには使わない安全弁的機能と位置づけられており、Mooncakeが扱う需要側シェディング(拒否)と供給側拡張(CPU活用)は補完関係にある。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 18 Advanced Prefill-Decode and KV Cache Tuning]], [[@2024__arXiv__Mooncake - A KVCache-centric Disaggregated Architecture for LLM Serving]]) - **TetriInferの2段階スケジューラとArrowの適応的インスタンススケーリングは、PD分離が生む「フェーズ間不均衡」という分離固有の新規課題への異なる解法として整理できる**: DistServe・P/D-Serveは静的または準静的な段階別GPU割当を扱うのに対し、TetriInferはリクエストレベルの通常ルーティングとクラスタ全体のホットスポット予測を組み合わせた2段階スケジューリングでボトルネック形成を未然に防ぎ、Arrowは入力/出力トークンレートとバックログを継続的に測定してprefill/decodeワーカー数を動的に再配分する(最大5.6倍のリクエスト処理率、極端なワークロード変動下)。両者はMooncakeが指摘する「Decode負荷の現在値に基づくスケジューリングの本質的な時間遅れ」という振動問題に対する具体的な対処法であり、TetriInferは予測による予防、Arrowは継続的モニタリングによる追随という異なるアプローチを取る。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 18 Advanced Prefill-Decode and KV Cache Tuning]], [[@2024__arXiv__Mooncake - A KVCache-centric Disaggregated Architecture for LLM Serving]]) - **PD分離のKV Cache転送非対称性は、KVキャッシュ転送そのものの効率化(帯域選択・トランスポーズコスト)を超えて、ネットワークトポロジ設計との構造的ミスマッチを引き起こす**: これまでの横断的知見はScale Up/Scale Out経路選択・NIXLパス選択・TP形式変換など「KV Cache転送をどう速く行うか」というトランスポート/実装レイヤーの最適化に集中していた。[[ZCube]] concept が扱う本番クラスタ実測は、この問題をネットワークアーキテクチャ層まで遡って捉え直す。PD分離で生じるKV Cache転送は送信元・宛先・トラフィック量が動的に変化するため、[[Fat-Tree|ROFT(Rail-Optimized Fat-Tree)]] のような静的レール割り当てを前提とするトポロジでは、特定Leafスイッチ・リンクへのトラフィック集中(トポロジ誘発輻輳)が恒常的に発生することが、Grafana実測(NIC間スループットの偏り、PFC Pause Packetsの周期的バースト)で定量的に示された。KV Cache転送の「効率化」を論じる際は、転送プロトコル・配置戦略だけでなく、その転送パターンとネットワークトポロジの整合性も設計変数として扱う必要があることを示唆する。(Source: [[@2026__X__Next-generation LLM Inference Network - How ZCube Alleviates Network Bottlenecks]]) - **PD分離のどちらが優位かという評価結論そのものが、ベンチマークに使うワークロード生成の精度に依存することが定量的に示された**: [[@2026__NSDI__ServeGen - Workload Characterization and Generation of Large Language Model Serving in Production]](NSDI '26)は、Qwen2.5-72B を PD分離 SGLang(2P6D/3P5D/4P4D)でベンチマークする際、到着トレースとデータセットを独立に単純合成する「NAIVE」ワークロードと、クライアント単位の因果モデリングに基づく [[ServeGen]] ワークロードとで、3つのSLO設定中2つ(Base SLO・Tight TBT SLO)において最良のPD構成に関する結論が食い違うことを示した。これまでの横断的知見(KV Cache転送設計・並列化選択・GPU割当アルゴリズム)は「PD分離をどう設計するか」を扱ってきたが、この知見は「PD分離の設計をどう評価するか」——ベンチマークに使うワークロード自体の忠実性——という、評価方法論そのものに潜むバイアスを指摘する点で新しい軸である。ServeGen 論文はこの食い違いを、より長いテールを持つ実際のリクエストパターンが Decoding インスタンスへの需要を過小評価させることに起因すると分析しており、本番運用では PD分離が「予測不能」に性能低下する現象として現れうると論じている。(Source: [[@2026__NSDI__ServeGen - Workload Characterization and Generation of Large Language Model Serving in Production]]) - **PD分離が対応すべき負荷変動の多くは、ワークロード全体としてではなく少数の上位クライアントに起因する因果構造として説明できる**: ServeGen が提案する「クライアント分解」([[LLMサービングワークロード特性化]])は、入出力長分布の時間シフトや到着バースト性のシフトが、上位少数クライアントのレート変動によって引き起こされることを示す。これは、これまでの横断的知見が「PD分離はどうプロビジョニングすべきか」を到着レート全体の統計量(Mooncake の Early Rejection、Meta のオンライン/オフライン境界)として扱ってきたのに対し、負荷変動の発生源をクライアント単位まで遡って捉え直す視点を提供する。DistServe・Mooncake・P/D-Serveが集約統計に基づく容量計画を扱う一方、クライアント分解はその集約統計自体がなぜ・どう変動するかを説明する、より上流の因果モデルとして位置づけられる。(Source: [[@2026__NSDI__ServeGen - Workload Characterization and Generation of Large Language Model Serving in Production]]) - **「PD分離が有利か」の判断そのものを実測ヒートマップから導出し、実行時にPD分離/PD同居を切り替える設計は、DistServe・P/D-Serveが暗黙に前提としてきた「PD分離は常に導入する」という選択を相対化する**: [[@2025__ATC__DeepServe - Serverless Large Language Model Serving at Scale]](Huawei Cloud、USENIX ATC '25)は、prefill長・decode長・RPSを軸にPD分離とPD同居(chunked prefill併用)のJCT差を実測したヒートマップ(80%超のセルがRPSを変えても符号が一貫)を構成し、軽量LLM分類モデル(84.9%精度)で予測したdecode長とヒートマップの符号から、リクエストごとにPD分離TEとPD同居TEのどちらへ送るかを実行時に決定するselect-tes-PD-heatmapポリシーを提案した。DistServe(段階別GPU割当の静的最適化)・P/D-Serve(細粒度P/D group)・Niyama(同居維持のQoS co-scheduling)がいずれも「PD分離するか同居するか」を構成時に固定するのに対し、DeepServeは同一クラスタ内でリクエスト単位にPD分離/PD同居を動的に使い分ける点で、静的配置と動的配置の中間に位置する第三の設計を提示する。(Source: [[@2025__ATC__DeepServe - Serverless Large Language Model Serving at Scale]]) - **PD分離TEの正しい選択がもたらす利得は、誤った選択による損失より非対称に大きいという実測結果は、ヒートマップベースのスケジューリングを頑健にする根拠になる**: DeepServeのヒートマップ実測は、PD分離が有利な場合の性能差(濃い赤、最大+0.87)がPD同居が有利な場合の性能差(薄い青、最大-0.40程度)より系統的に大きいことを示した。これは「Beyond the Buzz」(NVIDIA)が示す「disaggregationはprefill-heavy・大規模モデルで最も有効」という条件付けと同じ問題意識——PD分離の有効性は普遍的ではなく条件付きである——を、単一クラスタの本番トレースに基づく非対称な利得・損失分布として再確認するものであり、予測モデルの誤りに対してヒートマップベースのポリシーが頑健である理由を定量的に補強する。(Source: [[@2025__ATC__DeepServe - Serverless Large Language Model Serving at Scale]]) - [KVキャッシュ転送の下層基盤] dmaplane はユーザ空間の転送ライブラリが前提とする「バッファが確保・配置・共有・登録済みで completion/ティアダウン下でも安全」という条件をカーネルレベルの明示的なオーケストレーション層として提供する。2 台の EC2 g5.xlarge 間で Soft-RoCE 上の RDMA WRITE WITH IMMEDIATE により KV キャッシュチャンクを転送するデモでは、TTFT 98.2 ms のうち KV キャッシュ転送が 52.1 ms（約 53%）を占め最大の内訳だった([[@2026__arXiv__The DMA Streaming Framework - Kernel-Level Buffer Orchestration for High-Performance AI Data Paths]])。 - [completion 安全性] クレジットベースのフロー制御（送信側 completion 容量と受信側 receive WR 容量の双方で in-flight 操作を境界づける）は、意図的にクレジットを枯渇させたストレス構成でも 5 秒間に 7270 万回のクレジットストールを生みながら CQ overflow をゼロに保った。KV キャッシュのような point-to-point 転送で completion キューのオーバーフローが送信側の会計を破損しうるという、Mooncake・TransferEngine 等のユーザ空間トランスポートが前提としている「登録・配置済み」の裏にあるカーネル側の安全性条件を具体的に示す([[@2026__arXiv__The DMA Streaming Framework - Kernel-Level Buffer Orchestration for High-Performance AI Data Paths]])。 - [起源] Splitwise(ISCA 2024, Patel+)はPrefill-Decode分離の最初期の代表実装のひとつ。プロンプト計算(計算バウンド)とトークン生成(メモリ帯域/容量バウンド)の資源特性差を実運用Azureトレースで特性評価し(Insight I〜VII)、分離設計の根拠を定量的に示した(Source: [[@2024__ISCA__Splitwise - Efficient Generative LLM Inference Using Phase Splitting]]) - [KVキャッシュ転送オーバーヘッド] Splitwiseはレイヤー単位パイプライン転送(各層の計算完了ごとに非同期でKVキャッシュをMSCCL++経由でput)により、分割のE2Eレイテンシへの影響を0.8%(逐次転送では3%)に抑えた。プロンプトサイズが小さい場合は逐次転送、大きい場合はレイヤー単位転送を使い分ける(Source: [[@2024__ISCA__Splitwise - Efficient Generative LLM Inference Using Phase Splitting]]) - [異種ハードウェア] Splitwiseはトークン生成が計算能力の低いGPU(A100)でもPerf/W・Perf/$で有利であることを実測し、Splitwise-HA(H100プロンプト/A100トークン)がSplitwise-HH(同種H100)よりコスト・電力効率で優位な場面があることを示した。ただし異種GPU間のInfiniBand接続が一般的でない点は運用課題として残る(Source: [[@2024__ISCA__Splitwise - Efficient Generative LLM Inference Using Phase Splitting]]) - [混在プール(mixed pool)によるワークロード頑健性] Splitwiseは常時のプロンプト/トークンプールに加え、負荷変動時にのみ拡張する混在プールを設けることで、想定と異なるワークロード(トレース変更・モデル変更)でもスループット・レイテンシ低下がほぼ生じないことを実測した。同種ハードウェア構成(Splitwise-AA/HH)ほどこの頑健性が高く、異種構成(Splitwise-HA/HHcap)では最大7%のスループット低下が生じた(Source: [[@2024__ISCA__Splitwise - Efficient Generative LLM Inference Using Phase Splitting]]) - [プリフィル律速要因] プリフィルフェーズの支配要因は文脈長とバッチサイズによって計算律速と通信律速の間を移動する。短コンテキスト(1K〜8K)では大バッチ時に通信(テンソル並列all-reduce等)が計算を上回る一方、中〜長コンテキスト(128K〜1M)ではデバイス数拡張に伴う集合通信が支配的になる(Source: [[@2026__HOTI__Scaling Inference Prefill with High-Radix Photonic Interconnects]] Section V)。 - [プリフィル/デコードの結合] disaggregated servingのdiscrete-event simulationでは、[[フォトニックインターコネクト]]によるプリフィル側のTTFT改善(p99で12〜20%)が、デコードワーカーの飽和により相殺されうる。プリフィルが速くなるほどデコードキューが密になりデコードバッチサイズが上限に近づくため、p99 TPOTが77〜110%悪化し、出力長(OSL)次第でend-to-endレイテンシの改善は限定的(OSL 1024では−1〜−5%)になる(Source: [[@2026__HOTI__Scaling Inference Prefill with High-Radix Photonic Interconnects]] Section V-E)。 - [定義] DeepSeek-V4.1-Flash は Encoder–Prefill–Decode(EPD)disaggregation を採用し、ビジョンエンコーディング・prefill・decode の 3 段階を独立にスケール・オーバーラップさせる配備を行う。これは Prefill-Decode の 2 分割をさらにエンコーダ段まで拡張した構成である(Source: [[@2026__TechReport__DeepSeek-V4.1-Flash - Pushing the Limits of KV Cache Compression]])。 - Causal Encoder-Decoder(CED)アーキテクチャは、モデル内部の層構成レベルで decoder の global KV を encoder 最終層の隠れ状態から直接射影することで、prefill 時に前半層のみを計算すればよくし、prefill 計算量を O(NL) から O(NL/2) へほぼ半減させる。これはサービング配備でのプレフィル・デコード分離とは別に、モデルアーキテクチャ自体が prefill コストを削減する設計であり、対比材料として記録する(Source: [[@2026__TechReport__DeepSeek-V4.1-Flash - Pushing the Limits of KV Cache Compression]])。 ## 未解決の問い - PD分離のKV Cache転送非対称性がトポロジ誘発輻輳を引き起こす閾値(トラフィック非対称性がどの程度になるとROFTのレール割り当てが破綻するか)は定量化されていない。[[ZCube]] concept も参照。 - TetriInferの2段階スケジューラ(予測的ホットスポット防止)とArrowの適応的インスタンススケーリング(継続的モニタリングによる資源再配分)は、Mooncakeが指摘するPrefill/Decode間の逆位相振動問題を、システムレベル将来負荷予測とは異なるアプローチでどこまで緩和できるか。3手法(Mooncakeの予測ベースEarly Rejection、TetriInferの2段階スケジューリング、Arrowの継続的適応)を同一ワークロードで比較した実証研究はない。 - NVIDIA DynamoのKVキャッシュTP形式変換(トランスポーズ)カーネルのオーバーヘッドは、モデル規模・TP_p/TP_d比・NVLink世代によってどう変化するか。第18章は「NVLinkスループットに比べれば小さい」と述べるが、定量的なベンチマークは示されていない。 - CPU prefillワーカーを含む3択スケジューリング(GPU prefill/CPU prefill/decode-local prefill)は、Mooncakeの3プール分離やAIBrixのKubernetes CRDベースオートスケーリングとどう統合すべきか。CPU利用率が高まった場合にGPU容量計画をどう見直すべきかの指針は示されていない。 - llm-dのvariant autoscalerによる動的PD再配分は、Mooncakeが指摘するPrefill/Decode間の逆位相振動問題(§横断的知見)に対してどのような予測・平滑化機構を持つか、書籍本文には詳細がない。AIBrixのKubernetes CRDベースのオートスケーリングとllm-dのアプローチは同じ問題をどう異なる粒度で解いているか。Mooncakeが指摘するPrefill/Decode間の逆位相振動問題(§横断的知見)に対してどのような予測・平滑化機構を持つか、書籍本文には詳細がない。AIBrixのKubernetes CRDベースのオートスケーリングとllm-dのアプローチは同じ問題をどう異なる粒度で解いているか。 - Niyama の同居 QoS co-scheduling と DistServe 型の物理分離は、同一ワークロード・同一 GPU 予算で直接比較されていない。KV キャッシュ転送コストが小さい環境(高速 NVLink 等)では分離が優位、転送コストが大きい環境では同居が優位、という条件分岐は成立するか。 - 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)にどう補正すべきか。 - 「Beyond the Buzz」は disaggregation が prefill-heavy・大規模モデルで最も有効と定量化したが、この結論は NVIDIA 独自の proprietary シミュレータに基づく。実機ベンチマーク(DistServe・Mooncake 等)との定量的な突き合わせは行われていない。シミュレーション結果と実測結果はどの程度一致するか。 - MLA(DeepSeek-R1)における piggybacked co-location の prefill chunking オーバーヘッドは、一時的な up-projected KV キャッシュで緩和可能と述べられているが、この緩和策はまだ定量評価されていない。緩和後も MLA は GQA と同等の chunking 効率に到達し得るか。 - ServeGen が示した「ワークロード生成精度が PD 構成評価の結論を左右する」という知見は、他の PD 分離研究(DistServe・Mooncake・P/D-Serve・Splitwise 等)が用いたベンチマークワークロードにどこまで当てはまるか。これらの先行研究のワークロード生成手法(多くは NAIVE 型)を ServeGen で再評価した場合、報告された優位性は再現されるか。 - DeepServe の select-tes-PD-heatmap ポリシーは単一クラスタ・単一モデル(34B, TP=4)のヒートマップに基づく。モデル規模・並列化構成が変わるたびにヒートマップを再実測する必要があるのか、それとも「Beyond the Buzz」が示すモデル規模・トラフィック方向という2軸だけでヒートマップの形状を予測できるのか(ヒートマップの転移可能性)は未検証。 - dmaplane のようなカーネルレベルのバッファオーケストレーション層は、ハードウェア RDMA NIC（ConnectX・EFA 等)上でも Soft-RoCE と同等の completion 安全性・NUMA 配置効果を示すか(未測定) - Splitwiseの混在プール機構(閾値超過時に反対プールのマシンを動員)は、DistServe・Mooncake等の後続分離システムのgoodput最適化やKVキャッシュ中心アーキテクチャとどう関係づけられるか。混在プールに相当する仕組みは後続研究にも引き継がれているか未整理 - CED のようなモデル内部での encoder/decoder 層分割によるプレフィル削減と、EPD/PD disaggregation のようなサービング層でのステージ分離は、両者を組み合わせた場合にどこまで相加的にコストを削減できるか(本論文はモデル単体の効果のみ報告し、サービング側の定量評価は示していない)。 ## 関連 - ソース: [[@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]] / [[@2025__LMSYS Blog__Deploying DeepSeek with PD Disaggregation and Large-Scale Expert Parallelism on 96 H100 GPUs]] / [[@2026__MLSys2026__MLCommons Chakra - Advancing Performance Benchmarking and Co-design using Standardized Execution Traces]] / [[@2025__arXiv__Niyama - Breaking the Silos of LLM Inference Serving]] / [[@2026__MLSys2026__Beyond the Buzz - A Pragmatic Exploration of Prefill-Decode Disaggregation in Large Scale Inference]] / [[@2026__MLSys2026__Optimizing Deployment Configurations for LLM Inference]] / [[@2025__ATC__DeepServe - Serverless Large Language Model Serving at Scale]] / [[@2026__arXiv__The DMA Streaming Framework - Kernel-Level Buffer Orchestration for High-Performance AI Data Paths]] / [[@2024__ISCA__Splitwise - Efficient Generative LLM Inference Using Phase Splitting]] - エンティティ: [[DistServe]] / [[vLLM]] / [[Mooncake]] / [[LMCache]] / [[P-D-Serve]] / [[AIBrix]] / [[SGLang]] / [[DeepEP]] / [[MLCommons Chakra]] / [[Sarathi-Serve]] / [[NVIDIA Dynamo]] / [[NIXL]] / [[Meta]] / [[Huawei Cloud]] / [[dmaplane]] - 概念: [[LLM推論設計空間探索]] / [[並列化戦略]] / [[ZCube]] / [[Fat-Tree]] / [[LLMサービングワークロード特性化]] - 関連 MOC: [[LLM4SRE - MOC]] - コンセプト: [[フォトニックインターコネクト]] ## 出典 - [[@2026__X__Next-generation LLM Inference Network - How ZCube Alleviates Network Bottlenecks]](PD分離のKV Cache転送非対称性がネットワークトポロジ誘発輻輳を引き起こす実測、ZCubeによる解決) - [[@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]] - [[@2025__LMSYS Blog__Deploying DeepSeek with PD Disaggregation and Large-Scale Expert Parallelism on 96 H100 GPUs]](SGLang の DeepEP Normal/Low-Latency Dispatch モード切替による PD 分離の拡張) - [[@2026__MLSys2026__MLCommons Chakra - Advancing Performance Benchmarking and Co-design using Standardized Execution Traces]](vLLM PD 分離構成での per-layer KV 転送レイテンシのトレースベース実測、MLSys 2026 Oral) - [[@2025__arXiv__Niyama - Breaking the Silos of LLM Inference Serving]](同居維持のまま QoS 差別化で co-scheduling する対照的アプローチ、動的チャンキング、SOTA サイロ比 GPU 13〜32% 削減) - [[@2026__MLSys2026__Beyond the Buzz - A Pragmatic Exploration of Prefill-Decode Disaggregation in Large Scale Inference]](NVIDIA、数十万設計点のシミュレーションで PD 分離の有効性をモデルアーキテクチャ・サイズ・トラフィックパターンの3軸で定量化、レートマッチングの整数計画的アルゴリズム、MLSys 2026 Oral) - [[@2026__MLSys2026__Optimizing Deployment Configurations for LLM Inference]](Meta、月間10億ユーザー規模の本番運用実測。オンライン推論で分離が継続的バッチング比1.5〜2.2倍のQPS、オフラインでは差が消失。オンラインサービスの大半を分離へ移行し約30%容量削減、MLSys 2026 Industry Track) - [[@2025__SpeakerDeck__AIインフラを考える]](KV Cache転送のモデル規模・入力長別スケーリング試算とScale Up/Scale Out経路選択によるボトルネックの違い) - [[@2025__OReilly__AI Systems Performance Engineering - Chapter 15 Multinode Inference, Parallelism, Decoding, and Routing Optimizations]](disaggregated PDアーキテクチャの実務教科書的整理。NIXLのノード内/ノード間パス選択指針、1GPUあたり1NIC推奨、Kubernetesベースのllm-dによる動的プール再配分) - [[@2026__NSDI__ServeGen - Workload Characterization and Generation of Large Language Model Serving in Production]](Alibaba Group / Peking University、NSDI '26。本番4か月・35.4億リクエストのワークロード特性化とクライアント分解、PD分離のケーススタディでワークロード生成精度がベンチマーク結論を左右することを実証) - [[@2025__ATC__DeepServe - Serverless Large Language Model Serving at Scale]](Huawei Cloud / Peking University、USENIX ATC '25。PD分離とPD同居の性能差を実測ヒートマップ化し、decode長予測モデルと組み合わせてリクエスト単位で動的に切り替えるselect-tes-PD-heatmapポリシー、1年以上の本番Ascend NPUクラスタ運用実績) - [[@2026__arXiv__The DMA Streaming Framework - Kernel-Level Buffer Orchestration for High-Performance AI Data Paths]](カーネルレベルのバッファオーケストレーション層が KV キャッシュ転送の completion 安全性を支える基盤として提供されることを示す) - [[@2024__ISCA__Splitwise - Efficient Generative LLM Inference Using Phase Splitting]](Prefill-Decode分離の初期の代表実装。特性評価(Insight I-VII)とレイヤー単位KVキャッシュパイプライン転送、混在プールによる頑健性を実測)