Inference Phases（推論フェーズ）

LLM 推論は計算プロファイルの正反対な 2 フェーズの直列実行である。Prefill は compute-bound、decode は memory-bandwidth-bound — この非対称性が共有スケジューラでの ITL スパイク原因であり、chunked prefill と PD disaggregation の動機。バッチング詳細は tech-43、TTFT/TPOT/ITL/Goodput/MFU 定義は tech-44、注意機構は tech-38、Transformer は tech-35。

なぜ Prefill と Decode を分けて考えるか

prompt_len = 512 で prefill は decode の 512 倍、32K で 32,000 倍の arithmetic intensity。これが「共有スケジューラで干渉する」根本原因であり、後述技術のすべての設計動機。

Prefill フェーズの compute プロファイル

プロンプト全トークンを一括 forward pass で処理し、① 最初の出力トークン、② プロンプト全長分の KV キャッシュを出力する。全トークン並列に通すため GEMM サイズが prompt_len に比例し、十分長いプロンプト (512+) で ridge point を超えテンソルコア律速 (Roofline 解釈)。prefill 時間が TTFT の主要因で TTFT ≈ T_queue + T_prefill、T_prefill は prompt_len × model_size でほぼ線形 (tech-44)。prompt_len が 512 → 32K で prefill コストは 64 倍となり、ロングコンテキスト有効化で TTFT が秒オーダーまで伸び得る (P2 の元ネタ)。

Decode フェーズの memory プロファイル

最初の出力トークン生成後、<eos> または max_length まで 1 トークンずつ自己回帰生成。各ステップで全モデル重み + KV キャッシュを HBM から読み出し 1 トークン分の forward を回す。batch=1 では各ステップで全重みを読み直す (7B FP16 で約 14 GB) ため HBM 帯域に律速され下限は

TPOT_floor = model_size_bytes / HBM_bandwidth_bytes_per_s

例: 7B FP16 を A100 80GB (HBM 2 TB/s 級) で回すと batch=1 の TPOT 下限は概ね 7 ms/token。バッチングは重み読みを複数リクエスト間で償却するため効き、十分大きな batch で初めて compute-bound 側に倒れる (tech-43)。decode 各ステップ所要時間は TPOT / ITL に直結し、ITL は瞬時値なので連続バッチング下で長 prefill chunk と co-batched されたステップでスパイク、体感は ITL p99。

共有スケジューラで両者を混ぜると何が起きるか

Orca (Yu et al., OSDI 2022, https://www.usenix.org/conference/osdi22/presentation/yu) は iteration-level scheduling で head-of-line blocking を解消したがフェーズを分割しない — 1 イテレーションで「新規 prefill 全体 + in-flight decode」を同時処理する (tech-43)。長プロンプトが入ると ① GPU 時間の大半を prefill が消費 → ② in-flight decode が遅延 → ③ ITL スパイクとして観測される (例: decode 16 系列稼働中 (各 ~10 ms) に prompt_len=4096 到着で ITL が約 20 倍スパイク)。Roofline 視点では prefill が FLOPs を飽和し decode の memory-bound 処理が割り込めず、idle リソース (decode が使いたい帯域) と逼迫リソース (FLOPs) が同時発生する。Goodput (tech-44) が TTFT < T_ttft AND TPOT < T_tpot at p99 の同時条件で定義される本質的理由。

Chunked Prefill — 時間分割による干渉緩和

長い prefill を固定サイズのチャンク (例: 512 トークン) に分割し、各イテレーションで「1 prefill chunk + 全 active decode」を同時処理。Orca の「prefill 全体を 1 イテレーションで終わらせる」暗黙制約を外す。効果: ITL スパイクが chunk_size / prompt_len に比例して縮小、compute-bound chunk と memory-bound decode を同一イテレーションに混在させ idle 時間を短縮、長プロンプト TTFT も短縮。トレードオフ: 総計算量不変だが KV を段階的に埋めるためイテレーション数が増え、単一リクエスト TTFT は微増し得る (実装依存)。

論文と実装:

• Sarathi-Serve (Agrawal et al., arXiv:2403.02310, https://arxiv.org/abs/2403.02310) — chunked prefill を定式化、本番サービング向けに拡張
• DeepSpeed-FastGen の Dynamic SplitFuse (https://github.com/microsoft/DeepSpeed/tree/master/blogs/deepspeed-fastgen) — 同概念のリブランド、チャンク予算を動的決定
• vLLM: --enable-chunked-prefill、FlashAttention-2 backend で既定有効化が進行中 (https://docs.vllm.ai/en/latest/features/chunked_prefill.html)
• SGLang: chunked prefill + RadixAttention (Zheng et al., arXiv:2312.07104) で RAG・エージェント向け最適化 (tech-43)
• TensorRT-LLM: in-flight batching + chunked context processing

チャンクサイズは vLLM 系では --max-num-batched-tokens で制御、概ね 512 トークンから始めるのが実務的出発点。

Prefill-Decode Disaggregation — 空間分割による干渉除去

prefill workers と decode workers を物理的に分離し、KV キャッシュをネットワーク (NVLink / InfiniBand / Ethernet) 経由で転送する。chunked prefill が「同一 GPU 上の時間分割」なのに対し「異なる GPU 上への空間分割」 (tech-43)。効果: 干渉が原理的に消え、prefill / decode workers を別々に SLO 最適化、異種 GPU フリートを構成可能。トレードオフ: KV 転送オーバーヘッド (7B・4096 トークンで GB オーダー、P3 で計算)、NVLink で数 ms、Ethernet (100 GbE = 12.5 GB/s) では数十〜数百 ms に増え TTFT に直接乗る。実装複雑性も高い。

主要論文:

• Splitwise (Patel et al., ISCA 2024, arXiv:2311.18677, https://arxiv.org/abs/2311.18677) — MSR。prefill は FLOP 効率重視 (H100 等)、decode は HBM 帯域重視という異種フリートが最適と主張、KV 転送は NVLink / PCIe で prefill 完了後即送出
• DistServe (Zhong et al., OSDI 2024, arXiv:2401.09670, https://arxiv.org/abs/2401.09670) — 北京大 / UCSD。prefill cluster と decode cluster を分離し KV 転送。「goodput」(SLO 遵守 token のみ計上) を主要指標として提唱し tech-44 が広範に引用

Speculative Decoding — フェーズ修飾子として

軽量ドラフトモデルが K 個の候補を生成し、ターゲットが 1 forward で全 K 個を並列検証、最初の不一致まで accept する decode 最適化。1 ステップ = ドラフト K 個 + ターゲット 1 forward + 0〜K+1 トークン accept。主要論文は Leviathan et al. (arXiv:2211.17192)、Chen et al. (arXiv:2302.01318)、accept rate 向上策に Medusa (2024)、EAGLE (2024) (tech-43)。指標は tech-44。chunked prefill と組合せで「prefill chunk + 不均一 accept の decode batch」管理が複雑化 (P4 元ネタ)。

ハードウェア階層マッピング

Splitwise の key claim は prefill に FLOP-dense GPU、decode に HBM-bandwidth-dense GPU を割り当て各ボトルネックに最適化された HW を別々に使える点。同一フリート混走ではどちらか一方が常に余って経済効率が悪い。

5 大ピットフォール

tech-43 はバッチング観点、tech-44 は指標観点。本記事はフェーズ観点で重複なく定義する。

P1: TTFT だけチューニングして TPOT を無視する — chunked prefill で TTFT が改善すると安心しがちだが decode-heavy では TPOT / ITL が依然ボトルネック。TTFT SLO ≤ T1 AND TPOT SLO ≤ T2 の同時条件 (DistServe の goodput 定義) が本番運用の出発点。

P2: 長コンテキストで prefill コストを「無料」扱いする — prompt_len = 32K の prefill は 512 の 64 倍にスケール (compute-bound 故)。TTFT が秒オーダー化を「モデルの限界」と誤解しがちだが、chunked prefill か disaggregation で緩和できる場合が多い。まずフェーズ分解で計測する。

P3: disaggregation 導入時に KV 転送コストを過小評価する — 7B・32 層・32 ヘッド・head_dim=128・4096 トークン・FP16 の KV は

KV_bytes = 2 × layers × heads × head_dim × seq_len × dtype_bytes
        = 2 × 32 × 32 × 128 × 4096 × 2  ≈ 2.1 GB

(式は tech-43)。NVLink 600 GB/s で ~3 ms、100 GbE では ~160 ms が TTFT に乗る。NVLink が使えないクラスタでは disaggregation の SLO 改善が KV 転送で打ち消され得るためネットワーク要件の事前検証が必須。

P4: Speculative decoding と chunked prefill の相互作用を無視する — 同時有効化で 1 イテレーションに「prefill chunk + accept 数が系列ごとに異なる decode batch」が並び KV 更新が複雑化、high-batch では accept 数ばらつきが GPU 効率を不均衡化。両オン前に実負荷で goodput を比較するベンチが不可欠。

P5: 長プロンプトが chunk 予算を超過する場合の挙動を確認しない — max-num-batched-tokens 超のプロンプトは複数イテレーションに分割される。設定が小さすぎると多イテレーションを要し TTFT が逆に悪化。出発点は max_prompt_len / 2 を仮置きし TTFT / ITL を同時観測しながら調整する。

参考文献

• Yu et al. (2022). Orca. OSDI 2022. https://www.usenix.org/conference/osdi22/presentation/yu
• Agrawal et al. Sarathi-Serve. arXiv:2403.02310. https://arxiv.org/abs/2403.02310
• Patel et al. Splitwise. ISCA 2024. arXiv:2311.18677. https://arxiv.org/abs/2311.18677
• Zhong et al. DistServe. OSDI 2024. arXiv:2401.09670. https://arxiv.org/abs/2401.09670
• Leviathan et al. Speculative Decoding. arXiv:2211.17192. https://arxiv.org/abs/2211.17192
• Chen et al. Speculative Decoding. arXiv:2302.01318. https://arxiv.org/abs/2302.01318
• DeepSpeed-FastGen / Dynamic SplitFuse. https://github.com/microsoft/DeepSpeed/tree/master/blogs/deepspeed-fastgen
• vLLM chunked prefill docs. https://docs.vllm.ai/en/latest/features/chunked_prefill.html