LLMバッチ処理（バッチ推論）とは、大規模言語モデルに対する複数の推論リクエストをまとめて一括処理する技術である。個別リクエストを逐次処理するオンライン推論と異なり、リクエストをキューに蓄積してGPUの並列計算能力を最大限に活用することで、スループットの大幅な向上とコスト削減を実現する。AnthropicやOpenAIが提供するBatch APIでは最大50%のコスト削減が可能であり、大量データの分類・要約・翻訳などの非リアルタイム処理に広く活用されている。
LLMバッチ処理（Batch Inference）は、大規模言語モデル（LLM）への推論リクエストを個別に処理するのではなく、複数のリクエストをまとめてGPUに投入し一括で推論する技術である。リアルタイム応答が不要なユースケースにおいて、GPUの計算リソースを効率的に活用し、推論コストを大幅に削減できる。
オンライン推論（リアルタイム推論）では、ユーザーからのリクエストが到着するたびに即座にモデルを実行して結果を返す。一方、バッチ推論では数百から数百万のリクエストをキューに蓄積し、GPUのSIMD（Single Instruction, Multiple Data）アーキテクチャを活かして並列実行する。この違いにより、バッチ推論はオンライン推論と比較してスループットが5〜20倍向上し、リクエストあたりのコストは50〜80%削減される。
バッチ処理が特に有効なユースケースには、大規模コーパスの文書要約、多言語翻訳、感情分析・分類タスク、データセットのアノテーション、合成データ生成などがある。これらはレイテンシ要件が緩く、スループットとコスト効率が重視される。
リアルタイム推論とバッチ推論の特性を理解することは、適切なアーキテクチャ選定の基盤となる。
| 比較項目 | オンライン推論 | バッチ推論 |
|---|---|---|
| レイテンシ | 低い（100ms〜数秒） | 高い（分〜時間単位） |
| スループット | 低い（GPU利用率30〜60%） | 高い（GPU利用率80〜95%） |
| コスト効率 | 低い（アイドル時間が多い） | 高い（リソース利用を最大化） |
| スケーリング | オートスケール必須 | 固定リソースで予測可能 |
| 適用場面 | チャットbot、リアルタイム翻訳 | データパイプライン、分析 |
| SLA | p99レイテンシ保証 | 完了時間のSLA |
| エラー処理 | 即座にリトライ |
| バッチ単位でリトライ可能 |
| GPU利用効率 | 低い（リクエスト間にアイドル） | 高い（連続的にGPU占有） |
バッチ推論の最大の利点は、GPUのアイドル時間を最小化できることにある。オンライン推論ではリクエスト間の待ち時間にGPUが遊んでしまうが、バッチ推論では常に次のリクエストが待機しているため、GPU利用率を90%以上に維持できる。
LLMバッチ処理を支える技術スタックは、サービングエンジン、バッチングアルゴリズム、メモリ管理の3層で構成される。
現在主流のLLMサービングエンジンは以下の通りである。
| エンジン | 開発元 | バッチ方式 | 主な特徴 |
|---|---|---|---|
| vLLM | UC Berkeley | Continuous Batching | PagedAttention、高スループット |
| TGI | Hugging Face | Continuous Batching | Flash Attention、Rust実装 |
| TensorRT-LLM | NVIDIA | Inflight Batching | TensorRTカーネル最適化 |
| Triton Inference Server | NVIDIA | Dynamic Batching | マルチモデル対応 |
| SGLang | Stanford | RadixAttention | プログラマブルなバッチ制御 |
バッチングの方式には大きく3つのアプローチがある。
LLMのバッチ推論においてKVキャッシュのメモリ管理は最大のボトルネックとなる。PagedAttention（vLLM）は仮想メモリのページング機構をKVキャッシュに適用し、メモリの断片化を解消した画期的な手法である。従来の連続メモリ割り当てでは、最大シーケンス長分のメモリを事前に確保する必要があり、実際の使用率は20〜40%に留まっていた。PagedAttentionにより、メモリ利用効率は90%以上に改善された。
主要なLLMプロバイダが提供するBatch APIは、バッチ推論をマネージドサービスとして利用できる手段である。
| プロバイダ | API名 | コスト削減 | 最大リクエスト数 | 完了時間SLA |
|---|---|---|---|---|
| Anthropic | Message Batches API | 50% | 100,000/バッチ | 24時間以内 |
| OpenAI | Batch API | 50% | 50,000/バッチ | 24時間以内 |
| Vertex AI Batch Prediction | 30〜50% | カスタム | カスタム | |
| AWS | Bedrock Batch Inference | 変動 | カスタム | カスタム |
Anthropic Message Batches APIの利用手順は以下の通りである。
/v1/messages/batches エンドポイントにPOSTでバッチを作成OpenAI Batch APIも同様のワークフローで、.jsonlファイルをアップロードし、/v1/batchesエンドポイントでバッチジョブを作成する。いずれも通常のAPI料金の50%で利用可能であり、24時間以内の完了が保証される。
大規模バッチ処理システムの設計にはいくつかの定番パターンがある。
メッセージキュー（Redis Queue、Amazon SQS、Apache Kafka）を介してリクエストを蓄積し、ワーカープロセスがバッチ単位で消費する。プロデューサーとコンシューマーの分離により、負荷変動への対応が容易になる。
大量のドキュメントを分割（Map）し、各チャンクに対して並列にLLM推論を実行した後、結果を集約（Reduce）する。文書要約やデータ抽出のパイプラインで広く使われる。
リクエストに優先度を付与し、高優先度のリクエストを低レイテンシで処理しつつ、低優先度のリクエストはバッチにまとめてコスト効率重視で処理する。SLAの異なる複数のクライアントを単一のインフラで処理する場合に有効である。
バッチ推論のパフォーマンスを最適化するための主要パラメータを以下にまとめる。
| パラメータ | 説明 | 推奨値 | 影響 |
|---|---|---|---|
| max_batch_size | 同時処理リクエスト数 | GPU VRAM依存（8〜256） | スループット↑、レイテンシ↑ |
| max_waiting_tokens | バッチ構成の待機トークン数 | 20〜100 | バッチ効率↑、初回レイテンシ↑ |
| max_input_length | 入力の最大トークン長 | モデル依存 | メモリ使用量に直結 |
| max_total_tokens | 入出力合計の最大トークン長 | モデル依存 | KVキャッシュサイズに直結 |
| gpu_memory_utilization | GPU VRAM使用率上限 | 0.85〜0.95 | OOM回避とスループットのバランス |
| tensor_parallel_size | テンソル並列度 | GPU数に合わせる | 大型モデルの分散推論 |
バッチサイズの最適化は、GPU VRAMとモデルサイズの関係から決定される。例えばLlama 3.1 70Bモデル（FP16）をA100 80GB×4で実行する場合、テンソル並列度4でモデルが約140GBのVRAMを占有し、残りの約180GBがKVキャッシュに充当される。4096トークンのシーケンスでは、1リクエストあたり約1.3GBのKVキャッシュが必要となるため、最大バッチサイズは約128〜140程度が目安となる。
バッチ推論は、リアルタイム応答が不要で大量のリクエストを処理する必要がある場合に最適である。具体的には、大規模データセットの分類・ラベリング、文書の一括要約、多言語翻訳パイプライン、合成データ生成、定期的なレポート生成、RAG用のドキュメント前処理（チャンク分割・埋め込み生成）などが代表的なユースケースである。24時間以内の完了で許容される処理であれば、クラウドプロバイダのBatch APIを使うことで50%のコスト削減が見込める。
バッチサイズの決定にはGPU VRAM容量、モデルサイズ、入出力トークン長の3要素を考慮する必要がある。まずモデルの重みが占有するVRAM量を算出し（パラメータ数×データ型のバイト数）、残りのVRAMからKVキャッシュに割り当て可能な容量を計算する。1リクエストあたりのKVキャッシュサイズは「レイヤー数×2（Key+Value）×ヘッド数×ヘッド次元×シーケンス長×データ型バイト数」で求められる。実際にはPagedAttentionのオーバーヘッドや活性化メモリも考慮し、gpu_memory_utilizationを0.90程度に設定して安全マージンを確保するのが一般的である。
Continuous BatchingはStatic Batchingと比較して、スループットが2〜8倍向上することが実験的に確認されている。この差はリクエストの生成長のばらつきが大きいほど顕著になる。Static Batchingではバッチ内の最も長い生成が完了するまで全リクエストがGPUを占有し続けるため、短い生成のリクエストが終了後もGPUリソースが無駄になる。Continuous Batchingではイテレーション単位で完了したリクエストを解放し新しいリクエストを投入できるため、GPU利用率を常に高く維持できる。vLLMの論文では、同一ハードウェアでStatic Batchingの最大23倍のスループットを達成した事例が報告されている。
バッチ推論のエラー処理は、エラーの種類に応じて戦略を分ける。OOM（Out of Memory）エラーはバッチサイズを縮小してリトライする。タイムアウトエラーはmax_tokensを確認し、必要に応じて入力を短縮する。APIレートリミットエラーは指数バックオフでリトライする。Anthropic Message Batches APIでは、バッチ内の個別リクエストが失敗しても他のリクエストは正常に処理される。失敗したリクエストのみを新しいバッチとして再送信する「部分リトライ」パターンが推奨される。