DeepInfer 源码完全拆解（三）：KV 内存与 SWA 有界重放——两本块账、YoCo 截断与等价性验证

推理侧：窗口 + 回退

cache_engine.py 里给推理侧 ring 定尺寸的函数是：

1
def get_inference_swa_block_size(window_size: int) -> int:
2
    """swa_block_size 等于 window_size 加上为回退功能额外存的部分。"""

它的返回值对应代码里的 swa_block_size_inference。官方 Q&A 给出的具体数字是：

128 是窗口本身，这个好理解。6 是回退余量（backtracking），来源是投机解码：一次 decode step 里可能一次接受多个草稿 token，如果验证后被拒绝了一部分，KV 就要回滚。回退的最坏情况需要多保留几个位置，DeepInfer 取 6 作为上界。

注意这里的一个语义细节：ring 比窗口多出的这 6 个位置，就是「回退缓冲区」。这意味着 ring 里的 134 个位置，任意时刻只有窗口那 128 个是「有效窗口」，另外最多 6 个是「刚刚被踢出但还留着以便回滚」的位置。这个设计让「踢出窗口头部」变成一个纯粹的指针移动，而不需要真的擦除数据。

落盘侧：为什么要加长到 396

同一个 cache_engine.py 里还有第二个函数：

1
def get_kvstore_swa_block_size(window_size: int) -> int:
2
    """kvstore 视角的 swa_block_size：inference 大小 + prefill 落盘多存的部分。
3

4
    YoCo 截断开启时再叠加锚点回退余量 get_yoco_store_extra_tokens()。
5
    """

官方 Q&A 给出的 PE 侧数字是 396：

为什么落盘侧要多存这么多？Q&A 的解释是：store 只在 128 的整数倍处触发，而 prefill chunk 的边界不会正好落在整倍数上。

把这句话拆开：SWA 的持久化（store）有一个硬性约束——只在 token 位置是 128 的整数倍时才存。这个约束来自下面的「边界对齐」一节：只有对齐在 128 边界上，才能保证跨请求复用时不出现「半截窗口」这种没法对齐的状态。

但 prefill 是按 chunk 跑的，一个 chunk 的结束位置是在任意位置的。假设当前 chunk 算完停在位置 $p$，而 $p$ 不在 128 的整数倍上，那么最近的一个 128 边界在 $p$ 之前若干位置。要能从这个 ring 里「重排出一个完整可写的 134-token 窗口」，ring 就必须比 134 多留一段——多留的这段就是 PREFILL_STORE_EXTRA_SIZE = 128 与 YOCO_PREFILL_KEEP_TOKENS = 134。

cache_engine.py 里对应的代码路径是先判断是否开启 extra-state：

1
return get_inference_swa_block_size(window_size) + (
2
    (envs.DEEPINFER_PREFILL_STORE_EXTRA_SIZE + get_yoco_store_extra_tokens())
3
    if envs.DEEPINFER_PREFILL_STORE_EXTRA_STATE else 0
4
)

而 get_yoco_store_extra_tokens() 只在截断模式不为 off 时返回非零：

1
def get_yoco_store_extra_tokens() -> int:
2
    """YoCo 截断开启时，参与落盘重排的 state ring 额外多存的 token 数。"""
3
    return max(0, envs.DEEPINFER_YOCO_PREFILL_KEEP_TOKENS) \
4
        if envs.DEEPINFER_YOCO_PREFILL_TRUNCATION_MODE != "off" else 0

Q&A 里还有一句关键区分：CE 不开这个 extra，ring 就是 134。也就是说 396 只发生在 prefill 引擎（PE）侧，decode 引擎的 ring 保持 134。这不难理解——落在 128 整数倍处的重排需求只出现在 prefill 阶段，decode 阶段是通过「副本区」的机制来做 store 的（见下文）。

两个尺寸的对照

把两个数字放在一起：

这个表也解释了 cache_engine.py 里为什么 StateBlock 要同时持有 swa_block_size_kvstore 与 swa_block_size_inference 两个字段——它们对应不同的物理缓冲，一个给引擎用，一个给落盘重排用。

第一本账：KVCache 类里的四张表

cache_engine.py 的 KVCache 类把「逻辑 KV tensor」和「state tensor」分开描述。类里的注释把各张表的形状写得很明确：

1
class KVCache:
2
    """index attn state: [num_state_seqs, ring_size, 2, index_dim], fp32."""
3
    """compressed attn state: [num_state_seqs, ring_size, 2, dim], fp32."""
4
    """sliding window attn cache: [num_state_seqs, swa_block_size, 1, 528], uint8.

逐条解释形状里的每个维度：

[num_state_seqs, ring_size, 2, index_dim]（index attn state，fp32）

• num_state_seqs 是状态序列数——不是 token 数，是「有多少个序列能同时持有状态」。这个数由 get_num_state_slots(max_num_seqs) 决定。
• ring_size 是压缩 ring 的长度，由 get_inference_compress_block_size(compress_ratio) 给出（下详）。
• 2 是 K 和 V 两个分量。
• index_dim 是索引头的维度。
• fp32：状态是累加器，不量化。

[num_state_seqs, ring_size, 2, dim]（compressed attn state，fp32）

同样是 ring 结构，但存的是压缩条目的中间状态，dim 是压缩条目的维度。

[num_state_seqs, swa_block_size, 1, 528]（sliding window attn cache，uint8）

• swa_block_size 就是前面推出来 134（推理侧）。
• 1 是占位维度，保持与其它表统一的四维形状。
• 528 是每 token 每层的字节数。
• uint8：这里是字节视图，实际的量化格式（MXFP8）由内核在读写时解释。用 uint8 做容器类型是常见做法——显存就是一串字节，格式语义交给 kernel。

注意这三张表的第一维都是 num_state_seqs。这正是「状态槽」的本质：状态是按序列分配的固定大小块，不是按 token 分配的。

压缩 ring 长度：再加上回退历史

get_inference_compress_block_size 的注释只有一句，但信息量很大：

1
def get_inference_compress_block_size(compress_ratio: int) -> int:
2
    """Compression ring plus rollback history; environment changes require clearing the cache."""

「Compression ring plus rollback history」——压缩 ring 也不是单纯的 $m$ 个位置，同样要加上回退历史。原因和 SWA 一样：投机解码被拒绝时要回滚。

后半句「environment changes require clearing the cache」对应一个显式的失效接口：

1
def clear_compress_block_size_cache() -> None:
2
    """Clear cached ring sizes after changing DEEPINFER_MAX_BACKTRACKING_TOKENS."""

这说明 ring 长度是按环境变量算完就缓存的，运行时改 DEEPINFER_MAX_BACKTRACKING_TOKENS 必须手动清理缓存，否则新的 ring 长度不会生效。这是一个很容易踩的坑：改了环境变量但没清缓存，池子还是按老尺寸分配的，越界写入就会发生。

第二本账：块表的记账规则

第一本账讲的是「状态槽」，第二本账是经典的分页 KV 块。第二篇里提到的 1.4 TB/卡 这类容量数字、以及 prefill 侧也用 paged KV（Q&A：「在 prefill 侧同样是 paged KV cache」），说的都是这本账。

两本账的关键区别，用一张表对照：

Q&A 里描述的「命中策略」一节给出了两本账在前缀复用上的配合方式，这段非常关键：

命中的原则是：命中长度由 Block KVCache 决定，最后一个 block 是否需要重算由 SWA KVCache 决定，若 SWA KVCache 未命中，就退一块重算。具体地，根据 YOCO 截断要求，对于输入长度 L，最大的命中长度最多为 L - 134（窗口 128 + 投机回退 6）。在这个上限下，首先查询 Block KVCache 命中情况，假设命中长度为 L1（L1 为 block size=128 的整数倍），再查询 SWA KVCache 命中情况。假如在 L1 - 128 至 L1 长度范围内，存在 SWA KVCache 则命中长度为 L1，否则命中长度为 L1 - 128，其中 128 为重算窗口。

把这段算法化的规则拆成四步：

第一步，确定命中上限。 命中长度最多 $L - 134$。为什么不是 $L - 128$？因为还要留出投机回退的 6 个位置——这是 YoCo 截断的硬要求。也就是说，最后 134 个 token 永远不会来自缓存，一定是本次实算的。

第二步，查第一本账。 在 $L - 134$ 的上限下查 Block KVCache，得到命中长度 $L_1$。$L_1$ 按定义是 block size（128）的整数倍——块表只能按整块命中。

第三步，查第二本账，只查最后一块的范围。 在 $[L_1 - 128, L_1]$ 这个区间里查 SWA KVCache 是否存在。

第四步，二选一。 区间内 SWA 存在 → 命中长度 $= L_1$；不存在 → 命中长度 $= L_1 - 128$。

第 3、4 步的语义是：压缩条目命中到哪里，还不足以决定能复用到哪里。因为注意力的最后一层是滑窗，如果最后一个 block 的滑窗 KV 不在，那么这一块的注意力就没法正确算出来——但压缩条目本身是对的。于是 DeepInfer 选择「退一块」：放弃最后一个 block 的复用，把它连同后面的内容一起重算。

「退一块」这个动作对应 128 的粒度，正好等于一个 block size。所以这套规则的粒度是干净的：要么命中到最后一块，要么退一整块，不存在「命中到块中间」的中间状态。

为什么状态槽不需要驱逐

对比一下通用框架（比如 vLLM 或 SGLang）的 KV 管理：它们要处理的是「块是共享资源，序列之间争用」这个问题，所以需要引用计数、需要 LRU、需要抢占（preemption）时把某个序列的块换出。

状态槽完全不需要这些，理由在上面那张表里已经列出：槽位是序列独占的，没有共享，所以没有争用，自然不需要驱逐。序列结束的时候，整个槽位一次性归还给池子。

这也解释了 KVCacheManager 里那个看起来像是「重复校验」的 finalize()：

1
def finalize(self) -> None:
2
    # 校验 process 累加出的 state offset 与 StateBlock 预计算的总量一致，防止两处逻辑 drift
3
    sb = self._state_block

注释说得很明白：state offset 是 process() 累加出来的，而总量是 StateBlock 预计算好的，两处逻辑各自演进就会 drift（漂移）。所以需要一个 finalize() 去断言二者一致。这是一种防御性编程：布局算错了不会表现为「慢一点」，而是会表现为显存越界或数据错位，所以宁可在初始化时直接报错。

两种模式各自的机制

mask 模式：不物理移动数据，只把窗口外的位置标记为无效。

mask 的做法是在注意力计算时施加一个掩码，让 query 只 attend 到被保留的那部分 KV。物理缓冲还是完整长度，只是「不看了」。好处是实现简单、不需要搬数据；代价是显存占用没有真正下降（该占的位置还占着），省的是计算而不是空间。

compact 模式：把保留的 KV 物理搬到缓冲区的连续前段。

compact 的做法是真的把数据搬过去，缓冲区后面的位置被腾出来。好处是显存占用真的下降；代价是有一次数据搬运，而且要保证搬运之后所有指向这些位置的索引都被正确更新。

从 cache_engine.py 的注释里能看出 compact 涉及的具体动作——state_size_to_disk 的计算在 extra-state 模式下要先做 ring 重排：

1
# inference 布局的前 state_size_to_disk 字节，按长度截断即可排除整个 dropped region。
2
# 开启 extra-state 时先把 kvstore ring 重排为 inference 窗口；关闭时可直接截取原 buffer。

「先把 kvstore ring 重排为 inference 窗口」——这就是 compact 的核心动作：ring 长度从 396 重排成 134，重排之后前 state_size_to_disk 字节就是可以整体落盘的连续区域。

等价性怎么验证

「两种模式等价」不是一个可以靠读代码就断定的事。DeepInfer 的做法是提供一个专门的验证方法，总览篇的参考资料里就列了它：

1
examples/yoco/run_yoco_equiv_l2.sh

配套的脚本是 examples/yoco/yoco_equiv.py（51 KB，是个实打实的验证程序），README 在 examples/yoco/README.md。脚本名里的 l2 是这套验证方法的关键线索——用 L2 距离衡量两种模式的输出差异。

验证的逻辑可以推断为：

1. 同一批输入、同一个模型权重；
2. 分别用 mask 模式和 compact 模式跑一遍前向；
3. 逐位置比对两者输出的 hidden state（或 logits）；
4. 用 L2 距离度量差异，并在一个容许阈值内判定「等价」。

这个验证方法的价值在于它把「等价」变成了可执行的断言，而不是一个口头承诺。mask 与 compact 的差别在数学上是「看不看某些位置」与「这些位置在哪」——只要掩码逻辑与搬运逻辑一致，输出就应该逐位相同（在浮点误差范围内）。用 L2 距离而不是逐位相等，是因为搬运本身不引入数值误差，但不同的内存访问模式会改变 kernel 的归约顺序，从而产生浮点层面的微小差异。

这也顺带解释了一个容易被误解的地方：compact 模式的显存收益是真实的，但它不改变模型语义。如果它改变了语义，L2 距离就不会接近 0，这个验证脚本也就永远跑不过。

与抢占的交互：一条写在注释里的既定行为

step() 里有一句注释，总览篇引用过，这里值得再提一次因为它直接关系到截断模式：

NOTE 开启 yoco 截断时，允许抢占导致的结果变化

含义是：截断模式下 KV 只保留了有界后缀，一旦发生抢占需要重算，重算出来的结果可能与不抢占时不同。注释明确说这是「可接受的既定行为，而非 bug」。

为什么会有差异？因为在截断模式下，重算路径与原始路径处理的 KV 集合不完全相同——原始路径的中间状态是从更早的位置一路累积下来的，而重算路径是从保留的锚点重新开始的。累加器的历史不同，数值结果就会有细微差别。

这条的实操含义：任何把「同输入必同输出」当作硬要求的场景（比如确定性采样），必须同时考虑这一条。总览篇的另一条约束在这里形成闭环——要确定性就必须 DEEPINFER_ENABLE_MTP_VARLEN=0（因为变长验证的草稿长度由运行时估计决定），而截断与抢占的交互是确定性要求的第二个障碍。

问题定义

前缀缓存要能命中，就需要知道「命中到哪里」。而命中之后会有一个尴尬的问题：命中部分的 SWA KV 可能不在。

压缩条目（第一本账）是持久化的、存在 3FS 上的、能跨机命中的——Q&A 说得很清楚：「Block KVCache（Main KV + Indexer K）使用独立 3FS 存储集群存储」。但 SWA KV（第二本账的一部分）不进持久化缓存：

SWA KVCache 不进持久化缓存，而是留在产生它的那台机器的内存里，由一个逻辑上统一、实际按 key 分开存放在各台 Entrypoint 上的内存目录记录在哪台机器，命中时本机没有就跨机取回。

这句话有几个直接后果。第一，SWA KV 的命中率天然低于压缩条目，因为它只存在「产生它的那台机器」的内存里。第二，跨机回拉需要走网络（Q&A：「跨机命中靠 entrypoint 的内存目录配合 400G VLAN 回拉」）。第三，也是最关键的——当 SWA KV 缺失时，你只有一个选择：重算。

问题是重算多少。

朴素做法为什么不可行

最朴素的想法是「SWA 缺了就重算整个命中前缀」。这不可行，因为重算量与上下文长度成正比——一个 100K 上下文的前缀，为了拿回最后 128 个位置的滑窗 KV，就要把 100K 全部前向一遍。这等于把前缀缓存的收益整个抹掉。

第二种朴素想法是「只重算最后 $n_{\text{win}}$ 个 token 的前向」。这看起来对，但有一个隐藏问题：滑窗注意力在重算段内的边界怎么处理？

假设从位置 $s$ 开始重放，重算段是 $[s, s + 128)$。对于位置 $i \in [s, s+128)$ 的 query，按正常滑窗逻辑它应该 attend 到 $[\max(0, i-127), i]$。但位置 $i - 127$ 到 $s-1$ 这一段在重算段之外，我们没有它们的 KV。如果不做处理，这些位置要么被当成「空」从而得到错误结果，要么需要额外把重算段向左扩展 128——那就变成重算 256 个 token 了。

DeepInfer 的答案：截断在重算段内

官方 Q&A 给出的解法只有一句话，但完全解决了上面的问题：

采用 SWA Bounded Replay 只重算最近 128 个 token，并把注意力窗口截断在重算段内：从位置 s 起回放，位置 i 的 query 只和 max（s，i−127）到 i 区间的 key 计算，重算得到近似的 SWA KVCache。重算代价由此降为与上下文长度和层数无关的常数。

把这个公式抄下来：

对比正常滑窗公式：

唯一的差别是把下界的 $\max(0, i-127)$ 换成了 $\max(s, i-127)$，其中 $s$ 是重放起点。

这个替换的后果是：对于位置 $i \in [s, s+127]$，它看到的窗口比正常情况短——正常应该看 128 个位置，而这里只看到 $i - s + 1$ 个。也就是说，重算段的开头部分，注意力被截断了。

Q&A 用词很准确：「重算得到近似的 SWA KVCache」。这是近似的，不是精确重建。

重算的边界为什么可以接受

为什么近似可以接受？这里有三层理由，每一层都值得说清楚。

第一层：受影响的 kv 数量是有限的、且位于窗口边缘。 在重算段 $[s, s+128)$ 里，只有前 128 个位置（正好是整个重算段）的 query 会遇到「窗口比正常短」的情况——更准确地说，位置 $i$ 看到的窗口长度是 $\min(128, i - s + 1)$。当 $i = s$ 时窗口只有 1 个位置，当 $i = s + 127$ 时窗口终于达到 128。

第二层：真正进入缓存并服务于后续 decode 的，只有最后一段。重算得到的是「近似的 SWA KVCache」，但后续 decode 的 query 位置都在 $s + 128$ 之后（因为命中长度最多 $L - 134$，重算段覆盖到接近 $L$）。对于这些 query，它们的窗口是 $[\max(s, i-127), i]$，而 $i \ge s + 128$ 意味着 $i - 127 \ge s + 1$——窗口完全落在重算段内部，且完整。

这就解释了 Q&A 那句「重算代价由此降为与上下文长度和层数无关的常数」背后的真正机制：重算段里开头那部分的截断，其影响被限制在重算段内部，不会向外传播。因为后续所有的 query 只依赖重算段的后 128 个位置的 KV，而这部分的 KV 是精确的。

第三层：这个近似与 YoCo 的设计意图一致。 YoCo 的前提就是「只 cache 一次、其余重算」，而重算本身就被接受为一个近似操作。SWA Bounded Replay 是这个思路在推理侧的落地：既然重算被接受，那就把重算范围压到最小。

Encoder SWA Bounded Replay

前缀缓存命中长度从此只依赖 Block KVCache。SWA KVCache 缺失时，重算命中前缀的最后 128 个 token，与未命中后缀一同前向；重算段只重建 SWA KVCache，Block KVCache 原样复用、不重算不覆写。

拆开来看：

「前缀缓存命中长度从此只依赖 Block KVCache」——这是重放带来的最大好处。没有重放机制时，命中长度被两本账同时约束（见前文的四步算法）；有重放机制后，SWA 缺失不再是「退一块」的理由，而是「重算一小段」的操作。命中长度的决定权收归到压缩条目这一本账上。

「重算段只重建 SWA KVCache，Block KVCache 原样复用、不重算不覆写」——这句划清了重算的作用范围。重算段跑完前向，只把 SWA KV 写进状态槽，不碰压缩条目。压缩条目是持久化的、跨机的、贵重的，绝不能因为一次局部重算就覆写掉。

这里有个设计上的克制值得注意：重算段为什么不顺便把压缩条目也算出来？ 因为压缩需要对 $m$ 个 token 的窗口做累加，而重算段只有 128 个 token；如果 $m$ 大于 128，重算段根本凑不出一个完整的压缩块。更重要的是，压缩条目本来就在缓存里命中了，重算一遍纯属浪费。

Decoder SWA Bounded Replay：省掉一半 prefill

第二处的动机完全不同，也更激进：

Decoder SWA Bounded Replay：prefill 计算仅在 encoder 层进行。CED 架构下 decoder 层的 Block KVCache 由 encoder 末层 hidden state 投影得到，仅 decoder SWA KVCache 需各层自算，精确重建要 20 个 decoder 层跑最后 2560 个 token；改为每次 prefill 在 decoder 层只重算 prompt 末尾 128 个 token，产出仅供 decode、不进前缀缓存，总 prefill 计算量近乎减半。

这段需要逐句拆。

「prefix 计算仅在 encoder 层进行」——这是 CED（Cross-Encoder-Decoder，或类似的双段架构）的基本设定。encoder 层负责把 prompt 完整跑一遍。

「decoder 层的 Block KVCache 由 encoder 末层 hidden state 投影得到」——关键点在这里。decoder 的压缩条目不是自己算的，是从 encoder 最后一层的 hidden state 投影过来的。这意味着 decoder 的 Block KVCache 不需要重算——它有现成的来源。

「仅 decoder SWA KVCache 需各层自算」——但 SWA 不行。SWA 是每层自己的注意力窗口，没法从别处的 hidden state 投影出来，必须各层自算。

「精确重建要 20 个 decoder 层跑最后 2560 个 token」——这是不截断的代价。20 层 × 2560 token。2560 这个数字的来源 Q&A 没在本篇展开，但它显然是「窗口 × 层数相关量」的组合。关键是对比：精确重建要算 20 × 2560。

「改为每次 prefill 在 decoder 层只重算 prompt 末尾 128 个 token」——截断之后变成 20 层 × 128 token。工作量降了 20 倍。

「产出仅供 decode、不进前缀缓存」——这一句是整段里最重要的限定。decoder 层重算出来的 SWA KV 不进入前缀缓存。为什么？因为它只覆盖了 prompt 末尾 128 个 token，这个范围太短、复用价值太低，而写缓存需要持久化和跨机管理，成本远大于收益。所以它的产物直接投喂给紧随其后的 decode 步，用完即弃。

「总 prefill 计算量近乎减半」——这是最终收益。为什么是「近乎减半」而不是更多？因为减掉的只是 decoder 层 SWA 的重算部分，prefill 里还有其他开销（encoder 层的完整前向、压缩、投影等）。减半是一个合理的量级描述。

官方仓库给出的 prefill 侧 Pareto 曲线交代了这一侧的目标位置——横轴是首 token 延迟（TTFT），纵轴是 prefill 吞吐：

（图源：DeepInfer 官方仓库 doc/images/prefill_pareto.png。Bounded Replay 想动的是这条曲线可及的前沿——它不改变单次前向要算多少 FLOPs，而是把「重建 SWA 状态」这块本可以避免的重复计算砍掉，让同样的算力能落到更多的有效 token 上。）

两处重放的对照

一句话概括两处重放的共同点：都是把「重算」的作用范围限制在 128 个 token、限制在重算段内部，从而把重算代价变成常数。差异在于产物是否值得写进缓存——encoder 侧值得（它会支撑后续多次命中），decoder 侧不值得（它只服务当前这一次请求）。

与磁盘缓存三档策略的关系

本站 DeepSeek V4 注意力机制完全拆解 里介绍过论文侧给磁盘 KV Cache 的共享前缀的三套 SWA 策略：

SWA Bounded Replay 就是 Zero SWA Caching 那一档在工程上的落地方式。「Zero」听起来很吓人——完全不存滑窗 KV，每次都要重算。但有了 Bounded Replay，重算量从「与上下文长度成正比」降到「常数」，Zero 策略才真正可用。论文里那句「重算量 $\le 128 \times L$ 远小于全 prefill」，讲的就是这件事。

从工程视角看，DeepInfer 并没有全局采用 Zero 策略。Q&A 明确说了 SWA KV 是 「留在产生它的那台机器的内存里」，并有 entrypoint 内存目录做跨机索引——这是「存了一部分」的做法，介于 Full 与 Zero 之间。Bounded Replay 是兜底机制：当那份 SWA KV 因为跨机、重启、驱逐等原因拿不到时，用常数代价重算一小段，而不是退化成全量重算。

Prefill 侧的 store

Q&A 的描述：

Prefill 阶段结束后存储：位置取序列末尾留出一个 token 后向下对齐到 128 所得的位置，不足一个 128 tokens 则本轮不存储；chunked prefill 中途不存储，只有最后一个 chunk 才存储。

拆开三个动作：

「位置取序列末尾留出一个 token 后向下对齐到 128 所得的位置」——公式化：

「留出一个 token」是为了保证锚点处已经是完整 token；「向下对齐」保证落在块边界上。

「不足一个 128 tokens 则本轮不存储」——如果 $L \le 128$，$p_{\text{store}}$ 会是 0，没有可存的东西。短 prompt 直接跳过 store。

「chunked prefill 中途不存储，只有最后一个 chunk 才存储」——这是一个很实用的优化。chunked prefill 把一个长 prompt 切成多个 chunk 依次前向，如果每个 chunk 结束都存一次，就会在同一次请求里反复做落盘，浪费 IO。只在最后一个 chunk 存，等于「一个请求一次落盘」。

Decode 侧的 store：副本区机制

Decode 阶段的情况不一样，因为没有「最后一个 chunk」这种天然的结束点。Q&A 给出的方案：

Decode 阶段在显存中另开一块副本区，每跨过一个 128 tokens 边界就把该请求当前的窗口在显存内拷入副本区，请求结束时从副本区中最近一次完成拷贝的位置存储，附着点向下对齐到 128 边界，拷贝位置最多越过边界 5 个 token，由 ring 比窗口多出的 6 个位置吸收。

这段的机制值得逐步还原：

「另开一块副本区」——为什么不能直接存主 ring？因为主 ring 是滚动缓冲区，一直在变。如果从主 ring 直接落盘，落盘的瞬间窗口可能正在被改写（比如 next token 正在写入），就会拷出一个不一致的状态。副本区提供的是一个稳定的快照点。

「每跨过一个 128 tokens 边界就把该请求当前的窗口在显存内拷入副本区」——拷贝的触发条件是「跨过 128 边界」。这意味着副本区里始终有一份「最近一次对齐的完整窗口」。

「请求结束时从副本区中最近一次完成拷贝的位置存储」——请求结束的时候，从副本区取，不从主 ring 取。

「拷贝位置最多越过边界 5 个 token，由 ring 比窗口多出的 6 个位置吸收」——这一句终于解释了那 6 个回退余量的第二个用途（第一个用途是投机解码回滚）。

拷贝在「跨过边界」时触发，但触发检测是有粒度的：可能一次前进多个 token 才检测到跨界。所以实际拷贝位置可能在边界后若干位置——Q&A 给出的上界是最多越过 5 个 token。为什么是 5？这来自 prefill 之外的另一个约束（decode 一次最多推进的 token 数），Q&A 没有展开，但给出了结果：5 ≤ 6，正好被 ring 多出的 6 个位置吸收。

这是一个很漂亮的尺寸论证：ring 多出的 6 个位置，同时承担了投机解码回滚（需要 6）和 store 拷贝越界（需要最多 5）两个需求。取两者最大值 6，一个余量解决两个问题。如果这两个需求没有对齐——比如拷贝可能越界 8 个——那么 ring 就得多留 2 个位置，整个布局的三个尺寸推导都要重来。

store 内容与介质

Q&A 把落盘的内容算得很具体：

落进 store 的只有 state_size_to_disk = 20 层 × 134 token × 528 B = 1,415,040 B/seq。528 B/token 是 MXFP8 的 SWA KV 格式。SWA KVCache 不进持久化缓存，而是留在产生它的那台机器的内存里……

三点：

只有 state_size_to_disk 这部分落 store。 也就是 StateBlock 的第一段（stored region）。dropped region 不落——它的恢复依赖重算。

按 20 层的量算。 不是全部 43 层（V4-Flash 的总层数）。这与「V41 store 的层是前 20 层」一致。

介质是「产生它的那台机器的内存」，不是持久化集群。 与 Block KVCache 走 3FS 完全不同。这带来两个后果：SWA KV 在机器重启后丢失（必须重算）；跨机命中要走 400G VLAN 回拉（Q&A：「跨机命中靠 entrypoint 的内存目录配合 400G VLAN 回拉」）。

顺带看一下这套设计与 3FS 的分工。Q&A 关于 3FS 的描述提到 Block KVCache 用纠删码存储（10+2 Erasure Coding，每个 EC 组容忍 2 节点同时故障）、GC Worker 按 LRU 周期性淘汰、TTL 对于 agent 流量 3 天、chatbot 7 天。这些机制只服务第一本账。第二本账（状态槽里的 SWA KV）走的是完全不同的路径：本机内存 + entrypoint 内存目录 + VLAN 回拉。

两本账的介质差异，其实是它们性质的必然推论：

• 压缩条目是「序列历史」，值得持久化、值得纠删码保护、值得跨机共享；
• SWA KV 是「序列状态」，只与当前位置有关，持久化的价值低（换了位置就没用了），跨机共享的收益也低（只有窗口那一小段）。

跨机取回的两种路径

Q&A 提到 SWA KVCache「命中时本机没有就跨机取回」。这里的权衡是：跨机取回需要走网络，而重算只需要 GPU 时间。什么时候取、什么时候算？

虽然没有直白的阈值公式，但从机制上可以推断出决策依据：取回 1.4 MB 的 20 层窗口，与重算 128 个 token 的 20 层前向，谁便宜。这个比较依赖于具体的网络带宽（400G VLAN）与 GPU 算力，也依赖当前的 GPU 是否空闲。如果 GPU 恰好闲着而网络拥塞，重算更划算；反之取回更划算。

Q&A 里还有一条关于 overlap 的描述，说明取回路径本身是精心设计过的：

取 KV 在独立进程里异步做，把 KVCache 从 3FS 搬进宿主机 shm；换入从 shm 到 HBM 在 engine 进程内的线程里做，目标是实现逐层 H2D 传输与前向计算重叠，由于 CUDA copy engine 对于 KVCache Block 细粒度的拷贝性能不佳，换入使用 GDR 实现，用 RDMA 网卡就能打满 PCIe 带宽，并且不占 SM。

这段讲的是 Block KVCache（第一本账）的取回，但它揭示的工程要点对两本账都适用：用 GDR（GPUDirect RDMA）而不是 CUDA copy engine 做换入。理由是「CUDA copy engine 对于 Block 细粒度的拷贝性能不佳」——细粒度小拷贝会打不满带宽。用 RDMA 网卡直接写 GPU 显存，既能打满 PCIe，又不占用 SM（流多处理器）。这是一个典型的「省下 SM 去算注意力」的优化。