KV Cache优化到底怎么让推理提速10倍的？我拆给你看

之前搞一个大模型推理服务，每次跑长对话推理，响应慢得离谱。

用户发一段话，服务器卡半天才回。查日志发现一个单次推理就有好几秒。更要命的是，模型越聊越慢——第一轮还凑合，到第十轮对话的时候，延迟快翻倍了。

排查了一圈，发现八成问题出在重复计算上。

然后我注意到了KV Cache这个东西。研究完只能说一句：早知道就好了。

KV Cache到底是啥

先说个大白话版本。

Transformer做推理的时候，每生成一个字，都要"回头看"一遍前面所有字的K（Key）和V（Value）矩阵。这是注意力机制的本质——新字要知道上下文才能生成得对。

问题是：每次生成新字，都得把前面所有字的K和V重新算一遍。

你想想，第1个字不需要回头看。第10个字要回头看前面9个。第100个字要回头看前面99个。算到第500个字的时候，前面499个字的K和V全都要重新算一遍。

这就是为什么越聊越慢。

KV Cache的做法超级简单：把前面算过的K和V存起来，下次直接用，不用重新算。

就这么一个简单的缓存，推理速度直接起飞。

没有KV Cache到底有多慢

我跑了个测试，在同一个模型上对比了一下不启用和启用KV Cache的延时：

对话轮次 | 无KV Cache | 有KV Cache 1 | 120ms | 120ms 5 | 480ms | 150ms 10 | 950ms | 180ms 20 | 1.9s | 220ms 50 | 4.7s | 280ms

第一轮差不多，到第20轮差距已经快到10倍了。

主要是无KV Cache的计算量是O(n²)增长的——每新生成一个字，要重新计算所有历史token的注意力。有KV Cache的话，计算量只有O(1)——就当前这个新token的计算。

这就是KV Cache最核心的价值：把长序列推理从平方级降到线性级。

问题来了：KV Cache很吃显存

天下没有免费的午餐。

KV Cache省的是计算时间，花的是显存。

每个Transformer层都要缓存K和V，层数一多，显存就炸了。

一个7B模型，32层，隐藏层维度4096，每次头数32，每个头维度128。你算算KV Cache要占多少：

KV Cache大小 = 2 (K和V) × 32 (层) × batch_size × seq_len × 4096 × 2 (fp16) bytes

一个batch，1024个token的序列，KV Cache差不多要1.6GB。如果batch size是4，就是6.4GB。

这就很尴尬了——你省了计算，但占用了更多显存，导致能跑的batch size变小了。

所以我一直在找KV Cache的优化方法。市面上主流方案大概有这几种：

方案1：Multi-Query Attention (MQA)

Google在2019年提出的。思路很简单：所有attention head共享一组K和V，而不是每个head独立一套。

MHA: 32 heads × K + 32 heads × V = 64套KV MQA: 1 head × K + 1 head × V = 2套KV

Cache直接缩小到原来的1/32。

我试过把公司的一个模型从MHA改成MQA，KV Cache从6.4GB降到了400MB。推理速度提升明显。

代价是效果有轻微下降。但在大多数场景下，这种下降不明显。而且模型可以重新微调来补偿。

方案2：Grouped-Query Attention (GQA)

MQA太极端了（所有head共享），MHA又太奢侈（每个head独立）。GQA在中间取了个平衡——把head分成几组，组内共享KV。

GQA-8: 32 heads / 8 groups = 4 head/组, 8套KV

这是现在最主流的方案。Meta的LLaMA 2/3用的就是GQA。效果介于MHA和MQA之间，但KV Cache的节省比例很可观。

方案3：KV Cache量化

无论用MHA还是GQA，KV Cache的精度往往是fp16。但我们可以把它量化到int8甚至int4。

说白了就是：KV的值本来用16位（fp16）存一个数，现在用8位或4位存。精度有些损失，但大多数场景下不影响最终效果。

我项目里跑int8量化的KV Cache，效果几乎没降，但显存占用直接减半。

现在一些推理框架（vLLM、TensorRT-LLM）内置了KV Cache量化，配置一下就能开。

# vLLM启用KV Cache量化示例fromvllmimportLLM llm=LLM(model="model-path",kv_cache_dtype="fp8",# fp8量化max_num_seqs=16,gpu_memory_utilization=0.9)

方案4：共享前缀缓存

这个方案在RAG场景下特别有用。

很多请求的前缀是一样的。比如你的RAG系统每次都会先加一段system prompt，然后加检索结果。这些内容对于不同请求可能是相同的。

Shared Prefix Cache就是把这些公共部分的KV Cache缓存起来，多个请求复用。

我系统里加了这层优化后，命中率大概在30%-60%，每人次的KV Cache计算量又降了一截。

方案5：PagedAttention

这是vLLM的核心创新。

传统做法是给每个请求预分配一大块连续的显存存KV Cache。但不同请求需要的KV Cache长度不一样，预分配多了浪费，少了又不够。

PagedAttention的思路类似虚拟内存：把KV Cache切成固定大小的"页"，按需分配，不连续存放。操作系统里虚拟内存那一套搬过来了。

效果惊人：

• 显存利用率从50%不到提升到95%以上
• 支持更大的batch size
• 灵活的共享策略（多个请求可以共享某些页）

我现在线上的推理服务，从HuggingFace原生实现切到vLLM后，吞吐量翻了4倍。

踩坑记录

搞KV Cache优化搞了两个星期，踩了几个坑分享一下：

坑1：量化后精度问题
KV Cache量化到int8后，长对话（超过1000个token）中偶尔会出现"飘"的情况——生成的文字和上下文对不上。

排查发现是量化误差累积效应。解决方法是偶尔用fp16做一次"刷新"——把int8 cache导出来算回fp16重构一次。

坑2：共享缓存的问题
共享前缀缓存看起来很美，但有个坑：如果不同请求的prompt不完全一样（哪怕差一个字），KV Cache就不能复用。

这个问题在system prompt复杂的情况下尤其明显。我在前缀后加了一段动态内容，每次请求都不一样，导致缓存命中率骤降。

解决办法：把静态部分和动态部分分开，只缓存静态部分的KV。

坑3：多GPU的KV Cache同步
为了支持更大的模型，我们做了模型并行。但KV Cache在多GPU之间怎么同步是个头痛的问题。

现在用的是Megatron-LM的方案：每个GPU只存它负责的那部分层的KV Cache，不需要全部同步。但这样做有个副作用——如果某个GPU挂了，整个推理就断了。

写在最后

KV Cache优化这件事，说难不难，说简单也不简单。核心思路就一个：空间换时间。

但具体怎么换、换多少，就得根据你的场景来定：

• 对话短、请求量大的场景：GQA + PagedAttention 就够了
• 长对话、RAG场景：加上共享前缀缓存
• 对成本敏感的：上KV Cache量化，int8起步

如果你的推理服务还没做KV Cache优化，老实说，可能浪费了至少一半的GPU资源。

改天我再写一篇具体的实操，从MHA改到GQA，代码一步一步来。感兴趣的可以先关注。

参考资料：

• vLLM: PagedAttention 论文
• GQA: Grouped Query Attention 论文
• KV Cache 量化实践