ストリーミングを切ると TTFT / ITL が測れない#

LLM の体感速度は、リクエストを投げてから最初のトークンが返るまでの TTFT（Time To First Token）と、その後のトークン間隔 ITL（Inter-Token Latency）で決まる。非ストリーミングでリクエストすると、クライアントは生成完了まで待つので、この 2 つは原理的に取れない。AIPerf は TTFT / ITL を出すには --streaming が必要だと明記している¹。

自作スクリプトで stream: false のまま「レスポンス時間」を測ると、出てくるのは生成完了までの E2E であって、体感速度の代理指標にはならない。汎用 HTTP ツールの「レスポンス時間」も同じで、ストリーミングにしても HTTP 完了までの時間しか記録しない。

メトリクスの名前が同じでも定義が違う#

vLLM の vllm bench serve は、TTFT をリクエスト送信から最初のストリーム出力まで、TPOT を (E2E - TTFT) / (出力トークン数 - 1) としてリクエスト単位で集計し、ITL を連続するストリーム出力の間隔と定義している²。投機デコードを使うと 1 回のストリームイベントで複数トークンが返るため、ITL と TPOT が乖離しうる²。

reasoning モデルではさらにずれる。AIPerf の TTFT は reasoning を含む最初のトークンまでで、reasoning でない最初の出力トークンまでは TTFO という別の指標になっている。旧 GenAI-Perf の TTFT は後者に相当する³。つまり同じ TTFT という名前でも、ツールとバージョンで測定点が違う。vLLM 公式も、名前ではなく測定点と式で比較せよ、と書いている²。

自作スクリプトの場合、この定義は書いた人の頭の中にしかない。「TTFT 400ms」の 400ms が最初のバイトまでなのか、最初の非 reasoning トークンまでなのか、レポートを読んでも分からない。

prefix cache でスループットが水増しされる#

vLLM は prefix caching を持つので、同じサーバーに同じプロンプトを繰り返し投げると、prefill が省略されてスループットが実態より良く出る。公式はこれを Warning として書いていて、意図しないなら --seed を変えるか、サーバーを再起動するか、キャッシュをリセットする vllm bench sweep serve を使え、としている²。

自作スクリプトは「Hello」を 100 回投げがちで、これは prefix cache のベンチマークをしているのに近い。

負荷発生器側が先に飽和する#

Locust のデフォルト HttpUser は requests ベースで、高 RPS では負荷を掛ける側の CPU が先に飽和する。公式は FastHttpUser を用意していて、同一ハードウェアで最大 RPS が 5〜6 倍になることがあると説明している⁴。目安として 1 プロセスあたり FastHttpUser で約 16,000 RPS、HttpUser で約 4,000 RPS とあるが、これは被試験システムの性能ではなく、負荷発生器側の上限である⁴。Python はプロセスあたり 1 コアしか使い切れないので、分散時はコアあたり 1 worker が推奨されている⁵。

asyncio + httpx で書いた自作スクリプトが 1 プロセスで頭打ちになり、それが「サーバーの限界」として報告されている可能性は普通にある。

負荷の掛け方で分布が変わる#

同じ 100 リクエストでも、一斉送信するのか、毎秒 5 本の定常レートで送るのか、Poisson 到着にするのか、同時数を 16 に固定するのかで、レイテンシ分布はまったく違う。vllm bench serve の --request-rate はデフォルトが inf（一斉送信）で、--burstiness で Poisson / Gamma、--max-concurrency で同時数上限を指定する²。GuideLLM のプロファイルは synchronous / concurrent / throughput / constant / poisson / sweep に分かれている⁶。vLLM の sweep 文書は、request_rate より max_concurrency のほうがエンジン負荷を直接制御できて安定しやすい、と書いている⁷。

自作スクリプトは asyncio.gather で一斉送信していることが多い。これは throughput プロファイルの一種であって、定常レートの結果とは比べられない。

入出力トークン長がレポートに残らない#

ISL（入力トークン長）と OSL（出力トークン長）を変えれば、prefill と decode の比率が変わり、TTFT も tok/s も変わる。専用ツールはこれを prompt_tokens=512,output_tokens=128 のように明示するが、自作スクリプトでは固定文字列とデフォルトの max_tokens になりがちで、レポートに残らない。

こうして並べると分かるとおり、ずれる場所のうち ISL / OSL や負荷プロファイルは要件次第で変わってよいものだが、メトリクスの定義、ストリーミングの扱い、キャッシュへの対処、負荷発生器の上限はツールに固有である。同じツールを使っていれば、条件の違いは引数の違いとして読めるが、ツールが違えば、同じ名前の数字が違うものを指す。この観点を持ったうえで、ツールを見ていく。

比較表#

Locust — Python チームの標準候補#

Locust は HTTP を中心とした OSS の負荷試験ツールで、テストは普通の Python として書く⁹。各仮想ユーザーは greenlet 上で動くため、async コールバックではなく同期風のコードでシナリオを書ける⁹。公式が挙げる特徴は、シナリオを Python で書くこと、master / worker による分散実行、リアルタイム Web UI（ヘッドレス実行も可能）、HTTP 以外もクライアントを書けば対象にできること、である⁹。

スループット側の注意は前述のとおりで、高 RPS が要るなら FastHttpUser を使い⁴、単一マシンなら locust --processes -1 で論理コア数ぶんの worker を立てる⁵。master 自体は User を動かさない。

LLM 向けには、実験的な locust.contrib.oai.OpenAIUser がある。OpenAI SDK を使い、response_length に出力トークン数を入れる設計で、ペイロードのバイト数より有用という位置づけである¹⁰。ただしTTFT / ITL の標準メトリクスは出ないし、公式も experimental と注記している¹⁰。Locust 2.40 以降は pytest 風の test_* 関数と session fixture でもシナリオを書けるが、こちらも experimental である¹⁰。

Locust が向くのは、Python チームがシナリオとアプリコードを同じ言語でメンテしたい場合、認証・複数ステップ・条件分岐のあるユーザー行動を再現したい場合、社内 SDK や既存クライアントを再利用したい場合、Web UI で同時ユーザー数を探索的に変えたい場合、分散負荷を OSS のまま複数マシンに広げたい場合である。向かないのは、単一ノードで数十万 RPS を出したい場合と、LLM のトークン単位 SLO を厳密に測りたい場合である。

k6 — Python ではないが、CI ゲートとしては強い#

Grafana k6 は Go 製の負荷試験ツールで、テストスクリプトは埋め込み JS エンジン（Sobek）上の JavaScript である¹¹¹²。Node.js ではないため npm パッケージは使えない。単一静的バイナリ、高 RPS、そして CI 向きの thresholds（満たさなければ非ゼロ終了）が強みである¹³。

1
export const options = {
2
  thresholds: {
3
    http_req_failed: ['rate<0.01'],
4
    http_req_duration: ['p(95)<200'],
5
  },
6
};

「p95 が閾値を超えたら fail」を宣言的に書けるのは、Locust だと後処理が要るところなので、CI ゲートとしては k6 のほうが素直である。

OSS の k6 は AGPL-3.0 で¹²、自システムへの負荷試験ツールとして社内で走らせる分と、製品に埋め込んでホストする分では法務上の扱いが違う。Python 互換を謳う xk6-python は Grafana Hackathon の PoC で、Starlark 方言であり CPython / pip は使えない。リポジトリは archived である¹⁴。

Python メインなら、k6 は「ゲートウェイの高 RPS CI」に限定して併用するのが現実的で、メインのシナリオ言語にはしない。

その他#

• Molotov — @scenario 付きの asyncio コルーチン。aiohttp セッションを受け取る。gRPC 対応（2.7 以降）。--sizing で失敗率が閾値を超えるまで worker を増やす¹⁵。Locust より単純だが、UI・分散・エコシステムは薄い
• JMeter — HTTP 以外（JDBC, JMS, LDAP 等）が必要なときの OSS 選択肢。テスト計画は XML（.jmx）
• Gatling — JVM DSL。assertions と HTML レポートが強い。Python チームには学習コストが大きい
• Vegeta / oha — URL を定数レートまたは高並行で叩く CLI。シナリオ維持には向かない
• Taurus — 複数エンジンの YAML ラッパー。エンジン選定を代替するものではない

比較表#

GuideLLM の README にも他ツールとの比較表があるが⁶、プロジェクト自身の表なので割り引いて読む。たとえば vllm bench は TTFT / ITL を出すので、そこでの「フルメトリクスなし」は GuideLLM 基準の自己評価である。

GuideLLM — vLLM 本番評価の第一候補#

GuideLLM は vLLM プロジェクト配下の Python パッケージで、OpenAI 互換および vLLM native サーバーに対して本番に近い負荷をかけ、TTFT / ITL / E2E の分布を取る⁶。vLLM のベンチマーク文書は、本番サーバー評価に GuideLLM を勧め、vllm bench serve よりデータセット読み込み・リクエスト形式・負荷パターンが柔軟だと書いている²。

1
pip install guidellm[recommended]

最小の sweep 例（合成データ、30 秒）⁶：

1
guidellm run \
2
  --backend kind=openai_http,target=http://localhost:8000 \
3
  --profile kind=sweep \
4
  --constraint kind=max_duration,seconds=30 \
5
  --data kind=synthetic_text,prompt_tokens=256,output_tokens=128

負荷プロファイルは synchronous / concurrent / throughput / constant / poisson / sweep。データは合成テキスト、HuggingFace、ローカルファイル、マルチモーダル合成、Mooncake trace の replay など⁶。出力は JSON / CSV / HTML。warmup / cooldown、エラー上限、過飽和（over-saturation）検出もある。Python 3.10–3.13、Linux / macOS、Apache-2.0⁶。

注意点が 2 つ。sweep の最初のステージは同期（逐次）実行になるため、--max-requests を大きくすると極端に長くなり得るという Issue がある¹⁶。時間制約（max_duration）を先に置くか、同期ステージの件数を小さくする。もう 1 つ、CLI は kind=key,value 形式へ移行済みで、古いブログにある guidellm benchmark --rate-type=sweep はそのまま使えないことがある。AI にコマンドを書かせると古い形式が出てくることがあるので、README の現行形式で確認する。

vllm bench serve / sweep — vLLM 付属#

サーバーを立ててからクライアント側で測るオンラインベンチマークである²。

1
vllm serve NousResearch/Hermes-3-Llama-3.1-8B
2

3
vllm bench serve \
4
  --backend vllm \
5
  --model NousResearch/Hermes-3-Llama-3.1-8B \
6
  --endpoint /v1/completions \
7
  --dataset-name sharegpt \
8
  --dataset-path ShareGPT_V3_unfiltered_cleaned_split.json \
9
  --num-prompts 10

出力にはリクエスト / 出力トークン / 総トークンのスループットと、TTFT、TPOT、ITL が含まれる²。定義は前述のとおり。負荷パターンは --request-rate、--burstiness、--max-concurrency で、データセットは ShareGPT、random、custom JSONL、画像・音声など広い²。

vllm bench sweep は複数設定を回して可視化するスイートで⁷、次のサブコマンドを持つ。

• serve — vllm serve のパラメータ組み合わせ（例: max_num_seqs × max_num_batched_tokens）
• serve_workload — 負荷レベルを探索してレイテンシ vs スループット。公式は GuideLLM の --profile sweep 相当と明記。デフォルトは GuideLLM 寄せで request_rate だが、--workload-var max_concurrency のほうが安定しやすい⁷
• serve_sla — 例: {"p99_e2el_ms": "<=500"} を満たす最大レート / 同時数を探索
• plot / plot_pareto — 曲線と tokens/s/user vs tokens/s/GPU

機能の回帰や「この PR で ShareGPT が落ちていないか」には vllm bench serve。本番の容量計画には GuideLLM。設定スイープはどちらでもできるが、vLLM 付属 sweep はサーバー起動からキャッシュリセットまで一体で回せる。

AIPerf — NVIDIA の生成 AI ベンチマーク（旧 GenAI-Perf）#

AIPerf は NVIDIA の OSS（pip install aiperf）で、OpenAI 互換エンドポイントのストリーミング性能を測る¹⁷。NIM 向けガイドは Locust / k6 を負荷試験、AIPerf を性能ベンチマークと分け、後者を推奨している⁸。GenAI-Perf の後継で、多くのオプションは drop-in である³。

1
aiperf profile \
2
  --model your-model \
3
  --url localhost:8000 \
4
  --endpoint-type chat \
5
  --streaming \
6
  --concurrency 10 \
7
  --request-count 100

--streaming を付けると TTFT / ITL が有効になる¹。時間ベースなら --benchmark-duration。goodput（SLO を満たしたリクエストだけのスループット）や、disaggregated serving 向けの --prefill-concurrency もある。vLLM を OpenAI 互換で叩けるので、NVIDIA スタックや goodput / GPU テレメトリが要るときに使う。

Locust で vLLM を叩く意味#

意味はあるが、GuideLLM の代替ではない。向くのは、LiteLLM や自前ゲートウェイを経由して vLLM に届く経路全体、API キー・レート制限・リトライ・マルチターンといったユーザー行動、「同時 N ユーザーがチャットする」運用試験（オートスケール、接続枯渇、タイムアウト）といったアプリ層である。

1
from locust import HttpUser, task, between
2
import json
3

4
class ChatUser(HttpUser):
5
    wait_time = between(1, 3)
6

7
    @task
8
    def chat(self):
9
        self.client.post(
10
            "/v1/chat/completions",
11
            json={
12
                "model": "your-model",
13
                "messages": [{"role": "user", "content": "Hello"}],
14
                "stream": True,
15
                "max_tokens": 128,
16
            },
17
            headers={"Authorization": "Bearer dummy"},
18
            name="/v1/chat/completions",
19
        )

この書き方で Locust が記録するのは、HTTP 完了までの時間である。ストリーミングの最初のチャンク時刻（TTFT）を取るなら、自前で chunk を読んでイベントを fire する必要がある。ここまで来ると専用ツールを使うほうが早い。実験的な OpenAIUser は Responses API の例が中心で、vLLM の主経路は Chat Completions なので、アプリ試験は HttpUser のほうが現状は分かりやすい¹⁰。