July 29, 2026 中 #KV Cache #LLM Inference #Attention & MLA

LOCKS 阅读笔记：为什么 KV Cache 摘要要按「页」而不是按「序列」或「全局」来建

笔记日期： 2026-07-29 作者： Zhongzhu Zhou 阅读论文： LOCKS: Page-Local Compact Key Summaries for Efficient Long-Context Decoding 论文作者： Junsung Hwang arXiv： 2607.24555 发表状态： 预印本，2026 年 7 月 28 日

1. 为什么读这篇，它到底在解决什么问题

如果你实际部署过长上下文的 LLM 服务，大概率遇到过这样一个具体又烦人的情况：模型权重轻轻松松能塞进显卡显存,但单个 128K token 请求的 KV cache 却塞不下。以 Llama-3.1-8B 用 bf16 存 KV 为例，一个 128K 上下文的 KV cache 大约占 16 GiB —— 比模型权重本身还大。再乘以一个 batch 里并发的多个请求，你就同时撞上了两个互相抢占同一块加速卡资源、但本质不同的瓶颈：能装下多少 KV cache（容量问题），以及每个 decode step 要读多少 KV 字节（带宽问题）。这两者常被混为一谈，但其实是完全独立的问题。LOCKS 精准地针对第二个：它把整个 KV cache 都留在显存里，但在每一个 decode step，只读取其中很小一部分。

这个思路本身并不新——decode 阶段的稀疏注意力已经有很多名字：Quest、ShadowKV、Loki、H2O 式驱逐、RocketKV 等等。这篇论文有意思的地方不在于”又一个 selector”，而在于它对为什么现有的 selector 在极端预算下会掉质量给出了一个具体、可证伪的解释——背后有一个干净的理论不可能性结果，加上一整条相互衔接的实证测量链，精准定位每一个竞争方法具体在哪一环失效。如果你做 KV cache 压缩、量化，或者长上下文服务，这篇论文值得细读，因为它的核心论点——“表征的范围（scope）决定保真度，而不是大小（size）“——很可能能推广到这篇论文之外的很多场景。

前置知识：读懂这篇论文需要什么

如果你已经熟悉分页式 KV cache 服务（vLLM 那一套）、query-aware 稀疏注意力，以及基础线性代数（SVD / 特征分解），可以直接跳到第 3 节。否则，这里把必要背景压缩成你实际需要的部分。

decode 阶段的注意力，一句话讲清楚。 在自回归生成过程中，每个新生成的 query token 都要对之前所有缓存的 key、value 做注意力计算： $\mathbf{o} = \sum_i \alpha_i \mathbf{v}_i$ ，其中 $\alpha = \mathrm{softmax}(\mathbf{q}^\top \mathbf{k} / \sqrt{d})$ 。在 prefill 阶段，这是一次大批量矩阵乘法；但在 decode 阶段，每生成一个 token 就要做一次，而且 query 每次只有一行。正是这种不对称，让 KV cache 的读带宽在长上下文、大 batch 场景下成为瓶颈：prefill 阶段权重读取能在多个 token 间摊销，但 batch 里每个序列的每一次 decode step 都必须完整读取自己的 KV cache，这部分开销无法摊销。

分页式 KV cache 服务。 vLLM 及其后续系统把 KV cache 存成固定大小、由 $B$ 个连续 token 组成的”页”（page，也叫 block），而不是一整块按序列排布的连续缓冲区。这样做既方便内存管理（页可以像虚拟内存系统一样按需分配/释放），对本文来说更关键的是：它给稀疏注意力的”保留还是丢弃”决策提供了一个天然的粒度单位——不用逐 token 判断，而是逐”页”判断。

为什么稀疏 decode 注意力能生效。 经验上，在任意一个 decode step，只有少数几个 page 承载了这次 query 几乎全部的注意力质量——cache 里剩下的大部分内容对这一步的输出几乎无关紧要。这个现象被反复观察和利用过（H2O、StreamingLLM 的 sink+window、Quest 等）。如果能在不读取任何内容的情况下就便宜地识别出哪些页重要，就能跳过读取剩余部分，在几乎不损失质量的情况下获得很大加速。问题在于”便宜地识别”——想要精确回答这个问题，就必须读取 cache 里的每一个 key，这就违背了初衷。所以每一个实用的稀疏 decode 方法都需要某种紧凑的、常驻显存的摘要，让你可以在不读取完整 key 的情况下按重要性给页排序。

低秩分解 / 特征分解基础。 如果把一组向量堆叠成矩阵 $D \in \mathbb{R}^{B \times d}$ 的行，Gram 矩阵 $DD^\top$ （或者说 $D$ 里类协方差的结构）可以做特征分解，找到这批向量云里方差最大的方向。只保留前 $r$ 个特征向量，就得到一个秩- $r$ 近似：每一行都可以近似表示成仅 $r$ 个基向量的线性组合，而不是原来完整的 $d$ 维向量。这正是 LOCKS 用来把每个 page 的 key 压缩成一个更小”谱摘要”（spectral summary）的数学工具。这篇论文的核心实证主张恰恰在于在哪个范围拟合这个基：逐页（本文）、逐序列（ShadowKV），还是整个 cache 全局（Loki）——而这个选择的影响巨大。

log-sum-exp（LSE）作为注意力质量的代理指标。 对一组未归一化的注意力 logit $\{z_i\}$ ， $\log \sum_i e^{z_i}$ 是一个平滑、可导的量，用来表示”这组 token 在归一化之前承载了多少总注意力质量”。它在高效注意力研究里频繁出现，因为它让你可以估计某一页在总注意力质量中的占比，而不需要对整个序列做完整的 softmax——只需要这一页的 logit 相对于所有页合起来的 LSE。

有了这些词汇，后面的内容就好理解了。

2. 架构总览：LOCKS 到底建了什么、做了什么

从高层看，LOCKS 是一个可直接插入未修改 vLLM 的注意力后端插件。它不需要改模型权重、不需要微调、不需要训练一个 gating 网络——完全免训练。安装之后，它的工作是拦截 decode 阶段的注意力计算，对每个 KV head 的每一个 decode step，判断 cache 里哪些页值得完整读取。

flowchart TD
    A["新 token 到来，形成 query q"] --> B{"页刚写满？"}
    B -- "是" --> C["构建阶段：对该页居中后的<br/>key 做特征分解，保留秩-r 基 V_j<br/>+ 系数 c_i，量化为 int4/int8"]
    C --> D["存储逐页谱摘要<br/>（约为该页 KV 字节数的十分之一）"]
    B -- "否 / 已构建" --> E["打分阶段：从摘要重建<br/>页内 logit，用 log-sum-exp 归约"]
    D --> E
    E --> F["归一化为每个 query 的页质量占比"]
    F --> G["跨 GQA 组做共享平均<br/>-> 组内所有 head 共用一个排序"]
    G --> H["选中 sink 页 + 最近页<br/>+ 按平均占比排序的 top-(k-2) 页"]
    H --> I["仅为选中的页取回完整 K/V"]
    I --> J["仅对选中页做标准注意力"]

图 1（自绘 Mermaid）：LOCKS 的两阶段流水线——每个页写满时执行一次性构建阶段，以及每个 decode step 都要跑的打分/选择/注意力循环，选择阶段全程不碰完整 key/value。

这个设计干净地分成两个执行频率截然不同的阶段：

构建（每页写满一次）。 这一步很便宜：只需一次很小的 $B \times B$ 特征分解（记住 $B$ 是页大小，通常是 16 个 token——所以这是一个 $16\times16$ 的小特征值问题，不是什么复杂运算）。它运行在 decode 关键路径之外，对 prompt 部分在 prefill-decode 边界批量执行，对生成过程中新写满的页则增量执行。
打分（每个 decode step，每个 KV head 都要跑一次）。 这是频率高但单次计算量很小的部分：对每个页，从存储的小摘要重建其页内 logit（一次矩阵-向量乘法加一次长度为 $B$ 的 log-sum-exp），按估计的注意力质量占比给页排序，选出 top- $k$ （扣掉预留给 sink 页和最近页的两个名额）。

让这套设计真正可部署的关键架构决策是：选择阶段本身从不读取任何候选 key 或 value——只读取那些体积约为原页十分之一的常驻摘要。只有在选择之后，引擎才会为选中的页取回完整 K/V，并对这个缩小后的集合做常规注意力计算。

数据流概览

flowchart LR
    subgraph Resident["常驻显存"]
        FullKV["完整 KV cache<br/>（每一页每一个 token）"]
        Summ["逐页谱摘要<br/>（int4 基 + int8 系数，约 1/10 大小）"]
    end
    Query["decode 阶段 query q"] --> Score["仅用摘要<br/>为所有页打分"]
    Summ --> Score
    Score --> Select["选出 top-k 页<br/>（sink + 最近页 + 排序结果）"]
    Select --> Fetch["仅为选中页<br/>取回完整 K,V"]
    FullKV --> Fetch
    Fetch --> Attn["对选中页做<br/>标准 softmax 注意力"]
    Attn --> Out["输出 o"]

图 2（自绘 Mermaid）：数据流视角。注意，完整 KV cache 始终常驻显存（这是一个带宽优化，不是容量优化）——摘要改变的只是每一步读取什么，而不是存储什么。

这个区别值得多花一秒钟琢磨清楚，因为很容易把 LOCKS 和真正会丢弃 token 以节省内存的驱逐类方法（H2O、StreamingLLM 式的 window+sink、R-KV）混为一谈。LOCKS 什么都不驱逐——每个 token 永远留在 cache 里，以防未来某个 query 需要它。LOCKS 减少的是decode 阶段的读取流量，而当你的 cache 大到”读取它”（而不是”存储它”）成为吞吐瓶颈时，这才是真正制约性能的东西。

3. 核心理论主张：表征范围（而非大小）决定保真度

这是论文的思想核心，值得仔细梳理，因为它的论证分两部分：一个实证的”局部性发现”，加一个形式化的不可能性证明。

3.1 铺垫：一个好的页摘要必须保留什么

论文第 2 节先明确了任何摘要都应该逼近的目标量。对于一个决策步骤保留的页集合 $S$ ，被丢弃的补集 $S^c$ ，论文给出一个精确恒等式（归功于 Tzachristas 等人与 Tian 等人的同期工作），描述注意力输出的变化量：

\mathbf{o} - \mathbf{o}_S = \varepsilon(\bar{\mathbf{v}}_{S^c} - \bar{\mathbf{v}}_S), \qquad \varepsilon = 1 - \gamma_S(\mathbf{q}) \tag{1}

其中 $\gamma_S(\mathbf{q})$ 是这个 query 的总注意力质量落在 $S$ 内的比例， $\bar{\mathbf{v}}_S, \bar{\mathbf{v}}_{S^c}$ 分别是保留集合与丢弃集合按质量加权的均值 value。

为什么这一点重要，以及背后的直觉。 这个恒等式说明，丢弃页带来的输出误差不是简单地正比于丢了多少质量（ $\varepsilon$ ）——而是丢掉的质量乘以保留部分与丢弃部分之间的差异。如果丢弃的页所携带的 value 看起来跟保留部分的均值很像（即 $\bar{\mathbf{v}}_{S^c} \approx \bar{\mathbf{v}}_S$ ），那即使丢掉很多质量也很便宜，因为你只是丢了”更多类似的东西”。但如果你恰好丢掉了一个承载单一、独特、罕见 token 的页——这个 token 携带了序列中其他任何地方都没有重复的信息——那么即使这个 token 携带的原始概率质量很小， $\bar{\mathbf{v}}_{S^c}$ 也会与 $\bar{\mathbf{v}}_S$ 剧烈偏离，误差项会趋近其理论上限。这正是稀疏注意力在”大海捞针”任务上失败的机制：针 token 往往 softmax 权重很小，所以一个只优化”平均保留质量”的 selector 没有任何信号提示它这个 token 重要——但丢掉它对输出质量是灾难性的。

这对选择策略意味着什么。 基于这个恒等式，论文推导出（引理 1，证明见附录）：在不读取 value $\{\mathbf{v}_i\}$ 的确定性选择规则中（即只看 query/key 信息、不看每个页实际存了什么内容的规则），按精确 log-sum-exp 注意力质量给页排序是最坏情况下最优的。这就给了 LOCKS 一个明确的目标量：用一个便宜的常驻摘要，尽可能逼近按精确 LSE 质量排序的结果。

设计选择讨论：为什么不干脆追踪总的”平均捕获质量”，而不是”关键页留存率”？ 显而易见的替代指标是”我选中的集合在多次 query 上平均捕获了多少总注意力质量”——不少竞争方法（尤其是基于包络的 selector Quest）在这个指标上表现相当不错，即使在很小的预算下也是如此。论文的诊断手法是把这个”整体质量”指标和第二个指标区分开：关键页留存率（carrier-page retention）——具体来说，对某个任务而言真正决定性的少数几个页（比如检索任务里存有密码的那一页）是否在选择中幸存下来。论文表明这两个指标可以剧烈背离：Quest 在整体捕获质量上紧跟精确质量 oracle，但关键页留存率却不到一半（图 1b）。平均意义下的保真度掩盖了最坏情况（关键页）的失败。这是一个独立于本文其余内容、本身就很有用的方法论启示：如果你在评估一个稀疏注意力 selector，一定要测量关键页召回率，而不只是捕获质量，否则你会系统性地高估检索密集型任务上的质量。

3.2 局部性发现：逐页特征基比共享基捕获更多能量

既然精确 LSE 质量需要读取每个 key（这违背了初衷），LOCKS 需要一个能近似它的摘要。自然的做法——也是先前工作采用的——是一次性拟合一个共享低秩投影，要么覆盖整个 cache（Loki：一个离线校准的共享 PCA 基），要么逐序列（ShadowKV：每个序列一个低秩基，刷新频率低于逐页）。LOCKS 则为每一个页单独拟合一个基。

论文的第一个实证主张是一个”剂量-反应”模式：随着基的拟合范围从全 cache 缩小到逐序列，再缩小到逐页，在固定秩下捕获的页内 key 能量比例大幅上升。一个页自己的秩-8 特征基能捕获该页大部分 key 能量；一个逐序列的基只能捕获其中一小部分；一个整 cache 共享的基几乎捕获不到任何东西。关键的是，论文控制了一个自然的质疑——“也许共享基只是需要更多状态（更高的秩）才能追上”——并证明即使把共享基的秩增大到匹配甚至超过逐页基的总存储字节数，它依然落后于逐页保真度（附录表 D.15）。这排除了”大小”作为解释,把矛头精准指向”范围”。

3.3 不可能性证明：为什么共享基被证明是对页内容”盲”的

这是论文里最锋利的一块内容，值得完整拆解。命题 1（非形式化表述）：固定任意共享线性投影 $W \in \mathbb{R}^{d \times \rho}$ （ $\rho < d$ ），以及任意只依赖 query、页质心 $\mu$ 、被草图化的 key $\{W^\top \mathbf{k}_i\}$ 的打分规则。那么存在一个 $(d-\rho)$ 维的页内内容变化族，这个打分规则对其完全看不见——以某种方式改变实际的 key，使得真实注意力质量剧烈变化，但打分结果却零变化。

逐步拆解这个构造。 取任意与 $W$ 的张成空间正交的单位向量 $u$ （这个正交空间维度为 $d - \rho$ ，所以只要共享投影的秩小于全维度，这样的方向必然存在）。取一个至少含两个 key 的页 $P$ ，构造修改后的页 $P'$ ：给其中一个 key 加上 $c\cdot u$ ，给另一个 key 减去 $c\cdot u$ （ $c > 0$ 任意）。因为 $u \perp \mathrm{span}(W)$ ，这两个 key 的草图 $W^\top \mathbf{k}_i$ 完全不受这个扰动影响—— $P'$ 的共享摘要与 $P$ 逐字节相同。所以任何只基于这个草图构建的打分规则，都必然对 $P$ 和 $P'$ 给出相同分数，对任意 query 都是如此。

但真实的对数质量并不相同。 对任意满足 $q^\top u > 0$ 的 query $q$ ， $P'$ 的实际（精确）log-sum-exp 注意力质量会随 $c \to \infty$ 无界地偏离 $P$ ——因为真实的注意力 logit 确实依赖完整的 key 向量，包括它们在 $u$ 方向上的分量,即使共享草图完全看不到这个分量。

为什么这一点在实践中很重要，而不仅是数学上的趣味结论。 这不是关于”某个 $W$ 选得不好”的陈述；它对每一个秩小于 $d$ 的固定共享 $W$ 都成立，无论如何校准。它把”一个基适配所有页”这种做法的直觉形式化了：这种做法必然会丢弃整整一部分页特有的变化维度，而主要活在这些盲方向里的内容，对 selector 来说是不可见的——不是近似得差，而是精确为零信息。逐页的基没有这个问题，因为每个页都拥有一个专门针对该页自身内容拟合的 $\rho$ 维子空间，不存在所有页共享的固定盲区。

替代方案与边界。 显而易见的反驳是：“那就在线自适应地刷新 $W$ 。” 这个命题明确不覆盖随底层 cache 变化而自适应刷新共享基的做法——那类方案只能通过实证（附录里的”范围前沿”消融）来评估，而非被这个定理排除。这是一个值得指出的诚实边界：不可能性结果是关于固定共享基的陈述，而足够激进的在线刷新方案是这个论证没有完全封死的一条逃生通道，尽管论文指出，在其测量范围内，这类方案在实践中尚未达到逐页保真度的水平。

4. LOCKS 的具体构造：如何构建和打分一个逐页基

弄清楚了为什么需要逐页范围之后，下面是 LOCKS 具体如何构建和使用其逐页摘要。

4.1 构建阶段——完整推导

对于一个含 $B$ 个 token 的页 $P_j$ ，设 $\mathbf{k}_i$ 为（RoPE 之后的）key 向量， $i \in P_j$ 。首先对该页居中：

\mathbf{k}_i = \mu_j + \delta_i, \qquad \sum_{i \in P_j} \delta_i = 0 \tag{2}

即 $\mu_j$ 就是该页 key 的均值， $\delta_i$ 是每个 key 相对均值的偏差。把这些偏差堆叠成矩阵 $D_j \in \mathbb{R}^{B \times d}$ 的行。因为 $B$ （页大小，比如 16）通常远小于 $d$ （head 维度，比如 128），对小的 $B \times B$ Gram 矩阵做特征分解，比对大的 $d \times d$ 协方差矩阵做特征分解要便宜得多：

D_j D_j^\top = U_j \Sigma_j^2 U_j^\top \in \mathbb{R}^{B \times B} \tag{3}

特征值 $\sigma_{j,1}^2 \geq \sigma_{j,2}^2 \geq \cdots$ （正好是 $D_j$ 的奇异值平方），特征向量给出右奇异向量 $v_{j,k}$ （通过标准的”从 Gram 矩阵求 SVD”关系）。只保留前 $r$ 个分量，得到：

系数 $c_i \in \mathbb{R}^r$ —— $C_j = U_{j,r}\Sigma_{j,r}$ 的各行，等价于 $c_i = V_j^\top \delta_i$ （每个 key 偏差投影到保留基上的结果）。
正交基 $V_j = D_j^\top U_{j,r} \Sigma_{j,r}^{-1} = [v_{j,1} \cdots v_{j,r}] \in \mathbb{R}^{d \times r}$ 。

重建 $\delta_i \approx V_j c_i$ 在 $r \geq \mathrm{rank}(D_j)$ 时是精确的（即如果该页真实的 key 偏差点云本身就活在一个 $r$ 维子空间里，你不会损失任何信息），否则误差以谱尾（spectral tail） $\tau_{j,r} = \sum_{k>r} \sigma_{j,k}^2$ 为界——字面意义上就是被丢弃方向的奇异值平方之和。这个谱尾量在下面的主定理里会再次出现，也是一般性理解特征分解/SVD 压缩误差的自然方式：你付出的误差恰好等于被丢弃方向里剩下的”能量”。

存储。 基以 int4 存储，系数和质心以 int8 存储（带逐列/逐行量化 scale）。在出货配置下（ $r=8$ ， $B=16$ ），逻辑负载约为该页原始 KV 字节数的 9.4%——算上量化 scale 的开销大约十分之一。构建摘要只需对每个写满的页做一次很小的特征分解，运行在 decode 关键路径之外；完全不影响模型的 prefill 注意力路径。

4.2 打分阶段——完整推导

每个 decode step，对 query $\mathbf{q}$ 和页 $j$ ，LOCKS 仅从摘要重建页内 logit，并用 log-sum-exp 归约：

\hat{s}_j(\mathbf{q}) = \log \sum_{i \in P_j} \exp\!\left( \frac{\mathbf{q}^\top \mu_j + (V_j^\top \mathbf{q})^\top c_i}{\sqrt{d}} \right) \tag{4}

这个式子从哪来。 query $\mathbf{q}$ 对 key $\mathbf{k}_i$ 的真实（精确）注意力 logit 是 $\mathbf{q}^\top \mathbf{k}_i / \sqrt{d} = \mathbf{q}^\top(\mu_j + \delta_i)/\sqrt{d} = (\mathbf{q}^\top \mu_j + \mathbf{q}^\top \delta_i)/\sqrt{d}$ 。代入重建式 $\delta_i \approx V_j c_i$ ，得到 $\mathbf{q}^\top \delta_i \approx \mathbf{q}^\top V_j c_i = (V_j^\top \mathbf{q})^\top c_i$ ——也就是说你只需要query 在该页自己的基上的投影，与存储的逐 key 系数做点积。注意这个投影 $V_j^\top \mathbf{q}$ 是一个便宜的 $r$ 维运算（这里 $r=8$ ），每个页每个 query 只算一次；对 $i \in P_j$ 求和（只有 $B=16$ 项）就是 log-sum-exp 归约。这就是整个打分阶段便宜的原因：每页一次 $r$ 维投影加一次长度为 $B$ 的 LSE，可以融合成一个排序 kernel。

重建后的分数归一化成页质量占比，然后合并 GQA 组内的 query。因为 Grouped-Query Attention 让一组 $G$ 个 query head 共享同一份 KV cache，组内每个 query head $g$ 各自算出归一化占比 $\hat{m}_g(j) = e^{\hat{s}_j(q_g)} / \sum_{j'} e^{\hat{s}_{j'}(q_g)}$ ，然后在组内简单平均：

\bar{\hat{m}}_j = \frac{1}{G}\sum_{g \leq G} \hat{m}_g(j) \tag{5}

sink 页和最近写入的页永远占据 $k$ 个名额中的两个（先前工作已知，无论测量到的质量高低，这两类页都格外重要——sink token 吸收注意力”溢出”，最近页则是局部连贯性所必需的），剩下的 $k-2$ 个名额留给按 $\bar{\hat{m}}_j$ 排序的最高分页。组内所有 $G$ 个 head 随后都对同一个共享的页集合做注意力——这在实践上是个不错的性质，因为 GQA 里 KV 存储本身就是按 KV head 共享的，所以计算”每个 head 不同的选择”不会带来额外的内存流量。

设计选择讨论：为什么要跨组做份额平均，而不是取最大值或投票？ 论文证明（推论 3）这条规则在所有共享选择规则（即必须为整个 GQA 组选一套统一页集合的规则）中，最大化组内平均覆盖率。显而易见的替代方案是 group-max（选组内任意一个 head 打高分的页）或 group-mass（其他某种池化方式）。实证上（§5.4 消融），份额平均在每一个测量统计量——平均覆盖率、最差 head 覆盖率、第 5 百分位数——上都保留得更多。有意思的是，论文指出这条规则其实已经作为”TokenSelect 的 head 软投票”存在于先前文献中；这里的贡献是证明它在这个场景下是最优的，并测量它与代价高得多的逐 head oracle 之间的差距（只差约 2 个覆盖率百分点，尽管选择开销少了 $G$ 倍）。

4.3 算法 1：构建（每个写满的页）

算法 1：LOCKS 页摘要构建
输入：页 P_j 及其 key {k_i}_{i in P_j}，目标秩 r，页大小 B
输出：基 V_j，系数 {c_i}，质心 mu_j（量化后）

1:  mu_j <- mean_{i in P_j}(k_i)                      # 页质心
2:  for i in P_j:
3:      delta_i <- k_i - mu_j                         # 每个 key 居中
4:  D_j <- stack({delta_i}) 作为行                     # D_j 属于 R^{B x d}
5:  G_j <- D_j @ D_j.T                                # 小的 B x B Gram 矩阵
6:  (U_j, Sigma_j^2) <- 特征分解(G_j)                  # 按降序排列
7:  U_j_r <- U_j[:, :r]                                # 前 r 个特征向量
8:  Sigma_j_r <- Sigma_j[:r, :r]                        # 前 r 个奇异值
9:  V_j <- D_j.T @ U_j_r @ 逆(Sigma_j_r)               # 正交基, d x r
10: C_j <- U_j_r @ Sigma_j_r                            # 系数, B x r
11: tau_j_r <- sum(Sigma_j[r:]^2)                       # 谱尾（诊断量）
12: V_j_quant <- 量化为int4(V_j)                        # 逐列 scale
13: C_j_quant, mu_j_quant <- 量化为int8(C_j, mu_j)      # 逐行 scale
14: 返回 V_j_quant, C_j_quant, mu_j_quant

4.4 算法 2：打分与选择（每个 decode step，每个 KV head）

算法 2：LOCKS 打分与选择
输入：query 组 {q_g}_{g<=G}，逐页摘要 {(V_j, c_i, mu_j)}，预算 k
输出：选中的页集合 S（整个 G-head GQA 组共享）

1:  S <- {sink页, 最近页}                              # 永久保留名额
2:  for 每个候选页 j（不在 S 中）:
3:      for g in 1..G:
4:          proj_g <- V_j.T @ q_g                       # r 维投影
5:          for i in P_j:
6:              logit_i <- (q_g.T @ mu_j + proj_g.T @ c_i) / sqrt(d)
7:          s_hat_j(q_g) <- logsumexp({logit_i})         # 式 4
8:      for g in 1..G:
9:          m_hat_g(j) <- 按页做softmax(s_hat_j(q_g))     # 每个 head 归一化
10:     m_bar_j <- mean_{g<=G}(m_hat_g(j))              # 式 5，份额平均
11: 按 m_bar_j 对所有候选页降序排序
12: S <- S 并上 {按 m_bar_j 排序的 top (k-2) 页}
13: 仅为 S 中的页取回完整 (K, V)
14: 返回 attention(q_g, K_S, V_S) 用于组内所有 g          # 标准 softmax 注意力

5. 定理 1：留存保证的完整推导

这是把整个理论论证与第 3.1 节的输出误差恒等式串联起来的理论收获。设 $\eta$ 为组内所有页、所有 query 上的最坏对数质量重建误差：

\eta := \max_{g,j} \left| \hat{s}_j(q_g) - s_j(q_g) \right| \tag{6}

第 (i) 部分：从谱尾界定 $\eta$ 。 论文证明

\eta \leq \max_{g,j} \frac{\|(q_g)_\perp\| \sqrt{\tau_{j,r}}}{\sqrt{d}} \tag{7}

其中 $(q_g)_\perp$ 是 query 中位于页 $j$ 保留基之外的分量。直觉： logit 的重建误差由”query 有多少分量指向该页基没有保留的方向”，乘以”该页在自身被丢弃方向上还剩多少‘能量’“（即上面式 2 的谱尾 $\tau_{j,r}$ ）共同决定。如果每个页都有 $r \geq \mathrm{rank}(D_j)$ （即保留的秩足够精确表示该页），则 $\eta = 0$ ——完全没有误差。这是一个干净、令人满意的闭式关系：它直接把质量旋钮（ $r$ ）与你能预期的误差联系起来，中间由每个页 key 谱”尖锐”还是”扁平”来调节。

第 (ii) 部分：从对数质量误差到留存覆盖率。 给定这个逐 query、逐页的打分误差，论文证明由组平均估计占比选出的共享 top- $k$ 集合，至少保留

e^{-4\eta} \tag{8}

比例的、精确质量选择本应达到的组平均覆盖率（含永久保留的页）。这是一个乘性留存保证：如果 $\eta$ 很小， $e^{-4\eta} \approx 1 - 4\eta$ ，你几乎保留了 oracle 的全部覆盖率；如果 $\eta$ 很大，保证会退化但不会变得空洞（它只是随 $\eta \to \infty$ 收缩趋于零，这也正是预期的最坏情况）。

第 (iii) 部分：把覆盖率损失转化为实际输出误差。 结合第 1 式的精确恒等式，论文得到一个完整的端到端界：

\frac{1}{G}\sum_{g \leq G} \left\| \mathbf{o}_S(q_g) - \mathbf{o}(q_g) \right\| \leq 2R\left(1 - e^{-4\eta}\right)\bar{\gamma}^\star \tag{9}

其中 $R$ 是 value 向量范数的上界， $\bar{\gamma}^\star$ 是精确选择的组平均覆盖率。从左到右解读这个界： 组平均注意力输出误差由以下几点共同控制——(a) value 向量能有多大（ $R$ ——模型本身的性质，与 selector 无关）、(b) 精确 oracle 自身在给定预算下能达到多大覆盖率（ $\bar\gamma^\star$ ——任务本身稀疏性的性质，与 selector 无关）、(c) 你的量化摘要留存率与那个 oracle 覆盖率有多接近，完全由 $\eta$ 控制。这正是前面提到的组合式证明：Lipschitz 重建界（重建 logit 与真实 logit 之间的最大距离） $\to$ 组内份额三明治界（误差如何在跨 head 平均时传播） $\to$ 排序鲁棒性界（当分数被扰动不超过 $2\eta$ 时，top- $k$ 选择结果如何变化）。

一个至关重要且难得诚实的说明。 以上全部是对未量化摘要证明的。实际部署的 int4/int8 量化摘要的对数质量误差是测量出来的,而非解析证明——论文报告这个测量误差在中位数处很小,但在匹配的百分位数上大约是未量化误差的两倍，并且在极端值处呈重尾分布。因为定理里的 $\eta$ 是所有页上的最大值，正是这些尾部页会主导这个界——所以如果你天真地把测量到的量化误差代入式 8，得到的将恰恰是被这些尾部页支配的结果。作者也很谨慎地指出，留存常数在”测量到的量级下是定性的”，真正支撑实际质量的证据来自第 5.4 节的实证测量（特别是关键页留存率），而不是机械地把测量到的 $\eta$ 代入式 8。这是很好的科学习惯：区分”被证明的”与”仅仅被测量的”，而不是夸大部署系统实际并不享有的保证。

5.1 一个手算玩具算例

为了让式 4 和式 6-9 更具体，假设有一个极小的页， $B=4$ 个 token，head 维度 $d=4$ ，保留秩 $r=1$ （一个极端的、说明性的压缩配置）。假设居中后的 key 偏差是：

\delta_1 = (1, 0, 0, 0), \ \delta_2 = (0.9, 0.1, 0, 0), \ \delta_3 = (-1, 0, 0, 0), \ \delta_4 = (-0.9, -0.1, 0, 0)

这里主导的奇异方向显然接近 $(1,0,0,0)$ ——四个偏差几乎完全沿第一个坐标轴对齐，只在第二个坐标轴上有很小的分量。一个秩-1 基 $V_j \approx (1,0,0,0)^\top$ 几乎精确捕获了每个 key 在第一坐标轴上的较大分量，只留下第二坐标轴上的小分量（ $\pm 0.1$ ）作为重建误差——这恰好就是谱尾项 $\tau_{j,1}$ ，它会很小，因为被丢弃的第二奇异值本身就很小。现在假设一个 query $\mathbf{q}$ 恰好主要指向第二坐标轴（这个秩-1 基丢弃的方向）。四个 key 的重建 logit 会几乎一模一样（因为保留的基无法在这个轴上区分 $\delta_2$ 和 $\delta_1$ ，或 $\delta_4$ 和 $\delta_3$ ）——即使用完整 4 维 key 计算的真实 logit，实际上是有差异的。这正是式 6 里 $\eta$ 在实践中产生的方式：每当某个 query 在与页保留基正交的方向上分量较大（式 7 里的 $(q_g)_\perp$ 项），且该页在这个方向上的谱尾非平凡时，对这一个特定 query 而言重建分数就会不可靠——即使它对另一个沿主导方向的 query 而言可能完全没问题。这个玩具算例也很紧凑地说明了为什么逐页拟合很重要：单独为这个具体的 4-key 点云拟合的基能便宜地捕获它的主导方向，而一个跨多个、主导方向各不相同的页共享的基,无法同时为所有页都做到这一点——这正是命题 1 的内容。

6. 实验结果详解

评估是围绕论文想端到端验证的这条”推理链”组织的：逐页谱集中性 $\Rightarrow$ token-logit 保真度 $\Rightarrow$ LSE 排序保真度 $\Rightarrow$ 关键页留存 $\Rightarrow$ 极端稀疏下的任务质量 $\Rightarrow$ 实际端到端加速。

图 3（论文原图 Fig.1）：一图说明局部性论点。 面板 (a) 在匹配字节数下画出精确与重建的页质量占比：逐页（ $r=8$ ，int4，768 字节）的点几乎完美贴合对角线，而逐序列基（ShadowKV 风格，780 字节——存储成本相当）则明显偏离对角线，散布很广，这证实这是一个范围效应，而不是存储预算效应。面板 (b) 展示关键页留存率随每 head 预算的变化：LOCKS 在低至 0.5% 预算时依然紧贴精确选择上限，而基于包络的 Quest 与简单的质心基线明显落后，尤其在预算很小时——恰恰是对检索任务最关键的区间。面板 (c) 是”误差阶梯”：在匹配存储字节数下，全局（整 cache 共享）和逐序列基在 logit-MAE、LSE-MAE、排序相关性上都明显比逐页范围差得多，这是对第 3 节理论论证的直接实证确认。面板 (d) 是 RULER-16K 在 256-token 紧预算下各任务族得分的雷达图：LOCKS 在几乎所有能力维度上（单针检索、多键、多值、聚合、状态追踪、开放问答）都几乎完全贴合 FullKV，而对比方法在多个维度上都落在多边形内侧。

图 4（论文原图 Fig.2）：检索与长文档问答 vs. 预算。 在 LongBench-v1、RULER-16K、RULER-32K 上，LOCKS（绿色）在整个预算扫描范围内几乎完全贴合精确 LSE oracle（虚线），而四个有竞争力的基线——Quest、KVzip、ShadowKV、RocketKV——都随预算收缩出现明显下滑,在检索密集的 RULER 上、预算最小时差距最为悬殊。这正是图 3(b) 展示的关键页留存性质在任务质量上的回报：依赖找到少数几个特定 token 的任务,恰恰是”保留平均质量”型 selector 最容易失败的地方，而 LOCKS 对关键页更敏感的保真度,体现为明显更平坦的退化曲线。

基线/前作对比 —— InfiniteBench 在 100K+ 上下文（论文表 1）。

在紧预算下（ $b=512$ ），GLM-4-9B-Chat-1M 上 100K+ token 上下文，LOCKS 得分 41.1（FullKV 为 43.0，精确 LSE oracle 为 42.3）——明显领先于 RocketKV（38.5）、ShadowKV（36.0）和 Quest（34.7）。在更宽松的预算下（ $b=2048$ ），LOCKS 的平均分甚至超过了精确 LSE oracle（43.6 vs 43.9，考虑到报告的置信区间，在噪声范围内），基本与 FullKV 持平。这是一个相当亮眼的结果：一个免训练、基于常驻摘要的 selector,以约 2% 的读取流量，达到了读取整个 cache 的质量水平。

图 5（论文原图 Fig.3）：长程推理 vs. 预算。 这或许是最有意思的质量结果，因为推理轨迹与检索/问答的行为方式不同——模型自己要 decode 出成千上万个 token，所以随着生成推进，它需要关注的”工作集”会不断增长，而不是静态 prompt 的固定比例。结果是出现了一个预算下限：低于某个每 head 预算，所有方法（包括精确 LSE oracle）在 AIME26 和 MATH-500 上的准确率都会崩塌，因为真实的注意力质量本身就需要这么多 token 的预算才能答对——这是任务本身的性质，与任何具体 selector 的保真度无关。区分 LOCKS 与 Quest、R-KV、TriAttention、LazyEviction 的地方在于，一旦预算清了这个下限之后的表现：LOCKS 的曲线几乎完全贴合 oracle，而这些基线在 oracle（以及 LOCKS）已经恢复完整质量之后，仍然持续落后很长一段。

图 6（论文原图 Fig.4）：极端上下文下的 decode 效率。 在 H200 NVL 节点上用真实 vLLM 0.24 测量，在 LOCKS 匹配全 cache 质量的出货预算下：每 token 延迟（TPOT）在 1M-token 上下文时比稠密 FlashAttention-3/FlashInfer 基线低 2.0×（面板 a）；prefill 首 token 时间保持不变，因为选择只影响 decode（面板 b）；每 decode step 读取字节数在 1M-token 上下文时下降 9.8×（面板 c），这正是延迟收益背后的直接机制。论文里的表 2 还进一步显示，加速比会随 batch size 增大而增长——在 256K 上下文下，加速比从 batch size 为 1 时的 1.30× 增长到 batch size 为 4 时的 1.80×（更大的 batch size 稠密基线会 OOM 而 LOCKS 不会）——因为稠密引擎每个请求的 cache 读取量随 batch 线性增长，而 LOCKS 的选择性读取不是这样扩展的。

值得指出的消融实验

论文还仔细消融了自己剩下的两个设计旋钮。秩与量化精度：int8 紧跟未量化（bf16）基；int4 会损失一些召回率，且过了适中的秩之后就不再提升（也就是说，你无法通过给量化误差堆更多秩来弥补——量化本身的下限主导了误差）；int2 无论秩多高都会退化为接近”质心级别”的排序（也就是说，任何秩下的 int2 基都仅比直接用页均值好一点点，这生动说明了逐 key 的精细结构对比特宽度有多敏感）。这正是出货配置选择 $r{=}8$ 、int4 的原因——这是添加更多秩不再有回报的最便宜的点。GQA 合并规则：份额平均在每一个测量统计量（平均、最差 head、第 5 百分位覆盖率）上都优于 group-max 和 group-mass，且只比代价高 $G$ 倍的逐 head oracle 差约 2 个覆盖率百分点。

7. 值得深挖的设计选择

除了上面已经讨论过的两个（份额平均合并规则、r=8/int4 作为出货配置），还有几个设计决策值得逐一给出 why / 替代方案 / 边界的讨论。

为什么固定页大小 $B=16$ ，而不是自适应页大小？ 显而易见的替代方案是让页大小可变——内容同质的地方用更大的页（用低秩就能便宜地概括），内容异质的地方用更小的页（每个 token 需要更多秩才能精确捕获）。论文自己的秩-精度消融（图 5，前文讨论过）恰恰展示了这种张力：在相同的关注 token 预算下，更大的页需要更多秩才能达到同样的保真度，这与更大的页包含更多页内多样性、需要更多秩去捕获是一致的。论文没有探索自适应页大小；这里的边界是,固定 $B=16$ 大概率是为了匹配 vLLM 原生的分页粒度、图省事,这是个合理的默认值，但留下了一个未被探索的方向——一个内容自适应的分页方案，或许能在小预算区间（每一点秩效率都最珍贵的地方）做得明显更好。

为什么用固定的每 head token 预算 $b$ ，而不是固定的上下文比例？ 论文明确主张这是特性而非缺陷：一个固定的绝对预算给服务系统一个与上下文长度无关的内存/计算占用来规划,而固定比例的预算会随上下文长度无界增长，从根本上违背了稀疏注意力系统的初衷。边界条件正是第 6 节讨论过的推理任务预算下限——一个能舒适覆盖短推理轨迹的固定预算,对一道更难问题上更长的轨迹来说，可能根本不够，而 LOCKS 没有任何运行时自适应机制来检测并响应这一点；实践者需要为自己预期中最难的场景保守地设置 $b$ ，代价是在更简单场景下损失一些效率。

为什么用精确 log-sum-exp 质量作为目标，而不是别的代理量？ 论文明确对比的替代方案是二阶矩 / block-moment 家族（COBS、SPLA——同期工作），这类方法对高斯分布的页内容是精确的，但”在承载关键页的高动态范围、尖锐分布页上，最坏情况控制能力最弱”。用大白话说：如果一个页内的注意力 logit 大致呈钟形分布，那匹配这个分布的均值和方差（二阶矩）几乎和匹配完整分布一样好。但关键页从定义上就是异常值——在一个原本平坦的分布里出现的尖锐、非高斯的尖峰——而一个只捕获均值/方差的摘要，恰恰对这种罕见、极端的结构视而不见。LSE 重建（LOCKS 的做法）捕获的是整个 logit 分布的形状（通过逐 key 系数，而不只是两个汇总统计量），这正是它更能应对关键页的原因，代价是每页需要的比特数比纯二阶矩摘要要多。

8. 局限性：作者自述与我的补充

论文对自身局限性相当坦诚，但让我把它们摆出来,并加上我认为被低估的部分。

作者自述的局限：

留存保证（定理 1）是针对未量化摘要证明的；部署的 int4/int8 摘要的实际留存率是实证测量的，而非逐步骤认证的。
摘要成本约为被概括页的十分之一；页大小固定为 $B=16$ 。
由于选择阶段从不读取 key/value，一条完全 offload 的服务路径（只在加速卡上保留摘要，完整 KV offload 到主机内存或磁盘）被明确留作未来工作。
深入刻画估计器行为的逐页测量（附录 B）每个模型只用了”少量记录”，所以它们详细刻画的是估计器本身的行为,而不是在众多任务和模型家族间建立广泛的覆盖率证据。
所有最优性主张都明确是相对于某个类别而言的：质量排序仅在确定性、value-blind的 selector 中是极小化极大最优的；谱基仅在正交秩- $r$ 逐页线性重建中是残差最优的。类别之外的方法（例如把 top-k 与采样统一在统计保证下的 vAttention）被明确承认是互补而非被支配的关系。

9. 批判性分析

这篇论文特有的弱点与缺陷。 首先，头条效率数字（1M 上下文下 TPOT 降低 2.0×，读取字节数降低 9.8×）只在单一硬件目标（H200 NVL）和单一模型（GLM-4-9B-Chat-1M）上测量；不同加速卡（内存带宽与算力比不同）、不同模型（head 维度、GQA 组大小不同）下，这些数字会如何变化尚未确立——逐页特征分解构建步骤的相对成本（大致按 $B^2 d$ 而非上下文长度扩展）与 KV 读取节省之间的权衡，可能会移动 LOCKS 变得划算的临界点。第二，论文报告部署的量化摘要保真度”在极端值处呈重尾分布”，但没有系统刻画哪些页会落入这个重尾——是否可从页内容预测（比如动态范围异常高的 key）？还是本质上不可预测的逐页噪声？如果可以预测，一个自适应的逐页秩或精度方案（把比特精确花在可能落入重尾的页上）看起来是论文没有涉足的”低垂的果实”。第三，检索/问答结果（图 2/表 1）与推理结果（图 3）用的是不同的模型家族（检索用 Llama-3.1-8B / GLM-4-9B-Chat-1M，推理用 Qwen3-4B）——论文没有报告推理模型上的检索任务结果，反之亦然，所以我们无法直接判断推理任务中的”预算下限”现象是任务本身的性质，还是与特定模型的注意力 head 行为存在交互。

作者低估或忽略的局限。 论文在理论范围上很谨慎，但在系统范围上相对不够谨慎：每当一个页在生成过程中（而不只是 prefill 边界）写满时，逐页构建步骤都会引入一个虽小但非零的延迟/计算开销，虽然论文声称这”运行在 decode 关键路径之外”，但没有报告在高吞吐生成或大量并发请求的重度批处理服务场景下，这种增量构建究竟占用了多大比例的 GPU 算力——在同时运行数十条各自以不同节奏写满新页的并发长生成推理轨迹时，这个开销可能比论文的表述更重要。此外，共享的、每个 GQA 组统一一套选中页（份额平均）的设计被呈现为相对逐 head 选择的一个干净胜利，但论文自己的数字显示它”仅”比逐 head oracle 差 2 个覆盖率百分点——平均值可能掩盖了这样一种分布：少数 head（比如先前工作 DuoAttention 识别出的专门化检索 head）因被迫共享针对组内平均调优的选择，而受到不成比例的损害；论文自己的相关工作部分承认 DuoAttention 发现不同 head 有非常不同的检索型/流式型角色，但没有把这两个想法交叉验证一下，看看 LOCKS 的组内共享选择是否特别地服务不好 GQA 组内的”检索 head”少数群体。

具体、可操作的改进建议。 (1) 对页做逐页、逐量化尾部的刻画：按测量到的重建误差把页分桶，检查误差是否与可测量的页属性相关（key 范数的动态范围、第 $r$ 与第 $(r{+}1)$ 奇异值之间的谱间隙）——如果相关，就可以推出一个自适应秩的变体，只把额外比特花在高尾部风险的页上，很可能在相同平均字节预算下弥补部分质量差距。(2) 在真实的多序列批处理服务负载下（而不仅是孤立的单步 TPOT），报告逐页增量构建开销占总 decode-step 算力的比例，因为这个数字才真正决定 LOCKS “关键路径外”的表述在持续长生成流量的生产负载下是否站得住脚。(3) 直接用 DuoAttention 的检索 head/流式 head 区分来交叉验证份额平均设计：专门针对独立识别出的”检索型” head，测量组内共享选择带来的逐 head 覆盖率损失，检查平均 2 个百分点的差距是否掩盖了一个集中在这篇论文最关心的（检索、大海捞针）任务最重要的极少数 head 上、大得多的差距。(4) 把推理任务评估（Qwen3-4B）扩展到至少一个检索任务模型（Llama-3.1-8B、GLM-4-9B-Chat-1M）上，以厘清推理任务的”预算下限”现象究竟是任务本身固有的，还是依赖模型家族。(5) 明确消融固定 vs. 自适应页大小，因为论文自己的秩-页大小消融已经显示出这种张力（更大的页按比例需要更多秩），暗示内容自适应的分页大小是一个当前尚未被探索、但可以直接改进秩效率前沿的自然扩展方向。

10. 可复现性说明

论文声明证明在附录 A、完整评估协议与预算核算在附录 C 有文档记录，代码、kernel、容器栈和测量工具都已发布（附录 F）——对一篇系统论文来说，这是相当扎实的可复现性姿态，超越了只发布模型 checkpoint 或脚本的做法，直接发布了用于生成报告数字的实际测量工具。实践层面，如果你想复现或在此基础上继续做工作：(a) 出货配置是秩 $r=8$ ，页大小 $B=16$ ，int4 基 / int8 系数——从这里开始，而不是从头重新推导超参数；(b) 论文所用的 vLLM 版本是 0.24，作为一个 pip 可安装的通用插件，无需 fork 或打补丁,如果你的服务栈已经在兼容的 vLLM 版本上，集成摩擦应该相对较低；(c) InfiniteBench、LongBench-v1、RULER 的所有结果都在同一个引擎、同一个 FullKV 参照下，跨所有对比方法使用相同的记录——这正是稀疏注意力公平对比所需要的方法论纪律,值得在你自己跑对比实验时确认保留这个原则（“你的方法”和”基线”数字之间不匹配的记录或引擎，是这个领域一个经典且容易被忽略的不公平对比来源）。

11. LOCKS 在 KV cache 效率工作版图中的位置

值得把 LOCKS 放到更宽的 KV cache 效率技术版图里看一看，因为这个领域已经真正分化成几个基本正交的轴向，很容易把解决不同问题的方法混为一谈。

驱逐类（H2O、StreamingLLM sink+window、R-KV） 永久丢弃 token 以节省内存。LOCKS 保留一切，只跳过读取。这两者是互补的——你可以想象在一个已经通过驱逐缩小过的 cache 上再跑 LOCKS 式的选择性读取，同时攻克容量和带宽这两个瓶颈，尽管论文没有评估这种组合。
量化（GPTQ 风格、KVQuant 等） 为每个 token 减少每条目比特数，与”哪些 token 被关注”正交。LOCKS 自己的摘要内部已经用了量化（int4/int8），但这与cache 本身的量化是不同的关切点，后者会进一步缩小常驻的全精度 KV 本身。
query-aware 选择（Quest、ShadowKV、Loki、RocketKV） 是直接的对比类别，本文的核心贡献是对为什么这些方法会在质量上留下遗憾给出一个具体的、可证伪的解释：表征范围。如果你读过这些前作中的任何一篇，可以把 LOCKS 理解为”同样的整体配方，但坚持摘要必须逐页拟合而不是逐序列或整 cache 拟合，并且这个选择不仅仅是经验上的小调整，而是结构上必要的，有证明支撑”。
训练稀疏性 / 蒸馏门控（SeerAttention） 通过额外训练把选择机制烘焙进模型。LOCKS 的免训练特性是一个真实的实践优势——如果你无法为每个想加速的模型都负担得起微调或蒸馏一个门控网络，代价是无法像训练出来的门控那样学习到任务特定的选择模式。

12. 实践要点

如果你在构建或评估一个长上下文服务栈，无论是否采用 LOCKS 本身，这篇论文有三点值得带走。第一，评估任何稀疏注意力 selector 时,要测量关键页留存率，而不只是整体捕获质量——这两个指标可以剧烈背离，只看整体质量会系统性高估检索密集型负载的质量。第二，如果你在为任何 KV cache 用途（选择、驱逐打分或其他）构建紧凑的逐 token 或逐页摘要，范围比大小更重要——一个小的、逐页拟合的表征可以胜过一个大得多的共享表征，命题 1 给了你一个具体的理由去预期这一点，而不只是把它当作经验上的巧合。第三，为生产环境选择稀疏 decode 预算时，记住推理评估里的预算下限现象：低于某个任务相关的最小预算，没有免费的午餐，无论 selector 多好，都无法恢复精确 oracle 本身在那个预算下都无法达到的质量；实践上的教训是,按你预期中最难的推理负载而不是平均负载来设置预算。

13. 一个用于落地判断的决策框架

如果你在判断自己的长上下文服务栈是否值得引入 LOCKS 这类逐页谱摘要，与其整体照搬，不如走一遍简短的自查清单。

你的瓶颈是读取带宽,还是容量本身？ 如果你的 KV cache 完全能塞进显存，但 decode 吞吐受限于每步要读多少字节（大 batch、长上下文、带宽受限的加速卡），LOCKS 这种读取侧优化可以直接适用。如果瓶颈是 cache 根本装不下，你需要先做驱逐或 offload（也可以和 LOCKS 组合），因为 LOCKS 本身不缩小常驻内存占用。
你的负载对关键 token 有多敏感？ 检索类任务（大海捞针、密码检索、结构化的多键/多值查找）恰恰是关键页留存性质最重要的地方，也是更便宜的平均质量型 selector（Quest 式包络）最容易悄悄失败的地方。如果你的负载更接近平滑的长文档摘要，没有哪个单一 token 是决定性的，一个更粗糙、更便宜的 selector 可能是可以接受的取舍。
你能接受固定的绝对预算吗？ LOCKS 采用与上下文长度无关的固定每-head token 预算，这是一个刻意的设计选择，也有真实的边界：带有任务预算下限的推理负载（第 6 节、图 5）需要提前识别并按最难场景配置这个下限；这里没有在线自适应机制。
你的服务栈是否已经在兼容的 vLLM 版本上？ 如果是，实际集成成本接近于零（pip 可安装插件，无需 fork），这会显著改变相对于需要打补丁或 fork 服务引擎的方法的成本收益核算。
你需要一个被证明的最坏情况界，还是测量到的经验保真度就够了？ 定理 1 的保证适用于未量化摘要；实际部署的 int4/int8 版本是通过实证验证的，而非逐 step 认证的。对有硬性正确性要求的负载（而不是”大部分时候大致正确”这种质量目标），这个区别值得认真对待，而不是想当然地认为定理无条件覆盖了实际部署的系统。

在采用任何稀疏 decode 方法（不只是 LOCKS）之前先走一遍这份清单是个好习惯，因为 KV cache 效率这个领域横跨了好几个真正不同的问题场景（容量 vs 带宽、平均情况 vs 关键 token 敏感、静态 vs 增长中的工作集），单一的 benchmark 数字很少能完整覆盖这些差异。

对中文读者的延伸思考

国内在长上下文推理服务这块的工程实践里，KV cache 相关的优化往往被简单地归为”量化”或”驱逐”两大类，容易忽略 LOCKS 这里强调的第三个维度——同样的存储预算，摘要拟合的范围本身就是一个独立的自由度，而且往往比调大调小压缩率更能决定下限质量。如果团队里已经在用类似 Quest、H2O 这类稀疏 decode 方案，值得直接照搬这篇论文第 3 节的诊断方法：把”整体捕获质量”和”关键页/关键 token 留存率”分开测，而不是只看一个综合分数——很多国内评测报告里常见的”平均分不错”结论，如果不拆开看关键样本的留存情况，很可能掩盖了大海捞针类任务上的真实风险。

与近期已发表长上下文/KV cache 系统工作的定位对比

把 LOCKS 放到我们之前读过的几篇同类工作旁边看会更清楚。KV-Fold（本站 2026-07-26 笔记）解决的是一个不同的子问题——如何把跨层的 KV 表示递归地压缩，本质是纵向（跨 layer）压缩；LOCKS 是横向（同一层内跨 page）的选择问题，两者理论上可以叠加使用。VeriCache 关注的是有损 KV cache 的正确性验证问题，与 LOCKS 的选择性读取是完全正交的关切——你可以在一个用 VeriCache 验证过的有损 cache 上，继续用 LOCKS 做进一步的读取侧优化。而 MosaicKV 的两维动态压缩思路，与本文强调的”范围优先于大小”是互补而非竞争关系：MosaicKV 关心的是沿哪两个维度（层、头）分配压缩预算，LOCKS 关心的是压缩表示本身应该在多大的内容范围内拟合，两条轴其实可以同时优化。

团队实践建议

对不同规模的团队而言，落地这类方法的优先级应该不同。小团队/单模型部署场景：如果你的服务已经在用未修改的 vLLM，且长上下文请求占比不高，直接引入训练自由的 LOCKS 插件的边际成本很低，值得优先尝试而不是自己重新造一套选择性 KV 读取方案。中大型团队：如果你已经有自研的 KV cache 系统（比如已经做过驱逐或量化），更有价值的做法不是照搬 LOCKS 的具体实现，而是照搬它的诊断方法——用第 3 节的”关键页留存率 vs 整体捕获质量”这套双指标体系，去审视自己现有系统在检索密集型任务上是否存在类似的隐藏质量缺口。对做基础研究的团队，命题 1 这类不可能性证明的思路（固定共享投影必然对某个子空间视而不见）本身是一个可迁移的分析工具，值得在评估任何自己团队负责的系统时留一个”我的共享表示有没有天生看不见的方向”的问题清单。

14. 常见误读澄清

读完这篇论文，几个容易产生的误解值得单独澄清一下。

误读一：LOCKS 是一种驱逐（eviction）方法。 不是。LOCKS 从不丢弃任何 token——完整 KV cache 永远留在显存里。它改变的是每个 decode step 读取哪些内容,而不是存储哪些内容。如果你的目标是缩小显存占用（容量问题），LOCKS 帮不上忙，你需要驱逐或 offload 类方法。

误读二：秩为 8 意味着每个 page 只保留 8 个 token 的信息。 不对，秩 $r=8$ 指的是每个 page 内 key 向量点云的子空间维度，而不是 token 数量。一个 16-token 的 page 用秩 8 的基，仍然为全部 16 个 token 各自保留了独立的系数 $c_i$ ，只是这些系数都活在同一个 8 维子空间里——重建时依然能区分这 16 个 token 彼此的差异（只是差异的表达能力被限制在 8 个自由度内）。

误读三：命题 1 证明了所有共享投影方法都不能用。 这个说法过强了。命题 1 证明的是”存在一族被完全忽略的内容变化”，但这不等于说共享投影方法在所有实际场景下都会失败——如果实际数据的变化恰好很少落在那些盲方向里，共享投影仍然可能表现不错。命题 1 给出的是一个结构性的最坏情况保证缺失，而不是一个”共享投影总是很差”的经验论断；论文自己的实证部分（而不是命题 1）才是共享投影在真实数据上确实表现更差的证据来源。

误读四：LOCKS 只对检索类任务有用。 从图 4（论文 Fig.2）和图 6（论文 Fig.4）看，LOCKS 在长文档问答、极端上下文效率上同样有明显收益，并不局限于大海捞针式的检索任务。检索任务只是凸显了 LOCKS 与平均质量型 selector 差距最大的场景，不代表这是它唯一擅长的场景。

15. 决策对照表

下表把第 13 节的决策框架浓缩成一个更快速的对照参考。

判断维度	更适合引入 LOCKS 类方法	更适合先做别的事
瓶颈类型	decode 阶段读带宽是主要瓶颈	KV cache 根本装不下显存（容量问题）
任务特征	检索/多键值/需要找到少数关键 token	平滑长文摘要，无单一决定性 token
预算灵活性	可以为最难场景预先设置固定预算	需要运行时动态调整预算的场景
工程环境	已在未修改 vLLM 上，希望零侵入部署	服务栈高度定制化，难以接入外部插件
正确性要求	可接受”经验验证的高保真度”	需要逐 step 可证明的确定性保证

16. 写这篇笔记前该想清楚的三个问题

在决定要不要把 LOCKS 这类工作纳入自己的技术雷达之前，值得先问自己三个问题：第一，我现在的瓶颈到底是内存容量还是读带宽？如果连这个都没分清楚，任何”KV cache 优化”的讨论都容易变成鸡同鸭讲。第二，我的评测体系有没有区分”平均质量”和”关键样本留存率”？如果没有，即使不引入 LOCKS，仅仅补上这个评测维度本身就可能暴露现有系统的隐藏缺口。第三，我愿意为多大的确定性换取多少效率？LOCKS 的核心权衡就在这里——它给你的是被测量验证过的高保真度，而不是逐 step 可证明的正确性,这个权衡是否符合你的场景，值得在引入之前想清楚。

17. 术语速查表

术语	含义
Page（页）	KV cache 中固定大小（本文 $B=16$ token）的存储单元，是 LOCKS 做选择决策的粒度
谱摘要（spectral summary）	每个页自己的低秩特征分解结果：正交基 $V_j$ + 逐 key 系数 $c_i$ + 质心 $\mu_j$
谱尾（spectral tail） $\tau_{j,r}$	保留秩 $r$ 之外、被丢弃的奇异值平方和，衡量重建误差的来源
关键页/关键 token（carrier）	承载任务决定性信息、丢失后会造成灾难性输出误差的稀有页或 token
LSE（log-sum-exp）	一组未归一化 logit 的平滑归约量，用作注意力质量的代理目标
份额平均（share-average）	GQA 组内多个 query head 各自归一化占比后取平均，作为共享选择依据的合并规则
$\eta$	组内所有页、所有 query 上的最坏对数质量重建误差，定理 1 的核心变量

18. 小规模验证实验思路

如果团队想在采用 LOCKS 之前先做一次低成本的内部验证，不需要完整复现论文全部实验，一个最小可行的验证思路是：选一个已经在用的长上下文模型和一个小型大海捞针测试集（几十条记录即可），分别用 FullKV、一个简单的质心/包络型 selector、以及本文的逐页谱重建打分，在同一个预算下比较两个指标——总体准确率，以及”针”所在页是否被选中的比例（关键页留存率）。如果后者在质心/包络方法上明显低于前者能反映的水平，就已经足以说明第 3 节的诊断方法在自己的场景下同样成立，值得进一步投入完整评估。这个最小实验的价值在于低成本地验证”表征范围优先于大小”这个核心论点是否在自己的模型和数据分布上依然成立，而不需要一开始就投入完整的 LongBench/RULER/InfiniteBench 级别评测。

19. 部署检查清单

在真正把 LOCKS 这类插件接入生产服务之前，一份简短的部署前检查清单可以避免一些常见的踩坑：

确认 vLLM 版本与插件兼容，且插件安装方式为 pip 安装、不需要对引擎打补丁——如果发现需要 fork 或修改引擎源码，说明可能装错了版本或路径配置有误。
在小流量灰度环境下，先用与生产一致的模型和典型请求分布跑一遍关键页留存率诊断（参考第 18 节的最小验证实验），而不是直接全量上线。
确认服务的 batch size 和上下文长度分布与论文测量的场景（H200 NVL、GLM-4-9B-Chat-1M 等）有多大差异，效率收益（2.0×、9.8× 这类数字）在自己的硬件和模型上很可能不同，不要直接照搬论文数字做容量规划。
检查自己的推理类工作负载是否存在类似论文图 5 展示的”预算下限”现象——如果有更长、更难的推理任务，需要按最难场景而不是平均场景设置预算，并在上线前专门测试这类边界情况。
如果服务同时运行多个不同模型家族（不同 GQA 分组大小、不同 head 维度），分别验证每个模型家族下的收益和质量表现，不要假设一个模型上验证过的结论可以直接套用到另一个模型上。

结论

LOCKS 提出了一个范围很窄但论证充分的主张：为 decode 阶段稀疏注意力构建一个紧凑的常驻摘要时，拟合低秩表征的范围——逐页而非逐序列或整 cache——才是决定摘要能否保留良好选择所需保真度的关键，而这是可以被证明的，不只是一个经验上的调参选择。论文用一个干净的不可能性定理（命题 1）、一个把重建误差一路串联到注意力输出误差的组合式留存保证（定理 1），以及一整套真正全面、能逐环定位竞争方法具体在哪里失效的实证评估，支撑了这个主张。其结果——一个免训练的 vLLM 插件，以约 2% 的读取流量达到接近 oracle 的质量，在极端上下文下测得 2.0-9.8× 的 decode 时间收益——是一个扎实的实践成果，但对整个领域而言更持久的贡献，是”表征范围而非大小”这个视角本身，它很可能会影响下一代 KV cache 摘要的设计方式，无论这些设计是否使用完全相同的特征分解构造。