smakosh

每個 AI 閘道器都會在您的應用程式與模型之間增加一個跳轉點。真正重要的是這個跳轉點在使用者盯著空白聊天視窗時的成本：第一個 token 的時間。大多數關於閘道器延遲的討論都跳過了實際測量，直接爭論架構 — 因此我們進行了實際測量。

我們針對 LLM Gateway 與 OpenRouter 執行了一個開源的 TTFT 基準測試，從同一台機器、同一模型交替進行測試。75 次測試的中位數結果：LLM Gateway 在冷連線時首次取得內容 token 為 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 標準函式庫 — 原始 socket，不使用 HTTP 函式庫 — 並分別計時串流請求的每個階段：DNS、TCP 連線、TLS 握手、TTFB（請求送出到第一個回應位元組）、以及 TTFT（請求送出到 SSE 串流中的第一個內容 token）。

這種分離正是重點所在。「閘道器延遲」的主張通常混淆了連線成本、邊緣接近程度以及實際路由開銷。此工具將它們分開。

我們在 2026 年 7 月 22 日的測試設定：

  • 兩個閘道器使用相同模型：claude-haiku-4.5，串流，max_tokens: 16，相同提示詞
  • 每個閘道器執行 75 次冷連線 + 75 次暖連線，交替輪詢以使時間漂移平均影響兩者
  • 冷連線 = 全新連線，支付完整 DNS + TCP + TLS 成本，使用新的 TLS 內容（無工作階段恢復）
  • 暖連線 = 在已開啟的 socket 上的第二次請求 — 這是您的實際生產流量主要使用的連線池情境
  • 單一住宅視點，兩個閘道器在所有 450 次 HTTP 請求（包含預熱）中皆零錯誤

結果：LLM Gateway 與 OpenRouter 比較

每格 n=75 的中位數。冷 TTFT 是端到端：DNS + TCP + TLS + 到第一個內容 token 的時間 — 這是短期程序會支付的成本。

中位數 TTFB（冷） TTFT（冷） TTFT（暖）
LLM Gateway 201ms 906ms 814ms
OpenRouter（直接） 1369ms 1392ms 1232ms

以中位數搭配 p10–p90 範圍呈現的差異：

指標 LLM Gateway OpenRouter
冷 TTFB 201 (194–240) 1369 (979–1643)
冷端到端 TTFT 906 (803–1380) 1392 (1002–1675)
暖 TTFB 176 (171–193) 1229 (924–1500)
暖 TTFT 814 (673–1379) 1232 (924–1501)

除了中位數之外，還有兩點值得注意。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 的邊緣實際上贏得了握手 — TLS 13ms 對比我們的 40ms。它在請求送出後的所有階段都輸了。

關於 TTFB 欄位的一個誠實提醒：它對 LLM Gateway 來說有點美化，這是架構原因。我們的閘道器在大約 200ms 內啟動回應串流，在第一個上游 token 到達之前。OpenRouter 會等到第一個 token 準備好才送出第一個位元組，因此其 TTFB 每次都等於其 TTFT。TTFB 告訴您誰先串流標頭；TTFT 是使用者感受到的數字，也是本文的真正重點。

第二個提醒：每個閘道器對此模型都執行其預設路由。OpenRouter 每次請求都會選擇其上游（我們檢查的一個請求是透過 Amazon Bedrock 提供服務），而我們的測試則固定在 Anthropic 的 API。這兩種都是開箱即用的設定，但上游不同。

Vercel AI Gateway 的比較

我們沒有自行對 Vercel 進行基準測試。該基準測試的作者已發布他自己使用相同腳本的測試結果 — 從他的視點、在不同的日期 — 比較 Vercel AI Gateway、OpenRouter，以及 Cloudflare AI Gateway 代理 OpenRouter：

他的測試結果（n=5 的中位數） TTFB TTFT（冷） TTFT（暖）
Vercel AI Gateway 785ms 1099ms 822ms
OpenRouter（直接） 1100ms 1123ms 986ms
Cloudflare → OpenRouter 1300ms 1420ms 1279ms

這些數字無法直接與我們的結果比較 — 不同的地點、不同的網路、不同的日期，n=5 對比 n=75。它們有用的地方在於 sanity check：OpenRouter 在他的測試和我們的測試中，到達第一個 token 的時間都超過一秒，來自網際網路的兩個不同角落。對照他的表格，LLM Gateway 的冷連線 906ms 與暖連線 814ms 達到或低於最佳列 — 但我們唯一會陳述為事實的比較是我們自己從一台機器交替測量的結果。

地點依賴性是雙向的，基準測試的 README 也明確指出：結果取決於您測量的位置，而不是全球排名。這也是為什麼正確的做法是自己執行測試。

自己執行基準測試

整個測試只需要一個設定檔和兩個 API 金鑰：

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

進入全螢幕模式 退出全螢幕模式 

{
  "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"
    }
  ]
}

進入全螢幕模式 退出全螢幕模式 

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

進入全螢幕模式 退出全螢幕模式

它會在執行過程中印出每筆執行記錄，然後印出中位數表格，並以 JSON 格式傾印每筆執行的原始資料以及請求 ID 收據。如果您從您的地區執行並得到不同的數字 — 包括我們輸掉的情況 — 我們希望能看到。

延遲是您在每次請求支付的稅

閘道器透過故障轉移、統一計費以及跨它路由的每個模型的單一 API 來證明其跳轉的價值。但您在每次請求、永遠支付其延遲成本。這使得第一個 token 的時間成為少數值得在承諾之前測量的閘道器屬性之一 — 也是最容易測量的之一，因為工具是開源的，執行只需幾分鐘。

如果您目前使用 OpenRouter，LLM Gateway 提供相同的 OpenAI 相容 API — 切換只需要更改 base URL 並換上 LLM Gateway API 金鑰，詳細說明請參閱OpenRouter 遷移指南。

常見問題

什麼是 TTFT？為什麼它比 TTFB 更重要？

TTFT（到第一個 token 的時間）是指從送出請求到在串流中收到第一個模型輸出片段之間的延遲。TTFB（到第一個位元組的時間）只測量伺服器開始回應的時間 — 閘道器可以在模型仍保持沉默時立即串流標頭。對於使用者即時觀看的任何內容，TTFT 才是他們實際體驗到的延遲。

AI 閘道器良好的 TTFT 應該是多少？

這取決於模型以及您與閘道器邊緣的距離，因此應該比較閘道器之間的結果，而不是絕對標準。在本次 AI 閘道器效能基準測試中，透過 LLM Gateway 從 claude-haiku-4.5 取得的第一個 token 大約在 800–900ms，而透過 OpenRouter 則需要 1200–1400ms，都是從同一台機器、同一工作階段測量。

這些結果是否對每個地點都有效？

不 — 延遲基準測試取決於視點，基準測試自己的 README 也明確指出這一點。我們的數字來自某一天的單一住宅連線；作者的 Vercel 數字來自另一個視點。腳本是開源的，執行只需幾分鐘，因此請從您的伺服器實際所在的位置進行測量。

LLM Gateway 是否支援與 OpenRouter 相同的模型？

LLM Gateway 路由重疊的型錄 — 完整清單請參閱模型頁面，涵蓋供應商頁面上的主要封閉與開放權重供應商。無論哪種方式，請求都使用 OpenAI 相容格式，因此在兩者之間移動工作負載只需要更改 base URL 和金鑰。

自己測量：