# PLA-Serve: A Prefill-Length-Aware LLM Serving System > [!info] Talk metadata > - **会議:** [[MLSys2026]] Day 2 (May 19 / Tue)、Research Track Oral "Agentic AI 2 & LLM Serving 1" セッション（14:45 PDT 開始） > - **登壇者:** Jianshu She（Mohamed bin Zayed University of AI）。共著者: Zonghang Li, Hongchao Du, Shangyu Wu, Wenhao Zheng, Eric P. Xing, Zhengzhong Liu, Huaxiu Yao, Jason Xue, Qirong Ho（MBZUAI / UNC Chapel Hill） > - **URL:** https://openreview.net/forum?id=dzjCkSEDyG > - **スライド:** https://mlsys.org/media/mlsys-2026/Slides/3787_G7LPmPu.pdf > - **タイトル表記の相違（注記）:** OpenReview 投稿タイトルは "PLA-Serve: A Prefill-Length-Aware LLM Serving System"。スライド表紙にも同タイトルが記載されるが、スライド末尾に「新タイトル: "LAPS: A Length-Aware-Prefill LLM Serving System"」との記述がある。本ノートでは OpenReview 上のタイトルを正式名称として採用する。 > [!abstract] 概要（OpenReview） > 長さ認識プリフィルサービング（LAPS）は、LLM サービングにおいてプロンプト長の異なるリクエストを識別・分離し、TTFT レイテンシを削減するシステムである。近年のシステムはプリフィルとデコードのステージを分離してスループットを改善してきたが、異種ワークロード特性に適応できない統一的なスケジューリングポリシーに依然として依拠している。プロンプト長の変動が異なる性能ボトルネックを引き起こすことを観察し、適応的スケジューリング戦略の動機を示す。LAPS はマルチターンの長プリフィルリクエストを短プリフィルリクエストから分離し、短プリフィルワークロード向けの長さ認識スマートバッチング機構を導入する。単一プリフィルインスタンス上の時間的分離（temporal disaggregation）と複数インスタンスにまたがる空間的分離（spatial disaggregation）を支持する二重キュー設計を採用する。短プリフィルバッチに対しては、バッチ待機ウィンドウ（batch waiting window）と CUDA Graph ベースのクラスタリングにより異種計算からの干渉を緩和し、バッチング遅延を削減して平均レイテンシを低下させる。実マルチターンワークロードにおいて LAPS は、プリフィル−デコード分離下の素の SGLang と比較してプリフィルレイテンシを 30% 以上削減し、素のデータ並列構成のマルチインスタンス展開で SLO 違反を 28% 低減する。負荷分散付き SGLang ルータと比較しても、マルチ GPU 設定で SLO 違反をさらに 12% 低減する。高並行性かつ混合リクエストシナリオでは、Qwen2.5-32B モデルのプリフィルインスタンスでリクエストスループットを 35% 改善し、異種 LLM サービングワークロードの最適化における有効性を実証する。 ## 問題設定 - LLM 推論はプリフィル段階（prefill stage）とデコード段階（decode stage）の 2 フェーズに分かれる。プリフィルは計算律速（compute-bound）で大規模 GEMM を実行し KV キャッシュ（KV cache）を生成する。デコードはメモリ律速（memory-bound）でトークンを逐次生成する - 現行の SOTA であるプリフィル−デコード分離（PD disaggregation）は両フェーズを別 GPU インスタンスで実行するが、**プリフィルインスタンス内部**では長短リクエストが同一バッチで処理され、スケジューリングが統一的なまま残されている - 実世界のワークロードにはプロンプト長に大きな偏りが存在する。スライド「Background: Real-World LLM Serving Workload」で示された 8 種のトレース分析によれば: - LMSYS-Chat-1M: $P(\text{prefill} < 256) = 95.5\%$、中央値 35、平均 70 - ShareGPT: $P(\text{prefill} < 256) = 89.1\%$、中央値 72、平均 122 - CoT 推論（MMLU-Pro / GSM8K）: $P(\text{prefill} < 256) = 90.5\%$、中央値 60、平均 111 - RAG（クエリ＋検索チャンク）: $P(\text{prefill} < 256) = 0.3\%$、中央値 2,504、平均 3,487 - エージェント初回ターン: $P(\text{prefill} < 256) = 50.8\%$、中央値 250、平均 452 - エージェント後続ターン（ツール返却＋ユーザメッセージ）: $P(\text{prefill} < 256) = 22.5\%$、中央値 802、平均 2,298 - Azure trace 2023（累積プロンプト）: $P(\text{prefill} < 256) = 7.1\%$、中央値 1,227、平均 2,210 - Mooncake trace（Kimi、累積プロンプト）: $P(\text{prefill} < 256) = 1.3\%$、中央値 3,498、平均 6,994 - 長短プリフィルの混在は 2 種の干渉を引き起こす: 1. **ヘッドオブラインブロッキング（head-of-line blocking）**: 長リクエストがキュー先頭に居座り短リクエストを待たせる。スライド「Motivation: Intra Prefill Task interference」の P90 TTFT 測定では、短リクエスト専用バッチ（$S=8$: 45 ms, $S=16$: 48 ms, $S=32$: 52 ms）に対し長短混在バッチでは $S=8$: 125 ms, $S=16$: 165 ms, $S=32$: 205 ms へ悪化 2. **計算/メモリ律速の干渉**: 混合バッチのフォワードパスレイテンシが短リクエスト専用バッチの 29〜31 倍に膨張。Qwen2.5-7B で Config A（短プリフィル専用 8×64 トークン）19 ms に対し Config C（混合 7×64 + 1×2048）567 ms。Qwen2.5-32B で Config A: 74 ms 対 Config C: 2289 ms ## 提案手法 ### 理論的基盤: レイテンシモデルとスケジューリング干渉 スライド「Theoretical Analysis: Latency Model & Scheduling Interference」に 2 つの理論的分析を提示する。 1. **ヘッドオブラインブロッキングの M/G/1 待ち行列モデル**: 長短ジョブ混在時の追加待ち時間は $\Delta W = \lambda \cdot p(1-p) \cdot (S_L - S_S)^2 \;/\; 2(1-\rho) > 0$ ここで $\lambda$ はリクエスト到着率、$p$ は長ジョブの混合比率、$S_L, S_S$ は長短のサービス時間、$\rho$ はサーバ利用率である。$(S_L - S_S)^2$ が異種性とともに増大するため、長短混在のペナルティは急激に拡大する 2. **プリフィルレイテンシの分解**: プリフィル時間 $T(L, H)$ は計算時間 $T_{\text{compute}}$ とメモリ時間 $T_{\text{memory}}$ に分解される。$L$ は新規リクエストトークン数、$H$ は履歴 KV トークン数として: - $T_{\text{compute}}(L, H) \approx \alpha L(L + 2H) + \beta L$（アテンションは二次、FFN は線形） - $T_{\text{memory}}(L, H) \approx \gamma_w \cdot L + \gamma_r \cdot H$（$\gamma_w \cdot L$ は KV 書き込み、$\gamma_r \cdot H$ は履歴読み出し） - 初回ターン（$H=0$）では $T_{\text{memory}} = \gamma_w \cdot L$、リプリフィル（$H \gg 0$）では $T_{\text{memory}} = \gamma_w \cdot L + \gamma_r \cdot H$ - 短長の境界: $L_m = (\gamma_w - \beta) / \alpha \approx 256$ トークン（H200 上） スライド「Characteristic of Prefill Request」の H200 上 Qwen2.5-7B ルーフラインモデルでも、短シーケンス（16〜256 トークン）ではカーネル時間がほぼ一定（GEMM: 4.9〜5.4 ms、FlashAttn: 同程度）でメモリ律速、256 トークン以降で計算律速へ遷移し時間が急増（1024 トークン: 13.7 ms → 2048 トークン: 51.6 ms）する。マルチターンタスクのリプリフィルは KV キャッシュ履歴が大きく算術密度が低下する。 ### LAPS: 第 4 のサービングモード スライド「LAPS: Introducing the 4th Serving Mode」では、既存の 3 モード（Mix Mode、PD 時間的分離、PD 空間的分離）に加え、**プリフィルバッチ分離（Prefill Batch Disaggregation）** を第 4 のモードとして導入する。長プリフィルと短プリフィルをプリフィルステージ内部で分離し、時間的または空間的に処理する。既存の PD 分離と完全に互換であり、プリフィルクラスタ内で動作しインタフェース変更を要しない。 ### イノベーション 1: プリフィル分離と動的インスタンスバランシング スライド「Our Solution: Length-Aware-Prefill LLM Serving System」および「Innovation 1: Prefill Disaggregation — Dynamic Instance Balancing」による。 - リクエスト到着時にプロンプト長 $L_p$ を閾値 $L_m$ と比較し、メモリ律速プール（短プリフィル、SP）と計算律速プール（長プリフィル、LP）に振り分ける - LAPS スケジューラがランタイムメトリクスとインスタンスメトリクスを参照し、**時間的分離**（単一プリフィルインスタンス上で SP/LP バッチを交互実行）または**空間的分離**（複数インスタンスを SP プールと LP プールに分割）を選択する - 空間的分離では $N$ 個の GPU インスタンスを SP プールと LP プールに分割し、軽量コントローラが $\Delta t$ 秒ごとに各インスタンスを監視してリバランスする。プレッシャー（Pressure）スコアは以下の 3 信号から算出: - **キューバックログ（Queue Backlog）**: キュー長 → 到着率に追従不能 - **SLA 逸脱（SLA Deviation）**: TTFT デッドライン近傍・超過のリクエスト - **GPU 利用率（GPU Utilization）**: 高利用率 → プレッシャー低減 - $\text{Pressure} = \text{Queue} \uparrow + \text{SLA miss} \uparrow - \text{GPU util} \uparrow$ - $\text{Pressure}_{SP} \gg \text{Pressure}_{LP}$ の場合、LP プールから 1 インスタンスを SP プールへマイグレーション（例: sp=4, lp=4 → sp=5, lp=3） ### イノベーション 2: CUDA Graph バケット化による短プリフィルバッチ処理 スライド「Innovation 2: CUDA Graph Bucketization for Batched Short Prefills」による。 - 通常のプリフィルではリクエストごとにテンソル形状が変化するため CUDA Graph を適用できない。一方、短プリフィルはデコードに近いメモリ律速動作でコンパクトかつ安定した形状を持ち CUDA Graph に適する - **バケットグリッド（$L \times B$）**: 系列長 $L$（8, 16, 32, 64）とバッチサイズ $B$（1, 2, 4, 8, 16）の組み合わせごとに CUDA Graph を 1 つキャプチャ。ヒット頻度に基づく動的変更も可能 - **キャプチャ（一回限りの初期化）**: (1) ダミーテンソルで入力形状を確保、(2) GEMM → FlashAttn → FFN の全レイヤ完全フォワードパスを実行、(3) `graph_store[(32, 4)] = graph` のようにキー (L, B) で保存 - **リプレイ（毎リクエスト）**: 到着リクエスト（例: 29 tok, 47 tok, 13 tok, 58 tok）を最近傍バケットにルックアップ（29→32, 47→64, 13→16, 58→64）し、バケットキーでグルーピングしてグラフを即時リプレイ - 2 つのグルーピング戦略: - **メモリ優先（Memory first）**: `batch(2×64) + batch(1×32) + batch(1×16)` のようにパディングを最小化、カーネル起動は複数回 - **レイテンシ優先（Latency first）**: `batch(4×64)` のように同一長に揃え単一カーネル起動 ### イノベーション 3: 適応的待機深度（AWD）スケジューラ スライド「Innovation 3: Adaptive Wait-Depth (AWD) Scheduler」による。 - 待機ウィンドウ（Waiting Window）対レイテンシ・スループットのトレードオフ: 待機が短すぎるとバッチ充填不足でスループット低下、長すぎるとレイテンシ増大。最適点は約 6 ms（スライドのグラフ） - AWD は毎スケジューリングラウンドで 2 つの適応的閾値を選択: - $W_{SLA}$: **SLA 安全ウィンドウ** — いかなるリクエストもデッドラインを逃さず待てる最遅ディスパッチ時刻 - $W_{GR}$: **グラフ充填ウィンドウ** — CUDA Graph バケットを満たす十分なリクエストが到着するまでの予想時間 - $W = \text{clip}(\min\{W_{SLA}, W_{GR}\})$ - $W$ まで待機しバッチ深度 $D$ に達するまでリクエストを蓄積。SLA スラックが閾値 $\sigma$ 以下のリクエストがあれば即座にディスパッチ。毎ディスパッチ後に $W$ と $D$ を観測到着率から更新 ## 実験・結果 ### 単一プリフィルインスタンス（時間的分離） スライド「Results: Request Throughput — Single Prefill Instance (Temporal)」による。LMSYS-Chat-1M データセット、プリフィルインスタンス 1 台での 4 構成比較（Baseline / Graph / Disaggregation / LAPS）。 - **Qwen2.5-7B**: LAPS は全並行度（CC=10〜60）でスループット・平均レイテンシ・P90 レイテンシのいずれにおいても最良。CC=60 で約 550 req/s 超（Baseline 約 400 req/s） - **Qwen2.5-14B**: 同様の傾向。LAPS が全指標で一貫して優位 - **Qwen2.5-32B**: LAPS は CC=60 で約 150 req/s（Baseline 約 50 req/s 以下）、P90 レイテンシも大幅に低減 ### 8 プリフィルインスタンス（空間的分離） スライド「Results: Request Throughput — 8 Prefill Instance (Spatial)」による。LMSYS-Chat-1M データセット、プリフィルインスタンス 8 台。 - **Qwen2.5-7B**: CC=60 で LAPS は約 600 req/s 超（Baseline 約 450 req/s） - **Qwen2.5-14B**: CC=60 で LAPS が Baseline・Graph・Disaggregation を明確に上回る - **Qwen2.5-32B**: CC=60 で LAPS は約 400 req/s 超（Baseline 約 100 req/s 前後）、P90 レイテンシも他手法の半分以下 ### 主要数値（OpenReview アブストラクトより） - プリフィル−デコード分離下の素の SGLang と比較しプリフィルレイテンシを **30% 以上**削減 - マルチインスタンス展開（素のデータ並列構成）で SLO 違反を **28%** 低減 - 負荷分散付き SGLang ルータと比較しマルチ GPU 設定で SLO 違反をさらに **12%** 低減 - 高並行性・混合リクエストシナリオで Qwen2.5-32B モデルのリクエストスループットを **35%** 改善 ## 設計上のトレードオフ スライド「Discussion: Two Design Trade-offs in LAPS」による。 ### D1: バケットパディングによる KV キャッシュスロット浪費 - CUDA Graph 使用時、各リクエストは最近傍バケット境界までパディングされ、未使用スロット分の GPU メモリが浪費される（例: 29 tok → バケット 32 で 3 スロット浪費、47 tok → バケット 64 で 17 スロット浪費） - 緩和策: メモリ優先戦略（`2×32 + 2×64` のように分割）でパディングを削減。レイテンシ重視時はレイテンシ優先、メモリ逼迫時はメモリ優先を選択 ### D2: PD 分離下の KV キャッシュ転送バースト - AWD が待機ウィンドウ中にリクエストを蓄積し一括ディスパッチするため、プリフィル完了時に全リクエストの KV キャッシュがデコードインスタンスへ同時転送される - InfiniBand 環境: 高帯域がバーストを吸収し新たなボトルネックにならない - InfiniBand 非搭載環境: バーストがネットワークを飽和させ新たなボトルネックとなりうる。$W$ が大きいほどバッチが大きくなりピーク帯域要求が増大 ## 結論・オープン課題 - LAPS は既存 3 モード（Mix、PD 時間的分離、PD 空間的分離）に加え、**プリフィルバッチ分離**を第 4 のサービングモードとして提案した。プリフィルステージ内部で長短リクエストを分離し、短プリフィルには CUDA Graph バケット化と AWD スケジューラを適用する - 既存の PD 分離フレームワーク（SGLang 等）と完全に互換であり、プリフィルクラスタ内で動作しインタフェース変更を必要としない - 理論的な長短境界 $L_m \approx 256$ トークンは H200 での導出であり、GPU アーキテクチャや将来のハードウェアで変動しうる。異なる GPU に対するプロファイリングベースの閾値自動決定が実用上の課題 - InfiniBand 非搭載環境での KV キャッシュ転送バースト問題は未解決。ネットワーク帯域制約下でのバッチサイズ・待機ウィンドウの最適化が残る - バケットパディングによるメモリ浪費はモデルサイズ増大とともに深刻化する可能性があり、動的バケット再構成やメモリプール最適化が今後の方向性として考えられる