# AI Gateway 延迟指南：分别测量网关、供应商与获救请求

> 网关确实增加一跳，但用户感受到的是完整请求路径。应分别测量客户端往返、首 token、流持续时间和网关处理，并把首次尝试、重试、回退与缓存命中分成不同组，避免平均值掩盖请求快慢的真正原因。

_发布 2026-08-15 · 更新 2026-08-15 · [KeepRouter Editorial](https://keeprouter.com/editorial-policy#editorial-team) · 9 分钟阅读_

![拆分客户端、网关、供应商、重试与生成阶段的端到端 AI 请求延迟轨迹](https://keeprouter.com/editorial/blog/ai-gateway-latency-guide.png)

_把新增网关跳转与供应商耗时、被重试或故障切换挽救的请求分开测量。_

**先给结论：**比较 AI Gateway 与供应商直连时，应固定客户端区域、模型线路、提示词、输出上限、流式模式和连接状态。报告 p50、p95 与 p99 的首 token 和总完成时间，并给重试、回退与缓存结果加标签，不要把它们混成一个平均值。

网关自身处理时间很重要，但只是用户可见延迟的一部分。DNS、TLS、连接复用、请求上传、网关准入、供应商路由、供应商排队、模型生成、流传输与客户端解析都会产生影响。

## 采集前先定义时钟

| 时钟 | 起点 | 终点 | 回答的产品问题 |
|---|---|---|---|
| 客户端往返 | 发送前一刻 | 终止响应或错误 | 用户等待了多久？ |
| 首字节时间 | 发送前 | 第一个响应字节 | 链路多快开始响应？ |
| 首 token 时间 | 发送前 | 第一个可用模型输出 | 生成的响应感如何？ |
| 流持续时间 | 第一个 token | 终止事件 | 输出生成和传输多久？ |
| 网关上游前处理 | 网关收到 | 发出上游请求 | 准入、转换和路由做了什么？ |
| 网关上游后处理 | 收到上游响应 | 发给客户端 | 规范、日志或计费做了什么？ |

不要把一家厂商的内部处理数字与另一家的客户端往返直接比较，也不要把一个区域的平均值与另一区域的尾部分位数比较。每个结果旁边都应写清测量定义。

## 建立可重复请求集

删除密钥后使用生产形态载荷。至少包含短非流式、流式、代表性长上下文、工具调用与预期失败。固定公开模型 ID；产品允许时，还要固定供应商线路与模型版本。

保持相同输出上限，否则某条线路可能因为产生更多有效内容而显得更慢。temperature 与 reasoning 控制在生效时也要保持一致。把响应使用量和终止状态与时间数据一起保存。

## 控制网络路径

从同一计算位置运行直连与网关请求。记录 DNS 与 TLS 是否预热、HTTP 连接是否复用，以及网关或供应商是否冷启动。住宅网络浏览器与云区域服务器回答的是不同问题。

先测试低并发，再测试应用预期并发。单请求中看不到的排队，可能在突发流量中占主导。使用足够样本让尾部分位数有意义，并公开样本量。

## 按线路结果拆分数据

| 分组 | 为什么必须分开 |
|---|---|
| 首次尝试成功 | 说明不含恢复成本的正常线路 |
| 同线路重试 | 包含必要或可避免的第二次尝试 |
| 供应商故障切换 | 改变网络、队列、缓存，可能还改变数据策略 |
| 模型回退 | 改变生成行为与输出长度 |
| 缓存命中 | 可能完全跳过模型生成 |
| 缓存未命中 | 同时承担查询与正常生成 |

回退可以提高完成率，也会让该请求更慢。这可能是合理产品取舍，但一个延迟平均值无法解释。应把时间与成功率和任务质量一起看。[故障切换设计指南](/zh/blog/llm-failover-design-guide)说明如何识别各次尝试。

## 用证据拆分网关工作

认证、额度检查、策略查询、请求转换、日志写入、费用计算、缓存访问与响应规范都可能增加时间。关键路径取决于实现，远程数据库或同步日志服务的影响可能超过代理代码本身。

如果产品提供 trace span 或网关时间戳，应直接使用。跨系统相减前先确认时钟同步。如果只能取得客户端数据，就明确报告边界，不要虚构内部归因。

## 把流式当作有状态协议测量

记录第一个有效事件、第一个内容 token、工具调用事件、用量事件与终止事件。连接可以很快打开，却很晚才产生可用内容；没有终止事件的流，在首字节图上可能很快，却会留下不完整计费和客户端状态。

取消流并观察供应商工作与计费何时停止。使用慢客户端测试 backpressure。网关不应无界缓冲流，也不应改变客户端依赖的事件顺序。

## 按交互设定预算

自动补全、聊天、代码 Agent 与后台任务需要不同预算。为首 token 与总完成时间设置可接受 p95 增量，同时为重试设置最大总截止时间。供应商选择与上游负载会变化，发布后仍需监控同一指标。

简短说明见[网关是否增加延迟](/zh/answers/does-ai-gateway-add-latency)，再用 [AI Gateway 评估框架](/zh/blog/evaluate-ai-gateway)把延迟与契约、可靠性、安全和成本证据结合。

## 常见问题

### 应该报告哪个延迟分位数？

至少报告 p50 与 p95，样本量足够时报告 p99，并附样本数与测试窗口。

### 缓存命中应计入平均值吗？

应作为独立分组。缓存命中与模型生成是不同执行路径。

### 首字节可以替代首 token 吗？

不能。网关可能在可用模型输出前发送响应头或元数据，两只时钟回答不同问题。

### 重试应如何出现在延迟报告中？

给每次尝试加标签，并把首次成功、获救请求与耗尽失败分别报告。

## 参考的一手资料

_本文最近复核 2026-08-15_

1. [OpenTelemetry trace concepts](https://opentelemetry.io/docs/concepts/signals/traces/)
2. [Cloudflare AI Gateway analytics](https://developers.cloudflare.com/ai-gateway/observability/analytics/)
3. [Vercel AI Gateway observability](https://vercel.com/docs/ai-gateway/observability)
4. [KeepRouter API observability](https://keeprouter.com/features/api-observability)

## 继续阅读

- [AI Gateway 会增加延迟吗？](https://keeprouter.com/zh/answers/does-ai-gateway-add-latency.md)
- [LLM 故障切换设计指南：恢复请求，同时避免不安全重试](https://keeprouter.com/zh/blog/llm-failover-design-guide.md)
- [API 可观测性](https://keeprouter.com/zh/features/api-observability.md)
- [如何用证据型评分卡评估 AI Gateway](https://keeprouter.com/zh/blog/evaluate-ai-gateway.md)
- [按场景选择 AI Gateway](https://keeprouter.com/zh/compare/best-ai-gateways.md)
- [AI Gateway 对比供应商直连 API](https://keeprouter.com/zh/compare/direct-provider-apis.md)

[全部文章](https://keeprouter.com/zh/blog.md) · [模型与价格](https://keeprouter.com/models.md)