OpenRouter 通过 Cloudflare Workers 边缘计算将网关额外延迟降到最低。影响延迟的主要因素有三个：边缘缓存预热（新区域首次请求较慢）、积分余额检查（余额低时触发额外数据库查询）、以及 Provider 故障时的自动回退重试。最佳实践是维持足够的积分余额（建议 $10-20 以上）并配置 auto-topup，同时利用 provider 路由优化 TTFT 或整体响应时间。

OpenRouter 将性能作为首要设计目标，在每次 API 请求中增加的额外延迟极低。

低开销架构

OpenRouter 采用以下方式将请求延迟降到最低：

• 边缘计算：基于 Cloudflare Workers，运行在靠近你应用的节点，减少物理网络距离
• 边缘缓存：用户数据和 API key 信息在边缘节点高效缓存
• 优化路由：路由决策逻辑本身的处理时间极短

影响延迟的因素

缓存预热（Cache Warming）

OpenRouter 的边缘缓存在"冷启动"状态下（通常是某个区域最初 1-2 分钟），首次请求会略慢。一旦缓存建立，后续请求延迟恢复正常。这一现象在切换区域或长时间未请求后重新调用时较为明显。

积分余额检查

为保证计费准确、避免超额扣费，以下情况 OpenRouter 会对数据库执行额外查询：

• 用户积分余额处于低位（个位数美元）
• API key 接近其配置的积分上限

这些额外查询会导致该时段请求延迟明显上升，直到充值后积分余额恢复正常为止。

Provider 故障回退

使用模型路由或 Provider 路由时，若主 Provider 出现故障，OpenRouter 会自动尝试下一个候选 Provider。失败后重试本身不可避免地会增加该次请求的延迟。

不过 OpenRouter 会持续追踪 Provider 的可用性状态，在后续请求中智能绕开不可用节点，避免每次都触发故障重试。

最佳实践

维持充足积分余额

积分余额过低是引发额外延迟最常见的原因：

• 开启 auto-topup（自动充值），设置较高的触发阈值和充值金额
• 建议账户余额始终保持在 $10-20 以上，避免余额临界触发强制数据库检查
• 在请求高峰期到来前提前充值，而不是等余额耗尽再手动操作

利用 Provider 路由控制延迟

不同 Provider 在 TTFT（首 token 延迟）和整体响应时间上差异明显：

• 对延迟敏感的场景（如实时对话），优先选择 TTFT 更低的 Provider
• 可通过 Provider 路由配置指定 Provider 偏好或排除特定 Provider
• 合理设置 provider.order 或 provider.require_parameters，避免路由到不符合需求的节点

常见问题

Q: OpenRouter 本身增加了多少延迟？

A: 通常在 5-20ms 以内（边缘计算节点正常运行状态）。绝大多数延迟来自模型 Provider 本身，而非 OpenRouter 网关。

Q: 为什么有时候同一模型请求的延迟差距很大？

A: 主要原因有三：①该次请求触发了积分余额检查；②主 Provider 不稳定，触发了故障回退；③边缘缓存刚被清理，处于预热阶段。维持充足积分并配置合理的 Provider 偏好可以减少这类波动。

Q: 如何监控请求延迟？

A: 可以通过 /api/v1/generation?id={id} 接口获取每次请求的详细耗时统计，也可以在活动面板中查看历史请求的响应时间。