滑动窗口注意力与环形缓存：KV Cache固定内存的工程实现

如果你正在阅读或实现过 Mistral、Longformer 这类使用滑动窗口注意力（Sliding Window Attention）的模型，大概率会产生一个疑问：decode 阶段每生成一个 token，KV Cache 就会增加一份，但滑窗注意力明明只关注最近几个 token，为什么不能把窗口外的 KV 直接删掉？删掉之后，内存空间又该怎么管理？如果每次生成都重新分配一个更小的数组，内存碎片和拷贝开销会不会让推理性能变得很难看？

这个问题的标准答案，就是环形缓存（Ring Cache / Ring Buffer）。它不只是"提高缓存利用率的小技巧"，而是滑窗注意力在推理阶段保持固定内存开销、稳定吞吐的关键设计。这篇文章不打算只讲概念，我会从一个 decode 的实际场景出发，讲清楚为什么需要环形缓存、它背后的索引映射逻辑、最小可运行代码，以及它在 PagedAttention 这类工程方案中是如何被块级化落地的。

全文会围绕几个关键点展开：滑动窗口注意力和全注意力的本质区别；decode 阶段为什么必须做 KV 缓存；普通数组方案在缓存淘汰时的问题；环形缓存为什么能用一个取模公式同时解决存储复用和注意力正确性；最后给出可以直接运行的 Python 示例和工程落地建议。

1. 这篇文章要解决的痛点

很多技术文章介绍滑动窗口注意力时，会给出一个很漂亮的复杂度公式：原本全注意力需要 O(n²) 的计算量，滑窗注意力只需要 O(n×w)，其中 w 是窗口大小。这个公式在讲训练时是对的，但它掩盖了推理阶段一个非常实际的问题：decode 是逐 token 生成的，每生成一个新 token，模型都要把当前 token 的 Key 和 Value 写入缓存。如果把所有历史 token 的 KV 都保存下来，缓存会无限增长；如果把窗口外的 KV 直接删掉，又需要一套机制来管理存储空间。

于是我观察到，很多开发者会在三个地方卡住：

1. 觉得"删掉旧 KV"就够了。但实际上，KV Cache 通常是一块预分配的连续内存。如果只做逻辑删除，物理内存并没有被复用；如果做物理删除，数组中后续数据要整体前移，代价非常大。

2. 不理解为什么取模运算能保证注意力正确。看到slot = position % window_size时，第一反应是：取模之后位置信息和原始位置对不上了，注意力不是会算错吗？实际上，注意力计算只需要在目标位置集合上做 softmax，根本不需要"原始位置绝对连续"。

3. 分不清 prefill 和 decode 阶段的差异。prefill 阶段是一次性处理整段输入，token 顺序明确，缓存可以按顺序写入；decode 阶段是流式的，每步只来一个 token，窗口边界不断移动，这时候才真正需要"覆盖旧数据"的机制。

这篇文章就是围绕这三个痛点展开的。读完你会理解：环形缓存本质上是用"固定大小的物理存储 + 位置取模映射"来实现滑动窗口的 KV 淘汰，它不需要移动数据，也不需要动态扩容，内存开销严格受窗口大小控制。

2. 滑动窗口注意力：把复杂度从 O(n²) 拉下来

在正式进入环形缓存之前，需要先准确理解滑动窗口注意力本身。

2.1 全注意力的问题

Transformer 的标准注意力公式是：

Attention(Q, K, V) = softmax(QK^T / sqrt(d_k)) V

对于长度为 n 的序列，QK^T 的计算复杂度是 O(n²)。当序列变长到几万甚至几十万 token 时，这个复杂度会让显存和时间都变得不可接受。这也是很多长文本模型的瓶颈所在。

全注意力的语义是：序列中任意两个 token 之间都可以建立依赖关系。这对理解整篇文档很有帮助，但实际场景中，很多依赖是局部的。一个词的意思往往主要由它附近的词决定，距离太远的 token 对它的影响非常有限。

2.2 滑动窗口注意力的思路

滑动窗口注意力做了一个很强但有效的假设：每个 token 只关注它前面最多 w 个 token（在因果自回归场景下，后面 token 本来就看不到）。这样一来，序列长度 n 变大时，每个 token 的注意力计算量不会跟着变大，始终是 O(w)。整体计算复杂度从 O(n²) 降到了 O(n×w)。

它的掩码非常直观：对于序列中的第 i 个 token，它只能 attend 到下标满足i - w < j <= i的位置 j。超出这个范围的 token，不管在物理存储上位于哪里，在注意力计算时都会被 mask 掉。

2.3 与稀疏注意力的关系

滑动窗口注意力是稀疏注意力的一种特例。常见的稀疏注意力模式有：

滑窗注意力的优势在于实现简单，掩码规则固定，对硬件友好。它的代价是：如果某个重要信息恰好落在窗口之外，模型就无法直接感知。这也是为什么很多实际模型会在滑窗之外额外加少量全局 token。

这里需要强调一个判断：滑动窗口注意力在训练阶段解决的是"长序列下的计算量爆炸问题"，但在推理阶段，它更要解决的是"缓存管理问题"。计算量已经是 O(w) 了，真正会无限增长的，是每步生成都要追加的 KV Cache。

3. decode 阶段为什么离不开 KV Cache

要理解环形缓存，必须先理解 decode 阶段的缓存机制。很多文章默认读者知道 KV Cache，但我还是想展开讲一遍，因为它和环形缓存的设计是强耦合的。

3.1 自回归生成的过程

大模型生成文本时，是一个自回归过程：

1. 输入一段 prompt，模型计算得到下一个 token 的概率分布。
2. 采样得到一个新 token。
3. 把新 token 拼接到输入序列末尾。
4. 重复第 1 步，直到生成结束。

最朴素的做法是：每步都把整个 token 序列重新输入模型一次。这样做的结果是，越到后面 token 越多，计算量越大。比如生成到第 1000 个 token 时，每次都要重复计算前 999 个 token 的注意力结果，但这些结果其实并没有变化。

3.2 KV Cache 的作用

KV Cache 的核心思路是：把已经计算过的 token 的 Key 和 Value 缓存下来，后续生成新 token 时，只需要计算新 token 的 K、V，然后从缓存中读取历史 K、V 做注意力计算即可。

这样，decode 每步的计算量基本不随历史 token 数量增长，因为它只需要：

新 token 的 Q、K、V 计算 Q 与历史 K 做注意力 注意力权重与历史 V 加权求和

这套机制就是 KV Cache。几乎所有主流推理框架都默认开启它。

3.3 prefill 和 decode 的差别

推理过程通常分为两个阶段：

prefill 阶段因为可以并行处理整个序列，计算密度高；decode 阶段每步只有一个 token，访存带宽往往成为瓶颈。这也是为什么 KV Cache 的布局和访问效率对 decode 性能影响巨大。

在滑动窗口注意力中，prefill 阶段可以直接用掩码计算，因为所有 token 同时存在；decode 阶段则不同，窗口边界每步都在移动，新 token 只能看到窗口内的历史 KV。这正是环形缓存要解决的场景。

4. 用普通数组存 KV，会在这四个环节出问题

假设我们不使用环形缓存，而是用一个普通数组来充当滑窗注意力的 KV Cache。每次写入新 token 时，把窗口外最老的 KV 删掉。这在逻辑上完全可行，但工程实现会四处碰壁。

4.1 内存无限增长，无法控制上限

如果使用追加写入的普通数组，随着 decode 的进行，数组会不断变长。虽然滑窗注意力只需要最近 w 个 token，但如果不对物理存储做回收，KV Cache 占用的显存就会持续增长，最终可能在长文本生成中 OOM。

很多人说"可以定期删除旧数据"，但删除本身会引发第二个问题。

4.2 删除数据导致内存碎片化

如果从数组中间删除一组 KV，后面的数据需要前移，或者整个数组需要重新分配。频繁的移动和重新分配会产生大量内存碎片，并带来不必要的拷贝开销。在 GPU 上，数据搬迁的代价比计算更高。

更麻烦的是，如果你预分配了固定大小的数组，然后删除头部数据，数组的前半段就空出来了。但 decode 是流式的，新数据总是追加在尾部，前面的空洞不会自动被利用。结果就是：物理内存总量是上限的两倍甚至更多，但真正有效的数据只有窗口内那一小段。

4.3 位置索引失效

普通数组的索引是连续的。一旦删除某些位置的 KV，数组下标和 token 原始位置之间的对应关系就被破坏了。注意力计算时，需要知道某份 KV 对应的是原始第几个 token 的 Key 和 Value。

如果强行维护一个"位置到数组下标"的映射，每删一个元素都要更新所有受影响的下标。这个时间复杂度虽然不是不能接受，但在高性能推理框架中会让每一步 decode 都变慢。

4.4 多批次场景下更难管理

实际推理服务通常同时处理多个序列。每个序列的 decode 进度不同，窗口位置不同，需要淘汰的 KV 也不同。使用普通数组，会非常难以统一管理多个序列的缓存空间，很容易出现某个序列的缓存增长占用了其他序列可用的内存。

从上面的分析可以看出，问题的本质不是"删除旧 KV"这个逻辑难实现，而是"如何在 O(1) 时间内完成淘汰，并且不破坏注意力计算所需的索引关系"。环形缓存给出的答案非常优雅：用固定大小的数组加取模运算，让新数据自然覆盖最旧的、已经滑出窗口的数据。

5. 环形缓存的核心原理：位置取模、槽位复用、窗口即容量

环形缓存（Ring Buffer）在操作系统和网络编程中已经有很长的历史，它通常用于数据流的生产者和消费者模型。在滑窗注意力中，它的设计思路完全一致：用一个固定大小的数组，通过取模运算把物理位置循环利用。

5.1 为什么叫"环形"

假设窗口大小是 w，我们分配一个有 w 个槽位的数组。写入第 0 个 token 时放在槽位 0，第 1 个 token 放在槽位 1，直到第 w-1 个 token 放在槽位 w-1。下一个 token 是第 w 个，按照公式slot = position % w，它会回到槽位 0。

从逻辑上看，存储空间像一个首尾相接的环：

位置 0 位置 1 ... 位置 w-1 ↑ ↑ └──────────┬───────────┘ ↓ 新数据写入

槽位 0 里原本保存的是第 0 个 token 的 KV，但在第 w 个 token 写入时，这个 KV 已经滑出了窗口，因为当前 token 的位置 w 只能看到位置w-w+1到w之间的 token。所以覆盖槽位 0 是安全的。

5.2 一个取模公式解决淘汰问题

环形缓存的核心就一行代码：

slot = position % buffer_size

这里 buffer_size 在线程中等于窗口大小 w。这个公式同时完成了三件事：

1. 限定存储上限：无论生成多少个 token，物理空间始终只有 w 个槽位。
2. 确定写入位置：新 token 的 KV 总是写到它应该覆盖的位置。
3. 保证窗口有效性：当 position 超过 w 后，被覆盖的永远是窗口外的旧数据。

这个公式背后的数学直觉是：在滑窗注意力中，position 和 position + w 这两个 token 永远不会同时在窗口内。它们可以被安全地映射到同一个物理槽位，因为注意力计算时，当前 token 只会去读窗口内的位置，而窗口内的位置和槽位的对应关系是唯一的。

5.3 为什么覆盖旧位置不会破坏注意力计算

这是很多人容易卡住的地方。我详细解释一下。

注意力计算时，当前 token 的 Q 需要与窗口内所有历史 token 的 K 做点积，再对 V 加权。它依赖的是：能够拿到窗口内每个位置对应的 K 和 V。

环形缓存保证的是：对于当前 token 位置 pos，窗口内的任意位置 p（满足pos - w < p <= pos），其 KV 都存储在槽位p % w中，而且这个槽位不会在该 token 被需要之前被覆盖。

原因很简单：当写入位置为p + w的 token 时，覆盖了槽位p % w。而从位置 p+w 的视角看，位置 p 已经在它的窗口之外，因此 p 的 KV 不再需要。从位置 p+w-1 的视角看，位置 p 还在窗口内，而 p+w-1 还没有写入，所以 p 的 KV 也还没有被覆盖。

这就是环形缓存"刚好够用"的本质：每个 KV 被覆盖的时刻，恰好是它滑出所有未来 token 窗口的那一刻。

5.4 和 prefill 阶段有什么不同

prefill 阶段是一次性处理整个 prompt，所有 token 的位置已知，存储分配可以直接确定。这个阶段通常还是按顺序写入内存，不需要环形覆盖。因为 prompt 是有限的，内存峰值可以预估。

decode 阶段是无限流式的，你不知道模型会生成多少 token。环形缓存的神奇之处在于，它不需要知道未来生成多少 token，因为存储上限就是窗口大小。无论生成 100 个 token 还是 10000 个 token，KV Cache 的物理占用都保持不变。

6. 最小实现：手写一个环形 KV Buffer

概念说得再多，不如一段可运行代码。这里我用 PyTorch 写一个最小实现，帮助你从代码层面理解环形缓存的工作过程。这个实现没有做任何性能优化，纯粹为了讲清楚原理。

6.1 第一步：生成滑动窗口掩码

如果想在自回归模型中使用滑动窗口注意力，第一步是构造掩码。下面的函数会生成长度为 seq_len 的掩码矩阵，其中 mask[i][j] 为 True 表示第 i 个 token 可以关注第 j 个 token。

import torch def build_sliding_window_mask(seq_len: int, window_size: int) -> torch.Tensor: """ 为因果自回归场景构造滑动窗口注意力掩码。 语义：mask[i, j] = True 表示第 i 个 token 可以 attend 到第 j 个 token。 约束条件：j <= i（因果）且 i - j < window_size（窗口）。 """ mask = torch.zeros(seq_len, seq_len, dtype=torch.bool) for i in range(seq_len): start = max(0, i - window_size + 1) mask[i, start:i + 1] = True return mask mask = build_sliding_window_mask(seq_len=8, window_size=3) print(mask)

运行结果：

tensor([[ True, False, False, False, False, False, False, False], [ True, True, False, False, False, False, False, False], [ True, True, True, False, False, False, False, False], [False, True, True, True, False, False, False, False], [False, False, True, True, True, False, False, False], [False, False, False, True, True, True, False, False], [False, False, False, False, True, True, True, False], [False, False, False, False, False, True, True, True]])

可以看到，窗口大小为 3 时，最后一个 token 只能看到位置 5、6、7 三个 token。掩码中每一行只有窗口内的位置是 True。

6.2 第二步：实现环形 KV 缓存

现在实现一个最简版本的 RingKVBuffer。它的核心是维护两个固定大小的 tensor，分别存 K 和 V，用position % window_size计算槽位。

import torch from typing import Dict, List class RingKVBuffer: """ 极简环形 KV Buffer，演示 decode 阶段的槽位复用。 物理存储只分配 window_size 个槽位，新的 KV 会覆盖最旧且不再被需要的 KV。 """ def __init__(self, window_size: int, num_heads: int, head_dim: int): self.window_size = window_size self.k_buffer = torch.zeros(window_size, num_heads, head_dim) self.v_buffer = torch.zeros(window_size, num_heads, head_dim) # 记录原始 position 到槽位的映射，便于读取 self.slot_of_position: Dict[int, int] = {} def write(self, position: int, k: torch.Tensor, v: torch.Tensor) -> None: slot = position % self.window_size self.k_buffer[slot] = k self.v_buffer[slot] = v self.slot_of_position[position] = slot def read(self, positions: List[int]): slots = [self.slot_of_position[p] for p in positions] return self.k_buffer[slots], self.v_buffer[slots]

关键点：

• k_buffer和v_buffer的形状是(window_size, num_heads, head_dim)，物理内存始终固定。
• write使用取模计算槽位，自动完成覆盖。
• read根据原始位置列表找到对应的物理槽位。

这个类的规模很小，但它体现了环形缓存的全部核心逻辑。在实际推理框架中，k_buffer 和 v_buffer 往往是大块连续显存，write 和 read 会变成更复杂的索引操作，但原理完全一致。

6.3 第三步：在 decode 循环中使用环形缓存

最后，写一个简单的 decode 循环demo。为了直观，我假设第 pos 个 token 的 K 和 V 是由位置决定的张量。真实场景中，它们是模型前向计算得到的。

def decode_demo(seq_len: int, window_size: int, num_heads: int, head_dim: int): cache = RingKVBuffer(window_size, num_heads, head_dim) # 模拟：第 pos 个 token 的 K、V 由其位置决定 def compute_kv(pos): k = torch.ones(num_heads, head_dim) * pos v = torch.ones(num_heads, head_dim) * (pos + 1) return k, v for pos in range(seq_len): k, v = compute_kv(pos) cache.write(pos, k, v) # 当前 token 只 attend 窗口内的历史位置 valid_positions = [p for p in range(pos + 1) if pos - p < window_size] past_k, past_v = cache.read(valid_positions) # 这里可以继续做 QK^T / softmax / @V，演示时只打印关键信息 print(f"第 {pos:2d} 个 token：需要 attend {valid_positions}") print(f" 读到的 K 形状：{tuple(past_k.shape)}") print(f" 槽位映射：{[cache.slot_of_position[p] for p in valid_positions]}") decode_demo(seq_len=6, window_size=3, num_heads=2, head_dim=8)

运行结果：

第 0 个 token：需要 attend [0] 读到的 K 形状：(1, 2, 8) 槽位映射：[0] 第 1 个 token：需要 attend [0, 1] 读到的 K 形状：(2, 2, 8) 槽位映射：[0, 1] 第 2 个 token：需要 attend [0, 1, 2] 读到的 K 形状：(3, 2, 8) 槽位映射：[0, 1, 2] 第 3 个 token：需要 attend [1, 2, 3] 读到的 K 形状：(3, 2, 8) 槽位映射：[1, 2, 0] 第 4 个 token：需要 attend [2, 3, 4] 读到的 K 形状：(3, 2, 8) 槽位映射：[2, 0, 1] 第 5 个 token：需要 attend [3, 4, 5] 读到的 K 形状：(3, 2, 8) 槽位映射：[0, 1, 2]

注意观察第 3 个 token 的行：它需要 attend 位置 1、2、3。位置 1 映射到槽位 1，位置 2 映射到槽位 2，位置 3 映射到槽位 0（因为 3 % 3 = 0）。虽然位置 0 的旧 KV 曾经存在槽位 0，但它已经被位置 3 的新 KV 覆盖了，而位置 0 已经滑出窗口，所以覆盖不会影响正确性。

这正是环形缓存最核心的验证：每个需要 attend 的位置，都能在缓存中找到未过期的 KV；每个过期 KV，都恰好被后续某个 token 覆盖。

7. PagedAttention 与块级环形缓存：工程上怎么落地

上面的最小实现能讲清楚原理，但和生产环境的差距很大。实际推理时，KV Cache 不是以单个 token 为粒度管理的，而是以块（block）为单位管理。这里以 vLLM 的 PagedAttention 为代表，介绍工程化的环形缓存思想。

7.1 为什么需要块粒度

在 GPU 上，如果为每个 token 单独分配/释放显存，会有两个问题：

1. 显存分配需要调用底层接口，每次都有固定开销。
2. 单个 token 的 KV 数据量很小，单独分配会造成大量碎片。

所以 PagedAttention 的做法是：把 KV Cache 划分成固定大小的块，每个块可以容纳一定数量的 token。常见的实现中，一个块可能包含 16 个 token 的 KV，具体数值因框架和配置而异。

逻辑上，每个序列的 KV Cache 是一串逻辑块；物理上，这些块可能分散在显存的不同位置。框架用一个 block table 来记录逻辑块到物理块的映射。

7.2 环形缓存在块粒度上的体现

在滑窗注意力场景中，环形缓存的思想可以上移到块粒度：

• 假设窗口大小是 w，每个块容纳 b 个 token，那么需要的物理块数量上限为ceil(w / b)。
• 当生成 token 数量超过窗口时，最旧的块不再需要，新 token 写入的块可以复用旧块。

块级环形缓存的好处是：不需要精确到单个 token 的淘汰，而是按块推进。这样每一步只需要把新 token 的 KV 写入当前块，当当前块写满时，切换到下一个物理块，如果所有物理块都写完了，就回到第一个物理块重新覆盖。

从实现角度看，这比逐 token 管理简单得多，也更贴近 GPU 显存分配的特点。

7.3 多序列并发时的思考

实际推理服务中，单个请求可能并行处理多个序列，比如 beam search 或并行采样。每个序列的 decode 进度不同，窗口位置不同。

如果每个序列固定分配ceil(w / b)个物理块，那么整个服务的 KV Cache 总量是可以提前算出来的：

总显存占用 = 最大并发序列数 × 每个序列固定的 KV 块数 × 每块大小

这一点非常重要。在生产环境中，"可预测的内存上限"意味着你可以通过限制并发数来避免 OOM，而不是依赖运行时动态调整。

如果每个序列的 KV Cache 上限不确定，调度器很难决定当前请求是否能被接受。有了块级环形缓存，每个序列的内存占用就是一个固定值，调度变得非常干净。

需要注意的是，vLLM 的 PagedAttention 本身并没有规定必须用环形缓存，它只是提供了逻辑块到物理块的映射能力。滑窗模型在接入时，会在块分配策略上体现"覆盖最旧块"的行为。你可以把 PagedAttention 理解成解决通用 KV Cache 管理的框架，而环形缓存是解决滑窗场景下"淘汰哪块"的策略。

8. 常见误区与排查方法

对于滑动窗口注意力和环形缓存，我在实践和讨论中经常看到下面这些误区。把它们整理成一张表，方便快速对照。

另一个容易混淆的概念是：滑动窗口注意力并不是"只保留最近 w 个 token"这一个规则。实际模型可能还会包含全局 token 或多个注意力层使用不同窗口。这时候，KV Cache 的过期判定不能只看单层窗口，而要看所有层中最大的窗口需求。如果一个模型第 3 层使用窗口大小为 4096，其余层使用 1024，那么 KV Cache 至少要保留 4096 个 token，否则第 3 层会读到已经被覆盖的数据。

另外，不要误解"环形缓存可以让显存占用严格等于窗口大小"。它确实让物理存储上限等于窗口大小，但在实际框架中，由于块对齐、内存分配粒度、多序列共享等原因，实际显存占用会略高于理论值。在估算资源时，建议在窗口容量之外再留 10%~20% 的余量。

9. 最佳实践与工程建议

9.1 窗口大小与缓存容量对齐

在实现或配置滑窗模型时，最重要的原则是：缓存容量不能小于窗口大小。如果框架允许配置 KV Cache 容量，请确保：

cache_capacity >= window_size

如果缓存容量小于窗口，早期的 token 会过早被覆盖，导致注意力信息丢失，生成质量下降且难以排查。

9.2 用位置索引，不要用物理索引

在做环形缓存读取时，始终用原始 position 作为键，而不是物理槽位。写代码时把"位置到槽位"的映射集中封装，避免在注意力代码里散落的取模逻辑。

例如在 PyTorch 中，建议先通过torch.gather或索引数组把 K、V 按位置顺序取出，再参与注意力计算：

slots = torch.tensor([position % window_size for position in valid_positions], device=...) k_sorted = k_buffer[slots] v_sorted = v_buffer[slots]

这样即使槽位顺序是乱的，注意力计算的输入顺序仍然是正确的原始位置顺序。

9.3 对缓存覆盖进行监控

在开发和调试阶段，建议输出每一步的覆盖情况。比如记录每个槽位被写入的 position 列表，如果发现某个 position 的 KV 在被读取之前就被覆盖，说明你的缓存容量小于窗口大小，或者槽位映射逻辑有误。

这类监控在生产环境可以降级为 metrics，例如：

• 每个序列的 KV 槽位写次数。
• 每步读取的 KV 是否全部命中缓存。
• 缓存实际最大占用率和峰值。

9.4 长文本生成前评估窗口是否够用

滑窗注意力对超长文本并不总是合适。如果你的业务场景是"全文要点定位"，比如从一本长篇小说里找到某个事件，滑窗很可能丢失远处线索。这时候你应该考虑：

• 增加窗口大小。
• 在文本前面添加全局 token。
• 使用 RAG 先检索相关片段，再让滑窗模型处理片段。

9.5 多副本和批处理场景的内存规划

在生产环境中，如果同时处理多个请求，建议提前把每个请求的 KV 缓存上限设为窗口对应的块数。这样调度器在接纳请求时，可以立刻判断显存是否足够，避免运行中 OOM。

一个推荐的估算方式是：

估算总显存需求 = 并发数 × 每序列最大 KV 块数 × 每块大小 + 模型权重显存 + 激活显存

如果你的服务允许生成的最大 token 数小于窗口大小，那么可以按最大生成长度来设置缓存上限，这样更省显存。例如窗口是 4096，但你的业务最多只生成 512 个 token，那缓存上限设为 512 的 KV 就足够了。

9.6 何时不应该用环形缓存

环形缓存并不是所有场景的最优解。如果你使用全注意力模型，窗口外的 token 仍然可能被需要，就不能随便覆盖 KV。另外，如果模型的层数较多且每层窗口大小不一致，要按所有层中最大的窗口来决定缓存容量，否则会因为某一层的窗口需求而破坏其他层的数据。

对于离线批处理任务，如果所有序列长度都已知，并且不需要在线持续生成，其实可以在 prefill 阶段一次性计算出所有 KV，再按需求进行注意力计算。这种场景下，环形缓存的优势就不明显了，内存可以按批次整体分配。

10. 总结与后续学习方向

滑动窗口注意力的核心价值在于把注意力计算复杂度从 O(n²) 降到了 O(n×w)。但在 decode 阶段，真正限制推理性能的往往不是计算量，而是 KV Cache 如何随着 token 增长而增长。环形缓存用一个固定大小的物理存储空间，通过position % window_size的取模映射，把滑窗外的旧 KV 自然覆盖掉，让缓存容量始终等于窗口大小，不需要动态扩容和删除迁移。

需要记住的关键点有三个：

1. 环形缓存的覆盖时机是安全的：每个 KV 被覆盖的时刻，恰好是它滑出窗口的时刻。
2. 读取时不要按物理槽位顺序拼接，必须按原始 position 顺序取回 KV，否则注意力会算错。
3. 工程实现上，环形缓存通常以块为单位管理（例如 PagedAttention 风格），把缓存上限和并发数相乘，就可以得到可预测的服务显存需求。

如果你接下来想深入，可以按这个顺序学习：先用 PyTorch 写一个完整的滑窗 Transformer decode 实现，观察不同窗口大小下的显存占用；然后对比普通数组追加写入和环形缓存的显存曲线；最后再去读 PagedAttention 的论文和 vLLM 源码，理解逻辑块、物理块和块表的具体实现。弄通了这三个层次，你对"大模型推理时 KV Cache 如何管理"的认知，会比大多数只调 API 的开发者深得多。