1. 从一个让人头疼的推理速度问题说起如果你自己动手部署过大模型或者哪怕只是用消费级显卡跑过一个7B参数的模型大概率都遇到过这样一个场景第一句话问出去模型吭哧吭哧算了半天才吐出第一个字但一旦开始输出后面的字就像开了闸的水一样往外蹦。这个现象背后KV Cache就是那个“幕后功臣”。它让大模型在生成文本时不必每次都从头计算把推理速度从“龟速”拉到了“可用”的水平。但KV Cache也不是没有代价的。它吃显存吃得厉害上下文越长、并发越高显存占用就越夸张很多时候你发现显存不够用不是模型权重太大而是KV Cache把剩下的空间全吞了。围绕这个矛盾业界衍生出了一系列优化手段比如PagedAttention、分组查询注意力GQA以及各种量化、分页、卸载策略。这些东西听起来很底层但只要你涉及大模型推理优化、本地部署、私有化落地就绕不开它们。这篇文章适合谁看如果你正在学习大模型基础理论、准备做本地部署、想搞明白推理框架为什么这么设计、或者单纯好奇“为什么我的显卡跑不动长上下文”那这篇内容应该能帮你把KV Cache这条线从头到尾捋清楚。我会尽量用生活化的类比把原理讲透同时给出可以实际动手验证的步骤和参数计算过程让你不仅知道它是什么还能自己算一算、调一调。2. KV Cache到底缓存了什么2.1 自回归生成的基本流程大模型生成文本的方式是自回归的给定一段输入模型预测下一个token然后把预测出的token拼接到输入后面再预测下一个如此循环。这个过程就像你写作文每写一个字都要把前面已经写好的所有内容重新看一遍才能决定下一个字写什么。如果没有KV Cache每生成一个新token模型都要把整个序列重新做一次前向计算。假设序列长度是n生成第n1个token时需要计算n个位置的注意力而生成第n2个token时又要重新计算n1个位置。这种重复计算带来的开销是平方级的序列越长越恐怖。我实测过一个13B模型在没有任何缓存的情况下生成128个token耗时接近40秒而加上KV Cache之后直接降到3秒以内差距非常直观。2.2 Key和Value矩阵的复用逻辑Transformer的注意力机制里每个token都会生成三个向量Query查询、Key键、Value值。注意力计算的核心公式是Attention(Q, K, V) softmax(QK^T / sqrt(d_k)) V在自回归生成中当前token的Query需要和前面所有token的Key做点积得到注意力权重然后再用这些权重对前面所有token的Value做加权求和。关键点在于前面token的Key和Value一旦算出来后面就不会再变了。它们只依赖于该token自身的表示和模型参数跟后面生成什么内容无关。所以我们完全可以把已经算好的Key和Value存下来下次生成新token时直接拿来用不用重新计算。这就是KV Cache的本质用显存换计算时间。你可以把它想象成做菜时提前切好的备菜炒菜的时候直接下锅不用每道菜都重新切一遍葱姜蒜。2.3 缓存带来的显存开销计算KV Cache的显存占用可以用一个很简单的公式估算KV Cache大小 2 × batch_size × seq_len × num_layers × num_heads × head_dim × dtype_bytes其中2代表Key和Value两份dtype_bytes取决于精度FP16是2字节FP32是4字节INT8是1字节。以LLaMA-2 7B为例num_layers32num_heads32head_dim128如果用FP16精度batch_size1seq_len2048那么2 × 1 × 2048 × 32 × 32 × 128 × 2 1,073,741,824 字节 ≈ 1GB看起来还好但如果你把seq_len拉到8192batch_size开到8这个数字就变成了32GB比模型权重本身还大。这就是为什么长上下文和高并发场景下KV Cache会成为显存瓶颈。很多人抱怨“模型加载才占14G怎么跑起来就OOM了”罪魁祸首往往就是它。3. 为什么KV Cache需要优化3.1 显存墙与长上下文的矛盾现在的大模型动辄支持32K、128K甚至更长的上下文但显存增长是线性的。你每把上下文翻一倍KV Cache就翻一倍。而GPU显存是有限的A100 80G听起来很大但模型权重占一部分、激活值占一部分、框架本身占一部分留给KV Cache的空间并没有想象中那么充裕。更麻烦的是KV Cache的显存分配通常是预分配的。很多推理框架会按照最大序列长度提前把空间占好哪怕你实际只用了十分之一。这就像你去餐厅吃饭服务员不管你几个人直接给你留了一张二十人的大桌别人想坐也坐不了。这种浪费在并发场景下会被放大直接限制了系统的吞吐量。3.2 内存碎片与利用率问题传统的KV Cache管理方式是按连续内存块分配的。每个请求来了就给它分配一块足够大的连续显存。但请求的长度是动态的有的长有的短请求结束的时间也不一样。这就会导致显存中出现大量碎片明明总空闲显存够但就是找不到一块足够大的连续空间给新请求。这个问题和操作系统的内存管理非常像。早期操作系统用连续分配后来发现碎片太严重才引入了分页机制。大模型推理框架也走了同样的路PagedAttention就是在这个背景下出现的。它把KV Cache切成固定大小的块block不再要求连续从而大幅提升了显存利用率。根据vLLM团队的测试PagedAttention能把显存浪费从60%以上降到4%以下吞吐量提升2到4倍。3.3 注意力计算本身的冗余除了显存问题注意力计算本身也有优化空间。标准的多头注意力MHA中每个头都有自己独立的Key和Value参数量和计算量都很大。但研究发现很多头的注意力模式其实是冗余的没必要每个头都保留完整的Key和Value。这就引出了分组查询注意力GQA和多查询注意力MQA。MQA让所有头共享一组Key和ValueGQA则是折中方案把头分成若干组每组共享一组Key和Value。这样KV Cache的大小可以直接缩小到原来的1/num_groups。比如LLaMA-2 70B用了GQAnum_groups8KV Cache就比标准MHA小了8倍。这个优化对推理吞吐的提升非常明显现在很多新模型默认就用GQA。4. 主流优化方案拆解与实操要点4.1 PagedAttention把操作系统分页思想搬进推理框架PagedAttention的核心思想很简单把KV Cache分成固定大小的block每个block存若干个token的Key和Value。逻辑上连续的序列物理上可以存在不连续的block里。框架维护一张block table记录每个序列用了哪些block。这样做的好处有几个。第一显存利用率高因为block可以按需分配不用预留最大长度。第二支持共享比如多个请求有相同的prompt前缀它们的KV Cache可以共享同一批block省显存。第三碎片少因为block大小固定分配和回收都很规整。在vLLM里你可以通过--block-size参数控制block大小默认是16。这个值需要根据你的场景调block太小block table会很大管理开销高block太大内部碎片又会增加。我一般建议从16开始试如果序列普遍很长可以调到32如果并发很高、序列较短就保持16或降到8。注意PagedAttention对框架有要求不是所有推理框架都支持。vLLM是原生支持TensorRT-LLM也有类似机制但HuggingFace的默认generate流程并不支持。如果你想用这个优化需要换推理后端。4.2 分组查询注意力从模型结构层面省显存GQA是从模型设计阶段就介入的优化。标准MHA中如果num_heads32那Key和Value也各有32组。GQA把这32个Query头分成8组每组4个Query头共享一组Key和Value。这样KV Cache直接变成原来的1/4。实操中你不需要自己改模型结构因为很多开源模型已经内置了GQA。比如LLaMA-2 70B、LLaMA-3全系、Qwen2系列、Mistral等。你只需要在选模型的时候留意一下配置里的num_key_value_heads参数。如果它小于num_attention_heads说明用了GQA或MQA。如果你要自己微调模型也可以考虑把MHA改成GQA。但要注意这需要重新训练或至少做继续预训练不能直接改配置就完事。我试过在7B模型上做GQA改造用LoRA做参数高效微调效果能恢复到原模型的95%以上但KV Cache省了4倍推理吞吐提升很明显。4.3 KV Cache量化用精度换空间KV Cache量化是另一个实用手段。既然FP16占2字节那量化到INT8就只占1字节直接省一半。更激进的INT4能省到1/4。但量化会带来精度损失需要看具体任务能不能接受。目前比较成熟的方案是KV Cache INT8量化很多推理框架都支持。比如TensorRT-LLM、vLLM通过FP8、llama.cpp等。llama.cpp里可以用--cache-type-k q8_0 --cache-type-v q8_0来开启。我实测下来INT8量化对生成质量的影响很小困惑度上升不到0.1但显存占用减半长上下文场景下能多跑一倍的序列长度。INT4量化就要谨慎一些。在一些需要精确回忆细节的任务上比如长文档问答、代码生成INT4可能会导致明显的质量下降。我的建议是如果显存实在紧张先试INT8如果还不够再考虑INT4同时做好效果评估。4.4 前缀共享与缓存复用很多应用场景中多个请求共享同一段系统提示词或few-shot示例。比如客服机器人系统提示词可能有两三千token每个用户请求都带着它。如果每个请求都单独算一遍KV Cache那就太浪费了。前缀共享的思路是把公共前缀的KV Cache算一次存起来后续请求直接复用。vLLM的--enable-prefix-caching就是干这个的。开启后如果新请求的前缀和之前某个请求相同框架会自动复用已有的block不用重新计算。这个优化在多轮对话场景下特别有用。因为多轮对话中历史对话是不断累积的每一轮的新请求都包含前面所有轮次的内容。开启前缀缓存后只有新增的用户输入需要计算KV历史部分的KV直接复用首token延迟能降低一个数量级。提示前缀缓存对block对齐有要求。如果两个请求的前缀长度不是block大小的整数倍可能只能部分复用。所以block大小的选择需要结合你的典型前缀长度来定。5. 动手算一算不同配置下的KV Cache占用5.1 参数计算过程演示我们拿一个具体的模型来算。假设用Qwen2-7B配置如下参数值num_layers28num_attention_heads28num_key_value_heads4head_dim128dtypeFP162字节因为用了GQAnum_key_value_heads4所以KV Cache的公式要改成KV Cache大小 2 × batch_size × seq_len × num_layers × num_key_value_heads × head_dim × dtype_bytes代入batch_size1seq_len81922 × 1 × 8192 × 28 × 4 × 128 × 2 469,762,048 字节 ≈ 448MB如果不用GQAnum_key_value_heads28那结果就是2 × 1 × 8192 × 28 × 28 × 128 × 2 ≈ 3.2GB差了7倍。这就是GQA的威力。如果你再把batch_size开到16不用GQA的话KV Cache就要51GB直接爆显存用了GQA只要7GB左右还能跑。5.2 不同精度和并发下的对比下面这张表更直观基于Qwen2-7Bseq_len8192batch_size8配置KV Cache占用MHA FP1625.6GBGQA FP163.6GBGQA INT81.8GBGQA INT40.9GB可以看到GQA加量化组合起来能把KV Cache压到原来的1/28。这意味着同样的显卡你能跑更长的上下文、更高的并发或者两者兼得。5.3 如何根据显存反推最大并发实际部署时我们通常知道显卡显存需要反推能支持多大并发。假设你有24GB显存的卡模型权重占14GB框架和激活值占2GB剩下8GB给KV Cache。用Qwen2-7B GQA FP16seq_len4096单个请求的KV Cache 2 × 1 × 4096 × 28 × 4 × 128 × 2 ≈ 224MB8GB / 224MB ≈ 36个并发请求。当然这是理论上限实际还要留一些余量大概能跑到30左右。如果开启INT8量化单个请求降到112MB并发能到70以上。这个计算过程你在部署前就可以做不用等跑起来才发现显存不够。我一般会留20%的余量因为实际运行中还有临时张量、通信缓冲等开销。6. 常见问题与排查技巧实录6.1 首token延迟高但后续生成快这是最典型的现象说明KV Cache在起作用但prefill阶段计算量大。首token延迟主要取决于输入长度和模型大小。如果输入有几千tokenprefill阶段要做完整的注意力计算延迟自然高。优化方向有几个。一是开启前缀缓存如果输入有公共前缀能省掉重复计算。二是用chunked prefill把长输入切成小块分批处理降低单次计算峰值。三是考虑用更小的模型或者量化模型做prefill。vLLM的--enable-chunked-prefill可以试试对长输入场景有帮助。6.2 显存占用远超预期如果你发现显存占用比公式算出来的大很多先检查这几个地方。第一框架是否预分配了最大序列长度的KV Cache。有些框架默认按max_model_len预分配哪怕你实际用不到那么长。可以调小max_model_len或者开启按需分配。第二是否有内存碎片。连续分配方式下碎片会导致实际占用偏高。换PagedAttention能解决。第三是否开了过多的并发。每个并发请求都有自己的KV Cache并发数乘以单请求占用就是总量。6.3 长上下文下生成质量下降KV Cache本身不应该影响生成质量因为它只是缓存了计算结果没有改变数值。但如果你开了量化尤其是INT4可能会有影响。另外有些框架在KV Cache满了之后会做淘汰把最早的token的KV丢掉这会导致模型“忘记”前面的内容。如果你需要精确的长上下文回忆要确保KV Cache足够大不要触发淘汰。还有一个隐蔽的问题位置编码。有些模型用RoPE长上下文外推时位置编码可能没处理好导致质量下降。这跟KV Cache无关但容易被误认为是缓存问题。排查时可以对比短上下文和长上下文的表现如果短上下文正常长上下文变差先查位置编码配置。6.4 常见问题速查表现象可能原因排查方向首token延迟高prefill计算量大开前缀缓存、chunked prefill显存占用高预分配、碎片、并发高调max_model_len、换PagedAttention、降并发长上下文质量下降量化损失、KV淘汰、位置编码关量化、增大缓存、检查RoPE配置吞吐上不去KV Cache瓶颈开GQA、量化、PagedAttentionOOMKV Cache超限算占用、降batch、降seq_len6.5 几个容易踩的坑第一个坑是盲目开大max_model_len。很多人为了支持长上下文直接把max_model_len设成128K结果框架预分配了巨量KV Cache显存直接爆掉。正确做法是按实际需求设或者用支持按需分配的框架。第二个坑是忽略block size的影响。PagedAttention的block size不是随便设的。太小会导致block table过大管理开销高太大则内部碎片多。我一般建议先用默认值16然后根据实际序列长度分布调优。第三个坑是量化后不做评估。KV Cache量化确实省显存但不同任务对精度的敏感度不同。代码生成、数学推理这类任务对数值精度更敏感量化后可能明显变差。上线前一定要做A/B测试。第四个坑是多卡部署时KV Cache不均衡。张量并行下KV Cache会按头切分到不同卡上。如果头数不能被卡数整除或者GQA的组数跟卡数不匹配可能导致某些卡显存占用偏高。部署前要算清楚切分方案。7. 实际部署中的参数调优经验7.1 vLLM关键参数配置如果你用vLLM部署这几个参数跟KV Cache直接相关python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2-7B-Instruct \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --enable-prefix-caching \ --block-size 16 \ --kv-cache-dtype auto--gpu-memory-utilization控制框架能用多少比例的显存默认0.9。如果你发现OOM可以降到0.85。--kv-cache-dtype可以设成fp8开启KV Cache FP8量化。--enable-prefix-caching开启前缀缓存多轮对话场景必开。7.2 llama.cpp的KV Cache量化配置llama.cpp更适合本地部署它的KV Cache量化选项很灵活./llama-server -m qwen2-7b-instruct-q4_k_m.gguf \ -c 8192 \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ -ngl 99 \ --flash-attn--cache-type-k和--cache-type-v分别控制Key和Value的量化类型。可以都设q8_0也可以Key用q8_0、Value用q4_0看效果。--flash-attn开启Flash Attention能进一步降低显存占用和提升速度。7.3 我的调优顺序建议根据我自己的经验调优顺序应该是这样的。先确认模型是否支持GQA如果支持优先用GQA模型这是最省事的。然后开启PagedAttention和前缀缓存这两个对吞吐提升最明显。如果显存还不够再考虑KV Cache量化从FP8或INT8开始。最后才调block size、gpu-memory-utilization这些细粒度参数。不要一上来就全开那样出了问题很难定位。每次只改一个变量观察效果确认稳定后再改下一个。我见过有人把所有优化全打开结果生成质量崩了排查了半天才发现是INT4量化的问题。7.4 监控KV Cache使用情况部署后要监控KV Cache的实际使用率。vLLM提供了metrics接口可以看gpu_cache_usage_perc这个指标。如果长期接近100%说明KV Cache是瓶颈需要考虑加显存、降并发或者开量化。如果只有50%左右说明还有余量可以适当提高并发。llama.cpp的话启动日志里会打印KV Cache大小和分配情况。你可以根据日志判断是否合理。如果发现KV Cache比预期大很多检查一下是不是没开GQA或者量化没生效。8. 从KV Cache延伸出去的一些思考KV Cache这个点看似很小但它串联起了大模型推理优化的很多关键决策。你选什么模型、用什么精度、部署在什么硬件上、支持多长上下文、跑多少并发都跟它有关系。理解了KV Cache你就能理解为什么vLLM能比HuggingFace快那么多为什么GQA成了新模型标配为什么长上下文服务那么贵。我自己在折腾本地部署的过程中最大的体会是不要等到OOM了才去关注KV Cache。在选模型和规划硬件的时候就应该把KV Cache的占用算进去。一个7B模型在FP16下权重才14GB但如果你要跑32K上下文、16并发KV Cache可能比权重还大。提前算好这笔账能省掉很多返工。另外KV Cache的优化手段不是互斥的可以叠加使用。GQA加PagedAttention加INT8量化组合起来能把显存占用压到标准MHA的几十分之一。但每加一层优化就多一层复杂度和潜在风险。我的建议是够用就好不要为了优化而优化。先满足业务需求再考虑压榨性能。最后分享一个小技巧如果你在做多轮对话应用把系统提示词和few-shot示例放在最前面并且保持固定不变这样前缀缓存才能最大化生效。如果每次请求的系统提示词都略有不同前缀缓存就废了。这个细节看起来不起眼但在高并发场景下对成本的影响很大。