1. 从一道口令实验说起：共享状态到底共享了什么
第一次看到“共享状态，隔离问题”这个说法，是在一次内部技术分享的茶歇上。当时有人抛出一个问题：Transformer 推理时，KV cache 到底算不算一种“共享状态”？如果算，那它共享的是哪些东西，隔离的又是什么问题？这个问题听起来像哲学，但落到工程上，它直接决定了你的推理服务能不能扛住并发、显存会不会爆、延迟能不能压下来。
我后来自己动手做了一组口令实验，用最朴素的方式去观察 KV cache 在自回归生成过程中的行为。实验本身不复杂：构造一段固定前缀的 prompt，让模型连续生成多个 token，同时记录每一层、每一个注意力头的 key/value 张量变化。结果很有意思——前缀部分的 KV 在第一个 token 生成后就被固定下来，后续所有 token 的生成都在复用这份“共享状态”，而每个新 token 自己的 KV 则是独立追加的。换句话说，共享的是历史，隔离的是当下。
这个观察直接解释了为什么 KV cache 能大幅加速推理：没有它，每生成一个 token 都要把整个序列重新过一遍注意力计算，复杂度是 O(n²) 的重复劳动；有了它，历史 token 的 key/value 只算一次，新 token 只需要和这份共享状态做一次注意力交互。但问题也随之而来——这份共享状态是“只读”的吗？多个请求之间能不能共享？共享的边界在哪里？隔离的代价是什么？
这篇文章就是围绕这几个问题展开的。我会从 KV cache 的结构讲起，拆解它在 Transformer 注意力机制中的位置，然后用手写代码的方式复现一个最小可用的缓存逻辑，最后聊一聊在实际部署中怎么平衡共享与隔离。适合已经了解 Transformer 基本结构、但想进一步搞清楚推理优化细节的读者。如果你正在做推理加速、显存优化或者多路并发服务，这些内容应该能直接派上用场。
2. KV cache 的本质：注意力机制里的“历史账本”
2.1 自注意力到底在算什么
要理解 KV cache，得先把自注意力机制的计算过程拆开看。标准的缩放点积注意力可以写成：
Attention(Q, K, V) = softmax(QK^T / sqrt(d_k)) V其中 Q、K、V 分别由输入序列经过三个线性变换得到。对于长度为 n 的序列，Q、K、V 的维度都是 n × d_k。计算 QK^T 会得到一个 n × n 的注意力分数矩阵，再经过 softmax 和 V 相乘，得到 n × d_k 的输出。
在训练阶段，整个序列是并行处理的，n × n 的矩阵一次性算完，效率很高。但在推理阶段，尤其是自回归生成时，序列是一个 token 一个 token 往外蹦的。每生成一个新 token，如果都重新计算整个序列的 Q、K、V，那计算量会随着序列长度平方级增长。这就是所谓的“重复计算”问题。
2.2 缓存的是 K 和 V，不是 Q
关键洞察在于：对于已经生成的历史 token，它们的 K 和 V 在后续计算中是不变的。因为 K 和 V 只依赖于对应位置的输入表示，而这个表示在生成那一刻就已经确定了。Q 则不同，每个新 token 都有自己的 Q，需要和所有历史 K 做注意力。
所以 KV cache 的做法很直接：把每一层、每一个注意力头的历史 K 和 V 存下来，新 token 来的时候，只需要计算它自己的 Q、K、V，然后把新的 K、V 追加到缓存里，用新的 Q 和完整的 K、V 做注意力计算。这样每步的计算量从 O(n²) 降到了 O(n)，显存换时间，非常划算。
用一个生活化的类比：KV cache 就像你在读一本书时做的读书笔记。每读一页，你把关键信息记下来（K 和 V），下次需要引用前面内容时，直接翻笔记就行，不用把整本书重新读一遍。笔记越厚，翻起来越慢，但总比重新读书快得多。
2.3 缓存的结构与显存占用
KV cache 的显存占用可以用一个公式估算：
显存占用 = 2 × batch_size × num_layers × num_heads × seq_len × head_dim × dtype_size其中 2 是因为要存 K 和 V 两份。以一个 7B 级别的模型为例，假设 num_layers=32，num_heads=32，head_dim=128，dtype 为 fp16（2 字节），batch_size=1，seq_len=2048，那么单层的 KV cache 占用约为：
2 × 1 × 32 × 32 × 2048 × 128 × 2 字节 ≈ 1.07 GB32 层加起来就是 34 GB 左右。这还只是 batch_size=1 的情况，如果并发上来，显存会线性增长。所以 KV cache 的显存管理是推理服务里非常核心的一环，后面会详细讲怎么优化。
注意：不同框架对 KV cache 的布局可能不同，有的是 [batch, heads, seq, dim]，有的是 [batch, seq, heads, dim]。做显存估算时一定要先确认布局，否则算出来的数字可能差一个数量级。
3. 手写一个最小 KV cache：从零复现缓存逻辑
3.1 实验环境与数据准备
为了把 KV cache 的行为看得清清楚楚，我用 PyTorch 手写了一个极简的单头注意力模块，不依赖任何现成的 Transformer 库。环境很简单：Python 3.10 + PyTorch 2.1，CPU 就能跑，不需要 GPU。数据方面，我构造了一个简单的正弦序列作为输入，这样注意力模式比较直观，方便观察缓存前后的输出是否一致。
先定义基本的注意力计算函数：
import torch import torch.nn.functional as F def attention(q, k, v, causal=True): d_k = q.size(-1) scores = torch.matmul(q, k.transpose(-2, -1)) / (d_k ** 0.5) if causal: seq_len = q.size(-2) mask = torch.triu(torch.ones(seq_len, seq_len), diagonal=1).bool() scores = scores.masked_fill(mask, float('-inf')) attn = F.softmax(scores, dim=-1) return torch.matmul(attn, v)这个函数就是标准的缩放点积注意力，加了因果掩码，保证每个位置只能看到自己和前面的位置。
3.2 无缓存版本：每步重算全序列
先写一个不带缓存的生成循环，作为基准：
def generate_no_cache(x, steps): outputs = [] for _ in range(steps): out = attention(x, x, x) next_token = out[:, -1:, :] x = torch.cat([x, next_token], dim=1) outputs.append(next_token) return torch.cat(outputs, dim=1)每一步都把整个序列重新过一遍注意力，逻辑简单，但计算量随序列长度增长很快。跑 100 步，序列长度从 10 涨到 110，耗时肉眼可见地增加。
3.3 带缓存版本：只算新 token 的 Q
缓存版本的核心改动是：维护一个 k_cache 和 v_cache，每次只计算新 token 的 q、k、v，然后把新的 k、v 拼到缓存后面，用新的 q 和完整的 k_cache、v_cache 做注意力。
def generate_with_cache(x, steps): k_cache = None v_cache = None outputs = [] for i in range(steps): if i == 0: q = k = v = x else: q = k = v = x[:, -1:, :] if k_cache is None: k_cache, v_cache = k, v else: k_cache = torch.cat([k_cache, k], dim=1) v_cache = torch.cat([v_cache, v], dim=1) out = attention(q, k_cache, v_cache, causal=False) next_token = out[:, -1:, :] x = torch.cat([x, next_token], dim=1) outputs.append(next_token) return torch.cat(outputs, dim=1)这里有个细节需要注意：带缓存时，q 只包含当前 token，而 k_cache 和 v_cache 包含所有历史 token，所以不需要再加因果掩码，因为 q 的位置天然就在最后，它只能看到前面的 k。这也是为什么代码里 causal=False。
3.4 两种版本的输出对比与性能差异
跑同样的输入和步数，对比两种版本的输出：
x = torch.randn(1, 10, 64) out_no_cache = generate_no_cache(x, 50) out_with_cache = generate_with_cache(x, 50) print(torch.allclose(out_no_cache, out_with_cache, atol=1e-5))实测下来，输出几乎完全一致（浮点误差范围内），但耗时差异明显。在序列长度到 200 左右时，带缓存版本的速度大约是无缓存版本的 3 到 5 倍，序列越长差距越大。这个实验虽然简单，但它把 KV cache 的核心价值展示得很清楚：用显存换计算，用共享换效率。
实操心得：手写缓存版本时，最容易出错的地方是拼接维度。k_cache 和 k 的拼接一定要在序列维度上，而不是 batch 或 head 维度。建议在拼接前后打印 shape，确认维度对齐。
4. 共享与隔离：多请求场景下的缓存管理策略
4.1 单请求内的共享：前缀复用
在单个请求内部，KV cache 的共享是天然的：所有已生成的 token 共享同一份历史缓存。但更进一步，如果多个请求有相同的前缀（比如相同的 system prompt），那这份前缀的 KV cache 能不能跨请求共享？答案是能，而且收益很大。
这就是所谓的 prefix caching。做法是：把相同前缀的 KV cache 算一次，存起来，后续请求如果命中相同前缀，直接复用，只需要计算差异部分的 KV。对于 system prompt 很长的场景，这能省下大量重复计算。
但这里有个隔离问题：不同请求的后续生成是独立的，它们不能互相看到对方的 token。所以共享的是前缀部分，隔离的是各自的后缀部分。实现上通常用引用计数或者写时复制来管理，前缀缓存只读，后缀缓存各自独立。
4.2 多请求并发：PagedAttention 的思路
当并发请求很多时，KV cache 的显存碎片化会成为大问题。每个请求的序列长度不一样，如果按最大长度预分配显存，浪费严重；如果动态分配，又容易产生碎片。vLLM 提出的 PagedAttention 借鉴了操作系统虚拟内存的分页思想，把 KV cache 切成固定大小的 block，按需分配，用页表来映射逻辑位置和物理位置。
这样做的好处是：显存利用率大幅提升，因为 block 可以非连续分配；共享前缀时，多个请求的页表可以指向同一个物理 block，实现零拷贝共享；隔离性也有保障，每个请求有自己的页表，逻辑上互不干扰。
实测下来，PagedAttention 在并发场景下能把吞吐量提升 2 到 4 倍，具体取决于序列长度分布和并发数。代价是实现复杂度高，需要自己管理 block 分配和回收。
4.3 隔离的代价：什么时候不该共享
共享不是免费的。跨请求共享前缀缓存，需要做前缀匹配，这本身有计算开销；共享的 block 需要引用计数，回收时机要精确；如果前缀匹配率低，共享带来的收益可能抵不过管理开销。
我的经验是：如果 system prompt 长度超过 500 token，且请求量足够大，prefix caching 的收益非常明显；如果 prompt 都很短且各不相同，那老老实实每个请求独立分配反而更简单高效。隔离问题在这里体现为：共享的粒度越细，管理成本越高；隔离得越彻底，资源利用率越低。找到平衡点是工程上的关键。
| 策略 | 共享粒度 | 隔离方式 | 适用场景 | 显存开销 |
|---|---|---|---|---|
| 无共享 | 无 | 完全独立 | 短 prompt、低并发 | 高 |
| 前缀缓存 | 前缀 block | 后缀独立 | 长 system prompt | 中 |
| PagedAttention | block 级 | 页表隔离 | 高并发、变长序列 | 低 |
| 完全共享 | 全序列 | 无隔离 | 相同输入批量推理 | 最低 |
5. 常见问题与排查技巧实录
5.1 缓存导致输出不一致怎么办
这是最常见的问题。带缓存和不带缓存的输出对不上，通常有三个原因：一是位置编码没处理好，缓存版本的位置索引要从当前长度开始算，而不是从 0 开始；二是因果掩码用错了，带缓存时 q 只有最后一个 token，不需要掩码，但如果误加了掩码，会把所有位置都遮住；三是浮点累积误差，序列很长时误差会放大，但一般 atol=1e-4 以内都算正常。
排查方法：先用短序列（长度 5 以内）对比，逐步加长，定位从哪一步开始出现偏差。如果短序列就不一致，基本是逻辑错误；如果长序列才不一致，大概率是浮点误差。
5.2 显存溢出但序列并不长
有时候序列长度才几百，显存就爆了。这种情况多半是 batch_size 或者 num_heads 设大了，或者 KV cache 的 dtype 没降下来。检查步骤：先算理论显存占用，和实际对比；如果实际远大于理论，检查是否有重复分配或者缓存没释放。
另一个隐蔽的原因是：有些框架会为每个请求预分配最大长度的缓存，即使实际序列很短。这种情况下，把预分配改成动态增长，显存能省一大半。
5.3 并发时延迟抖动大
并发场景下延迟抖动，通常是缓存管理策略导致的。比如多个请求竞争同一份共享前缀缓存，或者 block 分配器出现碎片，导致某些请求的缓存被频繁换入换出。
解决思路：一是限制共享缓存的并发访问，用读写锁保护；二是预分配一定数量的 block 作为缓冲池，减少动态分配频率；三是监控缓存命中率和碎片率，如果命中率低于阈值，考虑关闭共享。
避坑技巧：在压测时，不要只看平均延迟，一定要看 P99 和 P999。KV cache 的问题往往在高分位才暴露出来，平均延迟正常但尾部延迟爆炸的情况很常见。
5.4 缓存回收不及时导致内存泄漏
这个问题在长时间运行的服务里特别致命。表现是显存占用随时间缓慢增长，最终 OOM。原因通常是请求结束后缓存没被正确释放，或者引用计数有 bug。
排查方法：定期打印缓存池的 block 使用情况，观察是否有 block 长期处于“已分配但无引用”状态。如果有，检查释放逻辑是否覆盖了所有异常路径，比如请求超时、客户端断开、解码失败等。
6. 从实验到生产：几个值得记住的经验
口令实验做完之后，我对 KV cache 的理解从“知道有这么个东西”变成了“知道它为什么这么设计”。共享状态和隔离问题，本质上是一对矛盾：共享带来效率，隔离带来正确性。Transformer 的注意力机制天然适合共享历史 KV，因为历史是不变的；但每个请求的生成过程必须隔离，因为未来是独立的。
在实际部署中，我踩过的坑包括：前缀缓存命中率低导致收益为负、PagedAttention 的 block 大小设得不合理导致碎片严重、缓存 dtype 没降精度导致显存翻倍。这些问题的共同点是，它们都不会在功能测试中暴露，只有在高并发、长序列、长时间运行的场景下才会显现。
如果你正在做推理优化，我的建议是：先用最小实验把 KV cache 的行为摸清楚，再逐步引入共享和分页策略。不要一上来就上复杂方案，因为调试成本很高。另外，监控一定要做细，缓存命中率、block 利用率、P99 延迟这三个指标能帮你提前发现大部分问题。
最后分享一个小技巧：在对比带缓存和不带缓存的输出时，除了看数值差异，还可以看注意力权重的分布。如果缓存版本的注意力权重在历史位置上明显偏移，那多半是位置编码或者掩码的问题，比单纯看输出数值更容易定位。
