长上下文的显存账:KV Cache 32k/128k 要多吃多少 G?

显存估算的「模型体积 ×1.2」只回答了一半:剩下那「0.2」里的大头是 KV Cache,而它不随模型体积走,随上下文长度线性走。这篇把它单独算清。

一、公式

KV Cache 字节/token = 2(K+V) × 层数 × KV 头数 × 头维度 × 2 字节(FP16)

三个常见架构代入口(Qwen3 与 Llama-3 系头维度均为 128):

模型	层数 × KV 头	每 token KV	8k	32k	128k
Llama-2-7B(老 MHA)	32 × 32	512KB	4G	16G	64G
Qwen3-8B	36 × 8	288KB	2.3G	9G	36G
Qwen3-32B	64 × 8	512KB	4G	16G	64G
70B 级(Llama-3-70B)	80 × 8	640KB	5G	20G	80G

(编辑部落表口径:FP16 KV、无量化;GQA 的 KV 头数公开资料可查。)

「模型体积 + KV 账 + 2G 激活/缓冲」才是长上下文的真实显存需求:

最后两行是本篇最重要的结论:长上下文场景下,KV 账可以反超模型账。8B 模型 + 128k 上下文的显存需求与 70B 模型 + 8k 同级——「我模型小所以显存无所谓」在长上下文里不成立。

GQA(架构层,免费):KV 头数从 32 砍到 8,账直接 ÷4——这是 2023 年后新模型的标准设计,选模型看一眼 KV 头数就能避开 Llama-2 式的账本爆炸;
KV 量化(框架层,轻微损质):llama.cpp 把 K/V 从 FP16 降到 Q8/Q4,省 1/2 到 3/4;长文档检索类任务的召回率有可感知的下降,对话场景基本无感;
滑窗/截断(策略层,功能取舍):只保留最近 N token 的 KV,「假装上下文只有 32k」——超长文档问答会失忆,适合聊天不适合 RAG。

日常写作/代码(≤16k):16G 卡(5060 Ti 16G / 5070 Ti)+ 14B 级模型,KV 账 5G 内,无忧;
长文档/代码库分析(32k):32B 模型需要 38G → 魔改 4090 48G 或 32G 5090 降模型到 14B;8B + KV Q8 也能在 32G 内解决;
128k 全量:单卡消费级无解,双卡 96G 或直接走 API——本地跑长上下文的真实成本,是这篇这张表。

速度侧的另一半账(长上下文吐字变慢)在带宽公式里;70B 最低配置与 32G 内存兜底是短上下文路线的参考。

常见问题

KV Cache 为什么随上下文线性增长?

注意力机制要「记住」每个历史 token 的键值(K/V)供后续查询,每多一个 token 就多存一份。它是「记忆账本」:账本随对话变厚,显存占用线性上升——[词条版解释](/wiki/kv-cache/)。

「显存估算 ×1.2」的余量够吗?

短上下文(≤8k)够;32k 起就不够了——32B 模型 Q4 约 20G,×1.2 = 24G,但 32k 上下文还要再加 16G KV。长上下文用户请按「模型体积 + KV 账 + 2G 激活」重新算,余量公式只对短上下文成立。

KV 量化能省多少?

llama.cpp 支持 K/V 各降到 Q8(省一半)甚至 Q4(省 3/4),质量损失在长上下文检索类任务上可感知但不大。128k 上下文从 64G 降到 16G,是「32G 卡跑长上下文」的唯一现实路径。

为什么 8B 模型反而可能比 32B 更吃 KV?

看 KV 头数与层数,不看参数量:老式 MHA(如 Llama-2-7B,32 个 KV 头)每 token 512KB,和 64 层 GQA 的 Qwen3-32B 一样;而 Qwen3-8B 只有 36 层,每 token 288KB。选模型时 KV 效率(GQA 头数)是隐藏参数。