KV 缓存详解:长上下文为什么吃掉你的显存

更新于 2026-08-04 · 核实于 2026-08-04

每一句「本模型支持 128K 上下文」都跟着一个以 GB 计量的星号。这个星号就是 KV 缓存。

它是什么

模型读取你的提示词时,会把每个 token 在每一层的中间表示(K 和 V 张量)存下来,这样就不用重复计算。这个存储就是 KV 缓存。它让生成变快——也让长对话或大文档独立于模型权重吃掉显存。

公式

KV 缓存 = 2 × 层数 × KV 头数 × 头维度 × 每值字节数 × 上下文 token 数

2 是 K 和 V 两份。每值字节数fp16(默认)为 2,q8 为 1。架构常数直接来自各模型的配置:

模型	层数	KV 头数	头维度	每 token	8K 时	128K 时
Llama-3.1-8B	32	8	128	128 KB	1.1 GB	17.2 GB
Qwen3-32B	64	8	128	256 KB	2.1 GB	34.4 GB
Llama-3.3-70B	80	8	128	320 KB	2.7 GB	42.9 GB
gpt-oss-120b	36	8	64	90 KB	0.7 GB	11.8 GB
DeepSeek-R1(MLA)	61	—	—	70 KB	0.6 GB	9.4 GB

再读一遍 Qwen3-32B 那行:128K 上下文时,KV 缓存(34GB)超过了 Q4 权重(20GB)。 一张「跑 Qwen3-32B 没问题」的 24GB 显卡,连它标称 32K 的上下文都碰不到,更别说 128K。

GQA 已经救过你一次(只是你没注意)

现代模型使用分组查询注意力:Qwen3-32B 有 64 个查询头,但只有 8 个 KV 头。老架构两者相等——那样 128K 那行就要读成 275GB 而不是 34GB。比较模型时,KV 头越少 = 长上下文越便宜。

MLA:DeepSeek 的压缩魔法

DeepSeek-R1/V3 缓存的是压缩后的潜在向量而不是完整的 K/V:61 层 × 每 token (512 + 64) 个值。这就是为什么 671B 的模型 KV 缓存比 Llama-8B 还小。我们的计算器为 MLA 模型使用独立公式——这也是 R1 的 128K 上下文(容量允许时)真正可用、而其他模型的 128K 只是宣传的原因。

上下文吃紧时的三个杠杆

q8 KV 缓存(减半):llama.cpp/Ollama/LM Studio 都支持,质量代价极小。第一个该试的。
缩短上下文(线性节省):Ollama 默认 num_ctx=2048,这就是你的实测显存比计算器估算低的原因——有意识地设置它。
换 KV 头更少或用 MLA 的模型:买模型时的结构性解法,不是一个设置项。

常见问题

128K 上下文到底要多少显存?

Llama-3.1-8B 约 17GB——是 Q4 权重的 3 倍多;Qwen3-32B 约 34GB,超过权重本身。这就是为什么「支持 128K 上下文」和「你的显卡能用 128K 上下文」是两回事。

q8 KV 缓存伤质量吗?

对大多数工作负载影响微小——上下文吃紧时是推荐的第一选择。llama.cpp、Ollama、LM Studio 都支持 KV 量化,开启后 KV 占用减半。

为什么我的 Ollama 显存占用比你们计算器算的低?

Ollama 默认 num_ctx=2048,不是模型的最大上下文。2048 token 的 KV 缓存很小。我们的计算器默认 4096,并允许你滑到模型的真实上限。