大模型服务 SLA 应该看哪些指标？
简化版
大模型 SLA 不能只写“接口可用率 99.9%”。流式生成至少要覆盖：可用性、TTFT、TPOT/每秒输出 Token、端到端完成时间、成功率、质量与安全，以及按租户和长度分桶后的 P95/P99。
SLA 是对客户的承诺，内部应以更严格的 SLO 管理，并用错误预算约束发布。例如月度可用性 99.9% 约允许 43.2 分钟不可用；但“返回 200 却没有有效答案”也应按业务定义计入失败。指标必须写清统计窗口、分母、排除项和测量位置。
详细版
LLM 请求通常分为排队、Prefill、Decode 和流式传输。TTFT 衡量用户多久看到首 Token，TPOT 衡量后续输出流畅度，端到端时间受输出长度影响，三者不能互相替代。
| 维度 | 典型指标 | 防止的问题 |
|---|---|---|
| 可用性 | 成功请求占比 | 5xx、超时、拒绝失控 |
| 交互延迟 | TTFT P95/P99 | 首次响应太慢 |
| 生成速度 | TPOT P95、Tokens/s | 流式卡顿 |
| 质量安全 | 任务成功率、违规率 | 快速返回错误答案 |
| 容量成本 | 拒绝率、单位成功成本 | 过载与预算失控 |
SLO 应按模型、租户、区域、输入长度和优先级分桶，并绑定告警、错误预算、灰度与回滚。平均延迟、仅服务端耗时或单一 HTTP 状态码都不足以代表用户体验。
完整版教学
1. SLA、SLO、SLI 分别是什么
SLI 是实际测量指标，如“成功请求比例”；SLO 是团队内部目标，如“30 天窗口内成功率 ≥ 99.95%”；SLA 是对外合同承诺及违约处理，通常比内部 SLO 宽松。
SLI: how measured
SLO: internal target
SLA: external promise + consequence面试时把三者混用，会导致监控指标和客户承诺边界不清。
2. 可用性分母如何定义
最简单定义为成功请求数除以有效请求总数，但关键在“成功”和“有效”。服务端 5xx、超时、模型加载失败通常计失败；客户端参数非法可排除；容量不足返回的 429 是否计入，要按产品承诺明确。
availability = good_events / valid_events返回 HTTP 200 但流中途断开、JSON 无法解析或生成空内容，也不能算好事件。
3. TTFT 衡量什么
Time To First Token 从服务边界收到有效请求开始，到客户端收到首个有效 Token。它包含排队、Prefill、首步 Decode 和网络传输。
只在 GPU 内测 Prefill 会漏掉队列与网关。应明确测量点，并按 Prompt 长度分桶，否则长上下文会把短聊天的体验混在一起。
4. TPOT 与生成速度怎么用
TPOT 是首 Token 之后相邻输出 Token 的平均间隔，近似反映流式生成速度：
TPOT = (last_token_time - first_token_time) / max(output_tokens - 1, 1)
tokens_per_second ≈ 1000 / TPOT_ms平均 TPOT 可能掩盖瞬时停顿，可额外监控最大 Token 间隔或间隔 P99，捕捉用户看到的“卡住”。
5. 端到端延迟为何要按长度解释
完整响应时间随输出 Token 数增长。两个请求模型速度相同，一个输出 20 Token、另一个输出 1000 Token，完成时间自然不同。
因此端到端 SLO 可以按任务类型或输出长度分桶，也可对固定输出预算的 API 直接承诺。流式聊天更适合将 TTFT 和 TPOT作为核心体验指标。
6. P95/P99 为什么比平均值重要
平均值会被大量短请求稀释，无法反映过载、长尾和区域故障。SLO 通常以分位数描述大多数用户能获得的体验。
但分位数也要有足够样本，低流量租户可采用更长窗口或好事件比例。全局 P99 达标不代表每个区域和租户达标。
7. 错误预算怎样计算
若 30 天可用性目标为 99.9%，不可用比例为 0.1%：
30 × 24 × 60 × 0.001 = 43.2 minutes错误预算消耗过快时，应冻结高风险发布、优先可靠性工作。预算不是允许主动制造故障，而是平衡迭代速度与稳定性。
8. 质量为什么也要进入服务目标
LLM 可以稳定、快速地返回事实错误或格式错误。业务 SLO 应包含任务成功率、Schema 合法率、引用正确率或人工升级率等质量指标。
质量评测比基础设施指标慢，可用线上规则与抽样评审结合。安全违规率通常设置独立红线，不能被平均质量分抵消。
9. 限流和拒绝如何计数
主动准入拒绝能保护系统，但对购买固定容量的客户可能属于未履约。应区分客户超配额、服务端容量不足和安全策略拒绝。
| 结果 | 示例 | 是否计入可用性失败 |
|---|---|---|
| 客户超合同配额 | 规范 429 | 通常不计，但需明确 |
| 服务容量不足 | 内部过载 429 | 通常计入 |
| 非法请求 | 400 | 通常不计 |
| 流中途断开 | 部分输出后失败 | 通常计入 |
最终口径必须写进 SLA，而不是事故后临时解释。
10. 如何按维度分桶
至少按模型版本、区域、租户等级、请求类型、Prompt 长度和流式/非流式拆分。聚合指标可能出现辛普森悖论：总体改善，但关键高价值流量恶化。
分桶不能无限增加，否则告警噪声和高基数成本失控。选择能对应责任边界和调度策略的维度。
11. 多窗口告警如何减少噪声
单个 5 分钟窗口容易因瞬时波动误报，月度窗口又发现太慢。可同时用短窗口高燃烧率与长窗口中燃烧率判断错误预算消耗。
告警应指向可行动问题，并附带模型、区域、长度桶和最近发布信息。仅报告“P99 高了”而无分解数据，值班人员难以定位。
12. 容量与成本指标的角色
队列 Token、KV 使用率、GPU 饱和、拒绝率是导致 SLO 违约的先行指标；单位成功请求成本与资源效率是经营指标。它们通常不直接写入对外 SLA，却用于提前干预。
成本下降若来自截断输出或路由到质量不足的小模型，可能同时伤害质量 SLO，因此性能、质量和成本要关联观察。
13. 发布怎样绑定 SLO
新模型、量化、Prompt、推理引擎和调度参数都可能影响 SLI。发布前跑离线质量与性能基线，灰度时比较同流量对照，并设置自动回滚阈值。
回滚条件应覆盖可用性、TTFT、TPOT、质量与安全。只看 5xx 会漏掉模型版本导致的慢化或回答退化。
14. 一套可执行的示例
例如交互式助手可定义：30 天可用性 ≥99.9%；输入 ≤4K Token 时 TTFT P95 ≤1.5s、P99 ≤3s；TPOT P95 ≤80ms；结构化任务 Schema 成功率 ≥99.5%；安全违规率低于独立阈值。
这些数字只是示例，真实阈值应由用户研究、模型能力和容量压测确定。每项还需注明区域、模型、统计窗口与排除规则。
好的 SLA 不只说明系统“在线”，还清楚定义用户何时算真正获得了一次可用结果。
15. 常见误区与追问
- 误区：HTTP 200 就算成功。 流中断、空答案和格式错误也可能是失败。
- 误区：平均延迟足以代表体验。 尾延迟才暴露过载和长尾问题。
- 误区：TTFT 就是模型 Prefill 时间。 它还包含排队、首步 Decode 和网络。
- 误区：可用性高就代表模型服务好。 质量和安全必须有独立指标。
- 误区：全球聚合达标即可。 区域、租户或长度桶可能已经违约。
- 追问：429 是否算失败？ 取决于配额与合同口径，服务端容量不足通常应计入。
- 追问：错误预算有什么用？ 用统一额度约束发布风险并决定可靠性投入优先级。
16. 加强记忆
- 先分概念：SLI 测量，SLO 内部目标，SLA 对外承诺。
- 再看可用：成功分母、流中断、429 口径要明确。
- 再看体验：TTFT 首响、TPOT 流畅、端到端完成。
- 再看尾部：P95/P99，并按长度、区域、租户分桶。
- 再看结果：任务质量与安全不能被 HTTP 成功替代。
- 再看治理：错误预算、告警、灰度和回滚绑定。
- 最后记原则：指标必须从用户边界测量并能驱动行动。