KV Cache 的显存占用可以用一个公式估算：每个 token 的 KV 字节数 = 2 × 层数 × KV 头数 × 每头维度 × 每个元素的字节数，再乘以序列长度和并发序列数。部署前算一遍，就能知道在给定显卡上能支撑多长的上下文和多少并发。

为什么要算 KV Cache

推理时显存主要分给三部分：模型权重、KV Cache、运行时开销（激活、框架缓冲等）。权重大小相对固定，KV Cache 则随上下文长度 × 并发数线性增长。很多「模型能加载，但一上并发就显存不足」的问题，原因就在这里。

公式拆解

每 token KV 字节 = 2 × L × H_kv × D × B
  2     ：K 和 V 各一份
  L     ：Transformer 层数
  H_kv  ：KV 头数（使用 GQA/MQA 时小于注意力头数）
  D     ：每个头的维度
  B     ：每个元素字节数（FP16/BF16 为 2，FP8/INT8 为 1）

总 KV 显存 ≈ 每 token KV 字节 × 序列长度 × 并发序列数

这些参数都能在模型的配置文件里找到（如 num_hidden_layers、num_key_value_heads、head_dim，或用 hidden_size / num_attention_heads 计算每头维度）。

手算示例（示意配置）

假设一个模型配置为：32 层、8 个 KV 头、每头维度 128、使用 FP16。

每 token = 2 × 32 × 8 × 128 × 2 = 131,072 字节 = 128 KiB
单序列 8,192 token = 128 KiB × 8,192 = 1 GiB
16 个并发序列 × 8,192 token = 16 GiB

如果同样配置不用 GQA（KV 头数等于 32 个注意力头），KV Cache 会是上面的 4 倍。这就是 GQA 对长上下文服务如此重要的原因。

（以上为示意配置的推算，实际模型请代入其配置文件中的参数。）

降低 KV Cache 占用的办法

  1. 选择使用 GQA/MQA 的模型：KV 头数越少，占用越小。
  2. KV Cache 量化：部分推理框架支持把 KV 存为 FP8 等较低精度，占用约减半，需评测质量影响。
  3. 限制最大上下文长度：按业务实际需要设置，而不是直接用模型支持的最大值。
  4. 分页管理：vLLM 等框架用分页方式按需分配 KV 块，减少碎片和预留浪费。
  5. 控制并发与批大小：在吞吐和延迟之间权衡，见下方延伸阅读。
  6. 前缀缓存：多请求共享相同的系统提示时，可复用前缀的 KV。

部署前的估算流程

  1. 从配置文件读出 L、H_kv、D，确定精度 B。
  2. 按业务定最大上下文长度和目标并发。
  3. 计算 KV 总量 + 权重大小 + 预留一部分运行时开销。
  4. 与显卡显存对比，不够就调整上下文、并发、量化方案或增加显卡。
  5. 上线前用真实流量压测验证，以实测为准。

相关阅读