共享状态隔离问题：KV cache串扰实验与推理优化方案

1. 从一场口令实验说起：共享状态到底藏了什么猫腻

第一次看到“共享状态，隔离问题”这个说法，是在一个做推理优化的朋友群里。有人丢了一张图，说同一个模型、同一段输入，跑两遍结果居然不一样，但把并发关掉就稳了。底下有人回了一句：“你查查 KV cache 是不是被串了。”当时我对这个方向的理解还停留在“缓存就是加速用的”这个层面，直到自己动手复现了一遍，才发现这里面的水比想象中深得多。

所谓“口令实验”，其实就是一个极简的探针：给模型喂一段带有明显区分特征的输入，比如两段完全不同的前缀，然后观察在共享缓存的情况下，第二段输入的解码结果会不会被第一段“污染”。这个实验之所以有效，是因为 Transformer 的自回归解码天然依赖历史 token 的键值对，也就是我们常说的 KV cache。一旦这个缓存被多个请求共享而没有做好隔离，后面的请求就会“看到”前面请求的上下文，输出自然就乱了。

这件事的核心价值在于，它把一个大模型推理系统里最容易被忽视的角落——状态管理——用一个很小的实验暴露了出来。适合谁来参考？如果你正在做推理服务、写过带缓存的解码循环、或者单纯好奇“为什么同样的输入两次结果不一样”，这篇内容都能给你一些可以直接上手的东西。我不打算讲太多论文里的公式，而是从实操角度，把共享状态的风险、隔离的必要性、以及 KV cache 在 Transformer 解码里的真实角色，一层层拆开。

2. 核心概念拆解：KV cache、注意力与共享状态的三角关系

2.1 KV cache 到底是什么，为什么它会被共享

先把这个概念说清楚。Transformer 解码是逐 token 生成的，每生成一个新 token，都要拿当前 token 的 query 去和前面所有 token 的 key 做点积，算出注意力权重，再对 value 加权求和。如果每步都重新算一遍前面所有 token 的 key 和 value，计算量会随着序列长度平方增长。KV cache 的做法很直接：把已经算过的 key 和 value 存下来，下一步直接复用，只算新 token 的那一份。

这个机制本身没问题，问题出在“存哪里”和“谁能读”。在单请求场景下，缓存属于这个请求自己，读写都是私有的。但一旦系统想提升吞吐，就会考虑让多个请求共享一部分缓存，比如相同的前缀、相同的系统提示词。共享的初衷是省显存、省计算，但如果没有严格的隔离边界，A 请求的缓存就可能被 B 请求读到，这就是“共享状态”带来的“隔离问题”。

我实测过一个最小复现：构造两个请求，前缀分别是“苹果是一种”和“香蕉是一种”，让它们共享同一块 KV cache 区域。结果第二个请求在生成时，注意力权重里明显混入了第一个请求的 token 信息，输出开始偏向水果相关的描述。这个现象在注意力热力图上看得非常清楚，某些本不该被关注的位置出现了异常高的权重。

2.2 注意力机制里的状态边界在哪里

注意力机制本身是一个加权求和的过程，它的输入是 query、key、value 三组向量。在解码阶段，query 来自当前 token，key 和 value 来自历史。所谓“状态边界”，其实就是：哪些 key/value 属于当前请求，哪些不属于。这个边界在数学上很清晰，但在工程实现里很容易被模糊掉，尤其是当缓存被设计成一块连续内存、用偏移量来索引的时候。

我见过一种常见的实现方式：用一个大的 tensor 存所有请求的 KV，然后用一个 position 数组记录每个请求写到哪了。如果这个 position 数组在并发下没有正确同步，两个请求就可能写到同一个位置，或者读的时候读到了别人的数据。这不是注意力机制本身的问题，而是状态管理的问题。注意力只是忠实地根据你给的 key/value 做加权，你给它脏数据，它就给你脏输出。

注意：判断缓存是否被串，不要只看最终输出。更可靠的方法是打印每一步的注意力权重，观察是否有异常位置被激活。如果某个位置的权重明显偏离预期，基本可以确定缓存边界出了问题。

2.3 共享与隔离的取舍：为什么不能一刀切

有人可能会说，那就完全不共享，每个请求独立缓存，不就没事了。理论上可以，但代价是显存占用随并发数线性增长，长序列场景下很容易爆。共享的价值在于，相同的前缀只需要存一份，多个请求复用，显存和计算都能省下来。所以现实中的方案不是“共不共享”，而是“共享什么、隔离什么”。

一个比较稳妥的思路是：只共享那些确定不会变的部分，比如系统提示词、固定的模板前缀，并且这部分缓存在写入后设为只读。每个请求自己的生成部分，严格私有，用独立的偏移区间。这样既拿到了共享的收益，又避免了读写冲突。我在实际项目里用过这种分层缓存的方案，显存比全私有省了大约三成，同时没有再出现串扰。

3. 口令实验的完整实操：从构造输入到观察污染

3.1 实验环境与最小依赖

这个实验不需要完整的训练框架，用 PyTorch 加一个预训练的小模型就够。我选的是一个小型 Transformer 解码器，层数不多，方便打印中间状态。依赖就三个：torch、transformers、numpy。如果你手头有现成的推理服务，也可以直接在服务层做，但那样观察不到注意力权重，所以我建议至少在本地跑一遍底层。

环境准备好之后，第一步是构造两段有明显区分度的输入。我用的是一组对照：请求 A 的前缀是“红色的苹果”，请求 B 的前缀是“蓝色的天空”。这两个前缀在语义上距离很远，一旦发生串扰，输出会立刻变得不伦不类，很容易判断。

3.2 构造共享缓存并注入请求

接下来是关键步骤：手动构造一块共享的 KV cache，然后依次把两个请求写进去。具体做法是初始化一个形状为[num_layers, 2, max_seq_len, num_heads, head_dim]的 tensor，第一维是层，第二维区分 key 和 value，后面是序列长度、头数和头维度。这个形状是常见实现里的标准布局，不同框架可能略有差异，但逻辑一致。

写入的时候，请求 A 从位置 0 开始写，请求 B 如果也从头写，就会覆盖 A 的数据。为了模拟“共享但未隔离”的场景，我故意让 B 从位置 0 开始写，但读取时两个请求都用同一块缓存。这样在 B 解码时，它的注意力会同时看到 A 和 B 的 key/value，污染就发生了。

import torch # 假设 num_layers=4, num_heads=8, head_dim=64, max_seq_len=128 num_layers, num_heads, head_dim, max_seq_len = 4, 8, 64, 128 kv_cache = torch.zeros(num_layers, 2, max_seq_len, num_heads, head_dim) # 请求 A 写入位置 0 到 9 kv_cache[:, :, 0:10, :, :] = request_a_kv # 请求 B 也写入位置 0 到 9，覆盖了 A kv_cache[:, :, 0:10, :, :] = request_b_kv # 此时 B 解码，读取整块缓存，实际看到的是 B 自己的数据 # 但如果 A 还在并发解码，它读到的就是 B 的数据

上面这段代码展示的就是最典型的串扰场景：两个请求写同一块区域，后写的覆盖先写的。如果 A 和 B 是并发执行的，A 在后续解码步骤里读到的就是 B 的 key/value，输出必然错乱。

3.3 观察注意力权重与输出变化

写入完成后，让 B 继续解码几个 token，同时打印每一层的注意力权重。正常情况下，B 的注意力应该集中在自己的前缀 token 上。但在共享未隔离的情况下，你会发现某些头对 A 的位置也产生了不低的权重。我实测时，在第 2 层的第 5 个头里，A 的“红色”这个 token 拿到了接近 0.3 的权重，而它本不该出现在 B 的上下文里。

输出的变化更直观。B 原本应该生成“天空是蓝色的”这类内容，结果因为混入了“红色”“苹果”的信息，开始生成“天空是红色的苹果”这种明显错误的句子。这个结果虽然看起来有点滑稽，但它精确地说明了：共享状态如果没有隔离，注意力机制会忠实地把脏数据整合进输出。

提示：观察注意力权重时，建议按头、按层分别看。有些头对串扰更敏感，有些层几乎不受影响。定位到敏感层之后，可以针对性地加隔离检查。

4. 隔离方案设计与落地：几种可参考的工程做法

4.1 物理隔离：每个请求独立缓存

最直接的做法是每个请求分配独立的 KV cache，互不干扰。实现上就是每个请求持有一个自己的 tensor，生命周期和请求绑定，请求结束就释放。这种方案的好处是逻辑简单，几乎不会出错。坏处是显存占用高，尤其是在高并发、长序列的场景下，显存很快就不够用。

我做过一个粗略的估算：假设模型有 32 层，每层 32 个头，头维度 128，序列长度 2048，那么单个请求的 KV cache 大约是32 * 2 * 2048 * 32 * 128 * 2字节，算下来接近 1GB。如果并发 16 个请求，就是 16GB，这还没算模型本身的权重。所以物理隔离适合并发不高、或者显存非常充裕的场景。

4.2 逻辑隔离：共享池加偏移索引

更常见的做法是维护一个共享的缓存池，但每个请求有自己的偏移区间和长度记录。写入时只写自己的区间，读取时只读自己的区间。这样显存只需要按最大并发总量来分配，而不是每个请求一份。关键在于偏移索引的管理必须严格，任何越界读写都要被拦截。

我在实现时用了一个简单的结构：一个free_blocks列表记录空闲块，一个request_map记录每个请求占用的块。分配时从空闲块里取，释放时归还。读取时根据请求 ID 查到对应的块，只从这些块里读。这套逻辑不复杂，但需要处理好并发下的锁，否则两个请求可能同时拿到同一个块。

4.3 只读共享：前缀缓存的安全复用

如果确实想共享，最安全的做法是只共享只读部分。比如系统提示词、固定的指令模板，这些内容在所有请求里都一样，缓存一份，所有请求都可以读，但谁都不能写。每个请求自己的生成部分，仍然走私有缓存。这样既省了前缀的重复计算，又避免了写冲突。

实现上，可以把缓存分成两段：前缀段和生成段。前缀段在第一个请求写入后标记为只读，后续请求直接引用。生成段每个请求独立。读取时，注意力同时看前缀段和自己的生成段，但前缀段的内容对所有请求都是一样的，所以不会引入污染。这个方案我在实际服务里用过，效果比较稳，显存节省明显，而且没有出现过串扰。

5. 常见问题与排查技巧实录

5.1 输出不稳定但找不到原因

这是最常见的问题。表现是同样的输入，有时候输出正常，有时候输出乱码或者语义漂移。排查的第一步是确认是否开启了并发。如果关掉并发就正常，基本可以锁定是共享状态的问题。第二步是检查缓存的写入和读取范围，打印每个请求的偏移区间，看是否有重叠。第三步是打印注意力权重，定位到具体是哪一层、哪个头出现了异常。

我踩过的一个坑是：偏移区间本身没有重叠，但缓存的初始化没有清零，残留了上一个请求的数据。这种情况下，即使区间正确，读到的也是脏数据。所以每次分配缓存块时，一定要显式清零，或者确保写入覆盖了全部读取范围。

5.2 并发下性能不升反降

有时候加了共享缓存，吞吐反而下降了。原因可能是锁竞争太激烈，或者缓存池的分配逻辑太慢。我遇到过一种情况：每次读取缓存都要遍历整个request_map来查偏移，请求一多，这个查找就成了瓶颈。后来改成用哈希表直接索引，性能立刻上来了。

另一个可能的原因是缓存碎片化。频繁分配和释放不同大小的块，会导致空闲块分散，大请求找不到连续空间，只能等待或者回退到慢路径。解决办法是预分配固定大小的块，按块管理，而不是按字节管理。这样虽然会浪费一点空间，但分配和释放都快很多。

5.3 前缀共享导致语义漂移

只读共享听起来很安全，但如果前缀本身包含了可变信息，就会出问题。比如你把用户 ID 也放进了前缀，那不同用户共享同一个前缀缓存，就会互相看到对方的 ID。所以共享的前缀必须是真正全局一致的内容，任何跟请求相关的信息都不能放进去。

注意：判断一个前缀能不能共享，标准是“它是否对所有请求都完全相同”。只要有一个 token 不同，就不能共享，否则就会引入污染。

5.4 排查速查表

6. 从口令实验延伸出去：状态管理在推理系统里的位置

这场口令实验看起来只是一个小把戏，但它揭示的问题在推理系统里非常普遍。Transformer 的解码过程本质上是一个状态机，KV cache 就是这个状态机的内存。状态管理做得好不好，直接决定了系统的正确性和性能。很多线上事故，追到最后都是状态边界没划清楚。

我个人在实际操作中的体会是，不要等到出了问题再去查缓存。在设计阶段就把隔离边界画出来：哪些状态是请求私有的，哪些是可以共享的，共享的状态怎么保证只读，私有的状态怎么保证不越界。把这些想清楚，后面写代码会顺很多。另外，注意力权重是一个非常好的调试工具，它能把缓存里的问题可视化出来，比只看输出要直观得多。

如果你也在做推理相关的优化，建议自己动手跑一遍这个口令实验。不需要多复杂的代码，一个小模型、两段输入、一块共享缓存，就能把问题复现出来。跑完之后，你对 KV cache 和注意力机制的理解会完全不一样。