Continuous Batching

Continuous batching（イテレーションレベルスケジューリングまたはインフライトバッチングとも呼ばれます）は、生成モデルのサービングに使われるスケジューリング手法です。サーバーはデコードの各ステップでバッチを再構成します。シーケンスが終了すると、すぐにバッチから抜けて結果を返し、待機中のリクエストが次のステップでその位置に入ります。ソウル大学校とFriendliAIのGyeong-In Yu氏らは、OSDI 2022で発表したOrcaでこの手法を導入し、同じレイテンシにおいてGPT-3 175BでNVIDIA FasterTransformerより36.9倍高いスループットを報告しました。2023年にvLLMとHugging Face Text Generation Inferenceが採用したことで、continuous batchingという名称が広まり、現在ではサービングエンジンで大規模言語モデル（LLMs）を扱う際のデフォルトのスケジューラーになっています。

リクエスト単位のバッチ処理がGPUを無駄にする理由#

テキスト生成では、フォワードパスごとに1つのtokenが生成されますが、リクエストごとに必要なパス数は大きく異なります。はい／いいえで答える質問は数トークンで終わりますが、コードファイルでは数千トークンに達することがあります。静的バッチ処理では、最も長いリクエストが完了するまでリクエストのグループが一緒に処理されます。早く終わったシーケンスのスロットはアイドル状態になり、新しいリクエストはグループ全体が空くまで待つため、長いリクエストの後ろに並んだ短いリクエストすべてに推論レイテンシが加わります。

NVIDIA Tritonなどのサーバーで使われるリクエスト単位の方式であるDynamic batchingでは、短い時間枠内に到着したリクエストを集め、1つのバッチとして完了まで実行します。これは、画像分類器や物体検出器のように、入力ごとの処理コストが一定のモデルに適しています。各入力が1回のフォワードパスで完了するためです。Ultralytics YOLOのpredictモードは、ソースからYOLO26の入力をリクエスト単位のバッチにまとめます。カメラURLを記載した.streamsファイルを使うと、各ストリームの最新フレームを保持する1つのバッチとして実行されるため、8つのストリームはバッチサイズ8で処理されます。また、batch引数は、動画、ディレクトリ、または.txt画像リストのフレームを1回のフォワードパスにまとめます。

イテレーション単位のスケジューリングの仕組み#

スケジューラーは、アクティブな各シーケンスに対してデコードを1ステップ実行し、終了トークンに達したか、長さ制限に達したかを確認します。完了したシーケンスは返されてメモリが解放され、KVキャッシュに空きがあれば、キュー内のリクエストが追加されます。Orcaは、ほかのシーケンスをデコードするのと同じステップで新しいリクエストのプロンプトを処理（プリフィル）します。現在のエンジンもチャンク化プリフィルで同じ処理を行います。

異なる長さのシーケンスを混在させるには、Orcaが「選択的バッチ処理」と呼ぶもう1つの工夫が必要でした。各トークンを個別に処理する演算（各トランスフォーマーレイヤーでの大規模な行列乗算など）は、すべてのシーケンスの全トークンをまとめて実行されます。各シーケンスにはそれぞれ固有のコンテキスト長があるため、アテンションはシーケンスごとに実行されます。

このシミュレーションでは、同時に4つのシーケンスをデコードするGPUで、同じ8つのリクエストをスケジューリングします。

import heapq

output_lengths = [5, 50, 8, 12, 40, 3, 30, 7]  # tokens each queued request will generate
slots = 4  # sequences the GPU decodes together at each step

# Static batching: each group of 4 runs until its longest request finishes
static_steps = sum(max(output_lengths[i : i + slots]) for i in range(0, len(output_lengths), slots))

# Continuous batching: the next request takes the first slot that frees up
slot_free_at = [0] * slots
for length in output_lengths:
    start = heapq.heappop(slot_free_at)
    heapq.heappush(slot_free_at, start + length)
continuous_steps = max(slot_free_at)

for name, steps in [("static", static_steps), ("continuous", continuous_steps)]:
    print(f"{name}: {steps} decode steps, slots busy {sum(output_lengths) / (steps * slots):.0%}")

静的バッチ処理ではデコードに90ステップ必要で、スロットの稼働率は43%です。Continuous batchingでは、最長のリクエストの長さにあたる50ステップで処理が完了し、スロットの稼働率は78%になります。

制限と併用する手法#

実行中のバッチを大きくすると総スループットは向上しますが、各ステップにかかる時間が延びるため、出力トークンあたりの時間も増加します。そのため、エンジンは同時実行するシーケンス数と、1ステップで処理するトークン数に上限を設けています。vLLMではそれぞれmax_num_seqsとmax_num_batched_tokensとして公開されています。また、continuous batchingは次の関連手法と組み合わせて使われます。

• PagedAttention：KVキャッシュを小さなブロックに分けて割り当てるため、シーケンスが完了するとメモリがすぐに解放され、新しいシーケンスは使用する分だけを確保します。
• チャンク化プリフィル：長いプロンプトを分割し、新しいリクエストのプリフィルによって、ほかのリクエストのデコードが停止しないようにします。
• 投機的デコード：大規模なcontinuous batchではGPUの計算能力がすでにほぼ使い切られているため、バッチサイズが小さい場合に最も効果を発揮します。