面向长时程LLM推理的上下文回收

arXiv cs.CL 论文

摘要

本文介绍了ContextForge,一种层次化内存架构,将LLM上下文窗口视为可回收工作空间,在长时程任务上实现了显著的令牌和速度改进,同时在拥有2.76亿行的企业基准上保持了准确性。

arXiv:2606.26105v1 发布类型:新 摘要:大型语言模型(LLM)在短上下文推理中表现出强大能力,但由于上下文窗口限制和低效的令牌使用,在长对话过程中性能会下降。我们介绍了ContextForge,一个上下文回收系统,通过结合结构化查询生成、外部内存检索和受控合成,在对话轮次中维护任务相关信息。该系统能够高效复用先前的计算,无需依赖完整上下文重播,从而减少令牌开销并保持答案质量。我们使用一个15轮对话基准评估ContextForge,该基准测试多轮推理、回指引用以及跨结构化医疗查询的领域切换。与使用相同底层模型的基准代理相比,ContextForge表现出更优的一致性并降低了令牌消耗,同时保持了相当的响应准确性。这些结果表明,上下文回收为扩展LLM在长时程任务中的能力提供了一种实用方法,无需更大的上下文窗口或模型重新训练。代码和评估工件可在 https://github.com/Betanu701/ContextForge 获取。
查看原文
查看缓存全文

缓存时间: 2026/06/26 05:13

# 面向长程LLM推理的上下文回收机制——固定上下文预算下无界会话的分层记忆架构
来源:https://arxiv.org/html/2606.26105  
\(2026年5月1日\)

###### 摘要

大型语言模型是无状态的:每次请求开始时都没有先前交互的记忆,固定大小的上下文窗口是外部知识到达模型的唯一通道。本文将上下文窗口重新定义为**可回收的执行工作空间**——一个固定预算的资源,在每个轮次中显式加载、使用和释放,类似于操作系统中的工作集。我们提出了一个支持这种模型的五层记忆层次结构,从可选的免训练LoRA层(分摊零token领域专业知识)到磁盘支持的存储(实际上无界容量),并采用确定性主动检索,在每次推理调用之前组装相关知识。该层次结构在ContextForge中实现,这是一个开源的Python系统,并在一个包含2.76亿行数据的企业数据集上,与使用相同LLM的Azure AI Foundry代理(采用Fabric Data Agent工具)进行了评估。在受控条件下,上下文回收系统在120个测试中达到约相等的准确率(85 vs. 84),同时token使用量减少4.2倍,响应速度在12轮基准测试中提升4.7倍。更长的15轮评估显示一致的结果(300个中225 vs. 194),且随着对话深度增加,效率优势进一步累积至token使用量减少13.4倍,响应速度提升8.0倍。无论对话长度或后备存储大小如何,主动上下文使用量保持在固定token预算内,从而能够在商品硬件上以固定主动上下文预算,在大型知识存储上运行长时间会话。代码和评估工件可在https://github.com/Betanu701/ContextForge获取。

关键词:上下文回收,分层记忆,大型语言模型,上下文窗口管理,缓存增强生成

## 1 引言

大型语言模型被部署到需要记忆的环境中,但它们本身却是无状态的。每次API调用都没有之前交互的记忆,而上下文窗口(通常为8K到128K token)是外部知识到达模型的唯一通道。对于知识库涵盖数十亿token且对话跨越数百轮次的部署场景,这种无状态特性在模型接口与应用需求之间造成了根本性的不匹配。

本文将LLM上下文窗口重新定义为**可回收的执行工作空间**,类似于操作系统中的工作集。系统不再试图将所有相关知识塞进一个不断增长的提示中,而是在固定token预算下,在每个轮次显式加载、使用和释放上下文。这一框架与长上下文模型架构的进步正交,并与现有的检索和记忆增强方法互补。核心贡献在于:主动上下文受限于固定预算,不会随对话长度增长,同时保留对更大后备存储的访问。

当前主流的LLM知识扩展方法各自解决了一部分问题:

#### 检索增强生成(RAG)

RAG系统(Lewis等人,2020 (https://arxiv.org/html/2606.26105#bib.bib1))从向量存储中检索文档片段并注入上下文窗口。这引入了每查询的检索延迟,产生可能受语义漂移影响的近似匹配,并采用扁平的层次结构。RAG还缺乏会话记忆:每个轮次都是独立的检索操作。本文的方法与RAG互补——它提供了RAG所缺乏的上下文管理层。

#### 微调

参数高效微调(LoRA,QLoRA)将领域知识嵌入模型权重,但需要标注训练数据、GPU计算,并且每当知识变化时需要完全重建适配器。

#### 扩展上下文窗口

具有扩展上下文窗口的模型可以处理更大的文档,但预填充延迟和服务成本会随上下文长度显著增长,且模型在会话之间仍然是无状态的。我们的方法是正交的:它管理进入上下文窗口的内容,无论窗口大小如何。

我们提出了一个五层记忆层次结构,将知识分布在靠近模型的多个层级中——从可选的权重内LoRA层(分摊零token成本)到磁盘支持的存储(实际上无界容量,子5毫秒检索)。上下文回收机制将上下文窗口视为可复用的固定预算工作空间,从而能够在固定主动上下文预算下,在大型知识库上运行长时间对话。

该层次结构在ContextForge中实现,这是一个开源的Python系统,可在https://github.com/Betanu701/ContextForge获取,用于在多个模型提供商上验证该架构。所有实验使用相同的底层LLM和数据集,以隔离上下文管理的影响。

本文剩余部分组织如下:第2节 (https://arxiv.org/html/2606.26105#S2)介绍五层架构。第3节 (https://arxiv.org/html/2606.26105#S3)详细说明可选的免训练LoRA构建。第4节 (https://arxiv.org/html/2606.26105#S4)描述上下文回收机制。第5节 (https://arxiv.org/html/2606.26105#S5)介绍主动加载流水线。第7节 (https://arxiv.org/html/2606.26105#S7)讨论数据库模块。第8节 (https://arxiv.org/html/2606.26105#S8)介绍夜间预计算系统。第9节 (https://arxiv.org/html/2606.26105#S9)提供实证评估,第11节 (https://arxiv.org/html/2606.26105#S11)总结。

## 2 五层记忆架构

系统将知识组织为五个层次,按与模型计算的接近程度排序(图1 (https://arxiv.org/html/2606.26105#S2.F1))。主要贡献在于对上下文窗口(第0–1层)的显式生命周期管理,它利用现有的KV缓存机制作为更广泛的上下文回收策略的一部分,以在轮次间锚定稳定的分层上下文。第-1层(LoRA)是可选的,仅适用于自托管模型;第2–3层提供索引和持久化。

第-1层:LoRA权重(可选)  
     模型内领域专业知识     0 token  
第0层:残差状态  
     稳定的KV前缀     约500 tokens  
第1层:分支缓存  
     动态每查询     2–10K tokens  
第2层:记忆索引  
     BM25倒排索引     <1 ms  
第3层:知识存储  
     磁盘上的SQLite     实际上无界  
     <50 ms    <1 ms    <5 ms  
图1:五层记忆层次结构。查询从顶部开始,仅按需向下访问。只有第1层token在查询之间变化。

### 2.1 第-1层:LoRA权重(可选)

对于可访问权重的自托管模型,可以通过免训练的低秩适配(LoRA)将领域专业知识直接嵌入模型的MLP权重矩阵。这一层消耗**零上下文token**:模型无需任何提示开销就能识别领域特定的模式、术语和推理策略。该层完全可选;没有它系统也能完整运行。第3节 (https://arxiv.org/html/2606.26105#S3)描述了构建过程。

当同一领域同时存在LoRA权重和知识树内容时,这两层是互补的:适配器提供模式级别的熟悉度,而树提供具体事实。

### 2.2 第0层:残差状态

系统提示、顶层树摘要和预计算指标在会话开始时组装一次,其KV缓存条目保留为稳定前缀。后续请求复用这些缓存的键值状态而无需重新计算,与每次请求重新编码系统提示相比,节省48%的内存。这利用了现有的KV缓存机制作为更广泛的上下文回收策略的一部分——贡献不在于KV复用本身,而在于将其集成到显式的上下文窗口生命周期管理中。

### 2.3 第1层:分支缓存

主动知识分支——与当前查询相关的树节点集合——被动态加载到上下文窗口中。分支切换耗时<50 ms。使用TQ3量化(3位KV缓存),16 GB VRAM预算可容纳约768K tokens的缓存知识(约600K单词)。这是唯一一个token数量在查询之间变化的层。

### 2.4 第2层:记忆索引

一个内存中的SQLite FTS5倒排索引使用BM25评分将关键词映射到树节点。每个术语的查找为O(1),无论索引大小如何,都在1 ms内完成。这是**路由**层:它决定加载哪个分支,而不消耗上下文token。

### 2.5 第3层:知识存储

永久存储是采用WAL(预写日志)模式的SQLite数据库,提供实际上无界的容量,在SSD上读取延迟<5 ms。所有树节点、文档、会话历史记录和缓存结果都驻留在此。数据库支持高达281 TB,FTS5索引开销约为索引文本大小的30%。

#### 关键洞察:

知识同时存在于三个层次:**模型权重中**(第-1层,零token,可选)、**主动上下文中**(第0–1层,固定预算下约3–12K tokens)和**磁盘上**(第2–3层,实际上无界)。只有第1层在查询之间变化;所有其他层要么稳定,要么充当路由索引。上下文窗口被视为一个固定的、可回收的执行资源——而不是随对话长度增长的缓冲区。

## 3 免训练LoRA构建(可选)

这个可选层探索了一种使用前向传播激活统计和线性代数来免训练构建LoRA适配器的方法,仅适用于自托管的开源权重模型。它**不是**本研究的主要贡献;没有它,上下文回收系统也能完整运行。我们包含此描述是因为该技术在我们的本地测试中提高了领域特定准确性,并且可能具有独立的研究价值。

该构建基于三个经验观察:

1. 1.**A矩阵实际上是随机的。**在标准LoRA训练中,下投影矩阵A从其随机初始化仅移动了7.6%。我们将A视为固定的随机投影基。
2. 2.**B矩阵包含知识信号。**领域特定文本与通用文本之间的激活差异捕捉了激活空间中“领域专业知识”的方向。SVD直接提取其秩r近似。
3. 3.**幅度可预测地缩放。**我们使用适配器幅度的经验默认先验\(\|B\| = \frac{\sqrt{d_{\text{hidden}}}}{30}\)(1),并在需要时通过对保留领域数据执行仅前向传播的困惑度扫描来细化它。

### 3.1 构建算法

给定领域文本语料库\(\mathcal{D}\)和通用参考语料库\(\mathcal{G}\),LoRA适配器构建如下:

算法1 免训练LoRA构建  
1: 领域语料库\(\mathcal{D}\),通用语料库\(\mathcal{G}\),秩\(r\)  
2: 每层的LoRA适配器\((A,B)\)  
3: for 每个Transformer层\(\ell\) do  
4: \(\mathbf{H}_{D}^{\ell} \leftarrow\) 在\(\mathcal{D}\)上约30次前向传播的激活  
5: \(\mathbf{H}_{G}^{\ell} \leftarrow\) 在\(\mathcal{G}\)上约25次前向传播的激活  
6: \(\Delta^{\ell} \leftarrow \mathbf{H}_{D}^{\ell} - \mathbf{H}_{G}^{\ell}\) ⊳ 领域信号  
7: \(U, \Sigma, V^{T} \leftarrow \text{SVD}(\Delta^{\ell})\)  
8: \(A^{\ell} \leftarrow V^{T}_{:r}\) ⊳ 类随机投影  
9: \(B^{\ell} \leftarrow U_{:r} \cdot \Sigma_{:r}\) ⊳ 知识方向  
10: 缩放\(B^{\ell}\):\(\|B^{\ell}\| = \sqrt{d_{\text{hidden}}}/30\)  
11: end for  
12: 打包为标准PEFT适配器

整个过程仅需要前向(推理)传播——无需反向传播、梯度计算或GPU。在CPU上构建完成约需200秒。

### 3.2 验证

表1 (https://arxiv.org/html/2606.26105#S3.T1) 将免训练方法与传统的GPU训练LoRA在医学问答基准上进行了比较。

表1:LoRA构建方法在医学QA准确率上的比较。在我们的内部评估设置中,免训练构建在医学QA任务上匹配或略微超过GPU训练的LoRA(表1 (https://arxiv.org/html/2606.26105#S3.T1));我们不一般性地声称这在所有领域或基准上都成立。

#### 范围和限制:

这一层仅适用于可直接访问权重的自托管模型。云API提供商(OpenAI、Anthropic)不暴露模型权重,因此无法支持适配器注入。验证在本地部署配置中的8个开源权重模型家族(Qwen、Llama、Mistral、Phi、Gemma、DeepSeek、Yi、InternLM)上进行。医学QA基准使用了精心策划的评估集;在标准化基准(如MedQA、USMLE)上以及企业规模下的进一步独立验证将加强这些发现。

### 3.3 领域覆盖

系统维护超过20个领域适配器(编程、医学、数学、工程、AI/ML、物理学、生物学、创意艺术、游戏开发、机器人学、电子学等),涵盖多种模型大小层级。适配器通过PEFT在推理时动态加载——无需重启模型。一个轻量级领域路由器对每个传入消息进行分类,并透明地激活适当的适配器。

### 3.4 查询处理流程

图2 (https://arxiv.org/html/2606.26105#S3.F2) 说明了一个用户查询通过五层层次结构的端到端路径。该图应从上往下阅读:每个查询被路由、组装、用于生成,然后在下一次轮次之前释放。

用户消息  
↓  
关键词提取(去除停用词,约0 ms)  
↓  
BM25索引查找(L2)FTS5倒排索引,<1 ms  
↓  
L1缓存命中?  
├─ 是 → 直接使用  
└─ 否 → 分支加载(从L3,2–4秒冷启动)  
↓  
上下文组装(L0 + L1 + 历史 + 消息)  
↓  
LoRA激活(L-1)领域适配器,0 tokens  
↓  
LLM生成  
↓  
上下文回收(释放分支token)  
↓  
返回给用户的响应  

图2:通过五层层次结构的查询处理流程。每个查询经历关键词提取、索引查找、缓存解析、带LoRA激活的上下文组装、LLM生成和上下文回收。

## 4 上下文回收

本工作的核心贡献是将上下文窗口视为一个固定预算、可回收的工作空间,而不是一次性缓冲区。传统的LLM部署将上下文填满历史和知识,生成响应,然后在下次调用时要么丢弃一切,要么重新打包。本文描述的系统将上下文窗口视为**可复用的执行资源**——类似于虚拟内存中的工作集,页框按需加载、使用,并在固定物理内存预算下被驱逐。

### 4.1 机制

在每个轮次:

1. 主动加载器通过BM25索引(第2层)识别最相关的知识分支。
2. 分支内容被加载到上下文窗口(第1层)。
3. LLM使用组装的上下文生成响应。
4. 分支被**释放**——其token从主动上下文中释放。
5. 下一个查询可以使用相同的token预算加载完全不同的分支。

### 4.2 有界主动上下文

表2 (https://arxiv.org/html/2606.26105#S4.T2) 显示了主动上下文如何保持有界,无论对话长度如何。

相似文章

内存

Reddit r/artificial

解释了为什么由于KV缓存随上下文长度和并发用户数扩展,LLM推理越来越受内存带宽限制,以及像vLLM和PagedAttention这样的系统如何提高内存利用率。