1. 为什么全网都在聊 KV Cache先搞懂大模型生成时在干什么KV Cache 这个概念凡是碰过大模型推理、显存优化、长上下文方案的人基本都绕不开。不管是自己用 Ollama 本地跑模型还是在公司做私有化部署只要模型一跑起来显存占用就会肉眼可见地往上涨这里面很大一部分就是 KV Cache 的功劳。先说人话KV Cache 是自回归解码过程中为了避免重复计算而缓存下来的 Key 和 Value 矩阵。大模型生成文本是逐个 token 往外蹦的每生成一个新 token都要拿当前这个 token 的 Query 去和之前所有 token 的 Key 做匹配再加权求和得到输出。如果每次生成都从头算一遍所有历史 token 的 Key 和 Value那计算量会随着序列长度呈现二次方增长——比如上下文到 4096 的时候, 光重复计算浪费的算力就占了总推理开销的大头。缓存的核心逻辑特别朴素已经算过的东西别算第二遍。就好比你写论文引用参考文献第一次看的时候摘录了重点后面再引用就不用重新翻一遍原文直接看摘录就行。KV Cache 干的就是这件事把历史 token 的 Key、Value 算好存起来后续生成只算当前 token 自己的 Key、Value 和 Query再和历史缓存的 KV 做注意力计算。这篇内容我会从推理机制、显存计算、为什么不是 QKV Cache、Long Context 下的 lost in the middle 现象、Prompt Cache 与 Prefix Cache 几个角度逐一拆开讲最后补一份实际部署时常用的显存优化和问题排查清单。适合刚接触大模型部署和推理优化的开发者也适合想深入了解 Transformer 解码器工作机理的算法工程师。我不堆公式尽量用实际数据和场景把这件事讲透。2. 从自回归解码说起KV Cache 到底省掉了什么计算2.1 大模型生成 token 的完整流程拆解要理解 KV Cache 为什么要存在得先完整走一遍大模型的推理过程。以目前主流的 Decoder-only 架构GPT 系列、Qwen、Llama 等都是这个路子为例生成一个回复可以拆成两个阶段Prefill 阶段预填充阶段用户输入的一整段 prompt比如“请介绍一下量子计算的基本原理”会被切分成若干个 token然后一次性喂给模型。这个阶段需要对所有的输入 token 做一次完整的前向计算算出每个 token 对应的 Key、Value、Query最终生成第一个输出 token。Prefill 阶段的计算强度极高因为输入序列的所有 token 都是并行计算的矩阵乘法的规模很大非常吃 GPU 算力。Decode 阶段解码阶段从生成第二个 token 开始进入逐 token 生成的状态。每一步只输入一个 token也就是上一步刚生成出来的那个模型要根据这个 token 以及前面所有的历史 token 来预测下一个 token。这个阶段的特点是计算量小、次数多每一步都要等上一步的结果所以延迟敏感。关键问题来了在 Decode 阶段假设当前已经生成了 100 个 token现在要预测第 101 个。注意力机制要求模型把第 101 个 token 的 Query 和前面 100 个 token 的 Key 全部做内积再乘上对应的 Value 加权求和。如果不做缓存那就得把前 100 个 token 重新喂一遍模型重新计算它们的 Key 和 Value——但这 100 个 token 在上一步已经算过了啊它们的内容又没有变化凭什么重算一遍这就是纯粹的浪费。2.2 计算复杂度的具体对比没有缓存 vs 有缓存我们用一个具体的数字来感受一下这个浪费有多恐怖。假设序列长度是 n根据 Transformer 的解码逻辑不做 KV Cache每一步都要对前 n 个 token 重新做一遍完整的自注意力计算。总计算量大约是 O(n²) 级别的因为每一步都在和越来越多的历史 token 做交互。生成到第 1000 个 token 的时候累计的重复计算量已经相当惊人。使用 KV CachePrefill 阶段一次性算好所有 prompt token 的 K 和 V 并存入显存。之后每生成一个新 token只需要用当前 token 的 Q 和当前 token 新算出的 K、V 参与计算历史 K、V 直接从显存里读。每次计算量只有 O(n)因为只需要做一个长度为 n 的向量内积n 是历史 token 的数量。这两者的差距随着生成长度增加是呈几何级数拉开的。业界实测数据在做 2048 长度的推理时启用 KV Cache 的推理速度可以做到不缓存的几十倍以上显存换算力这笔账怎么算都划算。我用一个生活化类比帮助理解KV Cache 就像你在一家餐厅连续点菜你每次去之前都要把整本菜单重新看一遍才知道想吃什么不缓存还是你第一次看菜单的时候就把喜欢的菜都记在脑子里之后直接报菜名就行缓存。重复翻菜单的时间省掉上菜速度自然就快了。2.3 Prefill 和 Decode 阶段对硬件资源的不同需求理解了这两个阶段也就明白为什么大模型推理服务通常会把 Prefill 和 Decode 分开优化。Prefill 阶段是计算密集型的适合用高算力 GPU 大规模并行处理Decode 阶段则是访存密集型的每一步都在反复读取 KV Cache 做矩阵乘加运算GPU 的显存带宽HBM bandwidth反而成了瓶颈。这也是为什么同样一张 A100 80G跑短 prompt 和跑长 prompt 的吞吐量差异巨大。Prompt 越长KV Cache 越大Decode 阶段每次读取的显存数据越多单 token 的生成延迟就越高。所以做推理优化的人不仅要看模型参数量还得把序列长度和 KV Cache 大小一起算进去不然配置了再好的 GPU 也可能被显存带宽拖死。3. 显存是怎么被 KV Cache 吃光的从公式到实际数值3.1 KV Cache 显存计算公式很多人第一次接触 KV Cache 时都有个疑惑模型参数不是固定的吗显存怎么还会随着对话长度变化答案就是 KV Cache 的大小是动态增长的。KV Cache 的显存占用可以精确计算公式如下显存占用字节 2Key 和 Value 两个矩阵 × 层数num_layers × 序列长度seq_len × 注意力头数num_heads × 每个头的维度head_dim × 字节数通常 2 字节半精度 FP16/BF16很多模型使用多组 Query AttentionGQA这时 KV 的头的数量与 Query 不一样公式里的注意力头数要换成 KV 头的数量num_kv_heads。举一个实际例子以 Llama 3.1 8B 为例模型有 32 层、每层 8 个 KV 头、每个头维度 128使用 BF16 精度。当上下文长度达到 8192 时KV Cache 的显存占用就是2 × 32 × 8192 × 8 × 128 × 2 1,073,741,824 字节 ≈ 1GB8B 模型本身 BF16 精度下权重占 16GB加上 1GB 的 KV Cache还有激活值、优化器状态训练时才需要、CUDA context 等显存规划就得往 24GB 以上走。也就是说你本地显卡如果只有 16GB 显存跑 8B 模型的 8K 上下文已经很勉强了。3.2 长上下文场景下的显存爆炸效应更让人头疼的是KV Cache 的大小和序列长度是线性关系上下文加长一倍缓存也翻一倍。现在很多模型宣称支持 128K、200K 上下文听起来很美但真在单卡上跑起来光 KV Cache 就能吃掉几十个 GB。以 7B 级别模型为例在不同上下文长度下 KV Cache 的显存占用大致如下假设 32 层、8 个 KV 头、head_dim 128、BF16上下文长度KV Cache 显存占用2K128MB8K512MB32K2GB128K8GB200K12.5GB而模型权重本身就占了 14GB 左右128K 上下文时单卡 24GB 已经兜不住。这也是为什么长上下文方案必须配合各种显存优化手段比如下面会提到的 GQA、量化、PagedAttention、KV Cache offload 等。3.3 为什么线上服务要动态规划显存实际做线上推理服务的时候不同请求的 prompt 长度和生成长度完全不一样如果按照最大上下文预分配显存那么短请求的显存利用率极低服务吞吐量上不去如果按请求动态申请频繁的显存分配和释放又会产生碎片和延迟。现在业界主流的方案是借鉴操作系统虚拟内存的思路把 KV Cache 切成固定大小的块block来管理。需要多少就申请多少块用完了就归还配合调度策略动态扩容。这个思路就是 vLLM 的 PagedAttention 的核心也是为什么同样的模型、同样的显卡vLLM 的吞吐量能比 Naive 实现高出好几倍的原因所在。后面讲实操时我会再展开。4. 为什么缓存的是 KV 而不是 QKVQ 为什么不能缓存4.1 Q、K、V 各自的角色差异这个问题几乎每次讲 KV Cache 都会被问到。要回答它得先想清楚 Query、Key、Value 在注意力机制里的分工。注意力机制的本质是检索Query 是“我当前想找什么”Key 是“每个历史位置的标签或索引”Value 是“每个历史位置实际存储的内容”。计算过程是拿 Query 去和所有 Key 做相似度比较得到注意力权重再用权重对 Value 做加权求和。在 Decode 阶段新生成的 token 作为新的 Query 出现它的 Q 是全新的、之前从未算过的所以必须实时计算。而它也会产生自己的 K 和 V追加到历史缓存里。问题在于历史 token 的 Q 在它们作为当前 token 时已经用过一次了后续生成新 token 时历史 Q 永远没有再被使用的机会因为后续步骤只关心“新 Query 和所有历史 Key 的匹配”而不是“历史 Query 和新 Key 的匹配”。既然用不到缓存它就是纯浪费显存。换个方式说每一步注意力计算中Query 只有一个来源——当前这一步正在生成的 token而 Key 和 Value 有 n 个来源——所有历史 token。所以 Query 最多“活”一步而 Key 和 Value 要“活”完整条序列的生成周期。这是一个不对称的关系缓存自然倾向于保活时间长的那些数据。4.2 如果缓存了 Q 会怎样假设我们“死不悔改”地把 Q 也缓存了会发生什么第一显存占用直接变成原来的 1.5 倍。还是拿 Llama 3.1 8B 8K 上下文来算KV Cache 大约 1GB如果是 QKV Cache 就是 1.5GB。看起来不多但换到 128K 上下文就从 8GB 涨到 12GB对本来就已经捉襟见肘的显存来说是雪上加霜。第二缓存 Q 完全没有收益。历史 Q 在整个后续解码过程中不参与任何计算存了也是一堆“死数据”还要额外消耗显存带宽去维护和管理属于纯粹的负优化。第三从工程实现的角度缓存 Q 还会让显存管理的逻辑复杂化。每一步都要把新 Q 写进缓存、又永远读不出来这种“只写不读”的结构在显存调度上是个灾难会白白占用 block 空间降低有效吞吐。所以结论很明确缓存 Q 没有任何计算上的必要性只会增加显存压力和工程复杂度。KV Cache 这个名字是经过实际推理推敲后留下的最佳设计不是拍脑袋定的。4.3 Group Query AttentionGQA和 Multi-Query AttentionMQA顺着 KV Cache 的话题就绕不开 GQA 和 MQA。这两个机制最大的动机之一就是压缩 KV Cache 的体积让显存占用降下来。MQAMulti-Query Attention所有 Query 头共享同一组 K、V相当于 KV 头数为 1。KV Cache 直接缩减到原来的 1/head 数但模型表达能力会有损失质量略微下降。GQAGrouped-Query Attention把 Query 头分成若干组每组共享一组 K、V。比如 Llama 3 系列是 32 个 Query 头、8 个 KV 头每 4 个 Query 头共用 1 组 KV。KV Cache 缩小到原来的 1/4模型质量损失极小。现在新发布的模型尤其是长上下文模型基本都会用 GQA。用 8B 模型举例如果有 GQAKV Cache 只有普通 MHAMulti-Head Attention) 方案的 1/4在长上下文场景下这是决定能不能跑得动的关键差异。5. Lost in the Middle 与 KV Cache 的关系长上下文的另一道坎5.1 为什么长上下文模型会“忘记”中间内容很多人在实际使用长上下文模型时发现一个诡异的现象你给它一段很长的资料放在开头和结尾的信息它能记住放在中间的却经常被忽略。这就是著名的 Lost in the Middle 现象业界叫“迷失在中间”。根源在于注意力分布的不平衡。模型在处理序列时对开头的 token 往往会给予较高的注意力权重因为它们是“初始上下文”模型会投入更多的注意力去理解基础设定对结尾的 token 也会比较关注因为距离当前生成位置最近位置编码的关联度更高。而中间部分的 token注意力权重往往被摊薄信息的“地位”变低。这个现象和 KV Cache 有密切关系吗这里要分清楚两件事KV Cache 本身只是缓存不改变注意力的计算逻辑和权重分布但 KV Cache 的存在让长上下文推理在工程上变得“可行”而这个可行反过来把注意力分布的问题暴露了出来。也就是说没有 KV Cache 的显存优化128K 上下文根本跑不起来Lost in Middle 也没机会被发现。KV Cache 是让长上下文“能用”Lost in Middle 是让长上下文“用得好不好”的问题。5.2 从位置编码看 KV Cache 对位置信息的影响Lost in the Middle 还有一个技术层面的因素就是位置编码。现代大模型普遍使用 RoPE旋转位置编码通过在 Key 和 Query 上注入相对位置信息把 token 的顺序关系编码进注意力计算。正是因为 KV Cache 保存的是注入位置编码后的 K、V而新的 Q 自带新位置信息两者的相对位置才能被正确计算。如果位置编码处理不当或者 KV Cache 在跨请求复用、缓存拼接时没有把位置信息同步处理好就会出大问题。比如你做 Prompt Cache 时如果缓存了某段文本的 KV却被用在了一个位置完全不同的新 prompt 里位置编码的错位会让注意力计算结果面目全非。这也是为什么工程上做 KV Cache 复用必须精确管理每个 token 的位置偏移。5.3 缓解 Lost in Middle 的常见手段业界针对 Lost in the Middle 做了很多尝试这里列几个实际可用的一是增强输入结构。把最核心的内容放在 prompt 的开头或结尾中间的填充内容尽量控制长度。这是成本最低、见效最快的方法也是为什么很多提示词工程教程建议“关键指令前置、总结内容后置”。二是引入注意力强化机制。部分模型在训练时做注意力正则化显式让模型对输入序列中段分配更多注意力权重或者使用滑动窗口注意力与全局注意力的混合结构。三是分段检索。不把整篇长文一股脑塞给模型而是先做向量检索只把最相关的片段送进去。这样既减少 KV Cache 压力又避开中间位置的注意力衰减问题。这也是 RAG检索增强生成架构在长文档场景下如此流行的原因之一。根据我自己的实测跑 32K 上下文时把关键数据放在离结尾 2000 token 以内模型提取的准确率比放在中段高出 20 到 30 个百分点。这个差距相当可观。6. Prompt Cache、Prefix Cache 到底是什么不止是推理阶段的 KV 缓存6.1 三层缓存KV Cache 只是最底下的一层聊到 Prompt Cache 和 Prefix Cache 之前得先说清楚一个常见的混淆点KV Cache 是指在单次请求的内部模型生成过程中自动保存的 Key、Value而 Prefix Cache 或 Prompt Cache 通常指的是跨请求之间的 KV 缓存复用。举个例子很多 AI 应用有固定的系统提示词System Prompt比如“你是一个擅长代码审查的助手请根据以下规则……”。这个系统提示词对每个用户请求都是完全相同的。如果每个请求到达时都从头对这段系统提示词做 Prefill 计算那就是成百上千次重复劳动。Prefix Cache 的思想很简单把公共前缀部分系统提示词、Few-shot 示例、固定指令的 KV 算好存起来新的请求来了直接复用这部分 KV只需要对用户输入的部分做 Prefill。这在大型服务里的收益极明显。比如一个请求的平均长度是 4K token其中 2K 是系统提示词那通过 Prefix Cache 可以省掉接近一半的 Prefill 算力。而 Prefill 阶段恰恰是服务端最吃算力的环节省下的算力可以直接转化为更高的并发吞吐量。6.2 Prefix Cache 的实现关键缓存命中的粒度与调度Prefix Cache 不是把整段字符串做哈希比对那么简单。它是基于 token 序列做前缀匹配的——从左到右逐 token 比对命中的 token 越多能复用的 KV 就越多。但 prompt 千变万化可能用户输入一改动前缀就断了命中的片段就不完整。工程实现上有两个关键点一是缓存粒度。按完整的 prefix 段缓存比如一条系统提示词作为整体命中率高、管理成本低按 token 级别的碎片缓存命中灵活能最大化复用但管理复杂。目前主流方案类似 vLLM 的 Prefix Caching 机制它把 KV Cache 按块block存储并做哈希表索引新请求的 token 块哈希命中就直接复用对应显存数据。二是缓存淘汰策略。显存是有限的缓存不可能无限增长。业界常用 LRULeast Recently Used策略长时间没被命中的缓存块先被淘汰。还要注意Prompt Cache 管理不当会出现缓存污染比如某个用户注入了一段奇怪的 prompt 导致公共前缀的 KV 被污染后续请求全部受到影响。我建议做 To B 部署的团队Prompt Cache 一定要结合实际的 prompt 分布来设计。如果业务里的 prompt 有大量重复前缀比如客服机器人、代码助手、文档总结收益巨大如果每个请求都是完全个性化的长文本Prefix Cache 的意义就小得多不如直接上更激进的 KV Cache offload 策略。6.3 不同缓存层级对最终效果的影响这里可以把整个缓存体系串起来看Token 级 KV Cache解决单次请求内部重复计算的问题是所有自回归推理的基础。Prefix/Prompt Cache解决跨请求公共前缀重复计算的问题提升服务吞吐。系统级 Cache在更上层做语义缓存比如短时间窗口内完全相同的请求直接返回历史结果完全不跑模型。这三层可以叠加。实际部署中先做 Token 级 KV Cache框架自带再按业务情况做 Prefix Cache最后视场景考虑语义缓存。每一层省下的都是实实在在的 GPU 时间和电费。7. 实操环节KV Cache 相关的优化方案与实际部署建议7.1 显存优化三板斧GQA、量化、KV offload实际部署时KV Cache 最大的敌人是显存。我按投入产出比排序讲三个最常用的手段。先说模型本身的 KV 头压缩。如果模型支持 GQA那恭喜你KV Cache 已经比 MHA 架构小了好几倍。如果模型是 MHA 架构可以通过推理框架的转换工具改造成 GQA 模式部分框架已支持但要小心精度损失需要评估业务场景是否可接受。第二是 KV Cache 量化。KV Cache 默认是 FP16/BF16也就是每个值占 2 字节。但如果用 INT8 量化立刻减半用 INT4 量化再减半。市场上主流推理框架如 vLLM、TensorRT-LLM都支持 KV Cache 量化。我实测跑 Llama 3.1 8B 的 8K 上下文KV Cache 用 INT8 量化后显存占用从约 1GB 降到 0.5GB困惑度PPL变化几乎可以忽略。INT4 的收益更大但有些任务上会有肉眼可见的质量下降尤其在数学推理、代码生成这类对 token 级精度敏感的场景谨慎使用。第三是 KV Cache Offload把暂时不参与计算的 KV Cache 从 GPU 显存搬到 CPU 内存用到时再搬回来或者直接在 CPU 上计算。这个方案适合长上下文但交互性要求不高的场景比如离线批量处理、文档总结。代价是生成速度明显变慢因为每次都要做跨设备数据传输PCIe 带宽和内存带宽成了新瓶颈。7.2 推理框架选型vLLM、TensorRT-LLM、llama.cpp 的 KV Cache 处理差异不同框架对 KV Cache 的工程处理策略差距很大这里列一个简表框架KV Cache 管理方式特点与适用场景vLLMPagedAttention 块式管理 Prefix Caching高并发、长上下文在线服务显存利用率高TensorRT-LLM静态/动态 KV Cache 规划支持 KV 量化与 Inflight Batching追求极致吞吐适合企业级 GPU 集群llama.cpp简单线性 KV Cache支持 offload 到 CPU/Metal单机推理、嵌入式设备、个人本地部署Hugging Face Transformers原生线性 KV Cache无高级调度适合实验和调试不适合高并发生产我个人在本地单卡部署时建议用 llama.cpp 系列包括 Ollama它开箱即用对 KV Cache 的 offload 支持做得很成熟。企业级并发服务则建议 vLLMPagedAttention 在长上下文场景下的显存节省非常明显——它只申请实际用到的块不像 Naive 实现那样一次性按最大长度预分配。7.3 实操心得跑长上下文时的显存规划建议最后分享几条我踩过坑之后沉淀下来的实操经验第一预估显存时别只算权重。很多人部署 7B 模型以为 16GB 显存绰绰有余结果跑 32K 上下文直接 OOM。正确做法是用上面的公式把所有项的显存都列出来权重≈2 字节 × 参数量、KV Cache、激活值通常 1 到 2GB、CUDA context约 500MB 到 1GB。留出 20% 的余量才是靠谱的配置。第二上线前先做压测。写个脚本模拟业务场景里最长 prompt 和最长生成序列的情况跑一遍观察显存水位。不同框架的显存曲线差异很大压测结果是最可靠的。第三关掉不需要的功能。比如部分框架默认开启动态计算图、多设备分布式等特性实际用不到却占显存。部署时按需最小化配置能省不少资源。第四监控要精细。显存监控不能只看总使用量最好能区分权重、激活、KV Cache 各自的占用比例。vLLM 提供日志接口可以打印 KV Cache 的使用情况olama 则可以通过观察模型加载后的剩余显存间接估算。8. 常见问题与排错实录KV Cache 相关的典型事故8.1 问题速查表我把实际工作中遇到过的 KV Cache 相关问题整理成表格方便按图索骥问题描述根本原因排查与解决思路生成到一半显存 OOMKV Cache 随序列增长持续膨胀加上激活值波动降低最大生成长度、开启 KV Cache 量化、使用 GQA/offload生成长文本时速度越来越慢Decode 阶段 KV Cache 读取量随序列增长访存带宽瓶颈启用 GQA 压低 KV head 数、考虑 sliding window 注意力使用 Prefix Cache 后生成结果异常位置编码错位缓存 KV 和当前 prompt 的位置不匹配确认缓存命中时位置偏移是否正确处理禁用部分缓存对比测试同一 prompt 相同轮次结果不稳定缓存淘汰策略导致部分 KV 被换出推理结果依赖显存状态固定缓存策略、增大缓存池、关键服务使用专用缓存区并发请求时吞吐剧烈下降KV Cache 碎片化严重显存利用率低切换到块式管理框架vLLM、开启 PagedAttentionGPU 利用率低但推理慢Decode 阶段是访存瓶颈计算单元大量空闲增加 batch size 提升吞吐或改用对访存优化的 kernel8.2 一个典型的 OOM 案例复盘有一次我帮朋友配置一台 24GB 显存的机器跑 13B 模型准备支持 16K 上下文。按公式估算权重加 KV Cache 应该是 26GB 5GB明明超了但他非说框架能跑起来。结果一跑长文本不到 3K 就报 OOM。复盘后问题有三个一是模型不是 GQA 架构KV Cache 膨胀速度快二是框架默认未开启 KV Cache 量化白白多占了一倍显存三是加载模型时 CUDA context 和激活值占用了接近 2GB。综合优化后开启 INT8 KV Cache 量化、限制最大生成长度为 4K、把模型换成了 GQA 架构的版本最终 24GB 显存跑 16K 上下文压力很小。这个案例想说明一件事别只看模型参数量和显存总量KV Cache 激活值 框架开销往往才是压垮骆驼的最后一根稻草。部署前把每项都列出来算清楚能省很多头疼时间。8.3 调试 KV Cache 问题的小工具和日志定位 KV Cache 问题我有三个百试百灵的工具性做法一是看推理日志。vLLM 启动时会打印 KV Cache 的总量、块数量、块大小。对比不同配置下的日志输出能快速定位显存分配逻辑。二是用 PyTorch Profiler 或 Nsight Systems 跟踪显存申请曲线。这一步能直观看到每一步生成时显存的变化趋势判断是 KV Cache 膨胀还是激活值泄漏。三是最朴素的办法分段压测。从 2K 上下文开始每次翻倍跑一遍记录显存峰值。如果显存增长明显超过线性大概率是激活值、注意力矩阵中间结果或框架本身的动态分配出了问题而不是 KV Cache。9. 一点个人体会KV Cache 优化是理解和优化整个推理链路的钥匙关于 KV Cache 这个话题通过它能把大模型推理的很多关键环节串起来自回归机制、显存分级、Attention 架构设计MHA/GQA/MQA、长上下文的工程瓶颈、服务端吞吐优化。我自己的感受是理解了 KV Cache你就理解了大模型推理至少一半的显存开销从哪来、怎么省、瓶颈在哪。如果你刚入门建议先在自己的机器上用一个小模型3B 或 7B打开框架的 KV Cache 统计日志实际调一调上下文长度观察显存变化曲线。数据直观呈现出来的东西比任何公式都更容易留下深刻印象。等到你真正开始做企业级部署、面对几十上百并发请求的时候KV Cache 相关的这些细节会直接决定你的服务是“能跑”还是“能稳定高效地跑”。