KV Cache优化实战：从OOM到32路并发，显存压缩与复用全攻略

前几天有个读者跑过来问我，说同样都是 4090 单卡，别人能挂 32 路并发，自家服务跑 4 路就开始一个接一个 OOM，同一个开源模型，同一份推理框架，怎么差别这么大。我让他把启动命令和日志贴出来，扫了一遍就发现问题全出在 KV Cache 上——显存预算没算、量化没开、前缀复用没用、页面调度不会配，等于把一个大显存杀手养在家里还天天给它加餐。其实 KV Cache 是现在大模型推理性能的命门，也是一块最值得花时间抠的性价比高地。这篇文章把 KV Cache 从头到尾拆一遍，把我实际跑过的瘦身方案、调度方案、复用方案都摊开讲，看完你可以直接对着自己的服务做一次全面体检。

KV Cache 这个概念对做 LLM 推理的朋友来说是老朋友了，但大多数人对它的理解还停留在“一个减少重复计算的缓存”这个层面。实际上 KV Cache 的显存消耗往往比模型权重还大，它的分配策略、量化精度、复用机制，直接决定你能挂多少并发、能跑多长上下文、首字延迟能压到多低。这篇文章适合正在做模型部署、性能调优、长上下文应用的工程师，也适合那些想把手头开源模型服务“再压榨一把”的朋友。

1. 先把底层逻辑讲清楚：KV Cache 到底在省什么

1.1 自回归解码的笨办法：每生成一个字，都把全文重新读一遍

要理解 KV Cache 的价值，得先回到 Transformer 解码的基本流程。大模型生成文本是自回归的，也就是一个 token 一个 token 往外蹦。假设我正在生成“今天天气真不错”这句话，生成到“真”这个字的时候，模型需要根据前面的“今天天气”来预测下一个字。纯理论上的做法，是把整个序列“今天天气”完整地送进模型算一遍注意力，拿到预测结果。

但问题来了，等到生成“不”这个字的时候，输入序列变成了“今天天气真”，模型又要重新算一遍完整的注意力。你会发现“今天天气”这四个 token 的 Key 和 Value 矩阵，在生成“真”的时候算过，在生成“不”的时候又被重新算了一遍，生成“错”的时候又算了一遍。序列越长，这种重复计算就越离谱，时间复杂度直接随序列长度二次方增长。

这里解释一下为什么缓存的是 K 和 V 而不是 Q。注意力计算的核心是 Q 和 K 做点积得到注意力分数，再用分数对 V 加权求和。在解码阶段，当前要生成新 token 时，它的 Q 是新鲜的，只属于这一步，用完即弃。但历史 token 的 K 和 V 是后续每一步都要反复用到的“参考资料”，所以最划算的做法是第一次算完就把 K 和 V 存进显存，之后每次生成只计算当前 token 的 Q，然后拿着 Q 跟缓存里的 K、V 做注意力，不再回看整段历史文本。

1.2 省下来的计算量，收走的却是显存

KV Cache 的代价从“存起来”这三个字就开始了。Key 和 Value 不是两个小数字，而是形状为 [层数, KV头数, 序列长度, 头维度] 的大矩阵，而且每个 token、每一层、每一个注意力头都得各存一份。序列越长，缓存占用越大；并发请求越多，缓存占用还要再乘以请求数。

我用一个生活化的类比：KV Cache 相当于你写材料时的草稿纸。没有草稿纸，每次改一个段落都要把整份材料从头读一遍再重写一遍，累但省桌子；有了草稿纸，改动时只看相关片段就行，效率高，但是草稿纸堆得多了桌面根本放不下。KV Cache 就是这张越来越大的草稿纸，它把计算的时间成本转移成了显存的空间成本，而显存恰恰是推理服务最稀缺的资源。

1.3 缓存的开销为什么被低估了

很多人评估推理显存需求时，只把模型权重算进去：7B 模型 FP16 权重大概 14GB，一张 24GB 的 4090 似乎妥妥够用。但一跑长上下文、一上并发，立刻 OOM，原因就是 KV Cache 的占用被严重低估了。而且模型权重是一次性常驻的静态开销，KV Cache 却是动态增长的，每一个请求、每一个新 token 都在往里加东西。

权重是堆在仓库里的货，KV Cache 是正在分拣的流水线，货摆好了不动，流水线上的东西却随着订单不断增加。很多部署新手只算了仓库能放下多少货，没算分拣场地够不够用，结果一开张就堵住了。

2. 显存账本：KV Cache 是怎么一口口吃掉你显存的

2.1 KV Cache 显存占用的精确计算公式

先把公式亮出来，这是做推理容量规划必会的一条硬公式：

KV Cache 显存占用（字节）= 2 × 层数 × KV头数 × 头维度 × 序列长度 × 并发请求数 × 每个元素的字节数

公式里的“2”来自 Key 和 Value 各一份。如果模型用 GQA（分组查询注意力）或 MQA（多查询注意力），KV 头数远小于 Q 头数，这部分开销会小很多；如果是传统的 MHA（多头注意力），KV 头数等于注意力头数，显存占用就直接按满配计算。每个元素字节数取决于精度，FP16 是 2 字节，INT8 是 1 字节，INT4 是 0.5 字节，FP8 也是 1 字节。

2.2 三组算例：7B、8B GQA、70B 规模对比

光有公式还不够，我直接给你算几组实际数据，你感受一下 KV Cache 的恐怖。

注意看第二行：一个传统 7B 模型，模型权重本身才 14GB 左右，如果你让 16 个用户同时并发、每个用户上下文达到 4096，KV Cache 直接吃掉 32GB 显存，比权重还多一倍多。700 亿参数的模型更夸张，单用户上下文 4096 时 KV Cache 就要 1.25GB，64 路并发直接冲到 80GB，这还没算激活值和中间临时张量。

GQA 之所以成了现代模型的主流配置，KV 头数砍到原来的四分之一甚至八分之一，KV Cache 的占用也随之大幅下降。这也是 Llama 3 这类模型“省显存”的底气所在。

2.3 长上下文和高并发为什么总是打架

KV Cache 有两个变量在同时增长：序列长度和并发数。这俩乘在一起，显存压力就是二次方的。上下文从 4K 拉到 32K，同样并发下 KV Cache 占用涨 8 倍；并发从 16 拉到 32，再翻一倍。长上下文服务想要高并发，本质上是在跟显存做乘法题，不做优化根本撑不住。

这也是为什么 OpenAI 这类商业 API 的长上下文定价贵：上下文每长一截，KV Cache 的成本就非线性上涨。模型参数是死的，缓存却是活的，每个用户会话都在持续吃掉显存。明白了这一点，你就知道为什么 KV Cache 量化、分页调度、前缀复用这些“高级玩法”不是锦上添花，而是长上下文工业化部署的刚需。

3. 玩法一：给 KV Cache 瘦身，INT8/INT4 量化实操

3.1 为什么 KV Cache 可以量化而模型不会“发疯”

量化 KV Cache 的核心思路，是把 FP16 的高精度缓存压缩成低比特表示，显存占用直接按比例下降。很多人担心量化之后模型输出质量崩掉，实际并不是这样，KV Cache 跟模型权重量化有本质区别。

权重矩阵里存的是学习到的知识，精度一旦受损，知识的细节就可能丢失；而 KV Cache 里存的是当前上下文里提取的注意力记忆，它的数值分布非常集中，大部分值都落在较小的区间内，离群值比例不高。这种情况下做量化，用较少的比特数也能近似还原出绝大部分信息，注意力计算对小的数值扰动有天然的鲁棒性。

3.2 K 和 V 的敏感度不一样，混合精度才是正道

我踩过最深的一个坑，就是一上来把 K 和 V 都压成 INT4，结果模型回答质量明显下滑。后来才知道，Key 和 Value 矩阵对量化的容忍度完全不同。V 矩阵的数值分布往往更尖锐，离群值更多，压缩太狠会破坏注意力输出的信息；K 矩阵分布相对平滑，量化友好度高得多。

所以现在业界的主流做法是混合量化：Key 用高一点的精度，比如 INT8 或 FP8；Value 用更低一点的精度，比如 INT4。这样显存省了，精度损失还能接受。如果你用的推理引擎支持 per-token 或 per-head 级别的量化，效果比整个矩阵统一一个 scale 更好，因为不同 token、不同注意力头的数值范围差异很大，细粒度量化能更精准地还原原始分布。

3.3 引擎里的量化参数怎么配置

不同推理框架对 KV Cache 量化的支持程度不一样，但主流引擎基本都跟上来了。vLLM 里可以用kv_cache_dtype参数，指定为fp8_e5m2或fp8_e4m3，显存直接砍一半，精度损失在大多数任务上微乎其微。llama.cpp 这类本地推理工具更灵活，支持单独指定 K 和 V 的缓存类型，比如 K 用 q8_0、V 用 q4_0，想怎么组合就怎么组合。

我实际用的命令大概是这样的：

# vLLM 启动时启用 FP8 KV Cache python -m vllm.entrypoints.openai.api_server \ --model meta-llama/Llama-3-8B-Instruct \ --kv-cache-dtype fp8_e5m2 \ --max-model-len 8192 # llama.cpp 混合量化 K/V 缓存 llama-cli -m model.gguf \ --cache-type-k q8_0 \ --cache-type-v q4_0

注意，vLLM 的 FP8 KV Cache 需要在支持 FP8 的 GPU 上跑（比如 Ada Lovelace 架构及以上），老卡上要么不支持要么会退化成模拟计算，性能反而更差。llama.cpp 的 GGUF 方案对硬件要求宽松一些，核显都能跑。

3.4 量化后的精度与显存实测参考

我在 Qwen2-7B 上做过一组对照：FP16 KV Cache、FP8 量化、以及 K-FP8+V-INT4 混合量化，跑了一批通用能力测试集。FP8 方案的分数跟 FP16 基本持平，差距在一个可忽略的区间内；K-FP8+V-INT4 会掉一到两个点，但换取的是显存占用从 16GB 降到 4GB 左右。如果你的任务对推理质量要求极高，比如医疗报告生成，建议保守一点用 FP8；如果做的是摘要、分类、信息抽取这类容错率高的任务，混合量化非常划算。

量化 KV Cache 还有一层隐藏收益，不只是省显存。显存占用降下来之后，可以塞进更大的 batch、拉更长的上下文，或者同显存下提高并发数，最终吞吐量的提升往往是翻倍的。我之前把一个长文档分析服务从 FP16 切到 FP8 KV Cache，同样的 24GB 显卡，并发从 8 路提到了 20 路，服务端吞吐从每秒 1800 tokens 涨到了 4200 tokens，效果非常直观。

4. 玩法二：PageAttention，学操作系统那套分页管理

4.1 连续分配的浪费，是变相 OOM 的元凶

传统推理框架分配 KV Cache 的方式非常粗暴：预先把显存里的一块连续空间按最大可能长度分配好，比如约定每个请求最多支持 8192 上下文，就直接给每个请求批预留整整 8192 个 token 的 KV 空间。但实际上绝大多数请求只用到几百甚至几十个 token，剩余空间全闲着。

更麻烦的是碎片化问题。不同的请求长度各不相同，一个请求结束了，它占用的内存块空出来了，但旁边的请求还在运行，新请求想从中间插入就插不进去，只能去找别的大块空闲内存。这种内部碎片加外部碎片，加起来可能浪费掉 60% 以上的可用缓存空间。很多人发现显存明明还剩很多，新的请求却报 OOM，就是这块在作怪。

4.2 PageAttention：像操作系统的虚拟内存一样管理 KV

vLLM 提出的 PagedAttention 借鉴了操作系统的虚拟内存分页机制，思路非常优雅。它不再为每个请求一次性分配连续的 KV 空间，而是把 KV 缓存切成固定大小的块，默认每个块存 16 个 token 的 KV，请求需要多少就动态申请多少块，分散在显存各处，不要求物理连续。

每个请求有一张块表，记录它用的哪些块、块内的填充情况。新的请求只需要申请足够当前 token 数量的块就行，请求结束了块就回收；之前请求留下的零散块也能被新请求拼凑使用。这个机制把显存利用率从 60% 以下拉到接近 100%，直接结果就是你可以在同一块显卡上塞下多得多的并发请求和更长的上下文。

4.3 vLLM 下的显存预算分配实战

vLLM 启动时有个gpu_memory_utilization参数，控制给整个推理过程分配多少比例的显存，其中大头就是给 KV Cache 用的。这个参数给得太低，缓存区太小，并发和长度都受限；给得太高，留给计算图、激活值和通信缓冲区的空间不够，容易直接 CUDA OOM。

我的经验值是 0.85 到 0.9 之间。启动日志里 vLLM 会明确打印本次 KV Cache 分配了多少显存、能容纳多少 token，这是判断显存是否喂饱的黄金指标。另外max-num-seqs控制并发序列上限，max-model-len控制单序列最大长度，这两个值直接影响 KV Cache 的“天花板”。想提高并发，在显存预算不变的情况下就得适当缩短 max-model-len，二者需要一起调。

我见过太多人把这三个参数随便填，最后要么显存利用率极低、并发拉不起来，要么直接 OOM。正确顺序是先定 max-model-len（根据业务最长输入和输出决定），再把 gpu_memory_utilization 拉高，最后根据显存余量逐步调高 max-num-seqs，直到接近 OOM 边界再往回退一些。

5. 玩法三：Prefix Caching，让上一轮的缓存直接续用

5.1 多轮对话和 Agent 场景的重复计算有多可惜

现在大模型应用最常见的一个场景就是多轮对话、Agent 任务和 RAG 问答。这些场景都有一个共同特点：每轮请求都带着大量相同的上下文。Agent 的 system prompt 是固定的，知识库检索后的前缀说明是固定的，对话前面的历史消息也在不断重复拼接。如果你不做任何优化，每一轮新请求都要把前面这些相同的 token 重新算一遍 KV，再重新存一遍。

几十轮对话下来，重复计算的成本是巨大的。我测过一个 Agent 应用的访问日志，请求总长度 6000 token，其中 5500 个 token 是上一轮就见过的历史内容，真正新增的只有几百个 token。这意味着 90% 以上的 KV 计算和存储完全是浪费。

5.2 前缀复用的实现原理与开启方式

Prefix Caching 的思路是把 KV Cache 块以内容哈希为标识存起来，新请求进入时，先按前缀逐块比对哈希，命中的块直接复用，不用重新计算。vLLM 里开启非常方便，新版本一般默认启用，或者加一个--enable-prefix-caching；SGLang 做得更细，提出了 RadixAttention，把共享提升到 token 级别，调度更灵活。

实际效果有多夸张？我在一个固定 system prompt 约 2000 token 的 RAG 服务上试过，同一 prompt 的批量请求，首 token 延迟（TTFT）直接从 800 多毫秒降到不到 100 毫秒。这个差距在短请求上不明显，但在长上下文的场景是数量级的提升。

注意这里的缓存复用是有前提的：前缀必须逐 token 完全相同。一个标点、一个空格变了都会导致哈希不匹配。很多人开了前缀缓存发现命中率很低，往往就是前缀里有动态内容在作怪。

5.3 把“变的部分”往后挪，命中率直接翻倍

提升前缀缓存命中率的实操技巧，就是做“前缀稳定化”。把所有动态内容——时间戳、随机数、用户输入里的变化部分——集中放到固定模板之后，而不是穿插在里面。比如 prompt 模板可以设计成“固定系统指令 + 固定任务说明 + 动态用户输入”，而不是“固定开头 + 动态片段 + 固定结尾”。

一开始我觉得这个设计和缓存命中无关，直到压测后发现动态片段一旦出现在较前位置，后面的固定内容全部无法复用，因为前缀匹配在第一个不一致处就断了。把动态内容往后挪之后，同样的业务流量，缓存命中率从不到 20% 提到了 85% 以上，显存和算力负担双双下降。

6. 从零压榨：一次完整的 KV Cache 调优实操记录

6.1 环境准备与模型选择

我用一台 4090 24GB 的单卡机器做了一次完整的 KV Cache 优化实测，模型选的是 Qwen2-7B-Instruct，推理框架用 vLLM 0.6 以上版本。这个组合很典型：模型权重 FP16 大约 14GB，算上激活值和运行时开销，留给 KV Cache 的空间大概在 5 到 6GB 左右，正是最能体现优化效果的环境。

我先准备了一个压测脚本，模拟 32 个并发用户请求，每个请求的 prompt 约 1500 token，输出限制在 512 token 以内。这个负载能让 KV Cache 的压力完全暴露出来，太小测不出差异，太大又容易直接崩。

6.2 第一步：跑一个关闭缓存的基线，感受一下有多痛

为了制造对照，我先用 Transformers 的generate方法跑了一轮，把use_cache设为 False，强制每次生成都重新计算所有历史 token 的 KV。结果非常惨烈：生成 100 个 token 花了近一分钟，GPU 算力利用率上去了，但 token 产出速度低得离谱。这个实验不用跑太多，一次就够，它能让你对“KV Cache 到底省了多少计算”产生强烈直观认知。

6.3 第二步：vLLM 默认配置，打开 KV Cache

然后我把推理切到 vLLM，保持默认配置：gpu-memory-utilization=0.85，max-model-len=8192，max-num-seqs=32。同样是 32 并发，效果立刻不一样，压测显示吞吐稳定在 2200 tokens/s 左右，TTFT 平均 350ms。连续跑了几轮之后看启动日志，KV Cache 占用的显存空间已经接近预算的 90%，说明空间基本吃满了。

这一步的结论是：上 KV Cache 之后，光是把计算次数压下来，吞吐就能提升一个数量级。Transformers 那个基线跑完整轮要几分钟，vLLM 几十秒就能完成同样的工作量。

6.4 第三步：叠加量化、分页调度与前缀复用

接着我把三项高级优化全开：KV Cache 用 FP8 量化，vLLM 启用 PagedAttention 和前缀缓存，max-num-seqs拉到 64。显存占用因为量化直接减半，原来 KV Cache 用 5.5GB 的地方现在只占 2.8GB 左右，省出来的空间塞下了双倍并发。

压测结果——吞吐直接冲到了 4300 tokens/s 左右，TTFT 降到 180ms。如果请求带固定前缀（比如相同的 system prompt），TTFT 甚至能压到 60ms 以内，因为前面所有 KV 都是直接从缓存里捞的，GPU 几乎不需要干活。

6.5 参数速查表：我反复调整后觉得最顺手的配置

这里有个小坑要提醒：max-model-len 设置得非常大，即使当前请求的实际 token 数很少，vLLM 也会按最大长度预留 KV Cache 容量，因为你无法预知请求未来会长到多少。所以别图省事设个 65536，如果你的业务绝大多数请求只有几千 token，设 8192 或 16384 就够，否则 KV Cache 空间大部分是被预占而非实际使用的。

7. 翻车现场与排查心得：KV Cache 相关的 5 个常见坑

7.1 明明显存还有，却一直 OOM

这个坑的根源绝大多数是 PagedAttention 的块分配策略没跑对，或者 gpu_memory_utilization 给得太高导致 CUDA context 和计算图空间不足。还有一个隐蔽原因：显存碎片来自非 vLLM 分配的缓存，比如 tokenizer、采样器、并发请求的中间激活。

排查步骤一般是这样：先看启动日志里 KV Cache 分配和上限的打印，再用nvidia-smi观察显存曲线，如果显存确实接近 100% 了，就先降 max-num-seqs，再降 max-model-len，最后才动量化。顺序反了容易做出错误判断。

7.2 开了前缀缓存，命中率却惨不忍睹

这个基本只有两个原因：前缀不固定，或者前缀里有动态字符。我见过一个系统把用户 ID 写进了 prompt 前半部分，导致每个用户的缓存都无法互相复用；还有人在固定模板里拼了当前时间，结果每一秒的请求前缀都不一样。

解决办法就是按 5.3 节说的，把动态内容全部挪到固定模板之后。另外注意 prompt 的格式化要完全一致，比如apply_chat_template之后前后不要有额外空格或换行，不同请求的模板渲染结果必须完全一致，哈希比对才能命中。

7.3 量化 KV Cache 之后回答质量明显变差

如果你发现量化后模型输出逻辑混乱、事实错误增多，不要急着否定量化这条路。先检查量化的粒度：整矩阵一个 scale 的粗粒度量化最容易损失精度，换 per-token 或 per-head 粒度通常能救回来不少。再检查 K 和 V 是否用了同一精度：尝试把 V 的精度提高一档，K 保持低精度。

我有一套兜底方案：把离群值多的层单独排除在量化之外。实践中往往只有少数几层对 KV Cache 精度敏感，其他层随便压。找出这些敏感层可以靠逐层替换测试，先全部量化，再逐层改回高精度看效果，直到质量达标为止。

7.4 长对话越聊越慢，响应延迟线性增长

长上下文对话服务的延迟会随着对话轮数增加而上涨，一部分是正常的——上下文越来越长，注意力计算量必然变大；但如果你发现延迟涨得远超过线性水平，就要怀疑 KV Cache 分配出现过载了。

排查思路是：看当前请求的 token 数是否逼近 max-model-len 上限；看 KV Cache 是否因为空间不足触发了旧 block 的逐出；看是否在 vLLM 内部发生了请求级的分块调度。优化手段包括：给对话历史做摘要压缩、缩短 max-model-len、开启前缀缓存让历史部分直接复用。最有效的还是给对话历史加摘要，把 100 轮的完整历史压成 500 token 的摘要，KV Cache 的负担瞬间降下来。

7.5 吞吐就是上不去，钱花了不出活

吞吐上不去通常意味着显存预算没有充分转化为并发能力。三个最常见的原因：gpu_memory_utilization 设太低导致 KV Cache 区太小；max-num-seqs 设太小限制并发；block_size 设置不合理导致块表膨胀或者尾部浪费。

vLLM 默认 block_size 是 16，对大部分模型都算合理。如果请求普遍很短，可以调小 block_size 减少尾部浪费；如果请求普遍很长，调大 block_size 可以降低块表管理开销。调完之后看启动日志里 KV Cache 的 token 容量是否接近显存上限，如果还有大把空间没利用，就继续拉高并发直到边界。

回到开头那个读者的案例，我给他开出的药方很简单：gpu-memory-utilization从 0.5 拉到 0.88，KV Cache 量化改成 FP8，max-num-seqs从 4 提到 32，prefix caching 打开。改完不到十分钟，同样的 4090 从 4 路并发 OOM 变成了稳定 32 路并发，服务端吞吐翻了接近十倍。KV Cache 就是这么个东西，它不显山不露水，但每一个参数都值真金白银。我自己现在部署任何推理服务，第一步永远是先按这套逻辑把 KV Cache 的账算清楚，再做其他优化——这已经成了我的肌肉记忆。