最終更新: 2026-06-22

バッチ推論スループット

バッチ推論は、本番環境の言語モデルサーバーが高い利用率を達成する方法である。リクエストを1件ずつ復号するのではなく、多数をまとめて処理する。モデルの重みが1回読まれてグループ全体で再利用されるため、サーバーの出力総量はバッチサイズとともに急激に増える。ただし個々のリクエストはバッチの完了を待つ。この計算は、測定したバッチ完了時間を合計スループット、リクエストごとの速度、リクエスト率という2つの視点に分けて示す。

バッチ処理のトレードオフ

自己回帰的な復号はメモリ律速であり、各ステップは1トークンを生成するためにすべての重みを読み込む。単一のリクエストだけが処理中のとき、そのメモリトラフィックのほとんどはたった1人の利用者のために費やされる。複数のリクエストを1つのバッチにまとめると、同じ重みの読み込みですべてのリクエストに対して同時にトークンが生成されるため、帯域幅コストがほとんど変わらないまま合計トークン速度がバッチサイズとともに上がる。問題はレイテンシである。リクエストはそれを含むバッチステップが完了するまで抜けられないため、リクエストごとの速度は改善せず、バッチが大きくなるとわずかに下がることもある。

計算式

バッチサイズ $B$、リクエストあたりの出力トークン数 $N_{out}$、測定したバッチ完了時間 $t_b$ から次のように求める。

ここで $v_{agg}$ は合計スループット、$v_{req}$ はリクエストごとのスループット、$R$ は1秒あたりに完了するリクエスト数である。合計はリクエストごとの速度にバッチサイズを掛けたものにほかならない。

計算例

サーバーが32件のリクエストからなるバッチを復号し、それぞれ256トークンを生成して、バッチが5秒間で完了するとする。

運用者にはサーバーから毎秒1,600トークンを超える流れが見えるが、各利用者はおよそ毎秒51トークンで読む。メモリが許し完了時間が5秒前後にとどまるなら、バッチを64に倍増させると合計はおよそ2倍になり、リクエストごとの値は変わらない。

バッチサイズの選び方

合計スループットは作業がメモリ律速にとどまる間だけバッチサイズとともに上がり続ける。バッチが計算を飽和させるか、キーバリューキャッシュがデバイスメモリを使い尽くすと、完了時間がバッチより速く伸びてリクエストごとのレイテンシが悪化する。実用上の目標は、メモリに収まりつつリクエストごとのレイテンシを許容範囲に保てる最大のバッチであり、いくつかのバッチサイズで完了時間を測定して求める。実際のサーバーは連続バッチ処理も用い、リクエストが固定グループとしてではなくステップごとに加わり抜けるため、持続的なスループットがさらに上がる。$v_{req}$ を決める単一ストリームの上限は推論スループットの計算を、多数のレプリカにわたるフリート全体の処理能力は実効トークン毎秒の計算を参照されたい。