LLM推論において、リクエストの到着・完了に応じてバッチを動的に構成し直す手法で、GPU稼働率を最大化しスループットを2〜5倍向上させるサービング最適化技術
Continuous Batching（連続バッチング、動的バッチングとも呼ばれる）は、LLMの推論サービングにおいてリクエストを動的にバッチへ追加・除外するスケジューリング手法である。従来のStatic Batching（静的バッチング）では、バッチ内の全リクエストが生成完了するまで新しいリクエストを受け付けられず、短い応答が先に完了してもGPUが遊休状態になる問題があった。Continuous Batchingはこの非効率を解消し、2026年現在の主要なLLM推論エンジン（vLLM、TGI、TensorRT-LLM）全てに標準実装されている。
Continuous Batchingの概念は、2023年にOrcaシステム（Microsoftの研究）で体系化された。その論文「Orca: A Distributed Serving System for Transformer-Based Generative Models」で提案されたIteration-Level Schedulingが、現在のContinuous Batchingの基盤となっている。
従来のStatic Batchingでは、バッチサイズ8のリクエストグループにおいて、最短20トークンのリクエストと最長512トークンのリクエストが混在すると、20トークンのリクエストが完了した後もバッチ全体の完了を待つ必要があった。この結果、GPU利用率は平均30〜50%程度に留まっていた。Continuous Batchingでは、各イテレーション（1トークン生成ごと）にスケジューリング判定を行い、完了したリクエストの枠に即座に新しいリクエストを投入する。これによりGPU利用率は80〜95%に向上する。
max_batch_total_tokens）を設定し、OOM（Out of Memory）を防止| バッチング方式 | GPU利用率 | スループット | レイテンシ | 実装の複雑さ |
|---|---|---|---|---|
| Static Batching | 30〜50% | 基準（1x） | 高い（最長リクエストに律速） | 低い |
| Continuous Batching | 80〜95% | 2〜5x | 低い（個別完了） | 中程度 |
| Chunked Prefill | 85〜95% | 3〜6x | 最低（Prefill分散） | 高い |
--enable-chunked-prefill フラグでChunked Prefill付きContinuous Batchingを有効化。デフォルトで最大256リクエストの同時バッチに対応--max-concurrent-requests 128 --max-batch-total-tokens 32768 でバッチパラメータを調整。Rust製Routerがイテレーションごとのスケジューリングを担当BatchScheduler クラスがCapacity Schedulerパターンで最適バッチサイズを決定max_batch_total_tokens を適切に設定する。大きすぎるとOOM、小さすぎるとスループット低下Static Batchingは「全リクエスト完了まで待つ」固定バッチ、Continuous Batchingは「完了次第入れ替える」動的バッチ。Chunked Prefillは Continuous Batchingの拡張で、長いPrefill（入力処理）を小さなチャンクに分割してGeneration（生成）フェーズと交互に実行する手法。いずれも本番LLMサービングでは組み合わせて使用するのが一般的。
Q1: Continuous Batchingを有効にするとレイテンシは悪化しますか？ A: 個々のリクエストのレイテンシはバッチサイズに応じてわずかに増加するが、全体のスループットが2〜5倍向上するため、同時リクエスト数が多い本番環境では総合的なユーザー体験が改善する。
Q2: Continuous Batchingはどのモデルサイズで効果がありますか？ A: 7B以上のモデルで顕著な効果。1B以下の小型モデルでは推論自体が高速なためバッチングのオーバーヘッドが相対的に大きく、効果が薄い。
Q3: CPUのみの環境でもContinuous Batchingは使えますか？ A: 原理的には可能だが、CPU推論ではGPU並列計算のメリットが得られないため効果は限定的。GPU環境での利用を前提とした最適化技術である。