Conference: ICML'26 Spotlight

Github: https://github.com/ThunderAgent-org/ThunderAgent

Abstract

这篇论文研究的是 agentic inference system，也就是面向 LLM Agent 多轮推理、多轮工具调用、多轮环境交互的推理系统。论文的核心问题是：现在的大模型不再只是一次性回答用户问题，而是越来越多地作为 Agent 使用，例如代码修复 Agent、科学发现 Agent、routing Agent、computer-use Agent 等。这类 Agent 往往需要在一个长时间运行的 workflow 中不断执行：

LLM reasoning $\rightarrow$ tool call $\rightarrow$ tool observation $\rightarrow$ LLM reasoning $\rightarrow$ tool call $\rightarrow \cdots$

这与传统 LLM serving 中“一个 prompt 对应一次 request”的模式不同。传统系统通常把 agentic inference 拆成两个彼此独立的组件：

  1. LLM inference engine，例如 vLLM、SGLang；
  2. tool orchestrator，例如 Kubernetes、Docker sandbox、API server 管理器等。

这种组合虽然工程上容易实现，但系统只在 per-request 层面调度资源，而没有看到整个 agent workflow 的 end-to-end 生命周期。论文指出，这种 request-aware 设计会导致两个关键资源管理不佳：

  1. KV cache 管理不佳：工具执行期间，系统可能提前 evict 该 workflow 的 KV cache；工具返回后，需要重新 prefill 整个历史上下文，造成严重 re-computation。
  2. tool execution environment 管理不佳：Docker sandbox、disk memory、network ports 等工具环境没有和 agent workflow 生命周期绑定，导致资源泄漏、环境准备时间过长、长时间运行后系统不稳定。

为了解决这些问题，论文提出 ThunderAgent。它的核心思想是将 agent workflow 抽象成 LLM Program / Agentic Program。也就是说，系统不再只调度单个 request，而是调度一个具有长期状态的 program。这个 program 会持续跨越多次模型调用和多次工具调用，并显式记录 workflow id、execution phase、scheduling status、context token 数量、tool resource 等元信息。

基于这个 program abstraction，ThunderAgent 设计了两个主要模块：

  1. Program-aware scheduler 用于提升 KV cache hit rate，减少 KV cache thrashing，同时缓解多节点场景下的 memory imbalance。

  2. Tool resource manager 用于管理工具环境生命周期，包括工具资源的 hook-based garbage collection 和 asynchronous environment preparation。

论文在 coding agent、routing agent、scientific discovery agent，以及 RL rollout 场景中评估 ThunderAgent。实验结果显示，相比现有系统，ThunderAgent 在 serving 中获得 1.5-3.6× throughput improvements，在 RL rollout 中获得 1.8-3.9× improvements，并最多带来 4.2× disk memory savings。

从系统设计角度看，这篇论文的关键贡献不是提出新的模型结构，也不是优化单个 Transformer kernel，而是提出一个更适合 Agent 时代的系统抽象：

Agentic inference should be scheduled as programs, not isolated requests.

也就是说，ThunderAgent 的核心价值在于把 agent workflow 从“一堆离散 request”重新建模为“一个具有生命周期、状态、资源依赖和执行阶段的程序”。

1. Introduction

Recent advances in language models have expanded their use beyond basic chatbots to complex agents [20, 26]. These agents address real-world problems in domains such as coding [7, 9] and computer-use [2, 24] by interleaving long reasoning with external tool calls, such as compilers and retrievers. 这类 Agent 往往以 autonomous system 的形式运行，可以在没有实时人工干预的情况下执行多步任务。

例如，在 coding agent 场景中，一个 Agent 可能需要：

  1. 阅读 issue description；
  2. 查看代码文件；
  3. 搜索相关函数；
  4. 修改源代码；
  5. 运行测试；
  6. 根据测试结果继续修改；
  7. 最终提交 patch。

在这个过程中，LLM 不是只被调用一次，而是被反复调用。工具也不是一次性使用，而是与 LLM 推理交替出现。因此 agentic workflow 是一个长生命周期、多轮状态持续增长的执行过程。

论文指出，当前现代 inference systems 在 agentic requests 数量增加时 throughput 会明显下降，如 Figure 1a 所示。同时，在 reinforcement learning, especially agentic RL 中，rollout 阶段占总 wall-clock time 的 70% 以上。因此，对于 autonomous agent 和 RL rollout 来说，系统效率主要由 sustained throughput 决定，而不是单个用户交互场景中的 tail latency。更高的 throughput 可以降低 serving cost，也可以减少 asynchronous RL 中的 policy lag，使训练数据更接近当前 policy，从而提升训练效率和最终性能。

然而，当前 agentic inference systems 的吞吐并不理想，主要原因是它们通常由彼此孤立的组件松散组合而成：

  • off-the-shelf model inference engine，例如 vLLM 或 SGLang；
  • general-purpose tool orchestrator，例如 Kubernetes。

这些组件各自只看到局部请求，无法看到完整 workflow。也就是说，LLM engine 只看到一条条模型请求，tool orchestrator 只看到一个个工具环境或容器操作，但系统整体并不知道这些请求属于同一个 agent program。因此，资源调度和资源释放都是 request-level 的，而不是 workflow-level 的。

论文将这种设计缺陷总结为三个 key challenges。

1. KV cache thrashing

第一个问题是 KV cache thrashing。

在多轮 Agent workflow 中，agent 的上下文是不断增长的。假设第 $t$ 步的上下文是 $c_t$，第 $t+1$ 步的上下文通常是在 $c_t$ 后面追加新的 observation 和 action。因此，理论上同一个 workflow 的 KV cache 应该具有非常高的复用率。只要上一轮的 KV cache 保留下来，下一轮就不需要重新 prefill 整个历史上下文。

但 request-aware 系统会把每次 LLM 调用看作独立请求。当 Agent 进入工具调用阶段时，GPU 上暂时没有这个 workflow 的 LLM decode 工作。系统可能认为这个 request 已结束，或者在高并发压力下为了容纳新请求而 evict 该 workflow 的 KV cache。等工具执行结束后，Agent 下一轮又需要基于完整历史上下文继续推理。由于之前的 KV cache 已经被释放，系统必须重新 prefill 整个 interaction history。

这个过程就是：

tool execution interval 中 KV cache 被提前释放 $\rightarrow$ tool call 完成后 workflow resume $\rightarrow$ 需要 rerun prefill 恢复 whole interaction history $\rightarrow$ re-prefill 成本显著增加 $\rightarrow$ E2E latency 上升，throughput 下降

论文指出，re-prefill cost 会使 agent workflow 的平均端到端延迟最高增加 7.14×，如 Figure 1b 所示。

2. Cross-node memory imbalance

第二个问题是 cross-node memory imbalance。

在多节点 inference setup 中，为了提升 KV cache hit rate，现有系统通常会把同一个 workflow 的所有请求固定路由到同一个 GPU node。这样做的好处是，如果该 workflow 的 KV cache 还在原节点上，就可以直接复用。

但是 agent workflow 的 context length 和 execution lifetime 非常不稳定。不同 workflow 可能有完全不同的 token 数、工具调用次数和运行时间：

  • 有些 workflow 很短，很快结束；
  • 有些 workflow 长时间运行，context 不断增长；
  • 有些 workflow 会产生很大的 KV footprint；
  • 有些 workflow 则几乎不占用太多内存。

如果所有请求都被固定到最初的节点，就会导致某些节点上的长 workflow 堆积，HBM 使用率很高；而其他节点可能仍然有大量空闲内存。这样系统虽然全局还有资源，但局部节点已经 memory pressure 很大，从而触发 pause、preemption 或 eviction。

论文指出，vLLM 的 KV-aware router 会把同一 agentic workflow 的请求发送到同一个节点以最大化 locality；SGLang 的 prefix-aware routing 也可能因为 agent workflows 具有相同 system prompt 而把大量请求集中到同一节点。结果是某些节点 overload，而其他节点 underutilized。

3. Tool lifecycle obliviousness

第三个问题是 tool lifecycle obliviousness。

Agentic workflow 不只消耗 GPU KV cache，也会长期占用工具资源，例如：

  • Docker sandbox；
  • API server；
  • network port；
  • disk memory；
  • repository checkout；
  • package installation；
  • database connection；
  • shell / Python / compiler 环境。

现有 request-aware orchestrator 很难判断工具资源何时应该释放、何时应该提前准备。其结果是：

  1. Resource leakage workflow 完成后，Docker image、sandbox、network port、disk data 等没有及时回收，导致磁盘占用持续增长，最终造成系统故障。

  2. Costly environment preparation 新 workflow 开始前需要准备工具环境，例如拉取 Docker、安装依赖、构建 repo 等。如果这些准备工作不能与 LLM reasoning 重叠，就会显著增加端到端 latency。

论文指出，在 long-horizon agentic workloads 中，tool environments 是 persistent resources。如果系统没有 program-level 视角，就无法判断一个工具等待是临时等待，还是 workflow 已经结束，也无法协调 GPU memory 和 tool resource lifecycle。

ThunderAgent 的贡献

This work introduces ThunderAgent, an agentic inference system that adopts an end-to-end view of agentic workflows to enable high-throughput agentic serving and RL rollout.

论文的贡献可以概括为三点。

1. Program abstraction

ThunderAgent 将 agent workflow 抽象为 agentic program。一个 agentic program 是一个 first-class scheduling unit，它会跨越多次模型调用和多次工具执行而持续存在，并向 runtime 暴露 semantic state。

这个 program 会记录：

  • workflow identifier；
  • execution phase，即当前处于 reasoning 还是 acting；
  • scheduling status；
  • total tokens；
  • tool resources；
  • backend placement。

这个抽象的好处是，它把 scheduling 从具体 backend 中解耦出来。ThunderAgent 不需要深度绑定某个特定 inference engine，而是可以作为 program-aware scheduling layer 集成在 vLLM / SGLang 等系统之上。

2. Program-aware scheduler

基于 program abstraction，ThunderAgent 将 agentic inference scheduling 建模为一个 constrained optimization problem。目标是在 GPU memory capacity 约束下：

  • minimize recomputation overhead；
  • minimize caching overhead；
  • maximize prefilling and decoding throughput；
  • mitigate cross-node memory imbalance。

具体包括两个机制：

State-aware pausing： 当 backend 出现 memory pressure 时，ThunderAgent 不再随机 evict KV cache，而是优先 pause 当前处于 acting state 的 workflow。因为 acting program 正在等待工具执行，暂时不产生 GPU decode/prefill 工作；而 reasoning program 正在 GPU 上进行有效推理，更应该保留。

Dynamic migration： ThunderAgent 使用全局 program-aware waiting queue，使所有 DP GPU nodes 共享等待队列。paused program 未来可以恢复到任意有空闲容量的节点，而不是必须回到原节点。这样可以缓解跨节点 memory imbalance。

3. Program-aware tool resource management

ThunderAgent 不只管理 GPU KV cache，还管理工具环境的生命周期。它通过追踪 program execution dependencies，使 I/O-intensive environment initialization 可以和 LLM reasoning 重叠。同时，当 program 完成时，系统可以根据 program termination signal 回收 Docker sandbox、network port、disk memory 等资源，从而防止累计资源泄漏。

这三个贡献都依赖 program-level abstraction。没有显式的 program state 和 workflow dependency，request-aware scheduler 无法区分：

  • 当前 workflow 只是临时等待工具；
  • 当前 workflow 已经结束；
  • 当前 KV cache 是否未来很快会被复用；
  • 当前 tool environment 是否应该保留或释放。

论文在 serving 和 RL rollout 中评估 ThunderAgent。Serving 场景包括 ToolOrchestra on HLE-Bench、SWE-Agent 和 OpenHands on SWE-Bench，以及 OpenHands on ScienceAgentBench。ThunderAgent 获得 1.48–3.58× throughput improvements。RL rollout 中，ThunderAgent 在 distributed GPU nodes 上获得 1.79–3.92× improvements。

2. Background

Figure 1 是论文动机图。它展示了三个重要现象：

  1. Figure 1a: Throughput degradation 随着 parallel workflow number 增加，vLLM 和 Continuum 的 throughput 在高并发下下降，而 ThunderAgent 能保持更高吞吐。

  2. Figure 1b: KV cache thrashing 随着并行 workflow 增加，prefix cache hit rate 下降，E2E latency 上升。这说明 throughput degradation 的主要原因之一是 KV cache 被频繁 evict，导致工具返回后需要重新 prefill。

  3. Figure 1c: Speedup from ThunderAgent ThunderAgent 在 SWE-Agent、OpenHands、ToolOrchestra 等不同 agent workload 上均获得明显 speedup，说明该问题不是单一应用中的偶然现象，而是 agentic inference 的普遍系统瓶颈。

2.1 System Properties of Current Agentic Workflows

当前 agentic workflows 在执行过程中会不断在 reasoning 和 acting 两种状态之间切换。

在第 $t$ 步，Agent 接收一个 observation：

$$ o_t \in O $$

然后生成一个 emission：

$$ e_t = (\ell_t, a_t) \in L \times A $$

其中：

  • $\ell_t$ 表示 thought，即 LLM 的推理文本；
  • $a_t$ 表示 action，即要调用的工具或执行的动作。

第 $t$ 步的累计上下文定义为：

$$ c_t = (o_1, e_1, \ldots, o_t) $$

这个上下文 $c_t$ 捕捉了整个 agent workflow 到目前为止的 interaction history。给定 $c_t$，Agent 根据策略 $\pi$ 采样下一步 emission：

$$ e_t \sim \pi(e_t \mid c_t) $$

这个形式化定义强调了 Agent 的两个重要特点。

第一，Agent 的上下文是递增的。第 $t+1$ 步的上下文是在第 $t$ 步上下文的基础上继续追加新 observation 和 emission。因此：

$$ c_{t+1} \text{ extends } c_t \text{ as a prefix} $$

这意味着同一个 workflow 的 KV cache 理论上可以高度复用。如果系统保留了 $c_t$ 的 KV cache，那么下一步只需要 prefill 新增部分，而不是重新计算整个历史。

第二，Agent workflow 具有 persistent states。论文指出有两类 persistent states。

1. GPU Memory

GPU Memory 中保存的是上下文 $c_t$ 的 KV cache。它实际上是 workflow 的推理记忆。由于 $c_t$ 会不断增长，KV cache 也会随之增长。如果系统能保持同一个 workflow 的 KV cache，那么后续步骤可以实现接近 complete KV cache reuse。

2. Tool Environment

Tool Environment 指 agent 调用工具所需要的外部资源，例如：

  • Docker sandbox；
  • database connection；
  • local repository；
  • compiler；
  • shell environment；
  • browser environment；
  • API server；
  • network port。

这些资源通常在 workflow 开始时初始化，并且必须在整个 workflow 执行过程中保持一致和可访问。比如一个 coding agent 在 Docker sandbox 中修改了代码文件，后续测试和再次编辑必须在同一个 sandbox 状态下进行。

因此，agentic workflows 本质上是 stateful 的。它们要求系统在长时间运行过程中协调 GPU memory 和 tool environment，而不能把每次 thought 或 action 当作 independent stateless request。

2.2 Existing Agentic Inference Systems

已有系统大多只优化 agentic inference 中的某个单独组件，例如 LLM inference engine 或 tool orchestrator。它们很少从 end-to-end workflow 角度同时优化 GPU、CPU、disk、network 和 remote resource。

论文重点讨论了两个代表性系统：Autellix 和 Continuum。

Autellix

Autellix 将 multi-turn agentic workflows 建模为 GPU-only programs，并在 central process table 中记录累计 GPU execution time。它相比普通 request-level 系统已经更接近 program-level abstraction。

但 Autellix 的问题是它忽略了 workflow locality。多个并发 workflow 之间可能互相 aggressive evict 对方的 KV cache，在 heavy workload 下仍然会触发 KV cache thrashing。因此，它虽然意识到了 Agent workflow 的程序性，但没有充分解决 KV cache reuse 和 workflow locality 问题。

Continuum

Continuum 是一个面向 multi-turn agentic workflows 的 serving system。它使用 time-to-live, TTL 机制，把 KV cache pin 在 HBM 中，从而尝试减轻工具执行期间的 context thrashing。

Continuum 的基本思路是：系统预测工具执行时间，在这段时间内保留该 workflow 的 KV cache；如果工具很快返回，就可以直接复用 KV cache。

但论文指出 Continuum 仍然无法彻底解决 KV cache eviction 问题，主要原因有两个：

  1. 工具执行时间不可预测 很多工具的执行时间具有高方差，例如 ToolOrchestra 中的 remote model API、coding agent 中的 compiler、computer-use agent 中的 web application。这些工具可能受网络延迟、远程服务排队、rate limit、sandbox I/O 等影响，TTL 很难准确预测。

  2. decode memory 仍可能超过 GPU limit 即使 KV cache 被 TTL pin 住，当 active workflow 的 decoding memory 超过 GPU 限制时，系统仍然不得不 preempt 并 evict pinned KV cache。这意味着 Continuum 在高并发下仍然会发生 thrashing。

因此，论文认为 agentic inference 需要一个 simple and fast program-aware scheduling layer，而不是继续在 request-aware inference engine 上做局部补丁。

3. Challenges in Existing Agentic Inference Systems

、

Figure 2 展示了现有 agentic inference 系统中的两个关键问题：跨节点内存不均衡和工具资源管理问题。论文使用 vLLM + Kubernetes 作为代表性 baseline，在 OpenHands RL rollout 中使用 GLM-4.6，并运行在两个 8×H100 GPU nodes 上。

Figure 2 包含三个子图：

  1. Figure 2a: Memory imbalance in rollout 展示两个节点 Node0 和 Node1 的 memory usage 随时间变化，以及它们之间的 absolute difference。结果显示，在 90 分钟 rollout 测试中，memory imbalance 最高达到 51%；并且有超过 37 分钟两个节点之间的 memory usage 差异超过 20%。

  2. Figure 2b: Runtime disk usage for tool envs. 展示工具环境的 disk usage 随 processed workflows 增加而增长。如果没有及时 GC，disk usage 会线性增加并超过 disk memory capacity。相比之下，active disk usage 表示当前真正还在运行的 workflow 所需要的资源，它并没有线性增长那么快。这说明大量磁盘占用来自已经结束但未释放的工具环境。

  3. Figure 2c: Tool env. preparation time 展示 parallel workflow number 增加时，平均工具环境准备时间也增加。具体来说，parallel workflow number 从 24 增加到 96 时，平均 env prepare time 从 29.9s 增加到 47.2s。这说明工具环境准备不是小开销，在高并发 agent serving 中会显著影响端到端效率。

论文在 Section 3 中强调，这些问题不能简单通过替换 inference engine 或 tool orchestrator 来解决。例如，将 vLLM 换成 TensorRT 或 SGLang，或者将 Kubernetes 换成其他 orchestrator，都无法让系统自动理解 workflow state 和 program lifecycle。因此需要新的 program-aware abstraction。

3.1 KV Cache Thrashing

Agentic workflows 在理论上具有很高的 KV cache reuse rate。原因是同一个 workflow 的上下文是 prefix-growing 的：

$$ c_{t+1} = c_t + \text{new observation/action} $$

如果 $c_t$ 的 KV cache 还在，那么 $c_{t+1}$ 只需要处理新增部分，历史部分可以直接复用。

但是在现有 LLM serving systems 中，每一步都被当作 independent and stateless request。高并发时，系统为了容纳新请求，会在工具执行期间频繁 evict 暂时没有 decode 的 workflow 的 KV cache。等工具返回后，该 workflow 必须重新 prefill 全部历史上下文。论文把这种 repeated eviction and reprefill 称为 KV cache thrashing。

KV cache thrashing 的影响可以分解为：

  1. 直接增加 prefill 计算 原本只需增量 prefill 新 observation，现在要重新 prefill 全部历史。

  2. 增加端到端 latency 工具返回后 workflow 不能立即继续 decode，而是需要等待 re-prefill。

  3. 降低系统 throughput GPU 时间被浪费在重复计算历史上下文上，而不是处理新的有效 decode/prefill 工作。

  4. 高并发下恶化更明显 parallel workflow number 越大，HBM 压力越大，KV eviction 越频繁，hit rate 越低。

Figure 1b 显示，这种 cache hit rate 下降会导致 E2E latency 明显增加。论文报告 re-prefill 最高可使每个 request 的 E2E latency 增加 7.14×。

3.2 Cross-Node Memory Imbalance

在 data parallel inference setup 中，通常有多个 backend replicas。现有 multi-turn scheduler 会根据 KV cache locality 进行 greedy routing，把请求分配到最可能命中 KV cache 的节点。

这种策略在单个 workflow 的局部视角下是合理的，但在全局资源利用角度有明显问题。因为不同 workflow 的 KV footprint 和 lifetime 具有高度异质性：

  • 有些 workflow 上下文短，KV cache 小；
  • 有些 workflow 上下文长，KV cache 大；
  • 有些 workflow 工具调用频繁，长时间占用工具环境；
  • 有些 workflow 很快结束；
  • 有些 workflow 进入长时间 acting 状态，但其 KV cache 仍可能被 pin 在某个节点上。

如果同一 workflow 被固定在同一节点，系统会出现 memory imbalance。某个节点可能因为承载了多个长上下文 workflow 而超过容量，而另一个节点还有大量空闲 HBM。此时系统可能在局部节点上触发 eviction 或 pause，但从全局看其实还有资源没有利用。

论文指出：

  • vLLM KV-aware router 会将同一 workflow 的请求发送到同一个 node；
  • SGLang prefix-aware router 会根据 prefix 匹配度路由请求，但 agent workflows 往往共享相同 system prompt，因此可能把大量请求集中到同一节点。

Figure 2a 中，两节点 memory usage 的 peak imbalance 达到 51%，说明 locality-aware routing 并不等价于全局最优调度。

这里的关键矛盾是：

为了 KV locality 固定路由，可以减少单个 workflow 的 recomputation； 但过度固定路由会造成全局 memory imbalance，增加 unused capacity 和局部 thrashing。

ThunderAgent 的全局 program-aware waiting queue 正是为了解决这个矛盾。

3.3 Tool Lifecycle Obliviousness

现有 agentic inference 系统没有把 external tool orchestrator 的生命周期和 LLM inference engine 同步起来，因此会产生 silent resource wastage 和 tool-side latency overhead。

这里有两个具体问题。

Resource leakage and unused sandboxes

Figure 2b 展示了 total disk usage 随 processed workflows 线性增长，最终超过系统容量。原因是 workflow 结束后，相关 Docker images、sandbox、临时文件、网络端口、API server 等没有被及时回收。

这类资源泄漏在短时间实验中可能不明显，但在 long-running agent serving 或 RL rollout 中非常严重。因为 Agent 系统可能连续运行数小时甚至数天，如果每个 workflow 都残留 sandbox 或 disk data，最终会导致：

  • disk memory exhausted；
  • network ports exhausted；
  • Docker daemon 压力过大；
  • tool environment 创建失败；
  • 整个 serving system 不稳定。

Costly environment preparation

大多数 agentic workloads 在启动前都需要准备工具环境。例如 coding agent 需要：

  • pull Docker images；
  • install packages；
  • build repositories；
  • checkout code；
  • prepare test environment；
  • 启动 shell / Python / compiler runtime。

这些准备工作通常是 I/O-intensive 的，并且随着 parallel workflow number 增加而变慢，如 Figure 2c 所示。如果 LLM inference engine 必须等环境准备完成后才能开始 reasoning，就会显著延长 E2E latency。

ThunderAgent 的设计是将环境准备和 LLM reasoning 重叠起来：当某个 program 在 global waiting queue 中接近 restore threshold 时，系统提前异步准备它的 tool environment，从而隐藏初始化开销。

4. ThunderAgent: A Program-Aware Agentic Inference System

Resource leakage and unused sandboxes. Figure 2b showcases that the total disk space consumption increases linearly with the number of processed workflows, eventually exceeding system capacity. This is because unused resources, such as Docker images of finished workloads, are not reclaimed when workflows complete. This inefficient garbage collection leads to fatal system instabilities for long-term agentic inference.

Costly environment preparation. Most agentic workloads need to prepare environments before initiating the multi-turn trajectory. For example, coding agents need to pull dockers, install related packages and build repositories. This preparation time is costly and increases with the parallel workload number, as shown in Figure 2c. If the LLM inference engine needs to wait until the environments are fully prepared, this overhead will extend the end-to-end latency of the inference system.

With all findings in Section 3, ThunderAgent is designed as a program-aware system for high throughput agentic inference. 本节是论文最重要的 methods / design 部分，核心内容包括：

  1. Program Abstraction：定义 Agentic Program，作为系统调度的基本单位；
  2. Cost Model：用 STP 对不同资源消耗建模，明确哪些成本是有效计算，哪些是浪费；
  3. Scheduling Policy：基于 program state、context length、tool waiting time 进行 pause / restore；
  4. Global Program-Aware Waiting Queue：跨 backend 做全局调度，缓解 memory imbalance；
  5. Tool Resource Management：用 lifecycle hook 做工具资源 GC，并异步准备工具环境。

Figure 3 是 ThunderAgent 的整体设计图。图中有多个 inference backends，以及一个由所有 backends 共享的 Global Waiting Queue。ThunderAgent 会周期性监控每个 backend 的状态。当 Backend #1 发生 thrashing，而 Backend #3 仍有空闲时，系统会将 Backend #1 上的 acting Program #2 pause 回全局队列，同时从全局队列中 restore Program #6 和 Program #9 到 Backend #3。这样既减少了 Backend #1 的 KV cache thrashing，也提高了 Backend #3 的资源利用率。

Figure 3 右侧还展示了 program metadata 示例，例如：

  • Program ID；
  • context token 数 $C$，如 15K、21K；
  • 当前 phase $\tau$，如 Reasoning 或 Acting；
  • backend placement $\mathcal{L}$，如 backend_3；
  • 当前 HBM 使用率，例如 55%。

这说明 ThunderAgent 的调度对象不是单条 request，而是带状态的 program。

4.1 Program Abstraction

The Agentic Program serves as a fundamental abstraction that encapsulates both the logical execution flow and the system-level dependencies of agentic workflows.

论文将一个 agentic program $P$ 定义为一个 tuple：

$$ P = \langle ID, c, T, \mathcal{L}, \tau, s \rangle $$

其中每个字段含义如下：

符号 含义 详细解释
$P$ Agentic program instance 一个完整的 agent workflow 实例
$ID$ Unique global identifier program 的全局唯一标识，用于关联多次 LLM 请求和多次 tool execution
$c$ Number of tokens in the context 当前累计上下文 token 数，近似表示 KV cache memory footprint
$T$ Set of tool environments program 需要的工具环境集合，例如 Docker sandbox、network port、repo、database connection
$\mathcal{L}$ Backend placement 当前 program 被放在哪个 GPU backend / node 上
$\tau$ Execution phase program 当前处于 Reasoning $(R)$ 还是 Acting $(A)$
$s$ Scheduling status program 当前状态：Active、Paused、Terminated

这个 abstraction 的意义非常重要。

1. $ID$ 让系统知道哪些 request 属于同一个 workflow

在普通系统中，请求只是 isolated request。即使有 session id，它通常也只是用于 routing，而不是用于完整 workflow state management。ThunderAgent 的 program ID 不只是路由标签，而是系统用来查询 program metadata 的 key。

例如，同一个 coding agent workflow 中可能有：

  • 第 1 次 LLM request；
  • 第 1 次 shell tool execution；
  • 第 2 次 LLM request；
  • 第 2 次 file editing tool；
  • 第 3 次 LLM request；
  • final answer。

这些操作都应该属于同一个 $ID$。有了 $ID$，ThunderAgent 才能知道它们共享同一个 KV cache lifecycle 和 tool resource lifecycle。

2. $c$ 让系统估计 KV cache footprint

$c$ 表示上下文 token 数。由于 LLM KV cache 大小基本与 token 数线性相关，$c$ 可以作为 GPU memory demand 的近似指标。

如果一个 program 的 $c$ 很大，说明它的 KV cache 很大。驱逐它会释放较多 HBM，但未来如果它 resume，需要重新 prefill 很长上下文，recompute cost 很高。

如果一个 program 的 $c$ 很小，驱逐它释放的 HBM 较少，但未来恢复成本也低。因此后面 shortest-first eviction 会用到 $c$。

3. $T$ 让系统管理工具环境生命周期

$T$ 记录该 program 依赖的 tool environments。例如一个 OpenHands coding workflow 的 $T$ 可能包括：

  • Docker container；
  • repository directory；
  • package cache；
  • shell process；
  • temporary test files；
  • port binding。

当 program 结束时，如果没有其他 program 依赖这些资源，ThunderAgent 可以安全释放它们。这是 request-aware orchestrator 很难做到的，因为它不知道 workflow 是否真的结束。

4. $\mathcal{L}$ 记录 backend placement

$\mathcal{L}$ 表示当前 program 被放置在哪个 backend 上。这个字段用于保持 spatial locality，也用于跨节点迁移。

当 program active 时，$\mathcal{L}$ 是某个 backend，例如 backend_1。 当 program paused 且 KV cache 被释放时，$\mathcal{L}$ 可以置为空，表示它不再绑定到具体节点。

5. $\tau$ 区分 Reasoning 和 Acting

这是 ThunderAgent 调度中最关键的状态。

  • $\tau = R$：program 正在 Reasoning，也就是进行 LLM prefill / decode；
  • $\tau = A$：program 正在 Acting，也就是等待工具执行结果。

Reasoning program 正在产生有效 GPU 工作，应优先保留或恢复。Acting program 暂时不使用 GPU decode，但可能需要保留 KV cache 以便工具返回后快速 resume。ThunderAgent 需要在保留 Acting KV cache 和释放 idle HBM 之间做 trade-off。

6. $s$ 表示调度状态

$s$ 可能是：

  • Active：program 当前在 backend 上运行或占用 KV cache；
  • Paused：program 被暂停，可能在 global waiting queue 中；
  • Terminated / STOPPED：program 已结束，资源应被释放。

ThunderAgent 的接口和可移植性

论文附录 B 进一步说明 ThunderAgent 的系统集成方式。ThunderAgent 作为一个 program-aware runtime layer，位于 agent control flow 和 backend inference engine 之间。它通过 OpenAI-style endpoint 与后端交互，不要求大幅修改现有 vLLM / SGLang API。

采用 ThunderAgent 主要需要三个变化，如 Figure 8 所示：

  1. LLM request 中附加 program id：
extrabody["program id"] = "PID"
chat_completion(model_id, messages, extrabody)
  1. Tool execution 中也传入 program id：
run_tool(command, sandbox, program_id="PID")
  1. Program 结束时显式发送 release signal：
POST /programs/release
{"program id": "PID"}

其他 OpenAI-style API 字段保持不变。因此 ThunderAgent 的部署成本较低，不需要重写整个 agent framework。

附录中还给出了 ProgramState 和 BackendState 的关键字段。

ProgramState 包括：

Field Type Meaning
status ProgramStatus 当前生命周期状态
backend_url str 当前分配的 backend endpoint
step_count int 已执行步数
total_tokens int 全历史 token 数

ProgramStatus 的语义包括：

Status Meaning
REASONING On-GPU inference
ACTING Off-GPU tool execution
PAUSED In global paused waiting set
STOPPED Released; resources reclaimed

BackendState 包括：

Field Type Meaning
url str backend endpoint
healthy bool backend 是否可用于 scheduling
cache_config Optional[CacheConfig] 启动时获取的静态 cache 配置
active_program_tokens int 当前 backend 上 active programs 的 token footprint

这些字段说明 ThunderAgent 的调度并不依赖某个具体 inference backend 内部实现，而是依赖抽象状态视图。

4.2 Cost Model

论文使用 cost model 指导 ThunderAgent 的调度设计。核心思想是区分：

  • 哪些资源消耗是在做有效推理；
  • 哪些资源消耗是系统浪费。

在 multi-turn agentic inference 中，只有 active prefilling 和 decoding 直接贡献有效 throughput。相反，以下行为都属于 non-productive usage：

  • re-computation；
  • unused capacity；
  • idle caching。

论文采用 Space-Time Product, STP 作为主要指标。STP 定义为 memory footprint 对 processing time 的积分：

$$ Cost_x = \int_0^{t_x} M_x(t) , dt $$

其中：

  • $x$ 表示某个 process phase，例如 prefill、decode、recompute；
  • $t_x$ 是 phase $x$ 持续的时间；
  • $M_x(t)$ 是时刻 $t$ 的 memory footprint。

由于 LLM 的 KV cache memory usage 可以用 token count 近似表示，因此论文将 cost model 简化为 token count over time 的积分。

总成本分解为五部分：

$$ Cost_{total} \approx Cost_{decode} + Cost_{prefill} + Cost_{recompute} + Cost_{unused} + Cost_{caching} $$

这五项分别表示：

1. $Cost_{decode}$

这是模型正在 decode 输出 token 的成本。它是有效成本，因为 decode 直接产生 agent 的 thought 或 action。

2. $Cost_{prefill}$

这是模型处理新输入、新 observation 或工具执行结果的成本。它也是有效成本。需要注意的是，论文区分了两种 prefill：

  • incremental prefilling：处理工具返回的新 observation，这是必要且有效的；
  • historical recomputation：由于 KV cache 被 evict，不得不重新 prefill 整个历史上下文，这是浪费。

3. $Cost_{recompute}$

这是 KV cache thrashing 导致的历史上下文重新计算成本。它来自 Section 3.1 中的 KV cache thrashing。

例如一个 workflow 已经积累了 30K tokens，如果工具执行期间 KV cache 被释放，工具返回后必须重新 prefill 30K tokens。这部分就是 $Cost_{recompute}$。

4. $Cost_{unused}$

这是由于跨节点 memory imbalance 造成的未利用资源成本。比如 Backend #1 已经内存满了，需要暂停 programs，但 Backend #3 还有空闲 HBM。如果没有全局调度，这些空闲资源无法被利用，就产生 $Cost_{unused}$。

5. $Cost_{caching}$

这是 Acting program 在等待工具时占用 GPU HBM 的成本。如果工具很快返回，保留 KV cache 很划算；但如果工具长时间运行，KV cache 长时间占用 HBM 却不产生有效 decode/prefill，就会造成 idle caching。

因此 ThunderAgent 的优化目标不是简单最大化 KV hit rate，而是：

$$ \min \left(Cost_{recompute} + Cost_{unused} + Cost_{caching}\right) $$

同时保持：

$$ Cost_{decode} + Cost_{prefill} $$

尽可能用于有效吞吐。

这点非常关键。很多系统容易把 KV cache hit rate 当成唯一指标，但论文指出在工具延迟高度随机的场景中，更高 KV hit rate 不一定意味着更高 throughput。因为 pin 太多长时间 acting programs 的 KV cache，会增加 $Cost_{caching}$，使 ready-to-run reasoning programs 无法获得 GPU memory。

4.3 Scheduling Policy

Based on the cost model above, the optimization target of the scheduling policy is to minimize non-productive overhead components:

$$ Cost_{recompute}, \quad Cost_{unused}, \quad Cost_{caching} $$

从而最大化 throughput。

ThunderAgent 的 scheduling policy 可以分成两个层次：

  1. 单 backend 内部：用 program-aware waiting queue 降低 recomputation 和 caching costs；
  2. 多 backend 全局：用 global program-aware waiting queue 降低 memory imbalance 和 unused cost。

4.3.1 Reducing Recomputation and Caching Costs via Program-Aware Waiting Queue

KV cache thrashing 是吞吐下降的主要瓶颈。要降低 $Cost_{recompute}$，系统必须显式控制 active programs 的数量，避免 backend 上 program memory demand 超过 KV cache capacity。

ThunderAgent 引入 program-aware waiting queue。这个队列不是普通 request queue，而是以 program 为单位管理。调度器根据每个 program 的：

  • token length $c$；
  • execution phase $\tau$；
  • scheduling status $s$；
  • backend placement $\mathcal{L}$；

决定哪些 program 应该在 GPU 上 active，哪些 program 应该 pause 到 waiting queue。

论文将 scheduler 行为形式化为两个 primitive operations：Restore 和 Pause。

Restore

Restore 表示将一个 paused program 恢复到 active execution。

给定：

$$ P = \langle ID, c, T, \mathcal{L}, \tau, s \rangle $$

如果：

$$ s = Paused, \quad \mathcal{L} = \emptyset $$

则 Restore 操作会把 $P$ 分配到一个有可用容量的 backend $\mathcal{L}’$，并更新为：

$$ P \leftarrow \langle ID, c, T, \mathcal{L}’, \tau, Active \rangle $$

直观理解：Restore 就是让一个等待队列中的 program 重新进入 GPU backend 执行。

Pause

Pause 表示将一个 active program 从 backend 中移除，释放它的 KV cache。

给定：

$$ P = \langle ID, c, T, \mathcal{L}, \tau, s \rangle $$

如果：

$$ s = Active $$

则 Pause 操作会解绑 backend placement，释放其 KV cache，并更新为：

$$ P \leftarrow \langle ID, c, T, \emptyset, \tau, Paused \rangle $$

直观理解：Pause 并不意味着 workflow 结束，而是让 program 暂时离开 GPU active set。未来它仍可被 Restore。

Periodic thrashing detection

ThunderAgent 使用周期性监控来检测 backend 是否即将发生 KV cache thrashing。对于某个 DP backend $\mathcal{L}$，如果所有 active programs 的 token demand 超过总容量，就认为发生或即将发生 thrashing：

$$ C_{total} < \sum_{p \in \mathcal{L}} c_p $$

其中：

  • $C_{total}$ 是 backend 的固定 KV cache token capacity；
  • $p \in \mathcal{L}$ 表示当前放在 backend $\mathcal{L}$ 上的 active programs；
  • $c_p$ 是 program $p$ 的 context token 数。

为什么需要 periodic detection？

因为 agent workflow 的 context length 会在 decoding 过程中快速增长。即使没有新的 request 到来，当前 active programs 的 $c_p$ 也可能随着时间增加而超过容量。因此，只在 workflow arrival 时检查 capacity 是不够的。ThunderAgent 每隔 $\Delta t$ 检查一次 backend state，从而在中途发现 memory pressure。

当 thrashing 即将发生时，ThunderAgent 调用 Pause，释放需要的容量：

$$ \Delta C = \sum_{p \in \mathcal{L}} c_p - \lambda_{max} \cdot C_{total} $$

系统会暂停部分 active programs，直到总内存使用低于：

$$ \lambda_{max} \cdot C_{total} $$

反过来，如果 backend 有可用容量：

$$ \sum_{p \in \mathcal{L}} c_p < \lambda_{min} \cdot C_{total} $$

则 ThunderAgent 会从 waiting queue 中 Restore paused programs，并保证 restore 后 memory usage 不超过：

$$ \lambda_{max} \cdot C_{total} $$

这里 $\lambda_{max}$ 和 $\lambda_{min}$ 是 high-watermark 和 low-watermark，形成 hysteresis window，避免频繁 pause / restore 抖动。论文实践中将两者都设为 1，因为不同 programs 通常共享相似 prompt，这本身会隐式保留一定 buffer。

为什么还需要 time-decay function

如果只做 capacity check，ThunderAgent 可以减少 KV cache thrashing，因为它会为 active programs 保留足够内存。但这样会带来另一个问题：Acting programs 在等待工具时，其 KV cache 可能长期占用 GPU HBM，却不产生有效 decode 或 prefill。

这会增加：

$$ Cost_{caching} $$

因此 ThunderAgent 在 capacity check 中加入 time-decay mechanism，对 acting programs 的有效权重进行折扣：

$$ C_{total} < \sum_{p \in \mathcal{L}, \tau = R} c_p + \sum_{q \in \mathcal{L}, \tau = A} c_q \times f(t_q) $$

其中：

  • $\tau = R$ 表示 reasoning programs；
  • $\tau = A$ 表示 acting programs；
  • $t_q$ 是 program $q$ 在当前 step 中的 tool execution time；
  • $f(t)$ 是 time-decay function。

这个公式的含义是：

  1. Reasoning program 正在 GPU 上做有效推理，所以它的 token demand 全额计入 capacity check。
  2. Acting program 正在等待工具，它的 KV cache 是否值得保留取决于等待时间。
  3. 如果刚进入 acting，$t_q$ 很小，$f(t_q)$ 接近 1，说明系统仍倾向于保留它的 KV cache。
  4. 如果 acting 时间很长，$f(t_q)$ 变小，说明该 KV cache 的优先级下降，系统更倾向于 evict 它以减少 idle caching。

附录 C 说明实际工具执行时间具有明显不确定性。对于 HLE-search、HLE-enhance-reasoning、SAB-execute_bash、SAB-execute_ipython_cell 等工具，p95 / p99 延迟远高于 median，并且 tail 可以达到几十秒甚至几百秒。因此固定 TTL 很容易失效。

附录 E.1 给出 time-decay function 的理论推导。假设工具返回时间不可可靠预测，且 decay function 只依赖 elapsed acting time，那么应满足 time-homogeneous property：

$$ f(t + \Delta) = f(t)\phi(\Delta) $$

令 $t = 0$ 且 $f(0) = 1$，可得：

$$ \phi(\Delta) = f(\Delta) $$

因此：

$$ f(t + \Delta) = f(t)f(\Delta) $$

在连续时间下，对两边取对数，令：

$$ h(t) = \ln f(t) $$

得到 Cauchy functional equation：

$$ h(t + \Delta) = h(t) + h(\Delta) $$

在有界条件下，其解为线性形式：

$$ h(t) = ct $$

令 $\lambda = -c$，得到指数衰减：

$$ f(t) = e^{-\lambda t}, \quad \lambda > 0 $$

在离散 tick time 下，得到几何衰减：

$$ f(k) = x^{-k}, \quad x > 1 $$

论文实验中使用：

$$ f(t) = 2^{-t} $$

这说明 ThunderAgent 并不是简单保留或释放 KV cache，而是根据 acting time 动态降低 long-idle acting programs 的 memory priority。

Minimizing $Cost_{recompute}$ via Shortest-First Eviction

当系统需要释放 $\Delta C$ 容量时，关键问题是：应该 pause 哪些 programs？

ThunderAgent 使用 Shortest-First Eviction，即优先 pause / evict context length 最短的 programs。其理论基础是 recomputation cost 与 context length 的平方成正比。

论文给出 Lemma 4.1：

给定 program $P_i$，其 context length 为 $c_i$，重新 prefill 它的 KV cache 产生的 recomputation cost 近似满足：

$$ Cost_{recompute}

\int_0^{t_{recompute}} c_i(t) , dt \propto c_i^2 $$

附录 E.2 进一步解释：chunked prefill 每次处理固定数量的 KV pairs，因此累计计算量随 prefill 进度线性增加；对时间积分后得到二次成本。若：

$$ t_{recompute} = c_i \times T_{decode/chunk} $$

且 $T_{decode/chunk}$ 和 chunk size 为常数，则：

$$ Cost_{recompute} \propto c_i^2 $$

因此，当需要释放容量 $\Delta C$ 时，可以定义 eviction optimization problem：

$$ \min_S \sum_{i \in S} c_i^2 $$

subject to:

$$ \sum_{i \in S} c_i \ge \Delta C $$

这里：

  • $S$ 是要 evict 的 program 集合；
  • 约束要求释放的总容量至少为 $\Delta C$；
  • 目标是最小化未来 recomputation cost。

由于平方函数是 strictly convex and super-additive，也就是：

$$ (a + b)^2 > a^2 + b^2 $$

对正数 $a,b$ 成立。因此，驱逐一个大 context program 的成本比驱逐多个小 context program 更高。

举例：

如果需要释放 20K tokens：

方案 A：驱逐一个 20K program，成本约为：

$$ (20K)^2 = 400M $$

方案 B：驱逐两个 10K program，成本约为：

$$ (10K)^2 + (10K)^2 = 200M $$

释放容量相同，但方案 B 的 recomputation cost 更低。这就是 shortest-first eviction 的直觉。

附录 E.3 使用 exchange argument 证明：如果某个最优集合中包含一个 long program，但没有包含一个可用的 short program，则可以通过交换或分解 long program 来降低平方和成本。因此，选择 context length 最小的 programs 是全局最优策略。

Restore 和 Pause 的调度分数

基于上述分析，ThunderAgent 定义两个调度分数：

$$ S_{restore}(P) = \frac{1}{c_P} + I(\tau = R) $$

$$ S_{pause}(P) = \frac{1}{c_P} + I(\tau = A) $$

其中 $I(\cdot)$ 是 indicator function。

这两个分数的含义如下。

Restore score

$$ S_{restore}(P) = \frac{1}{c_P} + I(\tau = R) $$

Restore 时优先恢复：

  1. 当前处于 Reasoning 状态的 program；
  2. context length 较短的 program。

原因是 Reasoning program 一旦恢复，就可以立即产生有效 prefill / decode 工作，从而提升 throughput。短 context program 更容易放进 backend，并且恢复成本更低。

Pause score

$$ S_{pause}(P) = \frac{1}{c_P} + I(\tau = A) $$

Pause 时优先暂停：

  1. 当前处于 Acting 状态的 program；
  2. context length 较短的 program。

原因是 Acting program 正在等待工具，不产生有效 GPU 计算；暂停它可以回收 idle caching memory。短 context program 未来 recomputation cost 较低，因此优先 evict 它更符合 shortest-first policy。

这里 indicator function 的作用是让 execution state 的优先级高于 context length。也就是说，系统优先根据 Reasoning / Acting 判断 program 是否应该恢复或暂停，然后再根据 context length 做细粒度排序。

总结一下，ThunderAgent 的单节点调度逻辑是：

  1. 周期性检查 backend KV cache capacity；
  2. 如果即将 thrashing，则 pause 一些 active programs；
  3. 优先 pause Acting programs；
  4. 在 Acting programs 中优先 pause context 较短的；
  5. 如果 backend 有空闲，则 restore waiting programs；
  6. 优先 restore Reasoning programs；
  7. 在 Reasoning programs 中优先 restore context 较短的；
  8. 对长时间 Acting programs 使用 $f(t)$ 降低其 KV cache 保留优先级。

4.3.2 Reducing Memory Imbalance via Global Program-Aware Waiting Queue

Section 3.2 和 Figure 2a 表明，跨节点 memory imbalance 会导致显著 $Cost_{unused}$。如果某些 nodes 还有空闲 HBM，而 paused programs 却因为 locality 或 queue 分散无法被调度过去，就会造成不必要的 program pausing 和吞吐损失。

ThunderAgent 的解决方案是：

unify waiting queues of all backend replicas into a global program-aware waiting queue.

也就是说，所有 backend replicas 共享一个全局等待队列，而不是每个 backend 维护自己的局部队列。

这一设计的关键动机是：当一个 program 已经被 pause 后，它的 KV cache 通常已经被 evicted，因此 future recomputation cost 不再与原 backend 绑定。既然恢复时都需要 recompute，那么它恢复到哪个 backend 都可以。因此，ThunderAgent 可以将 paused program 调度到任何具有 available memory capacity 的 backend。

这带来两个好处。

1. 不牺牲 KV locality 的前提下提升 load balancing

对于仍然 active 且 KV cache 保留在原节点的 program，ThunderAgent 仍可利用 locality。但对于已经 paused 且 KV cache 被释放的 program，继续强行送回原节点没有意义。此时更合理的目标是 load balancing。

2. 降低 $Cost_{unused}$

如果某个 backend 有空闲 memory，而全局队列中有 paused programs，就可以直接 restore 到该 backend。论文给出 unused cost bound：

$$ C_{unused} < c_{min} \cdot \Delta t $$

其中：

  • $c_{min}$ 是 paused programs 中最小 token length；
  • $\Delta t$ 是 periodic monitor interval。

由于 $\Delta t$ 相对 program lifetime 很小，系统可以在较短时间内发现空闲 backend 并调度 waiting programs，从而减少 unused memory cost。

Figure 3 中的例子正是这种机制：Backend #1 发生 thrashing，Backend #3 underutilized。ThunderAgent 将 Backend #1 的 acting Program #2 pause 回 global waiting queue，同时将 Program #6 和 Program #9 restore 到 Backend #3，从而同时解决局部 thrashing 和全局 imbalance。

4.4 Tool Resource Management

ThunderAgent 还通过 program-level abstraction 管理 tool resources，解决 Section 3.3 中的 resource leakage 和 environment setup overhead。

Hook-based garbage collection

ThunderAgent 实现 lifecycle hooks，将 tool resource persistence 与 program scheduling status $s$ 严格绑定。

当一个 program 状态变为 Terminated / STOPPED 时，collector 会立即触发 teardown sequence，系统性回收：

  • Docker sandboxes；
  • network sockets；
  • compute slots；
  • disk directories；
  • temporary files；
  • API server resources；
  • tool execution environment。

这与普通 Kubernetes / Docker orchestrator 的区别在于：ThunderAgent 知道 program lifecycle，因此它可以准确判断资源何时不再需要。普通 request-aware system 不知道 workflow 是否结束，容易将已经完成的 sandbox 长期保留。

Figure 2b 中 active disk usage 基本保持稳定，说明真正正在运行的 workflow 需要的磁盘资源是有限的；总 disk usage 线性增长主要来自未回收的历史资源。ThunderAgent 的 hook-based GC 可以避免这种累积。

Asynchronous environment preparation

工具环境初始化可能是 agentic workflow 的瓶颈。比如 coding agent 启动前需要：

  • start Docker container；
  • clone / checkout repository；
  • install dependencies；
  • run setup script；
  • build project；
  • prepare testing environment。

如果这些操作在 program 被 restore 到 GPU 后才开始执行，会导致 GPU 或 workflow 等待环境准备完成。

ThunderAgent 的做法是：监控 global waiting queue。当某个 high-priority program，即具有较高 $S_{restore}$ 的 program，接近 restore threshold 时，系统提前异步恢复它的 tool execution environment，而不是等 GPU memory 已经分配后才准备。

这样可以将 I/O-intensive environment initialization 与 LLM reasoning 重叠。对 coding agents 和 science agents 这类 tool-call-heavy workloads 来说，这可以显著降低 end-to-end latency。

附录中的相关设计补充

为什么单纯 KV cache offloading 不够

附录 A.2 测试了使用 LMCache 做 KV cache offloading。理论上，offloading 可以把 inactive KV cache 放到 CPU DRAM 或 SSD 中，从而扩展有效 memory capacity。但论文实验发现，在 agentic workloads 中，context switching 很频繁，KV 数据量很大，PCIe bandwidth 难以支撑高频 swap-in / swap-out。

Figure 7a 显示，在 GLM-4.6 + mini-SWEAgent 中使用 vLLM + LMCache，随着 parallel program number 增加，KV cache hit rate 下降到接近 0%，throughput 也明显下降。这说明 offloading 带来的 latency penalty 抵消了 memory capacity benefit。

因此，ThunderAgent 不是简单地把 KV cache 换到 CPU/SSD，而是在 program-level 控制哪些 KV cache 值得保留，哪些应该释放。

为什么 Prefill-Decode disaggregation 不够

附录 A.2 还测试了 PD disaggregation。PD disaggregation 是普通 chatbot serving 中常见优化，将 prefill 和 decode 分离到不同节点，减少互相干扰。

但在 agentic workloads 中，context 持续增长，prefill demand 本身非常重。如果将 cluster 切分成 prefill-only 和 decode-only nodes，prefill 可用 HBM pool 反而变小，更早达到 capacity limit，从而加重 thrashing。

Figure 7b 显示，不同 PD ratio 下 throughput 仍低于 aggregated serving。论文结论是，generic architectural optimizations 不能替代 program-centric scheduler。

Tool execution time variability

附录 C 进一步解释为什么 Continuum 的 TTL 机制难以稳定工作。不同 tool bucket 的延迟来源不同：

Tool bucket Role Primary variability source
HLE-search Retrieve evidence Remote service，network latency，rate limits
HLE-enhance-reasoning Model-as-a-tool call Remote service
HLE-answer Final generation Local LLM inference
SAB-execute bash Shell execution Sandbox and I/O
SAB-execute ipython cell Python cell execution Program runtime
SAB-str replace editor File edit Local filesystem
SAB-task tracker Task state tracking Local filesystem

Figure 9 显示部分工具的 p95 / p99 延迟显著高于 median，存在 heavy-tailed behavior。因此工具延迟缺乏稳定中心趋势，预测本身就很脆弱。

固定 TTL 会有两种失败模式：

  1. Underestimation 如果低估工具时间，系统会过早释放 KV cache，工具返回后触发 recomputation。

  2. Overestimation 如果高估工具时间，系统会过久 pin KV cache，导致 idle caching cost 增加，其他 ready programs 无法运行。

ThunderAgent 用 cost model 和 time-decay function 动态平衡 $Cost_{recompute}$ 和 $Cost_{caching}$，比固定 TTL 更适合工具延迟不稳定的场景。

5. Experiments

论文在 Section 5 中评估 ThunderAgent，覆盖 serving、RL rollout 和 ablation study。实验目标是验证：

  1. ThunderAgent 是否能在高并发 agent serving 中提升 throughput；
  2. ThunderAgent 是否能提高 KV cache hit rate 或在必要时合理牺牲 hit rate 换取更高吞吐；
  3. ThunderAgent 是否能缓解 RL rollout 场景中的 memory pressure；
  4. ThunderAgent 的工具资源管理是否能降低 latency 和 disk usage；
  5. ThunderAgent 对参数 $\Delta t$ 和 $f(t)$ 是否敏感；
  6. 通用 KV offloading 和 PD disaggregation 是否可以替代 program-aware scheduling。

5.1 Experimental setup

Benchmarks and workflows

论文评估了多种 agentic workloads。

1. Coding agent serving

使用：

  • OpenHands；
  • mini-SWEAgent；
  • 数据集：SWE-Bench Lite。

OpenHands 是 heavy-initialization workflow。每个 sandbox 平均 disk footprint 超过 10GB。这类 workload 非常适合验证 tool resource management，因为如果 Docker / repository / dependency 没有及时回收，磁盘资源会快速耗尽。

mini-SWEAgent 是 lightweight workflow，每个 sandbox footprint 约 2GB，更适合测试 KV cache scheduling 对吞吐的影响。

2. Other agent serving

使用：

  • ToolOrchestra on HLE；
  • OpenHands on ScienceAgentBench。

这些 workloads 包含更多 variable-latency tool calls。例如 HLE 场景中会调用 remote-service tools，ScienceAgentBench 中会执行科学计算、bash 命令、Python cell 等。这类 workload 的工具执行时间更随机，更能测试 ThunderAgent 的 time-decay policy。

3. RL rollout

论文还在 agentic RL rollout 场景中评估 ThunderAgent。使用相同 models、workflows 和 samples，在两个 8×H100 nodes 上运行。RL rollout 对 throughput 很敏感，因为 rollout 时间占 RL 总 wall-clock time 的比例很高。

Models and deployments

论文使用以下模型和部署方式：

  1. GLM-4.6 / GLM-4.6 MoE，355B 用于 SWE-Agent、OpenHands、ScienceAgent 等 workload。

  2. Qwen-3，235B 用于 SWE-Agent、OpenHands 等大型模型 serving。

  3. Qwen3-8B 用于 ToolOrchestra on HLE，FP16 precision，部署在 RTX 5090。

大模型采用 FP8 quantization，并使用 Tensor Parallelism，TP8，部署在 8×H100 nodes 上。论文将 LLM inference engine 和 Docker clusters 分开部署：

  • GPU cluster 负责模型推理；
  • dedicated CPU cluster 负责 agent Docker environments。

这种部署更接近真实系统：GPU 是昂贵推理资源，CPU / disk / network 负责工具执行和环境管理。

ThunderAgent configuration

ThunderAgent 默认配置：

$$ \Delta t = 5 $$

priority decay function：

$$ f(t) = 2^{-t} $$

其中 $\Delta t$ 是 periodic thrashing detection interval，$f(t)$ 是 acting program 的 time-decay function。

LLM inference engine 使用 vLLM。Throughput metric 使用 steps per minute。一个 step 包括 workflow 的一个 reasoning period 和一个 acting period。

Baseline techniques

论文比较了三类 baseline。

1. vLLM

vLLM 是 widely adopted request-aware LLM inference engine。它作为 stateless baseline，没有 agent-aware 或 program-aware 机制。它主要代表传统 LLM serving 系统在 agentic workload 下的表现。

2. Continuum

Continuum 是当前 SOTA multi-turn agentic workflow serving system。它通过预测 tool execution duration，并在 HBM 中 pin KV cache 来缓解 context thrashing。

它的主要弱点是：

  • 依赖工具时间预测；
  • 面对 stochastic tool execution time 时容易 mispredict；
  • 高并发下如果 active decoding memory 超出 GPU limit，仍会 evict pinned KV cache；
  • 可能为了追求 KV hit rate 而增加 idle caching cost。
3. vLLM + SGLang Gateway

用于 distributed RL rollout baseline。SGLang Gateway 优化 distributed inference 中的 cross-node memory balancing 和 KV cache hit rate，因此是 rollout 场景下较强的 baseline。

5.2 Serving Evaluation Results

Figure 4 展示 serving evaluation results。ThunderAgent 在三种模型、四种 agentic workflows 和三个 datasets 上均明显超过 vLLM 和 Continuum。

论文报告，在高并发下，例如 96 parallel programs，ThunderAgent 相比 vLLM 获得：

$$ 1.48\times \sim 3.58\times $$

throughput speedup；相比 Continuum 获得：

$$ 1.17\times \sim 3.31\times $$

speedup。

Figure 4 的具体观察

Figure 4 包含 6 个子图：

  1. SWEAgent-GLM4.6 parallel workflow number 为 24、48、72、96。ThunderAgent 在高并发下仍保持高 throughput，而 vLLM 和 Continuum 在高并发时下降。ThunderAgent 标注 speedup 为 2.65×，Continuum 为 1.52×。

  2. OpenHands(code)-GLM4.6 OpenHands 更重，工具环境初始化更复杂。ThunderAgent 在高并发下的优势更明显，达到 3.58×。Continuum 在该场景下只达到 1.08×。

  3. ToolOrchestra(HLE)-Qwen3-8B 工具调用时间更随机，ThunderAgent 仍优于 vLLM 和 Continuum，speedup 为 1.48×。Continuum 在该场景下甚至低于 vLLM，只有 0.65×，说明 TTL-based pinning 在 stochastic tool latency 下可能增加 caching cost。

  4. SWEAgent-Qwen3-235B 在更大模型上，ThunderAgent 也能保持优势，speedup 为 3.02×。

  5. OpenHands(code)-Qwen3-235B ThunderAgent speedup 为 2.43×，Continuum 为 1.22×。

  6. ScienceAgent-GLM4.6 科学发现 agent 中工具执行更复杂且随机，ThunderAgent 仍是最好，speedup 为 1.24×，Continuum 为 1.06×。

这些结果说明 ThunderAgent 的收益不是来自某个特定模型或某个特定 agent framework，而是来自 agentic inference 的通用资源管理问题。

High throughput under high concurrency

ThunderAgent 在高并发下仍能保持较高 throughput。原因主要有两个：

  1. Program-aware scheduler 通过 pause / restore 控制 active programs 数量，避免 KV cache thrashing；
  2. Tool resource manager 通过 asynchronous environment preparation 隐藏工具环境准备开销。

相比之下，Continuum 在高并发下仍然性能下降。虽然它用 TTL 保留 KV cache，但当 GPU memory 不足时，active programs 之间仍然会竞争有限内存，导致 pinned KV cache 被迫 evict。

Robustness to high concurrency

ThunderAgent 能够在 parallel workflow number 超过 GPU memory limit 后仍保持接近最大可达 throughput。实际 agent serving 中，很难提前静态确定最优 parallel workflow number，因为：

  • 不同 workflow 长度不同；
  • 工具执行时间随机；
  • context 增长速度不同；
  • 有些 workflow 会长时间 acting；
  • 有些 workflow 会快速返回 reasoning。

如果系统需要人工调 batch size 或并发数来避免 thrashing，部署会很困难。ThunderAgent 通过 runtime monitoring 自动适应 capacity，因此更适合真实部署。

Robustness across deterministic and stochastic tool executions

ThunderAgent 不仅在 deterministic / predictable tool patterns 上表现好，也能在 stochastic tool execution time 下表现好。

对于工具时间稳定的 workload，如 SWEAgent、OpenHands，ThunderAgent 保持接近 100% KV hit rate，避免 re-prefill。

对于工具时间高度随机的 workload，如 ToolOrchestra 和 ScienceAgent，ThunderAgent 不会盲目追求最高 KV hit rate，而是通过 $f(t)$ 在 recomputation 和 idle caching 之间做动态权衡。即使 KV hit rate 有时低于 Continuum，它仍能实现更高 throughput，因为它减少了 long-idle acting programs 对 HBM 的占用，让 ready reasoning programs 获得更多 GPU 资源。

Figure 5: KV Cache Hit Rate Statistics

Figure 5 展示不同 workload 下的 KV cache hit rate。

主要结论如下。

1. Predictable tool call time 下，ThunderAgent hit rate 接近最优

在 SWEAgent 和 OpenHands 等场景中，工具执行时间相对稳定。ThunderAgent 能保持接近 100% 的 KV cache hit rate。这说明 program-aware scheduler 能够准确保留短期内会 resume 的 KV cache，从而避免 re-prefill。

2. Continuum 在高并发下 hit rate 下降

Continuum 在低并发时可能 hit rate 较高，但随着 parallel workflow number 增加，其 hit rate 从 90% 以上下降到约 60%。原因是 TTL pinning 无法阻止 active programs decode memory 超过 GPU limit 后的强制 eviction。

3. Stochastic tool call time 下，高 hit rate 不一定等于高 throughput

在 ToolOrchestra 和 ScienceAgent 等工具时间随机的场景中，Continuum 可能通过长期 pin KV cache 获得较高 hit rate，但这会增加 $Cost_{caching}$，导致 GPU HBM 被等待工具的 programs 占用，降低有效 throughput。

ThunderAgent 在这类场景中可能主动牺牲一部分 hit rate，evict long-idle acting programs 的 KV cache，从而释放 HBM 给 ready programs。最终 throughput 更高。

这个现象非常重要，因为它说明：

KV cache hit rate 是中间指标，不是最终目标。 ThunderAgent 真正优化的是整体 throughput 和资源有效利用率。

5.3 Rollout Evaluation Results

Table 2 展示 GLM-4.6 在两个 H100 nodes 上进行 RL rollout 的结果，parallel program number $N = 144$，运行时间为 3 小时。

结果如下：

Workflow Serving System Throughput
mini-SWEAgent vLLM + Gateway 375.4
mini-SWEAgent ThunderAgent 671.8 (1.79×)
OpenHands vLLM + Gateway 69.1
OpenHands ThunderAgent 270.8 (3.92×)

这些结果说明 ThunderAgent 不仅适用于 online serving，也适用于 agentic RL rollout。

RL rollout 场景的特点是：

  1. 需要大规模并发生成 trajectories；
  2. 每条 trajectory 是多轮 agent workflow；
  3. rollout 占 RL 总时间比例很高；
  4. 如果 rollout throughput 低，会导致 training data stale；
  5. 异步 RL 中 policy lag 会变大。

ThunderAgent 通过减少 KV cache thrashing、缓解跨节点 memory imbalance、管理工具资源，显著提升 rollout throughput。尤其是 OpenHands 这种 heavy-initialization workflow，ThunderAgent 的提升达到 3.92×，说明工具资源管理和 program-aware scheduling 对复杂 coding agents 特别重要。

5.4 Ablation Study

Figure 6 展示两个消融实验：

  1. End-to-end latency breakdown；
  2. 参数 $\Delta t$ 和 $f(t)$ 的敏感性。

End-to-end latency breakdown

Figure 6a 分解了 OpenHands rollout 的平均 E2E latency。

结果显示：

  • vLLM 平均 E2E latency 约为 58s；
  • ThunderAgent 平均 E2E latency 约为 12s；
  • vLLM disk usage 约为 3.3TB；
  • ThunderAgent disk usage 约为 0.8TB；
  • 工具资源管理提供约 10% latency improvement；
  • disk memory savings 达到 4.2×。

主要收益来自 prefill 和 decode latency 的降低。这说明 ThunderAgent 通过减少 re-prefill 和 KV thrashing，让 GPU 时间更多用于有效工作，而不是重复计算历史上下文。

Ablation on $\Delta t$ and $f(t)$

Figure 6b 测试了 periodic detection interval $\Delta t$ 和 decay function：

$$ f(t) = x^{-t} $$

实验在单 H100 node 上，用 GLM4.6 + mini-SWEAgent 做 offline serving。

结论是 ThunderAgent 对参数较鲁棒，但仍有趋势：

  1. $\Delta t$ 太大时 throughput 会下降 因为检测周期太长，thrashing 可能在两次检测之间发生，从而降低 KV hit rate。

  2. $x$ 太大时 throughput 会下降 因为 $f(t)=x^{-t}$ 衰减更快，acting programs 会更早被 evict。这样虽然减少了 idle caching，但也会增加 recomputation，尤其是那些工具调用其实很快返回的 programs 会被过早驱逐。

  3. 适中的 $\Delta t$ 和 $x$ 可以平衡 recomputation 和 caching 论文默认使用 $\Delta t = 5$ 和 $f(t)=2^{-t}$，在实验中表现稳定。

Appendix Experiments: KV offloading 和 PD disaggregation

论文附录中的 Figure 7 进一步说明，通用 KV cache optimization 或 chatbot serving 架构优化不能替代 ThunderAgent。

KV cache offloading with LMCache

Figure 7a 显示，使用 vLLM + LMCache 进行 KV cache offloading 时，随着 parallel program number 增加，KV cache hit rate 从较高值快速下降到接近 0%，throughput 也显著下降。

原因是 agentic workload 中频繁 context switch 和大规模 KV transfer 会受到 PCIe bandwidth 限制。每次 swap-in / swap-out KV cache 的代价太大，抵消了扩展 memory capacity 的收益。

Prefill-Decode disaggregation

Figure 7b 测试不同 prefill-only / decode-only node ratio：

  • 1:3；
  • 2:2；
  • 3:1。

结果显示 throughput 仍低于 aggregated serving。原因是 agentic workflow context 持续增长，prefill pressure 很大。如果把集群切分为 prefill-only 和 decode-only nodes，prefill 可用 HBM pool 变小，反而更早触发 thrashing。

因此论文认为，agentic inference 需要 program-centric scheduler，而不是只依赖 generic KV offloading 或 PD disaggregation。

Appendix F: End-to-End Latency Analysis

附录 F 进一步比较 per-step E2E latency。虽然论文在 Introduction 中强调，对 autonomous agents 和 RL rollout 来说，program-level latency 和 sustained throughput 比每一步 latency 更重要，但作者仍然评估了平均 per-step latency。

Figure 10 显示，在 GLM4.6 和 Qwen3-235B 上，mini-SWEAgent 和 OpenHands 的低并发和高并发设置中，ThunderAgent 的 per-step latency 都显著低于 vLLM 和 Continuum。

这进一步说明 ThunderAgent 不是通过牺牲每步 latency 换 throughput。相反，它减少了 heavy KV-cache thrashing，因此同时改善了吞吐和平均 per-step latency。

6. Conclusion

We introduce ThunderAgent, a fast and simple agentic system built on a program-level abstraction that tracks metadata throughout the entire lifecycle of each agentic workflow.

这篇论文的核心结论是：在 Agent 时代，LLM inference system 不应该只围绕 request 做调度，而应该围绕 agentic program 做调度。Agent workflow 具有长期状态，跨越多次模型调用和多次工具调用，同时消耗 GPU KV cache、CPU、disk、network port、Docker sandbox 等异构资源。传统 request-aware system 看不到这些 workflow-level dependencies，因此会产生 KV cache thrashing、cross-node memory imbalance 和 tool lifecycle obliviousness。

ThunderAgent 通过以下设计解决这些问题：

  1. Program abstraction 将 workflow 表示为：

    $$ P = \langle ID, c, T, \mathcal{L}, \tau, s \rangle $$

    从而显式记录 program id、context length、tool environment、backend placement、execution phase 和 scheduling status。

  2. Cost model 将 agentic inference 成本分解为：

    $$ Cost_{total} \approx Cost_{decode} + Cost_{prefill} + Cost_{recompute} + Cost_{unused} + Cost_{caching} $$

    并明确优化目标是减少 non-productive overhead，而不是单纯最大化 KV hit rate。

  3. Program-aware scheduler 基于 program state 做 pause / restore。系统优先保留 reasoning programs，优先 pause acting programs，并使用 shortest-first eviction 降低 future recomputation cost。

  4. Time-decay mechanism 使用 $f(t)$ 动态降低 long-idle acting programs 的 KV cache priority，平衡 $Cost_{recompute}$ 和 $Cost_{caching}$。

  5. Global program-aware waiting queue 所有 backend 共享全局等待队列，使 paused programs 可以恢复到任意空闲 backend，缓解 cross-node memory imbalance。

  6. Tool resource management 使用 hook-based garbage collection 回收 Docker sandbox、network sockets、disk resources 等，并通过 asynchronous environment preparation 隐藏工具环境初始化开销。

实验表明，ThunderAgent 在多种 serving workloads 中获得 1.48–3.58× throughput improvements，在 RL rollout 中获得 1.79–3.92× improvements，并带来最高 4.2× disk memory savings。

从更高层面看，这篇论文的重要启发是：

Agentic inference 的系统瓶颈不只是模型推理速度，而是 workflow-level resource management。 当 LLM 从 chatbot 变成 autonomous agent 后，serving system 的基本调度单位也应该从 request 转变为 program。

因此，ThunderAgent 的价值在于提出了一个简洁但有效的 program-aware runtime abstraction，使系统能够统一管理 KV cache、GPU memory、工具环境和 program lifecycle。这种设计对于未来大规模 agent serving、agentic RL rollout、coding agent、scientific discovery agent 和复杂工具调用系统都具有较强参考意义。