LLM 推理服务 SRE 实战：SLO、容量规划与降级策略
摘要: 推理服务上线只是开始，"稳定提供服务"是另一回事。本文讲 LLM 推理服务的 SRE 三件套：SLO 怎么定、容量怎么算、过载怎么办。与 12 章部署篇（vLLM/TRT 参数）不同，本篇聚焦服务治理层：指标、告警、容量模型、降级策略。
0. 实验目标
- 定义推理服务的 SLO（首 token 延迟 / 总延迟 / 可用性）
- 建立容量模型：并发、吞吐、KV 显存三者的数学关系
- 设计降级策略：过载时的多级兜底
- 落地告警与容量规划 SOP
1. SLO：先定义"什么算正常"
text
# 示例 SLO（在线对话场景）
- 首 token 延迟（TTFT）P95 < 2s
- 总生成延迟 P95 < 30s（按 max_tokens 折算）
- 可用性：99.5%（月度）
- 错误率（4xx/5xx/超时）< 1%原理讲解：
- SLO 三件套：TTFT（首 token，用户感知的"响应快慢"）、TBT/总延迟（生成速度）、可用性。别只盯可用性——"服务没挂但慢得像挂"才是推理服务最常见的事故。
- 监控指标来自 vLLM/TRT 原生导出（本知识库 vLLM 生产化 篇的 Prometheus 指标表），网关层再加：请求量、错误率、超时率。
- 告警分级：P1（可用性跌破 / 错误率飙升，立即）、P2（TTFT P95 超阈值 5 分钟）、P3（容量水位接近上限）。
2. 容量规划：并发、吞吐、KV 显存的关系
先算账（8B 模型 · 80G 卡 · 8K 上下文示例）：
单卡并发上限 ≈ KV 显存预算 ÷ 单请求 KV 占用
- KV 预算 = 80G × 0.90 - 权重(~16G) ≈ 56G
- 单请求 8K 上下文 KV ≈ 1GB（FP16）→ 并发 ≈ 56
- FP8 KV 减半 → 单请求 0.5GB → 并发 ≈ 112
容量（QPS）≈ 并发 ÷ 平均请求耗时
- 平均耗时 5s、并发 56 → QPS ≈ 11
- 需要 100 QPS → 约 9-10 副本（含冗余）工程启示：
- 容量 = 并发 × 吞吐，不是"显卡数量"：显存决定并发上限，GPU 算力决定单请求速度，两者相乘才是容量。
- 规划公式：
副本数 = 目标QPS × 平均耗时 ÷ 单卡并发 × 冗余系数(1.3)。 - 上下文长度是变量：长上下文请求把并发上限压低（详见 长上下文推理 篇的 KV 账本）——容量规划必须按业务实际上下文分布算，不是按 max-model-len。
3. 过载降级：多级兜底
text
过载信号：排队数 > 阈值 / TTFT P95 超标 / CPU 网关压力
│
├─ 第一级：限流（网关层）——按租户/IP 限流，保护后端不被打穿
├─ 第二级：队列与优先级——长任务降优先级，短任务优先
├─ 第三级：降质兜底——max_tokens 上限下调 / 关闭检索 / 简化 prompt
└─ 第四级：读缓存兜底——热点问题命中缓存直接返回（见下）工程启示：
- 限流是第一道闸：网关层
limit_req按租户配额限流（nginx/网关配置见 vLLM 生产化 篇），别让过载请求堆进推理队列。 - 降质比降级好：把 max_tokens 从 2048 降到 1024、检索从 TOP6 降到 TOP3——用户感知的是"回答短一点"，而不是"服务不可用"。
- 多级缓存：KV 前缀缓存（命中省 prefill）+ 语义缓存（热点问题直接返回历史答案）+ 静态页缓存——三级缓存把真实推理压力降一个量级。
4. 容量规划与扩容 SOP
bash
# 扩容决策（示例）：监控面板触发条件
# 当 排队数 > 50 持续 5min 或 TTFT P95 > 2s 持续 10min
# 执行：网关 upstream 加一台新副本（同参数、同版本）→ /health 通过后加入
# 缩容：利用率持续 < 30% 且无排队 → 摘副本（先摘、后停）
# 告警闭环：Prometheus + Alertmanager → 值班群 → 处理记录归档工程启示：
- SLO 先定义后监控：TTFT/总延迟/可用性三项，分级告警。
- 容量 = 并发 × 吞吐：显存定并发上限，算力定单请求速度。
- 按业务上下文分布算容量，不是 max-model-len。
- 限流是第一道闸：网关层按租户配额，别让请求堆进推理队列。
- 降质优于降级：max_tokens/检索深度下调，比"不可用"体面得多。
- 三级缓存：KV 前缀 + 语义 + 静态，把真实推理压力降一个量级。
- 扩容自动化：指标触发 → 加副本 → 健康检查 → 上线，全流程脚本化。