常见问题 / 起步概念

KV cache 是什么?为什么上下文那么吃显存?

KV cache 是为了不重复计算而存下来的历史注意力数据,它随上下文线性增长,长对话和长文档的显存大户就是它。

模型生成每个新字都要回看前面所有字。为了避免每步都重算一遍,框架把前面各层的 Key/Value 张量存住,这就是 KV cache。它的大小 = 2 × 层数 × KV头数 × 每头维度 × 精度字节 × 上下文长度,所以是严格线性的:上下文翻倍,KV 翻倍。

精确算法和参数量关系不大,真正决定的是层数和 KV 头数。本站按 config.json 实算出来的对照:Qwen3-32B(64 层 / 8 KV 头 / 头维 128)4K 上下文正好 1.0G;Qwen3-8B 和 Qwen3-4B 都是 36 层 8 头,所以 KV 完全一样,都是 0.56G/4K;GLM-4-9B 只有 2 个 KV 头,4K 只要 0.16G;而 gpt-oss-20B 一半层用 128 token 的滑窗,4K 只要 0.10G。

反例很有教育意义:如果按参数量线性猜 KV,会把 GLM-4-9B 猜成 0.5G(高估 3.2 倍)、把 gpt-oss 猜成 0.5G(高估 5 倍)、把 Qwen3-4B 猜成 0.25G(低估 2.3 倍)。这三个错会直接把『我这张 12G 卡能开多大上下文』的结论改写成另一个故事。

省 KV 有两个开关:① KV 量化(llama.cpp 的 -ctk q8_0 / q4_0),Q8 几乎不掉质量就能省一半,Q4 省四分之三;② 选带滑窗架构的模型,比如 Gemma 3 系列 48 层里只有 8 层要全量 KV。本站容量表顶部给了 KV 精度的切换控件,切一下就能看到结论怎么变。

条目性质:本站依据自身数据模型与公开架构常数撰写。 有错请直接告诉我们,见关于页。

相关问题

为什么有的模型开长上下文特别便宜?因为层数、KV 头数、每头维度这三个数决定 KV,和参数量不成比例。滑窗架构更把大部分层的 KV 锁死在固定窗口里。上下文(ctx)到底是什么?8K 能装多少字?上下文是模型一次能『看见』的总字数预算,输入和它的回答共用这个预算。8K token 大约相当于中文 4000–5500 字。

延伸阅读

16G 显存有哪些卡→

起步概念 · 其他条目

能不能跑一个模型,到底只看显存吗?量化是什么?Q4_K_M、Q8_0、IQ3 这些名字什么意思?上下文(ctx)到底是什么?8K 能装多少字?tok/s 是多少才够用?我是不是需要很快?稠密模型和 MoE 有什么区别?为什么 30B-A3B 可能比 14B 还快?我内存大(64G/128G),是不是就能跑大模型?
← 上下文(ctx)到底是什么?8K 能装多少字?回到全部 40 条tok/s 是多少才够用?我是不是需要很快? →
这条内容有帮助吗?