每个 AI 网关都会在你的应用和模型之间增加一跳。真正重要的是这一跳在用户盯着空白聊天窗口时所带来的成本：首个 token 的时间。大多数关于网关延迟的讨论都跳过了实际测量，转而争论架构——所以我们进行了测量。
我们使用开源的 TTFT 基准测试对 LLM Gateway 和 OpenRouter 进行了交替测量，均来自同一台机器，使用同一模型。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 标准库——原始套接字，无 HTTP 库——分别计时流式请求的每个阶段：DNS、TCP 连接、TLS 握手、TTFB（请求发送到首个响应字节）和 TTFT（请求发送到 SSE 流中的首个内容 token）。
这种分离正是关键所在。“网关延迟”的说法通常将连接成本、边缘邻近性和实际路由开销混为一谈。这个工具将它们分开。
我们在 2026 年 7 月 22 日的设置：
-
两个网关使用同一模型：claude-haiku-4.5，流式，
max_tokens: 16，相同提示 - 每个网关 75 次冷运行 + 75 次热运行，交替轮询，以便时间漂移对两者影响相同
- 冷 = 新建连接，支付完整的 DNS + TCP + TLS 成本，使用新的 TLS 上下文（无会话恢复）
- 热 = 在已打开的套接字上的第二次请求——这是生产流量主要所处的连接池情况
- 一个住宅 vantage point，两个网关在全部 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 进行基准测试。该基准的作者发布了使用同一脚本的运行结果——从他的 vantage point，在不同日期——比较 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。它们有用的地方在于合理性检查：OpenRouter 在他的运行和我们的运行中，首个 token 耗时都超过一秒，来自互联网的两个不同角落。与他的表格相比，LLM Gateway 的 906ms 冷 TTFT 和 814ms 热 TTFT 处于或低于最佳行——但我们唯一会陈述为事实的比较是我们自己从一台机器交替测量的结果。
位置依赖是双向的，基准的 README 明确指出了这一点：结果是你测量位置的属性，而不是全球排名。这就是为什么正确的做法是从你自己的位置运行它。
自己运行基准测试
整个过程只需要一个配置文件和两个 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
它在工作时打印每次运行的行，然后输出中位数表格，并转储原始每次运行的 JSON，包含 request-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 首次 token 从 claude-haiku-4.5 到达大约需要 800–900ms，通过 OpenRouter 需要 1200–1400ms，均来自同一台机器的同一会话。
这些结果在每个位置都有效吗？
否——延迟基准测试是你 vantage point 的属性，基准的 README 明确指出了这一点。我们的数字来自一天内的一个住宅连接；作者的 Vercel 数字来自另一个。脚本是开源的，只需几分钟即可运行，所以从你的服务器实际所在的位置进行测量。
LLM Gateway 是否支持与 OpenRouter 相同的模型？
LLM Gateway 路由重叠的目录——完整列表在模型页面，涵盖提供商页面上的主要闭源和开源权重提供商。请求无论如何都使用 OpenAI 兼容格式，因此在两者之间移动工作负载只是 base URL 和密钥更改。
自己测量：
- 免费试用 LLM Gateway —— 一把密钥，从第一天起即可流式传输
- 从 OpenRouter 迁移 —— 仅 base URL 和 API 密钥更改
- 什么是 LLM 网关？ —— 跳跃何时收回成本
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.