Continuous Batching (2022)（コンティニュアスバッチング2022）
Yu ら ORCA 2022年 LLM 推論バッチング革新。生成途中のリクエストを動的にバッチ再配置→スループット 5-10倍向上
概要
Continuous Batching（連続バッチング、In-Flight Batching とも呼ばれる）は 2022年7月に韓国 Seoul National University の Gyeong-In Yu・Joo Seong Jeong ら 5名が OSDI 2022（USENIX Symposium on Operating Systems Design and Implementation）で発表した LLM 推論バッチング革新手法（論文「ORCA: A Distributed Serving System for Transformer-Based Generative Models」）。
従来 Static Batching（静的バッチング）は同じバッチ内のリクエスト全てが生成完了するまで待つため、短文応答（10 tokens）と長文応答（500 tokens）が同じバッチに入ると短文も長文完了まで GPU 浪費する問題があった。Continuous Batching は生成完了したリクエストを即座にバッチから除去し、新しいリクエストを動的に追加することで GPU 使用率を最大化、スループット 5-10倍 向上。
vLLM (UC Berkeley 2023)・HuggingFace TGI (2023)・NVIDIA TensorRT-LLM (2023)・SGLang (LMSYS 2024) 等の全ての主要 LLM 推論サーバが採用し、現代 LLM サービング基盤の事実上標準アルゴリズム。
主な特徴・仕組み
- 動的バッチ管理: 生成完了 → 即除去、新リクエスト → 即追加、GPU アイドル時間ゼロ化
- Iteration-level Scheduling: 各 step（トークン生成 1回）毎にバッチ再構成
- Selective Batching: prefill (プロンプト処理) と decoding (生成) を別バッチで実行
- KV キャッシュ管理: 各リクエストの KV キャッシュをメモリプールで動的割当
- スループット向上: 静的バッチ比 5-10倍（短文と長文混在シナリオで顕著）
- レイテンシ低下: P99 レイテンシ 30-60% 削減
- GPU 使用率: 静的バッチ 30-50% → Continuous 80-95%
- 対応モデル: GPT・Llama・Mistral・Mixtral・Falcon 全 Transformer 系列
- OS バージョン: ORCA 論文 v1 (2022-07 OSDI)・各サーバ独自実装で進化
スペック比較表
| 項目 | Continuous Batching (2022) | Static Batching | Dynamic Batching | PagedAttention 連携 |
|---|---|---|---|---|
| バッチ動的更新 | 各 iteration | バッチ完了まで | バッチ作成時 | 各 iteration |
| GPU 使用率 | 80-95% | 30-50% | 50-70% | 90-95% |
| スループット向上 | 5-10x (vs Static) | baseline | 2-3x | 7-15x |
| P99 レイテンシ | 30-60% 削減 | baseline | 20-30% 削減 | 40-70% 削減 |
| 採用サーバ | vLLM, TGI, TRT-LLM | 旧 PyTorch Serve | NVIDIA Triton | vLLM 標準 |
具体例・対応製品
- vLLM (UC Berkeley 2023-06): Continuous Batching + PagedAttention、業界標準
- HuggingFace TGI (2023-04): Text Generation Inference、Rust 実装
- NVIDIA TensorRT-LLM (2023-10): In-Flight Batching として実装
- SGLang (LMSYS 2024-01): RadixAttention + Continuous Batching
- NVIDIA Triton Inference Server: Dynamic Batching を拡張して Continuous 対応
選び方・注意点
- 現代 LLM サーバでは標準: 新規構築ならContinuous Batching 対応必須、Static は時代遅れ
- スループット重視シナリオ: バッチ 8 以上で効果大、低負荷 (バッチ 1-2) では差小
- KV キャッシュ管理重要: PagedAttention (vLLM) や RadixAttention (SGLang) 等と組合せで最大効果
- prefill vs decoding 分離: 高度実装は両者を別バッチで並列実行 (chunked prefill)
- 公平性問題: 長文リクエストが短文を圧迫しないよう scheduling policy 重要
- monitoring 困難: バッチ構成が動的に変わるため per-request latency 追跡が複雑
- memory fragmentation: KV キャッシュの動的割当でフラグメント化、PagedAttention で解決
関連用語との違い
| 用語 | 違い |
|---|---|
| Continuous Batching (2022) | 動的バッチ再配置・iteration 単位 |
| FlashAttention-2 (2023) | attention 計算ライブラリ |
| TensorRT-LLM (2023) | NVIDIA 専用推論スタック (Continuous 含む) |
| GGUF Quantization (2023) | llama.cpp 量子化フォーマット |
| BitNet (2024) | 1.58-bit 学習量子化 |
よくある質問（FAQ）
Q1: 静的バッチングとの違いは？ A: 静的は同じバッチ全リクエスト完了まで待つ（短文も長文完了まで GPU 浪費）、Continuous は完了即除去 + 新規即追加。短文/長文混在シナリオで GPU 使用率 30-50% → 80-95% に劇的改善。
Q2: PagedAttention とどう違う？ A: 別レイヤーの最適化。Continuous Batching は「バッチをいつ更新するか」、PagedAttention は「KV キャッシュをどう管理するか」。両者を組合せると vLLM の標準構成 (バッチ動的更新 + KV ページング) になる。
Q3: 低負荷時のメリットは？ A: バッチ 1-2 では効果小、バッチ 8-32 で 5-10倍、バッチ 64+ で 10-15倍。本番サービス（同時 100+ リクエスト）では必須技術、開発/テスト環境では差を感じにくい。
まとめ
- Seoul National University 2022年7月 OSDI 発表・ORCA システム
- 動的バッチ再配置で GPU 使用率 30-50% → 80-95%
- スループット 5-10倍向上・P99 レイテンシ 30-60% 削減
- vLLM・TGI・TensorRT-LLM・SGLang 全主要サーバ採用
- 現代 LLM サービング基盤の事実上標準アルゴリズム