上线前的 OOM 检查表
上线前把显存的账逐项列出来：权重（按精度与切分折减）、KV（按 P95 长度乘目标并发）、工作区预留、同卡其它进程占用、加载阶段的主机内存与磁盘、以及启动日志里报告的 KV 容量。列完再压测到目标并发，两道关都过才上线。
基本信息
| 权重 | 精度乘参数量，多卡按切分折减 |
|---|---|
| KV | P95 长度乘目标并发 |
| 工作区 | 按比例预留 |
| 同卡进程 | 监控与其它服务的占用 |
| 核对 | 启动日志里的 KV 容量 |
典型使用场景
- 新模型上线前的容量评审
- 扩容方案提交前的自检
- 排查「压测正常、上线就 OOM」
- 交接时作为标准化清单复用
- 把检查表与启动日志一起归档，形成可回溯的发布记录
- 把每次 OOM 的触发条件补进检查表
检查表
检查表
# □ 权重：精度 × 参数量，多卡按切分折减
# □ KV：P95 长度 × 目标并发
# □ 工作区：按比例预留
# □ 同卡进程与监控占用
# □ 启动日志的 KV 容量 vs 自己的估算值容易漏的三处
| 项目 | 容易漏的点 | 后果 |
|---|---|---|
| 权重 | 精度转换缓冲 | 加载阶段就失败 |
| KV | 长尾请求长度 | 压测通过后仍然 OOM |
| 工作区 | 大 batch 抬升峰值 | 只在特定配置复现 |
检查表走完还要压测到目标并发：静态估算与动态表现常有差距，两道关都过才上线。
启动日志里的 KV 容量是现成的现实校准：与自己的估算对照，偏差大就说明前面某一步的假设出了问题，先回头查它。
把上一次 OOM 的原因补进检查表：同类问题重复出现的概率最高，检查表应该随时间变厚。
检查表要留档或有人确认：走过场式的检查在真实压力下通常不会被执行。
把估算过程留痕：复盘时能看出偏差出在哪一步，而不是只留下一个结论。