LLM 服务的 SLO 怎么写
给 LLM 服务定 SLO，建议分成三块：可用性（成功请求占比，剔除客户端错误与限流）、延迟（首 token 延迟与每 token 延迟的分位）、队列等待。错误预算按 1 减 SLO 计算，预算耗尽时冻结非必要变更、优先修复稳定性。分位数要用 P95/P99 这类尾部指标，因为体验问题往往藏在长尾里。
基本信息
| 可用性 SLI | 成功响应占比，剔除客户端错误与限流 |
|---|---|
| 延迟 SLI | 首 token 延迟与每 token 延迟的分位值 |
| 排队 SLI | 请求等待时长的分位值 |
| 错误预算 | 1 减去 SLO，作为变更节奏的闸门 |
| 统计口径 | 分位数，不用平均值 |
典型使用场景
- 上线前定指标：先明确承诺什么，再决定容量与告警阈值
- 值班判断：出现异常时对照 SLO 判断影响程度与响应级别
- 变更评审：预算充足时正常发布，预算紧张时收紧改动范围
- 对外承诺：内部 SLO 通常要严于对外 SLA，留出缓冲
- 复盘依据：把一次故障折算成预算消耗，比争论「严重程度」更客观
错误预算与用法
错误预算与用法
错误预算 = 1 - SLO
月度预算耗尽 → 冻结非必要发布，优先修复稳定性
预算充足 → 可按正常节奏发布变更
前提：SLI 的统计口径与剔除规则写清楚，否则结论无法复核SLO 示例（数值按自身基线定）
| 维度 | 指标形态 | 目标示例 |
|---|---|---|
| 可用性 | 成功响应占比（剔除客户端错误与限流） | 按月统计的高可用目标 |
| 首包延迟 | 首 token 延迟分位 | 按业务可接受停顿设定 |
| 解码速度 | 每 token 延迟分位 | 按生成体感设定 |
| 排队 | 等待时长分位 | 按高峰期可接受等待设定 |
分位数先看 P95 与 P99：长尾体验问题藏在尾部，用平均值会把它们抹平，报表与用户体感长期脱节。
剔除规则要写清楚：把客户端错误与主动限流排除在外，否则可用性数字会被无关请求拖低，团队会去优化不该优化的东西。