LLM パフォーマンスの最適化：長いプロンプトのブロッキングとデコード遅延の解決

TL;DR

LLM のサービングにおいて長いプロンプトはプレフィルキューをブロックし、同時リクエストのトークン生成を遅延させます。これを緩和するために、リクエスト並列プレフィルは短いプロンプトの最初のトークンまでの時間（TTFT）を短縮し、分散プレフィルはプレフィルとデコードのフェーズを別々の GPU に分離して干渉を排除し、レイテンシを安定させます。

長いプロンプトのブロッキングという課題

標準的な LLM サービングでは、プレフィルフェーズ（初期プロンプトの処理）は計算負荷が高く GPU の使用率を飽和させることがありますが、デコードフェーズ（その後のトークン生成）は計算負荷が低めです。vLLM が使用するデフォルトのチャンク化プレフィル戦略では、異なるリクエストのプレフィルチャンクが順次スケジュールされます。

非常に長いプロンプトを持つリクエストがスケジュールされると、プレフィルキューがブロックされます。その後のリクエストは、長いプレフィルが完了するまで自分のプレフィルフェーズを開始できず、結果としてこれらのリクエストの最初のトークンまでの時間（TTFT）が大幅に増加します。

リクエスト並列プレフィル

キューのブロッキングに対処するため、vLLM は複数リクエストに対して並列プレフィルを許可する戦略を実装しました。ただし、同時に処理できる長いプロンプトの数には制限があります（例：4 つの並列プレフィルは許可するが、10,000 トークンを超えるものは 1 つだけ）。

  • Impact on Short Prompts: 短いプロンプトは「ファストレーン」を通って長いプレフィルを回避できるようになり、TTFT が劇的に短縮されます。
  • Impact on Long Prompts: 長いプロンプトは引き続き順次処理されます。これは、複数の計算負荷の高いプレフィルを同時にバッチ化した場合に起こり得る深刻なシステム遅延を回避するためです。
  • Limitation: TTFT は短縮されるものの、同時プレフィルが GPU リソースを消費し続けるため、出力トークンあたりの時間は依然として高く、既存リクエストのデコードステップが遅くなります。

根本的な欠陥：プレフィルとデコードの干渉

異なるリクエストに対して同じ GPU 上でプレフィルとデコードの操作を同時に実行すると、トークン生成が遅延します。長いプロンプトを持つ単一のリクエストだけで、現在デコードフェーズにある以前にスケジュールされたすべてのリクエストのパフォーマンスが低下します。

緩和策

この干渉に対処する主な方法は 3 つあります。

  1. Priority Penalization: 長いプロンプトは高優先度または短いリクエストが完了するまで待たされます。これにより長いプロンプトのレイテンシが増加し、実際に長いプロンプトがスケジュールされた後の干渉問題は解決されません。
  2. Dedicated Inference Servers: 長いプロンプトのリクエストを別サーバーにルーティングします。これには高度なルーターと追加の GPU リソースが必要ですが、短いコンテキストのサーバーは少ない GPU で展開可能です（例：Llama-3.3-70B は 130k コンテキストで 4 台の H100 が必要ですが、10k 未満のコンテキストでは 2 台の H100 で済みます）。
  3. Disaggregated Prefill: プレフィルとデコードに別々の推論エンジンを使用します。このアーキテクチャは複数の vLLM デプロイメントを伴い、あるワーカーがプレフィルのみ、別のワーカーがデコードのみを担当します。プレフィルが完了すると、KV キャッシュがデコードワーカーに転送されます。

レイテンシ最適化のための分散プレフィル

分散プレフィルは、同時プレフィルによって引き起こされるデコードフェーズへの直接的な妨害を排除し、トークン生成レイテンシを安定させる最も効果的な戦略となります。

トレードオフと現状

  • Resource Cost: このアプローチは、各ロールごとにフルサイズの vLLM デプロイメントを別々に用意する必要があります（例：Llama-3.3-70B では 8 台の H100、プレフィル用 4 台、デコード用 4 台）。
  • GPU Utilization: プレフィルはデコードより計算負荷が高いため、GPU の使用率はしばしば不均衡になります。ただし、大規模クラスターでは負荷パターンに応じてプレフィルとデコードのワーカー比率を調整することでバランスを取れます。
  • Goal: 主な目的は総スループットではなく「goodput」（レイテンシ目標を満たすリクエストの割合）を向上させることです。
  • Experimental Status: vLLM v0.7.3 時点でこの機能は実験的です。現在の制限としては、コンテキスト長の上限が低いことや、デコードワーカーで CUDA グラフの使用が一貫していないことがあり、統合デプロイと比較してデコード速度が遅くなる可能性があります。

Sources