王杰岸1. 为什么GTC上大家都在谈KV Cache：一个被忽视的显存黑洞
先说个我自己的感受。2025年的GTC，满会场跑下来，我听到最多的不是“下一个GPT什么时候来”，也不是又发了多少亿参数的模型，而是三个字：KV Cache。这个词在NVIDIA的演讲里出现了不下几十次，在各类workshop里更是被反复拿出来当典型案例讲，连做推理框架的、做硬件的、做MaaS平台的都在谈。
一开始我还有点纳闷，KV Cache这玩意儿不是早就有吗？Transformer架构火起来那会儿，它就在那儿了，怎么今年突然成了主角？
后来听了几场talk，又把几个技术分论坛的PPT翻了一遍，我才反应过来：大家不是在谈KV Cache本身，而是在谈KV Cache带来的显存危机，以及围绕这个危机展开的一整条产业链机会。
先说一个最基本的账。现在跑一个大模型推理服务，你的GPU显存大致分三块：模型权重、KV Cache、以及中间激活值。很多人直觉上觉得模型权重是大头，一个大模型动不动几百GB，KV Cache能占多少？但实际情况是，当你的并发请求量上来之后，KV Cache吃掉的显存会迅速超过模型权重。
我见过一个实际部署案例，一个基于Llama架构的7B模型，权重差不多14GB左右，用FP16存储，看起来不吓人吧？但如果你的在线服务需要同时处理几十个用户请求，每个请求的上下文长度在几千到上万token之间，KV Cache轻松冲到几十GB。换到更大的70B模型，权重就上百GB了，再加上并发用户的KV Cache，一块80GB的H100根本不够看，直接把你逼到多卡并行加各种优化措施上去。
所以GTC上那些演讲者们反复强调一个判断：推理成本的核心瓶颈，正在从算力转向显存带宽和容量。 而这个瓶颈，恰恰是被KV Cache放大的。理解了这一点，你就能看懂GTC 2025上为什么那么多演讲都围绕着KV Cache的量化、稀疏化、动态管理、以及新一代硬件架构来展开。
这里也想给刚开始接触推理优化的朋友提个醒：如果你的应用场景是单用户、低并发的离线推理，KV Cache可能还没给你造成什么困扰。但只要是做在线服务、做Agent类应用、做长上下文处理，KV Cache就是你绕不开的课题。这篇文章我就把GTC上关于KV Cache的核心观点、技术路线和工程实践，结合我自己的一些实操经验，尽量讲透。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. KV Cache到底做了什么：从Attention机制拆到工程实现
2.1 一次前向计算里，Key和Value为什么“舍不得扔”
要搞懂KV Cache为什么这么重要，得先回到Transformer的Attention机制里去看它到底在算什么。
你可以把Attention机制理解成一个检索过程。模型在处理当前token时，需要回过头去“看”之前的所有token，然后决定对哪个词更关注。这个“看”的动作，通过计算当前token的Query（查询向量）和之前所有token的Key（键向量）的相似度来完成，再用相似度作为权重，去加权求和之前token的Value（值向量），得到当前token的输出。
这个过程中，之前所有token的Key和Value，就是你在推理阶段反复用到的东西。
如果你写过一个最简单的Transformer推理代码，你会发现一种很笨的做法：生成每一个新token时，都把之前所有token重新跑一遍完整的Attention计算。这当然能得出正确结果，但代价是你把一个已经算过的结果反复重算了一遍又一遍。对于学术实验或者小规模demo来说无所谓，但在生产环境里，生成几百个token就意味着把前向计算重复几百次，时间复杂度直接爆炸。
于是大家想到了缓存。既然之前的token对应的Key和Value在生成本轮token时并没有改变，那我可以把它们存下来，下次直接用，不用重新算。这个缓存，就是KV Cache。
从短期看，这个缓存每增加一个新token，就往里追加一份新的Key和Value。所以如果你的输入是几千个token的上下文，那么第一次推理时你就要计算并缓存几千个Key和Value；之后每生成一个token，再追加一组。上下文越长，KV Cache越大，增长得还非常快。
2.2 工程视角：KV Cache怎么存储、怎么增长、怎么清理
从工程实现上来说，KV Cache的内存布局和生命周期管理，比理论描述要复杂得多。
首先，KV Cache不是一个单独的数组，而是按照模型层数、注意力头数、序列长度三个维度组织起来的。你可以把它想象成一个三维矩阵，每一层有自己独立的缓存，每一层的缓存又分多个注意力头。假设一个模型有32层、32个注意力头、隐层维度4096，那么每个token在该模型上的KV Cache大小就是：
2（Key和Value两份）x 32层 x 32头 x 当前已处理token数量 x 每头维度
这个数字如果展开来算，你很快就能感受到那种“指数级膨胀”的压力。
其次，KV Cache的内存不是一次分配好的，而是随着生成过程动态增长的。这意味着你在启动推理服务时，没法在初始化阶段就把显存完全分配好，而必须在每次生成新token时进行内存扩展。如果工程实现不好，就很容易出现频繁的显存碎片、频繁的重新分配，直接把性能拖垮。
我早期做过一个简单的推理Demo，用的还是PyTorch默认的KV Cache实现，结果并发一上来，显存碎片率到了30%，卡得不能用。后来换成了支持PagedAttention的服务框架，内存利用率才恢复正常。
最后，每个请求处理完之后，它的KV Cache怎么回收也是一个问题。你说简单清掉不就行了？但多路并发场景下，每个请求占用的KV Cache大小不一样，生命周期也不一样，如果管理不好，回收不及时，显存就会慢慢变成“漏水的桶”，跑着跑着就OOM了。
2.3 为什么说KV Cache是“变长的内存泄漏”
在社区里，大家经常把KV Cache比作“变长的内存泄漏”——虽然它不是真正的泄漏，但从显存占用的观感上说，它确实有一种“只增不减、越长越吃”的侵略性。
这一点的根源在于它的变长特性。传统的模型推理，输入输出形状在运行时基本是固定的，你可以在编译阶段就规划好显存分配。但KV Cache的大小和当前请求的上下文长度强绑定，而上下文长度又完全取决于用户输入和模型生成的token数，这就让显存规划变得非常困难。
想象一下，你在一个推理服务里同时跑了两个请求。一个请求只有几十个token的上下文，另一个请求生成了几万个token。前者的KV Cache只有几十MB，后者的KV Cache可能已经占了几个GB。如果没有一套好的动态调度机制，系统只能按照最大可能值去预留显存，那样的话资源利用率会低到令人发指。
所以GTC上那帮工程师反复强调一个概念：KV Cache管理本质上是一个动态显存调度问题，而不仅仅是一个算法优化问题。
3. 从GTC看KV Cache优化路线：几种主流思路的底层逻辑
3.1 KV Cache量化：用精度换容量的数学账
GTC上关于KV Cache量化的话题，几乎每一场系统优化相关的演讲都会提到。它的核心思路很直接：既然KV Cache太大，那我能不能用更少的bit去存它？
默认情况下，KV Cache用的是FP16，每个数值占2字节。如果你用INT8，每个数值只占1字节，KV Cache容量直接减半。如果你更进一步，用INT4，那容量直接降到原来的四分之一。
听上去很美好，但量化带来的精度损失是一个绕不开的问题。
这里有一个关键点：KV Cache量化和普通的模型权重量化不一样。模型权重是一次性的、静态的，你可以在离线阶段用各种手段去校准误差，甚至用高精度反向传播去补偿。但KV Cache是动态生成的，每生成一个token就要存一组新的值进去，你没办法做全局的误差补偿。
好在从GTC上的实验数据来看，KV Cache量化为INT8在绝大多数场景下精度损失是比较小的，尤其是在长上下文中，误差的累积效应并没有想象中那么严重。而INT4量化就需要非常小心了，在一些对数值敏感的任务上，比如数学推理、代码生成，精度下降会比较明显。
我的建议是：如果只是想把单卡并发顶上去，先从INT8量化开始试，结合后续的业务指标评估精度损失是否可接受。不要一上来就冲INT4，免得到时候出了问题还要花大量时间排查是不是量化精度导致的。
3.2 稀疏化与剪枝：不是所有Token都值得保留
另一个方向是稀疏化。这个思路的核心洞察是：Attention机制中，并不是所有历史token对当前token的贡献都是同等重要的。有些token在计算Attention分数时权重极低，几乎是可有可无的存在。
如果能在不显著影响生成质量的前提下，把那些低权重token的Key和Value从缓存中剔除掉，那KV Cache的大小就能大幅压缩。
这类方法的代表是H2O（Heavy-Hitter Oracle）这类基于Token重要性的剪枝策略。它维护一个token重要度评分，每次都优先保留那些在过去多次Attention计算中权重较高的token，把低重要度的token从缓存中踢出去。
从GTC的演讲来看，这类方法在实践中已经能做到在保持95%以上生成质量的同时，把KV Cache压缩到原来的五分之一甚至更低。但它的一个潜在风险是：你在“踢”掉某些token的KV Cache时，其实是在让模型“遗忘”一部分上下文。如果用户后续的问题恰好需要这部分被遗忘的信息，那么回答质量就会打折扣。
所以在实际应用里，稀疏化一般不是单独使用的，而是和量化、以及下面的动态管理策略组合在一起，做成一个多级优化管线。
3.3 PagedAttention：让显存像操作系统一样管理页
如果说量化和稀疏化是从KV Cache“内容”上做文章，那么PagedAttention就是从“存储布局”上做文章。
这个思路来自vLLM项目，在GTC上也经常被当作工程架构层面的典型案例来引用。它的灵感来自操作系统的虚拟内存分页机制。传统方式为每个请求预分配连续显存，但请求长度是动态的，预分配多了浪费，少了要重新分配，效率很低。PagedAttention把KV Cache切成固定大小的“页”，允许一个请求的KV Cache分散在多个不连续的页中，通过一个页表来索引。
这种方式的好处非常明显：
- 显存利用率大幅提升，因为没有必要按最大长度预留空间
- 多个请求之间可以实现显存的“共享”，比如做并行采样时，多个输出分支可以共用同一个输入前缀的KV Cache
- 减少了显存分配和释放的开销，因为页的大小是固定的，可以做预先池化
我自己的实测中，用PagedAttention做显存管理，显存利用率比之前用连续内存分配的方式高了将近一倍。这不是一个夸张的说法，因为之前预分配的浪费确实太严重了。
3.4 更极端的方向：无Cache推理与推测解码
如果上面这些还不够，GTC上还有一些更激进的方向，比如无KV Cache推理。这类方法试图通过改造Attention计算方式，让模型在推理时不缓存或者少缓存历史状态。
你可能听说过基于线性Attention的模型架构，它能将Attention的复杂度从二次方降到线性，从而从根源上规避KV Cache的快速增长问题。不过这类架构在模型质量上目前还没法和主流的Transformer架构正面PK，所以短期内还难以成为主流。
另一个方向是推测解码（Speculative Decoding）。它和KV Cache的关系比较间接，但目标一致：降低推理延迟。它的思路是先用一个小一点的草稿模型去猜测多个后续token，然后用大模型一次验证，这样可以把原来需要串行生成的多个token变成一次前向计算。虽然它不直接减小KV Cache的大小，但因为减少了前向计算次数，KV Cache的访问次数也会相应减少，间接减轻了显存的带宽压力。
4. 落到自己项目里：KV Cache优化要怎么做决策
4.1 先量化自己的“缓存画像”
聊了这么多方案，我知道大家最关心的还是那句话：我该怎么做？
做任何优化之前，我强烈建议先做一个动作——算清楚自己项目的“KV Cache画像”。所谓画像，就是你的推理服务在不同并发、不同上下文长度下，KV Cache到底占了多少显存。
这里有个快速估算的公式：
KV Cache显存 = 2（K和V）x 层数 x 隐层维度 x 精度字节数 x 最大序列长度 x 最大并发数
举个例子。你的模型是32层、隐层维度4096，用FP16存储，最大序列长度8192，最大并发32。那么KV Cache最大占用就是：
2 x 32 x 4096 x 2 x 8192 x 32 = 549,755,813,888字节，约512GB
看到这个数字，你应该就能理解为什么GTC上那么多演讲都在讨论KV Cache优化了。你还没算模型权重呢，KV Cache就已经撑爆了GPU。
根据这个画像，你就能判断自己最紧缺的资源到底是什么：
- 如果KV Cache占显存比重很低，那优化KV Cache的收益就有限，优先去看计算优化
- 如果KV Cache占比超过30%，就有必要上量化或PagedAttention
- 如果KV Cache占比超过50%，那稀疏化甚至是架构层面的改动，可能都要纳入考虑
4.2 优化前后必看的三个指标
做任何优化，都得有评估标准。KV Cache优化这块，我日常盯这三个指标：
第一个是显存占用。这个最直观，看推理服务运行稳定后KV Cache的峰值和均值。如果你在优化之后，同样的并发和上下文长度下显存峰值明显下降，说明优化的效果立竿见影。
第二个是P95首Token延迟。这是用户体验最敏感的指标之一。KV Cache优化如果影响了模型数值精度，可能会导致模型生成结果的分布漂移，首Token延迟可能会有波动。如果你的优化方案在减少显存的同时把首Token延迟也拉到了用户不可接受的范围，那这个优化就得重新评估。
第三个是端到端的生成质量。这个指标比较“软”，但恰恰是最不能忽视的。量化、稀疏化这些手段都可能在数值上带来微小变化，而这些变化累积起来，在长上下文的复杂任务上可能会放大成可见的质量差异。我习惯在优化前后各跑一批固定的评测集，对比关键任务的输出质量，再决定是否全面上这个方案。
4.3 我的实测经验与踩坑记录
最后分享几个我自己踩过的坑吧，都是真实经历，希望能帮大家少走弯路。
第一个坑是关于量化校准的。KV Cache量化虽然看着简单，但如果你只是简单地把缓存数据从FP16转成INT8，没有考虑当前输入的分布，很有可能会出现某些极端token的量化误差特别大，导致生成结果突然崩坏。后来我采用的是按层分组的动态量化，每一层根据自己的数值范围单独选择缩放系数，效果比全局量化稳得多。
第二个坑是稀疏化的“过早优化”。我曾经在一个短上下文的场景里强行上稀疏化，结果发现收益很小，反而是管理稀疏度的额外开销拖慢了整体速度。后来想明白了：稀疏化适合长上下文的场景，上下文太短的时候，KV Cache本来就不大，压缩空间有限。
第三个坑是关于显存预留的。分布式推理场景中，如果你的KV Cache优化方案只考虑了单卡，没有考虑多卡之间的负载均衡，很容易出现某一张卡因为KV Cache分配不均而OOM。这个问题在长上下文的场景下尤其明显。我的解决办法是引入基于KV Cache大小的动态负载均衡，而不是简单按token数分配。
说到底，KV Cache优化不是一个孤立的技术问题，它和你的模型架构、推理框架、部署环境、业务场景都强耦合。GTC上的那些最佳实践是别人踩过坑之后总结出来的路线图，但最终落地到你自己项目里，还是得靠一轮一轮的压力测试和质量评估来逼近最优解。
我在实际调优中最大的体会是：不要试图一次性把所有优化手段全部上齐，而是逐个开启、逐个对比，搞清楚每项优化手段在你这个场景里带来多少收益、付出多少代价。这样虽然慢一点，但每一步都站在数据上，不至于把系统调到“看似优化、实则失衡”的状态。