大模型百倍推理加速之KV cache篇
你一定听过这种说法：“KV cache？不就是个缓存嘛，有啥好讲的。”
说这话的人，我打赌十有八九没亲手写过推理引擎。要么就是看了两篇科普，觉得自己已经懂了。
可你知道吗？KV cache确实简单，简单到一纸公式就能讲明白。但简单≠不重要！恰恰相反，它是整个大模型推理里最要命的设计之一——决定了你能不能在一张24G显存的显卡上跑起长对话，决定了你的用户等第一个token要多久，也决定了你公司的账单到底有多难看。
今天这篇，我就把踩过的坑、实测的数据、和几份行业报告揉到一起，聊聊KV cache到底是个什么东西。顺便告诉你，它凭什么能带来“百倍推理加速”这个听起来像噱头的数字。
一、说KV cache是缓存的人，只看到了风景的一角
先从最根本的痛说起。
大模型生成内容是逐token的。你发一句“今天天气怎么样”，模型先把这句话转成token，然后走一次Transformer —— 这时候所有输入token可以同时算，这叫Prefill阶段。等输入全算完，模型开始吐第一个输出token，问题就来了：
每生成一个新token，它都得回头跟之前所有token做注意力计算。而且后一个token必须等前一个算完才能动，这叫Decode阶段。
你想想，每次生成一个新token，如果都得从头把历史所有K和V重新算一遍，那就是O(n²)复杂度。哪怕你把输入序列限制在2048个token，算起来也慢得让人崩溃。实际上早期没有KV Cache的推理引擎就是这么干的，我试过一个token能跑几百毫秒，长序列直接爆显存！
KV cache做的事非常朴素：既然第n步要用的K和V和前面n-1步算出来的是一模一样的，那何必重复算？存下来就行了。每次新token进来，只要算自己那个位置的K、V，再把历史缓存拼上，注意力计算直接复用。复杂度从O(n²)降到O(n)。
公式我就不贴了，素材里都有。但很多人没注意到一点：KV cache不是随便就能用的。它依赖于注意力机制里Query、Key、Value的角色差异——Query每次都在变，但Key和Value一旦算完就不会变。你问为什么只缓存K和V不缓存Q？因为Q是“我要找谁”，每次都不同；K和V是“我是什么内容”，历史内容不会改。
这听起来像常识，但我见过真有人把Q也塞进缓存，结果不仅没加速，显存还翻了一倍。
说到这儿，我想起一个特别形象的比喻：KV Cache就像你在买菜时的小推车。你每次走到货架前，不用从零开始把所有东西都搬一遍——推车里的东西就是K和V，你只需要把新拿的放进去，然后推着走就行了。但假如你连推车本身也重新造一遍，那不就是没事找事吗？
二、你以为问题解决了？显存才是真正的战场
好了，现在有了KV cache，Decode快了几十倍。高兴了吧？
别急。你马上会发现一个新瓶颈：显存。
一个模型参数量是固定的，但KV cache是动态增长的！一个7B模型，用FP16跑，每生成一个token，每层每个注意力头都得存两个向量（K和V）。假设32层、32个头、head_dim=128，那一个token的KV cache大小就是32×2×32×128×2字节 ≈ 0.5MB。听上去不大？
但生成2048个token就是1GB！8192个token就是4GB！如果输入上下文拉长到100K token……你自己算吧。
我去年用vLLM（v0.4.2）跑过一个推理服务，用户上传长篇文档做问答，上下文长度32K。单张A100 80G，并发数稍微高一点，显存直接爆，OOM。首Token延迟（TTFT）飙到十几秒，用户体验跟死了没区别。
所以看到XSKY的测试报告时，我特别有共鸣。他们用DeepSeek-R1（推理引擎是vLLM）测了不同上下文长度下的效果。不开KV Cache卸载的情况下，8K上下文的TTFT已经够高了；开了MeshFusion（他们的KV Cache共享存储卸载方案）之后，TTFT分别降低91%、96%、96%和94%（对应8K、32K、64K、100K）。TPS吞吐量提升13倍到28倍。
91%和28倍！不是随便写的数字。我自己没跑过那么大规模的集群，但从原理上能判断：这背后绝对不是单纯的卸载，而是把KV Cache用更高效的方式管理了。他们用的是G3.5共享存储池，把显存放不下的KV Cache挪到高速SSD上，同时靠预取和局部性保证延迟不大幅增加。说白了，这招是用存储换显存，把瓶颈从GPU转移到一个更能水平扩展的地方。
还有华为昇腾910C PD分离的测试也很有意思。Prefill和Decode拆成不同的节点，各自优化，再加KV Cache卸载，TTFT降低86%-92%，TPS提升271%-422%。而且上下文越长加速效果越明显，这说明长序列场景里KV Cache的管理已经比计算本身更关键了。
我的经验是：不管你用哪个推理框架，只要想跑长上下文，KV Cache一定是你第一个要优化的。别以为买了A100/H100就万事大吉，并发数和上下文长度会立刻吃掉所有显存。
三、别被优化名词唬住，真实落地有坑也得踩
KV Cache的优化技术这两年井喷一样冒出来：GQA、MLA、PagedAttention、量化、PD分离……每个听着都挺牛，但落地情况参差不齐。
先说GQA（Grouped Query Attention）。这是MHA（Multi-Head Attention）的一种变体，把多个Query头共享一组Key/Value，目的是减少KV Cache的存储量。我试着把MHA换成GQA（比如原本32个Query头改8组），显存直接省了四分之三，推理速度提升也很明显。但代价是模型精度会掉一点，尤其是在任务对细节敏感的场景（比如长文本问答、代码生成）。LLaMA 2 70B就已经用了GQA，但很多开源小模型还是MHA。
量化也是一种方法——把KV Cache从FP16压缩到INT8甚至INT4。我在transformers 4.35.0里用bitsandbytes试过8bit KV cache，显存少一半，速度变化不大。但问题是量化可能会增加解码延迟（需要反量化），而且INT4的精度损失往往无法接受，尤其是高重复率的场景容易出奇怪错误。
最让我感兴趣的是DeepSeek V3引入的MLA（Multi-head Latent Attention）。它的核心是把K、V压缩到一个低维潜在空间，然后用到的时候再解压回去。理论上KV Cache能缩小一个数量级。素材里提到，DeepSeek-V4在1M token上下文下，KV Cache只占标准MHA模型的10%。我虽然没有在生产环境用过，但这个思路确实漂亮——不是等事后再优化缓存，而是在模型设计层面就把问题解决了。
但你不能指望靠一个模型架构解决所有问题。即使KV Cache小到10%，1M token下依然有1.87GB（根据闪存那篇文章的数据），而且这还是算上了DeepSeek自己的CSA（Chunked Sparse Attention）之后的结果。当上下文长得离谱，哪怕1.87GB也得考虑卸载和调度。
另一个实操上的坑：连续批处理（Continuous Batching）和PagedAttention。我最早用vLLM的时候，觉得内存管理就是malloc/free，但PagedAttention把KV Cache切成固定大小的块，用类似虚拟内存的方式管理——这直接解决了显存碎片和预分配浪费的问题。sglang、lmdeploy也都有类似设计。如果你自己写推理引擎，这个几乎是必做的，不然并发一高就崩。
说到这儿，我想起一句特别形象的话：优化KV Cache就像整理你家的衣柜。有人用压缩袋（量化），有人用挂杆分类（GQA），有人干脆把不常用的衣服放去地下室（卸载）。方法五花八门，但核心目标只有一个——在有限的衣柜里塞下更多衣服，而且还要能快找到想要的那件！
四、有人可能会说：现在显存越来越大，搞这些还有必要吗？
我听过这种声音：“等H100降价了，显存上G，KV Cache那点事儿根本不是问题。”
这只有没跑过长上下文的人才会说。
首先，显存增长的速度赶不上用户需求增长的速度。你看现在AI论文动不动就100K token上下文，Codex、Claude、Gemini都在推百万token。即使H100有80G，你试试一个100K token的并发请求——光KV Cache一个请求就快20G了，四个请求塞满。这还没算模型参数、激活值、临时变量。你跟我说显存够？
其次，成本。XSKY的报告里说，通过KV Cache卸载到共享存储，整体基建TCO下降了30%-50%。这不是小钱。如果你做的是商业推理服务，客户可能要求32K以上的上下文，你一张A100只能服务几个用户？用卸载方案，同样预算能服务的用户量翻倍甚至翻两倍。
说到底，KV Cache的优化从来不是“能不能跑”的问题，而是“能不能跑得划算”的问题。
我见过太多团队，买了最贵的显卡，跑着最糟糕的代码。一个优化就能省下一半的算力成本，他们却选择硬扛，把钱烧在显存上限上。
你说，这是技术问题，还是认知问题？
最后一句话，给每个正在读的你：
真正厉害的人，不是解决大问题的人，而是把“小问题”挖透的人。KV cache虽小，但它是大模型推理的命门。谁掌握了它，谁就掌握了未来半年的竞争力。
而你，现在就可以开始。
读者评论 2