AI 功能的延迟预算：当核心组件是随机的，如何制定并达成 p95 SLO

你的系统平均端到端延迟为 400ms，p95 是 4.2 秒，p99 是 11 秒。在产品规格中你承诺了"亚秒级"体验。仪表盘上的每个指标看起来都很正常，直到有人问起 5% 的用户遭遇了什么——这时，你一直引以为傲的平均值才成了埋葬你的东西。

这就是 AI 功能的延迟预算问题，它与你之前解决过的问题有着本质区别。当核心组件是数据库查询或微服务调用时，p95 延迟大致可预测，并且适用标准 SRE 技术。而当核心组件是 LLM 时，响应时间的分布呈重尾特征，依赖于输入，并且部分由你无法控制的条件驱动。在制定诚实的 SLO 之前，你需要一套不同的思维模型——更别说去达成它了。

为什么 LLM 延迟会颠覆你已有的直觉

在典型服务中，延迟方差来自排队、GC 暂停和偶尔的慢磁盘。分布大致呈对数正态分布；p95 大约是中位数的 3–5 倍。你可以设置超时，观察百分位数，当 p99 漂移时触发告警。

LLM 延迟不是这么回事。两个因素使其在结构上与众不同：

输出长度是延迟计算的输入，而非常量。 生成 50 个 Token 的请求完成时间，只是生成 800 个 Token 的请求的一小部分——而你通常要到生成完成才能知道会生成多少 Token。这造就了一种不仅分布宽泛、甚至呈双峰的分布。短查询聚集在低延迟端，长文本生成聚集在高延迟端，而分布的形态随用户实际提问内容的不同而变化。

你在租用上游提供商的算力。 与自托管数据库不同，你的 LLM 推理算力与其他租户共享。冷队列、突发流量和提供商故障会引入延迟峰值，且这些峰值是相关的——当提供商变慢时，所有人同时变慢，而这恰恰是你最需要可靠性的时候。在正常负载下平均 TTFT 为 300ms 的系统，在高峰期可能达到 4 秒——不是因为你的代码变了，而是因为队列深度变了。

实际结论：如果你基于中位数设定 SLO，你是在向中位数用户做出承诺，同时悄悄地抛弃了其余用户。与传统服务不同，你无法简单地通过过度供给来解决这个问题——你并不拥有推理算力。

先测量：分解延迟栈

在设定 SLO 之前，你需要分解自己实际在测量什么。LLM 延迟有三个不同的组成部分：

首 Token 时间（TTFT）——从发送请求到第一个 Token 流回的延迟。这决定了 UI 是否感觉响应迅速。对于对话式界面，用户会注意到超过 200–300ms 的 TTFT。对于非交互式功能（后台摘要、异步分类），它的重要性要小得多。TTFT 由提示词处理、队列深度和模型预填充时间驱动。

每输出 Token 时间（TPOT）——首 Token 之后的 Token 生成速率。对于长输出，这主导了总生成时间。一个以 30 Token/秒生成的模型，无论 TTFT 多快，生成 300 个 Token 的响应都需要 10 秒。TPOT 主要由模型架构和 GPU 内存带宽决定。

端到端延迟——包括你的应用服务器、任何 RAG 检索、工具调用、后处理和网络开销在内的完整往返时间。这是用户实际体验到的延迟。

每个组成部分都需要独立的 SLO，并且需要分别设定。笼统的"p95 < 2s"目标对其中至少一个几乎肯定是错误的，而且无法告诉你应该修复栈的哪个部分。

实用起点：

• 面向用户的对话功能：TTFT p95 < 500ms
• 非对话功能（文档分析、报告生成）：TTFT p95 < 2s
• 包含工具调用的复杂 Agent 任务：端到端 p95 < 5s
• 批量/异步功能：吞吐量 SLO，而非延迟 SLO

这些数字需要根据你的实际使用数据进行校准。在承诺 SLO 之前，先测量两周的真实分布。

制定延迟预算：谁负责什么

一旦你为 TTFT 和端到端分别设定了 SLO，就需要为栈中的每一层分配预算。这是团队通常出错的地方——他们把提供商的延迟视为整个预算，却忘记了应用代码、编排开销和检索步骤也都在消耗时间。

一个针对 RAG 聊天功能、SLO 为端到端 p95 < 1.5s 的现实预算可能如下：

• 网络往返（客户端到服务器）：50ms
• 应用路由和鉴权：30ms
• Embedding + 向量搜索：150ms
• 上下文组装和提示词构建：50ms
• LLM TTFT：400ms
• 剩余生成（流式传输到客户端）：无上限，但首内容在 480ms 内可见
• 后处理和响应格式化：20ms
• 到首个有意义内容的总预算：~700ms p95

一旦你把这些列出来，两件事就变得显而易见。首先，没有任何余量。每一层都需要在子预算内完成，否则即使模型很快，顶层 SLO 也会失败。其次，模型并不是唯一的变量——Embedding 延迟、p95 的向量搜索，以及你的应用服务器中的冷路径，都很重要，而且都可以单独测量。

将此预算视为团队间的契约。平台团队负责 LLM TTFT 预算，应用团队负责 RAG 和编排预算。当顶层 SLO 被违反时，你就知道是哪个组件消耗了预算。

真正有效的策略

加载中…