慢不是模型慢：AI 服务延迟里藏着四个可量化的成分

上周帮一个团队看线上问题：客服机器人回答太慢，用户投诉，老板一句"换更快的模型"。换完之后，P95 延迟降了大概 400 毫秒，投诉还是没少。问题出在哪？他们只测量了"模型推理"这一段，但用户感知到的等待时间里，模型推理只占一小块。

把一次完整的 AI 服务调用拆开，延迟通常由四段组成：**网络往返、排队等待、prompt 处理（prefill）、逐 token 生成（decode）**。这四段的性质完全不同，对应的优化手段也完全不同，混在一起看就会得出"换模型"这种笼统结论。

**网络往返**好办，测 `t_proxy` 就行：从请求发出到收到第一个字节。跨地域叠加 TLS，单次 80 到 200 毫秒是常态。这一段优化的办法是把推理服务部署得离用户近，或者用流式响应保持长连接，作用有限但上限明确。

另外别忘了**客户端到网关**之间还有一段：用户端自己调 API 的超时设置如果只有 10 秒，你的服务明明 12 秒能答完，在用户眼里就是"挂了"。跨团队联调时，先把双方的超时对齐，比调任何参数都快。

**排队等待**是最容易被忽略、也最容易出事的一段。连续批处理（continuous batching）下，你的请求可能前面排着几十个。同一个"7B 模型"，空闲时首 token 200 毫秒，高峰期 3 秒都不奇怪。这段延迟和流量强相关，所以必须按分位数监控——看均值会骗自己，P95 和 P99 才是真实体验。

一个容易踩的坑：把"首 token 时间"当成整体 SLA。服务端报了 P95 首 token 800 毫秒，体感很好；但输出平均 500 个 token，decode 每秒 40 个，用户拿到完整答案要等 13 秒。首 token 快只影响"是否开始焦虑"，完整答案时长决定"是否放弃等待"，两个都要盯。

**prefill** 和并发也有关系，但有硬下限：一次处理上万 token 的长 prompt，就算 GPU 全空，首 token 也要等上几秒。所以"长文档问答"类和"短问句"类的服务，延迟基线天然不同，不能用一套 SLA 管。

实测里经常看到的现象：同一个模型，1 万 token 的 prompt 首 token 约 1 秒，8 万 token 直接 8 到 10 秒。这不是模型变慢了，是被 prompt 长度压住了。所以"把历史对话全塞进 prompt"的写法，延迟代价是线性增长的，用户侧完全无感知但账单和时延双涨。截断、摘要、或者检索只注入相关片段，都是针对这一段的杠杆。

**decode** 是逐 token 输出，速度基本由显存带宽决定（每生成一个 token 都要读一遍 KV cache），升级带宽更高的显存直接受益。但用户从"看到第一个字"开始就不焦虑了，所以体感上 decode 慢 50% 未必有人投诉，首 token 慢 500 毫秒一定有人投诉。

这也是为什么你觉得"答得不快但没人骂"，而竞品"首句快但尾部毛糙"反而体验更好——进度感本身就是产品能力，流式输出基本是标配。

怎么落地

三个动作，两周能做完：

1. **拆开计时**。在网关层记录四个时间点：请求到达、首字节、流式中间点（比如第 10 个 token）、完成。不拆，一切优化都是猜。

2. **监控用分位数**。按 P50 / P95 / P99 分别报四段延迟，趋势上任何一段恶化超过 30% 就告警，不用等用户投诉。

3. **按场景设 SLA 和降级**。短问句服务承诺 P95 首 token < 1.5 秒；长文档场景单独放宽。队列长度超阈值时，直接降级到小模型或返回"排队中"，别让请求在队列里无限膨胀——一个 30 秒队列里的 100 个请求，不如在 3 秒内让一半走小模型。

"换更快的模型"只有在 decode 段占比超过 50%、且当前模型确实小一个数量级时才划算。在动手之前，先花一天把四段延迟的量打出来——大多数团队量完会发现自己排队等了半天，白升级了显卡。