如何为 LLM 服务定义 SLO、错误预算与过载策略？

面试时怎么答

SLO 应围绕用户感知的正确、及时、可用定义，不能把 HTTP 200 当作成功。先给任务成功率与 TTFT/TPOT 等 SLI，再解释目标窗口、错误预算和 Burn Rate 如何决定冻结发布、限流或降级；高风险任务应单独设更严的语义失败标准。

可以这样答：

LLM 的 SLO 不能只写 99.9% HTTP 成功，而要描述用户任务是否正确、及时并安全完成。说先选 SLI，例如任务成功率、TTFT 和工具执行正确率，再规定统计窗口；错误预算就是允许失败的空间，Burn Rate 过快时冻结发布、限流或降级。但更严 SLO 需要更多冗余和成本。SLO 还应按问答、写操作等风险分级，监控成功率、P95 TTFT/TPOT、语义失败率、预算消耗率、降级请求占比和恢复时间。

核心回答

先从用户体验定义 SLI：请求是否成功、TTFT 是否低于阈值、流式 Token 间隔/TPOT 是否达标，以及关键任务是否满足可测质量门槛。SLO 则规定一个时间窗口内满足 SLI 的请求比例，例如“28 天内 99% 合法请求 TTFT < X 且无服务错误”。

错误预算是窗口内允许的 Bad Events：若 SLO 为 99.9%，预算约为 0.1% 合法事件。预算消耗过快时触发发布冻结、扩容、准入限制或降级，而不是等预算归零才处理。过载策略应优先保护已接纳请求和核心租户，采用有界排队、Token 配额、Admission Control、短上下文/小模型降级和明确的重试提示。

展开说明

用“低于阈值的请求比例”通常比单独一个 P99 更容易计算预算，并能定位哪些请求违约。
TTFT、TPOT 和成功率可分别设 SLO；若合成一个 Good Event，要明确必须同时满足哪些条件。
SLI 的分母应排除明确的无效请求，但不能随意排除超时、限流或内部取消来美化数字。
质量 SLO 只选能稳定、及时测量的关键门槛；主观质量可作为离线或延迟 SLI，不宜伪装成实时精确值。
使用 Burn Rate 同时看短、长窗口，可兼顾快速故障与慢性消耗。

版本边界：Google SRE 方法是通用可靠性框架，并未规定 LLM 的固定 TTFT/TPOT 数值；阈值必须按产品、区域、模型和流量分层，修改定义时保留指标版本。

工程实践

从生产 Trace 选用户可感知阈值，建立 SLI 事件表和预算看板，并让告警直接对应 Runbook。通过逐级加压验证入口限流早于 GPU 队列失控，重试带抖动且有上限；季度复查 SLO 是否过松、不可达或已与用户需求脱节。

常见追问

SLA、SLO 和 SLI 有什么区别？ SLI 是测量值，SLO 是内部目标，SLA 是对外承诺及可能的后果；三者不能把同一个百分比换名字使用。
为什么过载时要尽早拒绝而不是无限排队？ 队列过长会让所有请求都超时并触发重试风暴；快速、有界地拒绝一部分，反而能让已接纳请求保持 SLO。
错误预算耗尽后一定停止所有发布吗？ 通常冻结增加风险的普通变更，但允许直接修复可靠性或安全问题；具体策略应事先约定，而不是事故中临时争论。

一句话复习

LLM SLO 把成功、TTFT、TPOT 和必要质量变成可计数事件，错误预算决定何时限流、降级与冻结风险变更。

参考资料

官方指南：Google SRE Workbook: Implementing SLOs