はじめに
LLMの推論サーバーやAPIの性能を比べるとき、次の5つの指標がよく出てきます。
| 指標 | 正式名称 | ひとことで言うと | 単位 |
|---|---|---|---|
| TTFT | Time To First Token | 最初の1文字が出るまでの待ち時間 | 秒 / ミリ秒 |
| ITL | Inter-Token Latency | トークンとトークンの間隔 | ミリ秒 |
| TTLT | Time To Last Token | 最後の1文字が出るまでの時間（全体の所要時間） | 秒 |
| TPS | Tokens Per Second | 1リクエストの出力速度 | tok/s |
| Throughput | スループット | サーバー全体でさばける量 | tok/s（または req/s） |
名前が似ていて混同しやすいので、この記事では 図と動画で「時間軸のどこを測っているのか」 を整理します。
まずは全体像：1リクエストの時間の内訳
LLMはテキストを一度に返すのではなく、トークンを1つずつ順番に生成します。そのため、1回のリクエストは大きく2つのフェーズに分かれます。
- Prefill（プリフィル）: 入力プロンプト全体を読み込んで計算するフェーズ。ここが終わるまで1トークン目は出ません。
- Decode（デコード）: トークンを1つずつ生成していくフェーズ。
この時間軸の上で、各指標は次の区間を測っています。
- TTFT = リクエスト送信 → 最初のトークン
- ITL = あるトークン → 次のトークン
- TTLT = リクエスト送信 → 最後のトークン
- TPS = デコード区間で1秒あたり何トークン出たか
実際にストリーミングで返ってくる様子を見てみましょう。
GIFは見やすさのために時間を誇張しています（TTFT 0.6秒、ITL 0.15秒）。
1. TTFT（Time To First Token）
リクエストを送ってから、最初のトークンが届くまでの時間です。
ChatGPTなどで送信ボタンを押してから、最初の文字が表示されるまでの「考え中…」の時間がこれにあたります。ユーザーが 「反応が速い／遅い」と感じるかどうか を一番左右する指標です。
TTFTに含まれるもの：
- ネットワークの往復時間
- サーバーのキュー待ち時間（混んでいると長くなる）
- Prefill の計算時間（プロンプトが長いほど長くなる）
TTFT = t(最初のトークン受信) − t(リクエスト送信)
2. ITL（Inter-Token Latency）
連続する2つのトークンが届く間隔です。
ITLが小さいほど、文字がスムーズに流れるように表示されます。逆にITLがばらつくと、表示が「カクカク」止まって見えます。
ITL_i = t(i番目のトークン) − t(i−1番目のトークン)
ITLは1リクエストの中でもトークンごとに値が変わるので、平均値だけでなくp50 / p90 / p99 も見るのがおすすめです。
似た指標：TPOT（Time Per Output Token）
ITLと一緒によく出てくるのが TPOT です。こちらは1リクエスト単位で「2トークン目以降の平均生成時間」を求めたものです。
TPOT = (TTLT − TTFT) / (出力トークン数 − 1)
ITLは「トークン間隔ひとつひとつ」、TPOTは「そのリクエスト内の平均」と覚えておくと区別しやすいです。
3. TTLT（Time To Last Token）
リクエストを送ってから、最後のトークンが届くまでの時間です。E2E（End-to-End）レイテンシ とも呼ばれます。
TTLT = TTFT + Σ ITL
≒ TTFT + TPOT × (出力トークン数 − 1)
ストリーミングせずに結果をまとめて受け取る使い方（バッチ処理、エージェントのツール呼び出し、JSON生成など）では、TTFTよりも TTLTの方が重要 になります。
TTLTは 出力が長いほど伸びる ので、比較するときは出力トークン数をそろえることが大切です。
4. TPS（Tokens Per Second）
1つのリクエストで、1秒あたりに何トークン生成されたか です。ユーザー1人から見た「文章が出てくる速さ」を表します。
TPSは計算方法が2通りあるので注意が必要です。
# デコード速度（TTFTを含めない）… ITL/TPOTの逆数
TPS = (出力トークン数 − 1) / (TTLT − TTFT) = 1 / TPOT
# 全体速度（TTFTを含める）
TPS = 出力トークン数 / TTLT
ベンチマーク結果を比べるときは、どちらの定義か を必ず確認しましょう。TTFTが長い環境ほど、2つの値の差が大きくなります。
5. Throughput（スループット）
サーバー全体で、1秒あたりに何トークン（または何リクエスト）処理できるか です。
TPSが「ユーザー1人の体感速度」なのに対して、Throughputは「サーバーの処理能力」を表します。推論サーバーは複数のリクエストをまとめて（バッチで）処理するので、同時に生成中のリクエストが増えるほど全体の処理量も増えます。
動画では、各ユーザーのTPSは 4 tok/s のままですが、同時に生成しているユーザーが増えるほどThroughputは 4 → 8 → 12 → 16 tok/s と増えていきます。
Throughput（出力トークン）= 測定時間内の全リクエストの出力トークン合計 / 測定時間
Throughput（リクエスト） = 完了したリクエスト数 / 測定時間
（ざっくり）Throughput ≈ 1人あたりTPS × 同時に生成中のリクエスト数
入力トークンも含めて数える場合もあるので、「出力トークンのみか」「入力＋出力か」も確認しましょう。
指標どうしのトレードオフ
ここが一番大事なポイントです。Throughputを上げようとすると、1人あたりの体験（TPS・TTFT）は悪くなりがち です。
- バッチサイズ（同時リクエスト数）を増やす → GPUを効率よく使えるので Throughputは上がる
- その代わり、1ステップあたりの計算が重くなる → ITLが伸び、1人あたりTPSは下がる
- さらに混雑するとキューで待たされる → TTFTも伸びる
そのため、用途によって重視する指標が変わります。
| 用途 | 重視する指標 |
|---|---|
| チャットUI・対話アプリ | TTFT（最初の反応）、ITL（表示のなめらかさ） |
| 音声対話・リアルタイム処理 | TTFT、ITL（とくに p99） |
| エージェント・ツール呼び出し | TTLT（結果が揃うまでの時間） |
| 大量データの一括処理 | Throughput（コスト効率） |
| サービス運用（SLO設計） | 「TTFT p90 ≦ ○秒を守れる範囲での最大Throughput」 |
具体例で計算してみる
次のようなリクエストを考えます。
- TTFT = 0.5 秒
- ITL = 20 ミリ秒（毎トークン一定と仮定）
- 出力トークン数 = 500
TTLT = 0.5 + 0.02 × (500 − 1) = 0.5 + 9.98 = 10.48 秒
TPOT = (10.48 − 0.5) / (500 − 1) = 0.02 秒 = 20 ミリ秒
TPS（デコード） = 1 / 0.02 = 50 tok/s
TPS（全体） = 500 / 10.48 ≈ 47.7 tok/s
この状態のリクエストが20本同時に流れていれば、出力のThroughputはおおよそ 50 × 20 = 1,000 tok/s です（実際にはバッチが大きくなるとITLが伸びるので、単純な掛け算より小さくなります）。
まとめ
- TTFT: 最初のトークンまでの待ち時間。体感の「反応の速さ」
- ITL: トークン同士の間隔。表示の「なめらかさ」（平均はTPOT）
- TTLT: 最後のトークンまでの時間。結果が「揃うまで」の時間
- TPS: 1リクエストの出力速度。定義が2通りあるので注意
- Throughput: サーバー全体の処理量。上げすぎると1人あたりの体験が悪化する
ベンチマーク結果を見るときは「どの区間を測っているか」「平均か分位点か」「同時実行数（バッチサイズ）はいくつか」の3点を確認すると、数字の意味を正しく読み取れます。