導入
「せっかく高価なGPUインスタンスを確保したのに、nvidia-smiで確認すると利用率（Utilization）が20%前後を行ったり来たりしている……」
ITコンサルティングやプロジェクトマネジメントの現場では、エンジニアからこうした相談が寄せられることが少なくありません。PoC（概念実証）の段階ではモデルが動くこと自体に感動しますが、いざ本番運用を始めると、この「リソースの無駄」が経営上の大きなボトルネックとして立ちはだかります。クラウド破産という言葉も耳にしますが、GPUコストは決して軽視できるものではありません。
推論サーバーの運用において、常に「低レイテンシ（速い応答）」と「高スループット（大量処理）」という、相反する二つの要求の板挟みになります。応答速度を優先すればGPUの並列処理能力を使い切れず、処理量を優先してリクエストを溜め込めば応答が遅れます。
このジレンマを解消し、GPUのポテンシャルを最大限に引き出す技術こそが「動的バッチング（Dynamic Batching）」です。
ただ、多くの現場ではデフォルト設定のまま使っていたり、なんとなくの数値で運用していたりするのが実情ではないでしょうか。今回は、Triton Inference Serverを主な題材としつつ、「SLA（サービスレベル合意）から逆算する」というアプローチで、論理的にパラメータを決定し、GPU利用率を最大化するための実践的な実装手順を解説します。
感覚値でのチューニングから脱却し、データと論理に基づいた設定で、技術的な実現可能性とビジネス上の成果（コスト効率とパフォーマンス）の両立を目指しましょう。
2. なぜ「動的バッチング」が推論コスト削減の切り札なのか
まず、なぜGPU推論において「バッチング（束ねる処理）」がこれほど重要なのか、その根本的な理由を技術的な側面から整理しておきます。ここを理解することが、後のパラメータ設定の基礎となります。
GPUの並列処理能力と単一リクエストの非効率性
GPU（Graphics Processing Unit）は、もともと大量のデータを同時に処理するために設計されたハードウェアです。そのアーキテクチャは「SIMD（Single Instruction, Multiple Data）」と呼ばれ、一つの命令で複数のデータを同時に処理することに特化しています。
これをAI推論に置き換えてみます。例えば、チャットボットへのユーザーからの質問が1つ届いたとします。これをGPUで処理する場合、GPU内部の数千個あるコアのうち、実際に稼働するのはごく一部です。残りのコアは待機状態になります。さらに深刻なのはメモリ帯域の問題です。GPUはメモリからデータを読み込んで計算する速度が非常に速いのですが、データ量が少ないと、計算そのものよりもデータの転送待ち時間が支配的になってしまいます。
例えるなら、100人乗りの大型バスに、乗客を1人だけ乗せて発車させているようなものです。これでは、どれだけ高速道路を走っても、運べる人数（スループット）は限られており、インフラコストに対する効率は最適とは言えません。
静的バッチと動的バッチの違い
学習フェーズでは、データセットがあらかじめ手元にあるため、効率的なサイズ（例えばバッチサイズ32や64など）にデータを分割して処理する「静的バッチング」が可能です。
しかし、推論サーバーは異なります。ユーザーからのリクエストはいつ来るかわかりません。ここで登場するのが「動的バッチング」です。
動的バッチングは、サーバー側でごく短い時間（数ミリ秒〜数十ミリ秒）だけリクエストを待機させ、その間に到着した複数のリクエストをひとまとめ（バッチ）にしてGPUに送る仕組みです。先ほどのバスの例で言えば、「発車時刻を少しだけ遅らせて、駆け込み乗車の客を待つ」戦略に相当します。
導入で期待できるROI：スループット向上とインスタンス削減
この戦略が適切に機能すれば、劇的な効果が得られます。
- スループットの向上: 一度の推論実行で複数のリクエストを処理できるため、単位時間あたりにさばけるリクエスト数が大幅に増加します。
- コスト削減: スループットが上がれば、同じリクエスト数を処理するために必要なGPUインスタンスの数を減らすことが可能です。例えば、GPU利用率を20%から80%に引き上げることができれば、理論上はサーバー台数を4分の1にできる可能性があります。
実際の画像処理AIのプロジェクトにおいて、適切な動的バッチングの導入により、レイテンシをSLA内に収めつつ、推論サーバーの台数を半分以下に削減できた事例が存在します。これは単なる技術的な最適化ではなく、ビジネスの利益率に直結する重要な経営判断となります。
2. 導入前の現状分析とSLA定義
すぐに動的バッチングを有効化したいところですが、現状の把握とゴールの設定なしにパラメータを変更するのはリスクを伴います。
現状のGPUメトリクス（Utilization, Memory）の正しい読み方
まず、現在のサーバーの状態を正しく診断します。多くの現場で nvidia-smi コマンドが使われますが、ここで表示される GPU-Util （GPU使用率）だけを見て判断するのは早計です。
- GPU Utilization: カーネルが実行されている時間の割合です。「計算ユニットがどれくらい埋まっているか」を示すものではありません。つまり、小さな処理が高頻度で実行されていれば、計算能力自体に余裕があっても使用率は100%と表示されることがあります。
- Memory Usage: モデルの重み（Weights）とKVキャッシュなどで消費されます。動的バッチングを行うと、バッチサイズに比例して中間データのメモリ消費が増えるため、ここには余裕が必要です。
より詳細な分析には、NVIDIAの Nsight Systems や、Tritonのメトリクスエンドポイントから取得できるデータ（Prometheus + Grafana等で可視化）を活用することが推奨されます。特に「Compute Time（計算時間）」と「Queue Time（待ち時間）」の比率に注目してください。
許容レイテンシ（SLA）の明確化
次に、SLA（Service Level Agreement）、つまり「ユーザーに対して保証する応答速度」を定義します。これがパラメータ設計の基準となります。
「できるだけ速く」といった曖昧な目標ではなく、「99パーセンタイル（P99）で200ミリ秒以内」といった具体的な数値が必要です。
- P50（中央値）: 通常時の快適さを示します。
- P99（上位1%）: 高負荷時やエッジケースでの安定性を示します。動的バッチングの文脈では、このP99を守れるかが最大の焦点になります。
モデルサイズと最大バッチサイズの制約確認
最後に、ハードウェア的な限界を確認します。バッチサイズを大きくすればするほどスループットは上がりますが、同時にGPUメモリを消費します。メモリ不足でOOM（Out Of Memory）エラーが発生すればサービス停止につながります。
事前に負荷テストを行い、「最大でバッチサイズをいくつまで上げられるか」の上限値を把握しておくことが、安全な運用のためのガードレールとなります。
3. 実装ステップ①：サービングエンジンの選定と基本設定
ここからは具体的な実装手順に入ります。今回は、NVIDIAが提供するオープンソースの推論サーバーである Triton Inference Server を例に解説しますが、概念は TorchServe や TensorFlow Serving でも応用可能です。
Triton Inference Server vs TorchServe vs FastAPI独自実装
Tritonを推奨する理由は、動的バッチングの実装が極めて洗練されているためです。FastAPIなどでPythonコードとして独自実装することも可能ですが、リクエストのキューイングやスケジューリングをPython側で行うと、GIL（Global Interpreter Lock）の影響などでオーバーヘッドが大きくなりがちです。TritonのようなC++ベースの専用サーバーに任せるのが、高負荷環境では定石とされています。
モデルリポジトリの構成
Tritonでは、モデルごとに設定ファイル config.pbtxt を用意します。ディレクトリ構造は以下のようになります。
model_repository/
my_model/
config.pbtxt
1/
model.onnx (または model.pt など)
config.pbtxtにおけるDynamic Batchingの有効化
動的バッチングを有効にするには、config.pbtxt に以下の記述を追加します。非常にシンプルですが、重要な設定です。
# config.pbtxt の例
name: "my_model"
platform: "onnxruntime_onnx"
max_batch_size: 8
# 動的バッチングの設定セクション
dynamic_batching {
preferred_batch_size: [ 4, 8 ]
max_queue_delay_microseconds: 5000
}
- max_batch_size: このモデルが許容する最大のバッチサイズです。前述のOOMテストに基づいて設定します。
- preferred_batch_size: サーバーが優先的に形成するバッチサイズです。GPUのTensor Coreは8の倍数などで効率よく動くことが多いため、
[4, 8]のように指定します。これにより、リクエストが溜まったとき、可能な限りこのサイズのバッチを作ろうとします。
この設定を入れるだけで、サーバーは自動的にリクエストを束ね始めます。しかし、これだけでは最適化とは言えません。次のステップで、論理的なチューニングを行います。
4. 実装ステップ②：パラメータチューニングの方程式
ここが核心部分です。直感的な数値を入れるのではなく、SLAから逆算して論理的に値を決定します。根拠のない設定はリソースの無駄遣いにつながります。
max_queue_delay_microseconds（最大待機時間）の最適解
max_queue_delay_microseconds は、バッチを作るためにリクエストをキューの中で待たせる最大時間です。これを長くすれば大きなバッチができやすくなり（スループット向上）、短くすれば個別の応答が速くなります（レイテンシ向上）。
この値を決めるための論理的な方程式は以下の通りです。
許容待機時間 = (SLA目標値) - (最大バッチサイズ時の推論実行時間) - (ネットワーク・オーバーヘッド)
例えば、以下のような条件を想定します。
- SLA (P99): 100ms
- ネットワーク往復時間: 約10ms
- バッチサイズ8での推論実行時間: 50ms（事前のベンチマークで計測）
この場合、計算式は次のようになります。100ms - 50ms - 10ms = 40ms
つまり、理論上は 40ms (40,000 microseconds) までなら待たせてもSLAを守れることになります。実際には変動リスクを考慮し、安全マージンを取って 20ms〜30ms 程度に設定するのが現実的です。
この計算を行わず、直感で「1000マイクロ秒（1ms）」などに設定してしまうケースが散見されます。これではリクエストが十分に集まらず、バッチサイズが小さいまま処理が開始され、GPU利用率が上がらない主な原因となります。
タイムアウトとバッチサイズのバランス調整
リクエストの到着頻度が低い場合、設定した待機時間内に preferred_batch_size までリクエストが集まらないことがあります。その場合、Triton Inference Serverなどの推論サーバーは待機時間が経過した時点で、集まった分だけ（例えばバッチサイズ2や3で）推論を実行します。
ここで重要なのは、「待機時間は、バッチサイズ1で即時実行するよりも、待ってバッチ化した方がトータルで得する場合にのみ意味がある」という点です。待つことによる遅延コストを、まとめて処理することによる高速化メリットが上回らなければなりません。これは、スループットとレイテンシのトレードオフを定量的に評価する必要がある領域です。
同時実行数（Instance Group）との兼ね合い
Tritonには instance_group という設定もあり、これは「同じモデルをGPUメモリ上に何個ロードするか」を決めます。
instance_group [
{
count: 2
kind: KIND_GPU
}
]
モデルが軽量でGPUメモリに余裕がある場合、インスタンス数を増やすことで並列処理が可能になります。しかし、動的バッチングと複数インスタンスは競合する可能性がある点に注意が必要です。リクエストが複数のインスタンスに分散してしまうと、各インスタンスでバッチが埋まりにくくなるからです。
基本戦略: まずはインスタンス数1で動的バッチングの効果を最大化し、それでもGPUの計算ユニット（Compute）に空きがある場合のみ、インスタンス数を増やすことを検討します。リソースの分散は、バッチ効率の低下を招くリスクがあることを念頭に置くべきです。
5. 実装ステップ③：負荷テストによる検証と限界の見極め
机上の計算でSLAから逆算したパラメータが適切か、実戦形式のテストで検証します。本番環境でユーザーに遅延を感じさせる前に、システムの限界を把握することが重要です。特に最新の動的バッチング戦略やCudaグラフ最適化が、高負荷時にも期待通りのパフォーマンスを発揮するか確認することが不可欠です。
Locust/JMeterを用いた現実的な負荷シナリオ作成
負荷テストツールには、Pythonで柔軟にシナリオが記述できる Locust が推奨されます。LLM推論のテストでは、単にリクエスト数を増やすだけでなく、推論エンジンの特性を考慮したシナリオを用意します。
- トークン長の変動（Mix Workload）: 短い入力と長い入力、短い出力と長い出力をランダムに混ぜます。これにより、実装したバケットサンプリングが機能し、可変長シーケンスが効率的にパッキングされ、GPUの計算リソースに無駄が生じていないかを確認します。
- スパイクとランプアップ: 徐々に負荷を高めるだけでなく、突発的な大量アクセスを模倣します。SLA逆算で設定した動的バッチサイズの上限が機能し、レイテンシ（特にTBT）を悪化させずにリクエストを処理できるかを見極めます。
- 並列処理の検証: 大規模モデルの場合、テンソル並列化（TP）によるGPU間通信がボトルネックになっていないかを確認します。高負荷時に通信オーバーヘッドが増大し、全体のスループットを低下させていないか監視が必要です。
スループットとレイテンシの相関グラフ作成
テスト結果の分析では、従来の「平均レイテンシ」だけを見てはいけません。LLMのUX（ユーザー体験）に直結する以下の2つの指標を、RPS（Requests Per Second）およびGPU利用率との相関でグラフ化します。
- TTFT (Time To First Token): 最初のトークンが表示されるまでの時間。入力処理（Prefill）の効率と、Cudaグラフ最適化によるカーネル起動オーバーヘッド削減の効果を示します。
- TBT (Time Between Tokens): トークン生成の間隔。生成処理（Decode）のスループットを示し、ユーザーが感じる「滑らかさ」に直結します。
理想的な状態では、負荷が増えてもこれらの指標はSLAの許容範囲内に収まります。しかし、ある点を超えると、KVキャッシュの管理負荷や計算リソースの競合により、TBTが悪化し始めます。
サチュレーションポイント（性能限界）の特定
グラフ上で、SLA（例: TBT < 50ms）を守れなくなるポイントが、システムの真の 「サチュレーションポイント（飽和点）」 です。
例えば、「GPU利用率が90%を超えると、スループットは向上してもTBTがSLAの許容値を超える」という現象が見えたら、そこが限界です。この限界値を正確に把握することで、本番環境でのオートスケーリング（HPA）設定を、「CPU/GPU使用率」のような単純な指標ではなく、「SLA違反の予兆」に基づいて精密に設計できるようになります。
6. 運用監視とトラブルシューティング
導入して終わりではありません。動的バッチングは「待ち時間」を制御する繊細な技術であるため、継続的な監視が必要です。特にKubernetesのようなコンテナオーケストレーション環境は更新サイクルが早く、インフラ側の仕様変更が推論パフォーマンスに影響を与えることもあります。
監視すべき重要メトリクス（Queue Time, Compute Time）
運用ダッシュボード（Grafana等）には、必ず以下の指標を表示します。これらは推論サーバーの稼働状況を把握するために不可欠です。
- Queue Time: リクエストがバッチ化されるのを待っていた時間。
- Compute Time: 実際にGPUで推論計算を行っていた時間。
- Average Batch Size: 実際に形成された平均バッチサイズ。
もし Queue Time が設定した max_queue_delay ギリギリまで張り付いていて、かつ Average Batch Size が小さい場合、それは「リクエストが少なすぎて無駄に待っている」状態です。逆に Queue Time がほぼゼロなら、バッチングが機能していない（即時実行されている）可能性があります。
リクエスト急増時の縮退運転・オートスケール連携
GKE（Google Kubernetes Engine）やAKS（Azure Kubernetes Service）などのマネージドKubernetes環境でHPA（Horizontal Pod Autoscaler）を使用する場合の注意点です。
Kubernetesのエコシステムは常に進化しており、GKEやAKSではセキュリティ強化や機能改善のため、定期的に新しいバージョンへの自動アップグレードが実施されます。しかし、「HPAと動的バッチングの競合」という基本構造上の課題は、プラットフォームのバージョンを問わず発生します。
HPAが敏感すぎると、リクエストが少し増えただけで新しいPodが立ち上がり、リクエストが分散してしまいます。結果として、各Podでバッチが埋まらず、GPU効率が下がることがあります。
動的バッチングの効果を最大化するには、「あえて少し混雑させる」くらいの調整が必要です。HPAのスケールアップ閾値を少し高めに設定し、1つのPod（GPU）を十分に使い切ってから次を追加するようにします。最新のKubernetes環境で利用可能なカスタムメトリクスを活用し、CPU使用率ではなく「GPU使用率」や「平均キュー滞留時間」をトリガーにスケールさせるのが定石です。
また、古いOSイメージ（例：Ubuntu 18.04ベースなど）のサポート終了に伴うノードプールの更新も、推論レイテンシに影響を与える可能性があるため、公式のリリースノートを確認し、計画的な検証を行うことが推奨されます。
よくある失敗：断片的なリクエストによるタイムアウト多発
稀に、クライアント側のタイムアウト設定が短すぎて、サーバー側でバッチ待ちをしている間にクライアントが接続を切ってしまうケースがあります。
サーバー側の max_queue_delay + 推論時間 よりも、クライアント側のタイムアウト設定には十分な余裕を持たせるように、フロントエンドチームやアプリ開発チームと連携してください。これは技術的な設定の問題であると同時に、プロジェクト進行におけるコミュニケーションの課題でもあります。
まとめ
AI推論サーバーにおける動的バッチングは、単なる設定項目のON/OFFではありません。それは、「SLA（レイテンシ）」と「コスト（スループット）」のトレードオフをコントロールするための経営的なレバーです。
今回解説したステップを振り返ります。
- 現状分析: 闇雲にいじらず、まずはSLAを定義する。
- 基本設定: Tritonなどの専用サーバーで動的バッチングを有効化する。
- パラメータ設計: SLAから逆算して待機時間（Delay）を決定する。
- 検証: 負荷テストでサチュレーションポイントを見極める。
- 監視: Queue Timeとバッチサイズを継続的にモニタリングし、Kubernetes等の基盤更新に合わせて調整する。
GPUは現代のビジネスにおける貴重なリソースです。それを20%しか使わずに無駄にするのか、それとも知恵を絞って100%使い切るのか。それは、技術とビジネスの両面から最適な解決策を導き出すプロジェクトマネジメントの手腕にかかっています。
この記事が、自社の設定を見直すきっかけになれば幸いです。最適化によって浮いたコストでさらに新しいAIの実験に挑戦することが、ビジネスにおける革新への近道となります。
コメント