长时段LLM智能体服务的并行上下文压缩

# 针对长 horizon LLM 智能体服务的并行上下文压缩

**来源:** https://arxiv.org/html/2605.23296 – \\IEEEauthorblockNMusa Cim, Burak Topcu, Chita Das, Mahmut Kandemir\\IEEEauthorblockAThe Pennsylvania State University \{mtc5693, bvt5283, cxd12, mtk2\}@psu\.edu

###### 摘要

长 horizon LLM 智能体在运行过程中会积累不断增长的对话历史，最终超出模型的上下文窗口。通过基于 LLM 的摘要进行上下文压缩可将对话限定在可控范围内，但摘要本质上有信息损失，且阻塞调用会使智能体推理停滞数十秒。此外，由于提示指令在很大程度上被忽略，操作员无法对摘要体积进行细粒度控制；随着上下文增长，模型生成的输出 token 数量及其保留的信息量在不同运行间波动显著，使得智能体保留的知识不可预测。我们针对长 horizon 智能体流程引入了**并行压缩**，并与顺序同步基线进行了对比，使用了四种从 8B 到 120B 参数规模的后端模型，混合了密集型和 MoE 架构以及推理型和非推理型模型，在 HotpotQA 多跳 QA 和 LoCoMo 长上下文对话基准上进行测试。并行压缩赋予操作员对摘要体积的细粒度、可预测控制，并支持对每个块进行更精准的提示工程。在匹配的压缩解码体积下，它相比顺序基线减少了端到端耗时，并提高了压缩吞吐量。

## 1 引言

大型语言模型（LLM）智能体越来越多地部署在长 horizon 场景中，例如在单个会话中处理多个任务：基于累积证据的多跳问答、带工具使用的智能体代码编辑、以及多会话对话。在每种场景中，对话历史随每次交互增长，引发多个实际问题：每 token 延迟随序列长度增加；对话最终超出模型的上下文窗口；且在该窗口达到之前，推理质量就已下降，因为模型被迫关注越来越长且信号稀薄的历史记录。摘要这一自然补救手段也有其局限性：随着上下文增长，模型难以生成长度和内容可预测的摘要。上下文压缩定期将对话历史总结为更短的表示形式，使智能体在处理更多任务时上下文保持可界定。生产系统如 Anthropic 的 Claude Code\[anthropic2025claudecode\] 和 OpenAI 的 Codex\[openai2025codex\]，以及广泛使用的框架如 LangChain\[langchain\] 和 LlamaIndex\[llamaindex\]，在接近窗口限制时依赖 LLM 摘要调用来压缩上下文。这种压缩通常以同步方式进行，由于摘要本质上比原始内容短，信息必然有损失：上下文在 token 数上被缩减 90–99%，但模型决定保留什么、丢弃什么，且无法保证不同运行间的一致性。在交互式场景如 CLI 编码智能体中，信息损失尤其有害：压缩过于激进，使得最近上下文（包含智能体刚刚积累的洞见）与其他内容一起被大幅压缩，迫使智能体在后续轮次中重新发现并重建该上下文，代价是额外的 token 和时间。

当前的前沿模型支持 100k 到 1M token 的上下文窗口（大约 150–2500 页密集文本 PDF）。然而，将这么多材料一次性输入单个推理调用，在大多数用例上收益递减：众所周知的限制如“中间迷失”\[liu2024lost\] 和“上下文腐烂”\[hong2025contextrot\] 表明 LLM 难以关注长而信号稀薄的历史记录，同样的限制也适用于摘要过程；例如，要求模型压缩 96k token 上下文的调用，模型对整个历史关注不佳，产生短且不一致的摘要。在长 horizon 多轮智能体流程中，上下文压缩的摘要体积、信息保留以及延迟成本尚未被系统性地表征——无论是针对朴素的顺序基线还是并行方法。我们的贡献如下：

1. **压缩行为的表征。** 我们通过实验证明，在四种从 8B 到 120B 参数规模的后端模型上，摘要输出体积基本上与输入和提示无关。当输入从 2k 增长到 96k token 时，输出仅增长约 3 倍；将指令从“简洁”改为“非常详细”几乎不影响输出。此外，在较长的上下文下，摘要长度和内容都变得不稳定，使得智能体面临的信息损失不可预测。
2. **并行压缩的设计与表征。** 我们引入并行压缩，这是一种基于块的设计，通过块计数给予操作员对摘要体积的直接、细粒度控制，并在 HotpotQA 和 LoCoMo 上使用四种后端模型，针对顺序基线进行表征，报告端到端耗时、压缩吞吐量以及从 16k 到 2k token 的块大小扫描下的摘要体积。

## 2 背景与动机

### 2.1 长 horizon LLM 智能体

我们考虑一个在单个对话会话中处理一系列任务 \((q_1, q_2, ..., q)\) 的 LLM 智能体。在时间步 \(t\)，智能体接收任务 \(q_t\)，并将其附加到累积的对话历史 \(\mathcal{H}_t = [s, u_1, a_1, ..., u_{t-1}, a_{t-1}]\) 中，其中 \(s\) 是系统提示，\(u_i\) 是第 \(i\) 条用户消息（包括支持上下文），\(a_i\) 是相应的模型回复。随着处理更多任务，增长的上下文长度提高了每 token 的解码成本。

### 2.2 上下文压缩

当上下文长度超过阈值 \(\tau\) 时，压缩将对话历史总结为更短的表示形式：

\[\hat{\mathcal{H}}_t = \text{LLM}_{\text{compact}}(\mathcal{H}_t \oplus p_c) \quad (1)\]

其中 \(p_c\) 是一条压缩指令提示。智能体会阻塞直至摘要生成，之后压缩后的摘要替换对话历史。阈值 \(\tau\) 的选择构成了一个基本权衡：较低的阈值保持较小的上下文，但会带来更多阻塞开销并存在信息丢失风险；较高的阈值保留更多上下文，但允许延迟增长。

### 2.3 动机测量

在引入并行压缩之前，我们展示了一些动机测量，以表征顺序压缩的基本局限——为什么提示工程和输入长度本身无法控制摘要体积，以及同步压缩带来了多大的耗时开销，从而激发了采用不同方法的必要性。

#### 2.3.1 摘要输出与输入无关

我们测量了输入长度是否能够控制摘要体积。在四种后端模型上，针对 HotpotQA 和 LoCoMo，输入长度增长 48 倍（2k → 96k），而平均输出仅增长约 3 倍（表 1 (https://arxiv.org/html/2605.23296#S2.T1)）。

**表 1:** 平均摘要输出 vs. 输入长度。输出在输入增长时几乎保持不变。

**要点 #1：** 当输入长度从 2k 增长到 96k token（48 倍）时，摘要输出仅增长约 3 倍：模型自我限制其输出，无论接收多少上下文。

#### 2.3.2 压缩主导智能体耗时

为了量化同步压缩的成本，我们在不同的上下文阈值下端到端运行智能体流程，并测量总耗时中有多少花在压缩调用上。表 2 (https://arxiv.org/html/2605.23296#S2.T2) 显示，在低阈值下，同步压缩主导了耗时，在 HotpotQA 上消耗高达 62% 的总执行时间，即使在较高阈值下也仍然显著。开销随频率叠加：在 \(\tau=16\)k 时，每次运行压缩触发 15 次，每次都是完全停滞；而在 \(\tau=96\)k 时，仅发生 2 次压缩，但每次处理更长的上下文。因此，减少每次调用的延迟是提高端到端吞吐量的主要杠杆。

**表 2:** 压缩占端到端耗时的比例 vs. 阈值。

**要点 #2：** 同步压缩可能成为长 horizon 智能体流程中的瓶颈，消耗端到端耗时的相当大一部分。

## 3 实验方法

### 3.1 基准测试

我们评估两个智能体流程基准测试。**HotpotQA**\[yang2018hotpotqa\] 是一个基于 Wikipedia 的多跳 QA 数据集。**LoCoMo**\[maharana2024evaluating\] 提供长时间多会话对话，每个会话包含多个 QA，采用多项选择题格式\[percena\_locomo\_mc10\]。我们一次提供一个文档，并在阅读后立即提问，因此对话像长 horizon 智能体的历史那样累积。对于每个问题，后端 LLM 生成自由形式的答案，由 Qwen3-30B 作为独立的 LLM 评审器，使用评分模板进行评判，以确定性的方式进行，且对模型自身不可见，以避免自我偏好偏差。LLM 评估者往往偏爱自己的输出\[panickssery2024llm, xu2024pride\]，因此使用与后端（GPT 和 Llama）不同模型系列的评审器可确保更公平的评估。

**表 3:** 基准测试统计。

请参考图注。

**图 1:** 顺序压缩与并行压缩概览。

## 4 并行压缩

当对话长度超过压缩阈值 \(\tau\) 时，并行压缩经历三个阶段（图 1 (https://arxiv.org/html/2605.23296#S3.F1)）：

1. **快照与分区。** 复制当前对话 \(X\)，记录其长度，并将其划分为连续块，每个块大小为 \(B\) 个 token，其中 \(N = \lceil |X| / B \rceil\)，且 \(B\) 是固定的配置旋钮。
2. **分发。** 对于每个块 \(k \in \{1, ..., N\}\)，构建一个提示，依次包含块 1 到 \(k\)，其中块 \(k\) 被包裹在 `<target> ... </target>` 标记中。所有提示同时分发给 vLLM 服务器。
3. **合并。** 当所有工作线程完成后，按块顺序拼接每个块的摘要，形成压缩后的历史 \(\hat{\mathcal{H}}_t\)，替换原始快照。

**前缀感知的目标在尾部布局。** 存在两种自然的替代方案：仅向每个工作线程提供其块（独立块），或向每个工作线程提供整个快照并附带一个特定于工作线程的标记（共享完整前缀）。独立块会破坏前缀缓存并丢失跨块上下文；共享完整前缀也会破坏它，因为每个工作线程的标记落在不同的偏移位置。前缀感知的目标在尾部布局是一个折中方案：目标块位于可见提示的末尾，即注意力最强的地方；每个工作线程的前缀严格扩展前一个工作线程的前缀，从而保留缓存；同时，由于每个工作线程看到其块之前的完整对话历史，跨块上下文得以维持。这天然适合智能体流程，其中对话按时间顺序从左到右构建，因此前缀总是反映上下文累积的因果顺序。

### 4.1 模型

我们评估四种后端模型，以覆盖生产部署中最相关的规模：**Llama-3.1-8B**（小型密集型）、**gpt-oss-20B**（中型 MoE 推理型）、**Llama-3.3-70B**（大型密集型）和 **gpt-oss-120B**（大型 MoE 推理型）。这四种模型涵盖了小型/大型、密集型/MoE、推理型/非推理型架构。表 4 (https://arxiv.org/html/2605.23296#S4.T4) 列出了每个模型的类型、推理能力、上下文窗口和 GPU 配置。该选择还涵盖了实际成本范围，从大多数从业者可访问的单 GPU 部署到代表前沿服务成本的大型 MoE 模型。

**表 4:** 实验中使用的模型。

### 4.2 硬件与推理基础设施

所有实验均使用启用前缀缓存和分块预填充的 vLLM。Llama-3.1-8B 和 gpt-oss-20B 在单个 H100 上以 TP=1 提供服务；gpt-oss-120B 在单个 H100 上以 TP=1 且使用 mxfp4 权重提供服务；Llama-3.3-70B 需要跨一个 H100 NVL 对以 TP=2 提供服务。每次测量在专用 GPU（或 NVLink 对）上运行，无其他工作负载共享设备。

请参考图注。

**(a) HotpotQA**

请参考图注。

**(b) LoCoMo**

**图 2:** 在顺序压缩下，三种提示变体和四种后端模型的输出 token 数 vs. 输入长度。

## 5 表征顺序压缩

顺序压缩在上下文超过阈值 \(\tau\) 时，对整个对话快照发起一次阻塞摘要调用。我们沿着两个轴表征该基线：输出体积缩放（测量模型在输入增长和提示变化时产生多少输出）以及运行间稳定性（测量在相同输入下多次调用中输出的稳定性）。

### 5.1 提示与输入无关性

图 2 (https://arxiv.org/html/2605.23296#S4.F2) 绘制了四种后端模型在 HotpotQA (a) 和 LoCoMo (b) 上，三种提示变体下的摘要输出 token 数与输入长度的关系。两个模式主导。首先，四种后端模型在从 2k 到 96k 的完整输入扫描中，输出 token 数均处于狭窄范围内，远未达到输入长度增长 48 倍所暗示的幅度。其次，将提示从“简洁”改为“非常详细”几乎不影响曲线。该行为在密集型和 MoE 架构上一致，在推理型和非推理型模型上，在两个基准测试中也一致。Llama-3.3-70B 在相同输入长度下倾向于产生比其它后端模型更大的输出，但其行为在多次运行中非确定性的，使得其输出体积更难预测。操作员没有有效的提示侧旋钮来随着对话变长而增加摘要体积。

实际操作后果是，顺序压缩随着上下文增长逐渐丢弃越来越多的对话内容：在 2k 输入时，模型在摘要中保留约 48% 的 token，但在 96k 时，该比例降至约 3%。

**要点 #3：** 改变提示对输出长度没有显著影响：模型在很大程度上忽略长度指令，并自我限制其输出，无论提示要求简洁还是非常详细。