Re Reference AI

技術

バッチ推論とは

Batch Inference

複数の推論リクエストをまとめて処理し、GPUの利用効率とスループットを高める手法

推論最適化スループット

ひとことで言うと

複数の質問をまとめて処理し、コンピュータの計算効率を上げる方法。

概要

バッチ推論(Batch Inference)とは、複数の推論リクエストを1つにまとめ(バッチ化し)、GPU上でまとめて処理することで、単位時間あたりに処理できるリクエスト数(スループット)を高める手法。 GPUは多数の演算を並列に実行することを得意とするため、リクエストを1件ずつ処理するより、複数件をまとめて1回の演算にまとめた方がGPUの計算資源を効率的に利用できる。 リアルタイム性が求められないバッチ処理的な用途(大量データの一括要約・分類等)で特に有効に使われる。 一方でバッチをまとめる待機時間が発生するため個々のリクエストの応答速度(レイテンシ)は犠牲になりやすく、即時応答が必要なチャット用途とはトレードオフの関係にある。

背景

LLMの推論はGPU上での行列演算が中心であり、1件のリクエストだけではGPUの並列計算能力を使い切れず遊休状態になりやすい。 バッチ推論は、複数のリクエストをまとめて1回の演算にすることでこの遊休を減らしGPU利用効率を高めるために採用されている。

アーキテクチャ

複数の入力系列をまとめて1つの行列として扱い、GPU上で並列に演算する。 入力系列の長さが異なる場合は、短い系列をパディング(埋め草)して長さを揃える必要があり、バッチ内の系列長のばらつきが大きいと無駄な計算が発生する。 オンラインサービスでは、一定時間内に届いた複数のリクエストを動的にバッチへまとめる「動的バッチング」も用いられる。

ワークフロー

複数の入力リクエストを収集しバッチとしてまとめる → 系列長が異なる場合はパディングを施して揃える → GPU上で1回の演算としてまとめて処理 → 各リクエストへ個別の出力を振り分けて返す。

コード例

複数プロンプトをバッチにまとめて推論する

from transformers import AutoModelForCausalLM, AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained("gpt2")
tokenizer.pad_token = tokenizer.eos_token
model = AutoModelForCausalLM.from_pretrained("gpt2")

prompts = ["こんにちは、", "今日の天気は", "AIとは"]
inputs = tokenizer(prompts, return_tensors="pt", padding=True)

outputs = model.generate(**inputs, max_new_tokens=20)
for output in outputs:
    print(tokenizer.decode(output, skip_special_tokens=True))

利点

  • GPUの並列計算能力を効率的に利用でき、単位時間あたりの処理件数(スループット)を高められる
  • 大量のデータをまとめて処理するタスクで、推論コストを抑えられる
  • GPUの遊休時間を減らすことで、同じハードウェアからより高いスループットを引き出せる

欠点

  • 個々のリクエストはバッチが揃うまで待たされることがあり、リアルタイム性が求められる用途には不向き
  • 系列長にばらつきがあると、パディングによる無駄な計算が発生しやすい
  • バッチが揃うまでリクエストを待たせる設計のため、早く届いたリクエストほどレイテンシの面で不利になりやすい

比較

  • ストリーミング — バッチ推論が複数リクエストをまとめてスループットを重視するのに対し、ストリーミングは個々のリクエストへの応答性を重視する
  • 推論 — バッチ推論は、推論を効率化する代表的な手法の1つ
  • KVキャッシュ — バッチ推論では、リクエストごとに異なるKVキャッシュを同時に管理せねばならず、実装が複雑になる
  • vLLM — vLLMは、連続バッチングによりバッチ推論のスループットを高める
  • 連続バッチ処理 — 連続バッチ処理は、固定サイズのバッチ推論と異なりイテレーション単位でバッチの構成を動的に組み替える発展形

関連用語

ストリーミング推論KVキャッシュvLLM連続バッチ処理

よくある質問

バッチ推論はチャットのようなリアルタイム用途にも使える？

バッチサイズや待機時間を小さく抑えた動的バッチングを使えば、レイテンシへの影響を抑えつつスループットを高めることも可能だが、純粋なリアルタイム性とはトレードオフになる。

バッチサイズは大きいほど良い？

スループットは向上しやすいが、GPUメモリの上限や個々のリクエストのレイテンシとのトレードオフがあり、要件に応じた調整が必要。

参考文献

関連Zenn記事