AI APIレイテンシ指標：TTFT、最初の有効応答、出力速度
1本のリクエストタイムラインで、Upstream Header、最初のSSE Event、有効応答、可視テキスト、End-to-end Latency、出力速度を分けます。
AI APIのレイテンシは1つの数値ではありません。ストリーミングリクエストでは、アップストリームHeader、最初の空でないSSE Event、最初の有効なコンテンツまたはアクション、最初の可視テキスト、レスポンス完了の時刻を分けて記録します。それぞれ異なる問いに答えるため、すべてを「TTFT」と呼ぶべきではありません。
テキストだけのチャットでは、最初の可視テキストまでの時間が通常はユーザー向けレイテンシです。推論やツールを使うワークフローでは、推論メタデータや関数呼び出し引数という形で、有効な出力が先に現れる場合があります。出力開始後の生成速度は別の指標です。
指標に名前を付ける前にリクエストタイムラインを作る
クライアントまたはゲートウェイレベルのタイムスタンプには、単調時計と共通の起点を使います。ストリーミングリクエストは次のように表現できます。
t0 gateway receives request
t1 gateway starts upstream request
t2 upstream response headers arrive
t3 first non-empty SSE event arrives
t4 first effective content or action arrives
t5 first visible text delta arrives
t6 upstream body completes or closes
t7 gateway handler finishes
すべてのリクエストに、すべての時点が存在するわけではありません。非ストリーミングレスポンスには有用なSSEタイムラインがありません。Function Callだけのレスポンスは可視テキストを出さない場合があります。キャンセルされたStreamは開始していても正常完了しません。欠けている値はゼロではなく未設定として保存してください。ゼロにすると、そのEventが即時発生したと誤って表現されます。
Modelflareはリクエスト単位のメタデータをother.timingに記録します。各フィールドとタイムラインの対応は次のとおりです。
| フィールド | 測定内容 | 重要な境界 |
|---|---|---|
auth_ms |
Tokenとユーザーの認証時間 | ローカルフェーズの時間であり、アップストリーム時間ではない |
distribution_ms |
チャネル選択とルーティングポリシーの時間 | ローカルフェーズの時間 |
body_read_ms |
ダウンストリームRequest Bodyの読み取り時間 | ルーティング前の遅いアップロードを検出できる |
upstream_headers_ms |
アップストリームリクエスト開始からResponse Headerまで | 起点はアップストリーム開始であり、ゲートウェイ受信時点ではない |
first_sse_event_ms |
ゲートウェイ受信から最初の空でないアップストリームSSE Eventまで | Eventは有効な出力ではなくメタデータの場合がある |
first_response_ms |
ゲートウェイ受信から最初の有効なコンテンツまたはアクションDeltaまで | 可視テキスト、推論要約、関数引数、カスタムツール入力を含む |
first_text_delta_ms |
ゲートウェイ受信から最初の可視テキストDeltaまで | 可視ストリーミングテキストが実際に出た場合だけ存在する |
upstream_done_ms |
ゲートウェイ受信からアップストリームBodyの完了またはCloseまで | Closeしただけでは正常完了とは限らない |
total_handler_ms |
ゲートウェイ受信からRelayで把握できる最後の完了点まで | ゲートウェイ視点のEnd-to-end時間に最も近い |
visible_output_tps |
出力Token数を最初の可視テキストからアップストリーム完了までの時間で割った値 | 可視出力の診断値であり、システム全体のTPSではない |
この対応表により、起点が異なる値を直接引き算する誤りを防げます。たとえば、upstream_headers_msはアップストリームリクエスト開始からの時間ですが、first_response_msはゲートウェイがリクエストを受信した時点からの時間です。
TTFTには複数の実用的な意味がある
Time to First Tokenの一般的な定義は、クエリ送信から最初の出力Tokenを受信するまでの時間です。NVIDIA NIMベンチマーク指標ガイドでは、通常はネットワーク遅延、キュー待ち、Prompt Prefillを含み、内容のない初期レスポンスは数えないと説明しています。
この定義はテキスト生成ベンチマークには適しますが、現在のAPI Streamは可視テキストより前に複数種類のデータを送る場合があります。
- Response CreatedまたはメタデータEvent。
- 推論要約Delta。
- Function Call引数の断片。
- カスタムツール入力。
- 空のHeartbeatまたはプロバイダー固有のEnvelope。
Dashboardやインシデントレポートでは、明示的な名称を使います。
| 名称 | 推奨する意味 | 適した用途 |
|---|---|---|
| Time to Headers | リクエスト開始からアップストリームHeaderまで | ネットワーク、Proxy、アップストリームAdmissionの診断 |
| Time to First Event | リクエスト開始から最初の空でないSSE Eventまで | Transportの生存確認のみ |
| Time to First Effective Response | リクエスト開始から有効なコンテンツまたはアクションまで | Agentと推論ワークフローの応答性 |
| Time to First Visible Text | リクエスト開始からユーザーが描画できるテキストまで | チャットとユーザー体感の応答性 |
グラフに「TTFT」とだけ書く場合は、表のどの行を意味するか定義してください。そうしないと、2つのチームが同じリクエストについて異なる数値を報告し、どちらも正しいように見えてしまいます。
応答性と生成速度を分けて測る
End-to-endレイテンシは、リクエスト送信から完全なレスポンス受信までの時間です。選択した境界に応じて、キュー待ち、Prefill、Decode、ネットワーク転送、アップストリームStreamに現れるツール待ち、ゲートウェイ処理を含みます。
正常完了した単純なテキストStreamでは、次のように表せます。
end_to_end_latency = final_response_time - request_start_time
visible_generation_window = final_response_time - first_visible_text_time
visible_output_tps = output_tokens / visible_generation_window_seconds
Inter-token LatencyはTime per Output Tokenとも呼ばれ、通常は最初のToken以降の出力Token間隔の平均です。NVIDIA AIPerfの定義ではTTFTを除外し、残りの時間をoutput_tokens - 1で割ります。十分に長い出力では、その逆数が1ユーザーのDecode Throughputに近づきます。
SSE EventやText Deltaの数からToken単位のITLを計算しないでください。1つのEventに含まれるTokenはゼロ、1つ、複数のいずれもあり、Token境界はモデルのTokenizerにも依存します。Modelflareのvisible_output_tpsは記録された出力Token数と可視生成Windowを使います。TokenごとのEvent間隔やシステム全体のThroughputを表すものではありません。
各指標は別の問いに答えます。
- 最初のテキストが速く、出力速度が遅い場合、最初は反応してもその後が重く感じられる。
- 最初のテキストが遅く、出力速度が速い場合、長く待った後に一気に完了する。
- 1ユーザーの出力速度が低くても、高並列時のシステム総Throughputが低いとは限らない。
- Aggregate TPSが高くても、1ユーザーの良好なレイテンシは保証されない。
推論やツールは可視テキストより先に現れる
テキストだけのフローでは、first_response_msとfirst_text_delta_msがほぼ同じ場合があります。推論やFunction Callingでは、この差が重要です。
モデルが1.8秒でFunction Call引数を出し始め、その後アプリケーションまたはプロバイダー側のツール処理が続き、可視テキストが6.4秒で始まる例を考えます。システムは1.8秒で実行可能な結果を出していますが、ユーザーが文章を見るのは6.4秒です。両方をTTFTと呼ぶと、遅延が計画前、ツール処理中、回答描画前のどこで発生したか分からなくなります。
プロダクト体験に合わせてフィールドを解釈します。
- ターミナルAgentでは、最初の有効なアクションが最適な応答性指標になり得る。
- 文章だけを表示するチャットUIでは、最初の可視テキストがユーザー指標になる。
- コードが消費するTool Call APIでは、可視テキストが存在しない場合があり、必須にしてはいけない。
- 推論モデルでは、早いSSE Envelopeは接続の進行を示すだけで、有効な進行を証明しない。
AI APIストリーミングガイドでは、SSE解析、キャンセル、Idle Timeoutを扱っています。パーサーがEnvelopeと有効な出力を区別した後で、レイテンシ指標を計算します。
決まった順序で遅いフェーズを診断する
アップストリーム境界から始め、その後にローカルフェーズを確認します。リクエストの大部分がモデル待ちなのに、認証やルーティングを先に疑うことを避けられます。
| 症状 | 最初に見る指標 | 調べるべきレイヤー | 次の確認 |
|---|---|---|---|
| Header前が遅い | upstream_headers_ms |
ネットワーク経路、アップストリームAdmission、プロバイダーQueue、Proxy Route | チャネル、地域、ステータス、並列数を比較 |
| Headerは速いが有効出力が遅い | first_response_msから初期フェーズを除いた時間 |
モデルQueue、Prompt Prefill、推論、アップストリームScheduling | 入力Token、モデル、ルート、Inflight Countを比較 |
| 最初のEventは速いが有効出力が遅い | first_sse_event_msからfirst_response_msまでの差 |
メタデータだけのEvent、Heartbeat、推論開始 | 生の内容ではなく安全なEvent Typeを確認 |
| 有効なアクションは速いが可視テキストが遅い | first_response_msからfirst_text_delta_msまでの差 |
ツール/推論フェーズまたは回答構成 | 要求したツールと出力モードを確認 |
| テキスト開始後に生成が遅い | visible_output_tpsとupstream_done_ms |
Decode Throughput、競合、長いContext、ネットワークBackpressure | 出力長とチャネルInflight Countを比較 |
| アップストリーム指標はすべて正常 | auth_ms、distribution_ms、body_read_ms |
ローカル認証、ポリシー選択、クライアントUpload | 上昇しているフェーズだけを確認 |
単一指標だけで根本原因を証明することはできません。たとえば高いupstream_headers_msには複数の可能性が含まれ、ルート、地域、プロバイダー、並列負荷の証拠を組み合わせて切り分ける必要があります。
3つの合成Traceを読む
次の値は診断例であり、Modelflareの本番平均値やプロバイダーベンチマークではありません。
Trace A：アップストリームHeaderを待っている
| 指標 | 値 |
|---|---|
upstream_headers_ms |
6,100 ms |
first_sse_event_ms |
6,300 ms |
first_response_ms |
6,350 ms |
first_text_delta_ms |
6,400 ms |
total_handler_ms |
9,200 ms |
visible_output_tps |
42 |
待ち時間の大部分はHeader前に発生しています。可視テキスト開始後の生成は比較的良好です。クライアントRendererを最適化する前に、選択されたアップストリームルート、プロバイダーAdmission、ネットワーク経路、地域、並列負荷を確認します。
Trace B：有効なアクションが可視文章より早い
| 指標 | 値 |
|---|---|
upstream_headers_ms |
240 ms |
first_sse_event_ms |
310 ms |
first_response_ms |
2,900 ms |
first_text_delta_ms |
8,700 ms |
total_handler_ms |
10,200 ms |
visible_output_tps |
55 |
Transportは早い段階で動いており、2.9秒で有効なアクションも現れていますが、可視テキストまではさらに5.8秒かかっています。推論やツールを使うリクエストなら、そのフェーズを調べます。Header Timeoutを延ばしても、このパターンは改善しません。
Trace C：開始は速いが生成が遅い
| 指標 | 値 |
|---|---|
upstream_headers_ms |
260 ms |
first_sse_event_ms |
330 ms |
first_response_ms |
420 ms |
first_text_delta_ms |
430 ms |
total_handler_ms |
20,430 ms |
visible_output_tps |
9.8 |
テキストはすぐに表示されますが、その後の生成に約20秒かかっています。出力長、Context長、選択チャネル、Inflight Count、プロバイダー動作を比較します。First-output Timeoutは通過するため、この故障パターンは検出できません。
制御された条件でのみレイテンシを比較する
公平な比較では、ワークロード契約を一定に保ちます。最低限、次を記録してください。
- 正確なモデルIDとルートまたはグループ。
- 平均だけではなく、入力Tokenと出力Tokenの分布。
- ストリーミングまたは非ストリーミングモード。
- 有効にしたReasoning Effortとツール。
- 地域とクライアントからゲートウェイまでのネットワーク経路。
- 並列数または到着率。
- Sampling設定と最大出力長。
- Warmupポリシー、再試行ポリシー、除外した失敗。
- サンプル数、時間Window、Percentileの計算方法。
1つの平均値ではなくp50、p95、p99を比較します。失敗を除外しないでください。Timeoutやエラーを削除すると、信頼性の低いルートほど速く見える場合があります。異なるPrompt、出力長、並列数、エンドポイント動作で2つのプロバイダーを測定し、モデル速度ランキングとして提示してはいけません。
コンテンツではなく診断メタデータを保持する
レイテンシ診断にPrompt、Response、API Key、平文のクライアントIDを保存する必要はありません。有用なリクエスト記録には次を含められます。
- 生成したRequest IDとタイムスタンプ。
- モデル、グループ、選択チャネルの参照。
- ステータスと終了結果。
- 利用可能な場合の入力、出力、Cached Token数。
- 上記のTimingフィールド。
- Stream Event数とText Delta数。
- チャネルInflight Count。
- 粗い地域情報と、プライバシーレビュー済みのNetwork Trace ID。
upstream_headers_slowやgeneration_slow_tpsなどの粗い分類。
メタデータにも保持期間とアクセス制御を適用します。Request ID、ルート選択、時間パターン、Token数を組み合わせると、運用状況が推測される可能性があります。
調査は曖昧なTTFTラベルではなく、リクエストタイムラインから始めます。次にReliable AI API Routingで各試行が選択した正確なルートを比較し、AI API Error TroubleshootingでTimingと終了ステータスを関連付けます。これにより、Admission Delay、モデル起動、推論またはツール処理、可視生成、ローカルゲートウェイ処理を証拠に基づいて分離できます。