KV cache 为什么随上下文和并发增长?

把缓存容量写成可检查的 MiB 算式。

内容修订 4 · 2026-10-24

I01 · 修订 1 · 2026-10-21

  1. 每个 token:K + V
  2. × 层数 × KV 头
  3. × 历史长度 × 请求数
本站重绘:载荷乘数示意;下方数值可交互调整。

问题从哪里来

自回归解码不断读取历史 token 的键和值。缓存它们可避免重复投影,但每个请求、每一层都要保留历史状态;更长的输入和输出、更高并发都会推高容量与带宽需求。

关键机制

标准 MHA/MQA/GQA 的理想 KV 载荷为 2×B×L×T×H_kv×d×s 字节,2 对应 K 与 V;B 是等长请求数,L 是层数,T 是每个请求当前缓存长度,H_kv 是 KV 头数,d 是头维度,s 是每元素字节。异长请求用各自 T 求和。

KV_MiB = 2 B L T H_kv d s / 2²⁰

算例与证据

默认教学配置 B=1、L=32、T=4096、H_kv=8、d=128、s=2,得到 512 MiB;8 个这样的请求需要 4096 MiB。下方计算器只计算缓存载荷,不包括权重、激活、工作区、分页碎片、量化元数据与副本。

收益之外的新约束

容量减小不自动等于相同比例提速:decode 可能受带宽、计算或调度限制。MLA 使用不同的压缩表示,不能把这条标准 KV 公式直接套作其精确容量。

原始来源

启用脚本后可使用手动本地阅读记录和交互计算器。

继续追问

I02 · MQA、GQA 和 MLA 分别怎样减少 KV?

S04 · PagedAttention 如何减少 KV 分配浪费?

全部18题