L3 Synthesis: Continuum (2511.02230) — KV Cache TTL for Multi-Turn Agent Serving #

§1 相关论文 #

Continuum 处于 agent serving 系统优化 的核心地带——它解决的"多轮 tool call 间隙如何管理 KV cache"问题，是 2025–2026 年 agent 基础设施最密集的竞争区域。以下 8 篇论文从不同层次和角度与之关联：

KV cache 管理——直接竞品 #

• SAGA (2605.00528)：最直接的竞品。SAGA 将整个 agent workflow 建模为 Agent Execution Graph (AEG)，在 64-GPU 集群上实现 workflow-atomic 调度。二者共享"tool call 间隙的 KV cache 保留"这一核心问题，但 SAGA 攻击的是集群级分布式调度（session affinity + 多租户公平性），Continuum 攻击的是单机 TTL 最优化 [2605.00528]。

• PBKV (2605.06472)：用 GraphSAGE 多步预测 agent 调用序列，驱动分层淘汰 + 保守预取。与 Continuum 共享"预测 tool call 行为以优化缓存"的思路，但 PBKV 针对的是多 agent 工作流中跨 agent 的缓存复用，而 Continuum 针对单 agent 多轮中跨 turn 的缓存保留 [2605.06472]。

• SideQuest (2602.22603)：让 LRM 自身作为 KV cache 垃圾回收器，通过并行辅助线程做语义级 token eviction。SideQuest 工作在token 粒度（判断哪些 tool response 的 token 可以删除），Continuum 工作在请求粒度（判断整个请求的 KV cache 保留多久）。二者攻击的是 KV cache 管理的不同层级 [2602.22603]。

Agent 执行框架——上层架构 #

• Claude Code 解剖 (2604.14228)：对生产级 coding agent 的源码级逆向工程。其五层渐进式上下文压缩管道（budget reduction → snip → microcompact → context collapse → auto-compact）是 Continuum 所处生态的上层消费者——Continuum 在 serving 层保留 KV cache，Claude Code 在应用层管理 context window [2604.14228]。

• SGH (2604.11378)：提出 scheduler-theoretic 框架，将 Agent Loop 统一为 $|\mathcal{U}|$ 基数连续谱上的不同点。Continuum 的 program-level FCFS 可以被 SGH 框架描述为"对 $|\mathcal{U}|=1$ 的 single-ready-unit scheduler 的 TTL 增强"——SGH 提供理论坐标，Continuum 提供实际机制 [2604.11378]。

正交优化——不同瓶颈 #

• PASTE (2603.18897)：通过 pattern-aware speculative tool execution 将 tool 执行与 LLM 推理在时间上重叠。PASTE 攻击的是 tool 执行等待时间（占 E2E 35–61%），Continuum 攻击的是 tool call 间隙的 KV cache 排队延迟（占 E2E 58.2%）。二者是正交且可叠加的——PASTE 缩短 tool 侧等待，Continuum 消除 GPU 侧排队气泡 [2603.18897]。

• CPU-Centric Perspective (2511.00739)：系统刻画 agentic AI 的 CPU 侧瓶颈（工具执行占 E2E 延迟高达 88%）。Continuum 的优化完全在 GPU 侧（KV cache + 调度），与 CPU-Centric 的 COMB/MAS 调度优化攻击不同瓶颈 [2511.00739]。

上下文管理——不同范围 #

• CMV (2602.22402)：DAG 状态管理 + 三遍裁剪，管理跨会话的 context 复用。CMV 工作在应用层（conversation log 文件操作），Continuum 工作在 serving 层（GPU 显存中的 KV cache）。二者解决的"context 丢失"问题在不同时间尺度上：CMV 解决会话间的知识重建，Continuum 解决 turn 间的 KV cache 驱逐 [2602.22402]。

§2 本篇 vs 相关论文的 delta #

Continuum 的核心创新：per-turn queueing delay 的识别与量化 #

Continuum 的根本性贡献不是 TTL 机制本身（TTL 是成熟概念），而是首次识别 per-turn queueing delay 是 agent serving 的主导瓶颈，且与 KV reload cost 是独立的两个问题。

InferCept（Continuum 的直接前驱）证明了保留 KV cache 可以避免 reload cost，但 Continuum 的实测数据表明：即使 reload 近乎免费（CPU offloading），排队延迟仍占总延迟的 58.2% [2511.02230]。这个观察使得"是否保留 KV"从一个简单的"reload cost vs memory cost"权衡变成一个更复杂的"reload + queueing delay vs memory blocking"权衡——后者需要 memoryfulness factor η 这样的新量来建模。

vs SAGA：单机精致 vs 集群全局 #

维度	Continuum	SAGA
部署规模	单机 vLLM 插件	64-GPU 集群，三层架构
缓存决策粒度	每请求 TTL（cost-benefit）	每 session WA-LRU（AEG 预测复用概率）
工作流感知	无——仅知道 tool name 和历史延迟	有——AEG 编码 DAG 结构和转移概率
公平性	无——program-level FCFS 隐式偏向老程序	有——Agent Fair Share + Lyapunov 证明
竞争比	无形式化保证	1.31× vs Bélády optimal
延迟改善	1.12–3.66×（模拟），8.18×（真实）	1.64× geo-mean TCT

Continuum 的优势在于极简部署（vLLM 模块化插件，不需要改框架），但在多租户和长链工作流场景下缺乏 SAGA 的结构性优势。SAGA 的 session affinity 是其最大贡献（去掉后 TCT +96%），而 Continuum 完全不处理跨 worker 路由问题 [2605.00528] [2511.02230]。

vs PBKV：统计 CDF vs 学习型预测器 #

Continuum 用 per-tool 历史 CDF $\mathcal{P}(\tau, f)$ 预测 tool call 时长，本质是频率统计；PBKV 用 GraphSAGE + attention + LLM 隐藏状态的三流融合预测器预测下一个被调用的 agent。预测目标根本不同：Continuum 预测"什么时候回来"，PBKV 预测"谁会被调用" [2605.06472]。

PBKV 的 Lipschitz 退化保证（Theorem 5.1）是 Continuum 完全缺失的——Continuum 的 expected utility maximization 没有对预测错误的鲁棒性界 [2605.06472]。但 PBKV 的预测器需要训练数据（1K 轨迹）和额外推理开销（1.18ms/请求），Continuum 的 CDF 估计是零成本的在线统计。

vs SideQuest：请求级保留 vs token 级清理 #

SideQuest 在 agent 执行过程中主动删除已过期的 tool response token（56–65% peak token reduction），Continuum 在 tool call 间隙被动保留整个请求的 KV cache。二者是互补的——SideQuest 可以在 Continuum pin 住的 KV cache 内部进一步清理无用 token，释放更多显存给其他请求。

SideQuest 的 non-completion rate 数据（heuristic baselines 高达 60%+）揭示了一个 Continuum 未讨论的风险：如果 KV cache 被完全保留但上下文膨胀导致 attention 计算变慢，延迟可能从另一个维度恶化 [2602.22603]。

vs PASTE：GPU 侧排队 vs tool 侧等待 #

Continuum 和 PASTE 攻击的是 agent serving 延迟分解中的不同组成部分。PASTE 的 profiling 数据表明 tool 执行占 E2E 的 35–61% [2603.18897]，Continuum 的数据表明排队气泡占 58.2% [2511.02230]。两者加起来可能超过 100%——这不矛盾，因为 PASTE 测量的是 tool 执行时间本身，Continuum 测量的是 tool 返回后的排队时间。二者叠加的理论上限是消除所有非 LLM-inference 的 idle time。

vs CPU-Centric + Claude Code Analysis #

CPU-Centric 的核心发现是"GPU 越强，瓶颈越快转向 CPU"[2511.00739]。这对 Continuum 是一个有利的外部趋势：随着 H200/B200 让 GPU prefill 更快，KV cache reload 的时间成本下降，但 per-turn queueing delay 不变——Continuum 解决的问题相对更重要了。

Claude Code 的 5 层 compaction pipeline [2604.14228] 暗示：在应用层，context window 管理远比 serving 层想象的复杂。Continuum 假设"KV cache = 完整 context history"，但实际上 Claude Code 在 serving 请求到达之前已经做了大量裁剪——这意味着 Continuum 保留的 KV cache 可能对应的是已经被 compact 过的 context，保留的价值需要重新评估。

§3 可攻击面 #

攻击 1：TTL 最优性依赖工具延迟的平稳分布假设 #

Continuum 的 $\mathcal{P}(\tau, f)$ 从历史统计估计 tool call CDF，隐含假设 tool 延迟分布是平稳的。但真实 agent 的 tool 延迟高度依赖上下文：

• pytest 在首次运行（下载依赖）时可能需要 30s+，后续运行 <1s
• grep 在大仓库和小仓库上的延迟可能差 100×
• 网络 API 调用受带宽和服务端负载影响，CDF 会在一天内剧烈漂移

论文承认 tool call 时长的高度长尾（cd 最慢 10% 占 94.1% 总延迟）[2511.02230]，但 CDF 估计方法仅基于 tool name 分桶——相同 tool name 在不同执行上下文下的延迟方差被完全忽略。PBKV 的 GraphSAGE 预测器至少融合了工作流前缀和 LLM 隐藏状态来区分上下文 [2605.06472]，Continuum 的 per-tool CDF 是上下文无关的。

攻击 2：memoryfulness factor η 在非 ReAct 架构下可能失效 #

η = −Corr(k, N−k) 假设 agent 的 total step count N 和 current step k 之间存在可利用的相关性。这在 ReAct 循环中成立（已服务更多 turn 的程序剩余步数更少），但在以下场景下可能失效：

• Tree-of-thought / backtracking agent：步数不单调，k 增加不意味着 N−k 减少
• Multi-agent 工作流：一个"程序"可能触发子 agent，子 agent 的步数独立于父 agent 的 k
• 动态规划 agent：根据中间结果动态调整策略，N 本身是随机变量且与 k 无简单相关

SAGA 的 AEG 可以编码更复杂的工作流结构（包括回退边和分支概率）[2605.00528]，SGH 的 DAG 框架显式支持 any_of/all_of 并行 [2604.11378]——这些更丰富的工作流表示使得 Continuum 的线性 ReAct 假设显得脆弱。

攻击 3：缺乏形式化保证 #

Continuum 的 expected utility maximization 没有提供 competitive ratio 或 regret bound。对比：

• SAGA 提供 1.31× empirical competitive ratio vs Bélády optimal [2605.00528]
• PBKV 提供 Lipschitz 退化保证，遗憾上界与预测误差呈连续关系 [2605.06472]

Continuum 自己也承认"可以被形式化为 competitive ratio，但需要对 tool call 分布的先验假设"[2511.02230]。在对抗性场景下（恶意或极端长尾的 tool call 分布），TTL 策略的表现没有下界保证。

攻击 4：8.18× 真实环境改善的可复现性 #

论文最亮眼的数字（8.18× 延迟下降）来自"Company A 的真实 SWE-agent 测试床"[2511.02230]，但：

• 该环境的具体配置（GPU 数量、并发度、模型大小）未完全公开
• 模拟实验的改善仅 1.12–3.66×，与 8.18× 差距巨大
• 论文解释"真实 agent trace 的排队气泡问题比合成 benchmark 更严重"——但这也意味着该数字高度依赖特定工作负载特征

§4 生态位 #

范式定位：首个将"排队延迟"从"reload 成本"中独立出来的 agent serving 系统 #

Continuum 之前，agent serving 优化的共识是"保留 KV cache 以避免 reload cost"（InferCept 路线）或"更好地管理 KV cache eviction"（H₂O/SnapKV 路线）。Continuum 的核心范式贡献是证明了 per-turn queueing delay 是一个独立于 reload cost 的、更严重的问题——这重新定义了 agent serving 的优化目标函数。

SAGA、PBKV 等后续工作虽然各有创新，但都隐含地继承了 Continuum（和 InferCept）的这个基础洞察：tool call 间隙的 KV cache 管理是 agent serving 的核心问题。Continuum 的 TTL 机制可以被视为这个方向的 最简可行方案（minimum viable approach）——简单到可以作为 vLLM 插件部署，不需要改框架、不需要训练预测器、不需要集群调度器。

采用证据 #

• 代码开源（github.com/Hanchenli/vllm-continuum），基于 vLLM 实现
• 在 Company A 的真实 SWE-agent 环境中验证
• 被 SAGA 等后续工作作为 baseline 引用
• 与 Autellix (PLAS) 和 SGLang/Dynamo 的对比表明其在真实环境中的竞争力

在 agent serving 技术栈中的位置 #

应用层:  Claude Code compaction / CMV 会话管理 / Agent Framework
            ↓
框架层:  SGH DAG 调度 / PASTE 投机执行
            ↓
调度层:  SAGA 集群调度 / Continuum TTL ← [本文位置]
            ↓
引擎层:  vLLM/SGLang KV cache 管理 / SideQuest token 清理
            ↓
硬件层:  CPU-GPU 平衡调度 (COMB/MAS)

Continuum 占据"单机调度层"——比引擎层的 KV cache 管理更有 agent 语义感知，但比集群级的 SAGA 更轻量。这是一个deployment-friendly sweet spot：足够简单以在现有 vLLM 上快速部署，足够有效以在真实环境中产生显著改善。

§5 未探索方向 #

方向 1：TTL + 工作流预测的融合 #

Continuum 的 TTL 决策仅基于 tool call 的历史延迟分布，完全不利用工作流结构信息。将 SAGA 的 AEG 结构 [2605.00528] 或 PBKV 的 GraphSAGE 预测器 [2605.06472] 的工作流感知能力注入 TTL 计算，可以实现上下文感知的 TTL：

• 如果 AEG 预测当前 tool call 后大概率终止（转移概率低），TTL 可以设得更短
• 如果 GraphSAGE 预测后续 agent 会复用当前 KV cache 的前缀，即使 tool call 延迟超过统计 P90，也值得保留

这本质上是将 Continuum 的 $\mathsf{Benefit}(r)$ 从静态的 reload + queueing cost 扩展为动态的工作流感知期望收益。

方向 2：TTL + 投机执行的组合 #

Continuum 在 TTL 窗口内 pin 住 KV cache 等待 tool 返回；PASTE 在 LLM 推理期间投机执行下一个 tool [2603.18897]。二者可以深度组合：

• Continuum 的 TTL 窗口内，如果 PASTE 的 pattern predictor 已经预测了下一个 tool call 并完成了投机执行，TTL 可以提前释放（因为请求可以立即进入下一轮，无需等待 tool）
• 反过来，如果投机执行失败（参数不匹配），TTL 保证了 KV cache 仍在 GPU 上，请求不需要重新排队

这种"TTL 作为 safety net + speculation 作为 fast path"的组合，可能实现比各自独立运行更好的延迟-资源权衡。

方向 3：自适应 TTL + 在线学习 #

Continuum 的 per-tool CDF 是简单的运行平均。更先进的方案：

• Bayesian Online Change Detection：检测 tool 延迟分布的漂移（如网络环境变化），自动重置 CDF 估计
• Contextual Bandits：将 TTL 选择建模为 contextual bandit 问题，context 包含当前队列深度、显存压力、tool 类型等，直接优化 expected utility 而非两步分解（先估 CDF，再算 TTL）
• Multi-armed TTL：对每个 tool 维护多个 TTL 候选（保守/中等/激进），根据在线 reward 调整选择概率

方向 4：跨 turn 的 token 级混合管理 #

将 Continuum 的请求级 TTL 与 SideQuest 的 token 级 eviction [2602.22603] 结合：

• TTL 窗口内，SideQuest 的辅助线程可以在 pin 住的 KV cache 内部清理过期 token，释放部分显存给其他请求
• TTL 过期后，SideQuest 的清理可以部分保留高价值 token（而非全部驱逐），降低 re-prefill 时的计算量

这需要 serving 框架支持部分 KV cache eviction（目前 vLLM 仅支持全量保留或全量驱逐），是一个有价值的工程挑战。

方向 5：从 coding agent 到通用 agent 工作负载 #

Continuum 的全部评估限于 coding agent（SWE-bench, BFCL, OpenHands）。更广泛的 agent 类型有不同的 tool call 特征：

• Deep research agent（Qwen-DR, Gemini-DR）：tool call 以 web search + fetch 为主，延迟由网络决定，方差更大
• Scientific agent（VirtualLab）：tool call 包含模拟计算，延迟可达分钟级
• Browser agent（WebArena）：SAGA 的数据表明 browser agent 的 tool call 延迟变异系数 >2.0 [2605.00528]

Continuum 的 per-tool CDF 在高方差场景下可能严重失准。验证 TTL 机制在这些工作负载上的表现（或识别其失效边界）是一个重要的泛化实验。