调用 AI 接口时，「延迟 800 毫秒」这句话几乎没有信息量。是第一个字回来用了 800 毫秒，还是整段 800 字生成完用了 800 毫秒，用户体验差一个量级。测延迟要先做的一件事，是把这两个时间点拆开，分别定义、分别采样，再决定用哪个数字验收。
首字和整段，差在哪一段路
首字延迟从请求发出算到收到第一个内容片段，路上包含排队、网络往返、输入预处理，以及模型把整段提示词读一遍后吐出第一个 token。整段延迟算到最后一个片段到达，等于首字延迟加上「输出 token 数 ÷ 每秒生成 token 数」。这个加法关系决定了排查方向：首字慢，先看排队和输入长度；整段慢，先看输出长度和解码速度。
只有流式返回才谈得上首字延迟。接口一次性返回完整结果时，客户端拿到的是整包，首字和整段在观测上是同一时刻，这时只能测整段，首字指标要去厂商的监控面板里找。很多「首字延迟对不上」的争议，源头是拿非流式请求去测流式指标。
测试前要固定的五个条件
模型版本、输入长度、输出长度、并发数、测试机位置。这五项任何一项变了，数字就不能跨天比较。输入长度按 token 算而不是按字数算，中英文的折算比例不同；输出长度用 max_tokens 卡住，同时确认没有提前触发停止符，否则同一道题每次生成的长度都不一样。
连接方式也要固定。每次新建连接会把 DNS 解析和 TLS 握手的开销算进首字，复用连接则不会。两种测法都合理，但要说明测的是哪一种，否则两组数据放在一起没有意义。
看分位数，不看平均值
100 次请求里 90 次 600 毫秒、10 次 3 秒，平均下来 840 毫秒，看起来还能接受，但用户每十次就撞上一次 3 秒。平均值把长尾抹平了，而体验由长尾决定。P50 代表典型体验，P90 和 P95 代表经常遇到的慢请求，P99 代表极端情况。三个数一起报，别只报一个。
样本量建议不少于 30 次，条件允许就跑 100 次。次数太少时 P95 实际上就是第二慢的那次请求，波动极大。同时记录超时和重试的次数，失败请求如果被排除在统计之外，得到的是一份偏乐观的报告。
并发要压到拐点，网络要贴近生产
单请求测出来的是理想值。线上几十个请求同时打过去，排队时间会计入首字延迟，而且不是线性增长：接近服务端并发上限时，P95 会突然抬起来。至少跑 1、5、20 三档并发，看曲线在哪个点开始翘。拐点之前的并发，才是这套配置的真实容量。
网络位置差的是几十到几百毫秒的往返。办公室宽带、同区域云主机、跨地域调用，三种位置的数字不能互相替代。跨地域还会放大丢包重传的影响，表现为偶发的秒级尖峰。测试机放在离生产环境较近的位置，并记录调用时刻，厂商侧的负载波动有时比你的代码更能解释差异。
按交互类型定验收线
| 交互类型 | 首字延迟的地位 | 整段延迟的地位 | 验收时看什么 |
|---|---|---|---|
| 实时对话、语音助手 | 决定「有没有反应」，必须优先压 | 次要，用户会边听边等 | P95 首字是否稳定，抖动比均值更关键 |
| 写作补全、代码补全 | 决定输入是否跟手 | 中等，取决于补全长度 | 连续触发时的 P90，单次成绩没有参考价值 |
| 后台批处理 | 基本不看 | 决定任务何时跑完 | 吞吐量与 P99 整段，失败重试的成本要算进去 |
| 长文档分析 | 输入很长，首字天然偏慢 | 输出长，整段更值得关注 | 按文档长度分档报数，混在一起会失真 |
表格的用法是先给自己的场景对号，再看对应那一列的指标。拿对话场景的整段延迟去验收批处理，或者反过来，都会得出错误结论。
不达标时，按顺序查这四处
先看输入是否过长。提示词从 500 token 涨到 5000 token，预处理时间跟着涨，首字延迟首当其冲。再看输出是否失控，max_tokens 给得过大、提示词没约束篇幅，都会把整段延迟拉长。第三看流式是否真的在流，反向代理的缓冲、SDK 的默认配置都可能把片段攒起来再一次性下发，客户端看到的首字因此变晚。第四看是否在高峰时段测试，同一份代码在白天和凌晨的结果可能差出一截。
还有一处常被忽略：重试。超时后自动重试会把一次慢请求变成两次，统计里如果只记成功那次，延迟看起来正常，实际资源消耗翻倍。
哪些延迟数字不可比
换了模型版本、换了接入地域、换了分词器，数字都不可比。中文一个字可能对应一个 token，也可能对应两个，按字数固定输入长度其实没有固定住计算量。开启了提示词缓存的请求，首字会明显变快，这类请求要和普通请求分开统计，否则会高估日常表现。
厂商公布的延迟通常是特定条件下的实验室数据，可以作为量级参考，不能当作你的验收线。你的网络、你的输入分布、你的并发形态，才是决定体验的三个变量。网页版与本地部署的体验差异也遵循同一套逻辑：同一个模型换个位置，等待时间就变了。
如果测的是语音类产品，首字的权重还要再提高，人耳对「有没有在听」的容忍度很低，电视语音助手的实测方法里对这一点有更细的拆解。代码补全场景则可以参考程序员选 AI 的判断标准，把延迟和补全质量放在一张表里权衡。录音转写是另一个极端，它只有整段没有首字，转写准确率的对比方法更值得看。
接口延迟测试速查
- 首字延迟 = 排队 + 网络 + 预处理；整段 = 首字 + 输出 token ÷ 生成速度
- 固定模型、输入、输出、并发、位置，五项缺一不可
- 报 P50 / P95 / P99，不报平均值；样本至少 30 次
- 并发跑 1 / 5 / 20 三档，找曲线拐点
- 确认流式真的在流，代理缓冲会让首字虚高
