SideQuest: Model-Driven KV Cache Management for Long-Horizon Agentic Reasoning #

§1 TL;DR #

SideQuest replaces heuristic KV cache eviction with a parallel auxiliary LRM thread that semantically reasons about stale tool responses and issues structured deletion commands, achieving 56–65% peak token reduction on agentic benchmarks (FRAMES, BrowseComp) with ≤5% accuracy loss, trained on only 215 hindsight-annotated traces.

§2 核心问题 Q1 / Q2 / Q3 #

Q1 痛点：多轮 agent 工作负载中 KV cache 线性膨胀，启发式剪枝导致灾难性失败 #

在 ReAct 框架下的 deep research / coding agent 等长任务中，每轮 tool call 的返回（网页内容、搜索结果等）持续追加到上下文，KV cache 线性增长。这带来两个瓶颈：(1) GPU 显存占用挤压 batch size，降低并发；(2) attention 计算变为 memory-bandwidth bound。

现有启发式 KV 压缩方法（H₂O、SnapKV、R-KV 等）基于累积 attention score 或 token 冗余度做静态重要性估计，设计目标是固定长文档的单轮查询场景。但 agentic 上下文中 token 重要性是非单调的——某个 tool response 在第 $t$ 轮看似无用，到第 $t+n$ 轮合成最终答案时可能重新变得关键（论文以 Cursor 0 vs Cursor 1 的"暂时无关后复活"为例说明）。启发式剪枝在此场景下不仅导致精度下降，更引发模型崩溃（non-completion rate 高达 60%+），产生不可解析的输出。

Q2 方法：LRM 自身作为 KV cache 垃圾回收器，并行辅助线程隔离管理 token #

SideQuest 的核心洞察：让大语言推理模型自身判断哪些 tool response 已过期，而非依赖注意力分数等代理指标。

具体机制分三部分：

1. 并行辅助线程架构：每隔 $K$ 轮 ReAct 迭代，在主线程共享的 KV cache 上 fork 出一个辅助线程。辅助线程以 Memory management mode 触发短语开头，对当前所有 open cursor 进行语义推理，输出 {del_cursors: [ids]} 结构化删除命令。主线程当前轮结束后同步执行 eviction。
1. 触发式导引 + 微调：通过拼接触发短语 + LoRA 微调，使模型在看到触发时切换到"记忆管理"输出分布，主线程行为不受影响。
1. 后见之明训练数据合成：在正确推理 trace 上计算每个 cursor 的 last-use index，按固定间隔生成辅助标注；联合损失 $\mathcal{L} = \mathcal{L}_{\text{CE}}(\mathcal{D}_{\text{aux}}) + \lambda \mathcal{L}_{\text{distill}}(\mathcal{D}_{\text{main}})$，其中 distillation loss 防止遗忘基础推理能力。仅需 215 条高质量 trace。

核心技术壁垒：将 KV cache eviction 重新构建为与主推理任务并行的辅助推理任务，使得 (a) 管理 token 不污染主上下文窗口，(b) eviction 决策具有语义理解而非仅依赖统计代理，(c) 架构可组合——可部署在 RLM / Context Fold 等分层 agent 的子任务内部。这一 framing 需要同时解决共享 KV cache 的异步同步、触发式模式切换、以及极少样本下不破坏原有能力的微调，三者缺一不可。

Q3 结果 #

指标	数值	条件
Peak token 降幅	56–65%	vs uncompressed baseline, FRAMES + BrowseComp
KV cache reads 降幅	53–71%	vs uncompressed baseline
精度损失	~2% (FRAMES), ~5% (BrowseComp)	vs uncompressed baseline
Non-completion rate	近零 (≈baseline)	vs heuristic baselines 20–60%+
SGLang 峰值吞吐	1523 tok/s (+83.9%)	vs 828 tok/s baseline, H100 单卡
峰值 KV cache 占用	0.450 (−53.9%)	vs 0.977 baseline (normalized)
端到端运行时间	1489s (−36.8%)	vs 2356s baseline, FRAMES benchmark
训练样本量	215	LoRA fine-tuning on gpt-oss-20b

§3 架构 / 方法图 #



Paper's Figure 1, verbatim (caption: "Walkthrough example of SideQuest. (a) The main thread processes the user request by performing multi-turn reasoning and tool calling. (b) At regular intervals we spawn an auxiliary thread that runs in parallel with the shared context (c) The auxiliary thread reflects on the context and lists the cursors that can be deleted. (d) We clear the messages in the context by invoking a tool, reducing the context size for future turns.").

Figure 1 展示了 SideQuest 的四阶段工作流：主线程在 ReAct 循环中交替进行推理和 tool call (a)，每隔 $K$ 轮 fork 出辅助线程 (b)，辅助线程对所有 open cursor 进行语义分析判断哪些可删 (c)，等主线程当前轮完成后执行 KV cache 清理 (d)。关键设计点：辅助线程共享主线程的 KV cache，但其生成的管理 token 不合并回主上下文。

下面用状态图补充 Algorithm 1 的三阶段循环逻辑：

stateDiagram-v2 [*] --> MainReAct: 初始化 context C=[Q], t=0 state MainReAct { [*] --> Phase1_Eviction Phase1_Eviction: Phase 1: 检查辅助线程\n是否已完成 Phase1_Eviction --> ApplyEviction: S_thread.is_finished() Phase1_Eviction --> Phase2_Spawn: 无完成的辅助线程 ApplyEviction: 获取 Δ_ids\n执行 C.clear_kv(Δ_ids) ApplyEviction --> Phase2_Spawn Phase2_Spawn: Phase 2: 是否需要\n启动辅助线程? Phase2_Spawn --> SpawnAux: t mod K == 0 且无活跃线程 Phase2_Spawn --> Phase3_Execute: 否则跳过 SpawnAux: 拼接触发短语 p\nAsyncGenerate(M, C+p) SpawnAux --> Phase3_Execute Phase3_Execute: Phase 3: 主 ReAct 步\nR = M(C); C = C + R Phase3_Execute --> CheckDone CheckDone: R 含 Final Answer? } CheckDone --> [*]: 是 → 返回结果 CheckDone --> ToolExec: 否, R 含 Tool Call T ToolExec: 执行工具 O=Execute(T)\nC = C + O; t = t+1 ToolExec --> MainReAct

记忆模型：短期记忆 = KV cache 中的完整上下文窗口（主线程 + 辅助线程共享）；无显式长期记忆或向量数据库；辅助线程输出的删除命令是唯一的"记忆管理"通道。

错误恢复：如果辅助线程未完成（主线程先结束当前轮），则不执行 eviction，下一轮重新检查。同步策略保证 eviction 不会在主线程生成中途打断。

训练数据合成管线 #

训练管线（Algorithm 2）产生两类数据：

• Main traces：正确 ReAct trace + 基础策略 logits → distillation loss 保持原始能力
• Auxiliary traces：在正确 trace 的固定间隔点，通过 hindsight 计算 cursor 过期集合 → 随机分区为"已 evict"和"待判断" → 标注模型生成删除推理 → cross-entropy loss 教会 eviction

联合损失：$\mathcal{L} = \mathcal{L}_{\text{CE}}(\mathcal{D}_{\text{aux}}) + \lambda \mathcal{L}_{\text{distill}}(\mathcal{D}_{\text{main}})$

§4 作者证明 #

无形式化作者证明 — 仅实证。

论文不提供 eviction 正确性或推理保持的形式化保证。证明方式完全依赖经验评估。

符号表：

符号	含义
$Q$	用户 query
$\mathcal{M}$	推理模型 (gpt-oss-20b)
$K$	辅助线程触发间隔（每 $K$ 轮）
$p$	触发短语 Memory management mode
$\mathcal{C}$	当前上下文 token 序列
$\mathcal{S}_{\text{thread}}$	辅助线程句柄
$\Delta_{\text{ids}}$	待 evict 的 cursor ID 集合
$\ell_c$	cursor $c$ 的 last-use turn index
$\lambda$	distillation loss 权重

6 项经验检查：

1. Accuracy 保持：FRAMES 精度从 ~65% 降至 ~63%（−2%），BrowseComp 从 ~40% 降至 ~35%（−5%）——退化幅度小且可控。
2. Non-completion 控制：SideQuest 的 non-completion rate 与 uncompressed baseline 同量级（近零），而 H₂O/SnapKV/R-KV 在 16K/24K 缓存限制下达 20–60%+。
3. 效率增益单调性：KV cache reads 随 eviction 激进程度单调下降（53–71%），同时精度退化受控。
4. 泛化到 OOD：BrowseComp 是 out-of-distribution benchmark（训练在 FRAMES 类任务上），SideQuest 仍保持显著优于所有 heuristic baselines 的 Pareto 前沿位置。
5. 生产可用性：SGLang serving 实验展示真实 batch scheduling 下的端到端收益（吞吐 +83.9%，运行时 −36.8%）。
6. 极小数据需求：215 条训练 trace 足够，暗示 eviction 推理是模型已有能力的轻量释放（alignment tax 低）。

可形式化但未做的方向：可以对 eviction 策略建模为 MDP，证明在"cursor utility 可正确估计"假设下的 regret bound；也可分析辅助线程同步延迟（≥1 轮 lag）对理论最优 eviction timing 的影响。

Agent 特定验证 #

• 成功率模型：论文未提供 (task difficulty × planning depth × tool set × backbone) 的完整 sweep。仅有 medium/high reasoning effort 两个配置 × 2 benchmark × 5 方法的对比网格。
• 每轮延迟预算：辅助线程与主线程并行，理论上不增加关键路径延迟。但论文未量化辅助线程自身的 token 开销和 GPU 算力占用。
• 失败模式分类：Figure 4 显示三类失败——Unparsable Response（主导，因关键 token 被 evict）、Context Limit、Turn Limit。SideQuest 针对第一类（通过语义理解避免误删关键 token）。

§5 实验与数据 #

工作负载特征 #



Paper's Figure 2, verbatim (caption: "Distribution of ReAct Iterations and token count for FRAMES and BrowseComp with gpt-oss-20b (medium effort).").

Figure 2 揭示了 agentic workload 的规模：FRAMES 任务集中在 10–20 轮 ReAct 迭代、10K–40K token，而 BrowseComp 更重尾，部分任务超过 80 轮、120K token。这解释了 BrowseComp 上 heuristic 方法崩溃更严重的原因——更长的任务意味着更多的非单调 token utility 转折点，静态启发式更容易误判。

效率 vs 精度 Pareto 前沿 #



Paper's Figure 3, verbatim (caption: "Efficiency vs. Utility Trade-off. We evaluate Accuracy against Peak Token Usage and KV cache memory reads for gpt-oss-20b with Medium and High reasoning effort, on the FRAMES and BrowseComp benchmarks. The Uncompressed Baseline establishes the upper bound for accuracy but incurs the highest memory cost. SideQuest achieves substantial memory savings—reducing peak token usage by 56-65% compared to the baseline—while providing a better accuracy compared to heuristic based methods.").

Figure 3 是论文的核心结果。八个子图（2 benchmark × 2 effort × 2 metric）中，SideQuest（绿色星形）始终位于 Pareto 前沿的左上方：相比 uncompressed baseline（黑色方块），peak token usage 降低 56–65%，同时精度仅低 2–5%。关键观察：H₂O、SnapKV、R-KV 在类似压缩率下精度大幅低于 SideQuest，尤其在 BrowseComp (High) 上，heuristic 方法精度几乎腰斩。

非完成率——启发式方法的致命弱点 #



Paper's Figure 4, verbatim (caption: "Non-Completion Rate across benchmarks, categorized by failure type: Unparsable Responses (orange), Context Limits (green), and Turn Limits (purple). SideQuest demonstrates superior reliability, matching the near-zero failure rate of the uncompressed baseline, while other methods suffer from high rates of model collapse.").

Figure 4 揭示了一个比精度损失更严重的问题：heuristic eviction 在 agentic 设置下导致模型崩溃。BrowseComp (High) 上 H₂O (16K) 的 non-completion rate 超过 60%，几乎全是 Unparsable Response（橙色）。这说明关键 token 被 evict 后模型无法维持合法的 ReAct 格式输出。SideQuest 的 non-completion rate 与 uncompressed baseline 同量级，是其语义理解优势的最直接体现。

SGLang 生产 serving 性能 #



Paper's Figure 5, verbatim (caption: "Serving Performance in SGLang. We compare Sidequest against the uncompressed baseline for gpt-oss-20b (Medium Effort) on the FRAMES benchmark using a single NVIDIA H100 GPU.").

Figure 5 将 SideQuest 的 token 级收益转化为系统级指标。左图：SideQuest 在 batch size 36 时达到 1523 tok/s 峰值吞吐，而 baseline 在 batch size 24 时已因显存饱和而无法扩展（828 tok/s）。中图：归一化 KV cache 占用从 0.977 降至 0.450，释放的显存直接转化为更大 batch size。右图：端到端 benchmark 运行时间从 2356s 降至 1489s（−36.8%）。三者的因果链清晰：eviction → 显存释放 → 更大 batch → 更高吞吐 → 更短总时间。

辅助线程推理质量 #



Paper's Figure 7, verbatim (caption: "Examples of memory-management reasoning produced by SideQuest.").

Figure 7 展示三个辅助线程推理实例。模型能做出非平凡判断：例如中间的例子中，模型识别出 Cursor 0（搜索结果页）在 Cursor 1（具体电影页面，已包含发行年份）被获取后变得冗余，但保留 Cursor 2（选举结果查询）因其仍被后续推理需要。这种语义级的 stale/useful 判断是 attention score heuristic 无法做到的。

实验设置摘要 #

• 模型: gpt-oss-20b (21B total / 3.6B active params, MoE, MXFP4)
• Benchmark: FRAMES (424 samples, in-dist) + BrowseComp (500 samples, OOD)
• Baselines: H₂O (16K/24K), SnapKV (16K/24K), R-KV (16K/24K), uncompressed
• Training: LoRA, 215 traces, joint $\mathcal{L}_{\text{CE}} + \lambda \mathcal{L}_{\text{distill}}$
• Serving: SGLang on single NVIDIA H100

§6 论证链 #

步骤	论点	证据	依赖
1	Agentic workload 中 KV cache 线性增长是核心瓶颈	Fig 2: FRAMES/BrowseComp 任务 token count 分布长尾，部分超 120K	前提
2	现有 heuristic eviction 基于静态重要性估计，不适用于 token utility 非单调变化的 agentic 场景	Fig 4: heuristic baselines non-completion rate 高达 60%+，主要为 Unparsable Response	步骤 1
3	LRM 自身具有判断 tool response 语义有效性的能力	Fig 7: 辅助线程产生非平凡的 stale/useful 推理；仅 215 样本 LoRA 微调即可激活	步骤 2
4	并行辅助线程架构可隔离管理 token，避免主上下文污染和延迟增加	Algorithm 1: 辅助线程异步执行、主线程轮次结束后同步 evict；对比 sequential 方案的两个缺点	步骤 3
5	Hindsight 标注 + distillation 联合训练可用极少数据教会 eviction 而不破坏原有能力	FRAMES 精度仅降 ~2%（Fig 3）；non-completion rate 与 baseline 同量级（Fig 4）	步骤 3, 4
6	Token 级 eviction 收益可转化为系统级吞吐和延迟改善	Fig 5: SGLang 吞吐 +83.9%，运行时 −36.8%，KV 占用 −53.9%	步骤 5

论证链完全基于论文内部数据，因果方向：问题定义(1) → 现有方法失败(2) → 能力存在性(3) → 架构设计(4) → 训练可行性(5) → 系统收益(6)。

§7 实现 cross-reference #

[实现未公开]

论文未公开代码。以下为论文描述的关键实现细节：

核心技术壁垒实现要点：

并行辅助线程需要在 serving framework 层面支持 KV cache 的共享只读 fork。论文在 SGLang 上实现了这一机制——辅助线程与主线程共享同一份 KV cache tensor，辅助线程只读不写回主上下文。这要求 serving 框架支持：(a) 同一 request 内的多分支 generation；(b) 分支级别的 KV cache 引用计数管理（eviction 操作需要原子地从所有分支的视图中移除指定 cursor 的 KV entries）。

关键实现细节：

1. 触发短语的精确拼接：辅助线程的输入是 C_aux = C + p，其中 $p$ = Memory management mode 。这个短语必须在训练时保持一致，否则模型无法可靠切换到管理模式。训练数据中通过在每条 auxiliary trace 前统一 prepend 此短语来保证一致性。
1. 随机分区模拟已有 eviction：训练数据合成时（Algorithm 2 Line 16），过期 cursor 被随机分为"已 evict"和"待判断"两组，前者的 token 被 mask 掉。这模拟了推理过程中 SideQuest 已执行过若干轮 eviction 后的状态，使模型学会在部分上下文已缺失的条件下做出正确的 eviction 判断。这是一个容易遗漏但对鲁棒性至关重要的设计。

Agent 特定：工具与环境接口 #

• Tool catalog: 浏览器工具（搜索、打开网页），cursor 管理工具（del_cursors）
• Side effects: 搜索/浏览为只读；del_cursors 不可逆（KV cache 物理清除）
• Error surface: 论文未讨论工具失败时辅助线程的行为
• Environment: ReAct loop 内每轮是确定性的（给定上下文，模型输出确定）；但辅助线程的异步性引入了非确定性同步时序

Agent 特定：LLM backbone 要求 #

• 模型: gpt-oss-20b (21B total, 3.6B active, MoE, MXFP4)
• 最小模型规模: 未做 ablation，不确定是否适用于更小模型
• 必要能力: 长上下文、tool-call 格式、结构化输出（JSON deletion commands）、chain-of-thought
• Backbone 敏感性: 仅在 gpt-oss-20b 上测试，未验证 Llama/Qwen/Claude 等其他模型
• Serving 成本: 辅助线程每次生成 ~110–140 token 的管理推理（Fig 7），每 $K$ 轮触发一次

Agent 特定：评估 #

• Benchmarks: FRAMES (多跳推理, 6.4M Wikipedia 语料, 424 samples) + BrowseComp (导航查找, 100K 文档, 500 samples)
• Difficulty: FRAMES 偏简单/中等（多为 10–20 轮），BrowseComp 有重尾分布（部分 80+ 轮）
• Metric: Accuracy (task correctness) + Peak Token Usage + KV Cache Reads + Non-completion Rate + 系统吞吐
• Baselines: H₂O, SnapKV, R-KV (heuristic), uncompressed (upper bound)

Agent 特定：生产就绪度 #

• Sandboxing: 未讨论工具执行隔离
• Observability: Fig 7 展示辅助线程的推理 trace 可作为 eviction 决策的可解释日志
• 成本控制: 辅助线程的触发间隔 $K$ 是可调超参，控制管理开销与压缩力度的 trade-off
• 并发: SGLang 实验展示了 batch 级别的并发扩展能力（batch size 最大到 36）