容量与成本¶
容量规划的起点是工作负载分布与 SLO，而不是“平均一张 GPU 能跑多少请求”。对 LLM 服务，输入/输出 token、到达模式和延迟目标都会改变可承载能力。
推理容量模型¶
一个便于沟通的第一版估算：
\[ GPU_{needed} \approx \frac{Peak\ Token\ Rate}{Sustainable\ Goodput\ per\ GPU}\times Headroom \]
但需要分别考虑输入和输出 token，因为 prefill 与 decode 的成本不同：
\[ Work \approx \lambda \times (E[T_{in}]\cdot C_{prefill}+E[T_{out}]\cdot C_{decode}) \]
这只是估算框架；可持续 goodput 必须在目标请求长度分布、并发和 SLO 下压测获得。
并发与 Little's Law¶
稳定系统中可用 Little's Law 建立直觉：
\[ Concurrency \approx Arrival\ Rate \times Average\ Latency \]
如果到达率继续提高而吞吐已饱和，排队让 latency 增长，并发/内存占用继续扩大，形成过载。需要 admission control，不能期待无限排队自然恢复。
显存预算¶
推理显存近似分为：
\[ M_{GPU} \approx M_{weights}+M_{KV}+M_{runtime}+M_{workspace}+M_{fragmentation}+M_{margin} \]
容量评审要记录：模型版本、量化/精度、最大序列、并发、KV block 配置、CUDA Graph/编译缓存和安全余量。不要把启动时空闲显存全部承诺给 KV Cache。
峰值不是平均值乘系数¶
至少从历史流量提取：
- 分钟级/秒级峰值与 burst duration；
- input/output token 分布及相关性；
- 模型、租户、地区和时间段结构；
- 取消、超时、重试造成的额外负载；
- 发布、节点故障时的 N-1 / N-k 容量。
用 trace replay 或合成分布复现峰值，比固定 prompt/固定并发更可信。
Headroom 的组成¶
余量不是拍脑袋的统一 30%，应拆成：
- 故障余量：一个副本/节点/机架退出后仍满足 SLO。
- 扩容滞后余量：覆盖节点供给、镜像与模型加载、warmup。
- 预测误差余量：流量和请求形状的不确定性。
- 发布余量：滚动升级、canary、双版本共存。
- 性能抖动余量：邻居、温度、存储与网络尾延迟。
训练集群容量¶
训练容量除了 GPU 小时，还要考虑：
- 任务队列等待与 gang size 导致的碎片；
- 模型并行拓扑对节点整组分配的限制；
- checkpoint/数据 I/O 的共享瓶颈；
- 失败重算、维护与保留容量；
- 开发型小任务与长时大任务的调度公平性。
集群 GPU allocation 高不代表产出高。建议同时看 allocated、active、effective training time、queue time 和 useful tokens/s。
成本单位¶
推理：
\[ Cost_{1M\ tokens}=\frac{GPU\ Cost+CPU+Network+Storage+Platform}{Delivered\ Tokens}\times 10^6 \]
训练可以看每百万/十亿训练 token、每个成功实验或达到目标质量的总成本。仅比较 GPU 小时会忽略失败、重试、数据准备和低效排队。
容量评审模板¶
| 项目 | 内容 |
|---|---|
| SLO | TTFT/TPOT/E2E、可用性、训练 deadline |
| Workload | 模型、精度、token/batch/sequence 分布 |
| Baseline | 版本、硬件、拓扑与实测 goodput |
| Peak | 峰值到达率、持续时间、增长预测 |
| Failure | N-1/N-k、区域/节点/副本故障假设 |
| Lag | 扩容与预热端到端时间 |
| Headroom | 分项余量与计算依据 |
| Validation | 压测、故障演练与观测链接 |
决策原则¶
- 在 SLO 内比较 goodput 和成本，而不是脱离延迟谈峰值吞吐。
- 先通过调度、缓存、batch 和请求限制提升利用率，再决定加卡。
- 过度整合提高利用率但放大故障域与邻居干扰；关键在线服务保留明确余量。
- 定期用生产流量重放更新 baseline，模型与引擎升级后旧容量结论失效。