SLO 与容量规划

推理服务的两个核心问题：承诺什么（SLO：延迟与可用性的量化目标）与需要多少资源（容量规划：满足 SLO 要多少卡）。两者是一枚硬币的两面——SLO 定了，容量就是数学题；SLO 含糊，容量就是玄学。本章给一套从 SLO 到容量的完整方法。

SLO：承诺的量化

推理服务的 SLO 由三个延迟指标 + 可用性组成（见连续批处理的指标定义）：

三条设计原则：

一、用 P99 而不是均值：用户体验由长尾决定——"平均 200ms、P99 5s"的服务用户感知是慢。SLO 写 P99（甚至 P99.9），监控画分布。

二、TTFT 与 TPOT 分开承诺：prefill（排队+大计算）与 decode（步进）的瓶颈不同（见分离部署），分开 SLO 才能分别优化。

三、SLO 是分级的：不同产品/客户不同级（免费用户 P99 2s、付费 P99 500ms），调度器按级配优先级（见多租户）。

第一步：单卡容量基线。测出单卡（或单副本）在 SLO 约束下的容量：

\text{单副本容量} = \text{SLO 约束下的最大并发} \times \text{平均 token 速率}

70B 模型、单卡 TP=1（装不下，TP=2），SLO（TPOT P99 < 100ms）下的并发上限由两个约束取小：

约束	上限
KV cache（显存）	KV 池 ÷ 每 token KV ÷ 平均序列（见 KV）
decode 速度（带宽）	batch 越大 TPOT 越高（每步的计算+通信时间随 batch 涨）

第二步：流量预测。服务要处理的 QPS 与每请求的 token 分布（输入/输出长度的分布，不只是均值）。

第三步：排队论的最后一步。到达率 λ、服务率 μ（单副本容量），利用率 ρ = λ/μ 的经验法则：

利用率 0.85 是推理服务的红线——排队延迟随利用率指数增长，容量规划永远要留 15–20% 的余量。这与调度集群的利用率目标（gang+backfill 到 85%）恰好相反：批处理集群往满压，在线服务往松留。

第四步：故障余量。N+1 或 N+2：一个副本挂了（发布/故障），剩下的还要扛住流量——可用性 SLO 直接加到容量上。

问题：70B 模型对话服务，QPS 10、平均输入 2k token、输出 500 token、SLO（TTFT P99<2s，TPOT P99<100ms，可用性 99.9%）。

单副本容量：TP=4（KV 与速度双约束平衡），KV 池 ~40 GB → 并发 ~32；SLO 约束下实测最大并发 24，每请求平均 375 tokens/s（500 token ÷ 1.3s）→ 单副本吞吐 ~24 × 1.3 = ~31 req/s？不对——并发 24 × 每请求 500 token ÷ (500 × TPOT 50ms) —— 实测单副本稳定服务 ~8 req/s。
流量：QPS 10 → ρ = 10/8 = 1.25 > 1，一个副本不够。
副本数：至少 2（ρ=0.63）；加故障余量 N+1 → 3 个副本（12 卡）。
验证：峰值（QPS 波动 2×）时 ρ = 20/16 = 0.83，接近红线 → 4 副本（16 卡）。

每一步都是数字，没有玄学——SLO 定了，容量就是流量 ÷ 单副本容量 × 余量系数。