Skip to content
←

필사 모드: PD分離はスループットを増やさない — プリフィル/デコード分離が実際に買うもの

日本語
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

はじめに — 一つのGPUに同居する、性格の違う二つの仕事

LLM推論が二つの段階に分かれることは、もはや常識です。プロンプト全体を一度のフォワードパスで通してKVキャッシュを作るプリフィル(prefill)と、トークンを一つずつ取り出すデコード(decode)。KVキャッシュの話をするたびに出てくる、あの二段階です。

重要なのは、この二つの性格がまったく逆だという点です。SGLangドキュメントの表現をそのまま借りれば、プリフィルは入力シーケンス全体を処理する計算集約的(computation-intensive)な作業であり、デコードはKVキャッシュを管理するメモリ集約的(memory-intensive)な作業です。プリフィルはGPUの演算ユニットを焼き、デコードは一トークンごとにモデルの重みとKVキャッシュ全体を読み直すため、メモリ帯域に縛られます。

性格の異なる二つの作業を同じGPUに載せ、同じスケジューラで回すと何が起きるでしょうか。そして分ければ本当に良くなるのでしょうか。本稿は、その「分離」— PD分離(prefill/decode disaggregation)— が2026年にどこまで来ているのか、そしてインターネットに出回る倍率の数字をそのまま鵜呑みにしてはいけない理由についての話です。

一つのGPUに置くと何が問題か — 干渉

SGLangドキュメントは、統合エンジンで生じる問題を二つに絞って指摘しています。

第一に、プリフィル割り込み(Prefill Interruption)。ドキュメントの文をそのまま訳せば、「到着したプリフィルバッチが進行中のデコードバッチをたびたび中断させ、トークン生成に大きな遅延を引き起こす」となります。図を描けば明らかです。あるユーザーがトークンを一つずつ受け取りながらストリーミング中に、隣で8000トークンのプロンプトが一つ到着します。そのプリフィルはGPUをしばらく丸ごと占有し、ストリーミング中だったユーザーの次のトークンはその分だけ遅れて出てきます。ユーザーから見れば、文字が流れていたのに突然止まる瞬間です。

第二に、DPアテンション不均衡(DP Attention Imbalance)。データ並列アテンションで、一方のDPワーカーがプリフィルバッチを、もう一方がデコードバッチを同時に処理すると、デコードの遅延が増えます。

TensorRT-LLMの技術ブログも同じ診断を下しています — 統合サービングでは「コンテキスト処理がトークン生成を遅らせる干渉」が生じ、そのぶんインタラクティブ性が損なわれるというものです。そしてこのブログは問題の本質を一文にまとめています。「TTFTのような一つの指標を最適化すると、TPOTのような別の指標を犠牲にすることが多い。」

これが核心です。一つのGPU上で、プリフィルとデコードは同じリソースを奪い合う二つの相反する目標です。バッチを大きくすればスループットは上がりますがテール遅延が崩れ、プリフィルを細かく分割すれば(チャンク化プリフィル)干渉は減りますがプリフィル効率が落ちます。一つのスケジューラで二つの目標を同時に満たそうとすること自体が、構造的な妥協なのです。

だから分離する — PD分離の構造

発想は単純です。性格が違うのだから、ハードウェアも別々に与えよう。

vLLMドキュメントの定義では、分離プリフィルはプリフィルとデコードの段階を別々のvLLMインスタンスで動かし、その間でKVキャッシュをコネクタで受け渡すことです。実際の配置はおおよそこう見えます。

                     [ プロキシ / ルーター ]
                        |          |
             リクエスト ->|          |
                        v          v
              [ プリフィルインスタンス ]  [ デコードインスタンス ]
               GPU 0-3                  GPU 4-7
               プロンプト -> KV          KV -> トークンストリーム
                        |          ^
                        |  KVキャッシュ |
                        +--- RDMA --+
                          (コネクタ)

三つのパーツが必要です。

  1. プリフィルインスタンス — プロンプトを受け取りKVキャッシュを作る。
  2. デコードインスタンス — そのKVキャッシュを受け取りトークンを取り出す。
  3. コネクタとプロキシ — KVキャッシュを運び、リクエストをどちらに送るか調整する。

これで各段階に別々の並列化戦略をかけられるようになります。プリフィルにはTPを低く、デコードには高く — あるいはその逆。vLLMドキュメントがこの機能の利点として一番に挙げるのがまさにこれです。「TTFTとITLを別々にチューニングする」こと。そして二番目が「テールITLを制御する」ことです。プリフィルジョブがデコードを妨げられなくなるので、デコードGPU上でトークンは一定のリズムで出てきます。

vLLMではこの機能はまだexperimentalと表示されています。ドキュメントの文をそのまま訳せば「この機能は実験的であり、変更される可能性があります」。

数字の読み方 — スループットではなくgoodput

ここが本稿の核心です。

PD分離を検索すると、「2倍」「7倍」といった数字があふれてきます。ところが、まさにそのvLLM公式ドキュメントには、こんな一文が大文字で刻まれています。

"Disaggregated prefill DOES NOT improve throughput."(分離プリフィルはスループットを改善しません。)

矛盾しているように見えます。しかし、両方とも正しいのです。理由がわかれば、PD分離を見る目が完全に変わります。

考えてみれば当然です。PD分離はGPUを増やしてはくれません。 8枚のGPUを4枚はプリフィル、4枚はデコードに分けたからといって、総演算量が増えるはずがありません。むしろKVキャッシュをネットワーク越しに運ぶ作業が新たに生まれるので、純粋な総作業量で言えば増えます。TensorRT-LLMブログもこれを認めています — 「分離はKVキャッシュブロックを転送するオーバーヘッドを伴う」。

では、その倍率は何を測ったものでしょうか。答えはgoodputです。

この概念の出典は、PD分離の元祖論文であるDistServe(Zhongら、OSDI 2024)です。タイトルからして"Goodput-optimized"です。goodputはおおよそこう定義されます — TTFTとTPOTの制約を両方満たしながら処理できる最大リクエストレート。ただのスループットが「毎秒何個吐き出したか」だとすれば、goodputは「毎秒何個を約束した品質で吐き出したか」です。

この違いの大きさは、vLLMに入ったMORI-IOコネクタのブログ記事がはっきり示しています。そのブログのgoodputの定義はこうです。

"Goodput = maximum request rate (req/s) such that requests satisfy both TTFT < T_ttft and ITL < T_itl."

つまりSLOを守れなかったリクエストは数えません。スループットの計算では3秒かかったTTFTも1件ですが、goodputの計算では0件です。ユーザーはすでにタブを閉じているでしょうから。

まとめるとこうなります。

  • スループット(純粋なtokens/s、遅延を無視): PD分離は改善しません。むしろ転送オーバーヘッドでわずかに損をします。— vLLMドキュメントが言っているのはこれです。
  • goodput(SLOを守った処理量): PD分離が大きく改善します。— ベンダーブログが測っているのはこれです。

同じシステムを、違う物差しで測っている。インターネットの倍率を見るとき、どちらの物差しで測ったのかをまず確認すべき理由がここにあります。

その倍率を実際に分解してみると

このレンズで公開されている数字を読み直してみましょう。以下はすべてベンダー/著者の自己測定であり、それぞれの測定条件を併記します。条件こそが数字の意味です。

DistServe(Zhongら、OSDI 2024、著者自己測定)。 論文の見出しは「7.4倍多いリクエスト」あるいは「12.6倍厳しいSLO」です。しかし、そのすぐ後に条件が付きます — 「リクエストの90パーセント超について遅延制約内に収まりながら」。これはスループットの倍率ではなく、SLO達成率を固定した状態でのリクエストレートの倍率です。そして倍率はモデル・アプリケーション・遅延要件によって変わると論文自身が述べています。

TensorRT-LLM(NVIDIA自己測定、GB200)。 ここの数字は特に教訓的です。DeepSeek R1で入力4400/出力1200の条件では、MTPなしで1.4〜1.8倍、MTPを有効にすると1.6〜2.5倍。入力8192/出力256では4-GPU最大1.73倍、8-GPUで2倍。そして決定的な項目 — 入力4096/出力1024で「ユーザーあたり毎秒50トークンの地点で1.7倍改善」。最後の一文をもう一度読んでください。ユーザーあたり毎秒50トークンという遅延目標を固定した状態でのスループット倍率です。遅延制約を外せば、この倍率はそのままではいられません。Qwen 3では入力8192/出力1024の条件で1.7〜6.11倍という幅広い範囲が報告されており、これほど範囲が広いこと自体が「条件がすべて」という証拠です。

そしてNVIDIAは正直な脚注を一つ添えています。理論的な「rate-matched」分析と実際のエンドツーエンドベンチマークの間に0〜25パーセントの差があり、その原因は「理想化された仮定」と「KVキャッシュ転送オーバーヘッド」だというのです。理論上の倍率をそのまま信じるなという話を、ベンダー自身がしているわけです。

llm-d on AWS(AWS自己測定、2026年3月16日)。 GPT-OSSモデル、ml.p6-b200.48xlargeインスタンス、プリフィルポッド4個(TP1)とデコードポッド1個(TP4)、入出力それぞれ1024トークン、同時実行数最大128。結果は「同時実行数が上がるほど、標準vLLM配備に対して毎秒トークン数が最大70パーセントまで増加」。ここでも「同時実行数が上がるほど」という条件が付いています — 負荷が低ければ利得がないということです。そしてAWSの著者たちはこう付け加えています。「ただし、すべてのワークロード向けではありません。より大きなモデル、より長い入力シーケンス、疎なMoEアーキテクチャで試してください。」

パターンが見えたでしょうか。すべての数字に遅延目標または負荷条件が固定されています。これは偶然ではありません。それがPD分離の売り物だからです。

KVを運ぶ配管 — 本当のエンジニアリングはここにある

PD分離のアイデアは一段落で説明できます。難しいのは配管です。プリフィルGPUが作ったKVキャッシュをデコードGPUへ運ばなければならず、これは小さくありません。そしてこの転送がそのままTTFTに乗ります。

だから2026年の実際の競争は転送レイヤーで起きています。

NIXL(NVIDIA Inference Xfer Library)が現在もっとも広く使われている軸です。リポジトリの説明そのままでは、「NVIDIA DynamoのようなAI推論フレームワークの点対点通信を高速化するためのものであり、モジュール式のプラグインアーキテクチャを通じて多様なメモリ(CPU・GPU)とストレージ(ファイル・ブロック・オブジェクトストア)への抽象化を提供」します。Apache 2.0で、バックエンドプラグインとしてUCX、POSIX、OBJ、AZURE_BLOB、HF3FS、MOONCAKE、GUSLI、UCCL、GDS、GPUNETIO、LIBFABRICなどが接続されます。要するに、KVキャッシュをInfiniBandでも、NVMeでも、S3でも運べるようにした抽象化レイヤーです。

MooncakeはSGLangのデフォルト転送エンジンで、SGLangはMooncake・NIXL・ASCENDの三つのバックエンドをサポートします。Mooncake経路では--disaggregation-ib-deviceでInfiniBandデバイスを指定する必要があります。

vLLM側のコネクタ一覧は現在こうなっています — NixlConnector、LMCacheConnectorV1、MooncakeConnector、MoRIIOConnector(ROCm専用)、MultiConnector、OffloadingConnector、FlexKVConnectorV1、そして例示用のExampleConnector。内部の抽象化は三つのパーツです — コネクタ(生産者・消費者間のKV検索)、LookupBuffer(insertはノンブロッキング、drop_selectはブロッキング)、Pipe(単方向FIFO)。

ここで、配管が要件へと跳ね返ってくる点を見逃してはいけません。RDMAファブリックが事実上の前提です。AWSがllm-dを動かす際にEFAとlibfabricプラグインを一緒に語る理由がこれであり、SGLangがInfiniBandデバイスの指定を要求する理由も同じです。ふつうのイーサネットの上にこの設計を載せると、節約したはずのITLを転送遅延として吐き出し直すことになります。

2026年4月、MORI-IO — 具体的な測定を一つ

抽象的な話を、具体的な測定一つに落としてみましょう。2026年4月7日、vLLMブログにMORI-IOコネクタの記事が公開されました。AMDとEmbedded LLMチームが書いた記事で、測定は2026年3月12日に行われました。AMD自己測定であることを先に断っておきます。

MORI-IOは、MORI(Modular RDMA Interface)フレームワークの上に載せたRDMAベースのKVキャッシュコネクタで、vLLMにコントリビュートされました。AMD GPU(ROCm)陣営でNIXLに相当する位置を埋めるものだと考えればよいでしょう。

測定条件は以下の通りです。

  • ハードウェア: AMD Instinct MI300X 8枚(各192GB)、AMD EPYC 9654 96コア 2ソケット
  • ソフトウェア: Ubuntu 22.04 LTS、ROCm 7.0.51831、vLLM 0.16.0rc1.dev1
  • モデル: Qwen/Qwen3-235B-A22B-FP8
  • ワークロード: 入力2000トークン、出力1000トークン、合計100リクエスト、リクエストレート0.5〜10 req/s
  • SLO: TTFT 1秒未満、ITL トークンあたり50ms未満
  • 構成: プリフィルGPU 0-3、デコードGPU 4-7、そしてプロキシサーバー

リクエストレート8 req/s地点で報告された結果です。

構成SLO達成リクエスト相対goodput
標準 (1× TP8)26/1000.9倍
標準 (2× TP4)30/1001倍(基準)
MORI-IO Read (1P+1D)70/1002.4倍
MORI-IO Write (1P+1D)73/1002.5倍

この表で一番重要なのは倍率ではなくなぜ失敗したかです。ブログの文をそのまま訳します。

「両方の分離モードとも、ITL違反を完全に排除する。残る失敗は、リクエストレートが上がるにつれて発生するTTFT超過だ。」

これがPD分離の正体を一文で要約しています。ITL違反がゼロになりました。 デコードGPU上にプリフィルが割り込めなくなるのだから当然です。ところが失敗が消えたのではなく、TTFT側に移っただけなのです。ボトルネックをなくしたのではなく移動させただけであり、その取引がたまたま割の良い商売だっただけです。

ReadモードとWriteモードの違いも同じ話の延長です。

  • Readモード: デコードがプリフィルからKVをRDMAで引っ張ってくる。ブログの説明では「TTFTは、少なくとも1回の完全なプリフィルフォワードパス(プロキシシリアライゼーション)にRDMA転送時間を加えた分だけ増加する」。
  • Writeモード: プリフィルが演算中にKVをデコードへ押し込む。「TTFTはRDMA転送時間の分だけ増加するが、この転送がプリフィル演算と重なるため、正味のペナルティはより小さい。」

だからWriteが73、Readが70なのです。ブログの説明どおり「同時プロキシディスパッチがTTFTを下げる」からです。3ポイント差の正体は、結局TTFTペナルティの大きさだということです。

そして脚注が一つ、静かに付いています。「MORI-IOコネクタが要求するとおり、プレフィックスキャッシングを無効化」。 両方の分離構成でそうです。これは小さな脚注ではありません — 次の節で扱います。

タダではない — 正直なコスト

さて、請求書です。

TTFTが悪化する。 前に見た通りです。KVキャッシュがネットワークを渡る時間がTTFTに乗り、Readモードではプロキシシリアライゼーションまで加わります。MORI-IO測定でSLOを守れなかった27〜30件のリクエストが、すべてTTFT超過だった事実を覚えておいてください。PD分離はITL問題をTTFT問題に変える取引です。あなたのボトルネックがTTFTなら、この取引は損です。

プレフィックスキャッシングと衝突しうる。 MORI-IO測定では、プレフィックスキャッシングはコネクタの要件としてオフにされていました。これがなぜ痛いかというと — プレフィックスキャッシングは、長いシステムプロンプトやマルチターンの会話でプリフィルコストをまるごと消してくれる、大半の実務ワークロードにおける最大の単一最適化だからです。長い共通プレフィックスを共有するチャットボットトラフィックなら、プレフィックスキャッシングを切って得た2.5倍のgoodputが、プレフィックスキャッシングを有効にした統合サービングより優れているかはまったく自明ではありません。これは必ず自分のトラフィックで直接測るべき項目です。(コネクタとバージョンによって状況が異なるため、使おうとしている組み合わせの現在の制約を確認してください。)

RDMAファブリックが必要。 InfiniBandかRoCE、AWSならEFA。これはハードウェア調達とネットワーク設計の問題であり、フラグ一つ立てれば済む話ではありません。

GPUが複数枚必要。 最低でもプリフィル1+デコード1で、実戦の構成はそれより大きくなります — MORI-IO測定は8枚を4:4に割り、AWSの事例はプリフィルポッド4個とデコードポッド1個でした。GPU二、三枚で回しているサービスで議論するテーマではありません。

運用の複雑さが増す。 インスタンス一つが、インスタンス二種類+プロキシ/ルーター+転送レイヤーになります。プリフィルとデコードの比率をワークロードに合わせてチューニングする必要があり(AWSの記事が指摘するその項目です)、障害モードもそれだけ増えます。プロファイリングすら面倒になります — SGLangドキュメントは、プリフィルワーカーとデコードワーカーを別々にプロファイルする必要があると書いています。

モデルアーキテクチャに左右される。 SGLangのステージングバッファ最適化は非MLAモデル(GQA・MHA)向けであり、ドキュメントは「MLAモデル(DeepSeek-V2/V3など)ではこのフラグを有効にしてはならない」と明記しています。TensorRT-LLMは、このアプローチが「長い入力シーケンスと中程度の長さの出力」ワークロードに最も有利だと述べています。短いプロンプトに長い出力なら、プリフィルはそもそもボトルネックではないので、分ける理由も薄くなります。

まだexperimentalである。 少なくともvLLMではそうです。

それで、あなたは使うべきか

判断基準は意外にはっきりしています。MORI-IOブログが直接答えをくれます。

「プロダクション負荷でITL p99がSLOを超えているなら: 分離してください — これが主なユースケースです。」

「低いリクエストレートで短いプロンプトなら: 標準サービングで十分です。」

ここにここまでの材料を重ねて整理すると、こうなります。

使う価値がある場合

  • テールITLが実際のSLO違反の原因である。ストリーミングが途切れるという不満があり、p99 ITLを測るとプリフィル干渉が犯人だとわかった。
  • 長い入力+中程度の長さの出力のワークロードである。(TensorRT-LLMが明示した条件)
  • 負荷が実際に高い。AWS測定の利得が「同時実行数が上がるほど」現れたことを覚えておいてください。
  • RDMAファブリックとGPUの余裕がすでにある。
  • 大きなモデル、特に疎なMoE。(AWSが推奨する条件)

過剰、あるいは損な場合

  • ボトルネックがTTFTである。分離はTTFTをさらに悪化させます。
  • プレフィックスキャッシングがあなたの主力最適化である。長い共通システムプロンプトを共有するチャットボットなら特に。
  • 負荷が低い、あるいはプロンプトが短い。
  • GPUが数枚しかない、あるいはRDMAがない。
  • ただスループットが物足りないだけ。— この場合、分離は答えではありません。vLLMドキュメントが大文字で言っている通りです。

最後の項目が最もよくある誤解です。「GPUコストを減らしたい」という動機でPD分離を検討しに来たなら、方向を間違えています。それは量子化やバッチチューニングが解く問題です。PD分離が売っているのは予測可能性であって容量ではありません。

おわりに

まとめるとこうです。プリフィルは計算集約的でデコードはメモリ集約的なのに、同じGPUに同居させるとプリフィルがデコードを断ち切ります。PD分離は二つを別々のGPUに分けてその干渉を根本から取り除き、各段階の並列化を別々にチューニングできるようにします。MORI-IO測定でITL違反が完全に消えたことが、その証拠です。

代わりにKVキャッシュをネットワーク越しに運ばなければならず、その時間がTTFTに乗り、RDMAファブリックと複数枚のGPU、増えた運用の複雑さを要求し、プレフィックスキャッシングのような既存の最適化とぶつかることがあります。そして純粋なスループットは — vLLMドキュメントの表現通り — 増えません。

だからPD分離は「より速いサービング」ではなく「約束を守るサービング」です。同じGPUでより多く吐き出す技術ではなく、吐き出すものがSLOの中に収まるようにする技術です。この区別を曖昧にした瞬間、インターネットの倍率の数字に騙されます — その数字はすべて、遅延目標を固定したまま測ったgoodputだからです。

だから順序はこうです。まずp99 ITLを測ってください。それがSLOを超えていて、犯人がプリフィル干渉だとわかったら、そのとき分離を取り出してください。測りもせずに分離から始めるのは、存在しない病気をとても高価な薬で治療するようなものです。

参考資料

현재 단락 (1/109)

LLM推論が二つの段階に分かれることは、もはや常識です。プロンプト全体を一度のフォワードパスで通してKVキャッシュを作る**プリフィル**(prefill)と、トークンを一つずつ取り出す**デコード*...

작성 글자: 0자원문 글자: 11,191자작성 단락: 0/109