LLM 应用的 SLO 与告警
LLM 应用要定 SLI/SLO,但你不能照搬传统 Web(它的延迟方差大、质量难量化、成本是指标)。本文讲清 LLM 应用的 SLO 怎么定:延迟(p95/首字时间)、可用性(模型 API 失败率)、质量(评测分/bad case 率)、成本(token/请求),以及配套的告警与错误预算。
本文要点
- 主题聚焦：AI、DevOps
- 适合人群：独立开发者、全栈工程师、AI 应用开发者
- 核心价值：快速理解背景、实践路径、常见误区和工程建议
传统 Web 服务的 SLO 套路很成熟:可用性 99.9%、p99 延迟 < 500ms,配上错误预算,基本能跑。LLM 应用直接套这套,会出三个尴尬:
- 延迟方差极大:同一个 prompt,首字时间 300ms 到 8s 都有可能,均值毫无意义,尾部才是真相。
- "成功"是主观的:HTTP 200 但答非所问,比 500 还伤用户体验——可用性指标根本测不出来。
- 成本是头等指标:传统服务成本基本固定,LLM 应用按 token 烧钱,一次滥用就能在几小时里烧掉可观预算,不监控就是失血。
所以 LLM 应用需要一套专属的 SLI/SLO 体系,把延迟、可用性、质量、成本四条线都盯住。
一、四类核心 SLI:延迟、可用性、质量、成本
SLI(Service Level Indicator)是你能测的指标。LLM 应用我建议盯这四类:
| SLI 类别 | 具体指标 | 为什么重要 |
|---|---|---|
| 延迟 | 首 token 时间(TTFT)、总耗时 p95/p99 | LLM 看尾部,首字时间决定"卡没卡"的体感 |
| 可用性 | 模型 API 失败率、限流(429)率、工具调用失败率 | 区分"系统挂了"和"上游限流" |
| 质量 | 评测分(线上采样跑)、用户负反馈率、重试率 | 200 OK 不代表答得对 |
| 成本 | token/请求、token/用户、日均 spend | 防失控烧钱,定位滥用 |
几个反直觉但关键的点:
延迟看首字,不看总时长。 流式输出里,用户对"首字延迟"的体感远敏感于总耗时。TTFT 2s 比"总共 5s 但首字 300ms"难受得多。所以 SLO 要分两档:首字时间 + 总耗时 p95。
可用性要拆开测。 一个笼统的"错误率"会把模型 500、限流 429、工具超时、JSON 解析失败全混在一起。出事了你不知道是供应商挂了还是自己代码挂了。分开打点,才能分开告警、分开追责。
质量 SLI 是最被忽视也最难的。 三个实操抓手:(1) 线上按 1% 采样,用 LLM-as-judge 自动打分,跑出连续质量分;(2) 用户负反馈率(踩踩/重新生成按钮/复制率下降);(3) 重试率——用户反复点重新生成,基本等于"答得不行",这是最便宜的质量信号。
成本必须当一等指标。 不是月底看账单,是按小时盯。token/请求突增 3 倍,要么是 prompt 被改坏了,要么是被刷接口了,两件事都得立刻知道。
二、从 SLI 到 SLO:定一个能承诺的目标
SLO 是你对 SLI 设的目标线。定 SLO 的原则:不是"越完美越好",而是"用户能接受 + 工程能承担"。下面给一组我实操中合理的起步值(按对话式场景):
| 维度 | SLO 目标 | 说明 |
|---|---|---|
| 首 token 时间 p95 | < 2s | 决定"卡不卡"的体感线 |
| 总耗时 p95 | < 8s | 长回答兜底 |
| 模型 API 可用性 | ≥ 99% | 含上游,实事求是 |
| 自身服务可用性 | ≥ 99.5% | 不含供应商故障 |
| 质量评测分 | > 0.85 | 1-5 分制归一化 |
| 用户负反馈率 | < 5% | 重新生成 / 点踩 |
| 成本 | token/请求周环比 < +20% | 防异常飙升 |
两个坑要避:
别承诺 99.99%。 LLM 上游(模型供应商)自己都到不了这个数,你承诺了等于把锅全揽到自己头上。99% 看起来低,但给错误预算留了余地,反而更诚实、更可执行。
质量 SLO 一定要有,哪怕起步粗糙。 很多团队只定延迟和可用性,因为"质量没法测"。但线上跑一个采样 judge、盯一个负反馈率,门槛没你想的那么高。没有质量 SLO,你优化方向就是错的——只盯着把延迟压低,结果答得更糟,白忙。
三、错误预算:SRE 老办法,LLM 新用法
错误预算 = 100% − SLO 目标。可用性 SLO 99%,错误预算就是 1%。
经典玩法:一段时间(比如 30 天)内,只要错误预算没花完,随便发版、上实验功能;预算花光了,暂停一切非紧急发版,优先修问题。
这套搬到 LLM 应用特别合适,因为 LLM 应用改动频繁且风险高(改 prompt、换模型、调温度都可能导致质量滑坡)。具体做法:
- 按 30 天滚动窗口统计"质量分跌破阈值"和"延迟/可用性违约"的请求占比,消耗错误预算。
- 预算 < 20% 时自动告警,提示团队收敛改动。
- 预算耗尽,CI 里拦下新的非 hotfix 发版。
一句实在话:错误预算逼着你承认"线上总会出错",与其假装零故障,不如把容错额度管起来。 这对 LLM 应用尤其重要——它的质量本就是概率性的,不存在"100% 正确"。
四、告警设计:分级,别一惊一乍
告警是 SLO 的执行手段。最忌讳两件事:告警太频繁(大家麻木,pager 变垃圾邮件)、告警没分级(成本异常和系统挂了用同一声叫唤)。建议三档:
P0(立即响应,半夜叫醒):
- 自身服务可用性 5 分钟内 < 95%
- 模型 API 失败率 5 分钟内 > 20%(供应商级故障)
- 日成本比基线高 3 倍且仍在上升(疑似被刷)
P1(工作时间响应):
- 首 token p95 5 分钟内 > 4s(延迟突增)
- 质量评测分 1 小时内 < 0.75(质量下滑)
- 限流率突增(容量问题)
P2(日报/周报里看趋势,不实时叫):
- token/请求缓慢上升(可能是 prompt 悄悄变长)
- 负反馈率周环比 +10%
- 错误预算消耗速度异常
成本告警单列。 LLM 应用的成本曲线不像传统服务平稳,一个 prompt bug 一晚上能烧四位数。给它设"绝对值 + 环比 + 速率"三层阈值:日 spend 超上限、小时环比异常、分钟级 spend 速率超基线——任何一层触发就告警。
告警带上 trace 链接。 延迟告警里直接附上慢请求的 trace 链接,成本告警附上 top user/top endpoint。告警的目的不是"通知有人哭了",是"让人一打开就能开始查"。
五、监控栈:trace + metric + 评测 + 成本看板
落地这四件事,你需要一套组合拳:
- Trace 层:Langfuse / LangSmith,串起每条请求的模型调用、工具调用,既调试也作质量采样的数据源。
- Metric 层:把上面的 SLI 全部打成时间序列,接 Prometheus / Datadog / 自建看板。p95 用直方图,别用平均值。
- 定时评测:CI 和线上都跑评测集。线上每小时抽一批真实请求打分,输出连续的质量 SLI 曲线。
- 成本看板:按用户 / 功能 / 模型维度拆 token 和 spend,实时刷新。
一个常被忽略的细节:把 trace、metric、eval 用同一个请求 ID 串起来。 出问题时从告警跳到 trace,从 trace 跳到这条请求的评测分,一气呵成。三个系统各自孤立,排查就要在多个 tab 间来回跳,效率差一个数量级。
六、供应商故障:你的 SLO 里住着别人
LLM 应用最特殊的一点:你的可用性,被模型供应商绑架。OpenAI 抽风、Anthropic 限流,你的用户照样骂你。
应对策略:
- 拆分责任。自身 SLO(99.5%)和端到端 SLO(99%,含供应商)分开报。复盘时区分"我方故障"和"上游故障",别把供应商的锅算自己头上,也别反之。
- 多供应商兜底。关键链路接两个模型供应商,主挂切备。注意:备用模型的质量未必一致,切换前要在评测集上验过。
- 供应商侧指标单独盯。每个供应商的失败率、延迟、限流率分开打点,出问题时一眼定位是哪家。这数据还能在谈商务合同时当筹码。
金句:"你的 SLO 上限,是被供应商定义的。" 承认这一点,才能在它之上做真实的风险管理——而不是对用户承诺一个你自己都到不了的数字。
小结
- 四类 SLI 缺一不可:延迟(看首字 + 尾部)、可用性(拆分测)、质量(采样 judge + 负反馈)、成本(实时盯)。只盯延迟和可用性,等于闭着眼开车。
- SLO 要诚实,别承诺 99.99%:99% 留出错误预算,反而更可执行;质量 SLO 必须有,哪怕粗糙。
- 错误预算管改动:预算耗尽暂停发版,用 SRE 老办法约束 LLM 频繁且高风险的改动。
- 告警分三级:P0 叫醒、P1 工作时间、P2 趋势日报;成本告警单独三层阈值,防一夜烧光。
- 供应商是 SLO 的天花板:拆分自身和端到端可用性,多供应商兜底,别对用户承诺自己到不了的数。
一句话收尾:LLM 应用的 SLO,不是为了凑几个漂亮数字给老板看,是为了在"延迟、质量、成本"这个不可能三角里,给团队一条可执行的底线。 定不出完美 SLO 没关系,先粗糙地定、持续地测、果断地改——这件事开始做,就比 90% 的 AI 应用强了。
Related