SLO-Aware Compute Resource Allocation for Prefill-Decode Disaggregated LLM Inference

本論文は、LLM 推論におけるプリフィル・デコード分離アーキテクチャの最適リソース配分を、総スループットや SLO 制約、および入力・出力長を考慮した理論モデルと実証ベンチマークを組み合わせることで導出する手法を提案し、その有効性を示しています。

要約

🍽️ 物語：AI 厨房の「注文」と「料理」

AI が文章を生成するプロセスは、大きく分けて 2 つのステップがあります。

1. プレフィル（Prefill）: ユーザーが入力した文章（注文）を読み込み、文脈を理解する段階。
2. デコード（Decode）: 理解した文脈に基づいて、単語を一つずつ出力していく（料理を盛り付けていく）段階。

🚫 従来の問題点：「一人のシェフ」のジレンマ

昔は、この 2 つの作業を**同じ GPU（シェフ）**が順番に行っていました。

• プレフィルは「注文を聞いてメモを取る」作業で、計算が激しいですが、メモを取るだけなので時間は短いです。
• デコードは「料理を作る」作業で、メモを見るだけで計算は軽いですが、一つずつ丁寧に作るため、時間がかかります。

これらを同じシェフがやると、「メモを取る作業（プレフィル）」と「料理を作る作業（デコード）」が混ざり合い、お互いに邪魔をし合います。

• 注文が殺到すると、料理を作るシェフが待たされて、料理が出るのが遅くなります（ユーザーが待たされる）。
• 逆に、料理を作るのに集中させると、新しい注文の受け付けが遅くなります。
• 結果: 「最初の言葉が出るまでの時間（TTFT）」と「1 単語が出るまでの時間（TPOT）」の両方を同時に最適化するのが難しく、リソースの無駄も生まれます。

✅ 解決策：「プレフィル厨房」と「デコード厨房」の分離

そこで登場するのが、この論文で提案されている**「P/D 分離（プレフィル・デコードの分離）」**という仕組みです。

• プレフィル厨房：注文を聞いてメモを取る専門のシェフたち。
• デコード厨房：料理を作る専門のシェフたち。
• 両者は別々の部屋にあり、メモ（KV キャッシュ）だけを渡して連携します。

これにより、それぞれの厨房を独立して最適化できます。しかし、**「いったい、プレフィル厨房に何人のシェフを配置し、デコード厨房に何人を配置すればいいの？」**という新しい問題が生まれました。

• プレフィル厨房が多すぎると、料理を作る厨房が待たされて、全体が遅くなります。
• デコード厨房が多すぎると、注文を受ける厨房が待たされて、新しい注文が入りません。
• 業界の課題: 「どれくらい配置すればいいか」を計算する明確なルールがなかったのです。

---

🔍 この論文の提案：魔法の計算式と実験

この論文は、「理論（計算）」と「実測（実験）」を組み合わせたハイブリッドな方法で、最適な人数（リソース数）を導き出すことを提案しています。

1. 理論的な計算（レシピの設計図）

まず、ユーザーが求めている「1 分間に何人の注文を処理したいか（スループット）」や「注文の長さ（入力）」と「料理の長さ（出力）」から、必要な厨房の比率を計算する式を作りました。

• 式: 必要なプレフィル厨房の数 と 必要なデコード厨房の数 を求める公式。
• しかし、この式には**「1 人のシェフが 1 秒間にどれくらい処理できるか（スループット）」**という値が必要です。これが環境によって変わるため、単純な計算だけでは不十分でした。

2. 理論の補強：「待ち行列」の法則（プレフィル編）

「最初の言葉が出るまでの時間（TTFT）」を厳守するためには、プレフィル厨房の混雑具合を計算する必要があります。

• アナロジー: 銀行の窓口やスーパーのレジのような**「待ち行列（キュー）」**です。
• 注文が来ても、シェフが忙しすぎると「待つ時間」が発生します。
• 論文では、**「M/M/1 という待ち行列の数学モデル」**を使って、「ユーザーが許容する待ち時間（TTFT）」から逆算して、「実際に使えるプレフィル厨房の処理能力」を計算しました。
  • 例: 「2 秒以内に最初の言葉を出してほしい」という要望があれば、厨房をフル稼働させず、少し余裕を持たせて運用する必要がある、という計算ができるようになります。

3. 実測による補強：「料理の速度」の把握（デコード編）

料理を作る段階（デコード）では、「1 単語が出るまでの時間（TPOT）」が重要です。

• アナロジー: シェフが一度に何皿の料理を同時に作れるか（バッチサイズ）。
• 一度に大量に作れば効率は良いですが、1 皿あたりの完成が遅くなります。
• そこで、実際に実験して**「TPOT の制限を守りながら、最大で何皿同時に作れるか」**を見極め、その時の処理能力を測定しました。

---

🎯 結果：完璧なバランスの厨房

この 2 つの方法（理論計算＋実測データ）を組み合わせることで、**「ユーザーの要望（スループット、待ち時間）」を満たしつつ、最もコスト効率の良い厨房の人数（GPU 数）」**を正確に予測できました。

• 実験結果: 実際の AI 運用シナリオで、この方法で計算した人数（例：プレフィル厨房 3 部屋、デコード厨房 4 部屋）で運用したところ、「待ち時間」と「処理速度」の両方の目標を完璧に達成しました。
• 対比: 適当に人数を決めた場合（例：プレフィル 3、デコード 3）では、料理を作る厨房がボトルネックになり、目標の処理速度に届きませんでした。

💡 まとめ

この論文は、「AI 厨房をどう運営すれば、ユーザーを待たせず、かつ無駄なシェフを雇わずに済むか」という難問に対して、「数学的な待ち行列の理論」と「実際の料理速度の実験」を掛け合わせることで、最適なスタッフ配置を導き出す方法を提案したものです。

これにより、企業は AI 導入時のコストを最適化し、ユーザーには快適な体験を提供できるようになります。

技術概要

以下は、提示された論文「SLO-Aware Compute Resource Allocation for Prefill-Decode Disaggregated LLM Inference」の技術的な要約です。

論文要約：SLO 意識型 P/D 分離 LLM 推論における計算リソース割り当て

1. 背景と課題 (Problem)

大規模言語モデル（LLM）の推論サービスにおいて、Prefill-Decode (P/D) 分離は、TTFT（Time-To-First-Token）と TPOT（Time-Per-Output-Token）という相反する指標を独立して最適化するために広く採用されているアーキテクチャです。しかし、現在の業界には以下の重要な課題が存在します。

• 最適なリソース配分の欠如: 特定のワークロード（総スループット、SLO 制約、入力・出力長）に対して、Prefill 用と Decode 用の GPU リソース数をどのように決定すべきか、確立された手法が存在しません。
• 非効率な運用: 既存の手法では、SLO を満たすために過剰なリソースを割り当ててコスト増を招いたり、逆にリソース不足で SLO 違反が発生したりするリスクがあります。
• 既存ツールの限界: NVIDIA の AIConfigurator などはパラメータ設定の最適化を行いますが、ユーザーが指定した「総スループット」と「SLO」に基づいた P/D 間のリソース比率（何台の Prefill GPU と何台の Decode GPU が必要か）を包括的に算出する手法は不足しています。

2. 提案手法 (Methodology)

本論文は、理論モデルと実証ベンチマークを融合させたハイブリッドアプローチを提案します。この手法は、個々の P/D インスタンスの最適なデプロイメント（TP/DP 設定など）を決定するのではなく、事前に決定されたデプロイメント構成のもとで、ユーザー要件に基づいた**P/D リソースの「数量」**を算出します。

2.1 理論モデルによる P/D 比率の算出

総スループット、入力長（$L_{in}$）、出力長（$L_{out}$）、および各フェーズの実効スループット（$TP_{prefill}, TP_{decode}$）を用いて、必要なインスタンス数（$N_{prefill}, N_{decode}$）を導出します。

• 基本式: 全体処理時間は Prefill と Decode のどちらか長い方によって決まりますが、アイドル時間を避けるために両者の処理時間を等しく設定します。
• P/D 比率: 総スループットに依存しない比率 $R_{P/D}$ は、入力/出力長と各フェーズのスループット比から以下のように導かれます。
  $$R_{P/D} = \frac{L_{in} \times TP_{decode}}{L_{out} \times TP_{prefill}}$$

2.2 TTFT 制約下での Prefill スループットの推定

TTFT 目標値を満たすための実効 Prefill スループットを算出するために、M/M/1 待ち行列理論を適用します。

• モデル化: リクエストの到着率（$\lambda$）とサービス率（$\mu$）を定義し、システム利用率（$\rho$）を計算します。
• TTFT 分解: TTFT は「キュー待ち時間 + 計算時間 + オーバーヘッド（KV キャッシュ転送等）」としてモデル化されます。
• 導出: 目標 TTFT と最大ベンチマークスループットから、実効スループットを以下のように計算します。
  $$TP_{prefill} = \tilde{TP}_{prefill} - \frac{L_{in}}{TTFT - T_{overhead}}$$
  これにより、厳格な TTFT 要件を満たすために必要な利用率と、結果として得られる実効スループットを予測できます。

2.3 TPOT 制約下での Decode スループットの推定

Decode フェーズでは、実証ベンチマークを用いて TPOT 要件を満たす最適なバッチサイズを特定します。

• 相関関係: バッチサイズが増加するとスループットは向上しますが、TPOT も増加します。
• 手法: 実際のワークロード条件下で、バッチサイズに対する TPOT とスループットの曲線をベンチマークします。目標 TPOT を満たす最大バッチサイズを特定し、そこから実効 Decode スループットを算出します。

3. 主要な貢献 (Key Contributions)

1. 統合モデルの確立: 総スループット、SLO（TTFT/TPOT）、リクエスト長、および P/D 各フェーズの実効スループットに基づき、必要な P/D インスタンス数を計算する理論モデルを提示しました。
2. M/M/1 理論の適用: TTFT 制約下における Prefill 処理の待ち行列モデル化を行い、ベンチマーク値から実効スループットを導出する手法を確立しました。
3. 実証に基づく Decode 最適化: TPOT 制約を満たす最大バッチサイズを特定し、それに基づく Decode スループットを導出する実証的な手法を提供しました。
4. 高精度な予測: 実世界の推論シナリオにおいて、提案手法が最適な P/D リソース配分を正確に予測できることを実証しました。

4. 評価結果 (Results)

DeepSeek-V3.1-Terminus モデルを用いた実環境評価（NVIDIA H200 GPU、SGLang エンジン）を行いました。

• 設定: 目標 TTFT 2 秒、TPOT 20ms、平均入力長 6144、平均出力長 512、総スループット 500 万トークン/分。
• 計算結果:
  • 提案手法により、**3 つの Prefill インスタンスと 4 つの Decode インスタンス（3P4D）**の構成が最適と算出されました（P/D 比率 0.82:1）。
  • 比較対象として 3P3D 構成も評価しました。
• 実績:
  • 3P4D 構成: 約 4.8 M TPM のスループットで、TTFT 2 秒と TPOT 20ms の両方の SLO を同時に満たしました。目標スループット（5 M TPM）に極めて近い値を達成し、ノードあたりの効率も 0.69 M TPM と高くなりました。
  • 3P3D 構成: SLO 制約（特に TPOT）により、最大スループットは約 3.6 M TPM に制限されました。
• 結論: 提案手法により算出されたリソース配分は、コスト効率と SLO 遵守のバランスが最適化されており、リソースの無駄を最小化しつつ目標性能を達成できることが確認されました。

5. 意義と将来展望 (Significance)

• 実用性の向上: LLM 推論サービス運用において、経験則や過剰なマージンに頼らず、定量的かつ科学的な根拠に基づいてハードウェアリソースを設計・割り当てることが可能になります。
• コスト削減: SLO を満たす最小限のリソースで運用できるため、クラウドコストの大幅な削減が期待されます。
• 拡張性: 将来的には、AIConfigurator などの個別インスタンス最適化ツールと統合したり、マルチモーダルモデルにおける EPD（Embedding-Prefill-Decode）分離システムへの適用など、より複雑なアーキテクチャへの汎用化が期待されます。

本論文は、P/D 分離アーキテクチャの普及に伴う「リソース設計のブラックボックス」を解消し、効率的で信頼性の高い LLM 推論インフラの構築に寄与する重要な指針を提供しています。