1秒あたりのトークン数の仕組み
基本的な計算式は次のとおりです。
TPS = 数えたトークン数 / 経過秒数
推論中、言語モデルは出力としてトークンを生成します。その速度を測定することは簡単そうに見えますが、ベンチマークでは次の3点を決める必要があります。 as its output. Measuring their rate sounds simple, but a benchmark must make three choices:
- 誰のトークンか？1つのリクエストだけか、システム上で同時実行されているすべてのリクエストか。
- どのトークンか？出力トークン、入力トークン、それとも両方か。
- どの秒数か？最初のトークン後の生成期間だけか、リクエスト全体の時間か、それともベンチマークの全期間か。
これらの選択により、2つの一般的な意味が生じます。
リクエスト単位の出力速度は、1つの応答が始まった後、どれだけ速くストリーミングされるかを表します。多くの場合、最初の待ち時間を除外し、出力トークン間の間隔から計算します。これは、テキストが表示される間に人が目にする速度に最も近いTPSです。
システム出力TPSは、すべてのリクエストの出力トークンを合計し、ベンチマーク期間で割ったものです。デプロイメント全体の生成能力を測定します。NVIDIAのベンチマーク定義とAnyscaleのメトリクスガイドは、この2つの範囲を区別しています。負荷が変化すると、両者は反対方向に変化することがあるためです。
また、プロンプト処理を測定する入力TPSや、入力トークンと出力トークンを合わせた合計TPSを目にすることもあります。値を比較する前にラベルを確認してください。入力処理と出力生成は、どちらもトークンを使いますが、異なる処理です。
計算例
0.0秒でリクエストを送信したとします。出力トークンは41個生成されます。0.0 s. It produces 41 output tokens:
- 最初のトークンは
0.4秒で到着します。 - 最後のトークンは
2.4秒で到着します。 - 最初のトークン後の40個の間隔は
2.0秒にわたります。
定常状態での出力速度は次のとおりです。
40個の間隔 / 2.0秒 = 20 tok/s
リクエスト全体を含めるツールでは、代わりに次のように計算することがあります。
41個の出力トークン / 2.4秒 = 17.1 tok/s
この2つの結果は、同じ応答から得られたものです。前者は出力開始後の生成を分離しています。後者は最初の待ち時間を含み、すべての出力トークンを使っています。現在のドキュメントには、単一の普遍的な慣例はありません。Artificial Analysisは出力速度から最初のトークンまでの待ち時間を除外していますが、エンドツーエンドのメトリクスの中にはそれを含めるものもあります。
次に、範囲を変えてみましょう。5秒間のベンチマーク中に、複数の同時実行リクエストが合計400個の出力トークンを生成したとします。
400個の出力トークン / 5秒 = 80 system tok/s
この80 tok/sは合算された能力を表します。個々の応答が80 tok/sでストリーミングされたことを意味するものではありません。
1秒あたりのトークン数が重要な理由
リクエスト単位のTPSは、生成が始まってから長い応答がどれだけ速く届くかを判断するのに役立ちます。チャット、コード生成、そして回答が完了する前にストリーミングされた回答を処理するあらゆるワークフローで重要です。
システムTPSは、容量とコストの計画に役立ちます。指定した負荷の下で、デプロイメントがどれだけの出力を生成できるかを示します。同時実行数を増やすと、ハードウェアをより効率的に使えるため、この合算レートは向上する可能性がありますが、各リクエストは遅くなることもあります。容量の大きいシステムが、1人のユーザーにとって自動的に速い体験を提供するとは限りません。
TPSだけでは、応答時間の全体像は分かりません。リクエスト単位のTPSには、出力が始まるまでの待ち時間を測定する最初のトークンまでの時間を組み合わせてください。システムTPSには、推論スループットと負荷下のレイテンシを組み合わせます。デプロイメントは、アプリケーションの応答時間要件を満たしながら、十分な処理量を生成できて初めて有用です。
TPSの結果を変える要因
TPSはモデル名だけで決まるものではなく、測定対象となる構成の特性です。次の要因によって変化します。
- モデルのアーキテクチャとサイズ
- ハードウェアとデバイス数
- 推論エンジン、数値精度、キャッシュ、デコード方式
- プロンプトと出力の長さ
- 同時実行数、バッチ処理、リクエストレート、その他のトラフィックパターン
- トークンのカウントに使うトークナイザー
- ストリーミングチャンクやネットワーク配信など、クライアント側の影響
長いプロンプトは、初期の待ち時間と、その後の出力速度の両方に影響する可能性があります。また、サービス提供エンジンが投機的デコードなどの手法を使う場合、生成される内容によって出力速度が変わることもあります。そのため、再現可能な結果には、モデルとエンドポイント、ワークロードの形状、負荷、トークナイザー、正確な計算式を明記する必要があります。vLLMのベンチマークドキュメントは、メトリクス名だけでなく、測定点と計算式を比較することを推奨しています。
よくある誤解
「TPSで、回答がいつ始まるか分かる」
TPSは通常、生成中またはベンチマーク期間全体の速度を表します。最初のトークンが出るまでの何も表示されない待ち時間を分離するものではありません。2つのシステムの出力TPSが同じでも、最初のトークンまでの時間は大きく異なる可能性があります。
「システムTPSが高いほど、自分への応答も速い」
必ずしもそうではありません。より多くのリクエストを同時に処理すると、システム全体のTPSは上がる一方で、各リクエストがトークンを受け取る頻度は下がることがあります。結果がリクエスト単位か合算値かを確認してください。
「トークンは単語である」
トークンは、目に見えるテキストの固定単位ではありません。トークナイザーによって同じ文の分割方法が異なるため、同じtok/sの値でも、対応するテキスト量は異なる可能性があります。このため、モデル間のベンチマークでは、共通のトークナイザーで出力を再トークン化することがあります。
「TPSは標準化された単一のメトリクスである」
強制的に統一された定義はありません。TPSは最初のトークンまでの待ち時間を含める場合も除外する場合もあり、出力トークンだけを数える場合も、入力と出力の両方を数える場合もあります。必ず計算式を確認してください。
次に読む項目
応答の遅延を理解するには推論レイテンシ、初期の待ち時間を理解するには最初のトークンまでの時間、サービス提供能力の合計を理解するには推論スループットを使ってください。4つの測定値の境界については、レイテンシ vs. TTFT vs. 1秒あたりのトークン数 vs. スループットを参照してください。