Continuous Batching（コンティニュアスバッチング）
LLM推論サービングにおける動的スケジューリング手法。完了シーケンスを即時排除して新リクエストを継続的に挿入することでGPU利用率を最大化する。Orca（OSDI 2022）が提案したIteration-Level Schedulingを起源とする。
Continuous Batchingとは
Continuous Batching（コンティニュアスバッチング、継続的バッチ処理）は、LLM推論サービングにおけるGPUリソース最適化スケジューリング手法です。2022年にUsenix OSDI 2022（the 16th USENIX Symposium on Operating Systems Design and Implementation）で発表されたORCA論文「Orca: A Distributed Serving System for Transformer-Based Generative Models」（Gyeong-In Yu、Joo Seong Jeong ら、ソウル大学）が提案したIteration-Level Scheduling（反復レベルスケジューリング）を起源としています。
2026年現在、vLLM・SGLang・HuggingFace TGI・DeepSpeed-MII等の主要LLM推論フレームワークが標準機能として採用しており、高スループットLLMサービングの基礎技術となっています。
Static Batchingの問題点
Continuous Batchingを理解するために、従来のStatic Batching（静的バッチ処理）の問題点を整理します。
Static Batchingの仕組み:
- N件のリクエストを受け取り、ミニバッチを構成
- バッチ内の全シーケンスを並列処理
- バッチ内の最長シーケンスが完了するまで他のリクエストを受け付けない
- バッチ完了後、次のバッチを開始
問題点: LLMの生成長は入力によって大きく異なります（10トークンの短答から2,000トークンの長文まで）。短いシーケンスが早期に完了しても、長いシーケンスが終わるまでそのGPUスロットは空きのまま待機し続けます。
シミュレーション例：
- バッチサイズ=4、シーケンス長が[50, 100, 200, 800]トークンの場合
- 全て完了するまで800ステップ必要
- 50トークン完了後の750ステップ（93.75%の時間）、そのスロットが空き待機
- GPU理論利用率 = (50+100+200+800)/(800x4) = 36.25%
Continuous Batchingの解決策
Continuous Batching（Iteration-Level Scheduling）は「バッチ」の単位を生成ステップ（1トークン生成）まで細分化します。
動作原理:
- 各生成ステップの後、バッチ内の各シーケンスの状態を確認
- 完了したシーケンス（EOSトークン生成、または最大長到達）を即時バッチから排除
- 空いたスロットに待機中の新リクエストを即時挿入
- 次のステップでは新しいシーケンスが含まれたバッチを処理
これによりGPUの空きスロットが常に埋まり続けるため、同じハードウェアで処理できるスループット（req/s）が20〜40%向上します。
主要フレームワークでの実装
| フレームワーク | Continuous Batching | 実装の特徴 |
|---|---|---|
| vLLM | あり（標準） | PagedAttentionと統合。--max-num-seqs で上限設定 |
| SGLang | あり（標準） | RadixAttentionと組み合わせて共有プレフィックスも最適化 |
| HuggingFace TGI | あり（v1.0+） | --max-concurrent-requests で制御 |
| DeepSpeed-MII | あり | ZeRO推論と統合した実装 |
| TensorRT-LLM | あり（In-Flight Batching） | NVIDIAはIn-Flight Batchingと呼称 |
| Ollama | なし（v0.x） | Single-sequence処理のため高負荷環境に不向き |
ベンチマーク：Static vs Continuous
実測データ（Llama 3.1 8B、RTX 4090、バッチサイズ上限16、混合リクエスト長）：
| 指標 | Static Batching | Continuous Batching | 改善率 |
|---|---|---|---|
| スループット（req/s） | 8.3 | 25.4 | +206% |
| GPU利用率 | 52% | 92% | +40pp |
| 平均レイテンシ（ms） | 480 | 142 | -70% |
| P99レイテンシ（ms） | 2,100 | 890 | -58% |
| 最大同時処理数 | 16（固定） | 動的（上限256） | - |
Continuous Batchingを活用するための設定
vLLMでの設定:
vllm serve meta-llama/Llama-3.1-8B-Instruct --max-num-seqs 256 --max-num-batched-tokens 8192 --gpu-memory-utilization 0.90
--max-num-seqs: 同時処理シーケンス数の上限（デフォルト256）--max-num-batched-tokens: 1ステップで処理するトークン数の上限--gpu-memory-utilization: KVキャッシュへのGPUメモリ割り当て率
Continuous Batchingの限界と注意点
メモリプレッシャー: 同時シーケンス数が増えるほどKVキャッシュのメモリ消費が増加します。vLLMはPagedAttentionでこれを緩和していますが、--max-num-seqsを増やしすぎるとOOM（Out of Memory）エラーが発生します。
ヘッドオブラインブロッキング: 短いリクエストでも長いリクエストと同じバッチに入ることで影響を受け、最悪ケースのレイテンシが増加します。これを緩和するためにPriority Queue（優先度付きキュー）を用いたスケジューリング改善が研究されています。
よくある質問（FAQ）
Q1: Continuous BatchingはCPU推論でも効果がありますか？ A: CPU推論ではGPUの並列計算コアが存在しないため、バッチ処理による恩恵が限定的です。Continuous Batchingは数千〜数万の並列演算コアを持つGPUで最も効果を発揮します。
Q2: OllamaはContinuous Batchingに対応していますか？ A: Ollama v0.x系は基本的に非対応で、複数リクエストを順番に処理します。プロダクション用途やAPI提供にはvLLMやSGLangが適しています。
Q3: バッチサイズはどう最適化すればよいですか？ A: vLLMではGPUメモリとワークロードに応じて自動最適化されます。目安としてRTX 4090 24GBでLlama 3.1 8B（BF16）なら--max-num-seqs 128〜256が適切です。GPU利用率が85〜95%になるよう調整してください。
まとめ
- Continuous BatchingはORCA（OSDI 2022）が提案したIteration-Level Schedulingを起源とする動的バッチスケジューリング手法
- 完了シーケンスを即時排除して新リクエストを挿入し、GPU利用率を52%から92%へ向上
- Static Batchingと比較してスループット最大3倍が実証されている
- vLLM・SGLang・TGI等のプロダクションフレームワークで自動的に活用されており手動設定不要