3行でいうと
- TTFTは「依頼から最初の1トークンまで」。ITLは「最初の1つを除いた、トークン間の平均間隔」
- 「1秒あたりのトークン数」には、システム全体と1人あたりの2種類があり、別の数字になる
- 同時処理を増やすと全体の処理量は増えるが、ある点から待ち時間だけが伸びる
この記事は、実際に使って確かめた記録ではありません。この記事は公式の文書を読んでまとめたものです。
先に結論
- 速さの数字は、少なくとも4つに分かれます。最初の文字が出るまでの時間（TTFT）、出始めてからの間隔（ITL）、1秒に出るトークン数（TPS）、同時にさばける数（同時実行数）です。
- 「速い」と言われたら、どの指標かを聞くのが先です。TTFTが短くてもITLが長ければ、出だしは速いのに最後まで遅く感じます。
- ツールによって定義が少し違います。同じ名前の数字でも、別のツールで測った値をそのまま比べないほうが安全です。
前提：AIの返答はどう作られるか
- トークンは、AIが読み書きする文字の量を数える単位です。この記事の速さの数字は、すべてトークンで数えます。
- NVIDIAの技術ブログによると、AIの処理は2つの段階に分かれます。プリフィル（入力された文章を全部まとめて読み込む段階）と、デコード（返答を1トークンずつ順に書く段階）です。
- プリフィルは、並列に計算できるのでGPU（AI用の計算チップ）をよく使います。デコードは1ステップごとに1トークンしか作れず、計算より「メモリからのデータ転送」が時間を決める（メモリ律速）と書かれています。
- デコードでは、過去のトークンの計算結果をKVキャッシュ（途中の計算結果を保存しておく領域）に置き、毎回の計算をやり直さずに済ませます。
- 複数の依頼をまとめて処理することをバッチ処理と呼びます。NVIDIAの資料は、終わった依頼をすぐ外して新しい依頼を入れる「連続バッチ（in-flight batching）」が、GPUの使用率を大きく上げると説明しています。
この2段階があるため、「最初の1文字まで」と「その後の流れ」は、別々の理由で遅くなります。
4つの指標の定義
NVIDIAのブログ（2025年4月公開、2025年8月更新）とNVIDIA NIMの測定ドキュメント、vLLMの文書を読んで、同じ定義が出ているものを表にしました。
| 指標 | 公式資料での意味 | 主に影響するもの |
|---|---|---|
| TTFT（Time to First Token） | 依頼を送ってから、最初のトークンを受け取るまで | 順番待ち、プリフィル、通信。入力が長いほど伸びる |
| ITL（Inter-Token Latency）／TPOT（Time Per Output Token） | 連続するトークンの間の平均時間 | デコードの速さ |
| e2e（end-to-end）遅延 | 依頼を送ってから、最後のトークンを受け取るまで | TTFTとデコード全体の合計 |
| TPS（Tokens Per Second） | 1秒に出るトークンの数 | 測る単位（システム全体か1人か）で別の数字 |
| RPS（Requests Per Second） | 1秒に完了する依頼の数 | 同時処理の数、出力の長さ |
NVIDIAの資料の式は次のとおりです。
- e2e遅延 = TTFT + 生成時間（最初のトークンから最後のトークンまで）
- ITL = （e2e遅延 − TTFT）÷（出力トークンの総数 − 1）
- 1人あたりのTPS = 出力トークン数 ÷ e2e遅延
- システム全体のTPS = 出力トークンの総数 ÷（最後の応答の時刻 − 最初の依頼の時刻）
ITLの分母から1を引くのは、最初のトークンはTTFTに入っているので、ITLは「デコードの部分だけ」を表すようにするため、とNIMの文書に書かれています。
同じ名前でも定義が違う例
- NVIDIAのブログは、GenAI-PerfというツールがITLに最初のトークンを含めない一方、LLMPerfというツールはTTFTを含めて平均するため、同じ名前でも値が違うことがある、と書いています。
- vLLMの文書では、ITLとTPOTは別の指標です。ITLは「ストリームで届いた出力と出力の間の時間」、TPOTは「1つの依頼のデコード時間を出力トークン数で割った値」です。投機的デコード（先読みで複数トークンをまとめて出す方式）では1回の出力に複数トークンが入るので、2つの値が違ってきます。
- vLLMの文書の例では、ITLが40ミリ秒のものが2つあれば平均ITLは40ミリ秒ですが、同じ依頼でTPOTを（180ミリ秒 − 100ミリ秒）÷（5 − 1）で計算すると20ミリ秒になります。
- vLLMの監視用の指標では、出力が1トークン以下の依頼のTPOTは0として記録されます。ベンチマーク用コマンドの
vllm bench serveは、それらを除いて統計を作るため、両者の数字が合わないことがあります。
数字の読み方の例
見立てです。次の例は説明用に僕らが作った数字で、どのAIの実測値でもありません。
返答が500トークン、e2e遅延が10秒、TTFTが1秒だったとします（僕らの計算です）。
- ITL =（10 − 1）÷（500 − 1）= 約0.018秒（18ミリ秒）
- 1人あたりのTPS = 500 ÷ 10 = 50トークン/秒
- 1 ÷ ITL = 約55トークン/秒
1人あたりのTPSは、出力が長くなるほど「1 ÷ ITL」に近づく、とNVIDIAのブログが説明しています。短い返答ではTTFTの割合が大きく、50と55のように少しずれます。
このため、短い質問への返答が多い使い方ではTTFT、長い文章や推論の長い出力を作る使い方ではITLとTPSが体感を決める、と言えそうです。NVIDIAのブログは、用途別の目安として、要約は入力が約1,000トークンで出力が約100トークン、推論は入力が約100トークンで出力が1,000〜1万トークンと挙げています。これは用途の傾向を示す目安で、規格ではありません。
同時処理が増えると何が起きるか
同時実行数は、同時に1つの依頼を出している利用者の数です。NVIDIAの資料では、各利用者が前の依頼が終わるとすぐ次を送る前提で、システムの中にはいつも同じ数の依頼が入っています。
- 同時実行数を増やすと、システム全体の処理量（RPSやシステム全体のTPS）は増えます。最初は、待ち時間をあまり増やさずに処理量が上がります。
- あるところから、処理量はほぼ頭打ちで、待ち時間だけが伸びます。NVIDIAの資料は、同時実行数が最大バッチサイズを超えると順番待ちが起き、TTFTが伸びる、と説明しています。
- 1人あたりのTPSは、同時実行数が増えると下がります。
NVIDIAのGenAI-Perfの解説（2025年5月公開）は、1、2、5、10、50、100、250の同時実行数で測った例を示しています。その例では、50のあたりで、処理量はほとんど増えないのに待ち時間が急に伸びる点がある、と述べています。ただし、記事は図の元の数値を公開していないので、具体的な秒数やRPSは確認できていません。
選び方として、この記事は次の手順を紹介しています。
- 先に許せる待ち時間（たとえばTTFTの上限）を決める。
- 図の横軸でその値を見つけ、その範囲で一番処理量が高い同時実行数を読む。
- 待ち時間が急に伸びて処理量が増えない領域は避ける。
測定ツールごとの式の違いと、全体の処理量の測り方
NVIDIAのブログとNIMの文書は、システム全体のTPSを「出力トークンの総数 ÷（最後の応答の時刻 − 最初の依頼の時刻）」と定義しています。ここにはいくつか注意があります。
- 分子は出力トークンだけです。入力トークンは入りません。vLLMのベンチマークの出力例には、出力トークンの処理量と、入力を含めた処理量の両方があり、別の値として表示されます。
- LLMPerfというツールは、分母に、プロンプトの生成、依頼の準備、応答の保存といった、AIの処理以外の時間を含めます。NVIDIAのブログは、同時実行数が1のときには、これが全体の33%にもなりうる、と書いています。
- NIMの文書は、AIPerfというツールでは、中身が空の最初の応答はTTFTに数えず、最後の
[done]の合図もe2e遅延から除く、と説明しています。 - 同じ文書は、システム全体のTPSは「終わった後にまとめて出す」性質で、リアルタイムの指標ではなく、ウォームアップ（測定前の慣らし運転）を除く設定もできる、と書いています。
vLLMの文書で、運用中のサーバーの指標として挙がっているものは次のとおりです。
vllm:time_to_first_token_seconds：到着からの時間で、入力の処理時間を含むvllm:inter_token_latency_seconds：ストリームの出力ごとの間隔vllm:request_time_per_output_token_seconds：依頼ごとのTPOTvllm:e2e_request_latency_seconds：到着から最後のトークンまでvllm:request_queue_time_seconds、vllm:request_prefill_time_seconds、vllm:request_decode_time_seconds：順番待ち、プリフィル、デコードの時間
同じ文書は、処理量を直接表す名前付きの指標はなく、トークン数の累計の指標（vllm:prompt_tokens_total、vllm:generation_tokens_total）から秒あたりを計算する形だと説明しています。
「速くする」ための公式の考え方
OpenAIの遅延の最適化ガイドには、7つの原則があります。ここでは、速さの指標との関係が深いものを紹介します。
- 出力トークンを減らす：ガイドは、出力は通常いちばん遅い段階で、出力を50%減らすと遅延も約50%減りうる、と述べています。デコードが1トークンずつだからです。
- 入力トークンを減らす：効果は思ったより小さい、とあり、プロンプトを50%減らしても遅延の改善は1〜5%程度かもしれない、とされています。非常に長い文書や画像のときだけ、入力を減らす価値が大きい、という説明です。
- ストリーミング：ガイドは「最も効果的な方法」と呼んでいます。完成を待たず、できたところから表示するので、「待っている」時間が1秒以下にできるという説明です。体感する待ち時間（TTFT）を短くする話で、全体の処理が速くなるわけではありません。
- 小さいモデルに替える、依頼の回数を減らす、独立した処理を並列にする、といった項目もあります。
見立てです。TTFTとITLの区別を知ると、これらの原則がなぜ効くのかが読みやすくなります。出力を減らす対策はデコードの回数を減らすのでITLの合計に効き、ストリーミングは体感のTTFTに効く、という整理です。
選び方・判断の基準
見立てです。公式資料の定義を元にした、僕らの整理です。
- チャットのように人が待つ用途：TTFTと、1人あたりのTPS（人が読むより速く出るか）を見る。
- 大量のデータを一括で処理する用途：システム全体のTPSかRPSを見る。ここでは1件ごとの待ち時間は二の次になる。
- 比較表を見るとき：同じツール、同じ入力と出力の長さ、同じ同時実行数で測られたかを確認する。条件が書かれていない数字は、そのまま比べない。
よくあるつまずき
見立てです。公式資料を読んで、読み違えやすいと思った点を挙げます。
- 「1秒に○○トークン」が、システム全体の数字か、1人あたりの数字かを確かめずに読む。同時実行数が増えると、全体は増え、1人あたりは下がるので、片方だけでは「速い」とは言えません。
- ITLとTPOTを同じものとして扱う。多くの場合は近い値ですが、vLLMの文書は、投機的デコードで違ってくると書いています。
- 短い返答でITLだけを見る。出力が数トークンの場合は、TTFTが体感のほとんどを決めます。
- 入力を短くすれば劇的に速くなると期待する。OpenAIのガイドは、効果は1〜5%程度の場合もあると述べています。
気をつけること
- この記事は、実際に使って確かめた記録ではありません。数値の例は、説明のために作った計算です。
- 定義はツールとバージョンで変わります。NIMの文書もバージョン別のページがあり、この記事では「latest」のページを読みました。
- NVIDIAの2本のブログは2025年の公開です。指標の考え方は変わりにくい分野ですが、ツールの機能や名前は更新されている可能性があります。
- 各社のAPIが公開している速さの数字（「1秒に○○トークン」など）は、今回、公式の料金ページや仕様ページで確認していません。この記事で扱ったのは、測り方の定義です。
- OpenAIのガイドには古いモデルを使った例も載っていますが、ここでは原則の部分だけを紹介しました。
- GPUの種類、モデルの大きさ、入力の長さによって、数字は大きく変わります。同時実行数の最適な値は、環境ごとに測らないと分かりません。
出典
- LLM Inference Benchmarking: Fundamental Concepts（NVIDIA Technical Blog、NVIDIA、2025年4月公開、2026年10月8日確認）
- Metrics（NVIDIA NIM LLM Benchmarking、NVIDIA、2026年10月8日確認）
- LLM Performance Benchmarking: Measuring NVIDIA NIM Performance with GenAI-Perf（NVIDIA Technical Blog、NVIDIA、2025年5月公開、2026年10月8日確認）
- Mastering LLM Techniques: Inference Optimization（NVIDIA Technical Blog、NVIDIA、2026年10月8日確認）
- Metrics（vLLM Docs、vLLMプロジェクト、2026年10月8日確認）
- Benchmark CLI（vLLM Docs、vLLMプロジェクト、2026年10月8日確認）
- Latency optimization（OpenAI API Docs、OpenAI、2026年10月8日確認）
更新履歴
- 2026年10月25日 書き方を直しました。
- 前：運営者が使っていないと読める書き方 → いま：「この記事は、実際に使って確かめた記録ではありません」。公式の資料を読んでまとめた記事で、使い心地は書いていない、という意味に直した