LLM Gateway 与 OpenRouter 首 token 延迟基准对比

一篇发布在 Hacker News 上的 Show HN 文章展示了「LLM Gateway」与 OpenRouter 在首 token 时间（TTFT）上的实测对比。结果显示 LLM Gateway 在冷启动与热连接两种场景下均领先约 35%，但该测试由 LLM Gateway 团队自行设计并执行，存在明显的厂商立场偏差。

测量方法

测试使用开源脚本 ai-gateways-benchmark，以 Python 标准库中的裸 socket 实现，分阶段计时 DNS、TCP、TLS 握手、TTFB（首字节）以及 TTFT（首内容 token）。两端均跑 claude-haiku-4.5，流式返回，max_tokens 固定为 16，提示词完全一致。

• 每端各跑 75 次冷启动 + 75 次热连接，轮询交错进行以抵消时段漂移
• 冷连接指全新 socket，无 TLS session resumption
• 热连接指复用已有 socket 的连接池场景
• 单个住宅网络视角点，450 次 HTTP 请求（含预热）零错误

测试日期为 2026 年 7 月 22 日，单一地理位置，仅一个上游模型，样本量与代表性均有限。

核心结果

以 75 次中位数计：

• LLM Gateway：冷 TTFT 906 ms，热 TTFT 814 ms
• OpenRouter：冷 TTFT 1392 ms，热 TTFT 1232 ms

LLM Gateway 的冷热 TTFT 分别快约 35% 与 34%。更值得关注的是其分布稳定性：LLM Gateway 冷 TTFT 的 p90 为 1380 ms，已经低于 OpenRouter 的中位数；其热 TTFB 在 p10 至 p90 区间仅在 171–193 ms 波动。

时间分布拆解

按阶段拆开看，握手成本并非差距来源：

• LLM Gateway：TLS 40 ms，TTFB 201 ms，TTFT 830 ms
• OpenRouter：TLS 13 ms，TTFB 1369 ms，TTFT 1370 ms

OpenRouter 在 TLS 阶段反而更快，但请求发出后的处理明显落后。LLM Gateway 团队承认一个架构差异：LLM Gateway 大约在 200 ms 就开始推送响应流，不等首个上游 token；OpenRouter 则等到首个 token 就绪才发出首字节，因此其 TTFB 与 TTFT 在每次请求上都几乎相等。这意味着 LLM Gateway 的 TTFB 优势部分来自「更早开始推流」的设计选择，而非纯粹的路径缩短。

与其他基准的对比

ai-gateways-benchmark 原作者此前发布过一组对比（Vercel AI Gateway、OpenRouter、Cloudflare 代理 OpenRouter，n=5）：

• Vercel AI Gateway：冷 TTFT 1099 ms，热 TTFT 822 ms
• OpenRouter：冷 TTFT 1123 ms，热 TTFT 986 ms
• Cloudflare → OpenRouter：冷 TTFT 1420 ms，热 TTFT 1279 ms

两次测量在不同地点、不同日期进行，样本量差异显著（n=5 对 n=75），不可直接合并。LLM Gateway 的 906/814 ms 在原作者表中大致处于最优一行附近，但本文明确表示「唯一可作为事实陈述的，只有我们自己交错测量的一组」。

局限与启示

本文存在三处需要读者注意的偏差：

• 厂商立场：测试由 LLM Gateway 团队发布并选择对比对象，未自行测量 Vercel 与 Cloudflare
• 上游差异：LLM Gateway 走 Anthropic 官方 API，OpenRouter 默认路由经 Amazon Bedrock，两者并非同一条路径
• 地理局限：单一住宅节点，时延高度依赖测量地点，README 已明示「结果是测量点的属性，不是全局排名」

对开发者而言，TTFT 是 LLM 网关少数值得预先量化的属性之一，开源脚本几分钟即可跑通。读者在自己的网络环境下复测，并接受可能出现的反方向结果，才是稳妥的选型路径。