AI 产品和传统 Web 产品最大的差异之一，是用户对等待的耐受度完全不一样。一个按钮点下去 300 毫秒没反应，用户可能只是觉得页面有点卡；但如果一个 AI 助手在 8 秒后才开始输出，用户往往会直接怀疑它是不是坏了。
所以做 AI 产品时，延迟从来不是单一接口指标，而是一整条用户感知链路的设计问题。什么时候开始返回、返回多久、失败时等多久、要不要边生成边展示，这些都决定了用户到底觉得它“快”还是“慢”。
第一步，不要只看平均时延
很多团队做性能优化时，最先盯的是平均响应时间。但在 AI 场景里，这个指标参考价值有限。平均值可能很好看，P95 和 P99 却已经把用户体验拖垮。因为对用户来说，真正留下印象的往往不是“多数请求很快”，而是“关键时候是不是总会卡住”。
我们更建议把延迟拆成三层：
- 首响应时间，也就是用户多久能看到系统开始工作。
- 完整响应时间，也就是整个答案什么时候真正结束。
- 异常等待时间，也就是失败和回退会把等待拉长到什么程度。
只有把这三层分开看，团队才能知道到底要优化哪里。
第二步，先给不同任务定义不同预算
不是所有 AI 请求都该共享同一套时延目标。实时问答、批量总结、异步报告生成，本来就属于不同类型的任务。如果全都套一个统一 SLA，结果通常是要么成本过高，要么体验不稳定。
一个更合理的做法，是按任务类型定义不同预算：
- 实时对话：优先首响应，允许结果后续补全。
- 复杂分析：允许更长时间，但过程需要可见。
- 批量任务：优先吞吐和稳定，不必追求即时返回。
- 工具型调用：优先结构正确和边界可控。
预算一旦定义清楚，后续的模型选择、缓存策略、回退逻辑和前端交互才能跟着一致。
第三步，把延迟拆回链路
AI 请求变慢，经常不是模型本身慢，而是前后链路都在加时间。一个看起来“模型推理 8 秒”的请求，拆开后可能是：
- 前端预处理和网络传输 300 毫秒。
- 网关鉴权和路由判断 200 毫秒。
- 检索和上下文拼装 1 秒。
- 模型实际生成 4 秒。
- 工具调用和结果整合 2 秒。
- 回退或重试又额外加 2 秒。
如果不把延迟拆回链路，团队就很容易把所有责任都推给模型，然后错过真正能立刻优化的部分，比如缓存、Prompt 收缩、并行调用、工具超时或回退边界。
第四步，延迟优化不是越快越好
很多工程优化看起来能让响应更快，但会牺牲稳定性或者成本。比如把超时阈值压得很低，可能会让系统更快失败；把回退开得很激进，可能会让少数请求成功得更快，但整体成本暴涨；把上下文压得过短，又可能让质量出现隐性退化。
所以延迟优化最关键的不是“所有地方都快”，而是“快得值不值得”。我们更倾向于把延迟预算和质量预算、成本预算一起设计，而不是各自为战。
体验上，要尽量让等待变得可理解
用户并不天然排斥等待，用户排斥的是“不知道为什么要等”。因此在 AI 产品里，体验设计和性能设计应该一起做。
一些简单但很有效的做法包括：
- 尽早返回首 token 或状态反馈。
- 对长任务显示阶段性进度，而不是静默等待。
- 对明显超预算的请求，提前提示系统正在切换方案。
- 对异步任务给出结果回收入口，而不是让用户一直守着页面。
这类设计不一定能减少真实时延，但能显著改善用户对时延的感知。
平台层最该做的是控制尾部时延
如果只能在一个方向上投入，我们通常优先优化尾部时延，而不是平均值。因为尾部时延才是最容易摧毁信任的部分。一次很慢的关键请求，往往会让用户对整个产品都失去耐心。
平台在这里能做的事情包括：更稳定的主路由选择、更严格的回退边界、更早的异常探测、更细粒度的缓存和更明确的任务分层。所有这些动作的目标都不是把每个请求都做到最快，而是尽量减少“不可预测地变慢”。
结语
AI 产品的延迟预算，本质上是一种体验预算。它不只属于后端性能团队，也不只属于模型工程师，而是产品、平台和前端共同决定的结果。真正做得好的系统，不会把“慢”简单理解成技术缺陷，而会把它当成需要被设计、被分配、被持续校准的资源。