1. 从一句口令说起：共享状态到底共享了什么

第一次看到"共享状态，隔离问题"这个说法，是在一次内部技术分享上。当时主讲人抛出一个很朴素的问题：如果让同一个 Transformer 模型连续处理两段毫不相关的输入，它内部会不会"串味"？换句话说，前一段输入留下的中间状态，会不会污染后一段输入的计算结果？

这个问题听起来像是学术讨论，但落到工程上就是实打实的性能与正确性权衡。做过推理服务的人都知道，KV cache是绕不开的一环。自回归生成时，每生成一个新 token，都要拿它去和前面所有 token 的 Key、Value 做注意力计算。如果每次都把历史 token 重新算一遍 K 和 V，计算量会随序列长度平方级增长，延迟直接爆炸。于是大家把已经算过的 K、V 缓存下来，新 token 只算自己的那一份，然后和缓存拼接——这就是 KV cache 的由来。

问题就出在这个"缓存"上。缓存意味着状态被保留，状态被保留就意味着状态可能被共享。当多个请求并发进来，如果它们共用同一块缓存空间，或者缓存的生命周期管理出了岔子，就会出现一种很隐蔽的 bug：A 请求的上下文悄悄影响了 B 请求的输出。这种 bug 不会报错，不会崩溃，只会让模型"答非所问"，而且复现起来极其困难。

我拿一个口令实验来切入这个话题。所谓口令实验，就是给模型两段输入，第一段埋一个特定的"口令"（比如一个罕见词或特殊标记），第二段问一个和口令无关的问题，观察输出是否被第一段影响。如果隔离做得好，第二段应该完全不受第一段干扰；如果共享状态没管住，第二段就会"记得"第一段的东西。这个实验成本极低，但能一把撕开黑盒的一角，让你看到状态到底是怎么流动的。

这篇文章适合谁看？如果你正在做推理服务、写过带缓存的注意力实现、或者单纯想搞明白 KV cache 和注意力机制在工程上到底怎么落地，那接下来的内容应该对你有用。我会从设计思路讲到代码级细节，再到实际排查问题的记录，尽量把"为什么这么设计"讲透，而不是只丢一堆结论。

2. 整体设计思路：为什么共享和隔离是一对孪生问题

2.1 共享状态带来的收益到底有多大

先把账算清楚，不然没法理解为什么大家明知有风险还要共享。假设模型有 L 层，每层注意力头数为 H，每个头的维度为 d，序列长度为 n。那么单层单头的 KV cache 大小是 2 × n × d（K 和 V 各一份），整个模型的 cache 大小约为 2 × L × H × n × d × 精度字节数。

以一个中等规模模型为例，L=32，H=32，d=128，n=2048，用 FP16 存储：2 × 32 × 32 × 2048 × 128 × 2 字节 ≈ 1.07 GB。这还只是一个请求的缓存。如果并发 16 个请求，缓存占用就超过 17 GB，直接把显存吃满。所以工程上必须想办法让多个请求共享一部分状态，或者至少让缓存的分配和回收足够高效。

共享的收益体现在三个层面。第一是显存复用：多个请求如果前缀相同（比如相同的 system prompt），那这段前缀的 KV 完全可以只存一份，大家指针指过去就行。第二是计算复用：前缀只算一次，后续请求直接读缓存，省掉大量矩阵乘法。第三是调度灵活：有了统一的缓存池，才能做连续批处理（continuous batching），把不同长度的请求塞进同一批里跑，吞吐量能翻好几倍。

2.2 隔离问题为什么反而更难

共享的反面就是隔离。你共享得越激进，隔离就越难保证。这里有三类典型的隔离失效场景，我在实际项目里都踩过或者见别人踩过。

第一类是生命周期错配。请求 A 结束了，它的缓存被标记为可回收，但回收动作是异步的，还没真正清空，请求 B 就分配到了这块空间。如果 B 的前缀恰好和 A 有重叠，或者分配逻辑没有做清零，B 就会读到 A 的残留数据。这种问题在压力测试下才容易暴露，平时单请求跑得好好的。

第二类是前缀匹配的误判。为了复用前缀缓存，系统会维护一个前缀树或者哈希表。如果哈希碰撞了，或者匹配逻辑写错了（比如只比对了长度没比对内容），两个不同前缀的请求会被认为可以共享，结果就是张冠李戴。

第三类是注意力掩码的边界问题。即使缓存分配是对的，如果注意力计算时的 mask 没有正确隔离不同请求的 token，模型还是会在计算时"看到"不该看的位置。这类问题最隐蔽，因为缓存的物理隔离是好的，但逻辑隔离漏了。

提示：共享和隔离不是非此即彼的选择，而是一个连续谱。工程上的目标不是"完全隔离"，而是"在可接受的正确性风险下最大化共享收益"。所以你必须清楚自己的业务能容忍多大的风险。

2.3 口令实验的设计逻辑

口令实验的核心思路是构造一个可检测的状态泄漏信号。具体做法是：第一段输入里放一个模型在正常情况下绝不会在第二段输出里提到的词，比如一个随机生成的伪词 "Zylophane"。第二段输入是一个开放性问题，比如"请用一句话描述今天的天气"。如果隔离完好，输出里不应该出现 "Zylophane"；如果出现了，说明第一段的状态泄漏到了第二段。

这个实验的巧妙之处在于，它不依赖任何内部探针，纯靠输入输出就能判断。而且伪词的选择很关键：它必须是模型词表里存在的（否则会被切成多个 subword，信号变弱），但在自然语料里极少出现（否则模型本来就可能生成它）。我一般会从词表里挑那些出现频率排在末尾、但又是完整 token 的词。

实验还需要控制变量。比如固定温度参数为 0（贪心解码），避免随机性干扰；固定第二段输入，只改变第一段；跑多次取统计结果，而不是只看一次。这些细节决定了实验结论是否可信。

3. 核心细节解析：KV cache 与注意力机制的工程真相

3.1 KV cache 到底缓存了什么

很多人对 KV cache 的理解停留在"缓存 K 和 V"这个层面，但具体缓存的是哪一层的、什么形状的、怎么索引的，往往说不清楚。我拆开讲。

在标准的多头自注意力里，输入 X 经过三个线性变换得到 Q、K、V。假设 X 的形状是 [batch, seq_len, hidden]，那么 Q、K、V 的形状都是 [batch, seq_len, hidden]。然后按头数 H 拆开，变成 [batch, H, seq_len, d]。注意力计算是 softmax(QK^T / sqrt(d)) V。

自回归生成时，第 t 步只需要算当前 token 的 q_t，但需要和前面所有 token 的 K（即 K_1 到 K_t）做点积。所以缓存的是每一层、每一个头的 K 和 V，形状是 [batch, H, cached_len, d]。新来的 token 算出的 k_t、v_t 追加到缓存末尾，cached_len 加一。

这里有个容易忽略的点：缓存的精度。很多推理框架会把 KV cache 量化到 INT8 甚至 INT4 来省显存，但这会引入误差。误差在短序列上不明显，长序列上会累积。我实测过一个 7B 模型，KV cache 用 INT8 量化后，在 4K 长度上困惑度上升了约 0.3，在 8K 上上升到 0.8。如果你的业务对长文本质量敏感，这个代价要提前评估。

3.2 注意力掩码：隔离的逻辑防线

物理上缓存分开了，逻辑上还得靠 mask 隔离。因果自注意力（causal self-attention）的 mask 是一个下三角矩阵，保证位置 i 只能看到位置 j ≤ i。在带缓存的场景下，mask 的形状会变成 [1, 1, new_len, cached_len + new_len]，其中 new_len 是当前步新处理的 token 数（通常为 1）。

如果多个请求被拼进同一个 batch，每个请求的 cached_len 不同，就需要一个更复杂的 mask 来防止跨请求的注意力。常见做法是给每个请求分配独立的缓存块，然后在 mask 里把不属于当前请求的位置全部置为负无穷。这个 mask 的构造逻辑如果写错，就会出现"请求 A 的 token 注意到请求 B 的 token"的情况。

我见过一个真实的 bug：mask 的构造用了广播机制，但广播的维度搞反了，导致在某些 batch 组合下 mask 失效。这个 bug 只在 batch 内请求长度差异较大时触发，小流量测试根本发现不了。后来是靠口令实验才定位到的——第二段输出里莫名其妙出现了第一段的口令词。

3.3 前缀共享的实现细节

前缀共享是提升吞吐的关键手段。实现上通常用一棵前缀树（trie）来管理：每个节点代表一个 token，从根到某节点的路径就是一个前缀。新请求进来时，从根开始匹配，能匹配多长就复用多长的缓存。

这里有几个工程细节值得说。第一是块粒度。如果按 token 粒度共享，树的节点会非常多，管理开销大。所以实际系统通常按块（比如 16 个 token 一块）来共享，块内不拆分。第二是引用计数。一个缓存块可能被多个请求引用，必须用引用计数来管理回收，计数归零才能释放。第三是写时复制。如果两个请求共享了前缀，但后续生成分叉了，分叉点之后的缓存必须各自独立，不能互相覆盖。

注意：前缀共享的匹配必须是精确匹配，不能做模糊匹配。我见过有人为了提升命中率，用了编辑距离之类的近似匹配，结果两个语义相近但实际不同的前缀被共享了，输出直接错乱。这种优化得不偿失。

3.4 多头注意力里的状态分布

多头注意力把 hidden 维度拆成 H 份，每个头独立做注意力。这意味着 KV cache 也是按头分开存的。在隔离问题上，头与头之间一般不会串（因为每个头的 K、V 是独立计算的），但层与层之间的状态流动需要留意。

每一层的输出会作为下一层的输入，所以如果某一层的缓存被污染，污染会逐层放大。口令实验里如果发现泄漏，可以通过逐层注入探针来定位是哪一层出的问题。我的经验是，泄漏往往发生在靠前的层，因为靠前的层处理的是更原始的特征，缓存管理出问题时最先受影响。

另外，分组查询注意力（GQA）和多查询注意力（MQA）会改变 KV cache 的结构。GQA 里多个 Q 头共享一组 K、V 头，cache 大小能显著减小，但共享关系更复杂，隔离逻辑也要相应调整。如果你的模型用了 GQA，排查问题时不能套用标准 MHA 的思路。

4. 实操过程：从零搭一个口令实验

4.1 环境准备与模型加载

我用 PyTorch 加 HuggingFace 的 transformers 库来搭这个实验，模型选一个小规模的（比如 GPT-2 或者 Qwen 的小参数版本），方便在单卡上快速迭代。先装依赖：

pip install torch transformers accelerate

加载模型和分词器：

from transformers import AutoModelForCausalLM, AutoTokenizer import torch model_name = "gpt2" # 换成你要测的模型 tokenizer = AutoTokenizer.from_pretrained(model_name) model = AutoModelForCausalLM.from_pretrained( model_name, torch_dtype=torch.float16, device_map="auto" ) model.eval()

这里有个细节：device_map="auto"在多卡环境下会自动分配，但如果你要做精细的缓存控制，建议手动指定单卡，避免跨卡通信带来的额外变量。

4.2 构造口令与检测逻辑

口令词的选择我写了个小工具，从词表里筛出频率最低的一批完整 token：

def pick_rare_tokens(tokenizer, top_k=50): vocab = tokenizer.get_vocab() # 按 token id 排序，id 越大通常出现频率越低（因 BPE 合并顺序） sorted_tokens = sorted(vocab.items(), key=lambda x: x[1], reverse=True) candidates = [] for token, tid in sorted_tokens: # 过滤掉特殊 token 和含空格的 if token.startswith("<") or token.startswith("Ġ"): continue if len(token) < 4: continue candidates.append(token) if len(candidates) >= top_k: break return candidates

选出口令词后，构造两段输入。第一段是"请记住这个词：Zylophane。它没有任何含义。"第二段是"请用一句话描述今天的天气。"把两段拼起来喂给模型，观察输出。

检测逻辑很简单：看输出里是否包含口令词（大小写不敏感）。为了排除模型本来就会生成这个词的可能，还要跑一个对照组——第一段换成不含口令词的普通句子，看第二段输出是否出现该词。如果对照组不出现、实验组出现，就说明存在泄漏。

4.3 缓存隔离的代码级验证

光看输入输出还不够，我想直接看缓存。HuggingFace 的past_key_values就是 KV cache，可以在生成过程中打印它的形状和内容摘要：

def inspect_cache(past_key_values): for layer_idx, (k, v) in enumerate(past_key_values): print(f"Layer {layer_idx}: K shape={k.shape}, V shape={v.shape}") print(f" K mean={k.float().mean().item():.4f}, " f"K std={k.float().std().item():.4f}")

跑两次生成，一次带缓存一次不带，对比输出是否一致。如果带缓存的输出和不带缓存的输出不同，那缓存逻辑就有问题。这是最基本的正确性检查，但很多人跳过这一步直接上并发测试，结果问题定位起来更麻烦。

4.4 并发场景下的隔离测试

单请求没问题不代表并发没问题。我用多线程模拟并发，每个线程发一个带不同口令的请求，然后检查每个请求的输出是否只受自己的口令影响：

import threading results = {} lock = threading.Lock() def worker(req_id, passphrase): prompt = f"请记住这个词：{passphrase}。它没有任何含义。请用一句话描述今天的天气。" inputs = tokenizer(prompt, return_tensors="pt").to(model.device) with torch.no_grad(): output = model.generate(**inputs, max_new_tokens=30, do_sample=False) text = tokenizer.decode(output[0], skip_special_tokens=True) with lock: results[req_id] = (passphrase, text) threads = [] for i in range(8): t = threading.Thread(target=worker, args=(i, f"Zylophane{i}")) threads.append(t) t.start() for t in threads: t.join() # 检查交叉污染 for req_id, (own_pass, text) in results.items(): for other_id, (other_pass, _) in results.items(): if other_id != req_id and other_pass in text: print(f"泄漏！请求 {req_id} 的输出里出现了请求 {other_id} 的口令 {other_pass}")

这个测试跑下来，如果框架的隔离做得好，应该零泄漏。如果有泄漏，就能精确定位是哪两个请求之间串了。

4.5 参数选择与性能权衡

实验里几个参数需要调。max_new_tokens不能太小，否则模型还没"展开"就结束了，泄漏信号可能出不来；也不能太大，否则实验时间拉长。我一般设 30 到 50。温度设 0 保证可复现。batch size 从 1 开始，逐步加到显存上限，观察泄漏率是否随 batch 增大而上升。

还有一个容易被忽略的参数是缓存清理策略。有些框架在请求结束后不会立即清空缓存，而是标记为可复用。这种策略下，如果下一个请求的前缀和上一个请求有重叠，就可能读到残留。我在实验里会特意构造这种"前缀重叠"的场景来测试。

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

5.1 泄漏问题的排查速查表

5.2 几个我踩过的坑

第一个坑是分词器不一致。我用两个不同的分词器分别处理第一段和第二段，结果 token 边界对不上，缓存拼接时错位。这个 bug 花了我半天才定位到，因为输出看起来"只是有点怪"，不像明显的错误。教训是：整个流程必须用同一个分词器。

第二个坑是位置编码的连续性。带缓存生成时，新 token 的位置编码必须接在缓存长度之后，不能从 0 重新开始。我有一次忘了传position_ids，模型用了默认的从 0 开始，结果注意力计算全乱了。这个问题的表现是输出重复、循环，很容易误判成模型本身的问题。

第三个坑是多线程下的 GIL 假象。Python 的 GIL 让很多人以为多线程不会有并发问题，但实际上 PyTorch 的底层计算会释放 GIL，缓存操作仍然可能竞争。我一开始用多线程测没发现问题，后来换成多进程才复现出来。所以并发测试最好用多进程，或者用真正的异步框架。

提示：排查这类问题时，日志要打全。至少记录请求 ID、缓存块 ID、前缀哈希、mask 形状、输出摘要。出问题时能直接对比，比事后猜要快得多。

5.3 一个反直觉的发现

实验做到后面，我发现一个反直觉的现象：泄漏率并不总是随并发数单调上升。在某个并发区间（比如 4 到 8），泄漏率反而比低并发时低。后来分析发现，这是因为低并发时缓存分配器倾向于复用同一块内存，残留概率高；并发数上去后，分配器被迫开辟新块，反而减少了复用。这个发现说明，隔离问题不能只看"并发高不高"，还要看分配器的具体策略。

这个现象也提醒我，做性能优化时不能想当然。共享和隔离的平衡点，得靠实测数据来找，不能靠直觉。

6. 从口令实验延伸出去的思考

口令实验只是一个起点。它揭示的问题——共享状态与隔离的张力——在很多地方都存在。比如数据库连接池，连接被复用时如果上一个事务的状态没清干净，下一个事务就会读到脏数据。比如浏览器缓存，不同站点的资源如果缓存键设计不当，可能互相覆盖。再比如分布式系统里的会话状态，节点间同步不及时就会导致一致性问题。

回到 Transformer 和 KV cache，我觉得工程上最实用的原则是：把隔离做成默认，把共享做成显式优化。也就是说，系统默认每个请求独立分配缓存，只有在明确知道可以共享（比如前缀完全相同）时才启用共享，并且共享的每一步都要有校验。这样虽然牺牲了一点性能，但正确性有保障。等系统稳定了，再逐步放宽共享条件，用实验数据来指导优化。

另外，监控很重要。生产环境里应该持续跑一个轻量级的口令实验，作为健康检查的一部分。一旦发现泄漏率上升，立刻告警。这种主动探测比等用户报障要靠谱得多。

最后分享一个小技巧：如果你怀疑某个框架有隔离问题，但又没有源码，可以用"差分测试"——同一个请求跑两次，一次单独跑，一次和其他请求混跑，对比输出。如果不同，就说明混跑引入了干扰。这个方法不需要任何内部信息，纯黑盒就能用，非常适合快速验证。

我在实际项目里用这套方法定位过至少三个隐蔽的缓存 bug，每次都是靠口令实验先发现异常，再用差分测试缩小范围，最后看代码确认根因。整个过程虽然繁琐，但比盲目猜测高效得多。如果你也在做推理服务，建议把这套实验流程固化下来，作为上线前的必过项。