连续性而非重要性:文档编辑后陈旧KV缓存的预算修复
摘要
本文研究了文档编辑后LLM系统中陈旧KV缓存的预算修复方法,证明了连续的编辑本地窗口能有效恢复性能,并且比完全重新预填充更快。
arXiv:2609.17983v1 Announce Type: new
摘要:KV缓存复用可以降低检索增强生成和代理系统中的推理成本,但缓存的上下文可能在检索知识、工作记忆或用户状态被编辑后变得陈旧。在因果自注意力下,即使局部编辑也会影响下游KV状态。完全重新预填充能可靠地恢复一致性,但成本高昂,而仅刷新编辑过的跨度可能导致下游依赖陈旧。我们将原位修复建模为预算重计算,并在一个事实性RAG基准上比较了无训练位置选择策略,该基准匹配了直接和派生编辑。跨三个模型家族,所有策略都能修复直接情况,但派生情况清楚地将它们区分开来。在主要预算下,连续的编辑本地窗口至少恢复了编辑后答案边际的0.94,并且显著优于基于注意力、KV偏差和结构选择器的方法。机制分析表明,在清洁状态移植下有效的位置集合在实际重计算中可能失败,因为分散的位置会继承周围的陈旧性。编辑本地优势也取决于邻接性,当承载答案的文本向下移动时,这种优势基本消失。因为与答案相关的编辑几乎总是破坏模型行为,故障严重程度难以预测,且修复比完全重新预填充快13-21倍,我们的结果支持在依赖文本保持与编辑相邻时无条件进行编辑本地修复。
查看缓存全文
缓存时间: 2026/09/17 09:29
# 连续性而非重要性:文档编辑后的KV缓存预算修复
来源:https://arxiv.org/html/2609.17983
###### 摘要
KV缓存重用可降低检索增强生成和智能体系统中的推理成本,但当检索到的知识、工作记忆或用户状态被编辑时,缓存的上下文可能变得过时。在因果自注意力机制下,即使局部编辑也会影响下游的KV状态。完整的重预填充能可靠地恢复一致性,但成本高昂;而仅刷新编辑跨度又可能使下游依赖项保持陈旧。我们将原地修复建模为预算重计算,并在具有匹配的直接编辑和派生编辑的事实性RAG基准测试上,比较了无需训练的位置选择策略。在三个模型系列中,所有策略都能修复直接编辑情况,但派生情况明显区分了它们。在主要预算下,连续编辑局部窗口能恢复至少0.94的编辑后答案余量,并显著优于基于注意力的、基于KV偏差的和基于结构的策略。机制分析表明,在干净状态移植下有效的位置集在实际重计算下可能失败,因为分散的位置会继承周围的陈旧性。编辑局部优势也依赖于邻接性,当承载答案的文本移至下游时,这种优势基本消失。由于与答案相关的编辑几乎总会破坏模型行为,失败的严重程度难以预测,且修复速度比重预填充快13–21倍,我们的结果支持在依赖文本仍与编辑相邻时,进行无条件编辑局部修复。
1南佛罗里达大学电气与计算机工程系
2DEVCOM陆军研究实验室
\{mmao, xlin2\}@usf\.edu, wyatt\.t\.mackey\.civ@army\.mil
## 引言
图1:问题与探测设计。\(a\) 对缓存文档进行原地编辑,会使编辑跨度的KV条目编码旧文本,且所有下游条目都变为陈旧。\(b\) 每个基准测试项目将同一个问题与两种上下文结构配对:一个*直接*探测,其中编辑重写了答案文本;一个*派生*探测,其中答案位于编辑别名下游的未编辑查找条目中。若不修复,缓存将返回编辑前的答案。RAG管道和基于LLM的智能体越来越多地跨请求复用检索文档或内存块的KV状态,以避免重复预填充(Yao等人 2025;Bergman等人 2025;Ye等人 2026;Pan等人 2026)。此优化假设缓存的源内容不会改变。在部署中,当事实记录被更正(Ouyang等人 2025;Cohen等人 2024)、策略被修订或智能体的工作记忆更新时(Packer等人 2023),该假设会被打破。此时源文本已更新,而保留的KV张量仍编码旧版本。因此,请求可能基于不再匹配知识库的表示来得到回答。现有的文档级重用方法优化了重用和组合,但未在源编辑后同步缓存的表示。
修复这种不匹配并不限于编辑跨度。继续使用陈旧缓存服务会降低响应准确性(Ouyang等人 2025),而因果自注意力使得每个下游KV状态都依赖于旧内容。完整的重预填充恢复了一致性,但仅在编辑少量令牌后,就要重新编码整个长上下文。近期工作已开始在小型编辑后原地修复缓存,但每种提出的方法都存在局限性。KVEraser用学习到的引导状态替换目标跨度,但需要针对模型进行训练,且针对的是删除而非事实替换(Li等人 2026)。MTN使用控制智能体任务中的神谕信号,重计算按因果效应排序的下游节点(Li 2026)。两者都未能解决实际重计算下,事实性RAG的匹配预算问题。因此,为构建一个低预算、无需训练的修复策略,我们首先要问:一旦编辑跨度本身被刷新,哪些下游位置最重要?
我们的研究将事实编辑与大约5000个检索到的令牌的上下文配对。每个问题要么直接询问编辑后的事实,要么需要通过未改变的下游文本进行两跳推导。从陈旧缓存出发,每个策略刷新已知的编辑跨度,并在相同的重计算预算下选择K个下游位置。我们比较了编辑局部窗口、结构分隔符(Li 2026)、陈旧查询注意力(Wang等人 2026)、基于CacheBlend的KV偏差(Yao等人 2025)和随机选择。还引入了一个移植衍生的因果排序,但仅作为不可部署的诊断工具。评估涵盖Llama、Qwen和Mistral的开发集和保留集,以及一个将承载答案的文本移至下游的1099项变体。我们使用预先指定的标准,并报告保留集的余量恢复和翻转率。
三个结果确定了基线。当K=32时,每个策略在直接问题上都达到饱和,而派生答案则区分了它们。编辑局部窗口恢复了0.94–1.01的答案余量,并翻转了0.95–1.00的保留集项目,在余量恢复上以0.46–1.00的优势击败了所有替代方案(Holm校正p≤3×10⁻⁹)。这种优势依赖于邻接性。将承载答案的文本移至下游250个令牌,将编辑局部恢复率降至0.01–0.09,其中陈旧查询注意力仅在一个模型系列上有帮助。移植可恢复性也无法预测实际重计算下的修复情况。因果排序在干净状态移植下恢复了0.92–0.97的余量,但相同位置在K=8重计算下仅恢复0.01–0.21。重计算在每个保留集项目上表现更差。移植状态从正确的缓存导入信息,而重计算状态则读取陈旧的周围状态。连续的编辑局部窗口通过按顺序重建该依赖链而成功。最后,与答案相关的编辑几乎总会破坏陈旧缓存(基准率≥0.988),且廉价特征难以预测失败的严重程度(最佳折叠外ρ=0.17)。由于修复速度比重预填充快13–21倍,在此设置下,无条件应用编辑局部修复是实用的策略。它也是未来选择方法必须超越的无需训练的基线。
总之,本文做出了以下关键贡献:
- •我们将陈旧缓存修复建模为预算重计算,并引入了配对的直接、派生和距离控制的事实编辑。
- •我们在三个模型系列上,以匹配的预算比较了五种无需训练的选择器,建立了EditLocal作为强大的相邻块基线。
- •我们将干净状态移植下的定位与实际重计算下的修复区分开来。
- •我们表明,在此基准测试中,与答案相关的编辑值得进行无条件修复,因为失败频繁、严重程度难以预测且修复成本低廉。
## 相关工作
#### 文档级KV重用
RAGCache存储检索知识的中间状态,而TurboRAG预计算每个块的KV缓存,以便跨查询重用(Jin等人 2025;Lu等人 2025)。两者都通过重用检索文本的存储状态来减少重复预填充。两者都未解决源文本更改后这些状态应如何更新的问题。HoH表明,即使当前证据可用,过时的检索证据也会降低RAG准确性(Ouyang等人 2025),但它研究的是文本级别的过时信息,而非已缓存表示的修复。我们研究的是源编辑后随之而来的系统问题:一个陈旧文档缓存中有多少部分需要重计算?
#### 选择性重计算
选择性重计算处理的是不同的缓存不匹配。CacheBlend通过重计算具有大KV偏差的位置来恢复缺失的交叉注意力,而ProphetKV使用查询相关性对位置进行优先排序(Yao等人 2025;Wang等人 2026)。EPIC重计算一小部分固定的初始块令牌,Cache-Craft通过有限的重计算修复可重用的块缓存,KVShare在预填充和解码期间选择高偏差状态(Hu等人 2025;Agarwal等人 2025;Yang等人 2025)。在这些方法中,源块是不变的,不匹配来自在新上下文中重用其缓存。我们的实验将偏差和基于查询的选择信号转移到源文本已更改的缓存上,并在相同的下游位置预算下对它们进行比较。
#### KV缓存编辑
KV缓存编辑与我们的设置最接近。KVEraser用学习到的引导状态替换目标跨度以消除其影响(Li等人 2026)。Li(2026)表明,更改字段可能会在下游状态中保留旧结论,并按因果效应对这些状态进行排序。Leyline提供了用于删除或替换缓存跨度的服务原语,包括用于长度变更编辑的位置校正(Ma等人 2026)。我们隔离了保持长度不变的事实替换,并询问在实际重计算匹配预算下,哪个无需训练的选择器在其选择的位置上有效。这使我们的设置与学习擦除、缓存拼接以及通过神谕状态移植排序的位置集区分开来。
## 缓存修复作为预算重计算
#### 问题设置
服务系统预填充上下文C并存储其键值状态以供重用。编辑后产生C′,存储的缓存K(C)变为陈旧;完整预填充K(C′)是*神谕*修复目标,而非竞争方法。原地修复转而刷新K(C)的选定条目,使其朝向此目标。
我们隔离一个连续、保持长度不变的编辑:|C|=|C′|=n,且在半开跨度S=[s_start, s_end)之外,c_i=c′_i。因此位置和旋转相位保持不变;长度变更编辑也需要位置校正,不在我们的范围内(Ma等人 2026)。每个基准测试项目将一个*直接*条件(其答案位于S内)与一个*派生*条件(其答案位于未改变的下游文本中,但依赖于编辑后的事实)配对(图1b)。这对项目共享检索到的文档、插入点、主题、值对和查询,我们分别报告这些条件。
#### 修复接口
每个策略使用相同的算子,仅在选择的K个位置上不同。令D=[s_end, n-1]为下游候选池,令A_π ⊆ D, |A_π|=K为策略π选择的位置。修复后的集合为P_π = S ∪ A_π,且
\widetilde{\mathcal{K}} = \mathcal{R}\big(\mathcal{K}(C), C', P_\pi\big)。
该算子从C′逐层重计算P_π,所有其他状态保持不变,使用与先前系统相同的选择性重计算原语(Yao等人 2025)。其完整位置端点是
\mathcal{R}\big(\mathcal{K}(C),\,C',\,\{0,\dots,n-1\}\big) = \mathcal{K}(C')。(1)
已知的编辑跨度总是被重计算,并在策略间共享,而新的查询从不被缓存,在评分期间重计算。因此,K仅计算额外的下游位置。我们排除上游位置,因为因果注意力阻止它们依赖于编辑,并在数值上验证了此不变性。问题是哪个可部署规则能最有效地选择A_π。
#### 成本核算
我们分离三种成本:编辑跨度和新查询的公共工作、匹配的修复预算K⋅L令牌-层,以及选择器开销。公共项在策略比较中抵消,而开销在K之外报告。仅基于文本和位置的规则没有选择器前向传播;Attention增加了一个陈旧缓存评分管道(Wang等人 2026),CacheBlend在前缀上增加约一个预填充层(Yao等人 2025)。我们使用挂钟延迟作为主要系统度量,令牌-层作为与设备无关的次要度量;第5节报告了两者。完整的构建、接口不变性和成本分解见补充附录。
#### 什么算作修复
仅答案准确度无法区分发出相同字符串但具有不同底层偏好的缓存。因此每个项目定义了一个编辑前答案a_old和一个编辑后答案a_new。对于缓存状态x,令m_x为它们长度平均的、教师强迫对数概率之差。我们的主要指标是
MR = \frac{m_{repaired} - m_{stale}}{m_{oracle} - m_{stale}},(2)
其中0表示与陈旧缓存相比没有变化,1表示达到神谕水平。MR未裁剪,零间隙项目被排除。
我们配对此内部度量与可见行为。令y_b为对于保留项目b的最多16个令牌的贪婪续写。翻转率为
Flip = \frac{1}{|\mathcal{B}|} \sum_{b \in \mathcal{B}} \mathbf{1}\big[\,a_{new} \in y_b \;\wedge\; a_{old} \notin y_b\,\big]。(3)
MR捕捉决策边界前的部分恢复,而翻转记录生成是否仅暴露新答案。我们同时报告两者,并将KL恢复作为次要的分布度量。附录给出了完整的评分和边缘情况规则。
#### 选择策略
表1比较了四种可部署信号——编辑邻近性、结构、陈旧查询注意力(Wang等人 2026)和KV偏差(Yao等人 2025)——与匹配的随机对照。这些策略可能使用陈旧缓存、编辑后的上下文、编辑位置和查询,但永不使用神谕缓存或答案。灰色行使用不可用的相似文章
RestoreKV:在激进的查询无关KV缓存驱逐下恢复全缓存行为
RestoreKV 引入了一种学习式恢复机制,作为查询无关 KV 缓存驱逐的补充;它通过一次 LoRA 适配的遍历生成紧凑的上下文条件恢复缓存,从而在激进预算下恢复全缓存行为,并在四个长上下文基准上提升了性能。
查询可见性如何改变KV-Cache压缩排名:一项匹配预算的审计
本文在查询无关协议下审计了六种KV-cache压缩方法,发现与查询感知评估相比,排名发生了显著变化,这对长上下文推理中的缓存重用具有重要意义。
ResKV:重构被省略的注意力贡献以实现固定预算的KV缓存压缩
ResKV提出了一种KV缓存压缩方法,将固定预算分为精确的主缓存和紧凑的残差缓存,以重构被省略的注意力贡献,从而在多个骨干网络上提升LongBench和RULER上的性能。
@akshay_pachaar:你的 KV 缓存中 90% 从未被重用。(提示缓存从未旨在解决此问题)如果你的系统提示和工具定义…
CacheBlend,EuroSys 2025 最佳论文,解决了由于提示缓存中严格的前缀匹配导致 90% 的 KV 缓存从未被重用的问题。通过选择性地仅重新计算文档之间的边界令牌,它在不损失质量的情况下实现了 2-4 倍的多文档处理速度提升,并在开源 LMCache 层中实现。
价值感知KV缓存淘汰何时有效?一种针对非单调缓存压缩的固定契约诊断方法
本文介绍了一种固定契约诊断工具,用于分析KV缓存压缩方法在长上下文LLM推理中成功或失败的原因。文章确定了三种故障模式——遗漏证据、对无关token进行评分以及破坏相关证据——并在LongBench和NeedleBench上对这些模式进行了评估。