LLM 推理中 KV Cache 大小如何计算，哪些参数决定显存占用？｜蚂蚁集团 C/C++面经解析

60 秒回答模板

KV Cache 是自回归推理中为每一层保存历史 token 的 Key 和 Value，避免每生成一个新 token 都重新计算完整历史。核心公式可以写成 KV_bytes = batch_or_beam * cache_tokens * num_layers * 2 * num_kv_heads * head_dim * bytes_per_elem。这里的 2 是 K 和 V 两份缓存，cache_tokens 是 prompt token 加已经生成的 token，num_kv_heads 在普通 MHA 中通常等于 attention heads，在 GQA/MQA 中会小得多，head_dim 通常是 hidden_size / num_attention_heads，bytes_per_elem 由 FP16/BF16/FP8/INT8 等缓存精度决定。举例，32 层、32 个 KV head、head_dim 128、4096 token、BF16、batch 1 的 KV 大小约 2 GiB；如果是 8 个 KV head 的 GQA，约降到四分之一。实际部署还要乘并发请求、beam size 或 best-of，考虑 paged attention block、padding、对齐、碎片和 allocator 预留。多卡场景下每卡是否除以 tensor parallel 取决于 KV head 或 hidden 维度是否分片；如果某些实现复制 KV，就不能简单除。最后要强调 KV Cache 随上下文长度和并发线性增长，是长上下文服务显存瓶颈之一。

考点 核心公式

难度 真实面经题

回答目标 用公式快速估算 KV Cache，并把模型结构、推理配置和工程实现对显存的影响讲清楚。

深入解析

KV Cache 存的是什么

Transformer decode 时，新 token 的 Query 需要和所有历史 token 的 Key 做注意力，再用历史 Value 加权得到上下文。如果不缓存，每步都要重新计算历史 K/V。KV Cache 把每层历史 token 的 K 和 V 保存下来，decode 阶段只计算新 token 的 K/V 并追加。

核心公式要写出

估算公式是 batch_or_beam * cache_tokens * num_layers * 2 * num_kv_heads * head_dim * bytes_per_elem。它本质上是在数每一层、每个 token、每个 KV head、每个 head 维度上分别存一份 K 和一份 V。

区分 MHA 和 GQA

普通 multi-head attention 中，KV head 数通常等于 attention head 数。GQA 会让多组 Query head 共享较少的 KV head，MQA 甚至可能只有很少 KV head。KV Cache 显存跟 num_kv_heads 线性相关，所以 GQA/MQA 对长上下文推理显存很关键。

上下文和并发线性放大

cache_tokens 包括 prompt 长度和已经生成的 token 数。生成越长、最大上下文越大、batch 或在线并发越高，KV Cache 就越大。服务端如果按 max batch 和 max seq 预留缓存，实际可承载并发往往先被 KV 显存限制。

数据类型决定字节数

BF16/FP16 通常是 2 字节，FP32 是 4 字节，FP8/INT8 是 1 字节，INT4 理论上更低但实现会有打包和 scale 元数据。KV cache quantization 能降显存，但会影响注意力精度、长上下文稳定性和 kernel 复杂度，需要单独评估。

多卡和工程开销

tensor parallel 下 KV 可能按 KV head 或 hidden 维度分到不同 GPU，每卡 KV 近似除以 TP；但如果实现复制 KV、做特殊并行或跨卡 attention，不能机械除。paged attention、block table、padding、对齐、碎片、beam 复制和 allocator reserve 也会让实际显存高于公式裸值。

和其他显存分开算

总显存不只有 KV Cache，还包括模型权重、临时激活、workspace、通信 buffer、CUDA graph 或 runtime 预留。权重显存和模型参数量相关，KV Cache 与层数、上下文、并发和 KV head 数相关。面试里把两者分清，才能说明长上下文为什么贵。

易错点

只算模型权重大小，完全漏掉 KV Cache 随上下文和并发增长。
把 attention heads 直接当 KV heads，忽略 GQA/MQA 会减少 KV head 数。
漏掉 K 和 V 两份缓存，公式少乘 2。
只算 prompt 长度，不把已生成 token 纳入 cache_tokens。
默认多卡一定均分 KV，忽略实现可能复制、分片维度不同或有额外通信 buffer。
把理论字节数当实际显存，忽略 paged block、padding、碎片、beam 和 allocator 预留。

面试官追问

为什么 KV Cache 会随生成长度增长？

每生成一个新 token，每一层都会产生这个 token 的 K 和 V，并追加到缓存中。后续 token 都要 attend 到它，所以缓存长度等于 prompt token 加已生成 token。

GQA 为什么能降低 KV Cache？

GQA 让多个 Query head 共享一组 KV head，num_kv_heads 小于 attention heads。公式中 KV 大小和 num_kv_heads 线性相关，所以 KV head 减少会直接降低缓存显存。

beam search 对 KV Cache 有什么影响？

beam 会让同一个请求维护多条生成路径。共享 prompt 阶段可以优化，但生成分叉后通常要为每个 beam 保存不同的 KV，因此近似按 beam 数放大。

KV Cache 量化会带来什么风险？

它能降低缓存显存和带宽，但 K/V 误差会进入注意力分数和上下文加权，长上下文、多轮推理和尖锐注意力分布下更容易出现精度回归，需要按任务和长度切片评估。

为什么不能只用参数量估算推理显存？

参数量只能估权重显存。长上下文和高并发时，KV Cache 可能成为主要显存占用；此外还有激活、workspace、通信和分配器预留。