Continuous Batching（コンティニュアスバッチング）
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%に向上する。
主な特徴・仕組み
- Iteration-Level Scheduling: 1トークン生成ごとにバッチ構成を見直し、完了済みリクエストを排出・新規リクエストを投入。スケジューリングオーバーヘッドは1イテレーションあたり約0.1ms
- Preemption対応: 長時間実行中のリクエストを一時中断し、優先度の高い短いリクエストを先に処理するプリエンプション機能。SLO（レイテンシ目標）管理に有効
- GPU利用率最大化: Static Batchingの30〜50%から80〜95%にGPU稼働率を向上。同一ハードウェアでのスループットが2〜5倍改善
- 可変長シーケンス対応: バッチ内の各リクエストが異なる入力長・出力長を持つ場合でも効率的に処理。パディング無駄を排除
- 動的バッチサイズ: リクエスト流量に応じてバッチサイズを自動調整。ピーク時は最大バッチサイズまで拡張、閑散時は最小構成に縮小
- メモリ管理との連携: PagedAttention（vLLM）やInflight Batching（TensorRT-LLM）と組み合わせることで、KVキャッシュの断片化を防ぎつつ動的バッチングを実現
- Token Budget制御: 1バッチ内の合計トークン数に上限（
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分散） | 高い |
具体例・対応製品
- vLLM:
--enable-chunked-prefillフラグでChunked Prefill付きContinuous Batchingを有効化。デフォルトで最大256リクエストの同時バッチに対応 - TGI:
--max-concurrent-requests 128 --max-batch-total-tokens 32768でバッチパラメータを調整。Rust製Routerがイテレーションごとのスケジューリングを担当 - TensorRT-LLM: Inflight Batchingとして実装。
BatchSchedulerクラスがCapacity Schedulerパターンで最適バッチサイズを決定 - NVIDIA Triton Inference Server: バックエンドとしてTensorRT-LLMを使用し、Continuous Batchingをエンタープライズ環境で運用。Kubernetes連携でオートスケール可能
- Amazon SageMaker: LMIコンテナ（Large Model Inference）でContinuous Batchingを標準サポート。マネージドエンドポイントで設定不要
選び方・注意点
- バッチサイズ上限: GPUメモリに応じて
max_batch_total_tokensを適切に設定する。大きすぎるとOOM、小さすぎるとスループット低下 - Prefillとのバランス: 長い入力プロンプト（数千トークン）のPrefill処理は計算コストが高く、生成中のバッチとGPUリソースを競合する。Chunked Prefillの導入を検討
- レイテンシ vs スループット: バッチサイズを大きくするほどスループットは向上するが、個々のリクエストのTime-to-First-Token（TTFT）は増加する。SLOに応じた調整が必要
- プリエンプション戦略: インタラクティブなチャットアプリでは短いレスポンスを優先するShortest-Job-First、バッチ処理ではFIFOが適切
関連用語との違い
Static Batchingは「全リクエスト完了まで待つ」固定バッチ、Continuous Batchingは「完了次第入れ替える」動的バッチ。Chunked Prefillは Continuous Batchingの拡張で、長いPrefill（入力処理）を小さなチャンクに分割してGeneration（生成）フェーズと交互に実行する手法。いずれも本番LLMサービングでは組み合わせて使用するのが一般的。
よくある質問（FAQ）
Q1: Continuous Batchingを有効にするとレイテンシは悪化しますか？ A: 個々のリクエストのレイテンシはバッチサイズに応じてわずかに増加するが、全体のスループットが2〜5倍向上するため、同時リクエスト数が多い本番環境では総合的なユーザー体験が改善する。
Q2: Continuous Batchingはどのモデルサイズで効果がありますか？ A: 7B以上のモデルで顕著な効果。1B以下の小型モデルでは推論自体が高速なためバッチングのオーバーヘッドが相対的に大きく、効果が薄い。
Q3: CPUのみの環境でもContinuous Batchingは使えますか？ A: 原理的には可能だが、CPU推論ではGPU並列計算のメリットが得られないため効果は限定的。GPU環境での利用を前提とした最適化技術である。
まとめ
- Continuous Batchingはリクエスト単位の動的バッチ構成により、GPU利用率を80〜95%に向上
- Static Batchingと比較してスループットが2〜5倍改善し、本番LLMサービングの標準技術
- vLLM、TGI、TensorRT-LLM等の主要推論エンジンに標準実装済み
- Chunked PrefillやPagedAttentionとの組み合わせでさらなる最適化が可能