KVCache 在大模型推理中的作用：为什么它能让模型“越算越快”？

那天我在本地跑一个 7B 模型，连续生成几段代码。第一句输出还算平稳，第二句突然变快，第三句几乎是“刷刷刷”地蹦出来。我当时愣了一下——按常识来说，上下文越长，模型应该越慢，怎么反过来了？

在工程群里问了一圈，答案都很一致：
“你看到的是 KVCache 在发力。”

但这句话对大部分人来说更像一个黑箱。
所以今天我们不从术语、不从公式开始，而是一起从“模型为什么会越算越快”这个真实的体验出发，把 KVCache 讲成你脑子里能长出结构、工程师能真正看懂的东西。

---

模型为什么没有越算越慢？先理解这个反差

生成任务看似是一步一步往下推，但 Transformer 有个很坑人的特性——每一步都会和历史所有 token 做 Attention 互动。

按道理来说：

• 输入越多，Attention 的计算越重

• 序列越长，复杂度越高（O(n²)）

• 推理应该越跑越慢

但现实是：

• 越到后面越快

• 热启动效果明显

• 多轮对话特别快

这个反差背后的机制，就是 KVCache。

你可以把它理解成模型的“历史计算记忆”：
历史输入一次计算成 K（Key）和 V（Value），之后直接缓存下来，后续推理全部复用，不再重复算第二次。

这个缓存，就是让序列越长、模型越快的关键。

---

KVCache 到底是什么？为什么 Key/Value 可以缓存？

先用人话说 Attention：

• Query：我现在想找什么

• Key：历史内容的“目录索引”

• Value：历史内容的“实际内容”

如果每次都要：

• 重新建目录

• 重新整理内容

• 再用 Query 去查

那推理会慢得像乌龟。

但 Transformer 非常“聪明”：

历史 Key/Value 只需要算一次，之后都可以直接复用。
Query 每次重新生成，毕竟你每一步在问的问题不同。

这就像搜索引擎不会每次你搜索都重建整个互联网，只是用新的 Query 去查以前构建好的索引。

下面这张图