延迟预算

它是什么

延迟预算是一次 AI 交互允许消耗的端到端时间上限，并把这段时间分配给预处理、检索或工具、模型、后处理和网络。对流式体验，通常还要分别规定首个可见结果和完整结果的目标。预算是设计约束，不是一次测量出的平均延迟；它必须说明工作负载、百分位和超时行为。[S1][S2]

为什么需要它

一个“模型平均 2 秒”的数字无法保证用户体验：检索、连续工具调用和网络可能再增加数秒，少量尾部请求甚至等待更久。端到端预算迫使产品与工程共同决定时间该花在哪里、什么可以并行、何时显示进度，以及超时后应回退还是停止。

它如何工作

先从用户任务和服务目标定义 P95 等百分位目标，并区分首字延迟与完整完成时间。再为输入处理、检索、工具、模型、后处理和网络分配子预算，给各阶段设置截止时间并用分布式追踪测量。优化时优先减少不必要的顺序调用与输出、并行独立工作，并用流式呈现改善感知等待；总预算耗尽时取消、回退或转异步。[S1][S2]

必须澄清的误会

延迟预算 ≠ 感知延迟。 感知延迟是用户主观觉得等了多久；延迟预算是工程上的时间承诺。先给进度反馈能让感知延迟远低于实际耗时。

延迟预算 ≠ 延迟。 延迟是实测出来的耗时数字，预算是在这个数字之外预先定下的上限。

真实例子

客服助手把 P95 完整响应目标设为 8 秒、首个可见内容设为 1.5 秒。预算分配为输入与路由 0.3 秒、检索 1.2 秒、模型首字 1 秒、生成 4.5 秒、后处理与网络 1 秒。检索和用户资料查询并行；6 秒仍未得到可用内容时停止非必要工具，8 秒到期则取消生成并提供人工入口。团队同时记录首字和完整延迟，而不是用流式动画掩盖超时。

什么时候适合与不适合

交互式问答、实时辅助和多工具流程都需要明确预算；异步报告可以允许更长完成时间，但仍应有截止和状态通知。减少输出、并行调用或使用更快模型可能牺牲解释质量、提高成本或增加错误；流式输出只降低感知等待，不一定缩短完整生成。平均值还会掩盖高峰和尾部失败。[S1][S2]

亲自试一下

选择一个 AI 交互，写出 P50 与 P95 的首字和完整响应目标，再把 P95 完整预算分给至少四个阶段，确保子预算之和不超过总预算。为每个阶段写明测量点、超时动作和一个可并行机会。若方案只写“响应要快”，或各阶段预算相加超过总目标，就重新分配。

接下来学什么

先回到AI 产品把等待时间连接到用户任务，再学习感知延迟设计过程反馈；工程上继续学习延迟的测量口径、流式响应和备用模型。

来源与修订

减少生成与请求、并行、流式呈现及避免不必要模型调用参考 OpenAI 延迟优化指南 [S1]；可靠性目标、首字与流式指标、百分位监控和分布式追踪参考 Google Cloud AI/ML 可靠性指南 [S2]。模型速度、网络、负载、工具链与用户预期会变化，预算必须使用当前生产数据持续校准。