如何估算大模型推理的显存占用、并发容量和 GPU 数量？

简化版

推理显存 = 模型权重 + 激活/工作区 + KV Cache + 框架预留。并发容量通常受「剩余显存能容纳多少活跃 token 的 KV Cache」限制。GPU 数量不能只按参数量算，要在真实输入/输出长度和到达率下压测 TTFT、TPOT、吞吐和峰值显存，并预留故障和流量余量。核心心法：先算权重放不放得下，再算剩余显存能存多少活跃 token，最后用真实负载验证每副本能在 SLA 内处理多少 token。

详细版

权重显存 ≈ 参数量 × 每参数字节（量化还含 scale、zero point、打包元数据）。

每 token 的 KV Cache 元素数（标准 Decoder）：

每 token KV 元素数 ≈ 2 × 层数 × KV头数 × head_dim
   （系数 2 = K 和 V）
再 × 数据类型字节 × 活跃 token 总数 × 副本数

GQA/MQA 的 KV 头数远少于 Query 头，所以 KV Cache 比标准 MHA 小得多。TP 是否分片 KV、内存对齐、分页尾块都会改变每卡实际值。

完整版教学

一、权重显存：一个 7B 模型的账

权重是第一笔、也是最确定的一笔：

7B 参数模型的权重显存下限：
  FP16/BF16：7e9 × 2 字节 ≈ 14 GB
  INT8：     7e9 × 1 字节 ≈ 7 GB
  4-bit：    7e9 × 0.5 字节 ≈ 3.5 GB

但别按理论值把显存占满：还要加量化元数据（scale/zero point）、未量化的层、内存对齐、以及推理引擎的工作区。多卡 TP 后权重大致分摊到各卡，但每卡仍有通信缓冲等固定开销。

二、KV Cache 容量：并发的真正瓶颈

权重放下后，剩余显存决定能存多少 KV，从而决定并发。算一笔账（假设 32 层、KV 头 8、head_dim 128、BF16）：

每 token KV 字节 = 2 × 32 × 8 × 128 × 2 字节 ≈ 131 KB/token

若剩余显存给 KV 的有 40 GB：
  可容纳总活跃 token ≈ 40 GB / 131 KB ≈ 320,000 token

若平均每个请求上下文 2000 token：
  并发数 ≈ 320,000 / 2000 ≈ 160 个并发请求

关键认知：服务允许的”最大上下文”只是单请求上限，不代表所有并发请求都能同时达到上限。真实并发数要用「可分给 KV 的显存 ÷ 每 token KV 字节」算出总 token 容量，再按真实长度分布换算成并发请求数。这也解释了为什么 GQA/MQA（KV 头少）能大幅提升并发。

三、别忘了第三块：激活与工作区

除了权重和 KV，还有一堆「隐形」显存：

Prefill 激活（长 prompt 时不小）、注意力工作区；
CUDA Graph 捕获、通信 buffer、采样 logits（词表大时 logits 也占地方）；
内存碎片。

这些随 batch 和最大序列配置变化，必须用运行时峰值来校准公式，不能只算权重 + KV 就以为够了——上线常因为这块 OOM。

四、从吞吐估算副本数

容量规划的另一半是「要几个副本」：

若单副本在 SLA 内可稳定输出 R token/s，预计峰值需求 D token/s：
  理论副本数 ≥ ceil(D / R)
  实际副本数 = ceil(D / R) × 安全余量 + 滚动升级/故障/突发余量

易错点：请求 QPS 不能直接当 token 吞吐——要结合平均和尾部输出长度换算。一个 QPS=100 但平均输出 500 token 的服务，实际要 50000 token/s 的产能。

五、排队与过载保护

一个反直觉但关键的点：当到达率长期超过服务率，延迟会因排队无限增长，即使 GPU 利用率已经 100%。GPU 忙不代表没过载——它可能在满负荷处理积压队列，新请求越等越久。

所以必须有过载保护：队列上限、请求超时、最大输入/输出 token、租户配额、负载削峰，并用 P95/P99 SLA 触发扩容（而非等到 GPU 打满才反应）。

六、容量验证：压测才是真相

理论估算只是起点，上线容量必须实测：

用生产的长度分布 + 开放环到达率，先预热再压测；
记录峰值显存、KV 使用率、抢占次数、错误率、TTFT、TPOT、单位 token 成本；
分别测稳态、突发、单节点故障、缓存冷/热场景。

只测稳态、只用短请求，会得出乐观到危险的容量结论。

七、加强记忆

容量规划记「三步走」：① 权重放不放得下（参数×字节，7B FP16≈14GB）；② 剩余显存能存多少活跃 token 的 KV（每 token KV≈2×层数×KV头×head_dim×字节，除一下得总 token 容量，再按长度分布换并发）；③ 用真实负载验证每副本 SLA 内能处理多少 token，副本数≥ceil(D/R)×余量。三个易错点钉死：最大上下文≠所有并发都能拉满、激活/工作区/logits 也吃显存要按运行时峰值校准、GPU 打满≠没过载（到达率超服务率则排队无限增长，需 P99 触发扩容+过载保护）。理论显存只是起点，不是上线容量。

简化版

详细版