KV-Fold：把 KV 缓存当作长上下文推理的左折叠累加器

笔记日期： 2026-07-26 笔记作者： Zhongzhu Zhou 所读论文： KV-Fold: One-Step KV-Cache Recurrence for Long-Context Inference 论文作者： Alireza Nadali, Patrick Cooper, Ashutosh Trivedi, Alvaro Velasquez（科罗拉多大学博尔德分校） arXiv： 2605.12471v1，2026-05-12 收录状态： arXiv preprint（cs.LG）

0. 为什么值得认真读这篇论文

每隔几个月就会冒出一篇号称”无限上下文”的长上下文新方法，配方几乎总是同一套：压缩、淘汰，或者近似。滑窗注意力直接丢掉旧 token；KV cache 量化牺牲精度；学习式记忆 token 需要微调；状态空间模型干脆换掉注意力机制。这些都是合理的工程权衡，但它们共享一个盲点：都没有问过一个更基础的问题——一个完全没有被改动过、冻结的 transformer，会不会本来就有足够的机制去处理长上下文，只是需要换一种”跑法”？

KV-Fold 用一个近乎朴素到有点尴尬的想法回答了这个问题，还借用了函数式编程里的一个名字：把 KV 缓存当成一次左折叠（left fold，Haskell 里的 foldl）的累加器，作用在一串 chunk 上。没有新参数，不需要重新训练，没有特殊 token——只是换了一种”KV 缓存如何从一个 chunk 传到下一个 chunk”的记账方式。真正让这篇论文值得细读（而不是随手归到”又一个分块注意力技巧”里）的，是随之而来的实证结论：这样诱导出来的递归是稳定的。跟朴素迭代近似应有的预期（误差随链条深度单调累积）不同，KV-Fold 相对完整注意力的偏差会先短暂上升，然后趋于一个平台期——这个平台期在数值精度提升 10,000 倍、chunk size 扫过 8 倍范围、换三种不同模型家族的情况下都纹丝不动。这个”稳定性”的成色到底有多少、能信到什么程度，就是这篇技术评述要拆开来看的核心内容。

1. 前置知识

1.1 KV 缓存是什么

在一个 decoder-only transformer 里，每一层注意力都从当前隐状态计算 query、key、value：$Q = XW_Q$，$K = XW_K$，$V = XW_V$。自回归生成过程中，推理引擎不会每一步都重新计算所有历史 token 的 $K$ 和 $V$，而是把它们缓存下来。第 $\ell$ 层在处理完 token $0, \dots, s-1$ 之后的 KV 缓存，就是堆叠好的张量 $K^{(\ell)}_{0:s}, V^{(\ell)}_{0:s} \in \mathbb{R}^{s \times d}$（$d$ 是 head 维度）。当新 token $x_s$ 到来时，它的 query $q_s$ 会同时关注缓存里的 keys/values 以及自己新算出的 $k_s, v_s$，然后缓存增长一行。这是所有推理引擎（vLLM、TensorRT-LLM、SGLang 等）的标准机制,也正是这篇论文重新利用的对象。

有一点必须牢牢记住：KV 缓存不是压缩摘要。它存的是精确的逐 token key/value。如果你去关注 50,000 个 token 之前的一条缓存条目，你关注到的是那个 token 在那一层的精确线性投影——不是衰减、淘汰或量化后的替代品（数值精度效应除外，论文对此做了专门测试）。

1.2 为什么长上下文本身就难

单次前向传播中，对 $T$ 个 token 做注意力计算，代价是 $O(T^2)$（计算量和内存都是）。以 $T = 128\text{K}$、$H=32$ 个 head、bf16 精度为例，光是 score 矩阵 $QK^\top$ 就要：

$$\text{字节数} = H \times T \times T \times 2 = 32 \times 128000 \times 128000 \times 2 \approx 1.05 \times 10^{12} \text{ 字节} \approx 1\text{ TB} \tag{1}$$

——单张 40GB GPU 上完全放不下。这就是为什么长上下文推理是一个系统问题而不只是建模问题：即便模型训练时用了足够长的位置范围，一次真正”一口气”跑完整个序列的前向传播,内存上也可能根本装不下。

1.3 现有的三条路子，及它们共同的弱点

三大类方法在设法绕开这个 $O(T^2)$ 的墙：

1. 流式/滑窗方法（如 StreamingLLM、LM-Infinite）：只保留少量固定的”attention sink”token 加上一个有界的最近 token 滑窗。内存对序列长度是 $O(1)$。代价是：一旦某个信息滑出窗口，就彻底没了，不可恢复。如果一个 needle-in-a-haystack 事实滚出窗口，那就是硬失败。
2. KV 缓存压缩（淘汰、剪枝、量化）：保留完整缓存的一个子集或有损编码。内存增长是次线性或有界的，但召回是概率性的——一个不知道某些 token 很重要的启发式规则可能把它们直接淘汰掉。
3. 架构层面的替代方案（循环记忆 token、学习式压缩、Mamba 这类状态空间模型、修改位置编码）：改变模型实际计算的内容,通常需要训练或微调,并且改变了注意力计算本身（因此你就失去了”行为等同于原始训练模型”的保证）。

每一类方法都有合理的适用场景。但请注意它们共享的假设：必须以某种方式压缩过去才能给现在腾出空间。KV-Fold 的前提是:如果你有内存预算容纳一个线性增长的缓存,你其实不需要压缩任何东西——你可以在每一步都关注全部累积历史,唯一的问题是”逐 chunk 地做这件事”跟”一次性做一个巨大的前向传播”相比,行为会不会不一样。

1.4 什么是 needle-in-a-haystack

这已经是长上下文能力的标准压力测试:在一段很长的文档中间某个受控位置插入一个合成事实（比如”The magic number for obsidian is 47213.”),然后在文档末尾问模型能不能检索出来。这是测试精确召回而不是聚合困惑度的一种干净方式,因为困惑度是对很多预测求平均得到的边际量,可能掩盖单次灾难性遗忘事件。

1.5 为什么“左折叠”这个比喻选得很准

在继续往下读之前,值得说一下这个比喻本身为什么选得很准。在函数式编程里,foldl(f, init, [x1, x2, ..., xn]) 的语义是:用 init 和 x1 调用 f 得到一个累加値,再用这个累加值和 x2 调用 f,依次类推,直到处理完所有元素。关键特征有两点:(1) 同一个函数 f 在每一步都被重复调用,不变;(2) 上一步的输出完全决定了下一步的输入之一,中间没有任何共享可变状态。这两点在 KV-Fold 里完全对应:同一个 transformer 前向函数 $\mathcal{F}_\theta$(参数固定)在每个 chunk 都被重复调用,上一次调用产生的 KV 缓存完全决定了下一次调用的前缀输入。

这个比喻也帮助我们理解为什么这种方法不需要任何额外的“记忆模块”或“状态压缩器”:累加器本身(KV 缓存)就是 transformer 自己已经在维护的东西,不需要额外定义一个新的状态表示。相比之下,真正的循环神经网络(RNN)或状态空间模型(如 Mamba)需要学习一个固定维度的状态向量,并训练一个专门的更新函数;KV-Fold 则直接御用了 attention 机制本身对变长序列的处理能力,把“状态”定义为一个不断增长的集合,而不是一个固定维度的向量。这也是为什么论文强调“信息不被压缩成固定维度”——这是 KV-Fold 与线性注意力(Linear Attention)、状态空间模型等“固定大小状态”方案最本质的区别。

2. 架构总览

flowchart LR
    subgraph Chunk_tminus1["Chunk t-1 前向"]
        A["位置 (t-1)C..tC 的 token"] --> B["注意力层 l"]
        B --> C["K_(t-1), V_(t-1)"]
    end
    subgraph Chunk_t["Chunk t 前向"]
        D["位置 tC..(t+1)C 的 token"] --> E["注意力层 l"]
        E --> F["K_t, V_t（追加进缓存）"]
    end
    C -->|"前缀：无需复制、无需变换"| E
    F -.->|"传给 chunk t+1"| G["..."]

图1（论文图2）：核心机制——chunk $t$ 的注意力层把 chunk $t-1$ 的 key/value 当作一个未经改动的前缀来处理，自身的输出再被追加到缓存中传给 chunk $t+1$。这个操作在每一层 $\ell = 0, \dots, L-1$ 都完全一致,位置 ID 在 chunk 边界上是连续的（不会重置）。

上面这张图看起来简单得有点反直觉,但这正是重点所在。这里没有门控、没有压缩模块、没有可学习的路由——整个”机制”就是:chunk 之间不要丢掉 KV 缓存,也不要重置位置。除此之外的一切都是标准的 transformer 推理流程。

3. 整个序列的数据流

flowchart TD
    X0["chunk x_0 (token 0..C)"] --> P0["前向传播 F_theta"]
    P0 --> KV0["(K^0, V^0)"]
    KV0 --> P1["以 x_1 为输入的前向传播，以 (K^0,V^0) 为前缀"]
    X1["chunk x_1 (token C..2C)"] --> P1
    P1 --> KV1["(K^1, V^1)  [已累积]"]
    KV1 --> P2["以 x_2 为输入的前向传播，以 (K^1,V^1) 为前缀"]
    X2["chunk x_2"] --> P2
    P2 --> KVdots["...一直累积到 chunk N-1"]

图2（自绘）：整个序列被处理为 foldl(F_theta, (∅,∅), [x_0, x_1, ..., x_{N-1}])——每一步的输出缓存变成下一步的输入前缀,与函数式左折叠完全对应。

4. 把递归形式化

4.1 递归方程

设 $(\mathcal{K}^{(t)}, \mathcal{V}^{(t)})$ 为处理完 chunk $t$ 之后累积的 KV 缓存（跨所有层,论文里按层写作带 $\ell$ 上标）。那么：

$$(\mathcal{K}^{(t)}, \mathcal{V}^{(t)}) = \mathcal{F}_\theta\left((\mathcal{K}^{(t-1)}, \mathcal{V}^{(t-1)}), \mathbf{x}_t\right) \tag{2}$$

其中 $\mathcal{F}_\theta$ 就是参数固定为 $\theta$ 的普通 transformer 前向函数,以之前的缓存为前缀作用在当前 chunk $\mathbf{x}_t$ 上。把整条序列展开,恰好得到一个左折叠：

$$(\mathcal{K}^{(N-1)}, \mathcal{V}^{(N-1)}) = \texttt{foldl}\big(\mathcal{F}_\theta,\ (\emptyset, \emptyset),\ [\mathbf{x}_0, \mathbf{x}_1, \dots, \mathbf{x}_{N-1}]\big) \tag{3}$$

推导与直觉。 拿这个跟单次完整注意力前向传播对比。在完整注意力里,chunk $t$ 里的 token $i$ 会一次性、联合地关注所有之前的 token $0, \dots, i-1$。而在 KV-Fold 里,chunk $t$ 里的 token $i$ 关注的是 chunk $0, \dots, t-1$ 累积下来的缓存（在更早、独立的前向传播中算出）加上自己 chunk 内部的 token（联合计算,跟平常一样）。这两者在数学上完全等价,当且仅当满足两个条件：（a）位置 ID 在 chunk 边界上是连续的——即 chunk $t$ 里的 token $i$ 仍然认为自己在绝对位置 $tC + i$,而不是 $i$——这样 RoPE 旋转才能与完整前向传播里的完全对齐；（b）单独计算 chunk $t-1$ 的 $K, V$ 的数值结果,与它们在一次联合前向传播里被计算出来的结果完全一致。条件（a）通过构造直接满足（论文对此非常明确）。条件（b）才是有趣的实证行为的来源——而且它不是平凡成立的,因为注意力涉及对目前为止看到的完整一行 key 做 softmax 归一化,“孤立地计算 chunk $t-1$ 的 key,就好像它是唯一的 chunk”这件事,并不字面等同于”作为更长运行上下文的一部分来计算它们”——除非按照 KV-Fold 的构造,key 和 value 本身根本不依赖于更晚的 token（因果掩码已经保证 $K_i, V_i$ 只依赖于 $\le i$ 的 token）,因此分块状态下算出的 $K^{(\ell)}_s$ 在逐层意义上,与单次联合前向传播产生的结果是位级相同的——只要该层的注意力以相同的前缀为条件。真正微妙之处（论文选择用实证而不是逐层解析证明来处理）是：把 chunk 作为独立 kernel 调用来处理时引入的微小浮点差异（不同的批处理方式、矩阵乘法里不同的累加顺序),是否会随深度复合累积。

4.2 三种参照条件

为了精确测量这一点,论文为每个 chunk 定义了三种条件：

• FULL：在整个 $T$-token 序列上做单次完整注意力前向传播时的下一 token NLL——参照上限。
• ISOLATED：每个 chunk 完全不带任何前缀处理时的 NLL（每个 chunk 完全看不到之前 chunk 的上下文）——下限,代表如果只是独立跑各个 chunk、完全没有递归会得到什么结果。
• KV-FOLD：在上述累积缓存递归下的 NLL。

以及两个核心指标：

$$\text{drift}(d) = \text{NLL}_{\text{KV-FOLD}}(d) - \text{NLL}_{\text{FULL}}(d) \tag{4}$$ $$\text{advantage}(d) = \text{NLL}_{\text{ISOLATED}}(d) - \text{NLL}_{\text{KV-FOLD}}(d) \tag{5}$$

其中 $d$ 是链条深度（chunk 索引减一,即已经发生了多少次 chunk 到 chunk 的转移）。drift 衡量”我们离理想上限有多远”,advantage 衡量”我们比什么都不做（孤立 chunk）好多少”。一个既低 drift 又高 advantage 的方法,才是在做真正有用的工作,而不是退化到两个极端之一。

5. 算法：KV-Fold 的伪代码

算法 1 —— KV-Fold 分块前向传播

输入：token 序列 x[0..T-1]，chunk 大小 C，L 层模型 F_theta
输出：所有层的最终 KV 缓存 (K, V)，以及逐 chunk 的 logits

1.  N ← ceil(T / C)
2.  K[l] ← 每层 l = 0..L-1 的空列表    # 缓存初始化
3.  V[l] ← 每层 l = 0..L-1 的空列表
4.  for t = 0 to N-1:
5.      x_t ← x[t*C : min((t+1)*C, T)]           # 取第 t 个 chunk
6.      # 位置 ID 从绝对偏移 t*C 开始连续计数 —— 而不是重置为 0
7.      logits_t, (k_t[0..L-1], v_t[0..L-1]) ← F_theta.forward(
8.                x_t,
9.                past_key_values = (K, V),        # 前缀，不做任何改动
10.               position_offset = t * C)
11.     for l = 0 to L-1:
12.         K[l].append(k_t[l])                   # 缓存增长，不做淘汰
13.         V[l].append(v_t[l])
14.     yield logits_t
15. return (K, V)

这个算法故意写得不花哨——它就是 Hugging Face 风格 API 里 model.generate(..., past_key_values=past_kv) 已经在做的事情,只是把它反复调用在若干个连续 chunk 上,而不是一次性作用在整个序列上。真正的”新意”完全在于这篇论文证明了反复这样做是安全的,并且系统性地刻画了它什么时候安全、什么时候不安全。

算法 2 —— Needle-in-a-haystack 检索协议（论文的评估流程）

输入：由 N 个 chunk 组成的 T-token 文档 D，一个 (key, value) needle 对，
      目标链条深度 d（查询发生在第几个 chunk）
输出：检索是否成功（布尔值）

1.  在第 N-1-d 个 chunk 的位置插入句子 "The magic number for [key] is [value]."
2.  对全部 N 个 chunk 运行算法 1，保留最终的 (K, V)
3.  构造查询语句："Earlier in the document, what was the magic number
    associated with [key]? Reply with only the number."
4.  logits, _ ← F_theta.forward(query, past_key_values=(K,V), position_offset=T)
5.  answer ← greedy_decode(logits, max_new_tokens=30)
6.  extracted ← 从 answer 中提取第一个 5 位数字
7.  return extracted == value

5.5 一个容易忽略的实现细节:不同层的缓存是独立增长的

算法 1 的伪代码里有一个细节容易被一扫而过:第 11-13 行的循环对每一层 $\ell$ 都独立地把 $k_t[\ell], v_t[\ell]$ 追加到对应层的缓存里。这意味着整个系统实际上维护着 $L$ 个独立的累加器,而不是一个单一的全局累加器。这对内存布局有直接影响:工程实现时,每一层的 KV 缓存通常会分开存储(比如 vLLM 的 PagedAttention 按 block 管理每层每 head 的 KV),因此 KV-Fold 的“追加”操作在实现上对应的是 $L$ 次独立的内存写入,而不是一次。这个细节不影响论文的正确性论证,但对于想把这套方案接到现有推理引擎上的工程师来说很重要:你需要确保每一层的缓存都能独立地被正确地追加和寻址,而不是只处理了第一层就以为完事。

6. 设计选择：为什么位置 ID 要连续（以及它会在哪失效）

这个选择是什么。 chunk $t$ 的位置 ID 从 $tC$ 开始，而不是从 $0$ 开始——也就是说，模型永远不会被告知”一个新序列开始了”；RoPE 旋转的应用方式与在一次巨大前向传播里完全一致。

为什么这样有效。 RoPE 通过 query 和 key 之间的旋转角度差来编码相对位置。如果 chunk $t-1$ 的 key 被旋转得就像它们处在位置 $[(t-1)C, tC)$，而 chunk $t$ 的 query 被旋转得就像处在位置 $[tC, (t+1)C)$，那么任意一对 query-key 之间的相对角度,与它们在单次完整前向传播中的相对角度完全一致——这正是让缓存可以直接复用、不需要任何变换（架构图里说的”no copy, no transformation”）的全部窍门。

显而易见的替代方案。 在每个 chunk 边界把位置重置为 $0$（把每个 chunk 当作一个新的小序列,恰好能看到一些额外的 key）。这在某些推理框架里实现起来更简单,但它破坏了 RoPE 的相对位置语义：chunk $t-1$ 里”位置 0”的 key,被 chunk $t$ 里”局部位置 5”的 query 关注时,编码出的相对距离是 5,而原始序列里的真实距离是 $C + 5$。这会破坏所有涉及跨 chunk 配对的注意力分数。

连续位置会在哪失效。 这套方案只有在模型训练时的位置范围之内才是精确的。一旦 $tC$ 超过模型训练/外推支持的最大位置（也就是它的原生上下文窗口,比如 Llama-3.1-8B 的 128K),你就开始依赖 RoPE 的分布外外推行为——这是一个众所周知、独立于 KV-Fold 本身的退化来源。论文明确说明了它的所有实验都把 $T$ 保持在模型的原生窗口内,正是出于这个原因；论文没有测试把 KV-Fold 推到超出训练位置范围之外会发生什么（那样会把”递归不稳定”和”位置外推不稳定”这两种不同的失效模式混在一起,论文有意避免了这一点）。

6.5 因果掩码与 RoPE 的交互:一个容易被忽略的前提条件

第 4.1 节的推导里有一个前提条件值得单独拿出来讲:为什么因果掩码(causal mask)能保证 $K_i, V_i$ 只依赖于 $\le i$ 的 token,而不受到后面 token 的影响?在标准 transformer 里,每一层的 $K^{(\ell)}_i, V^{(\ell)}_i$ 确实只是 $x_i$(及其前面层的输出)经过线性投影得到的,不涉及任何 attention 汇总——attention 汇总发生在计算 $Q$ 之后,不会反过来污染 $K, V$ 的计算。正因为这个性质,孤立地算一个 chunk 的 $K, V$(假设位置 ID 正确)与在一个更长的联合序列里算同一个 chunk 的 $K, V$,在数学上应该得到完全相同的结果——这正是 4.1 节论证里隐含依赖的一个关键事实。如果模型用的是非因果注意力(比如双向 encoder),这个性质就不成立了,KV-Fold 的基本前提也会随之崩塌。这也是为什么这篇论文(以及绝大多数 KV 缓存相关的工作)默认只适用于 decoder-only、因果注意力的 transformer。

7. 核心实证结果：drift 会饱和

图3（论文图3）：Qwen2.5-7B-Instruct（$T=16{,}384$，$C=256$）上，逐步 drift（蓝色）和递归 advantage（绿色）随链条深度的变化。drift 在最初约 7 次转移中上升到约 0.04 nats,之后一直维持到深度 63 都是平的；advantage 全程保持为正,甚至还略有增长。

论文报告的具体数字：depth 15 到 depth 60 之间,drift 只变化了 $-0.0003$ nats——用论文自己的话说,“完全在窗口间噪声范围内（$N=42$）“。换句话说,过了最初的瞬态之后,把链条跑得更深,在偏离完整注意力这个指标上几乎不需要额外付出任何代价。这正是”稳定regime”这个解读的核心：KV-Fold 的行为,不像一个随深度线性（或者更糟,几何级数式）累积舍入误差的迭代数值近似；相反,它看起来像是系统在第一次 chunk 转移之后就稳定到了一个附近的不动点,并且一直停留在那里。

为什么这在机制上说得通。 完整注意力和 KV-Fold 计算的是同一个函数,对同样的底层 token、在每个位置都以相同的方式条件化——唯一的区别只是用了多少次独立的 kernel 调用来计算被关注的 key/value。如果这纯粹是加性浮点噪声,你会预期 drift 大致按 $\sqrt{d}$ 或 $d$（取决于具体的误差累积模型）增长,而不是趋于平台。平台期这个现象反而暗示:KV-Fold 引入的偏差是第一次边界处的一次性偏移,一旦模型”见过”这个新 regime 下的缓存状态,之后的 chunk 就不会再引入额外的偏移——因为模型的注意力计算足够鲁棒（大致 Lipschitz 意义上),对遥远过去 key 的小扰动不会被放大爆炸。

8. 设计选择：为什么 drift 是结构性的而不是数值性的

这是论文的第二个重要实证支柱,值得单独拆开讲,因为这部分才是把”我们在一次实验里看到一条平的线”变成”这里有一个关于为什么这条线是平的的论断”的关键。

鲁棒性测试1——精度。 论文在 bf16 和 fp32 下重跑了 drift 测量——单次操作的数值精度提升了 $10{,}000\times$（bf16 大约有 3 位十进制尾数精度,fp32 大约有 7 位）。如果 drift 是由 chunk 边界之间累积的浮点舍入误差引起的,升到 fp32 应该会大幅缩小它。但实际观测到的是平台期只缩小了 2.8%。这是”drift 不是数值伪影”这个论断最有力的一条证据。

鲁棒性测试2——chunk size。 把 chunk size $C$ 在 8 倍范围内扫描（128 → 1024）,平台期变化不到 9%,而且没有单调趋势。如果 drift 是某种随 chunk 粒度变化的 kernel 级批处理伪影,你应该能看到跟 $C$ 之间的明显趋势。但没有。

鲁棒性测试3——架构。 同样的定性饱和曲线（先升后平)在 Qwen2.5-7B、Llama-3.1-8B、OLMoE 三个不同模型家族上都能复现——这三个模型有不同的注意力实现、不同的 head 数,以及（OLMoE 的情况下)一个稀疏 MoE 架构。平台期的量级在不同模型间有差异（这符合预期——不同模型对分布偏移的敏感度不同),但定性形状是一致的。

论文隐含在排除的另一种解释。 有人可能会担心:这里的”稳定性”其实只是”模型反正已经不再关注旧 token 了,drift 当然会趋于平台——这只是注意力饱和/稀释,而不是真正的递归属性”。下面第9节的 needle-in-a-haystack 结果直接回应了这一点:如果模型是稀释饱和、事实上忽略了远处的 chunk,那么检索一个植入在 511 次 chunk 转移之前的事实应该会失败。但它没有失败。所以 drift 的平台期与对旧位置保留的基于内容的可寻址性是共存的——这比单纯的饱和是一个更强、更有趣的论断。

这仍然可能脆弱之处。 三个鲁棒性检查都是在 PG-19（长篇书籍文本)上、用同样的测量协议（固定窗口采样、除测试精度外都用 bf16 一致的贪心解码）做的。它们都没有测试真正对抗性或分布外的 chunk 边界——比如一个恰好落在关键依赖中间的 chunk 边界（一段只有在很久之前用不寻常语法定义了某个变量才能读懂的代码块,或者一份大量交叉引用的法律文件）。论文自己在第8节讨论中承认了一个可以推广到这里的相关警示:递归”能容忍噪声式的扰动……但对系统性的信息损失很敏感（衰减或淘汰会把特定位置完全移除）“。一种系统性地在每个 chunk 边界都混淆注意力的分布外内容结构,属于系统性而非噪声式的扰动,而论文的鲁棒性测试并没有排除这种情况。

9. 长距离检索：平台期真的保留了信息吗

表1（论文表3）：Qwen2.5-7B-Instruct 上的 needle-in-a-haystack 检索,$T=16{,}384$（$C=256$,每个距离 20 次试验)。

距离 $d$	FULL	ISOLATED	KV-FOLD	比值
1	100% (20/20)	0% (0/20)	100% (20/20)	1.00
15	100% (20/20)	0% (0/20)	100% (20/20)	1.00
31	100% (20/20)	0% (0/20)	100% (20/20)	1.00
62	100% (20/20)	0% (0/20)	100% (20/20)	1.00
总计	100% (80/80)	0% (0/80)	100% (80/80)	1.00

这张表承担了很多论证工作:KV-Fold 在所有测试距离上都精确匹配 FULL 上限,而 ISOLATED（完全没有递归)则彻底失败——证实了保留这个事实的是递归本身,而不是分块的其他某种副作用。

多 needle 压力测试。 单个植入事实相对容易（已知模型即使在有损压缩下也擅长单 needle 检索）。论文通过同时插入 $K \in \{4, 8\}$ 个独立的 (key, value) 对并分别查询每一个来强化这一点（表2,对应论文表5）:在所有配置下,176 个 needle 中有 175 个被正确恢复（99.4%),唯一的失误发生在 $K=4$、一个中等距离位置——也就是说,不是系统性的失败模式,而是与普通模型噪声一致的孤立失误。

模型	$T$	$K$	试验次数	单 needle 准确率	全部正确	ISOLATED
Qwen2.5-7B	16K	2	10	20/20 (100%)	10/10	0/20
Qwen2.5-7B	16K	4	10	39/40 (97.5%)	9/10	0/40
Qwen2.5-7B	16K	8	10	80/80 (100%)	10/10	0/80
Llama-3.1-8B	128K	4	3	12/12 (100%)	3/3	0/12
Llama-3.1-8B	128K	8	3	24/24 (100%)	3/3	0/24
合计			36	175/176 (99.4%)	35/36	0/176

9.5 为什么需要多 needle 而不只是单 needle

单 needle 检索测试的是一个相对宽松的能力:只要模型能对这一个特定位置的信息建立足够强的 attention 链接,就能成功。但实际应用中,一个长文档往往同时有多个需要记住的事实——比如一份合同里同时有月租、押金、违约责任三个关键数字需要同时准确记得。如果模型内部机制是“注意力预算有限,保住一个就会挤掉另一个”(比如某种形式的容量竞争),那么多 needle 测试会明确暴露这个问题——随着同时需要追踪的事实数量增加,单 needle 时完美的检索率可能会明显下降。

这正是表2(论文表5)要回答的问题,而结果是令人安心的:$K=8$ 个同时存在的事实,在 128K 上下文、511 次 chunk 转移的深度下依然能 100% 同时正确检索。这说明 KV 缓存的容量不是瀝颇之处——因为每个位置的信息都是独立存储的,不需要与其他位置共享一个固定容量的“记忆槽位”,这与线性注意力或状态空间模型将历史压缩进一个固定维度向量的做法形成鲜明对比——后者在多个事实竞争同一块有限容量时,几乎必然会出现相互干扰。

10. 扩展到 128K：内存与算力代价

图5（论文图1）：主要结果复现——左图显示 KV-Fold 在链条深度直到 511 的所有测试距离上都保持 100% 精确匹配检索,而 StreamingLLM 在超过距离 1 之后就崩溃到 0%；右图显示峰值 GPU 内存随 $T$ 线性增长,在 128K 时于 40GB A100 上达到 35.6GB。

10.1 内存扩展的推导

链条深度 $t$ 处的 KV 缓存,存储的是目前为止已经处理的所有 $tC$ 个 token 在所有层、所有 head 上的 key/value。对于一个有 $L$ 层、$H_{kv}$ 个 KV-head、head 维度 $d$、bf16 存储的模型：

$$\text{每 token 字节数} = L \times H_{kv} \times d \times 2\ (\text{K 和 V}) \times 2\ (\text{bf16 字节数}) \tag{6}$$

对 Llama-3.1-8B（$L=32$,$H_{kv}=8$,$d=128$）：

$$32 \times 8 \times 128 \times 2 \times 2 = 131{,}072 \text{ 字节/token} = 0.128 \text{ KB/token} \tag{7}$$

这几乎精确匹配论文实测的 $0.13422$ KB/token（小差距很可能来自额外的推理服务开销——padding、分配器粒度等)。在 $T=128\text{K}$ 时：

$$128{,}000 \times 0.134 \text{ KB} \approx 17.2 \text{ GB} \tag{8}$$

——匹配表4报告的 17.18GB 缓存大小。峰值 GPU 内存（35.6GB)还包括激活值和模型权重本身（一个 8B 模型 bf16 大约 16GB),这意味着在这个操作点上,40GB 显卡只剩约 4.4GB 余量——论文直接把这称为”操作上限”。

表3（论文表4）：Llama-3.1-8B-Instruct（A100 40GB）上大规模的单 needle 检索、内存与算力。

$T$	深度	每距离试验数	检索率	KV 缓存	峰值 GPU	每 chunk 耗时	全链条耗时
32K	127	10	100%	4.29 GB	21.00 GB	0.103 s	13.2 s
64K	255	5	100%	8.59 GB	25.86 GB	0.176 s	44.9 s
96K	383	3	100%	12.88 GB	30.72 GB	0.252 s	96.9 s
128K	511	3	100%	17.18 GB	35.57 GB	0.335 s	171.3 s

10.2 算力扩展的推导

在链条深度 $t$ 处,当前 chunk 相对整个累积缓存的注意力代价大致是 $O(C \cdot tC \cdot H \cdot L)$（query 长度 $C$,key 长度 $tC$）。对所有 $N = T/C$ 个 chunk 求和：

$$\text{总计算量} \approx \sum_{t=0}^{N-1} O(C \cdot tC \cdot H \cdot L) = O\!\left(\frac{L H C^2 N^2}{2}\right) = O\!\left(\frac{L H T^2}{2}\right) \tag{9}$$

这和单次完整注意力前向传播的 $O(T^2)$ 总 FLOPs 是同一个量级——这也是必然的,因为 KV-Fold 计算的注意力模式,本质上等价于完整的因果注意力,只是被分摊到了多次 kernel 调用里。实测的逐 chunk 耗时（$T=32\text{K} \to 128\text{K}$ 时依次为 0.103 → 0.176 → 0.252 → 0.335 s)大致随该 chunk 所关注的平均缓存大小线性增长,与这个推导一致。

设计选择:如果总 FLOPs 不变,这样做到底节省了什么? 节省的完全是峰值工作内存,而不是总计算量。在 $T=128\text{K}$ 时,单次完整注意力前向传播需要物化 $[H, T, T]$ 的 score 矩阵——按公式(1)算大约 1TB,无论你有多少总计算预算都不可行。KV-Fold 最大的单 chunk score 矩阵是 $[H, C, T]$——在 $C=256$、$H=32$、$T=128\text{K}$ 的情况下大约是 2.1GB,预算内绰绰有余。这是对何时需要内存的重新组织,而不是对工作量的削减——在精神上更接近梯度检查点（FLOPs 相同,内存曲线不同),而不是一种近似方法。

10.5 一个容易被忽略的细节:为什么第一个 chunk 的成本不能忽略

在公式(9)的推导里,我们隐式地假设了第 0 个 chunk 的成本可忽略不计(因为它没有任何前缀可以关注)。但在实际工程实现中,第一个 chunk 仍然需要对自身内部做完整的自注意力计算(cost $C^2$),这个成本在 $C \ll T$ 时确实微不足道,但在 $C$ 选得较大时(比如为了减少 chunk 数量而把 $C$ 设得很大)则不可忽略。这家揭示了 chunk size $C$ 实际上是一个非平凡的调优参数:$C$ 越小,chunk 数量 $N$ 越多,递归转移的次数越多,调度开销越大,但每次转移的峰值内存越小;$C$ 越大,情况相反。论文第8节的鲁棒性实验表明 chunk size 在 128 到 1024 范围内对 drift 平台期影响不到 9%,但这不意味着 chunk size 对工程性能无关紧要——它影响的是峰值内存和调度开销的权衡,而不是模型行为的稳定性。

11. 设计选择:与 StreamingLLM 的对比

表4（论文表6）：$T=128\text{K}$、链条深度 511 时的对比。

方法	NLL	峰值 GPU	全链条耗时	$d{=}1$	$d{=}31$	$d{=}255$	$d{=}511$
KV-Fold	2.46 ± 0.12	35.6 GB	166 s	3/3	3/3	3/3	2/3*
StreamingLLM	2.66 ± 0.17	16.6 GB	22 s	3/3	0/3	0/3	0/3

*在 $d=511$ 的三次试验中有一次没有提取到有效的 5 位数字答案；结合此前单 needle 扫描在同一设置下 12/12 的结果,联合检索率是 14/15。

StreamingLLM 为什么是这样工作的。 StreamingLLM 保留少量固定的”attention sink”token（通常是序列最开始的几个 token,经验上会吸收不成比例的注意力份额——这是 StreamingLLM 原论文里记录的一个现象),加上一个有界的最近 token 滑窗（这次对比中是 1020 个 token,构成 1024 token 的有效缓存）。这使得内存无论 $T$ 多大都固定在 0.13GB——比 KV-Fold 线性增长的缓存便宜得多——相应地,墙钟时间也快了 7.5×（这个操作点上是 22s 对 166s）。

权衡的精确表述。 这两种方法不是在同一个维度上竞争。StreamingLLM 优化的是有界内存下的流式处理、且困惑度可接受,这里”可接受”意味着模型不需要回忆很久以前的具体事实——对于开放式聊天或只关心最近上下文的监控类场景来说是合理的假设。KV-Fold 优化的是精确的长距离召回,代价是内存随总上下文长度线性增长（而不是被压缩）。表4把这一点表述得很精确:在超出滑窗覆盖范围的每一个距离上（31、255、511 次 chunk 转移之前),StreamingLLM 都跌到 0%,因为 needle 已经被彻底从缓存里淘汰了——这不是软性退化,是一个硬性的架构上限。KV-Fold 付出 35.6GB 和 166s 的代价,完全避开了这个上限。

KV-Fold 在实践中可能输掉这场对比的地方。 如果你实际的工作负载很少需要在有界的最近窗口之外做召回——大多数对话或监控类工作负载确实如此——那么 StreamingLLM 7.5× 的加速和几乎为零的内存占用,才是客观上更好的工程选择,而 KV-Fold 的保证是在为一个你根本不需要的能力付费。KV-Fold 恰好是正确工具的场景是:(a) 你需要在任意深度都能做检索,并且 (b) 你有足够的内存预算容纳一个线性增长、直到你的操作上限（按论文自己的外推,大致是模型的原生上下文窗口)的缓存。

12. 对存储层面扰动（量化）的鲁棒性

讨论章节还报告了一个进一步的鲁棒性检查:在 Llama-3.1-8B、$T=128\text{K}$、链条深度 511 的设置下,对 KV 缓存做逐步的量化往返（bf16 → int$N$ → bf16）。int8 时,检索率保持在 13/14 次试验（93%,唯一的失误是没有提取到有效答案,而不是给出了错误答案）。int4 时,检索率降到 24/33（73%),用论文的话说”比中等深度时的 100% 有所下降”。论文自己的表述很有启发性:“递归能容忍噪声式的扰动……但对系统性的信息损失很敏感（衰减或淘汰会把特定位置完全移除)。“量化噪声大致是均匀且非针对性的（它不会特意破坏 needle 所在的那些 token),而淘汰（如流式方法所做的)则系统性地、无条件地针对旧位置。这是一个干净、可检验的区分,而且与论文展示的其他一切都一致:KV-Fold 的保证是关于保留特定位置的可寻址性,任何专门、系统性地移除位置可寻址信息（而不仅仅是给它加噪声)的扰动,都会破坏这个保证。

13. 实践部署笔记(论文之外的补充)

如果你真的想把这套方案接入生产环境,有几个值得了解的操作细节:

• 跨 GPU 的缓存放置。 128K 时 17GB 的缓存,在较小的 GPU 上无法与模型权重舒服地共存。多 GPU 部署要么把整个缓存钉在单张卡上（付出跨设备注意力的开销),要么按 PagedAttention 的方式分片;KV-Fold 天然可以和 vLLM 这类分块推理服务架构组合,但推理服务的调度器必须被配置为不压缩或淘汰过去的 chunk,否则会悄悄重新引入 KV-Fold 本来想避开的流式权衡。
• prefill 与解码。 论文所说的”分块递归”本质上是一种受控的、分阶段的 prefill。一旦最后一个 chunk 处理完、缓存构建完成,后续逐 token 解码流程完全不变——它只是作用在一个恰好是增量构建而非一次性构建出来的缓存上。
• 面向交互式会话的检查点。 论文没有讨论、但很实用的一个模式:每处理 $k$ 个 chunk 就对累积缓存打一次检查点,这样交互式会话可以回退到更早的一个点,而不需要从头重新 prefill 整个文档。
• 生产环境中的监控。 论文证明了在受控条件下（PG-19 文本、特定模型）,平台期能延伸到深度 511。在内容更加异构的生产部署里,我仍然会在线监控逐 chunk 的 NLL,以便在平台期意外”抬升”时能检测到——比如高度分布外的领域、chunk 边界处语法不寻常的代码,或者对抗性输入。

13.5 一个容易被忽略的细节:最后一个 chunk 之后的解码阶段

读这类论文时,我发现一个很容易被忽略、但对工程落地很重要的细节:论文重点描述的是“分块递归”这个 prefill 阶段本身,对于最后一个 chunk 处理完之后的解码(逐 token 生成)阶段,论文并没有特别展开讨论——因为那一部分完全是标准流程,与 KV-Fold 无关。但对于实际部署来说,这里有一个值得注意的细节:解码阶段的每一步都需要对整个已经累积到 $T$ 长度的缓存做注意力,而不是只对最后一个 chunk 做注意力。这意味着,即便 prefill 阶段本身通过分块避开了峰值内存问题,后续解码阶段的每步成本仍然随 $T$ 线性增长(因为每步都要与完整的 $T$-token 缓存做注意力)——这与普通自回归解码在长上下文下的成本特征完全一致,并不因为用了 KV-Fold 而改变。对于需要在长上下文上进行交互式多轮对话的应用,这意味着每轮回复的首 token 延迟会随对话历史变长而变长,需要在产品层面提前设计好 SLA 预期。

14. 复现推导:一个手算的玩具例子

为了对公式(9)的算力扩展建立直觉,考虑一个玩具设置:$C=2$,$T=8$（因此 $N=4$ 个 chunk),单层（$L=1$),单 head（$H=1$)。每个 chunk 的注意力代价（忽略常数)大致是 $C \times$（该步的缓存大小）：

• Chunk 0：缓存大小 0（还没累积任何东西)→ 跨 chunk 代价 $\approx 2 \times 0 = 0$（chunk 内部仍然会关注自身,所以严格说是 $C \times C = 4$,但跨 chunk 项是 0)
• Chunk 1：缓存大小 2 → 跨 chunk 代价 $2 \times 2 = 4$
• Chunk 2：缓存大小 4 → 跨 chunk 代价 $2 \times 4 = 8$
• Chunk 3：缓存大小 6 → 跨 chunk 代价 $2 \times 6 = 12$

跨 chunk 总代价:$0 + 4 + 8 + 12 = 24$。对比在 $T=8$ 上做完整注意力:代价大致是 $T^2/2 = 32$（上三角因果掩码）。这两者是同一个数量级（$O(T^2)$),证实了公式(9)的论断:KV-Fold 并不节省总 FLOPs——它只是把计算分摊开来,使得没有任何单次 kernel 调用需要一次性把完整的 $T \times T$ 矩阵放进内存。

14.5 一个常见误解:“因为总 FLOPs 一样,所以两者延迟也应该一样”

看到公式(9)的推导后,一个自然而然会出现的误解是:既然 KV-Fold 和完整注意力的总 FLOPs 同阶,那为什么它们的实际延迟表现会不一样?答案在于峰值内存与总计算量是两个不同的轴。单次完整前向传播在 $T=128\text{K}$ 时根本无法实际运行(内存不够,无法得到一个实际延迟数据点来比较)。KV-Fold 的价值恰恰在于它把一个原本不可行的操作,变成了一系列可行的小操作。因此,正确的提问不应该是“KV-Fold 比完整注意力快多少”(因为后者根本跑不起来,无从比起),而应该是“KV-Fold 相对于其他能在相同内存预算下运行的方法(比如流式方法)慢多少”。表4/图6 的对比正是在回答后者:KV-Fold 比 StreamingLLM 慢 7.5 倍,但换来了任意深度的精确召回。把这两个不同的问题混为一谈,是读这类长上下文系统论文时最容易踩的坑之一。

15. 符号速查表

符号	含义
$T$	总序列长度（token 数）
$C$	chunk 大小（token 数）
$N$	chunk 数量,$N = T/C$
$L$	transformer 层数
$H$	query head 数量
$H_{kv}$	KV head 数量（GQA 模型可能 $H_{kv} < H$）
$d$	head 维度
$\mathcal{K}^{(t)}, \mathcal{V}^{(t)}$	处理完 chunk $t$ 之后累积的 KV 缓存
$\mathcal{F}_\theta$	标准 transformer 前向函数,参数固定为 $\theta$
FULL	参照:对全部 $T$ 个 token 做单次完整注意力前向传播
ISOLATED	参照:每个 chunk 完全不带前缀处理
KV-FOLD	本方法:chunk $t$ 关注 chunk $0..t{-}1$ 累积的缓存
drift($d$)	$\text{NLL}_{\text{KV-FOLD}}(d) - \text{NLL}_{\text{FULL}}(d)$
advantage($d$)	$\text{NLL}_{\text{ISOLATED}}(d) - \text{NLL}_{\text{KV-FOLD}}(d)$
平台期（plateau）	drift 经过初始瞬态后的平坦区域

15.5 对比:与其他已发表过的长上下文方法的定位

把 KV-Fold 放到这个博客之前已经写过的长上下文/KV 缓存相关论文旁边看,它的定位相当清晰:StreamingLLM、MosaicKV、VeriCache 这一类方法处理的是“如何在有限内存下保留尽可能多的有用信息”——它们都需要回答“哪些 token 值得保留”这个问题,无论是通过固定策略(滑窗)、重要性评分,还是多级存储调度。KV-Fold 完全跳过了这个问题——它的答案是“不选,全部保留”,代价是接受线性增长的内存。这两类方法在设计哲学上完全相反:前者相信“不是所有 token 都同等重要”,后者(KV-Fold)干脆不做这个判断,把选择的责任完全交给内存预算。对于已经在这个博客里写过的 MosaicKV(动态二维压缩)和 VeriCache(有损变无损)这类方法而言,KV-Fold 更像是它们的“参照组”而不是竞争对手——它回答的是“如果什么都不丢,会怎么样”,从而为评估那些压缩方法究竟丢失了多少信息提供了一个干净的参考上限。

16. 局限性与边界条件

• 依赖位置范围。 所有实验都保持在每个模型原生训练的上下文窗口之内（Llama-3.1-8B 的 128K）。论文没有测试 $T$ 超出这个范围会发生什么,那需要与位置外推方法（YaRN、Positional Interpolation、LongRoPE)组合使用——作者明确把这标记为未来工作,而不是一个已解决的问题。
• 内存并没有真正缩小。 KV-Fold 在深度 $N$ 处的缓存,存储的信息量和对 $NC$ 个 token 做一次完整前向传播所需要的信息量完全一样。收益完全是操作层面的（把峰值内存分摊到时间上),而不是总内存或算力占用的削减。如果你的硬件真的容纳不下这个线性增长的缓存,KV-Fold 帮不了你——你还是需要一个压缩方法。
• 鲁棒性扫描的文本领域。 论文第3.1节的精度/chunk size/架构鲁棒性实验全部使用 PG-19 书籍文本。同样的结构性（非数值性）drift 行为在非常不同的内容分布上（源代码、结构化表格数据、话题突变频繁的多轮对话)是否成立,论文没有测试。
• 模型规模。 实验使用的是 7-8B 参数规模的模型。平台期现象（及其量级)在参数量大得多或小得多的模型上、或者在注意力变体差异很大的模型上（比如线性注意力混合架构、高度稀疏的注意力模式)是否同样成立,这篇论文没有验证。
• 量化会优雅退化,但确实会退化。 int4 的结果（检索率降到 73%,从 100% 下降）说明”噪声式扰动都没问题”这个论断是有实际边界的——把 KV-Fold 和激进的缓存量化结合起来省内存,并不是免费的午餐。

16.5 一个未被测试但值得关注的边界:多轮对话中的增量更新

这篇论文的所有实验都是在“一次性处理一个固定文档然后查询”这个设定下进行的。但很多实际产品场景(比如长时间运行的多轮 AI 助手会话)需要的是一种增量式使用模式:用户问一句,模型回答一句,然后用户又问下一句,如此循环。KV-Fold 的递归结构对这种场景天然兼容:每一轮用户输入 + 模型回复,都可以当成一个新的 chunk,追加到累积缓存上,下一轮直接在这个不断增长的缓存上继续。但论文没有专门测试这种场景下的 drift 行为——多轮对话的 chunk 边界往往不是固定长度的(用户输入长短不一),而且话题可能在不同轮之间大幅跳转,这与论文鲜明选用的 PG-19、内容连贯的书籍文本在分布上差异明显。对于想将 KV-Fold 直接用于多轮对话系统的团队,这是一个值得自己补做的验证实验,而不应直接假设 PG-19 上的结论能无缝迁移。

17. 批判性分析

本文特有的缺陷。 “稳定性”这个核心论断几乎完全建立在两个模型家族在 PG-19 上的实验（Qwen2.5-7B、Llama-3.1-8B,外加一个规模更小的 OLMoE 检查)以及一个合成的 needle-in-a-haystack 任务之上。needle-in-a-haystack 是一个众所周知的”必要但不充分”的长上下文能力代理指标——它测试的是字面意义上的字符串/事实召回,而不是真实长文档使用场景经常真正需要的对远距离上下文的推理（比如”第2章发生的事情,是否改变了我应该如何解读第40章”)。一个模型完全可能通过这篇论文里的每一个 needle 测试,却仍然无法把远距离上下文正确整合进下游推理链,因为检索和整合是不同的能力。论文没有测试任何需要长上下文推理的基准（比如需要多跳综合的长文档问答,或者需要跨文件依赖追踪的代码理解),所以”稳定性”这个论断的实际适用范围,比结论部分的措辞（“冻结的预训练 transformer 已经具备长上下文推理所需的要素”)所暗示的要窄。论文的修辞里”召回”和”推理”在某种程度上被当作同义词使用,但证据只支持前者。

作者低估或省略的局限性。 论文对”内存不会缩小”和”位置范围边界”这两点相当坦诚,但对相对于其他同样保留精确召回的长上下文方法（而不只是天生就要牺牲召回的流式基线)的墙钟代价,就没那么坦率了。论文没有与调得比较好的 KV 缓存淘汰方法做对比——比如基于注意力分数重要性启发式的方法（H2O 风格),而不是朴素滑窗——这类方法试图保留重要的 token 而不只是最近的 token,可能在使用远少于 KV-Fold 的内存的情况下,取得比朴素 StreamingLLM 好得多的检索表现。没有这个对比,就很难判断 KV-Fold 相对流式方法的”精确召回”优势,是否能推广为相对整个更成熟、更复杂的压缩文献的优势,还是说它只是恰好打赢了一个该领域已经在更近期工作里超越了的、有点稻草人性质的基线（无重要性加权的均匀滑窗）。

具体、可执行的改进建议。

1. 加入一个真正的长文档推理基准（比如 LongBench 或 RULER 的多跳任务子集,或者一个”第2章改变了第40章的解读”这样的合成任务),来测试保留下来的信息是否真的可用于下游任务,而不只是能被逐字检索出来。
2. 至少与一种重要性加权的 KV 压缩方法做对比（H2O、SnapKV 或类似方法),而不只是与朴素滑窗基线对比,从而在内存与召回的真实 Pareto 前沿上确定 KV-Fold 的位置,而不只是相对于代价最低的比较对象。
3. 测试真正对抗性的 chunk 边界条件——比如故意把 chunk 边界切在一个语法上承重的结构中间(一个未闭合的括号,或者一个代词的先行词落在下一个 chunk 里的不完整句子)——来压力测试”drift 是结构性而非数值性的”这个论断,在 chunk 边界被对抗性选择、而不是按固定的、与内容无关的间隔选择时,是否依然成立。
4. 更一致地报告方差/置信区间。 好几个头条数字(比如表4里逐 $T$ 只跑一次试验的内存/耗时数字)是”第一次试验”的结果而不是多次平均,这使得很难像论文对基于 NLL 的 drift 数字那样仔细评估这些系统层面数字(内存、墙钟时间)的测量噪声。
5. 明确推一下位置范围这个边界,哪怕只是简单地把 KV-Fold 和一种位置外推方法(论文明确提到 YaRN 是未来工作)结合起来,报告平台期行为是否依然成立——这是论文自己局限性讨论里暗示的最显而易见的”下一步实验”,而它的缺失,使得”这套方法到底能扩展多远”这个问题,即便按论文自己的表述,也仍然悬而未决。

17.5 常见误读澄清

在讨论区里关于这篇论文,我观察到三个容易出现的误读,值得提前澄清:

误读 1:“KV-Fold 节省了计算量”。 不对。如第10.2节公式(9)所示,总 FLOPs 与完整注意力处于同一量级,KV-Fold 没有减少任何计算,只是把峰值内存需求分散到了时间维度上。这与梯度检查点(gradient checkpointing)的思路更相似,而不是与任何一种计算近似方法相似。

误读 2:“drift 平台期意味着模型对早期 chunk 完全不敏感了”。 也不完全对。平台期意味着逐步 drift 不再随深度增长,但它不意味着 drift 是零——实际测到的平台期数值大约是 0.04 nats(Qwen2.5-7B 上),这是一个真实存在、但不再持续恶化的偏差。第9节的检索实验证明了这个小偏差并不妈碍字面事实的精确检索,但对于对数值敏感的下游任务(比如需要比较两个候选答案哪个更可能的任务),这个非零偏差未必无关紧要。

误读 3:“KV-Fold 是一种新的模型架构”。 完全不对。KV-Fold 没有改变模型的任何一行代码,没有新增任何层或参数。它完全是推理时的调度/缓存管理策略,与模型本身完全解耦。这也是为什么它能在任何预训练好的 Hugging Face 兼容模型上直接使用,而不需要重新训练。

18. 可复现性说明

• 本次审阅的版本中没有找到代码链接（arXiv v1 PDF 里没有 GitHub 地址);该方法本身足够简单(参见上文算法1),可以直接对着任何兼容 Hugging Face past_key_values API 的实现重新实现。
• 使用的模型:Qwen2.5-7B-Instruct、Llama-3.1-8B-Instruct,以及 OLMoE(跨架构对比表里除了”OLMoE”之外没有给出更详细的具体变体)。
• 评估文本:PG-19 验证集切分,固定随机种子,窗口从文档第 200 个 token 处开始。
• 硬件:所有报告的内存/耗时数字都来自单张 40GB A100。
• 精度:默认 bf16;fp32 和 int8/int4 变体专门用于本文第8节和第12节描述的鲁棒性消融实验。

19. 一个实践决策框架:到底什么时候该用 KV-Fold

综合以上所有内容,值得把这个权衡浓缩成一个可以直接拿来用的决策框架,因为论文自己的表述(“冻结的 transformer 已经具备长上下文推理所需的要素”)容易让人把 KV-Fold 当成一个万能的即插即用升级。它不是——它是权衡曲线上一个具体的点,是否要用它,应该由你实际工作负载的形状决定,而不是被 foldl 这个框架的优雅程度说服。

决策变量1:你的任务需要在无界距离上做精确检索,还是只需要”足够近”的上下文? 如果你的应用是一个只关心最近几轮对话的客服聊天机器人,或者一个只需要对过去一小时日志做推理的监控系统,你几乎肯定不需要 KV-Fold 的保证——一个有界滑窗(StreamingLLM 风格)能给你快 7.5 倍的墙钟时间和一小部分的内存占用,代价只是放弃一个你反正也用不上的能力(任意深度的召回)。如果你的应用是仓库规模的代码辅助(一个在 5 万行文件开头定义、在文件末尾被引用的函数)、纵向病历审查,或者交叉引用密集的法律文档分析,那么无界召回就不是锦上添花,而是整件事的核心,KV-Fold 的权衡就直接相关了。

决策变量2:相对于你典型的上下文长度,你实际的内存预算是多少? KV-Fold 的缓存以固定、可预测的速率增长(公式6-8:对 8B 级别的模型大约是每 token 0.13KB)。如果你能提前算出,你 95 分位的上下文长度乘以这个逐 token 代价,仍然能在你的推理硬件上留出舒适的余量,那么 KV-Fold 在操作上就很容易采用。如果你最坏情况下的上下文长度会把你推过 GPU 的内存上限,KV-Fold 解决不了你的问题——你还是需要一个淘汰或压缩策略,而这时诚实的对比对象不是 KV-Fold 对 StreamingLLM,而是 KV-Fold 对一种重要性加权的压缩方法(第17节建议2),而这篇论文没有提供这个对比。

决策变量3:你的任务形态是”检索型”还是”推理型”? 如第17节所论证的,needle-in-a-haystack 测试的是字面意义上的事实召回,而不是跨远距离上下文的多跳综合。如果你的任务真的只需要”找到并复述之前的某个具体事实”(日志查找、ID 查找、某一行具体代码),这篇论文的证据直接支持使用 KV-Fold。如果你的任务需要整合、推理分散在长文档各处的信息(比如”第2节引入的约束条件,是否与第40节的假设冲突”),这篇论文的证据基础并没有直接回答 KV-Fold 是否有帮助,因为它从来没有在这类任务上被测试过。

一个简单的启发式总结:

场景	推荐方案
有界的最近上下文就够用,对延迟敏感	StreamingLLM / 滑窗
需要在任意深度做精确召回,内存预算能舒服覆盖最坏情况的 $T$	KV-Fold
需要在任意深度做精确召回,但内存预算紧张	重要性加权的 KV 压缩(这篇论文没有与 KV-Fold 对比过——请自行做基准测试)
需要对远距离上下文做多跳推理,而不只是召回	这篇论文两个方向都没有测试过;请直接在你自己的任务上做基准测试
上下文长度经常超过模型原生训练的位置范围	先与位置外推方法(YaRN / LongRoPE)组合使用;这篇论文没有测试这种组合

这个框架不是论文本身提供的——这是我自己对论文证据基础在哪些地方真正支持一个建议、在哪些地方保持沉默的综合梳理,我会把以上任何一条建议都当作一个需要在你自己的工作负载上验证的起始假设,而不是一个保证。

19.5 对中文读者的延伸思考

跳出这篇论文本身,有几点值得中文技术社区读者多想一层。

第一,这类”不改模型、只改推理协议”的论文,门槛低但含金量不一定低。 KV-Fold 没有引入任何新的可学习参数,复现它理论上只需要一个支持 past_key_values 前缀注入的标准推理接口——这跟很多需要专门训练基础设施、多机多卡才能复现的系统论文形成了鲜明对比。这对国内中小团队、高校实验室是个友好信号:验证这类论文的核心论断(drift 是否真的会饱和、检索是否真的能保持 100%),门槛主要在数据和计算资源,而不在复杂的训练工程。

第二,长上下文的”精确召回”和”深度理解”之间的距离,值得在国内长文本应用(比如合同审查、金融研报梳理、代码库级别的 AI 编程助手)中特别警惕。 这些场景下用户真正在意的往往不是”模型能否原样复述出某个句子”,而是”模型能否正确理解并结合分散在整个文档中的多个线索得出结论”。KV-Fold 的实验设计(植入单一字面事实然后原样问回来)本质上只能回答前一个问题,对于后一个问题没有任何直接证据。国内团队在评估这类长上下文方法时,建议自己额外补一套针对自己业务场景的多跳理解测试,而不要直接把 needle-in-a-haystack 得分当成产品就绪的充分依据。

**第三,当前国内开源推理框架(vLLM、SGLang 等)已经处处都在用 KV 缓存,KV-Fold 这种”不压缩、只累加”的思路其实很容易直接接到现有的 PagedAttention 类基础设施上——只需要确保调度器不会对旧 chunk 做预期之外的淘汰或压缩。对于国内已经在自建推理服务上投入了大量工程能力的团队,这意味着验证成本非常低——可以先在小规模、低成本的环境下验证 drift 平台期论断是否在自己的业务数据上成立,再决定是否值得投入更大的工程资源。

20. 结论

KV-Fold 的贡献不是一个新架构或新的训练配方——而是一个关于冻结 transformer已有能力的实证论断,并且刻画得足够仔细,因而是有用的。把 KV 缓存当作跨 chunk 的左折叠累加器,把一次不可行的完整前向传播变成了一系列可行的小前向传播,代价是内存线性(而非压缩)增长,而论文最核心的证据——drift 平台期在数值精度大幅提升、chunk size 扫描、架构切换下都能存活——是一个关于 transformer 注意力对这种分块重组到底有多鲁棒的、真正有趣的实证发现。needle-in-a-haystack 结果用任务层面的证据支撑了这一点,而不只是依赖聚合 NLL。在论文对自身局限性坦诚的地方(内存不会缩小、位置范围受训练限制、量化容忍度有上限),它赢得了信任;在它借助”长上下文推理”这样的修辞框架、而实际只展示了精确召回的地方,读者应该把这个论断限定在更窄、证据支撑更充分的版本上:在目前测试过的内容分布下,KV-Fold 可靠地保留了可检索的信息,贯穿很长的链条。