KV cache 为什么随上下文和并发增长?
把缓存容量写成可检查的 MiB 算式。
内容修订 4 · 2026-10-24
I01 · 修订 1 · 2026-10-21
- 每个 token:K + V
- × 层数 × KV 头
- × 历史长度 × 请求数
问题从哪里来
自回归解码不断读取历史 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 公式直接套作其精确容量。
原始来源
- Fast Transformer Decoding: One Write-Head is All You Need · 2019-11-05 · 核对 2026-10-21
- GQA: Training Generalized Multi-Query Transformer Models · 2023-05-22 · 核对 2026-10-21
启用脚本后可使用手动本地阅读记录和交互计算器。
继续追问
I02 · MQA、GQA 和 MLA 分别怎样减少 KV?