推理服务的 SLA 工程：SLO、错误预算与容量规划

SLA 的定义：推理服务的特有指标

推理服务的 SLA 不能照搬 Web 服务的指标——它的延迟结构与「文本生成」的形态绑定。核心指标的三个。TTFT（Time To First Token）：首 token 延迟——用户感知的「开始响应」（聊天的体验核心，本库流式篇）。TPOT（Time Per Output Token）：每 token 的生成时间——打字机的流畅度（TPOT 的倒数即生成速度 tok/s）。端到端延迟：完整回答的总时长。三个指标的分位数口径：SLA 承诺的必须是 P99（99% 的请求达标）而非均值——长尾才是体验杀手（均值 500ms 的服务 P99 可能 5 秒）。可用性的定义也要精确：「服务可用」= 能建立连接 + 能返回有效响应——生成中途的错误算不算（本库流式篇的流内错误）——SLA 的口径要把这类边缘情况写清楚。SLA 的分层承诺：不同等级的客户不同承诺（企业客户 P99 2s/99.9%，普通用户尽力而为——分层是 SLA 工程的常态）。

SLO 与错误预算：承诺的运营机制

SLO（Service Level Objective）是内部设定的目标（比对外 SLA 稍紧——留出缓冲），错误预算（error budget）是 SLO 的运营化：99.9% 的可用性 SLO = 每月 43 分钟的错误预算——预算内的故障是「预期内的」，预算耗尽 = 停止新功能发布、全力修复可靠性（Google SRE 的经典纪律——错误预算把「可靠性与迭代速度」的矛盾变成了可计算的决策）。推理服务的错误预算特点：预算的消耗更频繁（模型迭代每周、流量尖峰每日——每个变更都消耗预算）、预算的分层（TTFT 的预算、TPOT 的预算、可用性的预算分别记账——每个 SLO 独立的预算）。错误预算的运营节奏：每周的 SLO 复盘（预算的消耗 rate、消耗的原因分析）、预算耗尽的处置流程（冻结变更 → 排查根因 → 修复 → 预算恢复）。SLO 工程的元意义：SLO 把「服务好不好」从主观感受变成可度量的目标，错误预算把「要不要放慢迭代」变成数据驱动的决策——SLA 不是给客户看的纸，是自己给自己上的枷锁与标尺。

容量规划的三步法：从流量预测到资源配置

容量规划回答「要多少卡才能满足 SLO」，三步法。第一步：流量画像。流量的结构化特征：QPS 的日曲线与周曲线（峰谷比）、请求的 token 构成（输入长度的分布、输出长度的分布——prefill 与 decode 的比例决定负载形态，本库弹性伸缩篇）、以及并发的真实含义（同时在线的会话数 × 每会话的请求频率）。第二步：单副本容量的测定。单副本能扛多少：压测（本库压测篇）测出「满足 SLO 前提下的最大并发」——SLO 约束下的容量（不满足 TTFT P99 的并发不算有效容量）、显存的容量上限（KV Cache 的并发容量，本库 KV Cache 篇）。第三步：资源核算与余量。副本数 = 峰值并发 ÷ 单副本有效并发 × 冗余系数（冗余 30% 应对突发——本库弹性伸缩篇的余量纪律）+ 尖峰的专项预案（活动流量的扩容预案）。容量规划的反直觉点：GPU 利用率不是越高越好——利用率 95% 的推理服务 P99 已经爆炸（队列理论的规律：接近容量的系统延迟非线性飙升）——留余量不是浪费，是 P99 的必要条件（利用率 70–80% 是延迟友好区）。

实践的补充：容量规划之外的三个工程杠杆

容量不够时的三个杠杆（扩容之外）。杠杆一：优化单副本容量。推理的优化（批处理的效率、KV 的量化——同样的卡多扛 20% 的并发等于省 20% 的卡，本库 vLLM 篇）。杠杆二：请求侧的减负。prompt 的瘦身（上下文的精简——输入 token 减半 = prefill 减半）、输出的长度约束（输出 token 是成本的数倍）、以及缓存（前缀缓存消重复——本库 Prefix Caching 篇）。杠杆三：SLO 的重新协商。有些「SLO 紧张」其实是「SLO 定得过紧」——与业务方重新校准（P99 2s 的承诺是业务真的需要，还是拍脑袋？——SLO 的定义本身就是容量规划的一部分：更宽的 SLO = 更少的卡）。SLA 工程的收束：SLA 工程的本质是「承诺的科学与运营」——SLO 定义你要什么、错误预算管理你要多快、容量规划算你要多少资源；三者闭环，推理服务才从「尽力而为」变成「可承诺的服务」。

推理 SLA 的实战：一次 SLO 事故的复盘

推理 SLA（正文错误预算）的实战：一次 SLO 事故的复盘——用真实形态的案例走一遍错误预算的运营。事故的形态：某推理服务的 TTFT P99 SLO（2 秒）连续三天超标（P99 达 4–6 秒）。复盘的四步。第一步：定位消耗源——SLO 仪表盘的归因（TTFT 超标的请求画像：集中在长 prompt 的请求——某新功能上线导致 prompt 从 2K 涨到 20K）。第二步：根因的分析——长 prompt 的 prefill 风暴（prefill 时间与长度线性相关——新功能的上下文膨胀是根因，本库弹性伸缩篇的长 prompt 杀手）。第三步：处置的组合——短期：长 prompt 的限流与分池（长请求隔离池）；中期：prompt 的瘦身（新功能的上下文精简）；错误的预算决策：本月错误预算已耗尽 → 新功能发布冻结（本库正文的预算纪律的执行）。第四步：预防的机制——prompt 长度的监控告警（新功能上线自动加 prompt 长度的检查）、灰度期的 TTFT 评测（新功能灰度时就测 TTFT——不要等上生产）。复盘的元教训：这次事故的根因不是「容量不够」，是「一个产品决策（加长上下文）没有经过 SLO 影响的评估」——SLO 工程的最后一环，是把 SLO 的影响评估嵌入产品的决策流程：任何影响流量形态的新功能，上线前要回答「它对 TTFT/吞吐/成本的影响是什么」。**

SLA 的分层与商业化：推理服务的分级承诺

推理 SLA（正文分层）的商业化：分级承诺的产品化——SLA 不只是技术，是产品设计。分级的维度。等级的划分：免费层（尽力而为、无承诺）、标准层（P99 TTFT 5s/99.5%）、企业层（P99 2s/99.9% + 专属容量 + 优先支持）、旗舰层（专属集群 + 定制 SLO）——分级的背后是资源的物理隔离（企业层的专属副本、旗舰的专属集群——本库多租户篇的物理隔离）。分级的定价逻辑：SLA 的每一级都对应成本（专属容量的闲置成本、优先调度的公平性代价——SLA 等级的定价要覆盖它的资源成本）。SLA 的违约处置：SLA 未达的补偿机制（服务积分、退款——违约的补偿条款是 SLA 的牙齿）、豁免的条款（不可抗力、客户侧问题的豁免——豁免条款防止滥用）。SLA 产品化的收束：推理服务的 SLA 分级，本质是「用资源的物理隔离兑现商业的承诺」——免费的尽力而为、付费的严格保障——SLA 的每个数字背后都必须有对应的资源与流程支撑；没有资源支撑的 SLA 承诺，是负债不是资产。

推理 SLA 的进阶：SLO 的自动调参与自适应

推理 SLA（正文）的进阶：SLO 的自动调参——SLO 的自动调整与自适应。SLO 为什么要自动调。流量与模型的演进（流量的增长、模型能力的提升、业务的优先级变化——固定的 SLO 会逐渐偏离现实）、人工调参的滞后（SLO 的调整靠人工评审——滞后于变化）。自动调参的方向。方向一：基于错误预算的自动调整——预算充裕时自动收紧 SLO（尝试更激进的性能目标）、预算紧张时自动放宽（错误预算的自动化管理——SRE 的进阶实践）。方向二：基于流量的自适应——低峰期自动收紧 SLO（资源有富余）、高峰期自动放宽（容量的弹性与 SLO 的弹性联动——本库弹性伸缩篇的 SLO 版）。方向三：基于用户反馈的校准——用户满意度数据反哺 SLO 的校准（用户不满意的 P99 阈值 = SLO 需要收紧）。自动调参的边界：自动调整的范围要有限制（不能自动把 SLO 调到不合理的水平——自动化的边界由人工定义）、以及调整的透明性（SLO 的自动调整要记录与通知——黑盒的 SLO 自动调整是信任的杀手）。自动调参的收束：SLO 的自动调参是「SLA 工程的最高形态」——它让服务质量的目标本身变成一个自适应系统；但要记住：自动化的目的是减少人工的延迟，不是移除人工的判断。

推理 SLA 的实践清单：SLO 落地的检查项

推理 SLA 的实践清单：SLO 落地的检查项——每项都对应一个工程动作。检查项一览。① SLO 的定义文档（TTFT/TPOT/可用性的目标值与口径——有文档的 SLO 才是可执行的）。② 监控的覆盖（SLO 对应的指标已接入监控——没有监控的 SLO 是空头支票）。③ 错误预算的配置（预算的数值与消耗跟踪——预算的运营机制已建立）。④ 容量的规划（满足 SLO 的资源配置已核算——本库正文的三步法）。⑤ 降级的预案（SLO 濒临违反时的降级路径——预案已文档化且演练过）。⑥ 复盘的机制（SLO 违约的复盘流程——每次违约都走 postmortem）。检查项的用法：新服务上线前逐项打勾、存量服务定期复查——六项全过的推理服务才有资格向用户做出 SLA 承诺；六项缺三以上的，SLA 承诺等于自我欺骗。

小结

推理服务的 SLA 三指标（TTFT/TPOT/端到端）必须以 P99 口径承诺，可用性的边缘情况要写清。SLO 与错误预算把可靠性与迭代速度的矛盾变成可计算决策（预算耗尽即冻结变更）。容量规划三步法（流量画像 → SLO 约束下的单副本压测 → 副本核算加冗余），并记住反直觉点：GPU 利用率 95% 的服务 P99 已爆炸——留 20–30% 余量是 P99 的必要条件。容量不够时先动三个杠杆（单副本优化、请求减负、SLO 重议），最后才是买卡。