上下文长度要多少显存?KV 缓存计算公式与 Qwen3、Llama 3 实算表(2026)

KV 缓存是 Transformer 用来「记住」上下文里每个 token 的显存,它随上下文长度线性增长: 每 token 字节数 = 2 × 层数 × KV 头数 × 每头维度 × 每个数值的字节数。以 Qwen3 32B 为例,FP16 下每个 token 占 256 KiB,32k 上下文就是约 8 GB——这是在模型权重之外额外要的。这就是为什么模型能加载,一调大上下文就爆显存。

本文给出公式、常见开源模型的每 token 数值(读自各模型的 config.json),以及 24、32、48、80 GB 显卡各能放下多长的上下文。

公式

每 token KV 字节 = 2 × num_hidden_layers × num_key_value_heads × head_dim × 每数值字节
KV 总字节       = 每 token KV 字节 × 上下文 token 数 × 并发序列数

• 2 代表 Key 和 Value 两份。
• 采用分组查询注意力(GQA)的模型,num_key_value_heads 远小于注意力头数,所以新模型的 KV 缓存比老模型小得多。
• 每数值字节:FP16/BF16 为 2,8 位 KV 缓存为 1,4 位约 0.5。
• 并发会成倍放大。 服务端同时保留 4 个并发槽位,就要按 4 倍上下文来算。

常见模型每 token 的 KV 缓存(FP16)

结构参数来自各模型在 Hugging Face 上的 config.json(2026-10-23 读取)。下文 GB 指 GiB(1024³ 字节)。

模型	层数	KV 头	head_dim	每 token	8k	32k	128k
Llama 3.1 8B	32	8	128	128 KiB	1.0 GB	4.0 GB	16 GB
Qwen3 8B	36	8	128	144 KiB	1.1 GB	4.5 GB	18 GB*
Qwen3 14B	40	8	128	160 KiB	1.25 GB	5.0 GB	20 GB*
Mistral Small 3 24B	40	8	128	160 KiB	1.25 GB	5.0 GB	—(上限 32k)
Qwen3 32B	64	8	128	256 KiB	2.0 GB	8.0 GB	32 GB*
Llama 3.3 70B	80	8	128	320 KiB	2.5 GB	10 GB	40 GB
Qwen2.5 72B	80	8	128	320 KiB	2.5 GB	10 GB	40 GB*

* 超出模型原生窗口。Qwen3 稠密模型的模型卡写明原生上下文为 32,768 token,可通过 YaRN 扩展;超过原生长度前请先看模型卡说明。

含滑动窗口层的模型(如 Gemma 3、gpt-oss)或采用潜在注意力(DeepSeek V3 式 MLA)的模型不能直接套这个公式,它们的实际缓存比公式算出的小。

每档显卡能放多长上下文

总显存 ≈ 权重 + KV 缓存 + 开销。权重取官网 /zh/run 页的 Q4_K_M 大小;开销假设为 1.5 GB(CUDA 上下文、缓冲区与运行时)。结果是单序列的理论上限;推理框架还会预留额外缓冲,实际应留在上限以下。

Qwen3 32B,Q4_K_M(权重约 19.5 GB,每 token 256 KiB):

显存档位	扣除权重和 1.5 GB 后留给 KV	单序列上限	实用建议
24 GB(RTX 4090 / 3090)	约 3 GB	约 12k token	约 8k,偏紧
32 GB(RTX 5090)	约 11 GB	约 45k(原生上限 32k)	16k–32k 宽裕
48 GB(RTX 4090 48G)	约 27 GB	约 110k	原生 32k 用满,或开多个并发槽

Llama 3.3 70B,Q4_K_M(权重约 41.5 GB,每 token 320 KiB):

显存档位	留给 KV	单序列上限	实用建议
48 GB(RTX 4090 48G / A6000)	约 5 GB	约 16k	约 8k,偏紧
80 GB(A100 / A800)	约 37 GB	约 121k	32k 宽裕,还能留并发

「实用建议」一列与官网 Qwen3 32B 显存页、Llama 3.3 70B 显存页 的说明一致。

一个小计算器

def kv_gb(layers, kv_heads, head_dim, ctx, bytes_per_value=2, seqs=1):
    return 2 * layers * kv_heads * head_dim * bytes_per_value * ctx * seqs / 1024**3

def max_ctx(vram_gb, weights_gb, layers, kv_heads, head_dim,
            bytes_per_value=2, overhead_gb=1.5, seqs=1):
    free = vram_gb - weights_gb - overhead_gb
    per_tok = 2 * layers * kv_heads * head_dim * bytes_per_value / 1024**3
    return max(0, int(free / (per_tok * seqs)))

# Qwen3 32B(64 层、8 个 KV 头、head_dim 128),Q4 权重约 19.5 GB
print(kv_gb(64, 8, 128, 32768))          # 8.0
print(max_ctx(32, 19.5, 64, 8, 128))     # 约 45k(原生上限 32k)
print(max_ctx(24, 19.5, 64, 8, 128, bytes_per_value=1))  # 8 位 KV:约 24k

num_hidden_layers、num_key_value_heads、head_dim(或 hidden_size / num_attention_heads)都在模型的 config.json 里。

想放更长上下文的三个办法

1. 量化 KV 缓存。 每数值字节减半,缓存就减半。

# Ollama:8 位 KV 缓存(需开启 flash attention)
export OLLAMA_FLASH_ATTENTION=1
export OLLAMA_KV_CACHE_TYPE=q8_0
ollama serve

# vLLM:FP8 KV 缓存
vllm serve Qwen/Qwen3-32B-AWQ --kv-cache-dtype fp8 --max-model-len 32768

8 位对质量的影响通常不大,4 位更明显;请用自己的提示词实测。

2. 按需设置上下文,不要默认开到最大。 Ollama 可在请求里传 "options": {"num_ctx": 16384}(或设置 OLLAMA_CONTEXT_LENGTH);vLLM 用 --max-model-len 限制上下文,用 --gpu-memory-utilization 控制缓存可占用的显存比例。

3. 注意并发。 Ollama 的 OLLAMA_NUM_PARALLEL 和 vLLM 的批处理都会按序列分配缓存。单条测试没问题、一上并发就爆显存,通常就是这个原因。

实战排查:爆显存时按这个顺序调

假设你在 24 GB 的 RTX 4090 上用 Ollama 跑 Qwen3 32B(Q4_K_M),把 num_ctx 设成 32768 后出现显存不足或速度骤降(部分层被挪到 CPU)。按公式算:权重约 19.5 GB,32k 的 FP16 KV 约 8 GB,合计已超过 24 GB,放不下是必然的。可以按代价从低到高依次尝试:

1. 先降上下文。 把 num_ctx 调回 8192,KV 降到约 2 GB,总量约 23 GB,能跑但偏紧。
2. 再量化 KV。 开启 OLLAMA_FLASH_ATTENTION=1 和 OLLAMA_KV_CACHE_TYPE=q8_0,同样显存下上下文约翻倍,公式估算约 24k(上限,实际留余量)。
3. 检查并发。 把 OLLAMA_NUM_PARALLEL 设为 1,确认不是多个槽位在分摊显存。
4. 最后换卡。 仍不够就换到 32 GB 的 RTX 5090 或 48 GB 的 RTX 4090 48G;换卡要再等约 2 分钟开机,并重新下载模型。

每一步改完都用 nvidia-smi 看一眼实际占用,把实测数字记下来,下次选卡就有自己的依据。

用算出来的数字选卡

得到「权重 + KV + 开销」后,向上取到下一个显存档位,再到 部署页 看实时库存。2026-10-23 23:58(北京时间)挂牌价:RTX 4090 24G $0.33/h、RTX 5090 32G $0.59/h、RTX 4090 48G $0.65/h、A800 80G $1.09/h、A100 80G $1.49/h,按分钟计费,实例启动约 2 分钟。几张卡的并排对照见 4090、5090、A100 怎么选。

常见问题

模型的 KV 缓存大小怎么算? 用 2 × 层数 × KV 头数 × 每头维度 × 每数值字节(FP16 为 2)得到每 token 字节数,再乘以上下文长度和并发序列数。所需参数都在模型的 config.json 里。

Qwen3 32B 跑 32k 上下文要多少显存? FP16 KV 缓存约 8 GB(每 token 256 KiB × 32,768),加上约 19.5 GB 的 Q4_K_M 权重,32 GB 显卡比较宽裕。

为什么只有长上下文时才爆显存? 权重是固定的,KV 缓存却随上下文和并发请求增长。可以调小 num_ctx / max-model-len、减少并发槽位,或量化 KV 缓存。

8 位 KV 缓存能省一半显存吗? 能,缓存本身相对 FP16 减半。Ollama 设置 OLLAMA_KV_CACHE_TYPE=q8_0 并开启 flash attention;vLLM 使用 --kv-cache-dtype fp8。

这个公式对所有模型都适用吗? 适用于标准注意力和分组查询注意力。带滑动窗口层或潜在注意力的模型,实际占用比公式小。

声明:CloudGPU(cloudgpu.app)是独立服务,与模型厂商没有合作、授权或背书关系;模型名称归各自所有者。上下文上限为按上述假设得出的估算,不是实测。价格为 2026-10-23 23:58(北京时间)读取的挂牌价,实时价格与库存以 /deploy 页面为准。