KV cache 是本地部署里最容易算漏的一笔开销它不写在模型参数里却随上下文长度线性增长。同样 32K 上下文32 个 KV 头的结构和 8 个 KV 头的结构占用能差 4 倍——17.2GB vs 4.3GB。下面用一份自己跑出来的矩阵把 KV cache 的六个高频问题逐个答清脚本随文给出你可以代入自己模型的层数与 KV 头数重算。一、KV cache权重是定值它却会随上下文涨 32 倍自回归生成时每生成一个 token模型都要回看前面所有 token 的 Key 和 Value。为了不做重复计算推理框架会把它们缓存下来——这就是 KV cache。所以它的规模由两件事决定前面已经有多少 token上下文长度以及每个 token 需要缓存多少字节结构决定的。前者线性增长后者是常数。划重点权重占多少是模型大小决定的KV cache 占多少是你怎么用它决定的。同一台机器跑同一个模型开 4K 上下文和开 128K 上下文KV cache 能差 32 倍——这也是为什么模型能装下和服务能跑起来是两件事。能不能开长上下文只取决于三个数KV 头数、上下文长度、并发数。这三个数一旦确定KV 占用就确定了换句话说它是个可计算量不是玄学占用。所以排查跑不起来时顺序应该是先算权重能不能装下再算 KV能开多长、几个并发——顺序反了就会在错误的变量上折腾。二、公式里的 5 个变量我的模型各取多少公式本身是公开知识写成一行KV cache(GB) 2 × 层数 × KV头数 × head_dim × 序列长度 × batch × 位宽(bit) ÷ 8 ÷ 10^9真正容易出错的是取值。三个口径问题必须问清楚头数取的是 KV 头数不是注意力头数。GQA 模型里这两个值不同以公开配置为例8B 级模型常见num_attention_heads 32、num_key_value_heads 8照注意力头数算会把 KV 高估 4 倍70B 级模型常见 64/8高估 8 倍。batch 要不要算。本地单人调试可以按 batch1 估在线服务必须把并发乘进去——这是本地能跑、上线就 OOM的头号原因。单位是十进制 GB 还是 GiB。10^9与1024^3差7.4%在刚好装得下的场景里足以把结论判反。本文全部按十进制 GB与厂商标称口径一致。公式里的2是 Key 和 Value 各一份head_dim通常取 128但要以模型 config 为准。你也可以拿这三句话去问任何一家供应商报的是 KV 头数还是注意力头数含不含并发是十进制还是二进制口径三句答不齐后面的数字都不用看。这个坑我们当时踩过一次。上个月核对一台整机能不能开 32K 上下文规格页上写的是32 头我们顺手按注意力头数代入公式算出来 KV 要 17.2GB——当时差点得出这台机器开不了 32K的结论。后来回到模型的 config 里核对num_key_value_heads发现它其实是 8KV 只要 4.3GB结论完全反过来。同一份规格、同一个公式只因一个字段读错结论差了 4 倍。从那以后我们核对容量的流程里加了固定一步先从 config 里把层数、KV 头数、head_dim 三个值抄出来再动笔算。三、同样 32K 上下文32 头与 8 头差 4 倍用kv_lab.py本文第 6 节在本机跑的矩阵batch1、FP16模型结构4K8K32K128KMHA 7B32 层 / 32 KV头 / d1282.1 GB4.3 GB17.2 GB68.7 GBMHA 13B40 层 / 40 KV头 / d1283.4 GB6.7 GB26.8 GB107.4 GBGQA 8B32 层 / 8 KV头 / d1280.5 GB1.1 GB4.3 GB17.2 GBGQA 70B80 层 / 8 KV头 / d1281.3 GB2.7 GB10.7 GB42.9 GB关键对照同样是 32 头与 8 头的差别在 32K 上下文下是17.2GB vs 4.3GB整整 4 倍。这也解释了为什么 128K 上下文能普及——不是硬件突然变强了而是主流模型从 MHA 转向了 GQA/MQA把每个 token 要缓存的字节数压下去了。不过要提醒一句换结构不是免费的。KV 头数减少意味着多个注意力头共享同一份 Key/Value表达能力上有取舍所以新模型并不是头数越少越好而是在效果评测达标的前提下尽量少。工程上的判断顺序应该是先确认模型在你的任务上效果达标再比较它的 KV 头数与层数——不要为了省显存去选一个效果更差的模型那是把成本从显存挪到了业务上。四、batch 与 KV 精度INT8 一刀就把 KV 砍掉一半把开关拨到 GQA 70B、32K 上下文四个组合的实测结果KV 精度batch1batch8说明FP165.4 GB85.9 GB基线并发一变KV 涨 16 倍INT82.7 GB42.9 GB位宽减半占用减半INT41.3 GB21.5 GB再减半但精度风险更大两个结论①batch 的影响比位宽更猛——batch 从 1 到 8KV 直接 ×8②KV 量化是按位宽等比例压的FP16→INT8 省一半INT8→INT4 再省一半代价是量化算子带来的精度损失公开研究里 KV 量化已有多种方案例如 3-bit 类压缩与KV Pareto这类系统级优化见第 6 节来源。顺带回答一个常被问到的取舍FP16 与 INT8 都能跑区别只在精度余量和算子支持——如果你所在框架的 KV 量化算子还没经过充分验证那就先用 batch 与上下文这两刀它们是零风险的。五、8 / 24 / 48 / 128GB 各能开多长上下文把矩阵和权重账合起来反向查。下表按权重 单并发 KV估算留 10%–20% 余量的场景请自行下压一档机器容量权重配置KV 配置单并发合计结论8 GB8B-INT4 ≈ 4.0 GBGQA 8B32KFP16 4.3 GB8.3 GB超了KV 换 INT82.1 GB后 6.1 GB 才可行24 GB8B-INT4 ≈ 4.0 GBGQA 8B128KFP16 17.2 GB21.2 GB单并发可开 128K48 GB32B-INT4 ≈ 16.0 GBGQA 70B 结构32K 10.7 GB26.7 GB70B 权重35 GB装不下32B 级可开 32K 并留并发余量128 GB70B-INT4 ≈ 35.0 GBGQA 70B32Kbatch8 85.9 GB120.9 GB贴上限KV 换 INT8 后 77.9 GB余量回到 50 GB 级如果只记一句话可以直接引用这句先算权重定能不能装下再算 KV 定能开多长、能开几个并发。上表不适用于多机张量并行与 KV 分片场景——那种情况下 KV 会按卡切分需要按切分策略重算。接下来会遇到的问题通常不是算不出来而是算出来和nvidia-smi对不上那多出来的一块是运行时开销与显存碎片第 6 节统一解释。六、实验环境与复现说明商红科技在本机跑出的数据脚本kv_lab.py就在下面Python 3、无第三方依赖GB10**9defkv_gb(layers,kv_heads,head_dim,seq,batch1,bits16):return2*layers*kv_heads*head_dim*seq*batch*bits/8/GBprint(kv_gb(32,32,128,32768))# MHA 7B, 32K - 17.2print(kv_gb(32,8,128,32768))# GQA 8B, 32K - 4.3print(kv_gb(80,8,128,32768,batch8,bits8))# GQA 70B, 32K, b8, INT8 - 42.9本机实测输出原样贴出未做四舍五入对应上文 17.2 / 4.3 / 42.917.179869184 # MHA 7B, 32K, batch1, FP16 4.294967296 # GQA 8B, 32K, batch1, FP16 42.94967296 # GQA 70B, 32K, batch8, INT8关于实验环境与复现说明这批数据是在一台普通开发机上跑出来的GB定义为10 ** 9十进制刻意不依赖任何推理框架——这样任何人换上台式机、笔记本或统一内存设备只要层数与 KV 头数一致结果就一致。把 vLLM 文档里的 block 分配口径与我们这套算式口径对齐之后可以得到一个实用结论分块分配改变的是怎么分配不改变总量。所以先用它把碎片压下去再回到本文的算式判断容量够不够——两件事不要在同一个步骤里混着算。这张矩阵我们整理成了一张可直接复用的清单层数 / KV 头数 / 上下文 / 并发 四列对照需要的可以直接找我们要。参考来源KV cache 的公式与管理机制可对照 vLLM 官方文档其中--block-size决定每块 token 数与分配粒度KV 量化的公开研究可看 KV Pareto: Systems-Level Optimization of KV Cache and Model Compression。常见问题① 为什么我按公式算的和nvidia-smi看到的不一样——框架还会占用运行时开销与显存碎片公式算的是理论下限② 用了 PagedAttention 还需要算 KV 吗——需要它管的是怎么分配不改变总量③ MLA 结构怎么算——公式里的 KV 头数换成其压缩后潜在维度对应的等价项不再直接适用本公式。七、小结三句话记住 KV cache说到底KV cache 这件事只有三句话随上下文线性涨、被结构KV 头数决定、被并发放大约束。权重决定能不能装下KV 决定能开多长、能开几个并发——顺序反了就会得出能跑但实际跑不动的结论。把你的层数、KV 头数、目标上下文长度和并发数发到评论区我按上面的脚本给你重算一版矩阵如果算下来现有机器不够用也可以在评论区留言咨询下一步该压哪个变量——同一套公式对所有模型都成立换成你的 config 就能算。