KV cache 的下一层问题：什么状态才算真正可恢复？

1. 先拆开三条分析轴

讨论 KV cache 时，很容易把“缓存在哪里”“状态有多大”和“命中后能否续算”混成一个问题。存储后端解决了容量与搬运，但 hybrid 模型还提出另一层约束：下一次请求要恢复哪些组件，这些组件是否对应同一个前缀边界？

第一条轴是状态规模。Full KV、MLA、DSA 所需历史表示随上下文增长；SWA 窗口与 KDA、Mamba 的单个续算状态有界。不过，有界的是一个状态快照，大量历史 checkpoint 仍会累积容量，不能据此推出整个缓存固定大小。

第二条轴是恢复语义：历史页可命中、窗口完整、recurrent checkpoint 存在，是不同条件。第三条轴是驻留与路径：L1 HBM、L2 host、L3 外存描述位置，direct linker 描述访问路径。共享池、跨请求留存与提前 prefetch，也应分别讨论。

支持横向滑动查看

2. 模型状态决定合法恢复边界

DeepSeek-V4.1-Flash 报告将 global KV 长期保留在 persistent cache，把 SWA KV 放入短 TTL 的分布式 host 内存池；SWA 缺失时，以最近一个窗口 replay 做近似重建。这展示了特定模型的存储与重算取舍，不能直接推广成 KDA、Mamba 的精确恢复方法。报告也保留了 cache-resumption 鲁棒性风险。

这里的 persistent 是部署中的留存语义，不能仅凭名称推断通用断电持久性。类似地，“全量历史可表示”也不意味着所有 KV 页永不淘汰。模型表示能力与缓存管理策略之间，需要保留这条分界。

Marconi 处理的困难是 recurrent state 会原地更新，无法像历史 KV 那样任意截短复用，因此要选择值得保存的边界。vLLM #37898 用普通 attention 命中长于 SSM 命中的差异发现未留存的共享前缀，再在 block 对齐边界补算并保留 checkpoint；这不要求显式 session 计数器。轮末边界和共享前缀边界是互补线索。

状态在同一边界齐备，还不等于这次请求可以复用。9 月 30 日的 Shared KV Provenance v1 将计算来源一致与共享许可分成独立条件：相同 token 的 KV 可能来自另一 adapter／权重配置，即使状态值相同，租户策略也可能禁止共享。其旧版 vLLM 与指定 SGLang 版本实验不能当作当前主干漏洞结论；对 Mooncake 的证据仅限作者源码审计。对这里的恢复实验，除组件与 checkpoint 外，还应记录实际解析后的配置身份和授权 namespace，以隔离环境中的 no-cache、自播种 warm 与跨身份读取对照核验。

身份匹配之外，Agent 改计划还需要写入寿命与发布权限的交接。10 月 2 日新列表的 Retire v1 在作者的 vLLM 0.13.0 原型里先撤销旧 scope／epoch 的输出与状态提交权限，再关闭旧 writer；只有配置、租户与 ownership generation 合法、各参与者均已完成且对齐各 KV group 共同 block 边界的前缀才能继承。该前缀保留到后继采用，旧 suffix 则隔离到最后写入者退出后回收；迟到传输还须检查目标版本。这提示恢复验证应同时观察状态身份、写入关闭与继承期留存，不能仅凭 token 匹配或传输完成判定可安全续算。以上是论文原型契约，不代表当前 vLLM 主干已实现这些机制；本站未独立复现。

齐备状态还需要生命周期有效。10 月 2 日的 NIXL Draft #59713 把生产端明确导出的 lease 期限作为读取边界：未确认的心跳不再证明块仍被保留，到期走重算或报错；#59635 则把注册与 allocator 的 unmap/map 绑定，唤醒后用新 epoch 刷新远端 keys。同一虚拟地址、同一前缀和一个传输成功返回，都不能单独证明读到的仍是请求所属物理状态。固定代码与假时钟测试支持这些边界，但长 READ 越过 lease、旧 peer 缺 expiry 以及异构 TP push 竞态仍未封闭；二者尚未合并，本站未复现硬件。

3. 能匹配，不代表能留到下次

缓存树能找到共享前缀，只说明存在匹配关系。请求回来时，相关页与 checkpoint 是否仍驻留、是否被锁定、恢复是否赶得上准入，才决定命中的实际价值。Cache in the Wild 在其生产 traces 中观察到 cross-user 命中较少，同时指出单轮 API 的共享 system prompt 很重要；不能据此否定同一用户跨 session 的复用。

Preble 将分布式前缀复用与负载均衡联合考虑，也提醒我们：共享池建立后，路由、局部驻留与排队仍会改变收益。对新 code-agent 工作负载，既有论文是比较基线，目标部署的 traces 才能回答复用间隔与容量是否匹配。

容量测量同样需要拆分。L1、L2 至少应区分 active／locked、可淘汰 cache、free 与 in-flight。token_usage 的口径必须按部署 commit 核验；一个利用率数值无法说明所有已分配状态，也无法区分天然缺少共享与缓存留存不足。

4. 用有效恢复量检验缓存策略

更有解释力的指标是“组件齐备且实际被采用的恢复 token 数”。如果 KV 页命中增加了，合法 checkpoint 却没有覆盖更长前缀，对请求而言可能没有新增收益。SGLang direct linker 的具体实现，正好提供了观察这个边界的源码切口；其 LOAD、COMMIT 与 COW 机制放在关联文章中单独分析。

容量侧还可先建立可检验的基线。9 月 23 日的 KVSET v1 用 LRU stack distance 估计页驻留工作集，避免为每个容量独立回放。固定实现默认要求每个请求保住其理论可复用连续前缀的 99%（向上取整到页），若再取所需容量的 p99，则表示让约 99% 的请求达到这个目标；这两个 99% 不是全局 token 命中率。论文明确只估 Full-Attention KV，Mamba／SWA 需另留预算。因此，页容量曲线可以作为恢复实验的输入，但还要对照同一边界的 checkpoint 与必需组件，测量实际 adopted tokens，不能用页驻留替代状态齐备或性能证据。

一个待验证的实验是固定总容量，对比分组件 LRU、固定间隔 checkpoint 与共享分支边界优先保留。恢复位置覆盖 checkpoint 前后和分叉位置，同时记录 adopted tokens、齐备组件、重算量、写入放大，并检查 logits 或 logprob。若策略只提高对象 hit，却不提高可恢复长度，假设就不成立。

性能还要回到时间线。HiCache 已在 waiting queue 阶段提前 prefetch，不能假设它等 admission 后才搬运。应比较准入时尚未完成的传输、L2→L1 与同步等待，再测 TTFT 和 HBM 占用时间。恢复正确、命中更多、端到端更快，是需要分别建立的证据。

恢复预算也不等于只数一份 checkpoint。仍在评审的 SGLang #36345 把 Mamba 接入 buffer-only：一个 host checkpoint 要分别装入树节点和请求私有两个 device 槽，admission 因此同时计费；请求侧独立 H2D 受 layer gate 保护，重复节点目的槽则要留到 transfer ack。缺少 Mamba state 时，已取回的 Full KV 不能独自构成有效恢复，代码会放弃该 staged hit 并重算。作者的 H200／Inkling 小范围测试通过 flush 排除 L1 命中，8 次均恢复 512 tokens、KL 为 0；它支持这条 handoff 路径的正确性观察，尚不能回答容量压力、其他模型和端到端时延收益。

输出一致性也要固定数值执行条件。Vosti 的固定实现把 hash 当索引，继续核对页内 tokens、前缀深度与物理 parent，并将同一部署内的输出轨迹定义为 prefix-comparable；源码明确这不保证调度最终完成。它提供了对照恢复路径的测试思路，却尚未证明节省窗口外状态的 SWA 淘汰，也不覆盖 KDA／Mamba、MoE 或跨 GPU 布局。因此，恢复前后 logits 的差异应先与相同部署、相同 token 轨迹及已知 kernel 切换基线比较，不能直接把所有差异归为缓存错读。