レイテンシーは1つの推論リクエストにかかる時間、TTFTはストリーミングリクエストが応答を開始するまでの時間、1秒あたりトークン数は1つのストリームまたはシステム全体を表し得る速度、スループットはシステムが時間あたりに完了する総作業量です。最も重要な違いは対象範囲です。レイテンシーとTTFTは1つのリクエストを計測するのに対し、スループットは測定時間内の作業量を数えます。

「1秒あたりトークン数」という表現には特に注意が必要です。これは単位を示すだけで、完全なメトリクスではありません。どのトークンを数え、どの時間間隔を使ったのかを確認する必要があります。

各メトリクスが測定するもの

推論レイテンシー

推論レイテンシーとは、1つのリクエストにかかる経過時間です。生成された応答の場合、「エンドツーエンドレイテンシー」は通常、リクエストを送信または受信してから最終出力を受信するまでを指します。

次の問いに答えるものです：このリクエストが完了するまでどのくらいかかるか？

この境界は普遍的なものではありません。クライアント側の測定には、ルーティング、ネットワーク転送、キュー待ち、応答処理が含まれる場合があります。推論サーバーは、これらの一部が終わった後に計測を開始することもあります。「レイテンシー」とだけ記載されたベンチマークでは、その数値を再現するための情報が不足しています。

レイテンシーは出力長にも直接依存します。短い応答と長い応答でTTFTと生成速度が同じでも、長い応答のほうが完了までに時間がかかります。

Time to first token

Time to first token（TTFT）は、リクエストの境界から、ストリーミング応答で最初の空でない出力トークンが届くまでの時間です。

次の問いに答えるものです：応答が表示され始めるまでどのくらいかかるか？

TTFTには通常、キュー待ち、入力処理、プロンプトに対するモデルのプレフィル処理、最初のトークンの生成、選択した境界内に含まれるネットワーク時間が含まれます。これはエンドツーエンドレイテンシーの一部であり、その別名ではありません。

TTFTが短いと、インターフェースは応答性が高く感じられます。しかし、それだけでは応答の残りがどれだけ滑らかに届くか、また応答がいつ完了するかは分かりません。

1秒あたりトークン数

1秒あたりトークン数とは、出力トークン数を経過秒数で割ったものです。製品比較では、最初のトークンの後における1つのリクエストの生成速度を意味することがよくあります。

次の問いに答えるものです：生成が始まった後、生成テキストはどのくらいの速さで届くか？

出力トークンが(N)個の応答では、最初のトークンと最後のトークンの間に(N-1)個の間隔があります。その間隔に(G)秒かかる場合、最初のトークン後の速度は次のとおりです：

[\n\\text{リクエスト単位の生成速度} = \\frac{N-1}{G}\n]

これは、測定される各イベントに1トークンが含まれる場合の、出力トークン間隔あたりの平均時間の逆数です。実際のストリーミングAPIでは、複数のトークンを含むチャンクが配信されることがあるため、クライアントはイベントごとに1トークンと仮定せず、トークンを数える必要があります。

ツールによっては、すべての出力トークン数をリクエスト全体のエンドツーエンドレイテンシーで割ります。また、同時実行中のすべてのリクエストのトークンを合算する場合もあります。これらはすべてTPSまたはtokens/sと表示され得ますが、異なる選択によって異なる数値になります。

推論スループット

推論スループットとは、明示されたワークロードのもとで、システムが単位時間あたりに完了する総作業量です。出力トークン数/秒、総トークン数/秒、リクエスト数/秒、サンプル数/秒、またはワークロードに適した別の単位で測定できます。

次の問いに答えるものです：システムはどれだけの負荷を処理できるか？

スループットは集約的な特性です。テスト時間と負荷パターンが必要になります。同時実行数、リクエスト到着率、プロンプト長と応答長、バッチ処理、レプリカ数、失敗したリクエストの扱いなどによって変化します。

リクエストスループットとトークンスループットは互換ではありません。サーバーは、同じ出力トークン数/秒を生成しながら、多数の短いリクエスト、または少数の長いリクエストを完了できます。

実際の違い

MetricClock stops atTypical scopeTypical unitThe question it answers
LatencyFinal response outputOne requestms or s/requestWhen is this request finished?
TTFTFirst content tokenOne streamed requestms or s/requestWhen does the answer begin?
Tokens per secondDepends on the stated formulaOne request or the whole systemoutput tokens/sHow fast are tokens arriving, and for whom?
ThroughputEnd of a test intervalSystem or deploymenttokens/s, requests/s, or samples/sHow much work is completed under load?

報告された結果のほとんどは、次の3つの問いで明確にできます：

  1. 何を数えているか？出力トークン、すべてのトークン、完了したリクエスト、またはサンプルのどれか？
  2. 時計はどこで開始し、どこで停止するか？クライアントでの送信、サーバーでの受信、最初のトークン、最後のトークン、または固定されたテスト境界のどれか？
  3. 対象範囲はどこまでか？1つのリクエスト、1人のユーザー、1つのレプリカ、または同時負荷下にあるデプロイメント全体のどれか？

ベンチマークがこの3つすべてに答えられないなら、その数値は比較に使える状態ではありません。

具体例

出力トークンを81個返す1つのリクエストを考えます：

  • リクエストは0.0秒に送信されます。
  • 最初のトークンは0.8秒に到着します。
  • 最後のトークンは2.8秒に到着します。

このリクエストのTTFTは0.8秒です。エンドツーエンドレイテンシーは2.8秒です。最初のトークン後の生成には2.0秒かかり、トークン間隔は80個あるため、最初のトークン後の速度は毎秒40トークンです。

あるツールが81個すべての出力トークンを数え、完全な2.8秒のレイテンシーで割ると、約毎秒29トークンと報告します。これは数学的な不一致ではありません。時計の境界と分子が異なるだけです。

次に、1台のサーバーへ多数のリクエストを送ります。10秒間のテスト時間内に、サーバーが出力トークンを3,000個生成し、50件のリクエストを完了したとします：

  • 出力トークンスループット：(3{,}000 / 10 = 300) トークン/秒
  • リクエストスループット：(50 / 10 = 5) リクエスト/秒

サーバーの毎秒300トークンという値は、アクティブなリクエスト全体の出力を合算したものです。個々のユーザーは、毎秒40トークン、または負荷の増加によってキュー待ちやデコード遅延が増えれば、それ以下の速度で出力を受け取る可能性があります。

各メトリクスが重要になる場面

チャットインターフェース、コーディングアシスタント、その他のストリーミング対話では、TTFTが初期の待ち時間を表します。リクエスト単位の生成速度、またはその逆数である出力トークンあたりの時間が、その待ち時間後のペースを表します。ユーザーや別のプログラムが次に進む前に完全な回答を必要とする場合は、エンドツーエンドレイテンシーが重要です。

バッチジョブでは、通常TTFTよりスループットが重要です。失敗と出力品質が許容範囲内である限り、ジョブが重視するのは総完了速度です。

キャパシティプランニングでは、レイテンシー目標と併せてスループットを使います。同時実行数を増やすと、ハードウェアがより多くの処理を並列に行うため、最初は集約スループットが向上することがあります。同じ同時実行数でも、キュー待ちが増え、各ユーザーの速度が低下する可能性があります。飽和後は、レイテンシーが上昇し続ける一方で、スループットが横ばいになるか低下することがあります。

非ストリーミングAPIでは、応答が完了時にのみ配信されるため、クライアントからTTFTを観測できない場合があります。サーバーは内部ステージを測定できますが、クライアントから見えるパフォーマンスはエンドツーエンドレイテンシーです。

混同される理由

TTFTが低くてもレイテンシーが低いとは限らない

応答がすぐに始まっても、その後の生成が遅い場合があります。TTFTが捉えるのは最初の節目だけです。合計レイテンシーには、残りの生成時間も含まれます。

最初のトークン後を明示的に定義する場合、関係は次のようになります：

[\n\\text{エンドツーエンドレイテンシー} = \\text{TTFT} + (N-1)\\times\\text{出力トークン間隔あたりの平均時間}\n]

実装によって数え方が異なるため、あるメトリクスから別のメトリクスを再構成する前に、ベンチマークの式を確認してください。

1秒あたりトークン数がスループットになる場合

「1秒あたりトークン数」は、1人のユーザーの生成速度を意味することがあります。また、集約された出力トークンスループットの単位である場合もあります。ラベルだけでは両者を区別できません。

「リクエストあたり」、「ユーザーあたり」、「ストリームあたり」、「集約」、「システム」などの修飾語を探してください。何もなければ、式とテスト設定を確認します。

スループットが高くてもリクエストが速いとは限らない

サーバーは多数のリクエストをバッチ処理して毎秒の総トークン数を増やせても、各リクエストの待ち時間が長くなったり、トークンが届く間隔が長くなったりする場合があります。そのため、信頼できるサービングテストでは、スループットをレイテンシーのパーセンタイルと併せて報告するか、定められたサービス目標を満たしながら完了した作業量であるグッドプットを計算します。

異なるワークロードでは異なる結果になる

TTFTはプロンプト長とキュー待ちによって変化します。エンドツーエンドレイテンシーは応答長によって変化します。スループットは同時実行数、到着パターン、バッチ処理、ハードウェア割り当てによって変化します。トークン速度は、出力のカウントに使用するトークナイザーにも依存します。

システムを比較する際は、モデルの挙動、プロンプトと出力の分布、負荷パターン、ストリーミングモード、サンプリング設定、トークナイザー、測定境界、成功条件を同じにしてください。アイドル状態の1リクエストでのテストは、飽和状態のサーバーでのテストとは異なるものを測定します。

平均値では、ユーザーが記憶するリクエストが隠れる

平均TTFTや平均レイテンシーが健全に見えても、一部のリクエストがキュー内で大幅に長く待たされている可能性があります。関連するテールパーセンタイルを含む分布と、観測数を報告してください。スループットについては、成功した作業だけを数えたことを明示せずに済ませるのではなく、エラーと拒否されたリクエストも報告します。

推論ベンチマークの読み方

グラフやモデルカードの主張を信頼する前に、次の事項が記載されていることを確認してください：

  • 1秒あたりトークン数がリクエスト単位か集約値か；
  • 出力トークンのみを数えているか、入力と出力のトークンを合算しているか；
  • TTFTまたは最初のトークンをトークン速度の計算に含めているか；
  • レイテンシーがクライアント側、サーバー側、またはモデルのみの値か；
  • プロンプト長と出力長の分布；
  • 同時実行数とリクエストの到着パターン；
  • ウォームアップ、テスト時間、開始・終了境界の扱い；
  • 単一の平均値だけでなく、平均レイテンシーとテールレイテンシー；
  • 成功したリクエストとエラーの判定基準；
  • モデル、精度、ハードウェア、エンジン、レプリカ数。

最適なメトリクスは、この4つのうち単独の1つではありません。現実的な負荷のもとで、すべての境界を明示して測定し、ユーザーに見える目標または運用上の目標に合致するメトリクスこそが最適です。

次に読むもの

「推論レイテンシーとは？」ではリクエストの時間境界を、「Time to First Tokenとは？」ではストリーミング応答開始までの遅延を、「1秒あたりトークン数とは？」ではトークン速度の式を、「推論スループットとは？」では負荷下におけるシステムの処理能力を解説しています。