SWA 有界重放：SSD 上只剩八分之一

滑动窗口缓存不再写进 SSD，缺了就只重算最后 128 个 token。这个部署层面的取舍让持久化缓存缩到前代的约 1/8，代价是恢复出来的状态只是近似。

前两章讲的是全局 KV：跨越整个上下文、随长度增长、运行时常驻 HBM 的那部分缓存。每一层还有另一份缓存：最近 128 个 token 的滑动窗口 KV（SWA KV）。窗口长度固定，它的大小与上下文长度无关，看起来无关紧要——直到你要把缓存存下来。

持久化缓存是什么

DeepSeek 的服务会把算过的前缀 KV 持久化，供后续相同前缀的请求复用，这部分叫持久化 KV 缓存，受 SSD 和主机内存容量约束 [1]。V4 时代的做法是 [1]：

全局 KV 与 SWA KV 分开管理，都按 LRU 淘汰；
全局 KV 整段存储，命中就复用整个前缀；
SWA KV 只在两个位置存档——提示词末尾和输出末尾，方便重新生成和多轮对话从那里接着算；
SSD 上的持久化缓存配得足够大，典型负载下两类缓存都能驻留 72 小时以上。

问题在于：虽然每个存档点只存 128 个 token 的窗口，但它不压缩，而且每层一份。报告说在 V4 的部署里，SWA KV 占了持久化缓存将近一半的容量，多轮、每轮很短的对话尤其浪费 [1]。

为什么存 SWA KV 不划算

报告的判断是：持久化存 SWA KV“既昂贵又低效”，因为它的访问模式和持久化缓存的长保留策略不匹配 [1]。全局 KV 有长尾复用——同一份长文档可能几天后还会被问；SWA KV 只在一个活跃会话内几分钟的时间窗里被复用，会话结束或进入下一轮就没用了。

那干脆不存、缺了就重算？V4 的技术报告提过这种“零 SWA 缓存”方案，但精确重算很贵：滑动窗口的依赖会逐层累积，第 $l$ 层窗口里的状态依赖第 $l-1$ 层更早的位置，要精确恢复 $L$ 层的窗口状态，就得把最近“层数 × 窗口长度”个 token 重新前向一遍。报告说这在生产环境里代价高得不可接受 [1]。

V4.1 的做法：只重放 128 个 token

V4.1 改了两件事 [1]：

SWA KV 不再进持久化缓存，改放在一个分布式内存池里，池子取自每台机器 10% 的主机内存，存活时间只有几分钟，过期即回收给新会话。报告说在真实负载下，这种高周转足以覆盖绝大多数并发活跃会话。全局 KV 仍留在持久化缓存里，保证至少 72 小时。
缺了就有界重放：少数请求会遇到“全局 KV 命中、SWA KV 已被淘汰”。这时只重放缓存前缀的最后 128 个 token，和未缓存的后缀一起处理；重放的 token 只重新生成 SWA KV，全局 KV 直接复用、不重算也不覆盖。

具体做法是把滑动窗口截断在重放段内：从位置 $s$ 开始重放时，位置 $t$ 的 query 只看 $\max(s, t-127)$ 到 $t$ 之间的窗口 [1]。报告把它称为这套设计的“基石”：一次灾难性的缓存缺失，变成一次便宜的、温和的降级。

同一个技巧用在两处：

	编码器 SWA 有界重放	解码器 SWA 有界重放
什么时候用	全局 KV 命中、编码器的 SWA KV 缺失	每次预填充都用
重放多少	缓存前缀的最后 128 个 token	提示词的最后 128 个 token
得到什么	让前缀缓存只依赖全局 KV，SWA KV 从持久化缓存里拿掉	解码器的 SWA KV，只用于接下来的解码，不进前缀缓存
解决什么	存储	计算（配合 CED 把预填充砍掉近一半）

1/8 是怎么乘出来的

报告给的解释是两个相乘的因素 [1]：

持久化缓存不再存 SWA KV——在 V4 的部署里它占将近一半，这一项让体积几乎减半；
留下来的全局 KV，经过 CSA2 与 FP4 再压到 V4 的 1/4。

两者相乘，同样负载下持久化缓存约为 V4 的 1/8。官方公告的对应说法是：对 HBM 的需求减少到 1/4，对 SSD 的需求减少到 1/8 [2]。

代价：近似，而且与命中位置有关

重放出来的状态是近似的。 被截断的窗口看不到重放段之前的内容，所以恢复出的 SWA KV 与完整前向并不数学等价。报告为此给了两条理由 [1]：

已有研究表明，滑动窗口的有效感受野远小于理论上的“层数 × 窗口”；
他们的实验显示，这种近似对回答质量的影响“几乎可以忽略”；解码器那一侧还在后训练时模拟了同样的重放，让模型提前适应。

还有一个不那么显眼的后果：报告明确说，未缓存后缀算出来的全局 KV 与 SWA KV 取决于缓存命中的位置，不同命中位置之间并不数学相同 [1]。换句话说，同一段对话，缓存命中在哪里，模型内部的状态就可能略有不同。对需要严格复现的场景（例如回归测试、评测），这是一个值得记下的变量。

“影响可以忽略”是官方口径，报告没有公开对应的数字。报告在局限性一节也把“缓存恢复边界处的 SWA 状态重建”列为需要继续压测的方向 [1]。另外，这一章讲的全是 DeepSeek 自己的服务端部署策略：自托管时是否持久化、怎么重放，取决于你用的推理引擎是否实现了同样的机制。

和账单的关系

官方公告在介绍缓存压缩时特意说：Agent 场景里，缓存命中的费用往往占比较高，KV Cache 的压缩大幅降低了这类任务的成本 [2]。V4.1-Flash 上线时的缓存命中价比前一天的 V4-Flash 低了约 57%（见规格总表）。价格怎么定是商业决策，但方向与“存得更少”一致。

第一部分到此结束。下一部分转向主干：MoE、残差流与两个新加的组件。👉 1 + 384 选 6

参考文献

[1] DeepSeek-AI. “DeepSeek-V4.1-Flash: Pushing the Limits of KV Cache Compression.” 2026-09. arXiv:2609.19969 —— 第 1 节（全局 KV 与 SWA KV、持久化缓存的定义）、第 3.2.1 节（V4 的持久化缓存管理、SWA KV 占比、72 小时、10% 主机内存池）、第 3.2.2 节（编码器与解码器 SWA 有界重放、截断规则、非数学等价的说明）、第 6 节（局限性）。
[2] DeepSeek. “DeepSeek-V4.1-Flash 发布.” 2026-09-10. api-docs.deepseek.com/zh-cn/news/news260910 —— “对 HBM 的需求减少到 1/4，对 SSD 的需求减少到 1/8”与缓存命中费用的说法。