GPUFits
长上下文的显存代价:线性增长、架构差异与按需定长
更新于 2026-09-10 · 核实于 2026-09-10
模型卡上的「支持 128K 上下文」是一句架构描述,不是一句使用承诺。真正决定你能开多长上下文的,是你的显存减去权重之后还剩多少——剩下的部分,按每 token 固定单价被 KV 缓存逐字节买走。
这篇回答三个问题:上下文变长时显存怎么涨、为什么不同模型的「长上下文税」差出十倍、以及你手上的任务到底该开多长。KV 缓存本身的机制(为什么每层都要存、GQA 怎么省、MLA 怎么压缩)在 KV 缓存详解 里有完整推导,本文专注算成本账。
线性增长:没有拐点,只有单价
KV 缓存的公式里,上下文长度是唯一的变量,其余全是架构常数:
KV 缓存 = 每 token 成本(架构决定)× 上下文长度(你决定)
这意味着增长曲线是一条过原点的直线。以 Llama-3.1-8B 为例(fp16 KV,每 token 131,072 字节):
| 上下文 | KV 缓存 | 对照 |
|---|---|---|
| 4K(Ollama 默认) | 0.5 GB | 几乎无感 |
| 8K | 1.1 GB | 约等于一杯咖啡 |
| 16K | 2.1 GB | 开始值得注意 |
| 32K | 4.3 GB | 接近 Q4 权重(4.9GB) |
| 64K | 8.6 GB | 超过权重 |
| 128K(原生上限) | 17.2 GB | 权重的 3.5 倍 |
开 q8 KV 缓存,表中所有数字减半,斜率不变。这就是全部数学:上下文翻几倍,KV 就涨几倍。
换个角度读这张表:Qwen3-32B 的每 token 成本是 Llama-8B 的两倍(256 KB vs 128 KB),所以 32B 模型开 8K 上下文,比 8B 模型开 32K 还贵。「模型多大」和「上下文多贵」是两笔独立的账。
架构决定税率:每 token KV 成本榜
把站点收录的模型按每 token KV 成本排序(fp16,按本站计算器同款公式):
| 模型 | 架构要点 | 每 token | 32K 时 | 128K 时 |
|---|---|---|---|---|
| gpt-oss-20b | 24 层 × 8 KV 头 × 64 维 | 48 KB | 1.6 GB | 6.4 GB |
| Muse-Glimmer-30B | 52 层 × 2 KV 头 | 52 KB | 1.7 GB | 7.0 GB |
| DeepSeek-R1 | MLA 压缩潜向量 | 69 KB | 2.3 GB | 9.2 GB |
| gpt-oss-120b | 36 层 × 8 KV 头 × 64 维 | 72 KB | 2.4 GB | 9.7 GB |
| Qwen3-30B-A3B | 48 层 × 4 KV 头 | 96 KB | 3.2 GB | 12.9 GB |
| Llama-3.1-8B | 32 层 × 8 KV 头 | 128 KB | 4.3 GB | 17.2 GB |
| Qwen3-8B | 36 层 × 8 KV 头 | 144 KB | 4.8 GB | 19.3 GB |
| Mistral-Small-3.2-24B | 40 层 × 8 KV 头 | 160 KB | 5.4 GB | 21.5 GB |
| Qwen3-32B | 64 层 × 8 KV 头 | 256 KB | 8.6 GB | 34.4 GB |
| Llama-3.3-70B | 80 层 × 8 KV 头 | 320 KB | 10.7 GB | 42.9 GB |
| Gemma-3-27B | 62 层 × 16 KV 头 | 496 KB | 16.6 GB | 66.6 GB |
三个值得记住的事实:
- 参数量和 KV 成本基本无关。 30B 的 Qwen3-30B-A3B(4 个 KV 头)每 token 比 8B 的 Llama 便宜 25%;671B 的 DeepSeek-R1 靠 MLA 把成本压到 69 KB,不到 Llama-3.3-70B 的四分之一。决定价格的是层数 × KV 头数 × 头维度这三个架构常数。
- GQA 的分组比例就是税率。 同样 8 个 KV 头,Gemma-3 给了 16 个,成本直接翻倍。选模型时
num_key_value_heads值得和参数量一起看。 - 滑窗和混合架构的实际占用低于公式值。 gpt-oss 一半层只保留固定窗口,Gemma-3 每 6 层里 5 层是 1024 滑窗,Muse-Glimmer 是 3:1 的滑窗/全局混合——窗口层和线性层的 KV 不随上下文增长。本站计算器对它们仍按标准公式算(宁保守勿乐观),所以表中对这几款是高估。
机制层面的完整解释(GQA 论文、MLA 的 576 维潜向量、滑窗如何叠加 RoPE)见 KV 缓存详解。
长上下文不只贵,还慢
显存只是第一笔账,速度是第二笔。生成阶段(decode)每产出一个 token,显卡都要把全部权重和整段 KV 缓存从显存读一遍。上下文越长,每 token 要读的 KV 越多,生成越慢。
拿 RTX 4090(带宽 1008 GB/s,效率系数 0.75)跑 Llama-3.1-8B Q4_K_M(权重 4.9GB)算一遍(理论估算 ±30%):
| 上下文 | 每 token 读取量(权重 + KV) | 理论速度 |
|---|---|---|
| 短上下文(KV 忽略) | 4.9 GB | 约 154 tok/s |
| 32K | 9.2 GB | 约 82 tok/s |
| 128K | 22.1 GB | 约 34 tok/s |
上下文从近乎零拉到 128K,生成速度跌到原来的五分之一。注意本站速度工具只计权重读取,所以超长上下文下实际 tok/s 会低于工具估算值——差得越远,说明 KV 占比越高。
读入侧(prefill)也有代价:计算量约等于 2 × 参数量 × 提示词 token 数。8B 模型读一段 100K token 的提示词约需 1.6×10¹⁸ 次浮点运算,RTX 4090 按有效 40 TFLOPS 粗算要约 40 秒(理论估算,实际受框架影响很大)。长上下文的真实体验是:发完一条长文档,先等 prefill,再用变慢的速度看输出。
按任务选上下文长度
上下文不是越大越好,是够用就好。多开的每一 K 都在收显存税和速度税:
| 任务 | 建议上下文 | 依据 |
|---|---|---|
| 日常对话、写作、翻译 | 4–8K | 几十轮对话用不满 8K |
| RAG 问答 | 8–16K | 5–10 个片段 × 500–800 token + 问题 + 输出 |
| 单文件/小项目代码 | 8–16K | 一个文件加相关上下文 |
| 整库代码分析、长文档总结 | 32K+ | 百页 PDF 约 6–7 万 token(粗略换算:一页英文约 500 词 × 1.3 token),要么开 64K+,要么分段处理 |
| Agent / 多轮工具调用 | 按峰值 × 2 预留 | 历史记录只增不减,留增长空间 |
| 自托管 API 服务 | 单会话长度 × 并发数 | 每个会话各存一份 KV,见下文 |
两个具体提醒:
- 先检查默认值。 Ollama 默认上下文只有 4096 token(旧版本 2048)——很多人以为自己在用 128K 模型,实际窗口只有 4K。改法:
/set parameter num_ctx 16384或 Modelfile 里PARAMETER num_ctx 16384;llama.cpp 用-c参数;LM Studio 在加载面板里调。 - 设小不伤质量。 窗口是记忆长度不是能力,超出的旧内容被丢弃。对短任务主动调小窗口,省显存还提速,没有任何质量代价。
算出你的上下文预算
把公式倒过来用,就是你的显卡能买到的上下文长度:
可用上下文 = (显存 − 权重 − 1.5GB 固定开销)÷ 每 token KV 成本
几个典型组合(Q4_K_M 权重,fp16 KV):
| 显卡 | 模型 | 剩余预算 | fp16 可用上下文 | 开 q8 KV 后 |
|---|---|---|---|---|
| 12GB(RTX 3060) | Llama-3.1-8B(4.9GB) | 5.6 GB | 约 41K | 约 83K |
| 16GB(4070 Ti Super) | Qwen3-8B(5.0GB) | 9.5 GB | 约 62K,但原生上限 32K → 全窗口轻松 | 余量更多 |
| 24GB(3090/4090) | Llama-3.1-8B(4.9GB) | 17.6 GB | 约 131K → 刚好覆盖原生 128K(总需求 23.6GB,紧张档) | 从容 |
| 24GB(3090/4090) | Qwen3-32B(20.1GB) | 2.4 GB | 约 9K | 约 18K;原生 32K 需 25.9GB,单卡不够 |
判定口径:总需求 ≤ 可用显存 × 80% 为舒适,≤ 100% 为紧张。不想手算就开显存计算器,选模型、拉上下文滑块,KV 那条柱会实时变长;想直接知道自己的卡能跑什么,用 GPU 兼容性检查器。
做自托管服务的话,把「单会话 KV × 并发数」代入同一公式:24GB 卡跑 Qwen3-32B,剩余 2.4GB 预算,4 个并发会话每个只能分到约 2K 上下文——这就是为什么多用户场景要么加卡(见多卡指南),要么选 KV 便宜的模型。
要点回顾
- KV 缓存随上下文严格线性增长,每 token 单价由架构常数决定,选型时就能看到。
- 参数量不决定长上下文成本,KV 头数、层数、MLA/滑窗才决定。同规模模型能差 3 倍,跨规模能差 10 倍。
- 长上下文同时收两笔税:显存(线性)和 decode 速度(KV 占比越高越慢,理论估算 ±30%)。
- 按任务定长,不按上限定长。聊天 4–8K,RAG 8–16K,长文档和整库代码才需要 32K+。
- 显存不够时的顺序:q8 KV → 降权重量化档 → 换架构或加卡。权重量化和 KV 量化是独立开关,细节见量化指南和 KV 缓存详解。
买卡前、选模型前、设 num_ctx 前,先算这笔账。
常见问题
上下文每翻一倍,显存多花多少?
每个模型有一个固定的「每 token KV 成本」。Llama-3.1-8B 是 131,072 字节/token(fp16),所以上下文从 8K 翻到 16K,多花 1.1GB;从 64K 翻到 128K,多花 8.6GB。完全线性,没有拐点。
上下文设小了会伤模型质量吗?
不会。上下文窗口只是记忆长度,不改变模型本身的能力。超出窗口的旧内容被丢弃,仅此而已。对不需要长记忆的任务,主动把窗口调小是纯赚:省显存、提速,零质量代价。
长上下文会让生成变慢吗?
会。生成阶段每出一个 token 都要把整段 KV 缓存从显存读一遍。RTX 4090 跑 Llama-3.1-8B(Q4):不计 KV 时约 154 tok/s,32K 上下文时约 82 tok/s,128K 时约 34 tok/s(均为理论估算 ±30%)。上下文翻四倍,速度大约腰斩。
RAG 到底需要多长的上下文?
按检索片段总量算,不要按模型上限算。5–10 个片段 × 每段 500–800 token,加上问题和输出,8–16K 通常足够。盲目开 128K 只是把显存和速度浪费在永远用不到的窗口上。
多用户并发时 KV 缓存怎么算?
每个并发会话各存一份完整 KV,互不共享。总 KV = 单会话 KV × 并发数。Qwen3-32B 开 4 个 32K 并发,光 KV 就约 34GB(fp16)——做自托管服务时,先定并发数,再定上下文长度。
显存不够开长上下文,先动哪个开关?
第一步开 q8 KV 缓存(占用减半,质量代价可忽略);第二步降一档权重量化;都不行再考虑换 KV 更省的架构或加卡。注意权重量化和 KV 量化是两个独立开关,权重 Q4 不会让 KV 自动变小。