LLM 延迟 SLO 规划器

要解决的问题

在大模型产品里，延迟通常只被看成一个数字：整体平均耗时。但平均值会掩盖尾部问题——一次工具重试、一次 provider 连接缓慢、一次长输出生成，都可能让用户在几秒甚至十几秒内看不到任何反馈。等到上线后才发现 P99 超标，往往很难定位是哪一段在拖后腿。

这个技能做什么

该技能把延迟拆成可观测的阶段，而不是只看端到端汇总。核心工作方式如下：

1. 定义用户旅程与同步截止时间：先明确一次请求必须在多少时间内给出可见反馈，哪些环节是同步的、哪些可以异步或流式。
2. 分段测量：分别记录 queue、retrieval、prompt assembly、provider connection、time-to-first-token、generation、tools、retries、post-processing，避免把不同性质的开销混在一起。
3. 设定百分位目标：对 time-to-first-token 与 completion / task success 分别给出 P50/P95/P99 目标，而不是只设一个平均值。
4. 分配组件预算：把总预算拆到各个阶段，并显式保留余量（headroom），防止各段预算之和刚好等于截止时间。
5. 定义错误预算：区分 slow success、timeout、failure 三类结果，并据此计算错误预算。
6. 分维度切分：按 model、provider、region、输入/输出大小、是否 streaming、工具数量等维度拆分，定位是某一类请求还是某个 provider 出问题。
7. 基于燃烧率与持续尾部漂移告警：关注 burn rate 和持续的 tail shift，而不是对孤立采样点报警。

最终输出包括 SLI 定义、百分位目标、组件预算、错误预算计算、仪表盘建议、告警规则与缓解 playbook，并会标注样本量与测量窗口假设。

适用边界与注意点

• 它给出的是规划与拆分方法，不是监控平台的替代品；仍需真实请求数据来验证每个阶段的实际耗时。
• 样本量与测量窗口会影响百分位稳定性，短窗口下的 P99 容易噪声偏大，需要结合业务时段与流量波动评估。
• 组件预算依赖对现有链路的可观测性，如果某段尚无法单独计时，应先补埋点再设目标。
• 工具数量、输入输出大小等变量会显著影响延迟，跨 segment 的目标需要分开设定，避免用一套阈值套所有请求类型。