LLM推論ベンチマークのボトルネックは「計測ツール自体」だった — NVIDIAがGenAI-Perfの後継として開発した「AIPerf」の設計と使い方

9月19日、NVIDIAが「Benchmarking LLM Inference at Scale with AIPerf」と題した記事を公開した。この記事では、LLM推論のスケール時における性能評価を正確かつ再現性高く実施するためのツール「AIPerf」の設計思想と実践的な使い方について詳しく紹介されている。

「ベンチマークがボトルネック」という問題

LLMサーバーを立ち上げて動作確認した後、「本当に速いのか？」を測ろうとすると、curl を手打ちしたり、asyncio スクリプトを即席で書いたりという経験は多くのエンジニアにあるはずだ。

この手法の根本的な問題は、計測ツール自体がボトルネックになることだ。Pythonのシングルプロセス構成はGIL（Global Interpreter Lock）によって並行処理が制限され、高負荷時には「サーバーが遅い」のか「クライアントが追いついていない」のかが判別できなくなる。NVIDIA GenAI-Perfも同様の制約を抱えていた。

AIPerf はその後継ツールとして設計されており、ワーカープロセスが負荷生成を担い、別プロセスの結果処理サービスが計測を担当し、プロセス間通信にはZMQ（非同期メッセージングライブラリ）を使う構成だ。クライアント側がボトルネックになる前に、サーバー側を正しく飽和させられる。LLM推論基盤のスケールアウトが進み、マルチノード・マルチGPU構成が当たり前になりつつある今、計測精度の信頼性は以前にも増して重要な要件となっている。

まずは動かす：vLLM + Qwen3-0.6B で計測ループを確立する

記事ではQwen3-0.6B（vLLM経由）を題材にしたウォークスルーが紹介されている。モデルが小さいため1枚のGPUで動き、反復サイクルが速い。本質は計測ループの確立であり、モデルを差し替えるのはフラグ1つだ。

サーバー起動（Docker）

docker run --gpus all -p 8000:8000 -e HF_TOKEN vllm/vllm-openai:latest \
  --model Qwen/Qwen3-0.6B \
  --reasoning-parser qwen3 \
  --host 0.0.0.0 --port 8000

AIPerf インストール

uv pip install aiperf

aarch64環境では依存パッケージ crick がソース配布のみのため、Cツールチェーン（Debian/Ubuntuなら build-essential）が必要になる点に注意が必要だ。

静的ベンチマーク実行

aiperf profile \
  --model Qwen/Qwen3-0.6B \
  --endpoint-type chat \
  --streaming \
  --url localhost:8000 \
  --synthetic-input-tokens-mean 128 \
  --synthetic-input-tokens-stddev 0 \
  --output-tokens-mean 128 \
  --output-tokens-stddev 0 \
  --extra-inputs min_tokens:128 \
  --extra-inputs ignore_eos:true

フラグの意図を理解しておくことが重要だ：

--synthetic-input-tokens-stddev 0 / --output-tokens-stddev 0：入出力トークン数を128固定にし、静的ベースラインを作る
--extra-inputs min_tokens:128 と --extra-inputs ignore_eos:true：これがないとモデルが途中で出力を止める。スループット数値が低くなるだけでなく、実行ごとに再現性がなくなる
--streaming：TTFT（Time to First Token）とITL（Inter-Token Latency）を計測するには必須。非ストリーミングだと全レスポンスをまとめて受け取るため、これらのイベントが計測できない

読み解くべき4つの指標

AIPerf が出力するメトリクスのうち、特に重要な4つを整理する。

指標	意味
TTFT（Time to First Token）	リクエスト送信から最初のトークン受信までの時間。インタラクティブ用途の主要レイテンシ指標
ITL（Inter-Token Latency）	トークン間の生成間隔。TTFTが正常でもITLが高ければデコードフェーズに問題がある
Request Latency	レスポンス全体のエンドツーエンド時間
Output Token Throughput	全並行リクエスト合計のトークン生成数/秒。キャパシティプランニングの主要指標

各指標はp25〜p99のパーセンタイル、最小・最大・平均・標準偏差で出力される。平均TTFTが正常でもp99が外れ値になっているサーバーは、本番で問題を起こす。パーセンタイル分布を見ることで、ロングテールの問題を発見できる。

DCGMまたはpynvmlが利用可能な環境では、GPU電力・使用率・メモリ消費量も同じ実行結果に含まれる。レイテンシスパイクとメモリプレッシャーを別セッションで相関させる必要がない。

より実践的な負荷パターン：Poisson到着プロセス

静的ベースラインを取った後は、実際のトラフィックに近い形での計測に進む。

aiperf profile \
  --model Qwen/Qwen3-0.6B \
  --endpoint-type chat \
  --streaming \
  --url localhost:8000 \
  --request-rate 10 \
  --arrival-pattern poisson \
  --synthetic-input-tokens-mean 512 \
  --synthetic-input-tokens-stddev 128 \
  --output-tokens-mean 128 \
  --output-tokens-stddev 32 \
  --random-seed 42 \
  --request-count 200

**--arrival-pattern poisson**：リクエストが指数分布の間隔で到着する。固定レートではなくバーストと間隔が生まれ、キューイングが発生する実際の挙動に近くなる
**--synthetic-input-tokens-stddev 128**：プロンプト長に分散を持たせる。記事によれば入力シーケンス長は154〜818トークンの範囲に分布した
**--random-seed 42**：Poissonタイミングと長さの乱数を固定し、再現性を確保する

Poissonパターンで計測するとTTFTの分布が静的ベンチマークより大幅に広がる。複数リクエストがGPUを同時に奪い合い、プリフィル長が変動するためだ。静的・1並行の計測は可能な限り低いTTFTを示すが、それはスループットを犠牲にした理想化されたシナリオである点を理解しておく必要がある。

さらに高度な使い方

AIPerf はこの記事で紹介した範囲を超えて、以下のユースケースにも対応している：

マルチノードKubernetesデプロイでのベンチマーク
KVキャッシュ再利用のウォームアップ計測
Baseten・Mooncake・WEKA（AgentX）形式の本番トラフィックトレースのリプレイ
同時接続数やリクエストレートのスイープ設定

エンドポイントタイプも chat、responses、NIM rankings、画像生成など15種類以上をサポートしている。

分散推論の本番運用については、NVIDIAが別途公開している「How NVIDIA Dynamo 1.0 Powers Multi-Node Inference at Production Scale」も参照できる。

AIPerFのGitHubリポジトリおよび公式ドキュメントが正式なリファレンスだ。AWS・Coreweave・Baseten・Pinterestのエンジニアが外部コントリビューターとして開発に参加しており、クロスカンパニーでの検証が進んでいる点も信頼性の裏付けになる。

詳細はBenchmarking LLM Inference at Scale with AIPerfを参照していただきたい。