Continuum: Efficient and Robust Multi-Turn LLM Agent Scheduling with KV Cache Time-to-Live
Continuum: KV Cache TTL for Multi-Turn Agent Serving #
Hanchen Li, Qiuyang Mang, Runyuan He, Qizheng Zhang, Huanzhi Mao, Xiaokun Chen, Hangrui Zhou, Alvin Cheung, Joseph Gonzalez, Ion Stoica (UC Berkeley / Tsinghua) | 2025-11 | arXiv 2511.02230 Category: agent | Tags: agent-serving, kv-cache-management, multi-turn-scheduling, ttl-mechanism, react-agent Read: 2026-05-25
§1 TL;DR #
Continuum 为多轮 ReAct agent 推理引入 KV cache time-to-live (TTL) 机制：以 cost-benefit 模型计算最优保留时间，兼顾 reload 成本和排队延迟；结合 program-level FCFS 调度，实现 1.12–3.66× 延迟下降和最高 8.18× 真实 SWE-agent 加速。
§2 Q1 / Q2 / Q3 #
Q1 痛点：end-of-turn eviction 在 agent workload 中导致严重的排队气泡 #
现有推理引擎（vLLM/SGLang）在 agent tool call 间隙立即驱逐 KV cache。与人类交互不同，agent tool call 返回极快（≤2s），但 KV 被驱逐后下一轮推理必须重入等待队列，产生 per-turn queueing delay——此延迟跨多轮累积，在实测中占总延迟的 58.2%。即使启用 CPU offloading 让 KV reload 近乎免费，排队延迟仍然无法消除。
InferCept 虽保留 KV cache，但仅考虑 reload 成本、忽略排队延迟，且无法适应 tool call 时长的高度长尾分布（cd 最慢 10% 占 94.1% 总延迟）。
Paper Figure 1: 两种失败模式对比。上方：end-of-turn eviction 导致额外 prefill 重计算；下方：即使 CPU offloading 保留了 KV，per-turn queueing delay 仍然迫使请求在 GPU 队列中等待。
Figure 1 直观展示了为什么仅解决 KV reload 问题是不够的——排队延迟是一个独立于数据传输的调度问题，InferCept 的 preserve 策略对此完全无效。
Q2 方法：KV Cache TTL + Program-Level FCFS #
核心方法: 为每个完成 tool call 的请求计算最优 TTL $\tau^*$，在 TTL 窗口内 pin 住 KV cache 在 GPU 显存中。TTL 通过期望效用最大化确定：
$$\tau^* = \arg\max_{\tau} \left[ \mathcal{P}(\tau, f) \times \mathsf{Benefit}(r) - \mathsf{Cost}(\tau, r) \right]$$
其中 $\mathsf{Cost}(\tau,r) = \frac{\mathsf{MemUsage}(r)}{\mathcal{M}} \times \tau$ 量化 GPU 显存占用对其他请求的阻塞代价；$\mathsf{Benefit}(r) = \mathsf{CacheMissCost}(r) + \mathsf{OutofOrderCost}(r)$ 包含 reload 成本和排队延迟两项收益；$\mathcal{P}(\tau, f)$ 是 tool $f$ 在 $\tau$ 内完成的概率（从历史统计估计）。
核心技术壁垒: OutofOrderCost 的 memoryfulness factor $\eta = -\mathrm{Corr}(k, N-k)$。此标量捕获了「维持程序顺序是否有助于加速」：当 agent 程序步数固定（$\eta=1$），维持 FCFS 等价于近似 SRTF；当步数服从几何分布（$\eta=0$），排序无益。这一数量将排队延迟从「看起来重要」提升为「可量化决策」的变量——这是 Continuum 相比 InferCept 的本质差异。
当 TTL 过期而 tool call 未返回时，KV cache 自动驱逐，提供对长尾 tool 延迟的鲁棒性保证。
Q3 结果 #
- 模拟工作负载：1.12×–3.66× 延迟下降，1.10×–3.22× 吞吐提升（Llama-3.1 8B/70B, Gemma-3 12B）
- 真实 SWE-agent 测试床：最高 8.18× 延迟下降
- 调度气泡从占总延迟 58.2% 降至近零
- 改进随 turn 数增加而 放大（1× turns: 1.6×, 5× turns: 3.7×）
§3 架构 / 方法图 #
Paper Figure 7: Continuum 系统架构。Tool Call Handler 识别 tool call 并预测时长；Scheduler & TTL Logic 计算最优 TTL 并管理 Priority Queue；GPU Memory 中的 KV blocks 带 TTL 标记，过期自动释放。
Continuum 作为 vLLM 的模块化插件实现。核心组件是 Tool Call Handler，在每次请求进出引擎时被调用：(1) 从生成输出中识别 tool call；(2) 查询历史记录 $S[f]$ 预测 tool 时长；(3) 用 utility model 计算 TTL；(4) 将 KV cache pin 到 GPU 显存并设置 TTL 定时器。调度器在每轮调度循环中检查过期的 TTL pin 并释放，同时以 program-level FCFS 优先级调度等待队列中的请求。
Agent 的一个完整 turn 流经状态机：推理 → 检测 tool call → 计算 TTL → pin KV → 等待 tool 返回。如果 tool 在 TTL 内返回，请求以最高优先级被立即调度（无排队延迟）；如果 TTL 过期，KV 被安全释放，请求重新排队并承担可控的 reload 成本。
Agent Loop 详解 #
- Task class: closed（function calling / coding agent），遵循 ReAct 范式的 multi-turn tool-augmented 推理
- Interaction pattern: multi-turn，每个 program 包含 6–11 个 turns（BFCL 6.3±2.3, SWE-Bench 10.9±2.1）
- Autonomy: fully autonomous（tool call 由 LLM 自主决定）
- Memory model: short-term only（KV cache = 隐式 context window）；无显式长期记忆
- Planning style: ReAct（think-then-act loop），无树搜索或回溯
- Error recovery: TTL 过期是唯一的「失败」恢复路径——KV 被驱逐后请求重新排队，不影响 agent 逻辑层
§4 作者证明 #
无形式化作者证明 — 仅实证
Continuum 的 TTL 最优性基于 expected utility maximization，但未提供收敛性证明或 competitive ratio。所有正当性来自实验验证。
| 符号 | 定义 | 物理意义 |
|---|---|---|
| $\tau$ | TTL 值 | KV cache 最大 GPU 驻留时间 |
| $\mathsf{MemUsage}(r) / \mathcal{M}$ | 内存占比 | pin 一个请求阻塞多少个平均请求 |
| $\mathsf{CacheMissCost}(r)$ | 重建成本 | prefill 或 CPU→GPU reload 的时间 |
| $\eta$ | memoryfulness factor | 维持程序顺序对加速的贡献系数 |
| $\mathcal{T}$ | 平均排队延迟 | 历史观测的 per-request 等待时间 |
| $\mathcal{P}(\tau, f)$ | CDF@τ | tool $f$ 在 $\tau$ 内完成的概率 |
关键方程物理意义:
- $\mathsf{Cost}(\tau,r) = \frac{\mathsf{MemUsage}(r)}{\mathcal{M}} \times \tau$：pin 时长 $\tau$ 内，占用的显存阻塞了约 $\frac{\mathsf{MemUsage}(r)}{\mathcal{M}}$ 个请求的执行机会，总代价线性于 $\tau$。
- $\mathsf{OutofOrderCost}(r) = \eta \times \frac{\mathsf{MemUsage}(r) \times \mathcal{T}}{\mathcal{M}}$：当 $\eta=1$（固定步数），维持 FCFS 完全消除排队延迟 $\mathcal{T}$；当 $\eta=0$（无记忆），排序无益。
- $\tau^* = \arg\max_{\tau}[\mathcal{P}(\tau,f) \times \mathsf{Benefit}(r) - \mathsf{Cost}(\tau,r)]$：在「命中概率 × 收益」与「确定性占用成本」之间找最优平衡点。
6 minimum checks:
- Cost 单调性: ✓ $\mathsf{Cost}$ 关于 $\tau$ 单调递增，符合直觉
- Benefit 非负性: ✓ CacheMissCost ≥ 0, OutofOrderCost ≥ 0（当 $\eta \geq 0$）
- 边界条件 $\tau=0$: ✓ 等价于不 pin，退化为 vanilla vLLM 行为
- 边界条件 $\tau \to \infty$: ✓ cost 趋向无穷，TTL 有限解存在
- $\eta$ 范围: ✓ $\eta \in [-1, 1]$，实测中 SWE-Bench/BFCL 均为正值
- $\mathcal{P}(\tau,f)$ 单调递增: ✓ CDF 性质保证，确保更长 TTL 命中概率更高
- Success-rate model: 无。Continuum 不影响 agent 任务成功率，仅优化调度延迟。Figure 12 验证 pass rate 与 SGLang 一致（~7%），显著优于 Dynamo（~3.5%）。
- Latency budget per turn: tool call 平均 925ms (SWE-Bench) / 1923ms (BFCL)；LLM inference 2–5s；TTL 通常设置在 tool call 分布的 P90 附近。
- Failure mode classification: 论文识别 3 类失败：(1) turn-based eviction（reload 成本）；(2) per-turn queueing delay（排队累积）；(3) variable tool call duration（长尾阻塞）。Continuum 专门针对 (2) 和 (3)。
- Convergence bound: 不存在。可以被形式化为 competitive ratio $\frac{\text{Continuum delay}}{\text{OPT delay}}$，但需要对 tool call 分布的先验假设。
- Tool Call Handler 的模块化设计: 以回调形式挂载在 vLLM 的请求入口/出口，不修改核心调度循环。这意味着 Continuum 可以追随 vLLM 主线升级，实现了最小侵入性。
- 历史统计的 per-tool / global 双层估计: 对高频 tool 使用 per-tool 均值/方差 $(\hat{\mu}_f, \hat{\sigma}_f)$；对罕见 / 首见 tool 回退到全局统计 $(\hat{\mu}, \hat{\sigma})$。这种双层 fallback 避免了冷启动问题，同时保留了 tool-specific 的精度。
- Offline profiling of $\mathsf{Prefill\text{-}Reload}$: 通过离线测量不同 context length 下的 prefill 时间和 KV reload 时间，建立查找表。这是 cost model 中唯一需要硬件相关校准的部分。
- Tool catalog: 由 agent framework 定义（SWE-agent 使用 bash commands: grep, cat, sed, pytest 等；BFCL 使用 web APIs: fetch_url 等）。Continuum 不解析 tool 语义，仅记录 tool name 和 execution time。
- Side effects: Continuum 不区分 read-only 和 write tools。所有 tool call 对 Continuum 透明，仅影响 TTL 计算。
- Error surface: tool 失败对 Continuum 表现为「tool call 返回，但可能触发新的 tool call」。TTL 过期是唯一的调度层失败模式。
- Environment contract: 非确定性（tool 延迟可变）；有状态（agent 维护 multi-turn context）。
- Minimum model size: 验证了 8B–355B（Llama-3.1 8B/70B, Gemma-3 12B, GLM-4.5 355B），method 与模型无关。
- Required capabilities: tool-call 生成能力（structured output 或特定 token 格式）。
- Sensitivity to backbone: 无——Continuum 在 serving 层工作，不依赖特定模型架构。
- Serving cost: 未单独分析。Continuum 的 overhead 仅为 tool call handler 的回调和 TTL 管理，对 per-token 成本的影响可忽略。
- Benchmarks: SWE-Bench (coding agent), BFCL V4 (function calling / web search), OpenHands (real SWE-agent)
- Metrics: average job delay, P90/P95 job duration, throughput (JPS)
- Baselines: vanilla vLLM, InferCept, Autellix (PLAS), SGLang, Dynamo
- Hardware: H100, 多种配置（含/不含 CPU offloading via LMCache）
- Sandboxing: 不在 Continuum 范围内——由 agent framework（SWE-agent / OpenHands）负责
- Observability: 未讨论 trace logging / TTL 决策审计
- Cost controls: TTL 过期机制本身提供了 GPU 显存的成本上界
Agent-specific checks:
§5 实验与数据 #
主实验：OpenHands + Llama-8B on H100 #
Paper Figure 9: OpenHands + Llama-8B on H100 的 average 和 P95 job delay。Continuum（绿色）在所有 JPS（Jobs Per Second）下显著优于 vLLM 和 Autellix，且差距随负载增大而扩大。
在 OpenHands 真实 SWE-agent 工作负载上，Continuum 在 JPS=0.05 时将 average delay 从 vLLM 的 ~5000s 降至 ~1600s（3.1×），P95 从 ~9000s 降至 ~3000s（3×）。Autellix 的 PLAS 调度虽考虑程序级优先级，但因缺乏 KV 保留机制，在高负载下退化严重。
SWE-Bench 尾延迟 #
Paper Figure 11: SWE-Bench trace + Llama-8B 的 P90 和 P95 job duration。Continuum 在全部 JPS 下持续优于 vLLM、Autellix+、InferCept 三个基线。
P90/P95 的改善尤其显著——因为排队气泡对尾延迟的影响是累积的：每多一轮 tool call，气泡多叠加一次。InferCept 虽保留 KV，但因忽略排队延迟，其 P90/P95 与 vLLM 差距不大（JPS=0.125 时仅 1.1× 改善 vs Continuum 的 1.5×）。
Turn 数扩展性 #
Paper Figure 14: 随 turn multiplier 增加（1× 到 5×，即 10.9 到 50.6 turns），Continuum 的改善倍数从 1.6× 增长到 3.7×，而自身延迟保持稳定。
这是论文最关键的 scaling 实验。当 turn 数从 10.9 增加到 50.6 时，vLLM/InferCept/Autellix 的延迟线性增长（per-turn queueing delay 累积），但 Continuum 的延迟几乎不变——因为 TTL 消除了每轮的排队气泡。这验证了 per-turn queueing delay 是一个与 turn 数成正比的系统性问题。
TTL 平衡点 #
Paper Figure 6: TTL 过短导致 KV 被过早驱逐（左，承担 prefill + queueing 代价）；TTL 过长导致 GPU 显存被无效占用（右，阻塞其他请求）。
真实分布式 SWE-Agent #
Paper Figure 12: 真实分布式 SWE-agent 环境下，Continuum 在中高负载下延迟优于 SGLang 和 Dynamo，同时保持相同 pass rate（~7%）。
在 Company A 的真实 SWE-agent 测试床上，Continuum 最高达到 8.18× 延迟下降。这远超模拟实验的 1.12–3.66×，表明真实 agent trace 的排队气泡问题比合成 benchmark 更严重。
鲁棒性：batch size 与 chunk size #
Paper Figure 13: 不同 max batch size（16–256）和 chunk size（256–4096）下，Continuum 一致优于所有基线，证明其对引擎配置的鲁棒性。
关键数据汇总 #
| 维度 | SWE-Bench | BFCL v4 | OpenHands |
|---|---|---|---|
| Turns per program | 10.9 ± 2.1 | 6.3 ± 2.3 | ~ |
| Tool time (ms) | 925 ± 3550 | 1923 ± 2133 | ~ |
| Tokens per program | 70k ± 20k | 93k ± 69k | ~ |
| 延迟改善 (emulated) | 1.12–3.66× | 1.10–3.22× | up to 3.1× |
| 延迟改善 (real) | — | — | 8.18× |
§6 论证链 #
| 步骤 | 论证 | 证据 |
|---|---|---|
| 1. Agent workload 的 tool call 间隙导致 KV 被驱逐 | 现有引擎的 end-of-turn eviction 策略与 agent 的 fast tool return 不匹配 | Table 2: tool call 平均 925ms/1923ms，远快于人类交互 |
| 2. KV 驱逐的主要代价不是 reload，而是 per-turn queueing delay | 即使 CPU offloading 使 reload 近乎免费，请求仍需排队等待 GPU 空间；此延迟跨 turn 累积 | Figure 4: InferCept 保留 KV 后排队气泡仍与 vLLM 相当；气泡占总延迟 58.2% |
| 3. 简单的「always pin」策略不可行，因为 tool call 时长高度长尾 | 无限 pin 导致 GPU 显存被长尾 tool call 占死 | Figure 5: cd 最慢 10% 占 94.1% 总延迟 |
| 4. TTL 机制以 cost-benefit 模型设定有界保留时间 | 最优 $\tau^*$ 在命中概率 × 收益与显存占用成本之间取平衡 | §4.1-4.2 公式推导 + Figure 6 直观说明 |
| 5. Program-level FCFS 结合 TTL 实现近似 SRTF | 已服务更多 turn 的程序剩余 token 更少，FCFS 近似 SRTF | Figure 3: future tokens 随 step 单调递减 |
| 6. 效果随 turn 数增加而放大 | per-turn delay 是累积量，消除它的收益与 turn 数成正比 | Figure 14: 1× turns 1.6× → 5× turns 3.7× |
| 7. 真实生产环境效果优于模拟 | 真实 agent trace 的排队问题比合成 benchmark 更严重 | Figure 12: 最高 8.18× |
§7 实现 cross-reference #
代码开源: https://github.com/Hanchenli/vllm-continuum (基于 vLLM)
关键实现细节 #
核心技术壁垒 #
OutofOrderCost 中的 memoryfulness factor $\eta$ 是整个系统的 keystone——它将「是否应该维持程序执行顺序」从直觉判断转化为可量化的统计度量。没有这个因子，TTL 决策退化为仅基于 reload cost 的 InferCept 策略。$\eta$ 的计算仅需维护 $(k, N)$ 的运行时统计，overhead 可忽略，但其对决策质量的影响是决定性的。