四地探测显示：推理接口延迟因地域而异

选 AI API，不能只问哪家最快，还得问请求从哪里发出。作者从德国、美国中部、东京和圣保罗持续探测 44 家推理服务商，发现同一端点跨洲访问，延迟可能相差十倍。服务是否稳定，也会随观察地区和统计窗口变化。

这份数据最有用的地方，是把网络距离、模型响应和可用性拆开来看。不过，探测结果不等于真实业务体验，原文提供的材料也不足以排出一份完整榜单。

「最快」先要分清测的是哪段时间

标题说的是 100 天探测。作者称从 7 月开始，每 5 分钟访问一次各服务商的官方 API host；截至 2026 年 11 月 7 日，当前 90 天窗口积累了 480 万次测量。

这里最容易混淆的是两个指标：

• TTFB，即首字节时间。作者在已经建立的 TLS 连接上发出请求，测到第一个字节返回为止，用它观察网络距离和端点响应的基础开销。
• TTFT，即首 token 时间。它来自真实的流式生成请求，更接近用户等待模型开始回答的时间。

网络探测快，不代表模型生成快，更不代表回答质量好。

作者在持有付费密钥的服务商上测得，网络部分占 TTFT 的比例介于 2% 到 78%。例如，Groq 提供的 gpt-oss-120b，德国测得的 TTFT 中位数是 354 ms，东京则为 1,371 ms。

作者据此认为，对响应很快的小模型，选对服务所在的大洲，可能比换模型更重要。这有实际参考价值，但两地差异不能全部直接归因于地理距离：原文没有展示足够的控制实验来排除路由、服务调度等因素。

原文提到了各地区过去 24 小时的最快端点排名，但输入材料没有附上具体榜单，因此无法据此点名推荐某一家。

可用率必须带上时间窗口和测量地点

过去 24 小时的 50,006 次探测中，44 家服务商里有 36 家没有漏掉任何一次响应；把窗口拉长到 7 天，44 家中就有 26 家至少失败过一次。

这两组数字可以同时成立。短窗口适合观察近期状态，长窗口才更容易暴露偶发问题。只写一个可用率，不交代时间范围，比较价值很有限。

地区也会影响结果。作者在过去 7 天观察到，东京的失败频率是德国的 2 倍。只从一个机房监控，很可能漏掉其他地区的访问问题。

但这套统计对「服务商故障」有严格定义：同一分钟至少两个地区失败，且其他服务商没有失败，才计入该服务商的故障。单地区失败会列出，却不计入。

这有助于减少把探测端网络问题算到服务商头上的情况，也会收窄统计范围。例如，多家服务商同时受影响的事件，按这个规则可能不会计入单家故障。

另外，44 家中只有 11 家提供程序可读取的状态源。准备自动切换备用服务时，不能默认每家都有可用的状态订阅接口。

接入以后，还得盯住模型退役

速度和稳定性之外，作者还整理了服务商官方弃用页面上的 233 条记录，每条都同时包含公告日期和停用日期。不过，输入材料缺少提前通知时长的统计结果，无法判断行业通常会提前多久通知。

按原文截至 2026 年 11 月 7 日的信息：

• claude-opus-4-5 将于 11 月 24 日退役，claude-sonnet-4-5 将于 11 月 30 日退役，替代模型为 claude-sonnet-5-5。
• OpenAI 将于 12 月 11 日退役 gpt-5、gpt-5-mini、gpt-5-nano 和 o3，替代选择为 gpt-5.6 系列。

这些是原文列出的计划，落地迁移前仍需确认服务商公告。

作者提供了 llmlatency.dev 上的 /api/rankings.json、/api/incidents.json、/api/deprecations.json，以及供 agent 使用的 /mcp 端点。数据按 CC BY 4.0 开放，也发布到了 Hugging Face 和 Zenodo。

原文还给出安装命令，方便进一步使用相关工具：

pip install llmlatency

注意这行只有安装步骤，原文没有给出安装后的调用示例。

我的判断

我赞成把「哪家最快」改成「从我的部署地区调用，哪家更合适」。这比脱离调用位置看排行榜，更贴近 Node 服务端接入 AI API 的实际情况。

但这仍是一份外部观测，不能当作服务商 SLA。探针来自数据中心，作者也明确说，绝对延迟通常低于家庭网络；TTFT 只覆盖作者购买了密钥的部分服务商，样本较薄。

作者自费运营、没有服务商付费，这是利益关系披露，不能代替方法验证。相较于直接采用公共排名，我更倾向于用它筛选候选，再从业务部署地测真实请求。原文没有提供选型前后的业务对照数据，因此「选地区比选模型更重要」应当保留适用条件。

能拿来做什么

• 如果通过 Node 后端调用模型，就从后端实际部署地区测 TTFB 和 TTFT。若由浏览器直接调用，则应关注用户所在网络，避免把机房结果直接当作用户体验。
• 给 AI 编程工具或聊天功能选服务时，分别记录首 token 时间、完整生成耗时和任务完成质量，再决定是否切换模型或服务商。
• 设计故障切换时，同时观察调用错误和服务商状态源，并保留单地区失败记录；公共故障统计无法覆盖你的全部访问问题。
• 把正在使用的模型 ID 纳入维护清单，定期检查弃用信息，并在退役前用现有任务验证替代模型的效果。