工具
Claude Haiku 4.5 网关延迟对比：LLM Gateway vs OpenRouter
基于 150 次冷启动与 150 次热连接测试，LLM Gateway 端到端首 token 时间中位数较 OpenRo…
2026.07.23 · 周四约 4 分钟阅读
一项针对 Claude Haiku 4.5 的网关延迟基准测试显示，在 75 次冷启动与 75 次热连接共 150 次请求中，LLM Gateway 的端到端首 token 时间（TTFT）中位数比 OpenRouter 快约 34%。测试使用作者自研的 rbadillap/ai-gateways-benchmark 工具，仅依赖 Python 标准库与原始 socket，将每个请求拆解为 DNS、TCP、TLS、TTFB、TTFT 五个阶段，以隔离网络与网关开销。
测试方法
- 模型：Claude Haiku 4.5，两端使用相同的 prompt，最大输出 token 数 16。
- 请求组合：75 次冷连接 + 75 次热连接，冷连接指每次都重新进行 DNS + TCP + TLS 握手、不复用 TLS 会话；热连接则复用已建立的 socket。
- 控制变量：冷热请求按轮询交替发送，使时间漂移对两端影响一致；所有 300 次请求零错误。
- 测量环境：单一住宅网络连接，测量日期为 2026-07-22；OpenRouter 的边缘节点在本次测试中落在哥本哈根（cf-ray 显示 -CPH）。
关键结果
中位数对比（毫秒）
- 冷启动 TTFB：LLM Gateway 201 vs OpenRouter 1369
- 冷启动端到端 TTFT：906 vs 1392
- 热连接 TTFT：814 vs 1232
LLM Gateway 的冷启动 p90 TTFT 为 1380 ms，仍低于 OpenRouter 的中位数 1392 ms。
分阶段拆解（中位数，毫秒）
- DNS：3.2 vs 3.4（差距可忽略）
- TCP：20.9 vs 7.2（OpenRouter 略优）
- TLS：40.2 vs 12.7（OpenRouter 略优）
- TTFB：200.9 vs 1369.4（LLM Gateway 显著领先）
可以看到 DNS/TCP/TLS 三项网络握手阶段 OpenRouter 反而更快，真正的差距集中在 TTFB 与 TTFT。
分布区间（p10–p90，毫秒）
- 冷启动 TTFB：LLM Gateway 201（194–240），OpenRouter 1369（979–1643）
- 冷启动端到端 TTFT：906（803–1380）vs 1392（1002–1675）
- 热连接 TTFB：176（171–193）vs 1229（924–1500）
LLM Gateway 的热连接 TTFB 在 p10–p90 之间仅相差约 20 ms，稳定性也明显好于 OpenRouter。
观察与局限
- LLM Gateway 在首 token 到达前约 200 ms 就已开始流式输出响应，因此其 TTFB 远低于 TTFT；OpenRouter 的首字节与首 token 几乎同时到达，TTFB 与 TTFT 在每次运行中数值接近，说明 OpenRouter 在等待上游返回后才向客户端发出响应。
- 上游选择不同：OpenRouter 按请求动态选择上游，本次测试某次请求命中了 Amazon Bedrock；LLM Gateway 的请求固定走 Anthropic 官方 API。这是两款网关各自的默认行为。
- 测试视角单一，结果受测量位置影响，不能视为全局排名。
复现方式
仓库地址为 https://github.com/rbadillap/ai-gateways-benchmark ，运行 bench.py 即可按 config.json 中的设置重复冷热请求测试，所需密钥通过环境变量 LLMGATEWAY_API_KEY 与 OPENROUTER_API_KEY 注入。