smakosh

すべてのAIゲートウェイは、アプリとモデルの間にホップを追加します。重要なのは、ユーザーが空白のチャットウィンドウを見つめている瞬間に、そのホップがどれだけのコストがかかるか：最初のトークンまでの時間です。ほとんどのゲートウェイレイテンシの議論は測定を省略し、アーキテクチャを論じます。そこで私たちはそれを測定しました。

私たちはオープンソースのTTFTベンチマークをLLM GatewayとOpenRouterに対して、同じマシンから、同じモデルで交互に実行しました。75回の実行ごとの中央値：LLM Gatewayはコールド接続で906ms、ウォーム接続で814msで最初のコンテンツトークンを取得しました。OpenRouterは1392msと1232msでした。これはコールドで約35%高速、ウォームで34%高速で、300回の測定実行全体でエラーはゼロ — 合計450回のHTTPリクエスト（各ウォーム測定の前に実行される使い捨てのウォームアップコールを含む）で、すべてHTTP 200を返しました。生の実行ごとのデータは完全に公開されています。

AIゲートウェイのパフォーマンス測定方法

私たちはai-gateways-benchmarkを使用しました。これはRonny Badillaによるオープンソースのスクリプトで、最近Vercel AI Gateway、OpenRouter、Cloudflare AI Gatewayを比較する議論で話題になりました。Python標準ライブラリのみ — 生ソケット、HTTPライブラリなし — で、ストリーミングリクエストの各フェーズを個別に計測します：DNS、TCP接続、TLSハンドシェイク、TTFB（リクエスト送信から最初のレスポンスバイトまで）、TTFT（リクエスト送信からSSEストリーム内の最初のコンテンツトークンまで）。

この分離がポイントです。「ゲートウェイレイテンシ」の主張は通常、接続コスト、エッジの近接性、実際のルーティングオーバーヘッドを混同しています。このツールはそれらを分離します。

2026年7月22日のセットアップ：

  • 両ゲートウェイで同じモデル：claude-haiku-4.5、ストリーミング、max_tokens: 16、同一プロンプト
  • ゲートウェイごとに75回のコールド + 75回のウォーム実行、ラウンドロビンで交互に実行し、時間帯による変動が両方に等しく影響するように
  • コールド = 新しいTLSコンテキスト（セッション再開なし）でDNS + TCP + TLSの完全コストを支払う新規接続
  • ウォーム = 既に開いているソケット上の2回目のリクエスト — 本番トラフィックが主に存在する接続プールのケース
  • 1つの住宅用 vantage point、450回のHTTPリクエスト（ウォームアップを含む）すべてでエラーなし

結果：LLM Gateway vs OpenRouter

n=75ごとの中央値。コールドTTFTはエンドツーエンド：DNS + TCP + TLS + 最初のコンテンツトークンまでの時間 — 短命なプロセスが支払うもの。

中央値 TTFB (コールド) TTFT (コールド) TTFT (ウォーム)
LLM Gateway 201ms 906ms 814ms
OpenRouter (direct) 1369ms 1392ms 1232ms

中央値とp10–p90範囲でのばらつき：

メトリック LLM Gateway OpenRouter
コールド TTFB 201 (194–240) 1369 (979–1643)
コールド e2e TTFT 906 (803–1380) 1392 (1002–1675)
ウォーム TTFB 176 (171–193) 1229 (924–1500)
ウォーム TTFT 814 (673–1379) 1232 (924–1501)

中央値以外で目立つ2つの点。LLM Gatewayのp90コールドTTFT（1380ms）はOpenRouterの中央値を下回りました — ある分布の遅いテールがもう一方の中央値を上回ったのです。そしてLLM GatewayのウォームTTFBはほとんど動きません：p10–p90範囲で171–193ms、これは本番接続プールで望まれる安定性です。

時間の内訳

フェーズ分解は、オーバーヘッドが接続にないことを示しています：

ゲートウェイ DNS TCP TLS TTFB TTFT (リクエスト)
LLM Gateway 3.2 20.9 40.2 200.9 829.5
OpenRouter 3.4 7.2 12.7 1369.4 1369.8

OpenRouterのエッジは実際、ハンドシェイクで勝っています — 13ms TLS対私たちの40ms。リクエスト送信後のすべてで負けています。

TTFB列に関する正直な注意点：これはアーキテクチャ上の理由でLLM Gatewayを優位に見せます。私たちのゲートウェイは最初のアップストリームトークンが到着する前に約200msでレスポンスストリームを開始します。OpenRouterは最初のトークンが準備できるまで最初のバイトを保持するため、すべての実行でTTFBがTTFTと等しくなります。TTFBは誰がヘッダーを早期にストリーミングするかを示します；TTFTはユーザーが感じる数値であり、この投稿の正直な見出しです。

2つ目の注意点：各ゲートウェイはこのモデルのデフォルトルーティングを実行しました。OpenRouterはリクエストごとにアップストリームを選択します（検査したリクエストはAmazon Bedrock経由で提供されました）が、私たちの実行はAnthropicのAPIに固定されました。どちらも箱から出して得られるものですが、異なるアップストリームです。

Vercel AI Gatewayとの比較

私たちはVercelを自分でベンチマークしませんでした。ベンチマークの著者は同じスクリプトの独自の実行を公開しました — 彼のvantage pointから、別の日付で — Vercel AI Gateway、OpenRouter、OpenRouterをプロキシするCloudflare AI Gatewayを比較：

彼の実行（n=5の中央値） TTFB TTFT (コールド) TTFT (ウォーム)
Vercel AI Gateway 785ms 1099ms 822ms
OpenRouter (direct) 1100ms 1123ms 986ms
Cloudflare → OpenRouter 1300ms 1420ms 1279ms

これらの数値は私たちのものと直接比較できません — 場所が違い、ネットワークが違い、日が違い、n=5対n=75。役立つのは健全性チェックです：OpenRouterは彼の実行でも私たちの実行でも、最初のトークンまでに1秒を超えます。インターネットの異なる隅から。彼のテーブルに対して、LLM Gatewayの906msコールドと814msウォームは最良の行と同等かそれ以下ですが、私たちが事実として述べる唯一の比較は、私たちが自分で測定した、1台のマシンから交互に実行したものです。

場所への依存は両刃の剣であり、ベンチマークのREADMEも明示的に述べています：結果は測定する場所の特性であり、グローバルランキングではありません。だからこそ、正しい行動は自分で実行することです。

自分でベンチマークを実行する

全体が設定ファイルと2つのAPIキーです：

git clone https://github.com/rbadillap/ai-gateways-benchmark
cd ai-gateways-benchmark

Enter fullscreen mode Exit fullscreen mode 

{
  "runs_cold": 75,
  "runs_warm": 75,
  "prompt": "Reply with the single word: pong",
  "max_tokens": 16,
  "gateways": [
    {
      "name": "llmgateway",
      "host": "api.llmgateway.io",
      "path": "/v1/chat/completions",
      "model": "anthropic/claude-haiku-4-5",
      "auth_value": "Bearer $LLM_GATEWAY_API_KEY"
    },
    {
      "name": "openrouter",
      "host": "openrouter.ai",
      "path": "/api/v1/chat/completions",
      "model": "anthropic/claude-haiku-4.5",
      "auth_value": "Bearer $OPENROUTER_API_KEY"
    }
  ]
}

Enter fullscreen mode Exit fullscreen mode 

LLM_GATEWAY_API_KEY=... OPENROUTER_API_KEY=... python3 bench.py config.json

Enter fullscreen mode Exit fullscreen mode

作業中は実行ごとの行を出力し、その後中央値テーブルを出力し、リクエストIDレシート付きの生の実行ごとのJSONをダンプします。あなたの地域から実行して異なる数値（私たちが負ける場合を含む）を得た場合、私たちはそれを見たいと思います。

レイテンシはすべてのリクエストで支払う税金

ゲートウェイはフェイルオーバー、統一課金、ルーティングするすべてのモデルにわたる1つのAPIでそのホップを稼ぎます。しかし、あなたはそのレイテンシをすべてのリクエストで、永遠に支払います。これにより、最初のトークンまでの時間はコミットする前に測定する価値のあるゲートウェイの数少ない特性の1つになります — そして最も簡単なものの1つです。ツールはオープンソースで、実行に数分しかかかりません。

今日OpenRouterを使用している場合、LLM Gatewayは同じOpenAI互換APIを話します — 切り替えるにはベースURLを変更し、LLM Gateway APIキーを入れ替えるだけです。OpenRouter移行ガイドで説明されています。

よくある質問

TTFTとは何か、そしてなぜTTFBよりも重要なのか？

TTFT（time to first token）は、リクエストを送信してからストリーム内のモデルの最初の出力を受け取るまでの遅延です。TTFB（time to first byte）はサーバーが応答を開始したときのみを測定します — ゲートウェイはモデルがまだ沈黙している間もヘッダーを即座にストリーミングできます。ユーザーがリアルタイムで見ているものにとって、TTFTは実際に体験するレイテンシです。

AIゲートウェイにとって良いTTFTとは？

それはモデルとゲートウェイのエッジからの距離によるため、絶対的な基準ではなく、ゲートウェイ同士を比較してください。このAIゲートウェイパフォーマンスベンチマークでは、claude-haiku-4.5からの最初のトークンは、LLM Gateway経由で約800–900ms、OpenRouter経由で1200–1400msで、同じマシンから同じセッションで測定されました。

これらの結果はすべての場所から有効か？

いいえ — レイテンシベンチマークはvantage pointの特性であり、ベンチマーク自身のREADMEもそれを明示しています。私たちの数値は1日1つの住宅用接続から得られたものです；著者のVercel数値は別のものから得られたものです。スクリプトはオープンソースで実行に数分しかかからないため、サーバーが実際に存在する場所から測定してください。

LLM GatewayはOpenRouterと同じモデルをサポートしているか？

LLM Gatewayは重複するカタログをルーティングします — 完全なリストはmodels pageにあり、providers pageの主要なクローズドおよびオープンウェイトプロバイダーにまたがります。リクエストはどちらの場合もOpenAI互換形式を使用するため、2つの間のワークロードの移動はベースURLとキーの変更です。

自分で測定してください：