主流模型 P99 延迟对比
选模型的时候，团队经常盯着”平均响应时间”这一个数字做决策，但真正决定用户体验和系统稳定性的往往是 P99——那 1% 最慢的请求。一个平均延迟 800ms 的模型，如果 P99 冲到 8 秒，意味着每 100 次调用就有一次让用户明显感知到卡顿，高并发场景下这个比例会被放大成实实在在的投诉量。这篇文章不给一份”谁比谁快 X%“的榜单（不同供应商的延迟随时间、区域、负载持续变化，静态榜单发布即过时），而是讲清楚怎么测、看哪些指标、哪些因素在背后决定尾延迟，帮你搭建一套自己随时能跑的对比方法。
一、为什么平均值会骗人
假设两个模型 A 和 B 处理同一批 100 个请求：
- A：99 个请求都在 700ms 左右完成，1 个请求因为触发了服务端重试花了 6 秒 → 平均延迟约 753ms
- B：100 个请求都稳定在 900ms → 平均延迟 900ms
只看平均值，B 看起来更慢。但如果你的产品是面向终端用户的实时对话场景，A 的那 1% 慢请求可能才是决定用户是否流失的关键——平均值掩盖了分布形状。P99（乃至 P999）关注的正是这种”长尾”，工程决策该看的是分布，不是单点。
二、测量 P99 延迟要控制哪些变量
自己搭建延迟基准测试时，以下变量不控制好，测出来的数字没有参考价值：
| 变量 | 为什么重要 |
|---|---|
| Prompt 长度与输出长度 | 首 token 延迟（TTFB）主要受输入长度影响，总耗时主要受输出 token 数影响，必须固定测试用例的长度分布才能横向比较 |
| 是否流式输出 | 流式场景应该测 TTFB（首字延迟），非流式场景测总耗时，两者混着测没有意义 |
| 并发压力 | 单请求测出来的延迟和高并发下的延迟可能差数倍，测试要覆盖你实际的流量并发水平 |
| 测试时段 | 模型服务商的负载有明显的时段波动（工作时段 vs 深夜），单次测量容易赶上一个不具代表性的时间点 |
| 网络路径 | 国内直连 vs 需要中转/代理的网络路径，延迟差异可能比模型本身的推理耗时还大，测试时要固定网络条件，或者把网络延迟单独拆出来看 |
| 地区/机房 | 同一个模型在不同区域部署的实例延迟不同，测试要明确针对哪个区域 |
一个常见的坑是把”网络延迟”和”模型推理延迟”混在一起报告——如果测试环境本身到目标 API 的网络就不稳定，测出来的 P99 更多反映的是网络质量而不是模型性能。
三、影响尾延迟的关键因素
抛开具体数字，尾延迟异常通常来自以下几类原因，理解这些有助于判断”这次慢是正常波动还是真的有问题”：
- 输出长度的随机性：LLM 输出长度本身不确定，同样的 prompt 因为解码路径不同可能生成 200 token 也可能生成 2000 token，输出越长总耗时自然越长，这部分方差是模型行为决定的，不是延迟不稳定
- 服务端排队与限流：高峰期请求排队等待可用算力，这是尾延迟最常见的来源，也是为什么同一个模型白天和凌晨测出来的 P99 能差好几倍
- 重试与降级：客户端或网关在请求失败后自动重试，一次成功的重试会让这个请求的总耗时看起来异常高，统计 P99 时要想清楚是否要把重试耗时算进去
- 冷启动：部分供应商的某些模型/区域在低流量时会有实例缩容，首次请求需要唤醒实例，这类冷启动延迟会集中体现在尾部
- service tier 差异：部分供应商提供不同优先级的服务档位（如 flex/priority），低优先级档位在资源紧张时延迟会明显更不稳定，这部分可以参考 OpenAI service_tier 延迟与成本取舍
四、一套可复用的对比方法
与其等别人发布榜单，不如把对比测试变成可以随时重跑的脚本，跑在你自己实际会用到的网络环境和流量模式下：
- 固定测试集：准备一组覆盖不同输入/输出长度的 prompt（比如短问答、中等长度摘要、长文档处理），每个模型跑同一批，保证可比性
- 足够的样本量：P99 统计意义上至少需要几百次请求才能得到稳定的分位数估计，样本量太小（比如只测 20 次）算出来的”P99”噪声很大，参考意义有限
- 分别记录 TTFB 和总耗时：流式场景两个指标都要采，因为它们反映的是不同的用户体验维度——TTFB 决定”感觉响应快不快”，总耗时决定”任务多久能完成”
- 按时段多轮采样：至少覆盖一个业务高峰时段和一个低峰时段，避免单次采样的偶然性
- 把网络层单独测一次基线：比如用简单的健康检查接口测一次到目标区域的纯网络往返时间，作为后续拆解”到底是网络慢还是模型慢”的参照
这套方法论和评测流水线可以结合日常的模型评测一起跑，参考 把模型评测接进 CI 流水线 把延迟基准也纳入定期自动化监控，而不是等用户投诉了才想起来测一次。
五、拿到数据之后怎么用
测出 P99 只是第一步，实际决策还要结合业务场景权衡：
- 实时交互场景（对话、代码补全）：TTFB 的 P99 是核心指标，总耗时次要，可以考虑用流式输出 + 更小的模型来压低尾延迟
- 批处理/异步场景（离线摘要、批量分类）：总耗时的 P99 更重要，可以容忍更高的延迟换取更好的质量或更低的成本
- 延迟敏感但对失败容忍的场景：可以设置客户端超时 + 降级到备用模型/中转节点的策略，把尾延迟的影响兜底住，具体做法可以参考 降低 LLM 延迟的 10 种实战方法
- 国内访问场景：网络路径本身往往是尾延迟的主要贡献者，先排查网络层再怀疑模型本身，可以参考 国内访问延迟优化实测 里的具体排查思路
六、常见误区
- 只测一次就下结论：延迟有明显的时段和负载波动，单次测量的”P99”往往只是噪声。
- 不区分 TTFB 和总耗时：两者优化手段完全不同，混为一谈会导致优化方向跑偏。
- 忽略测试环境的网络质量：测试机房离目标 API 服务器很远、或者走了不稳定的代理，测出来的数字反映的是网络问题而非模型问题。
- 拿别人发布的榜单直接套用到自己的场景：不同的输入长度分布、并发模式、地理位置都会让实际延迟表现和公开榜单有明显出入，最终还是要用自己的流量模式测一遍。