HopBase結論から言うと、LLM API の性能は 3 つの計測可能な指標に集約されます。初回トークン到達時間（TTFT）の P95/P99 分布、ストリーミングの安定性（長い出力が途中で無言のまま切れずに最後まで届く割合）、そしてプロンプトキャッシュのヒットが速度とコストの両方をどれだけ押し上げるか、です。総レイテンシや平均値は判断を誤らせます。生成時間は出力の長さに支配され、平均値はユーザーが実際に体感するテール（裾野）を隠してしまうからです。役に立つベンチマークは、あえて地味に設計します。固定のプロンプトセット、temperature 0、同じ時間帯に最低 30 回の実行、平均ではなくパーセンタイルで読むこと、そして同じ時間帯に同じテストをベンダーの公式 API に対しても実行することです。性能はベンダーのページに書かれた形容詞であるべきではなく、あなたのターミナルに表示される数値であるべきです。以下の方法は curl コマンド 1 本から始められ、完全に再現可能です。
総レイテンシが悪い指標である理由
総生成時間は出力の長さに支配されます。回線品質に関係なく、2000 語の出力は 200 語の 10 倍の時間がかかります。ストリーミングでユーザーが実際に体感するのは 2 点です。最初のトークンがいつ届くか（TTFT）、そしてその後トークンが安定して流れ続けるか。TTFT こそが本当の回線指標であり、入口、ゲートウェイのスケジューリング、プロバイダー側のキューイングといったオーバーヘッドがすべて含まれます。
平均ではなく分布を読む
平均値はテールを隠します。1 秒のリクエストが 90 件、8 秒のリクエストが 10 件あれば、平均は見栄えのよい 1.7 秒になりますが、10 人に 1 人のユーザーは 8 秒待たされています。P95/P99 が太いことはキューイングやリトライが起きていることを意味し、忠実度テストにおけるエンジニアリング品質の判断基準の一つでもあります。手順の原則は、プロンプトを固定し、temperature 0 で、同じ時間帯に最低 30 回連続で実行し、パーセンタイルで読むことです。
途切れ率：最も見落とされている指標
長い出力がストリームの途中で無言のまま切れるのは、ストリーミングにおける最悪の障害パターンです。内容は半分しか届かず、エラーコードも返りません。テストは簡単です。長い出力（たとえば 2000 語）をリクエストし、N 回繰り返して、正しい SSE の終了で完結したストリームの割合を測ります。途切れ率の高いチャネルでは、どんな TTFT の数値も意味を失います。
キャッシュヒット：性能とコストは表裏一体
プロンプトキャッシュにヒットすると、入力は割引料金で課金され、TTFT も目に見えて短くなります。ここでは性能とコストは同じものです。ヒット率はルーティングのトポロジーに左右されます。リクエストが同じバックエンドアカウントに着地する必要があるため、ランダムにルーティングされるトラフィックではヒット率はゼロに近づいていきます。負荷の下でアフィニティスケジューリングがどのようにヒット率を維持するかは高同時実行のエンジニアリングノートで、課金の仕組みはプロンプトキャッシュガイドで解説しています。
エラーコードとリトライの挙動
見落としがちな項目があります。ゲートウェイはモデルプロバイダーのエラーコードを手を加えずにそのまま返しているでしょうか。429 を握りつぶしてタイムアウトに変えてしまうチャネルは、クライアント側のバックオフロジックを壊し、ピーク負荷時に破綻します。意図的にレート制限や不正なパラメータを発生させ、公式ドキュメントの挙動と比較してテストしてください。
コマンド 1 本から始めるベンチマーク
TTFT は素の curl で測定できます（ストリーミングを有効にすると、time_starttransfer が最初のチャンクの到着時刻になります）：
curl -N -s -o /dev/null \
-w "TTFT %{time_starttransfer}s | total %{time_total}s\n" \
https://api.hop-base.com/v1/chat/completions \
-H "Authorization: Bearer $HOPBASE_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"gpt-6-luna","stream":true,"messages":[{"role":"user","content":"Introduce yourself in one sentence"}]}'gpt-6-luna は、ご自身のキーで呼び出せる任意のモデルに置き換えてください。GET /v1/models で一覧を確認できます。これを 30 回ループし、ピーク時間帯にも繰り返せば、P95 とジッターが得られます。手順の全体像は、タスクセットを固定し、temperature 0、最初のコールドランを除外し、時間帯を変えて再テストし、必ず同じ時間帯にベンダーの公式 API とテスト対象のサービスを比較することです。
私たち自身の計測方法
HopBase はすべてのリクエストについて、モデル、使用量、レイテンシ、ステータスを記録しています。課金監査を支えているのと同じ記録が、性能監視も支えています。常駐プローブがすべてのチャネルを継続的にテストし、異常をできるだけ早く検知して対処しています。私たちが手法を公開しているのはそのためです。あなたが計測する数値と、私たちが監視している数値は、同じ経路から得られたものです。
よくある質問
良い TTFT の目安はどれくらいですか？
絶対値はモデル、リージョン、入口によって変わります。比較できるのは、同じ時間帯にベンダーの公式 API と行う A/B テストです。どんな絶対値よりも、その差と分布の安定性のほうが多くを物語ります。
ゲートウェイは直接接続より遅いのですか？
ホップが 1 つ増えることによる固定コストは数ミリ秒です。一方、キューイングの減少やキャッシュヒットによる改善は数百ミリ秒から数秒に及びます。上記の方法で両方を計測し、数値で判断してください。誰かを信用する必要はありません。
テストからノイズを排除するにはどうすればよいですか？
temperature 0、固定プロンプト、N は最低 30、コールドスタートを除外、時間帯を変えて再テストすること。そして異なる時間帯どうしを比較しないことです。そうしないと、プロバイダー側の時間帯による変動がゲートウェイの差に見えてしまいます。