Dynamic Batching（動的バッチング）とは、推論リクエストの到着パターンに応じてバッチサイズと構成タイミングを動的に調整するバッチング手法である。NVIDIA Triton Inference Serverが代表的な実装であり、最大バッチサイズ（max_batch_size）と最大遅延時間（max_queue_delay_microseconds）の2つのパラメータでバッチ構成を制御する。LLM専用のContinuous Batchingとは異なり、画像認識・音声認識・埋め込み生成など幅広い推論モデルに適用できる汎用的なバッチング技術である。
Dynamic Batching（動的バッチング）は、推論サーバーがクライアントから到着するリクエストを一定の条件に基づいてグループ化し、バッチとしてまとめてモデルに投入する技術である。固定サイズのバッチを事前に構成するStatic Batchingとは異なり、リアルタイムのリクエスト到着率とレイテンシ要件に応じてバッチサイズを動的に変化させる点が特徴である。
Dynamic Batchingの基本的な動作原理は以下の通りである。推論サーバーはリクエストキューを保持し、新しいリクエストが到着するたびにキューに追加する。バッチの送出条件は「キュー内のリクエスト数がmax_batch_sizeに達した」または「最初のリクエストがキューに入ってからmax_queue_delay時間が経過した」のいずれかが満たされた時点でトリガーされる。これにより、高負荷時はバッチサイズが大きくなりスループットが向上し、低負荷時は遅延時間の上限でバッチが送出されレイテンシが保証される。
NVIDIA Triton Inference ServerはDynamic Batchingの最も成熟した実装を提供しており、マルチモデル環境での同時推論、GPUメモリの共有管理、モデルアンサンブルのパイプライン処理など高度な機能を備えている。
Dynamic Batchingの動作は主に以下のパラメータで制御される。
| パラメータ | 説明 | 典型的な設定値 | 影響 |
|---|---|---|---|
| max_batch_size | 1バッチの最大リクエスト数 | 8〜128 | スループット ↔ メモリ |
| max_queue_delay_microseconds | バッチ構成の最大待機時間 | 100〜100,000μs | レイテンシ ↔ バッチ効率 |
| preferred_batch_size | 優先的に構成するバッチサイズ | [4, 8, 16] | GPU効率の最適化 |
| preserve_ordering | リクエスト順序の保持 | true/false | 順序保証 ↔ スループット |
| priority_levels | 優先度レベル数 | 1〜3 | SLA管理の粒度 |
| default_priority_level | デフォルトの優先度 | 1 | キュー管理の基準 |
max_queue_delay_microsecondsは、レイテンシとスループットのトレードオフを直接制御する最重要パラメータである。値が小さいほどレイテンシは低下するが、バッチサイズが小さくなりGPU利用率が下がる。値が大きいほどバッチが充填されやすくスループットが向上するが、最初にキューに入ったリクエストのレイテンシが増加する。
preferred_batch_sizeを設定すると、GPUカーネルの実行効率が高いバッチサイズ（通常は2のべき乗）を優先的に使用するようになる。例えば[4, 8, 16]と設定した場合、キュー内のリクエスト数が4、8、16に達した時点で即座にバッチが送出される。これにより、GPUのテンソルコアを効率的に利用できる。
Triton Inference Serverでは、モデルの設定ファイル（config.pbtxt）でDynamic Batchingを有効化する。基本的な設定例を以下に示す。
設定ファイルでは、dynamic_batchingブロックを追加し、preferred_batch_sizeとmax_queue_delay_microsecondsを指定する。instanceGroupでGPUインスタンス数を設定し、複数のモデルインスタンスを同一GPUまたは複数GPUで実行できる。
Tritonのモデルアンサンブル機能を使用すると、テキスト前処理→埋め込み生成→ベクトル正規化といったパイプラインを単一のDynamic Batchingの制御下で実行できる。各ステージのバッチ処理が統合的に管理されるため、ステージ間のデータ転送オーバーヘッドが最小化される。
Dynamic BatchingとContinuous Batchingは、対象とするモデルの特性に応じて使い分ける必要がある。
| 比較項目 | Dynamic Batching | Continuous Batching |
|---|---|---|
| 対象モデル | 汎用（CNN、Transformer Encoder等） | 自己回帰LLM特化 |
| バッチ粒度 | リクエスト単位 | イテレーション（トークン）単位 |
| 入出力形状 | 固定形状が理想的 | 可変長シーケンス対応 |
| メモリ管理 | バッチ単位の確保・解放 | PagedAttentionによるページ管理 |
| プリエンプション | なし（一般的に不要） | あり（メモリ不足時） |
| 適用例 | 画像分類、埋め込み生成、音声認識 | テキスト生成、チャット、翻訳 |
| 主要実装 | Triton Inference Server | vLLM、TGI |
| スケーリング | マルチモデル・マルチGPU | テンソル/パイプライン並列 |
Dynamic Batchingは入出力の形状が固定的で、推論時間がリクエスト間でほぼ均一なモデルに最適である。画像分類モデル（ResNet等）や埋め込み生成モデル（sentence-transformers等）では、全リクエストの推論時間がほぼ同じであるため、バッチ内のストラグラー問題が発生しにくい。
一方、LLMのテキスト生成では出力長がリクエストごとに大きく異なるため、Dynamic Batchingではバッチ内で短い生成のリクエストがGPUリソースを浪費する。Continuous Batchingはこの問題をイテレーションレベルのスケジューリングで解決している。
LLMアプリケーションにおいてDynamic Batchingが最も効果を発揮するユースケースの一つが、ベクトル埋め込みの生成である。RAG（Retrieval-Augmented Generation）パイプラインでは、大量のドキュメントチャンクをベクトル化する処理が必要であり、Dynamic Batchingによる効率化が直接的にコスト削減につながる。
| ユースケース | モデル例 | バッチサイズ目安 | 期待スループット |
|---|---|---|---|
| ドキュメント埋め込み | E5-large-v2 | 32〜128 | 500〜2,000文/秒 |
| クエリ埋め込み | BGE-base | 16〜64 | 1,000〜5,000文/秒 |
| マルチモーダル埋め込み | CLIP ViT-L | 16〜64 | 200〜800画像/秒 |
| リランキング | Cross-Encoder | 8〜32 | 100〜500ペア/秒 |
Triton Inference Serverを用いた埋め込み生成パイプラインでは、テキストのトークナイゼーション、モデル推論、ベクトル正規化の3ステージをモデルアンサンブルとして構成する。各ステージがDynamic Batchingで独立に最適化されるため、パイプライン全体のスループットが最大化される。
実運用環境では、単一の推論サーバーで複数のモデルを同時にホストする「マルチテナント」構成が一般的である。Triton Inference Serverは各モデルに独立したDynamic Batching設定を適用でき、GPUメモリの共有管理と動的なモデルロード・アンロードに対応している。
マルチモデル環境でのGPUリソース配分は以下の戦略で管理する。
max_queue_delayの設定は、SLA要件とスループット目標のバランスで決定する。リアルタイム推論API（p99レイテンシ100ms以下）では100〜1,000μs程度に設定し、バッチ効率よりもレイテンシを優先する。バッチ処理パイプライン（レイテンシ許容1秒以上）では10,000〜100,000μsに設定し、バッチ充填率を高めてスループットを最大化する。実運用では負荷テストを実施し、目標レイテンシを維持できる最大のdelay値を求めるのが標準的なアプローチである。また、preferred_batch_sizeと組み合わせることで、GPU効率が高いバッチサイズに到達した時点で即座にバッチを送出しつつ、到達しない場合はdelay時間で送出するハイブリッド戦略が有効である。
可能であり、実際のLLMアプリケーションでは組み合わせが一般的である。例えばRAGパイプラインでは、埋め込み生成（エンコーダーモデル）にはTritonのDynamic Batchingを使用し、テキスト生成（デコーダーモデル）にはvLLMのContinuous Batchingを使用する。両者を統合するアーキテクチャとして、Tritonの「BLS（Business Logic Scripting）」機能を使ってvLLMバックエンドと連携させる方法や、マイクロサービスアーキテクチャで各サービスに最適なバッチング方式を採用する方法がある。重要なのは、モデルの推論特性（固定長出力か可変長出力か）に基づいて適切なバッチング方式を選択することである。
不均一なバッチサイズはGPUのテンソルコアの利用効率に影響を与える。GPUのテンソルコアは行列演算を8の倍数（A100の場合）や16の倍数（H100の場合）で効率的に処理するため、バッチサイズが中途半端な値になるとパディングが発生し計算効率が低下する。preferred_batch_sizeパラメータで効率的なバッチサイズ（2のべき乗や8の倍数）を指定することで、この問題を軽減できる。ただし、preferred_batch_sizeへの到達を待つことで遅延が増加する場合もあるため、実際の負荷パターンでベンチマークを取り最適なバランスを見つけることが重要である。
Sequence Batching（シーケンスバッチング）は、ステートフルなモデル（RNN、LSTM、ストリーミング音声認識モデル等）で使用されるバッチング方式である。Dynamic Batchingが各リクエストを独立した推論として扱うのに対し、Sequence Batchingは同一セッション（シーケンス）の連続リクエストを同一のモデルインスタンスにルーティングし、内部状態を維持する。Triton Inference Serverでは、sequence_batchingブロックで設定し、correlation_idでセッションを識別する。LLMのテキスト生成ではKVキャッシュが内部状態に相当するが、Continuous Batchingがこの管理を専門的に最適化しているため、LLM用途ではSequence BatchingよりもContinuous Batchingが推奨される。