TTFTの仕組み
TTFTの測定には、2つのタイムスタンプが必要です。
TTFT ＝ 最初の出力時刻 − リクエスト開始時刻
式は単純です。しかし、どのタイムスタンプを選ぶかは単純ではありません。
クライアントが観測するTTFTは、クライアントがリクエストを送信した時点から、コンテンツを含む最初のトークンまたはストリーミングチャンクを受信した時点までです。この区間には、次の処理が含まれる場合があります。
- サービスへのリクエストの送信。
- 認証、ルーティング、キューイング。
- プロンプトのトークン化。
- プロンプト全体の処理。この段階はprefillと呼ばれます。
- 最初の出力トークンの選択。
- その出力の変換とクライアントへの返送。
prefillでは、モデルが入力を処理し、後続のトークン生成時に再利用する保存済みのアテンション情報を準備します。通常、プロンプトが長いほどprefillの処理量は増えます。サービスが混雑している場合は、その処理が始まる前にキューイングが追加されることがあります。
エンジンレベルのTTFTでは、より狭い境界を使用する場合があります。たとえば、vLLMのサーバーメトリクスはフロントエンドへの到着時点、現在はトークン化の開始時点から測定します。そのため、クライアント側のネットワーク経路や上流アプリケーションで行われた処理は含まれません。
このため、TTFTは普遍的に比較できる単一の数値ではありません。NVIDIAのベンチマークドキュメントでは、クエリの送信から最初のトークンを受信するまでと定義しています。一方、Google Cloudの用語集では、モデルがプロンプトを受け取ってから最初のトークンを生成するまでと説明しています。どちらの規約も有用ですが、リクエストの異なる部分を測定しています。
計算例
あるストリーミングリクエストのタイムラインが次のようになっているとします。
- 0 ms：クライアントがプロンプトを送信し、タイマーを開始します。
- 40 ms：サービスがリクエストを受信します。
- 110 ms：キューイングが終了し、処理が始まります。
- 350 ms：プロンプトの処理が完了し、最初のトークンが生成されます。
- 390 ms：クライアントがコンテンツを含む最初のチャンクを受信します。
クライアントが観測するTTFTは390 msです。
リクエストの到着時点から始まり、トークンの生成時点で終わるサーバー側の測定値は310 msです。これは350 msから40 msを引いた値です。
80 msの差は、測定範囲の違いによるものです。どちらかのタイマーが不正確だということではありません。
同じ例から、TTFTを総レイテンシとして解釈してはいけない理由も分かります。生成は390 msの時点以降も続きます。後続トークン間の間隔や、最後のトークンに到達するまでの時間は、別の測定値です。
TTFTが重要になる場面と理由
TTFTは、出力を生成開始直後から利用できる場合に最も重要です。チャットインターフェース、コーディングアシスタント、ライブテキストシステムでは、最初のコンテンツが届いた後に進捗を表示できます。TTFTが短いほど、そのフィードバックが表示されるまでの無言の待ち時間が短くなります。
アプリケーションが完全な回答を待たなければならない場合、TTFT単独の重要性は低くなります。たとえば、バッチ要約ジョブでは、総完了時間や全体のスループットのほうが重要な場合があります。
リクエストの開始部分を調査するには、TTFTを使用します。高い値は、長いプロンプト、プロンプトキャッシュを利用できなかったこと、高負荷時のキューイング、コールドワーカー、フロントエンドのオーバーヘッド、またはネットワーク距離を示している可能性があります。TTFTだけでは、どの段階が原因なのかは分かりません。トレースや、キューイング、prefill、ネットワークの個別の測定値と組み合わせてください。
システムを比較する場合は、ワークロードを一定に保ちます。同じプロンプト長の分布、キャッシュ状態、同時実行数、ストリーミング動作、クライアントの場所、開始イベントと終了イベントを使用してください。特に速かった1件のリクエストではなく、中央値やテールパーセンタイルなどの分布を報告します。この理由から、MLCommonsのベンチマーク手法では、定義されたシナリオを使用し、プロンプトフェーズのTTFTと生成フェーズの時間を分けて扱っています。
よくある誤解
TTFTが低くても、応答全体が速いとは限りません。システムがすぐに生成を開始しても、その後の生成が遅い場合があります。逆に、開始は遅くても残りの出力を速く生成するシステムもあります。
ストリーミングによって、モデルの計算時間が自動的に短縮されるわけではありません。ストリーミングでは、応答が完了する前にクライアントが部分的な出力を確認できます。サーバー、プロキシ、またはクライアントでバッファリングが行われると、モデルが最初のトークンを同じ時刻に生成していても、観測されるTTFTが長くなる場合があります。
最初のチャンクが常に1つのトークンとは限りません。ストリーミングプロトコルでは、複数のトークンを1つのイベントにまとめることがあります。目的が利用可能な出力の出現時点を測定することであれば、空のイベントやメタデータによってタイマーを停止してはいけません。
文脈なしに「良い」TTFTは存在しません。プロンプトの長さ、負荷、ハードウェア、キャッシュ、ネットワーク経路、測定境界のすべてが結果を変えます。目標値では、対象となるワークロードとパーセンタイルを明示する必要があります。
次に読む内容
TTFTをリクエスト全体のタイムラインの中に位置付けるには、「推論レイテンシとは？」を読んでください。最初のトークン到着後の生成速度については、「Tokens per Secondとは？」を読んでください。初期の待ち時間を生成速度やシステム容量と比較するには、「レイテンシ vs. TTFT vs. Tokens per Second vs. スループット」を使用してください。