1. 从一句口令实验说起：共享状态到底藏了什么
第一次看到“共享状态，隔离问题”这个说法，是在一个做推理优化的朋友群里。有人丢了一张图，说用同一段口令跑两次模型，第一次和第二次的输出居然不一样，但把中间某个缓存清掉之后，结果又稳定了。当时群里讨论得很热闹，有人说是随机种子的问题，有人说是浮点累加误差，还有人直接甩了一句“你去看KV cache就懂了”。
这个实验本身不复杂，但它像一根针，扎破了一个很多人默认成立的假设：同一个模型、同一段输入、同一套参数，输出应该是确定的。可现实是，一旦你开始做自回归生成，一旦你引入了KV cache这种“共享状态”，事情就没那么单纯了。共享状态带来了速度，也带来了隔离问题。你以为是同一个模型在回答，其实可能是带着不同历史包袱的模型在回答。
这篇文章想聊的就是这件事。我会从KV cache和Transformer注意力的基本机制讲起，拆解共享状态为什么会导致隔离问题，然后给出可复现的实验步骤、排查思路和工程上的处理方案。适合正在做推理服务、模型部署、或者单纯想搞明白Transformer推理为什么“有时候不太对劲”的读者。不需要你手推反向传播，但需要你对自注意力有一个大概的印象。
先说结论：KV cache是推理加速的核心手段，但它本质上是一种跨请求、跨步骤的状态共享。只要共享边界没划清楚，隔离问题就会以各种奇怪的形式冒出来。口令实验只是其中一种表现，更常见的是多轮对话串味、批量推理结果漂移、流式输出前后不一致。下面我们一层一层拆。
2. KV cache与注意力机制：共享状态是怎么被引入的
2.1 自回归生成为什么需要缓存
Transformer解码器生成文本的方式是自回归的：每一步只预测下一个token，然后把预测结果拼到输入后面，再预测下一个。如果没有缓存，第t步就要把前面t-1个token全部重新算一遍注意力。这意味着生成100个token，计算量大致是1+2+3+...+100的量级，平方级增长。
KV cache的思路很直接：前面token的Key和Value在每一步里是不变的，因为因果掩码保证了每个位置只能看到自己及之前的位置。既然不变，那就存下来，下一步直接拿来用，只计算新token的Query、Key、Value。这样每步的计算量从O(t)降到O(1)（相对于历史长度），整体从平方级降到线性级。
用生活类比：你在做一道需要反复查前面条件的题。没有缓存的时候，每写一步都要把前面所有条件重新读一遍。有了缓存，你把这些条件抄在一张纸上，每步只看新条件，然后从纸上取旧条件。纸就是KV cache。
2.2 缓存里到底存了什么
具体来说，对于每一层注意力，缓存里存的是历史所有token的Key矩阵和Value矩阵。假设模型有L层，每层有H个注意力头，每个头维度是d，当前序列长度是n，那么KV cache的大小大致是：
2 × L × H × n × d × 精度字节数
以常见的7B模型为例，L=32，H=32，d=128，n=2048，fp16精度，单条序列的KV cache大约是2×32×32×2048×128×2字节，算下来接近1GB。这也是为什么长上下文推理对显存压力这么大。
关键点在于：这个缓存是跟“当前这条序列”绑定的。如果多条序列共享同一块缓存，或者缓存没有正确重置，就会出现状态污染。口令实验里那种“第一次和第二次不一样”，很多时候就是缓存复用边界没处理好。
2.3 注意力机制里的因果掩码与位置编码
要理解隔离问题，还得看一眼因果掩码和位置编码。因果掩码保证位置i只能attend到位置≤i的token。位置编码则告诉模型每个token在序列中的位置。在KV cache场景下，新token的位置编码必须接在历史长度之后，不能从0重新开始。
如果位置编码算错了，比如每次生成都从0开始，模型会以为自己在生成序列的开头，注意力分布会完全乱掉。这种错误在批量推理里特别隐蔽，因为不同序列的长度不一样，位置偏移量也不一样。共享状态的问题往往不是缓存本身错了，而是缓存的元信息（长度、位置、序列ID）没有正确隔离。
3. 口令实验的完整复现与现象拆解
3.1 实验设计：同一口令跑两次
口令实验的设计很简单：准备一段固定的提示词，比如“请重复以下口令：ABCD-1234”，然后让模型生成固定长度的输出。第一次跑，记录输出。清空所有状态，第二次跑，记录输出。对比两次结果。
如果模型是确定性的，两次应该完全一样。但实际操作中，很多人会发现两次输出有细微差别，比如标点、空格、或者某个token的替换。更诡异的是，有时候第一次和第二次一样，但第三次不一样。这种非确定性让人很头疼。
我自己的复现环境是PyTorch + HuggingFace Transformers，模型用了一个小尺寸的GPT类模型，方便在单卡上跑。关键配置是do_sample=False，也就是贪心解码，理论上应该完全确定。但即便如此，两次输出仍然可能不同。
3.2 现象记录：差异出现在哪里
我把两次输出做了token级对比，发现差异通常出现在以下几个位置：
- 序列末尾的几个token，尤其是当生成长度接近max_length时
- 标点符号附近，比如逗号和句号的切换
- 重复模式开始的地方，比如模型开始重复某个短语时
这些位置有一个共同特点：模型的输出概率分布比较平坦，top-1和top-2的差距很小。在这种情况下，浮点运算的微小差异就可能导致argmax结果不同。而浮点差异的来源，恰恰和KV cache的共享状态有关。
3.3 根因分析：共享状态如何导致非确定性
第一个来源是批量推理中的padding。当多条序列一起推理时，短序列需要padding到长序列的长度。padding位置的KV cache如果没被正确掩码，就会参与注意力计算，导致结果偏移。即使掩码正确，不同batch组成也会改变浮点累加顺序，因为矩阵乘法的分块方式可能不同。
第二个来源是缓存的复用与重置。有些推理框架为了省显存，会复用KV cache的buffer。如果上一条序列的缓存没有完全清零，残留值会影响下一条序列。这种问题在单条序列测试时不容易发现，一到并发场景就暴露。
第三个来源是位置编码的累积误差。在长序列生成中，位置编码的数值会变大，浮点精度相对下降。如果两次运行的位置编码计算路径不同（比如一次用了缓存，一次没用），结果就会有差异。
注意：非确定性不一定是bug。浮点运算本身就不满足结合律，并行度不同、分块不同，结果就可能不同。但共享状态会放大这种非确定性，让它从“可忽略的数值噪声”变成“可观察的输出差异”。
4. 隔离问题的工程表现与排查方法
4.1 多轮对话串味：最典型的隔离失败
多轮对话是KV cache共享状态最直接的应用场景。每一轮对话，历史对话的KV cache会被保留，新问题接在后面。如果多个用户共享同一个模型实例，而缓存没有按用户隔离，就会出现A用户的对话历史影响B用户回答的情况。
这种串味有时候很隐蔽。比如A用户之前聊了天气，B用户问“那明天呢”，模型可能会接着天气话题回答，而不是问B用户“你指什么”。这是因为B用户的请求复用了A用户的缓存，模型看到了不属于B用户的上下文。
排查方法：在推理服务里给每个请求打上唯一的session ID，缓存按session ID隔离。如果发现串味，先检查session ID是否在请求间被复用，再检查缓存清理逻辑是否在session结束时执行。
4.2 批量推理结果漂移：batch组成影响输出
批量推理是提升吞吐的常用手段。但同一个请求，放在不同的batch里，输出可能不同。原因前面提过：padding、浮点累加顺序、缓存buffer复用。
我做过一个对比实验：同一个请求，分别单独跑、和一条短序列一起跑、和一条长序列一起跑。三次输出的token序列不完全一致。差异不大，但对于需要严格可复现的场景（比如评测、回归测试），这就是问题。
解决办法有两个方向：一是固定batch组成，评测时用相同的batch配置；二是在注意力计算中显式处理padding掩码，确保padding位置不参与。后者更根本，但需要改推理代码。
4.3 流式输出前后不一致：缓存与重计算的冲突
流式输出场景下，用户先看到一部分token，然后可能触发某种重计算（比如beam search的剪枝、或者长度惩罚调整）。如果重计算时没有正确回滚KV cache，后续输出就会和已经展示的部分矛盾。
这种问题在交互式应用里很致命，因为用户已经看到了前面的内容，后面突然接不上，体验很差。排查时重点看：重计算触发时，缓存是否被截断到正确的长度，位置编码是否同步回滚。
4.4 排查速查表
| 现象 | 可能原因 | 排查动作 |
|---|---|---|
| 两次输出不一致 | 浮点非确定性、缓存复用 | 固定batch、清空缓存重跑 |
| 多用户串味 | session未隔离、缓存未清理 | 检查session ID和缓存生命周期 |
| batch内结果漂移 | padding掩码、累加顺序 | 对比单独跑和批量跑的输出 |
| 流式输出断裂 | 重计算未回滚缓存 | 检查缓存截断和位置编码同步 |
| 长序列后期乱码 | 位置编码溢出、精度下降 | 检查位置编码范围和精度 |
5. 工程上的隔离方案与实操建议
5.1 缓存隔离的三个层次
第一层是请求级隔离。每个请求独立分配KV cache，请求结束立即释放。这是最基本的，但显存开销大。适合对隔离要求极高的场景，比如多租户SaaS。
第二层是会话级隔离。同一会话内的多轮请求共享缓存，不同会话之间隔离。这是最常见的方案，兼顾了多轮对话的效率和用户间的隔离。实现上需要维护session到cache的映射，并设置合理的过期时间。
第三层是批次级隔离。同一批次内的序列共享计算图，但缓存按序列索引隔离。这是批量推理的标配，关键是padding掩码和位置编码要按序列单独处理。
5.2 位置编码的正确处理
位置编码的隔离经常被忽略。在批量推理中，每条序列的起始位置可能不同。如果统一从0开始编码，短序列的位置信息就会错位。正确做法是：为每条序列维护一个位置偏移量，新token的位置编码等于偏移量加当前步数。
在HuggingFace的实现里，position_ids参数就是干这个的。如果你自己写推理循环，记得手动传position_ids，不要依赖默认行为。默认行为在单条序列时没问题，批量时容易出错。
5.3 缓存清理的时机与方式
缓存清理不是简单的del或置零。在GPU上，显存释放有延迟，而且如果buffer被复用，置零操作可能被优化掉。稳妥的做法是：
- 请求结束时，将缓存对应的序列长度标记为0，而不是物理删除
- 下次分配时，优先复用长度标记为0的buffer
- 定期做一次全量清理，防止碎片化
另外，注意PyTorch的torch.cuda.empty_cache()只是释放未使用的缓存，不会清理正在使用的tensor。别指望它解决隔离问题。
5.4 可复现性的保障措施
如果你需要严格可复现的输出，比如做评测或回归测试，建议：
- 固定随机种子，包括Python、NumPy、PyTorch、CUDA的种子
- 关闭所有非确定性算子，设置
torch.use_deterministic_algorithms(True) - 固定batch组成和序列顺序
- 每次测试前完全重置模型状态和缓存
- 记录完整的输入配置和版本信息
这些措施不能保证100%可复现，因为GPU浮点运算本身有非确定性，但能把差异降到可接受范围。
实操心得：我在做推理服务时，会给每个请求加一个
request_id，日志里记录这个ID对应的缓存分配、位置偏移、清理时间。出问题时，用request_id串起整条链路，比盲猜快得多。
6. 从口令实验到系统设计：共享与隔离的平衡
口令实验看起来是个小问题，但它揭示的是推理系统设计里的一个核心矛盾：共享状态带来效率，隔离状态带来正确性。KV cache是共享状态的典型代表，它让自回归生成从平方级降到线性级，但也引入了跨请求、跨步骤的耦合。
在实际系统里，这个矛盾无处不在。批处理是共享，但batch内序列需要隔离；多轮对话是共享，但用户之间需要隔离；流式输出是共享，但重计算需要回滚。每一个共享点，都要想清楚隔离边界在哪里。
我的经验是：先保证正确性，再优化效率。初期可以每个请求独立缓存，虽然显存吃紧，但问题少。等稳定了，再逐步引入会话级共享、批次级共享，每引入一层共享，就加一层隔离测试。测试用例要覆盖：单请求多次运行、多请求并发、长短序列混合、流式中断重试。
另外，别忽视日志和监控。缓存命中率、缓存大小、请求延迟、输出一致性指标，这些数据能帮你提前发现隔离问题。等到用户投诉再排查，成本就高多了。
最后分享一个小技巧：如果你怀疑是KV cache导致的非确定性，可以做一个对照实验——一次用缓存，一次不用缓存（每步重算全部历史），对比输出。如果不用缓存时输出稳定，用缓存时不稳定，那问题基本就锁定在缓存的状态管理上了。这个实验虽然慢，但定位问题很准。
这个方向后续还可以往推理框架的缓存抽象层设计、多租户场景下的缓存配额管理、以及长上下文场景下的缓存压缩与隔离结合等方向扩展。每个方向都有不少坑，也有不少机会。
