本文是「术语解构」系列之一。上一篇《上下文窗口：标称 1M 的 token，为什么 32K 就开始变笨》讲了模型“读不进去”的问题，结尾留了：KV Cache 出场一次，就吃掉了 64GB 显存。这一篇兑现承诺，拆这张“草稿纸”。

先纠正上一篇的一个数字。当时写的是：一个32B模型在1M上下文满载时，仅KV Cache就需要64GB以上显存。

在这篇中把公式摆出来，你会发现“以上”两个字有多克制——按Qwen3-32B的公开架构参数算，是256GB。

一台24GB的MBP，别说1M，把上下文开到128K，光这张草稿纸就要32GB，模型本体还没算，机器已经装不下了。

这就是本地部署时候都遇到过的两个现象的共同根源：上下文长度往大调，内存肉眼可见地飙升；对话越聊越长，生成越来越慢。

今天来看：KV Cache到底是什么、这笔显存账怎么算、以及行业和你各自能拿它怎么办。

一、KV Cache是什么：不是优化技巧，是生成机制本身

没有 KV Cache 时，每生成一个 token 都要重算全部前文；有 KV Cache 时，把 K/V 草稿纸存下来复用。
没有 KV Cache 时，每生成一个 token 都要重算全部前文；有 KV Cache 时，把 K/V 草稿纸存下来复用。

之前在显存篇讲过大模型推理分两个阶段：Prefill（把你的输入一次性读完）和Decode（一个token一个token地往外吐）。

问题出在Decode阶段。当Transformer生成每一个新token时，都要通过注意力机制“回看”前面所有的token。而回看的原材料，是每个token在每一层算出来的两组向量：K（Key）和V（Value）。

现在做一道选择题。生成第1000个token时，前面999个token的K和V从哪来？

  • 方案A：现算。把前文999个token从头再过一遍模型。生成下一个token时，再过一遍1000个。每个字都要重算全部前文——计算量随长度平方增长，长对话会慢到不可用。
  • 方案B：存下来。第一次算出来的K和V留在显存里，之后每个新token直接查表。代价是：这些向量得一直占着显存。

方案B就是KV Cache。它不是某种可开可关的“缓存加速”，而是所有主流推理框架的默认工作方式——没有它，长文本生成在算力上根本不成立。

所以KV Cache的本质一句话就能说清：拿显存换算力。草稿纸这个比喻的准确之处在于——你可以不打草稿，但那样每一步都得心算全部前文；打草稿快得多，只是纸会越用越厚。

它和模型权重还有一个关键区别：权重一次加载、所有请求共用一份；KV Cache 是每个会话、每段上下文各有一份，而且随长度一路长大。这个区别，是理解后面所有账目的钥匙。

二、算一笔明细账：显存税的税率是多少

KV Cache 显存占用：随上下文线性膨胀，与内容无关
KV Cache 显存占用：随上下文线性膨胀，与内容无关

这笔账有公式，而且不难：

每个token的KV Cache=2（K和V两份）× 层数 × KV 头数 × 每头维度 × 每参数字节数

拿两个公开架构参数的模型代进去（FP16 精度，每参数 2 字节）：

模型层数KV 头数每头维度每 token 占用32K 上下文128K 上下文1M 上下文
Qwen3-8B368128144 KB4.5 GB18 GB144 GB
Qwen3-32B648128256 KB8 GB32 GB256 GB

注意表格里几个扎眼的地方：

第一，税率是固定的，按长度线性征收。每读进一个token，Qwen3-32B 就要交256KB显存税——不管这个token是《三体》正文还是标点符号。上下文翻倍，草稿纸严格翻倍。这和上一篇讲的注意力计算量平方增长不同：计算量决定你等多久，KV Cache 决定你装不装得下。

第二，8B 的小模型也逃不掉。很多人以为小模型省显存，模型本体确实省——Qwen3-8B 量化后5GB左右就能装下。但把上下文开到128K，KV Cache要18GB，是模型本体的三倍多。长上下文场景里，草稿纸才是大头。

第三，存在一个交叉点。Qwen3-32B的4-bit量化权重约18～20GB。按256KB/token 算，上下文到7～8万token 附近，草稿纸就比模型本体还大了。过了这个点，你的显存主要不是在装模型，是在装草稿。

第四，并发是这笔税的放大器。上面算的都是单个用户。按表格，一个Qwen3-32B会话开32K上下文，草稿纸8GB——单看不算离谱。但8个用户同时挂着，就是 64GB，权重还是那一份，缓存按会话数复制。这解释了很多部署时的错觉：自己压测时一个人、一段上下文，觉得机器绰绰有余；真实用户进来，多轮对话、长文档、长任务同时挂着，显存突然就不够了。为什么长上下文 API 那么贵（上一篇的第二笔账）？现在你看到了成本端的实体：机房里的显存，一大半在给草稿纸交房租。

第五，它还拖慢生成速度，而且两个阶段慢得不一样。Prefill 阶段吃计算：输入越长，把整段上下文的K/V 算出来写进缓存的时间越久——这就是长文档丢进去后“先卡一下”的那段等待。Decode阶段吃带宽：每生成一个token，除了读一遍模型权重，还要把整个KV Cache读一遍。上下文10万token时，每个字都背着几十GB的读取量。这就是“越聊越慢”的物理解释——不是模型累了，是草稿纸太厚，翻一遍越来越费时间。

把这几条合起来，是四个本地部署玩家迟早撞上的“不代表”：

  • 模型文件装得进显存，不代表长上下文跑得起来
  • 单人聊天能跑，不代表多开几个会话还能跑
  • 8K配置很舒服，不代表64K只是慢一点
  • Prefill 扛过去了，不代表Decode能一直稳

上一篇讲的是长上下文会让模型变笨；这一篇讲的是更硬的一层——很多时候还没轮到它变笨，显存已经先不够了。

三、行业怎么驯服它：四条路线

驯服 KV Cache 的四条路线：少存、压缩、存粗、管好。
驯服 KV Cache 的四条路线：少存、压缩、存粗、管好。

256GB的账单摆在那里，整个行业这几年在KV Cache上下的功夫，比在“把窗口标大”上实在得多。四条路线，按思路分：

路线一：少存几份——MQA和GQA。

原始的多头注意力（MHA）里，每个注意力头都存一份自己的K和 V。以 Llama 2的7B 为例：32层 × 32头，每token要交 512KB。

后来发现，K和V不需要每个头独一份——多个查询头共享一组KV就够了，质量损失很小。这就是GQA（分组查询注意力）。

上面表格里Qwen3的“KV 头数 8”就是它：64个查询头共享8组KV，草稿纸直接砍到MHA的1/8。极端版本MQA只留1组。

现在几乎找不到不用GQA的新模型。没有这一刀，前面表格里所有数字乘以8——长上下文根本走不到发布会那一步。

路线二：压缩了再存——DeepSeek的MLA。

GQA是少存几份，MLA（多头潜在注意力）更激进：把K和V压缩成一个低维向量存起来，用的时候再解压展开。DeepSeek-V2论文给出的数字是KV Cache削减93%，压到MHA的约1/15。

这个架构一路沿用到V3和V4。上一篇讲过厂商在长上下文位置设收费闸门，而DeepSeek的API定价一直是行业地板价——MLA省下来的显存房租，就是底气的一部分。架构上的一个选择，最后会体现在价目表上。

路线三：存粗一点——KV Cache量化。

模型权重能量化，草稿纸一样能。K和V从FP16降到8-bit，占用直接减半；降到4-bit，只剩 1/4。代价是精度损失——8-bit基本无感，4-bit在长文本任务上开始可感（尤其V的量化更敏感）。

这条路线对本地部署用户最实惠，下一节展开。

路线四：管理得更聪明——PagedAttention和滑动窗口。

vLLM的论文揭了一个短：传统推理框架给每个请求预留最大长度的连续显存，实际用不满的部分全浪费——实测浪费率60%～80%。PagedAttention借鉴操作系统的分页内存，把KV Cache切成小块按需分配，浪费降到4%以下。同样的显存，能多服务好几倍的并发——这是推理服务这两年降价的技术底牌之一。

另一个思路是滑动窗口注意力：草稿纸只保留最近N个token，更早的直接扔。Mistral、Gemma都在部分层用了这个设计。省是真省，代价也直白——扔掉的部分，模型是真的“忘了”。

最后还有一条兜底路线：卸载（Offload）——显存装不下，就把一部分缓存搬到内存甚至磁盘，用的时候再搬回来。容量问题缓解了，速度账立刻难看：Decode每个token都要读缓存，而PCIe搬运不是免费的。这条路线的定位是“能跑总比跑不了强”，不是常规方案。

四、说句公道话：草稿纸也可以是资产

为了不把KV Cache写成纯反派，补一个反方向的视角。

既然这张草稿纸算一次这么贵，那算完别扔，存下来卖二手，是不是一门生意？

是的，这就是各家API的Prompt Caching（提示词缓存）：你的system prompt、背景材料这些每次请求都一样的前缀，第一次算完后KV Cache被存下来，下次命中直接复用，Prefill阶段整个跳过。严格区分一下这两个词：KV Cache是一次会话内部的运行时缓存，解决“生成时不重算前文”；Prompt Caching是把这份缓存跨请求持久化，解决“不同请求不重算相同前缀”。省的都是重复计算，省的位置不同。厂商省了算力，把折扣分你一部分——DeepSeek缓存命中的价格能低到未命中的几十分之一。

我自己的A股分析Agent就是靠这个把账单打下来的：固定的角色和规则放前缀，每天变的行情数据放后缀，缓存命中率能跑到97%以上。这套计费机制里的门道（写入费、精确前缀匹配、什么场景反而亏钱），值得单独一篇拆解，先按下不表。

所以对KV Cache完整的评价是：它是长上下文的成本，也是重复上下文的折扣券。贵的是第一次，会用的人不付第二次全款。

五、落地：三个场景的操作建议

场景一：本地部署——上下文长度是你手动签的显存支票。

这是最直接能省出真金白银（显存）的地方。关键认知：llama.cpp和LM Studio会按你设置的上下文长度，把KV Cache显存提前划走——不管你实际用不用得到。把context length拉满再抱怨内存爆，等于签了张空头支票怪银行。

两个具体动作：

  1. 按需设置上下文长度，别拉满。日常问答8K够用，代码和长文任务再上32K。按第二节的表格，Qwen3-32B级别的模型从128K降到 32K，立省24GB——在24GB的Mac上，这是能跑和不能跑的区别。
  2. 打开KV Cache量化。llama.cpp用--cache-type-k q8_0 --cache-type-v q8_0（V的量化需要同时开启Flash Attention），LM Studio在模型加载设置里也有对应开关。8-bit让同样的上下文只吃一半显存，日常任务质量无感。

场景二：API调用——把不变的放前面。

Prompt Caching的命中条件是前缀精确匹配。所以写提示词时养成习惯：system prompt、规则、示例这些不变的部分放最前面，每次变化的用户内容放最后。顺序反了，缓存一次都命中不了，每次都付全款。

场景三：长对话和Agent——定期换草稿纸，而且新草稿要记“状态”，不要抄“流水账”。

聊了几个小时的会话越来越慢、越来越贵（每一轮都背着全部历史的KV Cache），这时候最有效的操作不是换模型，是让模型总结当前进展，带着总结开个新会话。草稿纸从10 万token换成2千token，速度、价格、还有上一篇讲的“中间盲区”问题，一次全解决。

总结时有个讲究：模型需要的是状态，不是聊天记录原文。一份好的交接摘要长这样——目标是什么、已确认的事实和约束有哪些、试过哪些失败路径、下一步做什么。寒暄、重复尝试、已废弃的方案，清掉。Agent场景尤其要注意：工具输出、日志、报错会一轮轮塞回上下文，KV Cache在你没盯着的时候就涨起来了，定期把它们沉淀成状态表，是最便宜的“降税”手段。

顺带再回应上一篇评论区问到的一个问题——“多长的上下文是安全的”。现在可以给出完整答案：这个问题有两个上限，取较小值。能力上限看上一篇（有效窗口远小于标称，任务越复杂缩水越狠）；硬件上限看这一篇的公式（显存减去模型本体，除以每 token 税率）。云端API只受第一个约束，本地部署两个都躲不开。

一句话总结这篇：上下文窗口是“能装多少”的承诺，KV Cache是这份承诺的账单——按token计价，用显存支付。

数据来源