KV Cache 深度解析：大模型长上下文推理为何越聊越慢？-北京尧图网络

如果你最近用过带长文档阅读功能的AI助手大概率遇到过这个场景前几轮问答秒回但对话一旦超过几万字每生成一个字都像在挤牙膏有的平台甚至会直接提示上下文过长。很多人第一反应是模型能力不行或者网络变慢了但真正的原因藏在Transformer推理时一张看不见的缓存表——KV Cache里。这篇就专门把KV Cache这件事讲透。它是什么为什么AI会越聊越慢长上下文的成本到底花在哪了以及工程上常见的优化手段和我在实际部署中踩过的坑。适合正在做大模型推理部署的工程师、自己研究推理优化的开发者以及想了解长上下文为什么这么贵的产品和技术负责人。1. 先搞清楚越聊越慢的物理本质Transformer 生成时每一步都在干什么1.1 自回归生成的逐字逼供模式大语言模型的推理和普通人理解的看一遍问题直接给答案不一样。它实际上是一个自回归生成过程给定输入的前缀 token模型预测下一个 token 的概率分布选出一个 token 作为输出然后把输出追加到输入序列末尾再预测下一个。也就是说生成一句 500 个字的话模型要循环 500 次。每一次循环输入序列都比上一次多一个 token。如果模型长度上限是 128K理论上最极端的情况就是生成到第 128K 个 token。这个逐字逼供的模式是所有现象的原点。这里有个关键点每一次循环模型并不是把前面所有 token 重新读一遍然后重新思考模型的权重是固定不变的。真正参与计算的是当前序列里每个 token 经过层层变换后产生的中间向量。问题就出在这些中间向量上。1.2 注意力计算里的K和V到底在缓存什么Transformer 的每一层都包含注意力机制。注意力做的事情可以概括成三句话每个 token 生成一个查询向量 Q我要找什么所有 token 各有自己的键向量 K我是什么标签和值向量 V我携带什么内容。然后通过 Q 和所有 K 做匹配得到权重再用权重去加权求和所有 V得到输出。关键来了当模型生成第 N 个 token 时它需要回顾前面 N-1 个 token 的信息。按照注意力机制的定义它要用当前 token 的 Q去和前面所有 token 的 K 做点积再去加权它们的 V。如果没有缓存模型每次生成新 token 时都要把整个序列所有 token 重新经过一遍多层感知机和注意力计算把每一个历史 token 的 K、V 从头算出来——哪怕这些 K、V 和上一轮生成时算出来的结果一模一样。这相当于每次查资料都把所有书重新抄一遍。所以业界就引入了一个朴素且极其有效的设计把每一层注意力计算中所有历史 token 的 K 和 V 向量存下来下一次生成新 token 时直接读缓存只计算当前新 token 自己的 K、V以及它与历史 K、V 的注意力关系。这份缓存就是 KV Cache。这里面的 Q 不需要缓存因为 Q 只属于当前正在生成的 token用完即弃。而 K 和 V 是历史 token 留下的后面每个新 token 都要用到必须常驻显存。1.3 没有 KV Cache 的推理会慢到什么程度我见过不少刚接触推理优化的同学问不用缓存行不行答案是行但代价大到无法上线。我们来算一笔复杂度账。序列长度为 N如果不使用 KV Cache每生成一个新 token都要对全部 N 个 token 重新计算一遍 K 和 V再计算注意力。生成第 i 个 token 时累计计算量大约是 O(i)。整个生成过程下来总计算量是O(1) O(2) ... O(N) O(N²)如果用了 KV Cache历史 K、V 是直接读取的每生成一个新 token 只需要计算当前 token 的注意力单步复杂度是 O(N)因为要与 N 个历史 K 做点积。整个生成过程的总计算量是 O(N²) 里被压缩掉了一半的常数注意这里说的是半二次方——实际上仍然是平方级的只是把反复重算历史的浪费去掉了。用数字说话序列长度从 1K 变成 128K每次生成新 token 时需要读取并参与计算的历史 token 数量扩大了 128 倍。所以你会明显感觉到刚开始对话时生成速度飞快上下文越往后走每个字出的越慢。这不是错觉是计算模式决定的物理现实。KV Cache 的引入本质上是用显存换时间。但现实很残酷显存本身就是长上下文场景下最稀缺的资源。于是问题从要不要缓存变成了缓存空间从哪里来、如何让缓存容纳更长的上下文。2. 算一笔明白账长上下文的真实成本藏在哪里2.1 KV Cache 显存占用的标准公式很多人以为长上下文变贵是因为prompt 变长PreFill 阶段要算很多次但实际上真正持续吃显存的是 KV Cache。它有一个非常明确的计算公式显存占用 2K和V两份 × 层数 × KV头数 × 每个头的维度 × 序列长度 × batch大小 × 每个元素占用的字节数为什么每层都要缓存因为 Transformer 是深层的每一层的注意力都要用到历史 K、V所以每一层都有一份属于自己的 KV Cache。为什么 K 和 V 要分开算两份因为它们物理上就是两组不同向量不能省。以我常用的某个 7B 规模模型为例假设它的参数是 32 层、40 个 KV 头、每个头维度 128用 FP16每个元素 2 字节推理。单条序列、长度为 4096 时KV Cache 占用约2 × 32 × 40 × 128 × 4096 × 1 × 2 2,684,354,560 字节约 2.5GB一条 4K 上下文的请求就要吃掉 2.5GB 显存而模型权重本身不过 14GB 左右FP16 的 7B 参数。KV Cache 的体积已经非常可观。我把它扩展成一张直观的对比表30B 规模模型按 64 层、8 个 KV 头估算仅供参考模型规模层数KV头数序列长度单条请求KV Cache可同时容纳请求数80GB 显存7B级32404K约 2.5GB约 20 ~ 30 条7B级324032K约 20GB约 3 ~ 4 条7B级3240128K约 80GB约 1 条30B级648 (GQA)4K约 0.5GB约 80 ~ 100 条30B级648 (GQA)128K约 16GB约 3 ~ 5 条这张表清楚说明了三件事第一KV Cache 随序列长度线性增长但它在总显存里的占比增长速度远快于权重第二同样的显存下上下文越长同时服务的用户越少直接反映在成本上第三KV 头数对缓存体积的影响极大这也是后面讲 GQA 优化的意义所在。2.2 为什么说长上下文的价格曲线实际上是二次方的KV Cache 的显存是线性增长的但整个系统的感受成本不是线性的。第一个原因是 PreFill预填充阶段。当用户把一篇很长的文档交给模型时模型需要先一次性把整个 prompt 都过一遍这个阶段的计算量是 O(N) 的注意力。注意PreFill 阶段会为每个 token 生成 KV Cache之后随便一个用户回复都可能触发对整篇文档的注意力计算。第二个原因是 Decode解码阶段。我们前面说过每生成一个新 token都要和 KV Cache 里的所有 token 做注意力。序列越长单次解码的计算量就越大。也就是说输出的每一个 token 成本都在上涨整个过程累计下来就是 O(N²)。把这两个阶段结合起来就能理解为什么长上下文服务商的定价不是线性的。我见过有平台给 32K 上下文的定价是标准定价的好几倍不少人觉得不过是 8 倍上下文凭什么贵那么多。算算 KV Cache 显存和累计计算量这个定价逻辑其实是成立的。另外还有一个经常被忽略的点Batch 的放大效应。在线服务为了提升吞吐会把多条请求合并成 batch 一起计算。KV Cache 的大小是 batch 维度的直接乘法假设你想同时服务 8 个 128K 上下文请求显存需求立刻乘 8。所以上下文越长能拼进同一个 batch 的请求越少GPU 利用率越难看单次请求的机器成本就越高。2.3 标准多头注意力中的冗余每个头都在存一份K/V如果你仔细看过 KV Cache 公式会发现有一个因子是KV 头数。标准 Transformer 的 Multi-Head Attention 是每个注意力头都独立存一份 K 和 V。这带来一个隐含冗余K、V 的语义在很多头之间是高度重叠的。注意力头之所以多主要是为了让不同的头关注不同的关系模式Q 的多样性更重要而 K、V 承载的历史内容信息重复度其实很高。因此业界后来发展出 MQAMulti-Query Attention和 GQAGrouped-Query Attention这类结构让多个 Q 头共享同一组 K、V 头。从成本角度看这是对 KV Cache 最顶层的节流。后面专节讨论先把账算清楚40 个 KV 头降到 8 个 GQA 头KV Cache 体积立刻变为原来的五分之一。同一个 80GB 显存实例从只能放 1 条 128K 请求变成能放 5 条吞吐和单位成本就完全不一样了。3. 从工程视角看KV Cache 的分配、理解与复用中的几个关键矛盾3.1 预填充阶段与解码阶段两种完全不同的资源压力很多人把推理过程简单理解为输入一堆字输出一堆字但工程上必须把这两个阶段分开看因为它们对 KV Cache 的压力模式完全不同。PreFill预填充阶段处理用户输入的 prompt一次性计算所有输入 token 的 K、V 并写入缓存。这个阶段是计算密集型的并行度很高因为 N 个 token 可以同时过矩阵运算。它的延迟指标叫 TTFTTime To First Token首 token 延迟。长文档场景下TTFT 主要花在 Attention 的 O(N²) 计算上和 KV Cache 显存关系不是最大。Decode解码阶段逐 token 生成输出。每个新 token 都要访问 KV Cache 中的全部历史 K、V这个阶段是访存密集型的。核心瓶颈不是浮点运算量而是显存带宽——因为计算当前 token 的 Q 和所有历史 K 的点积需要的 K 向量总量巨大要从显存里搬出来。序列越长搬运的数据越多生成越慢。它的延迟指标叫 TPOTTime Per Output Token。理解了这两种压力你就会明白为什么长上下文服务不能简单用加 GPU解决。加更多的 GPU 可以提升并行算力但 KV Cache 的带宽瓶颈依然存在。这也是为什么业界会专门设计稀疏注意力、分页存储等手段。3.2 显存碎片与动态长度预分配策略为什么浪费巨大工程里最容易被人忽视的坑是KV Cache 不是一块连续、固定大小的显存而是随着生成过程动态增长的。一个请求在 PreFill 阶段写入的缓存长度等于 prompt 长度。进入 Decode 之后每生成一个 tokenKV Cache 就变长一点。在线系统通常不会为每个请求精确分配刚好够用的显存因为那样每生成一个 token 都要做一次显存分配太慢。常见的做法是预分配一个最大长度空间比如按模型上下文上限预留。这会导致什么问题如果上线时按最大序列长度预分配实际用户的平均请求长度往往远达不到上限显存利用率可能只有 30%~50%。如果按请求的实际长度动态扩容又面临频繁内存分配的碎片问题甚至可能因为显存不足触发重新分配直接影响服务稳定性。业界目前的通行解法是分页式显存管理思想把 KV Cache 逻辑上按固定大小的块Page管理物理上分散存储在显存的不同区域逻辑上通过索引串成连续序列。新 token 只需要追加一个 Page不用为整个请求找一块连续大内存。这个思路其实和操作系统管理进程内存页一模一样——谁说大模型推理的显存管理和操作系统没血缘关系。我自己的经验是如果推理框架不支持分页管理建议直接在配置里把显存预留分成几层水位线。比如给 max 长度打七折作为初始预留水位超过后触发动态扩展。虽然不如分页精细但至少能避免 80% 的碎片浪费。3.3 前缀复用与多轮对话缓存不是只能给单条请求用KV Cache 有一个非常实用的工程技巧前缀复用。如果多个请求都共享同样的开头比如系统提示词、固定的角色设定、论文文档的全文那么这部分 token 的 KV Cache 是可以跨请求复用的。多轮对话的每一轮其实都是完整历史新问句。如果服务端保存了上一轮对话生成的 KV Cache下一轮就不需要重新 PreFill 整个对话历史只需要计算新增部分。这也是为什么很多对话产品能做到多轮之后依然响应较快的原因之一——不是它们不缓存而是它们把 KV Cache 留在了显存里。但这里有个边界条件很容易被忽略前缀必须逐字节一致才能复用。只要 prompt 最前面变了一个 token——哪怕只是加了一个空格或改了一句系统提示——前缀后面的所有缓存全部失效模型必须从头算。所以提示词版本管理、系统提示词动态拼接对 KV Cache 命中率影响极大。我在实践中见过一个场景某业务方为了 A/B 测试在每条请求开头的系统提示词里拼了一个随机参数导致所有缓存全部失效GPT 级别的推理吞吐直接掉了一半。后来把随机参数挪到请求尾部问题立刻消失。这种收益不需要改模型只需要改 prompt 的组织方式。4. 长上下文场景实测与调优先学会算账再谈优化4.1 上线前算账模板给定参数先估算缓存体积我在做推理服务性能评估的时候第一步永远是算 KV Cache 账而不是直接压测。给一个可以直接抄的估算脚本Pythondef estimate_kv_cache_gb( layers32, kv_heads8, head_dim128, seq_len4096, batch1, dtype_bytes2, ): # 2: K和V各一份 total_bytes ( 2 * layers * kv_heads * head_dim * seq_len * batch * dtype_bytes ) return total_bytes / (1024**3) print(estimate_kv_cache_gb(seq_len4096)) # GQA 8头 print(estimate_kv_cache_gb(seq_len32768)) # GQA 8头 print(estimate_kv_cache_gb(seq_len131072)) # GQA 8头这只是缓存体积。要把这一项加进总显存评估才是真实可上线容量。总显存需求模型权重 KV Cache 中间激活值冗余余量。模型权重按参数量 × 每参数字节数来算比如 7B 模型 FP16 大约是 14GB激活值在长序列下也不能忽略通常给权重同等大小的余量比较稳。4.2 一组典型实测序列长度对延迟和吞吐的影响我之前在一台 80GB 显存实例上对比过同一个 7B 规模模型在不同上下文长度下的表现GQA 8 头FP16 权重数据大概如下序列长度单条KV Cache单条请求TPOT同批可并发数有效吞吐token/s4K约 0.8GB约 20ms高最高16K约 3.2GB约 35ms中下降明显64K约 12.8GB约 85ms低很低128K约 25.6GB约 150ms基本只能单条极低这里有个反直觉的结论上下文越长单条生成延迟上涨还不算最可怕的最可怕的是并发度坍塌。4K 场景下能同时跑十几条请求GPU 的算力被充分复用单 token 成本极低。到了 128K 场景显存只够放一条GPU 算力大量闲置但你还得为这条请求付整卡的成本。所以业务方如果跟我说我们要支持 128K 上下文我第一反应不是模型支不支持而是你有多少用户真的一上来就跑满 128K有没有可能 95% 的请求实际上下文只有 8K与其所有请求都按最高规格设计不如做分级策略短上下文用户走默认通道长上下文用户走专门的显存配额。4.3 监控什么指标别只盯着显存占用率做长上下文调优光看 nvidia-smi 的显存利用率是不够的因为它只告诉你显存被占了没告诉你缓存的收益是多少。我建议至少监控这几个指标TTFT首 token 延迟反映 PreFill 阶段的计算压力。长 prompt 时 TTFT 暴增优先看 Attention 计算优化和前缀复用而不是加 KV Cache 容量。TPOT每个输出 token 的延迟反映解码阶段的访存压力。如果 TPOT 随序列长度线性上涨说明带宽已经吃满可以考虑 KV Cache 量化或减少 KV 头。吞吐 / 并发度同一显存下能并行跑多少条请求这是衡量成本效率的关键。并发度从 10 掉到 2意味着单位 token 成本涨了 5 倍。KV Cache 命中率 / 前缀复用率注意预处理阶段和缓存复用是两回事。如果命中率低说明系统提示词组织或前缀管理出了问题修好它能立刻提升吞吐。我建议直接在监控面板里把平均请求长度和KV Cache 命中率两个指标放在最显眼位置。这两个指标能提前预警绝大多数长上下文性能问题比等到用户报障再查日志高效得多。4.4 调优优先级清单什么先做什么后做下面的顺序是我在实际部署中验证过性价比的模型层优先确认是否用了 GQA/MQA。如果还在用标准 MHA 且改模型可行这是所有优化里投资回报率最高的。KV 头数差 5 倍等于显存直接差 5 倍。精度层KV Cache 量化FP8/INT8能减少一半甚至更多缓存体积但对质量有一定影响需要做评测验证。工程层分页显存管理和前缀复用不改变模型只改变显存使用效率收益也很大。调度层上下文分级、请求排队策略避免少数超长请求把整张卡的资源打爆。算法层滑动窗口、稀疏注意力、token 淘汰这些会改变模型行为要谨慎评估质量损失。5. 把成本从O(N²)拉下来的几个主要技术方向5.1 GQA/MQA让多个Q头共享同一份K/V前面已经提到 GQA 的结构改进这里展开说原理。标准 MHA 中每组 Q、K、V 都是独立的一个头。设模型有 H 个 Q 头就有 H 个 K/V 头。GQA 的做法是引入分组数 G让 G 个 Q 头共享同一个 K/V 头KV 头数量变成 H/G。MQA 是 GQA 的极端版本所有 Q 头共享单组 K/V。为什么这能大幅降低 KV Cache 体积因为缓存体积直接乘在KV 头数上KV 头数降几倍缓存体积就降几倍。同时解码阶段的访存需求量也降几倍TPOT 也跟着降。代价是模型表达能力可能下降。但大量实验和线上实践表明把 KV 头数从 40 压到 8质量损失通常很小而推理成本收益非常大。这也是现在很多新模型默认采用 GQA 的原因。如果你在选型模型我强烈建议优先选 GQA 结构的模型尤其是有长上下文需求的场景。5.2 KV Cache 量化用 FP8/INT8 存储历史状态KV Cache 里存的 K、V 向量不一定需要高精度保存。开发中常见的做法是把缓存从 FP162 字节压到 FP81 字节甚至 INT8显存和带宽需求直接减半。量化 KV Cache 有种实现手法在写入缓存前做缩放per-channel 或 per-token把浮点数值映射到低精度范围读取时再用缩放因子还原。精度损失主要集中在它对长序列注意力的累积影响上具体损失有多大要实际评测。我的经验是 8 位量化在 7B 规模模型上通常还可以但 128K 超长上下文的尾部质量可能略有下降需要针对业务场景验证。比 KV 量化更进一步的做法是缓存压缩比如只保留有代表性的 token 表示丢弃冗余 token。但这属于改动模型行为的方案需要配合专门的训练或评估上线成本较高。5.3 滑动窗口和 Token 淘汰让缓存不是无限增长如果我们接受一个前提——模型不需要记住前文的每一个字那么 KV Cache 就不必无限增长。滑动窗口注意力就是这种思路的代表每个 token 只和最近 W 个历史 token 做注意力超过窗口的 KV Cache 直接丢弃。这种策略的收益非常直接缓存占用上限固定为 O(W)不再随序列总长度线性增长长上下文的内存压力瞬间消失。代价也很明确如果关键信息在窗口之外模型会失忆。所以滑动窗口一般用在最近上下文更重要的任务上比如代码补全、实时对话。还有一类更激进的 token 淘汰策略根据注意力得分或 token 的重要性主动丢弃一些历史 token 的 KV Cache。这类策略在长文档摘要等场景有不错效果但稳定性需要严格评测。毕竟遗忘是不可逆的token 被丢出去就再也不会被模型看到了。5.4 应用层策略长上下文不是越长越好最后一个方向可能和技术关系不大但我必须说不要把长上下文理解成万能药。很多产品把上下文长度当营销卖点结果用户在长文档里提问时模型后半段的注意力质量明显下降反而输出不如短上下文检索好用。真正适合超长上下文的场景往往是历史信息会被反复引用的对话、文档全局理解和长时间 Agent 任务。我本人处理长文档应用时第一选择仍是分段检索摘要压缩而不是无脑把整篇文档塞进上下文。KV Cache 成本低了几十倍回答质量反而更高。只有在需要模型严格引用全文细节、检索方案确实不够用的情况下才考虑直接给全文。最后说说我对 KV Cache 的个人体会用了这么多年 Transformer 推理我最大的感觉是KV Cache 不是一个可以忽略的技术细节它是长上下文成本的核心命门。早期做推理服务时我花了很多时间调批量大小和并发参数效果始终上不去后来一算 KV Cache 占用才发现瓶颈根本不在这。如果你打算在真实产品里支持长上下文建议从今天开始做三件事第一把 KV Cache 估算脚本接进容量规划流程任何模型上线前先算账第二监控面板上补上 TTFT、TPOT、并发度和缓存命中率用数据说话第三审视一下你的模型是否用了 GQA如果还在用标准 MHA这可能就是你和别人成本差距的最大来源。KV Cache 的优化空间还远没有见底。就在我写这篇内容的时候低精度缓存、缓存压缩、稀疏化这些方向还在快速迭代。但不管工具怎么变理解它的本质——用显存换时间用质量换成本——永远不会过时。遇到问题先回到这两个 trade-off 上想基本不会跑偏。

KV Cache 深度解析：大模型长上下文推理为何越聊越慢？

相关推荐

计算机导论C语言题库实操指南：从Word题干到可运行代码

OpenClaw 实战：用 Node.js 与 PowerShell 让 AI 直接操控 Windows 电脑

AI对话即入口：用TaoToken统一通道复现Radisson×Accenture的ChatGPT酒店预订范式

更多资讯

类模板偏特化完全指南：从语法到实战掌握编译期分派

CalculiX ccx-2.11开源CAE求解器编译与接触非线性实战指南

教学锚定的代码聚类：从形态分组到可解释的学情分析

实体验证分层设计：从if-else堆判断到可落地的校验体系

用 WebView2 给传统 Win32/C++ 程序补现代 UI：完整接入路径与踩坑复盘

PyTorch LSTM调制识别实战：RML2016-10a信号分类

今日更新

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？