「推論中、モデルは不正利用スコアのような1つの結果を返すこともあれば、生成テキストのように結果を少しずつストリーミングすることもあります。単一の予測には通常、明確な完了時点があります。一方、ストリーミングレスポンスにはありません。最初に表示される出力と、完成したレスポンスは異なる時点で到着します。
推論レイテンシの測定方法
まず、測定の境界を定めます。
モデルレイテンシは通常、モデルサーバーの内部またはその近くで行われる処理を指します。プラットフォームによっては、前処理やモデルコンテナとの通信が含まれることもあります。
サービスレイテンシには、モデルの周辺で行われる受付チェック、キュー待ち、バッチ処理などが加わる場合があります。
エンドツーエンドレイテンシは、クライアントの視点で測定されます。ネットワーク転送、ゲートウェイ、サービスキュー、モデル実行、後処理、結果の配信が含まれることがあります。
これらのラベルは完全には標準化されていません。あるプラットフォームの「モデルレイテンシ」には、別のプラットフォームがオーバーヘッドとして記録する処理が含まれる場合があります。したがって、タイムスタンプは定義の一部です。「クライアントが送信してから最終レスポンスを受信するまで」は比較可能ですが、「レイテンシは800ミリ秒だった」だけでは比較できません。
テキストをストリーミングする言語モデルでは、タイマーを停止する出力イベントも異なる場合があります。
- 最初のトークンまでの時間（TTFT）は、最初の出力トークンを受信した時点で終了します。レスポンスが表示され始めるまでの時間を示します。
- エンドツーエンドのリクエストレイテンシは、time to last token（最後のトークンまでの時間）と呼ばれることもあり、完全なレスポンスを受信した時点で終了します。
- トークン間レイテンシ（ITL）は、生成開始後に連続する出力トークン間の間隔を測定します。ツールによっては、出力トークン1個あたりの平均時間と呼びます。
一般的な規約の1つでは、次のようになります。
エンドツーエンドレイテンシ = TTFT + 生成時間
レスポンスにn個の出力トークンが含まれる場合、最初のトークン後の平均トークン間レイテンシは次のとおりです。
（エンドツーエンドレイテンシ - TTFT）/（n - 1）
分母がn - 1なのは、n個のトークンには、最初のトークン後にその数だけ間隔があるためです。結果を比較する前に、ツールの定義を確認してください。ツールによっては、トークンごとの平均に最初のトークンまでの待ち時間を含める一方、含めないものもあります。
計算例
仮想的なストリーミングレスポンスについて、クライアントが次のタイムスタンプを記録したとします。
- リクエスト送信：
0ミリ秒 - 最初の出力トークン受信：
450ミリ秒 - 最後の出力トークン受信：
1,400ミリ秒 - 出力長：
20トークン
クライアントが観測したTTFTは450ミリ秒です。エンドツーエンドレイテンシは1,400ミリ秒です。最初のトークン後の生成には950ミリ秒かかり、19個のトークン間隔に分散されています。
950ミリ秒 / 19 = 50ミリ秒
したがって、同じリクエストには、最初のトークンまでのレイテンシ450ミリ秒、平均トークン間レイテンシ50ミリ秒、完了レイテンシ1.40秒があります。これらの数値のいずれも、他の数値に取って代わるものではありません。
ここで、モデルサーバーがモデルコンテナ内の処理に720ミリ秒かかったと報告したとします。残りの680ミリ秒がネットワーク遅延だったと証明されるわけではありません。クライアントとサーバーのタイマーは、重複する段階や、異なる定義の段階を測定している可能性があります。この差を説明するには、キュー待ち、前処理、モデル実行、後処理、ネットワーク転送について、整合したタイムスタンプが必要です。
推論レイテンシを変化させる要因
レイテンシはモデルに永続的に備わる性質ではなく、テスト全体の結果です。次の要因によって変化します。
- 入力の形状とサイズ。入力が増えると、前処理やモデル処理が増えることがあります。
- 出力の形状とサイズ。生成されるレスポンスが長いほど、逐次的な生成ステップが多く必要になります。
- トラフィックと同時実行数。同じサービングリソースを他の処理が使用している場合、リクエストは容量が空くまで待つことがあります。
- バッチ処理とスケジューリング。リクエストをまとめるとシステム全体の効率は向上しますが、個々のリクエストの待ち時間は増えることがあります。
- ハードウェアとサービングソフトウェア。アクセラレータ、数値精度、メモリ転送、カーネル、推論エンジンが実行時間に影響します。
- ウォーム状態またはコールド状態。コード、モデルデータ、キャッシュの準備が整っていない場合、リクエストは遅くなることがあります。
- アプリケーションの各段階。検索、安全性チェック、ツール、後処理によって、モデルの外側でユーザーが感じる遅延が増えることがあります。
- ネットワークとクライアントの場所。サーバー側のベンチマークには、リモートユーザーが通過するすべての経路が含まれるわけではありません。
生成テキストでは、入力長は出力開始までの待ち時間に影響しやすく、出力長はレスポンスの完了時点に強く影響します。ストリーミングは部分的な出力を早く表示することで、インターフェースの応答性を高められますが、それだけで完了レイテンシが低下するとは限りません。
平均だけでは不十分な理由
本番サービスは、サイズの異なるリクエストを、変化する負荷の下で処理します。1つの平均値ではこの分布が圧縮され、最も長く待たされたリクエストが隠れてしまうことがあります。
レイテンシはパーセンタイルで報告されることがよくあります。p95の完了レイテンシとは、測定したリクエストの95%がその値以下で完了したことを示す値です。残りの5%は、より長い時間を要しました。p50は中央のリクエストを示し、p95やp99はより遅い裾の部分を明らかにします。
報告されたパーセンタイルには、必ず文脈が必要です。最低限、結果に次の項目を付記します。
- 境界：クライアントから最初のトークンまで、クライアントから最終結果まで、または名前を付けたサーバー側の区間。
- ワークロード：モデル、入力分布、出力分布、リクエスト設定。
- 負荷：同時実行数またはリクエスト到着パターン。
- 統計量：p50、p95、p99、平均、またはリクエストごとの値。
たとえば、「同時実行数20、特定のワークロードにおける、クライアントから最終結果までのレイテンシのp95」は、利用可能な測定値です。異なるプロンプト構成や単一リクエストの負荷で得られた低い数値は、本番システムが高速である証拠にはなりません。
推論レイテンシが重要な理由
レイテンシは、1つのリクエストがどれだけ待つかを決めます。適切な停止点は製品によって異なります。
インタラクティブなインターフェースでは、最初に出力が表示されるまでの時間が最も重要かもしれません。バックグラウンドの分類器では、予測が完了するまでの時間が重要です。複数段階のシステムでは、前の結果が完了するまで次の依存ステップを開始できないため、完了レイテンシが一連の処理全体で積み重なることがあります。
レイテンシは、システムが時間あたりにどれだけの処理を完了するかを測るスループットとも関係します。バッチサイズや同時実行数を増やすと総スループットは向上しても、各リクエストの待ち時間は増えることがあります。したがって、システムが1秒あたりに処理できる総トークン数は増えても、個々のユーザーには遅く感じられる場合があります。
よくある誤解
「推論レイテンシ」とは常にモデル実行時間を意味する。そうとは限りません。この用語は、サービスレベルやクライアントが観測した時間を指す場合もあります。測定境界を確認してください。
最初のトークンまでの時間がレスポンスレイテンシである。これはレスポンスにおける1つの節目です。最初のトークンが速くても、その後の生成に長い時間がかかることがあります。
ストリーミングによって推論の完了が速くなる。ストリーミングは部分的な結果が配信されるタイミングを変えます。最終結果の到着時刻が同じでも、体感的な応答性を向上させられます。
モデルには1つのレイテンシ数値がある。結果は、入力、出力、負荷、ハードウェア、ソフトウェア、報告される統計量によって異なります。
総トークン数/秒が多いほどレイテンシは低い。集約されたスループットと、リクエストごとの待ち時間は、反対方向に変化することがあります。
次に読む項目
ストリーミングレスポンスの開始が重要な場合は、最初のトークンまでの時間を使用します。生成速度を表すにはトークン/秒を使用し、サービング能力全体を表すには推論スループットを使用します。これらを横並びで区別するには、レイテンシ vs. TTFT vs. トークン/秒 vs. スループットを参照してください。