Akashic：一种基于MemAttention的低开销LLM推理服务

# Akashic：基于 MemAttention 的低开销 LLM 推理服务

来源：https://arxiv.org/html/2607.05708

杨 刘\\ast†罗 昭凯\\ast†胡 佳宜†何 若舟†洪 晨晨†王 志勇†  
刘 一飞¶顾 云飞¶吴 辰涛¶胡 俊浩§  
†小红书股份有限公司，中国  
¶上海交通大学  
§北京大学  
\\ast通讯作者：罗昭凯[](https://arxiv.org/html/2607.05708v1/mailto:[email protected])

###### 摘要。近年来基于 LLM 的智能体系统在多轮交互、工具调用和跨会话工作流中不断累积上下文。为每个请求重放完整历史很快变得不切实际：长上下文会增加预填充开销，可能超出上下文长度限制，并且常常将任务相关证据淹没在无关内容中，从而降低服务效率和输出质量。我们提出 Akashic，一种围绕 MemAttention 构建的低开销内存系统，它将上下文组织为有界块并建模跨块的语义关系，在无需反复重写完整历史的情况下保留跨块证据。Akashic 进一步应用软硬件协同设计的内存放置策略，将可能被同时检索的块共置，从而减少检索碎片化和 I/O 开销。在四个代表性工作负载和三种模型规模下，与强基线内存方法相比，Akashic 将任务准确率提升高达 10.2 个百分点，吞吐量提升高达 1.21 倍，可持续请求率提升高达 1.88 倍。

††版权：无

## 1. 引言

参考图 1。\(a\) 现有内存设计在任务质量与服务效率的权衡中占据不同位置，而 Akashic 瞄准高质量、高效率区域。\(b\) 在基于 OPT-30B 的 BrowseComp 上，Akashic 在准确率和吞吐量两方面均优于所有基线，比最强先前方法在准确率上提升约 2.0 个百分点，吞吐量提升约 1.35 倍。

近年来，智能体系统在多轮交互、工具调用和跨会话执行中不断累积输入上下文，这种不断增长的上下文会显著降低模型吞吐量和输出质量（Fan 等，2023（https://arxiv.org/html/2607.05708#bib.bib48）；Chen 等，2021a（https://arxiv.org/html/2607.05708#bib.bib106）；Github，2022（https://arxiv.org/html/2607.05708#bib.bib75）；Maharana 等，2024（https://arxiv.org/html/2607.05708#bib.bib14）；Packer 等，2023（https://arxiv.org/html/2607.05708#bib.bib16）；Cobbe 等，2021（https://arxiv.org/html/2607.05708#bib.bib49）；Wei 等，2022（https://arxiv.org/html/2607.05708#bib.bib50））。一种直接的解决方案是将完整的交互历史输入每个请求，但这种方法很快变得不切实际：长提示会增加预填充开销，可能超出上下文限制，并且常常将任务相关证据淹没在无关上下文中，损害服务效率和输出质量（Liu 等，2024（https://arxiv.org/html/2607.05708#bib.bib37）；Shaham 等，2023（https://arxiv.org/html/2607.05708#bib.bib41））。因此，现代智能体系统越来越多地维护外部内存，并在推理时仅重新注入部分先前上下文（Packer 等，2023（https://arxiv.org/html/2607.05708#bib.bib16）；Chhikara 等，2025（https://arxiv.org/html/2607.05708#bib.bib17）；Anthropic，2025（https://arxiv.org/html/2607.05708#bib.bib51））。构建此类内存的一种常见方式是*摘要*：一旦累积历史超过阈值，系统将较旧的上下文压缩为较短的表示，并在未来的请求中使用该表示（16（https://arxiv.org/html/2607.05708#bib.bib43）；19（https://arxiv.org/html/2607.05708#bib.bib44））。然而，现有的基于摘要的设计存在粒度权衡问题。*全上下文*方法（如 Mem0）在每个触发点对整个历史进行摘要（Chhikara 等，2025（https://arxiv.org/html/2607.05708#bib.bib17））。它们实现简单，但更新成本随历史长度增长，且无关主题被混合到一个内存对象中，可能在检索时引入噪声。*片段级*方法（如 MemGAS）独立地对较小的单元进行摘要（Xu 等，2025a（https://arxiv.org/html/2607.05708#bib.bib20））。它们限制了每次更新的成本，但语义相关的证据可能被分割到不同片段中，无法一起恢复，从而削弱了多轮和长距离推理能力。在实际的 LLM 服务中，解决这一权衡需要应对两个关键挑战。首先，上下文信息密度在不同工作负载间甚至在同一交互的不同阶段高度不均匀（§3.1（https://arxiv.org/html/2607.05708#S3.SS1））：某些跨度高度可压缩，而另一些则密集且压缩成本高昂。因此，固定的全局压缩策略通常与实际工作负载不匹配。其次，智能体内存不仅是语义对象，也是存储对象。即使检索只选择了少数相关记忆，如果这些记忆在物理上分散在许多页面或块中，端到端延迟仍可能很高。我们将这种语义相关性与物理放置之间的不匹配称为*局部性差距*（§3.2（https://arxiv.org/html/2607.05708#S3.SS2））。

我们提出**Akashic**，一种用于 LLM 服务的低开销内存系统，通过 MemAttention 和软硬件协同设计的内存放置优化来解决这些挑战。Akashic 执行*块粒度*内存维护：它每次压缩一个有界块，而不是反复重写完整历史。为了保留跨块证据，Akashic 使用*跨块推理*将每个新块与少量语义相关的先前块进行协调，然后再将结果写回内存。这种设计在保留信息（否则会因独立片段摘要而碎片化）的同时，限制了维护开销（§4.1（https://arxiv.org/html/2607.05708#S4.SS1））。Akashic 还包含一个*软硬件协同优化的内存管理器*，它将可能被同时检索的块共置，并将过时数据异地压缩，从而减少并发服务期间的读放大和检索端竞争（§4.2（https://arxiv.org/html/2607.05708#S4.SS2））。

我们在四个具有不同工作负载特征的基准测试上评估了 Akashic——LoCoMo（Maharana 等，2024（https://arxiv.org/html/2607.05708#bib.bib14））、SWE-bench（Jimenez 等，2024（https://arxiv.org/html/2607.05708#bib.bib12））、BrowseComp（Wei 等，2025（https://arxiv.org/html/2607.05708#bib.bib15））和 WebArena（Zhou 等，2024（https://arxiv.org/html/2607.05708#bib.bib13））——使用了不同规模的模型。如图 1（https://arxiv.org/html/2607.05708#S1.F1）\(a\) 所示，Akashic 在服务效率和任务质量两方面均一致优于先前的基线。图 1（https://arxiv.org/html/2607.05708#S1.F1）\(b\) 通过一个代表性示例进一步说明了这一优势，其中 Akashic 在准确率和吞吐量上都大幅优于现有方法（§5（https://arxiv.org/html/2607.05708#S5））。Akashic 始终处于*帕累托前沿*，在相同实验设置下，与最强内存基线相比，任务准确率提升高达 10.2 个百分点，吞吐量提升高达 1.21 倍，同时在并发服务下可持续支持高达 1.88 倍的请求率。

我们将继续在更新模型和数据集上更新 Akashic。后续代码将合并到 RedKnot 框架的分支中（Yang, Liu 等，2026（https://arxiv.org/html/2607.05708#bib.bib1））。开源地址为：https://github.com/rednote-machine-learning/RedKnot。

* • 我们表征了智能体内存中的两个关键瓶颈：固定摘要策略与异构上下文密度之间的不匹配，以及语义相关性与物理放置之间的局部性差距。
* • 我们设计了 **MemAttention**，一种块粒度的内存维护机制，它将每个新块与少量语义相关的先前块进行协调，在限制维护开销的同时保留跨块证据。
* • 我们提出并实现了一个**软硬件协同设计的内存管理器**，通过将可能被同时检索的块共置并压缩过时数据来减少 LLM 服务中的内存碎片化，从而降低检索 I/O 和竞争。
* • 我们实现了 Akashic 并在四个代表性工作负载上进行了评估，结果表明，与最强先前内存基线相比，准确率提升高达 10.2 个百分点，吞吐量提升高达 1.21 倍，可持续请求率提升高达 1.88 倍。

## 2. 背景

### 2.1. 长上下文作为首要瓶颈

现代智能体应用（例如多轮助手、工具增强规划器和长期运行的工作流）自然随时间累积对话状态，将输入上下文推向模型的最大上下文窗口。尽管近期前沿模型已大幅扩展其标称上下文限制（达到百万 token 级别），但长上下文请求在延迟和计算上仍然昂贵：例如，OpenAI 报告称，即使使用优化的推理栈，首 token 生成时间（TTFT）可能从约 128K token 时的几秒增加到约 1M token 时的大约一分钟（OpenAI，2025（https://arxiv.org/html/2607.05708#bib.bib45），https://arxiv.org/html/2607.05708#bib.bib46）。除了最大窗口的硬限制外，更长的上下文还会降低*有效任务准确率*。经验上，LLM 在长提示中间出现相关证据时会表现出强烈的注意力偏差：性能可能呈现独特的 U 形曲线，当承载答案的内容位于上下文中间时急剧下降（Liu 等，2024（https://arxiv.org/html/2607.05708#bib.bib37））。后续工作表明，即使使用长上下文模型变体，稳健的中间上下文利用仍然具有挑战性，这激发了位置编码和长上下文评估方面的努力（Zhang 等，2024（https://arxiv.org/html/2607.05708#bib.bib38）；Shaham 等，2023（https://arxiv.org/html/2607.05708#bib.bib41））。特别地，对于长期对话，诸如 LoCoMo 等基准测试表明，非常长的多会话对话会放大时间和因果推理失败，并且长上下文或检索增强方法仍然远远落后于人类水平的一致性（Maharana 等，2024（https://arxiv.org/html/2607.05708#bib.bib14））。

在 LLM 推理服务期间，长上下文请求之所以昂贵，主要是因为 Transformer 必须对整个提示执行完整的*预填充*过程，以构建每层激活并填充 KV 缓存，这会产生大量的计算和内存流量。在系统层面，这种预填充成本随序列长度快速增长：标准 Transformer 注意力在提示长度上表现出二次计算和内存扩展（Vaswani 等，2017（https://arxiv.org/html/2607.05708#bib.bib54）），即使精确的注意力实现也需要 IO 感知的内核设计，以防止内存带宽成为主要的性能限制因素（Dao 等，2022（https://arxiv.org/html/2607.05708#bib.bib102））。这些约束与智能体内存紧密相关。

### 2.2. 实际中的内存压缩与检索

为了应对有界窗口和长上下文退化，常见的智能体框架（如 Mem0（Chhikara 等，2025（https://arxiv.org/html/2607.05708#bib.bib17））、RMM（Tan 等，2025（https://arxiv.org/html/2607.05708#bib.bib19））和 SeCom（Pan 等，2025（https://arxiv.org/html/2607.05708#bib.bib18）））采用*压缩*（摘要）和*选择性检索*。一种代表性模式维护一个*运行摘要*，该摘要每轮（或达到 token 阈值时）增量更新，并且仅将摘要（可选加上短期的最近缓冲区）注入未来的提示；这种模式已被广泛使用的框架抽象明确实现。补充地，基于检索的内存将过去消息（或派生事实）存储在向量索引中，并检索一小组语义相关的项目来调节模型，这减少了提示长度，但引入了检索和整合的挑战。这种端到端的内存压缩、向量数据库存储和推理时检索流程构成了现代 LLM 智能体中的*内存工作流*。

最近的开源系统将内存提升到受操作系统启发的层次结构。MemGPT 提出了*虚拟上下文管理*，并在上下文工作内存和外部存储之间分页信息，使得长期运行的智能体能够超越固定上下文限制（Packer 等，2023（https://arxiv.org/html/2607.05708#bib.bib16））。工业界和开源的内存层（如 Mem0）同样强调将历史压缩为紧凑的内存表示，并为每个用户查询仅检索少量相关内存项（21（https://arxiv.org/html/2607.05708#bib.bib42））。工具生态系统（如 LlamaIndex）越来越多地暴露可配置的内存模块，这些模块将 FIFO 短期缓冲区与可定制的长期内存块（用于提取和重新注入）相结合（19（https://arxiv.org/html/2607.05708#bib.bib44））。总体而言，现有实践收敛于一种权衡：频繁摘要提高了有界性，但消耗了额外的模型调用，而不频繁摘要则面临窗口溢出和准确率下降的风险——这种紧张关系促使我们寻求更可控、更细粒度且更易更新的内存组织方式。

## 3. LLM 服务中的内存挑战

参考图 2。上下文信息密度在不同数据集和不同时间点差异很大。\(a\) 与 LoCoMo 相比，SWE-Bench 表现出更高的保留率。\(b\) BrowseComp 和 WebArena 在轨迹内显示出突发性和交替性的保留率。

### 3.1. 异构上下文密度下的内存低效

**非均匀的上下文信息密度。** 从长输入上下文中提取有效信息本身就是一个推理过程。在 LLM 系统能够从压缩的内存表示中受益之前，它必须首先识别原始上下文中的哪些部分是显著的，而这一步会消耗额外的计算。令 \(L_{\mathrm{raw}}\) 表示原始上下文的 token 长度，\(L_{\mathrm{eff}}\) 表示内存构建或压缩后保留的有效信息的 token 长度。我们将*保留率*定义为：

\[
\rho = \frac{L_{\mathrm{eff}}}{L_{\mathrm{raw}}}.
\]

较小的 \(\rho\) 表示上下文高度可压缩，而较大的 \(\rho\) 表示大多数 token 都承载信息，因此难以压缩。如图 2（https://arxiv.org/html/2607.05708#S3.F2）所示，上下文信息密度高度不均匀，无论是在不同数据集之间还是在同一工作负载的不同时间点。图 2（https://arxiv.org/html/2607.05708#S3.F2）\(a\) 显示了清晰的数据集间对比：LoCoMo 的保留率远低于 SWE-Bench，表明其长对话历史包含大量冗余，因此更适合传统的基于压缩的内存策略。相比之下，SWE-Bench 的保留率始终较高，表明大多数 token 都承载信息，这在代码调试和仓库级推理中很常见。在这种高密度工作负载中，压缩仍然会触发额外的推理步骤（用于摘要或内存构建），但只能带来有限的提示长度缩减。因此，内存维护可能引入额外开销，而无法有意义地缩短上下文，从而减少甚至抵消端到端的系统效益。图 2（https://arxiv.org/html/2607.05708#S3.F2）