vLLMの継続的バッチ処理：スケジューラ、チューニング、ベンチマーク

継続的バッチ処理により、vLLMサーバーは、他のリクエストがまだトークンを生成している間に新しいリクエストを受け入れられます。固定バッチでは、次のバッチを形成する前にすべてのメンバーが完了するのを待つ必要があります。一方、継続的バッチ処理では、スケジューリングの各ステップでアクティブセットを再評価します。この違いは、プロンプトと出力の長さが異なる場合に重要です。短いリクエストは、前のグループで最も長い応答を待つことなく、GPUの処理に参加できます。

推論チームにとって有用な問いは、機能一覧で継続的バッチ処理が有効になっているかどうかではありません。実際のリクエスト構成で、初回トークンまでの時間、キュー時間、エラー率をサービス目標の範囲内に保ちながら、1秒あたりの完了レスポンス数を増やせるかどうかです。このガイドでは、その仕組み、重要な制約、GPU容量を選択する前に実行できるベンチマークについて説明します。

vLLMの継続的バッチ処理の仕組み

vLLMの現行V1アーキテクチャでは、スケジューラは各ステップで、実行中および待機中のリクエストからトークン予算を埋めます。リクエストは計算済みトークン数を追跡し、スケジューラはその差を埋める作業を割り当てます。同じループで、チャンク化プリフィル、プレフィックスキャッシュ、投機的デコーディングも処理します。これは、完了まで実行される単一の静的バッチを示す図よりも正確なメンタルモデルです。スケジューラの説明については、vLLMのアーキテクチャ概要を参照してください。

短いチャット応答、長いドキュメントプロンプト、もう1件の短いチャットという、3つの到着を想像してください。固定バッチでは、2件目の短いチャットは長いリクエストのバッチ境界まで待つ可能性があります。継続的バッチ処理では、最初のリクエストがアクティブなままであっても、後のスケジューリングステップで考慮できます。ただし、受け入れはトークン予算、シーケンス上限、利用可能なKVキャッシュ領域によって制約されます。継続的バッチ処理は、キューイングがゼロになることや、すべてのリクエストで結果が速くなることを保証するものではありません。

PagedAttentionは問題の別の部分、すなわち注意機構のKVキャッシュをブロック単位で保存・管理することに対処します。これによりエンジンはメモリをより柔軟に使用できますが、どのリクエストに計算リソースを与えるかはスケジューラが決定します。これらの役割を分けて考えることで、スループット低下の原因がスケジューリング、KVキャッシュの逼迫、長いプロンプト、またはアップストリームのボトルネックのどれであるかを診断しやすくなります。vLLM PagedAttentionの設計では、メモリの仕組みを説明しています。

バッチを形作る制御項目

これらの設定は相互に影響します。トークン予算を増やすと、あるワークロードではスループットが向上する一方で、別のワークロードでは対話的レイテンシが悪化する可能性があります。受け入れるシーケンス数を増やすと並行性は高まりますが、KVキャッシュの消費も増えます。バージョン、モデルアーキテクチャ、コンテキスト長、ハードウェアはいずれも結果に影響します。使用中のvLLMリリースにおける動作については、スケジューラ設定リファレンスを読み、一度に変更する制御項目は1つだけにしてください。

KVキャッシュに新しい処理を収容できない場合、vLLMは実行中のリクエストをプリエンプトし、後でその進行状況を再計算することがあります。プリエンプション数の増加は、単にバッチへの到着リクエストを増やすことがコストなしではないという警告です。アーキテクチャ概要では、スケジューリングとプリエンプションのルールを説明しています。

本番トラフィックに一致するベンチマーク

クライアントが送信できる最大速度で単一の短いプロンプトを投入して、継続的バッチ処理の設定を比較しないでください。自社ログまたはプライバシーに配慮したトレースから、次の3つのリクエストグループを作成します。

1. 短いプロンプトと応答による短時間の対話型チャット。
2. 大きなプリフィルと中程度の出力長を持つ長文コンテキストのリクエスト。
3. プレフィックスの繰り返し、さまざまな出力長、キャンセル、バーストを伴うエージェントまたはRAGリクエスト。

実行間でモデルリビジョン、トークナイザ、GPUタイプ、vLLMバージョン、リクエストトレースを固定してください。想定負荷未満から、キュー時間またはエラーが許容できなくなる点まで、提示リクエストレートを変化させます。公式のvllm bench serve ガイドには、リクエストレートとデータセットの制御方法が記載されています。比較を再現できるよう、正確なコマンド、設定、トレースバージョンを記録してください。

各実行について、1秒あたりの完了リクエスト数、1秒あたりの出力トークン数、初回トークンまでの時間のp50およびp95、トークン間レイテンシのp95、エンドツーエンドレイテンシのp95、キュー時間、失敗、GPUメモリ使用量の最大値を記録します。vLLMの本番メトリクスリファレンスには、実行中および待機中のリクエストのゲージ、キュー時間、初回トークンまでの時間、プリエンプションのヒストグラムが含まれています。有用なスコアカードは次のとおりです。

この表には測定値を記入してください。他のモデルやプロバイダーからそのまま流用できる、普遍的な改善率はありません。単独で最も高いトークン・スループットを示す構成ではなく、受け入れられたレスポンスあたりのコストを最小限に抑えつつ、レイテンシーと信頼性の目標を満たす構成を選択してください。

期待外れの結果を診断する

継続的バッチ処理が効果を発揮していないように見える場合は、別のフラグを変更する前に制約を確認してください。

GPUメモリには余裕があるのに、待機中のリクエストが増加する。 受け入れ上限、小さすぎるシーケンス上限、CPUでのトークン化、クライアント側の並行実行数を確認してください。スケジューラは、GPUに到達しないリクエストでGPUを埋めることはできません。

長いプロンプトで初回トークンまでの時間が増加する。 ベンチマークでは、prefill負荷の高いトラフィックとdecode負荷の高いトラフィックを分離してください。チャンク化prefillとトークン予算の設定を見直し、平均値だけでなく長いプロンプトの分布を比較してください。

スループットは改善するが、p95レイテンシーが悪化する。 サーバーが、対話型サービスの目標で許容される以上の同時実行処理を受け入れている可能性があります。受け入れを制限し、キュー・タイムアウトまたは別のサービングプールを使用して、同じ投入負荷で再テストしてください。

プリエンプションまたはメモリ不足イベントが増加する。 アクティブなコンテキストがGPUのKVキャッシュに収まらない可能性があります。並行実行数またはコンテキスト上限を下げる、十分なメモリを持つGPUを選ぶ、あるいはモデルと精度の選択を見直してください。プリエンプトされたリクエストを、コストのかからないスケジューリングイベントとして扱わないでください。

リクエストが待機していてもGPU使用率が低い。 ボトルネックを継続的バッチ処理に帰する前に、CPU、ネットワーク、ストレージ、モデルのロード、クライアントのペーシングを調査してください。当社のvLLMデプロイメントガイドでは、より広範なサービングのランブックを扱っています。本記事ではスケジューラの動作と測定に焦点を当てます。

GPUの選択が意思決定に影響する場面

継続的バッチ処理はGPUの利用効率を高められますが、搭載されていないメモリにモデルを収めることはできません。想定する並行実行数およびコンテキスト長における重み、KVキャッシュ、ランタイム・オーバーヘッド、安全マージンを見積もってください。次に、レンタル予定のGPU構成でベンチマークを実行します。80 GB GPUとより大容量メモリのGPUでは、同じモデルおよびリクエスト・トレースであっても、受け入れとプリエンプションの動作が異なる場合があります。

Flatkey GPU Computeでは、H100 SXM、H200、B200、B300、A100 80GB、RTX 5090などのレンタルオプションを掲載しています。構成、リージョン、可用性、価格は、選択したレンタルについて確認する必要があります。オプションを比較する際は、ベンチマーク・トレース、目標レイテンシー、モデル・リビジョン、メモリ見積もりを用意してください。これにより、容量に関する議論を、見出しとなるGPU仕様ではなく完了した処理に基づいて行えます。

実践的な意思決定チェックリスト

vLLMの継続的バッチ処理構成を決定する前に、次の質問に答えてください。

• 最も負荷の高いトラフィック・シナリオで、p95の初回トークンおよびエンドツーエンド・レイテンシーの目標を満たしていますか？
• 通常のリクエスト率を超えるバースト時には何が起こりますか。キューは制限されますか、拒否されますか、それともレイテンシーが大幅に急上昇しますか？
• 意図したコンテキスト長において、プリエンプションとKVキャッシュの負荷は安定していますか？
• 実行予定の正確なモデル・リビジョンおよびGPU形状で、結果を再現できますか？
• 再試行とアイドル容量を考慮した後も、受け入れられたレスポンスあたりのコストは代替案を上回っていますか？

よくある質問

vLLMの継続的バッチ処理では、すべてのリクエストが直ちに実行されますか？

いいえ。新規到着リクエストはスケジューリング・ステップで考慮されますが、トークン予算、シーケンス・スロット、KVキャッシュ容量の空きを待つ場合があります。対話型レイテンシーの目標を約束する前に、実行中および待機中のゲージをキュー時間ヒストグラムとともに確認してください。

vLLMの継続的バッチ処理は、チャンク化prefillと同じですか？

いいえ。継続的バッチ処理は、リクエストが時間の経過とともにスケジュールされた処理に参加・離脱する方法を表します。チャンク化prefillは、長いプロンプトのprefill処理を分割し、ステップ間でトークン予算を共有できるようにします。現在のスケジューラでは両者は連携して動作しますが、一方のチューニング・ノブを調整しても、もう一方を測定する代わりにはなりません。

バッチサイズを最大化すべきですか？

必ずしもそうではありません。バッチを大きくするとスループットは向上する場合がありますが、キュー時間、初回トークンまでの時間、またはプリエンプション圧力が増加する可能性があります。同じ投入負荷で同じトレースを実行し、障害と受け入れられたレスポンスあたりのコストを含む、サービス目標全体を比較してください。

vLLMの継続的バッチ処理はベンチマーク結果ではなく、スケジューリング手法です。最も優れたセットアップとは、スループット、レイテンシー、メモリ動作、障害モードを、自身の測定値に基づいて説明できるものです。