1. 从"共享状态"这个词说起：一个被忽视的工程直觉
"共享状态，隔离问题"——这八个字第一次出现在我脑子里，是在调试一个多轮对话服务的时候。当时线上出现了一个非常诡异的现象：同一个批次里的请求，A 用户的回答里偶尔会混进 B 用户上一轮的上下文片段。日志里每个请求的输入都是干净的，模型输出却"串味"了。排查了大半天，最后定位到的根因，是推理引擎里 KV cache 的复用逻辑在批量调度时把不同序列的缓存块错误地共享了。
这件事让我意识到一个很朴素但经常被忽略的道理：在大模型推理系统里，"共享"和"隔离"是一对永远在拉扯的矛盾。共享是为了省显存、提吞吐；隔离是为了保证每个请求的语义边界不被污染。而 KV cache，恰恰是这对矛盾最集中的战场。
这篇内容我想聊的不是某个具体框架的 API 怎么调，而是围绕 KV cache、Transformer 注意力机制、批量调度这几个关键词，把"共享状态"这件事从原理到实操拆开讲一遍。适合谁看？如果你正在做 LLM 推理服务的部署、优化，或者单纯想搞明白"为什么我的显存明明够，吞吐却上不去"，又或者你被"多轮对话串上下文"这类问题折磨过，那这篇应该能给你一些可以直接抄作业的思路。我会尽量用生活化的类比把注意力机制和缓存复用的原理讲清楚，也会给出可复现的排查路径和参数计算。
先说结论性的判断：KV cache 的本质是"用显存换计算"，而批量调度的本质是"用调度复杂度换硬件利用率"，两者叠加之后，任何一处状态共享的边界没划清楚，都会以"看起来像模型抽风"的形式暴露出来。理解了这一点，后面所有的坑都好解释了。
2. KV cache 到底缓存了什么：把注意力机制拆到能算账的程度
2.1 自注意力里那三个矩阵，为什么只有两个需要缓存
要讲清楚 KV cache，得先把自注意力（self-attention）的计算过程摆出来。给定输入序列的隐藏状态，经过三个线性变换得到 Query（Q）、Key（K）、Value（V）三个矩阵。注意力的计算可以概括成一句话：用 Q 去和所有 K 做点积算相似度，归一化之后作为权重，去加权求和所有的 V。
用生活类比：你去图书馆找资料，Q 是你脑子里的"问题"，K 是每本书的"标签/索引"，V 是书里的"实际内容"。你拿问题去和每本书的标签比对（Q·K），比对得分高的书，你就多读一点它的内容（加权 V）。
关键点来了：在自回归生成（autoregressive decoding）里，每生成一个新 token，这个新 token 的 Q、K、V 都要算，但前面所有 token 的 K 和 V 是不变的——因为它们只依赖于前面的输入，不依赖于当前生成到哪一步。而 Q 是当前这一步才产生的，用完即弃。
所以缓存什么？缓存 K 和 V。这就是 KV cache 名字的由来。Q 不需要缓存，因为每一步的 Q 只服务于当前这一步。
这里有个很多人第一次接触时会卡住的点：为什么不是缓存整个注意力输出？因为注意力输出依赖于当前 Q，而 Q 每步都变，缓存了也没用。真正"跨步复用"的只有 K 和 V。
2.2 显存账本：KV cache 到底吃掉多少显存
光说"缓存 K 和 V"太抽象，我们算一笔账。KV cache 的显存占用公式大致是：
KV cache 显存 = 2 × batch_size × seq_len × num_layers × num_kv_heads × head_dim × dtype_bytes其中那个 2 就是 K 和 V 两份。我拿一个常见的配置举例：假设模型有 32 层，隐藏维度 4096，注意力头数 32，head_dim 128，用 FP16（2 字节）存储。如果 num_kv_heads 等于 num_heads（标准多头注意力 MHA），那么单个 token 的 KV cache 大小是：
2 × 1 × 1 × 32 × 32 × 128 × 2 字节 = 524288 字节 ≈ 0.5 MB也就是说，每多一个 token，就要多占 0.5 MB 显存。如果序列长度到 4096，单个请求就是 2 GB。批量 8 个请求，就是 16 GB——这还没算模型权重本身。这就是为什么长上下文场景下显存会爆炸。
也正是这个账本，催生了 MQA（Multi-Query Attention）和 GQA（Grouped-Query Attention）：让多个 Q 头共享同一组 K/V 头，把 num_kv_heads 从 32 降到 8 甚至 1，显存直接砍到 1/4 或 1/32。代价是表达能力略有损失，但实测在大多数任务上几乎无感。这个取舍非常值得，尤其是你要做高并发服务的时候。
提示：如果你在选型阶段，看到某个模型标称支持 128K 上下文，先别急着高兴，算一下它的 KV cache 在目标批量下要占多少显存。很多时候"支持"和"能跑起来"是两回事。
2.3 预填充和解码两个阶段，KV cache 的行为完全不同
这是实操中必须分清楚的一件事。LLM 推理分两个阶段：
- 预填充（prefill）阶段：一次性处理整个输入 prompt，所有 token 并行计算，KV cache 被"填满"。这个阶段是计算密集型的，GPU 算力吃满。
- 解码（decode）阶段：每次只生成一个 token，逐个往外吐。这个阶段是显存带宽密集型的，因为每生成一个 token 都要把整个 KV cache 读一遍。
为什么这个区分重要？因为批量调度在两个阶段的策略是相反的。预填充阶段适合大 batch 并行，把算力榨干；解码阶段则受限于显存带宽，batch 越大反而可能因为 KV cache 读取量线性增长而变慢。很多推理框架（比如 vLLM 的 continuous batching）就是靠把这两个阶段交错调度，让 GPU 在等解码的时候去跑别的请求的预填充，从而把利用率拉起来。
我踩过的一个坑：早期自己写了个简单的批量推理脚本，把预填充和解码混在一个 batch 里同步跑，结果 GPU 利用率只有 30% 出头。后来改成把请求按阶段分开调度，同样的硬件吞吐翻了将近两倍。这个教训就是——别把两个性质完全不同的阶段当成一件事处理。
3. 批量调度里的"共享"陷阱：PagedAttention 与缓存块管理
3.1 连续内存分配的浪费，和操作系统分页的启发
最朴素的 KV cache 实现，是给每个请求预分配一块连续的显存，大小按最大序列长度算。问题很明显：一个只生成 50 个 token 的请求，也占着 4096 长度的坑，浪费率极高。实测下来，这种方案的有效显存利用率经常只有 20%~40%。
vLLM 提出的 PagedAttention 借鉴了操作系统的虚拟内存分页思想：把 KV cache 切成固定大小的"块"（block），比如每块存 16 个 token 的 KV，然后按需分配，用一张块表（block table）记录逻辑位置到物理块的映射。这样不同请求的块可以非连续存放，碎片被大幅消除，显存利用率能拉到 90% 以上。
这个设计的精妙之处在于，它把"共享"这件事变得可控了。因为块是独立管理的，你可以精确地决定哪些块共享、哪些块隔离。
3.2 前缀共享：省显存的好东西，也是串味的源头
PagedAttention 带来一个非常实用的能力：前缀共享（prefix sharing）。如果多个请求有相同的前缀（比如同一个 system prompt，或者多轮对话里共享的历史），它们的 KV cache 块可以指向同一份物理块，不用重复存储。
这在多轮对话场景下收益巨大。想象一个客服机器人，system prompt 有 2000 个 token，100 个并发请求，如果不共享，光 system prompt 的 KV cache 就要占 100 份；共享之后只占 1 份。省下来的显存可以拿去提高并发。
但——这就是我开头那个"串味"bug 的来源——共享的前提是"内容完全相同且只读"。一旦某个请求需要修改共享块里的内容（比如它要继续往这个前缀后面追加 token），就必须触发"写时复制"（copy-on-write）：把共享块复制一份出来，改成私有的，再往上写。
如果框架的写时复制逻辑有 bug，或者块引用计数（ref count）管理出错，就会出现"我改了共享块，结果影响了别的请求"的情况。我遇到的那次串味，根因就是引用计数在某个异常路径下没有正确递增，导致一个块被提前回收又分配给了另一个请求。
3.3 一个可复现的排查路径
如果你怀疑自己遇到了类似的共享污染问题，可以按这个链路排查：
- 先确认是不是真串味：把出问题的请求的完整输入、输出、以及同批次其他请求的输入都打出来，人工比对。有时候"串味"其实是 prompt 模板拼接错误，不是缓存问题。
- 关掉前缀共享再测：大多数框架都有开关（比如禁用 prefix caching）。如果关掉之后问题消失，基本可以锁定是共享逻辑的问题。
- 降低并发到 1：单请求单批次跑，如果问题消失，说明是批量调度引入的。
- 打开块级别的调试日志：看块的分配、释放、引用计数变化。重点看有没有"块被释放后又被引用"的情况。
- 构造最小复现：用两个前缀相同、但后续内容不同的请求，反复跑，看是否稳定复现。
这套路径我在实际排查里用过不止一次，核心思路就是逐层剥离变量：先排除应用层，再排除共享层，最后定位到调度层。
注意：写时复制这个机制，在"共享前缀 + 各自续写"的场景下是必须的。如果你自己实现缓存管理，一定要把引用计数和写时复制当成一等公民来对待，别图省事直接原地修改共享块。
4. 注意力机制的变体：它们如何影响缓存策略
4.1 多头、多查询、分组查询：缓存大小的三档选择
前面提过 MHA、MQA、GQA 对 KV cache 大小的影响，这里展开说一下它们对调度的影响。
| 注意力类型 | KV 头数 | KV cache 相对大小 | 表达能力 | 适用场景 |
|---|---|---|---|---|
| MHA | 等于 Q 头数 | 1x（基准） | 最强 | 质量优先、显存充裕 |
| GQA | Q 头数 / 分组数 | 1/4 ~ 1/8 | 接近 MHA | 主流选择，平衡 |
| MQA | 1 | 1/32 左右 | 略弱 | 高并发、显存紧张 |
从调度角度看，KV cache 越小，同样显存能塞下的并发请求越多，批量调度的空间越大。所以现在主流开源模型基本都用 GQA，这是一个工程上非常务实的折中。
4.2 滑动窗口注意力与稀疏注意力：把"无限长"变成"有限长"
标准注意力是"每个 token 看前面所有 token"，KV cache 随序列线性增长。滑动窗口注意力（sliding window attention）则规定每个 token 只看前面固定窗口内的 token，超出窗口的 KV 就可以丢掉。这样 KV cache 大小被钉死在窗口长度上，不随总序列增长。
这个思路对长文本场景特别有用。代价是模型无法直接看到窗口外的信息，需要靠多层堆叠来间接扩大感受野。Mistral 系列就是典型代表。
还有一类是稀疏注意力，比如只保留部分重要的 KV（类似 H2O、StreamingLLM 那类思路），通过淘汰"不重要"的 token 来控制缓存。这类方法在实测中效果参差，取决于任务类型——对需要精确回忆远处细节的任务，淘汰策略可能丢信息。
4.3 视觉领域的空间注意力，和 LLM 的注意力有什么不同
热词里出现了"高度方向、宽度方向注意力""Swin Transformer""视觉 Transformer"这些，我顺带说一下区别，因为很多人会把它们混为一谈。
NLP 里的自注意力是在序列维度上做的，token 之间是一维排列。而视觉 Transformer（ViT）把图像切成 patch，也是拉成一维序列处理。但图像有天然的空间结构，Swin Transformer 引入了窗口注意力：把特征图划分成不重叠的窗口，只在窗口内做注意力，再通过窗口移位（shifted window）让信息跨窗口流动。这本质上和滑动窗口注意力是同一个思想——用局部性换计算量。
对 KV cache 的启示是一样的：限制注意力的范围，就能限制缓存的大小。这个思路是跨领域通用的。
5. 实操：从零搭一个带缓存管理的批量推理小实验
5.1 为什么建议自己动手写一遍简化版
光看框架文档，很多细节是体会不到的。我强烈建议你自己写一个极简版的 KV cache 管理 + 批量调度，哪怕只支持固定长度、不支持动态分配。写完之后你对"共享"和"隔离"的理解会上一个台阶。
下面给一个概念性的伪代码，展示核心逻辑（不是可直接运行的完整实现，重点是结构）：
class KVCacheBlock: def __init__(self, block_id, size): self.block_id = block_id self.size = size # 能存多少个 token 的 KV self.ref_count = 0 # 被多少个序列引用 self.data = None # 实际的 K/V 张量 class BlockManager: def __init__(self, num_blocks, block_size): self.free_blocks = [KVCacheBlock(i, block_size) for i in range(num_blocks)] self.block_table = {} # seq_id -> [block_id, ...] def allocate(self, seq_id, num_tokens): # 按需分配块，记录到 block_table ... def share_prefix(self, src_seq, dst_seq, prefix_len): # 让 dst_seq 的前 prefix_len 个 token 指向 src_seq 的块 # 关键：ref_count += 1 ... def append_token(self, seq_id, kv): # 如果当前块满了，分配新块 # 如果当前块是共享的（ref_count > 1），先 copy-on-write ...重点看append_token里的写时复制逻辑：只要发现要写的块被多个序列引用，就必须先复制。这一行如果漏了，就是串味的根源。
5.2 关键参数怎么定：块大小、批量上限、显存水位
几个实操中需要拍板的参数：
- 块大小（block size）：常见是 16。太小则块表管理开销大，太大则内部碎片多。16 是个经验值，实测比较平衡。
- 最大批量（max batch size）：不要拍脑袋定，用公式反推。可用显存 = 总显存 - 模型权重 - 激活值预留，然后除以单请求平均 KV cache 大小。
- 显存水位（gpu_memory_utilization）：vLLM 里默认 0.9，意思是预留 10% 给临时分配。如果你发现偶发 OOM，先把这个值降到 0.85 试试。
我一般会先跑一个压测，把并发从 1 逐步往上加，记录吞吐和显存曲线，找到吞吐开始下降或者显存逼近上限的拐点，那个点附近的并发就是比较合适的配置。
5.3 实测中的意外：吞吐不升反降的几种情况
批量调度的直觉是"batch 越大吞吐越高"，但实测经常打脸。我遇到过几种吞吐不升反降的情况：
- 解码阶段 batch 过大：显存带宽成为瓶颈，每个 token 生成都要读巨量 KV cache，延迟飙升。
- 预填充和解码互相阻塞：如果调度器没有做阶段交错，大 batch 的预填充会把解码请求饿死，导致首 token 延迟（TTFT）爆炸。
- 块分配碎片化：频繁分配释放小块，导致块表膨胀，管理开销吃掉收益。
对应的解法分别是：解码阶段控制 batch、启用 continuous batching、增大块大小减少管理频率。这些都不是文档里会明说的，得自己压测才能发现。
6. 那些容易被忽略的边界条件
6.1 序列结束与块回收：一个经典的悬空引用
序列生成结束时，它占用的块要回收。但如果这些块还被别的序列共享着（ref_count > 1），就不能直接回收，只能把 ref_count 减一。这个逻辑听起来简单，但在异常路径下（比如请求被取消、超时中断）特别容易出错。
我见过的一个真实 bug：请求超时被中断，中断处理里直接释放了所有块，没有检查 ref_count，结果把还在被其他请求共享的块给回收了，后续分配出去就串味了。异常路径的块回收，一定要和正常路径走同一套引用计数逻辑。
6.2 多轮对话的历史管理：什么时候该重新计算
多轮对话里，历史越长，KV cache 越大。有些框架支持"复用上一轮的 KV cache"，只计算新增的部分。这能省大量计算，但前提是历史完全没变。
如果中间做了任何修改（比如重新排序、截断、插入系统消息），缓存就失效了，必须重新预填充。我建议在应用层维护一个"缓存有效性标记"，任何对历史的修改都把这个标记置为无效，避免用错缓存。
6.3 采样参数与缓存的关系：一个反直觉的点
采样参数（temperature、top_p 等）不影响 KV cache 的内容，因为缓存的是 K 和 V，和采样无关。但有一个例外：如果你用了 beam search，每个 beam 都要维护自己的 KV cache，显存占用会乘以 beam 数量。这个在配置 beam search 时一定要算进去，否则很容易 OOM。
7. 我在实际项目里沉淀下来的几条经验
第一条，也是最值钱的一条：任何"共享"都必须有明确的"只读"或"写时复制"语义，没有中间地带。共享块要么绝对只读，要么在写之前先复制。我见过太多 bug 都是因为"我以为它不会改"。
第二条，把 KV cache 的显存账算清楚再上线。不要等 OOM 了才去算。公式前面给了，套进去就行。尤其是长上下文 + 高并发 + beam search 这三个因素叠加的时候，显存需求是指数级增长的。
第三条，批量调度不是越大越好，要分阶段看。预填充和解码的最优 batch 策略是相反的，能用 continuous batching 就用，别自己造轮子同步跑。
第四条，排查串味问题，先关共享再降并发。这个二分法能快速把问题范围缩小到共享逻辑还是调度逻辑。
最后分享一个我常用的自检小技巧：在开发环境里，给每个请求的 KV cache 块打上"归属标签"，跑压测的时候定期扫描，看有没有块被多个不同归属的序列同时引用却没有走写时复制。这个检查能提前发现大部分共享污染问题，比等线上出事再排查划算得多。这个思路其实和"共享状态，隔离问题"这八个字是一回事——共享是为了效率，但隔离的边界必须清晰到可以被验证。
