ThunderAgent: A Simple, Fast and Program-Aware Agentic Inference System
ThunderAgent: A Simple, Fast and Program-Aware Agentic Inference System
发表时间: 2026-02 · arXiv:2602.13692 (Georgia Tech / CMU / Stanford)
原文: https://arxiv.org/abs/2602.13692
作者/机构: Hao Kang∗1, Ziyang Li $^ { * 2 }$ , Xinyu Yang∗3, Weili Xu $^ { \dag 4 }$ , Yinfang Chen $^ 4$ , Junxiong Wang $^ { 5 }$ , Beidi Chen $^ 3$ , Tushar Krishna1, Chenfeng Xu $^ { 5 }$ , and Simran Arora $^ { 5 }$
$^ { 1 }$ Georgia Institute of Technology, 2Individual Researcher, $^ 3$ Carnegie Mellon University, $^ 4$ University of Illinois Urbana-Champaign, 5Together AI
A1 主要贡献
大型语言模型（LLMs）现已广泛应用于驱动复杂的多轮代理（agentic）工作流。然而，随着并行处理的代理请求数量增加，现有推理系统的吞吐量会下降。同时，在强化学习（RL）中，rollout（数据收集）过程占用了超过70%的总时长。对于大规模自主运行的代理工作流，系统效率由持续吞吐量决定，而非单次请求的尾部延迟。高吞吐量能通过分摊硬件成本来降低服务费用，并在异步强化学习中减轻策略滞后，从而提高收敛速度和最终策略质量。
当前代理推理系统吞吐量不佳，因为它们是松散地组合了独立的组件：一个现成的模型推理引擎（如vLLM）和一个通用的工具编排器（如Kubernetes）。这些组件在没有整个工作流端到端知识的情况下，按单个请求来调度和分配资源。这种设计导致了三个关键挑战：
1. KV缓存颠簸（KV cache thrashing）：请求感知的系统在工具执行期间会过早地驱逐KV缓存，而没有预见到其在代理工作流中未来的重用。这导致工具调用完成后，系统需要重新运行预填充（prefill）以恢复其交互历史，从而显著增加端到端延迟并降低吞吐量。
2. 跨节点内存不平衡：为了最大化KV缓存命中率，现有引擎会将来自同一代理工作流的所有请求固定到同一个节点。然而，由于代理工作流的上下文长度会快速且不可预测地增长，这种路由策略会导致某些节点容量耗尽，而其他节点仍未被充分利用。
3. 工具生命周期无感知：请求感知的编排器难以决定何时释放和准备工具执行所需的环境资源。这导致未使用的沙箱和API服务器持续占用关键的磁盘空间和网络端口，最终引起资源耗尽和系统故障。同时，代理工作流在推理前必须等待漫长的环境设置时间。
为应对这些挑战，本文提出了ThunderAgent，一个为高吞吐量代理服务和RL rollout设计的、端到端视角的代理推理系统。其主要贡献如下：
1. 程序抽象：我们将代理工作流抽象为“代理程序”（agentic programs）。代理程序是一个头等调度单元，它跨越多次模型调用和工具执行持续存在，并向运行时暴露语义状态。一个程序会追踪工作流的标识符、执行阶段（推理或行动）、调度状态、总token数和工具资源等元数据。这种抽象将调度与执行后端（如vLLM/SGLang）解耦，使得新工作流的集成变得无缝。
2. 程序感知的调度器：基于程序抽象，我们将代理推理调度视为一个约束优化问题，目标是在GPU内存容量的限制下，最小化重计算和缓存开销，并最大化预填充和解码的吞吐量。我们引入了两个关键机制：
* 状态感知的暂停（State-aware pausing）：当执行后端遇到内存压力时，系统会选择性地暂停那些当前处于“行动”（acting）状态（即正在调用工具）的工作流。这有助于为处于“推理”（reasoning）状态的程序保留内存，并消除任意、次优的KV缓存驱逐。
* 动态迁移（Dynamic migration）：我们通过让所有数据并行（DP）的GPU节点共享一个全局的程序感知等待队列，来在节点间迁移代理程序，以缓解内存不平衡。这打破了将同一程序的所有请求强制发送到同一节点的限制。
- 程序感知的工具资源管理：在长周期的代理工作负载中，工具环境是持久性资源，其管理不善会直接限制持续吞吐量。通过追踪执行依赖关系，ThunderAgent能够将I/O密集型的环境初始化与LLM推理过程重叠。对于已完成的程序，我们实现了一个生命周期感知的垃圾回收器，它利用程序终止信号来回收Docker沙箱和网络端口等工具资源。这可以防止累积的资源泄漏，确保ThunderAgent能够持续进行高吞-吐量的代理推理。
上述贡献无法在请求感知的推理引擎中实现，因为它们缺乏对程序状态和工作流依赖的显式表示，无法区分临时的工具等待和任务终止，也无法协调GPU内存与程序级别的资源调度。
图1：ThunderAgent与先前代理推理系统在并行工作流数量（即批处理大小）增加时的性能比较。我们在一个8卡H100 GPU集群上评估了服务于SWE-Bench Lite上的SWE-Agent的GLM-4.6 MoE模型（图a和b），以及SWE-Agent、OpenHands和ToolOrchestra（图c）。结果显示：(a) 当前推理系统在较大批处理大小时无法维持高吞吐量。(b) 吞吐量下降主要是由低KV缓存命中率引起的，这增加了端到端的请求延迟。(c) ThunderAgent通过减少KV缓存颠簸和管理工具执行资源的生命周期，与先前的推理系统相比实现了高吞吐量。
A3 背景知识与关键挑战
2 背景
本节介绍代理推理的特性和现有的支持方法。
2.1 当前代理工作流的系统特性
代理工作流在推理和行动之间交替进行。 在每个步骤 $t$，代理接收一个观察 $o_t \in \mathcal{O}$ 并产生一个输出 $e_t = (\ell_t, a_t) \in \mathcal{L} \times \mathcal{A}$，其中 $\ell_t$ 表示思考过程，$a_t$ 表示一个动作。我们将步骤 $t$ 的累积上下文定义为 $c_t = (o_1, e_1, \ldots, o_t)$，它捕获了代理工作流的交互历史。在给定 $c_t$ 的条件下，$e_t$ 从策略 $\pi(e_t | c_t)$ 中采样得到。这个工作流维持着两种持久状态：(i) GPU内存，其中 $c_t$ 的KV缓存作为工作流的记忆。随着轨迹的增量增长，$c_{t+1}$ 将 $c_t$ 作为前缀进行扩展，理论上可以在步骤之间实现近乎完全的KV缓存重用。(ii) 工具环境，其中在 $t=1$ 时初始化的外部资源（如沙箱或数据库连接）必须在整个执行过程中保持一致和可访问。这些状态依赖性要求对代理推理轨迹有一个程序级别的视图，从而使系统能够协调异构资源并管理长时运行工作流的状态。然而，现有的推理系统将每个思考 $\ell_t$ 和动作 $a_t$ 视为独立的、无状态的请求。
2.2 现有代理推理系统
先前工作主要优化代理推理中的单个组件，但缺乏端到端优化。 先前的工作主要集中在优化代理推理中的单个组件，包括LLM推理引擎或工具编排器（详见附录A.1，A.2），但很少有工作为跨GPU、CPU和远程资源的代理工作流提供端到端的优化。我们回顾了这些先前的系统。Autellix【13, Autellix: An efficient serving engine for llm agents as general programs, 2025, URL https://arxiv.org/abs/2502.13965】将多轮代理工作流建模为纯GPU程序，并在一个中央进程表中跟踪累积的GPU执行时间。然而，它忽略了工作流的局部性，允许并发工作流激进地驱逐彼此的KV缓存，在重负载下引发KV缓存颠簸。Continuum 【11, Continuum: Efficient and robust multi-turn llm agent scheduling with kv cache time-to-live, 2025, URL https://arxiv.org/abs/2511.02230】是另一个最近为多轮代理工作流设计的服务系统。它采用“存活时间” （Time-To-Live, TTL）机制将KV缓存固定在HBM中，从而减轻工具执行期间的上下文颠簸。然而，它未能解决KV缓存驱逐问题。第一个原因是大多数工具的执行时间不可预测（例如ToolOrchestra【18, Toolorchestra: Elevating intelligence via efficient model and tool orchestration, 2025, URL https://arxiv.org/abs/2511.21689】中的远程模型API、代码代理中的编译器、以及计算机使用代理 【35, Webarena: A realistic web environment for building autonomous agents, 2024, URL https://arxiv.org/abs/2307.13854】中的Web应用）。由于不正确的TTL估计，这类不可预测的工具在Continuum中会引发严重的颠簸以及滞留的KV缓存内存。此外，一旦运行中工作流的解码内存超过GPU限制，系统也会抢占并驱逐固定的KV缓存。这导致了图1a中所示的不可避免的颠簸和相应的吞吐量下降。这些局限性凸显了为代理推理构建一个简单快速的系统的必要性。我们设想这样一个系统可以作为新兴代理推理系统（例如，Zhang等人 【31, Megaflow: Large-scale distributed orchestration system for the agentic era, 2026, URL https://arxiv.org/abs/2601.07526】）的一个程序感知调度层 。
图2：当前代理推理系统在内存不平衡和工具资源管理问题上的演示。我们在两个8卡H100 GPU节点上，使用GLM 4.6模型对OpenHands RL rollout在SWEBench-Lite上评估了vLLM + Kubernetes。观察结果显示：(a) 在90分钟的rollout测试中，当应用vLLM的KV感知路由器时，最大内存不平衡可达51%。(b) 未能对工具执行环境进行垃圾回收，导致资源使用量逐渐超过系统容量。(c) 随着并行工作流数量的增加，平均工具执行环境准备时间快速增长。
3 现有代理推理系统中的挑战
本节将vLLM与Kubernetes的组合作为多轮代理推理的代表性基线进行剖析，并总结其关键的低效之处。值得注意的是，所发现的局限性无法通过替换推理引擎（如TensorRT或SGLang）或工具编排器来解决，而是需要新的程序感知抽象。默认情况下，我们使用GLM 4.6模型在两个8卡H100 GPU节点上进行OpenHands RL rollout。
3.1 KV缓存颠簸
代理工作流在执行过程中表现出很高的理论KV缓存重用率，但现有系统因请求级调度导致频繁的缓存驱逐和重填充。 然而，在现有的LLM服务系统中，每一步都被当作一个独立的、无状态的请求来服务。在高并发下，这种请求级别的调度导致KV缓存在工具执行期间为容纳新到达的请求而频繁被驱逐，从而造成重复的驱逐和重新预填充，我们称之为KV缓存颠簸。如图1b所示，随着并行工作流数量的增加，这种颠簸现象会加剧。由此导致的缓存命中率下降会引发频繁且代价高昂的重新预填充，即在工具执行完成后必须重新计算整个历史记录。与无颠簸设置相比，这种冗余使每个请求的端到端延迟显著增加高达7.14倍，导致严重的吞-吐量下降。
3.2 跨节点内存不平衡
现有跨数据并行（DP）节点的请求路由策略是次优的，导致节点间内存负载不平衡。 现有的多轮调度器【21, KV-aware Routing — vLLM Production Stack Documentation, 2025, URL https://docs.vllm.ai/projects/production-stack/en/vllm-stack-0.1.5/tutorials/kvaware.html】 【33, Sglang: Efficient execution of structured language model programs, 2024, URL https://arxiv.org/abs/2312.07104】贪婪地将请求分配给具有最高KV缓存局部性的目标DP节点，以最大化缓存重用。然而，这种策略忽略了内存负载可能在节点间变得不平衡的事实。例如，vLLM 【21, KV-aware Routing — vLLM Production Stack Documentation, 2025, URL https://docs.vllm.ai/projects/production-stack/en/vllm-stack-0.1.5/tutorials/kvaware.html】中的KV感知路由器会将来自同一代理工作流的所有请求发送到同一个节点。由于不同的工作流可能表现出高度异构的KV占用和执行生命周期，这种策略常常导致节点间严重的内存不平衡，一些节点过载而另一些节点则利用率很低。类似地，SGLang中的前缀感知路由器贪婪地将工作负载路由到具有匹配前缀的节点以最大化缓存命中。由于代理系统提示在所有工作流中都是相同的，这种策略会将几乎所有请求发送到同一个节点，而让其他节点闲置。如图2a所示，在90分钟的代 理RL rollout快照中，两个DP节点之间的内存使用差异在超过37分钟的时间里超过20%，峰值不平衡达到51%。
3.3 工具生命周期无感知
当前系统未同步工具编排器与LLM推理引擎的生命周期，导致资源浪费和延迟开销。
图3：ThunderAgent概览。展示了调度状态和内存管理之间的转换。ThunderAgent每隔$\Delta t$时间周期性地查询每个数据并行后端的状态。在这里，后端#1触发了颠簸，而后端#3利用率不足。所有后端共享的全局等待队列随后暂停并收集正在行动的程序#2回到队列中，同时释放正在推理的程序#6和#9，以停止后端#1的KV缓存颠簸并减少后端#3的内存不平衡。
资源泄漏和未使用的沙箱。 图2b显示，总磁盘空间消耗随处理的工作流数量线性增加，最终超过系统容量。这是因为当工作流完成时，未使用的资源（例如已完成工作负载的Docker镜像）没有被回收。这种低效的垃圾回收导致长期代理推理的系统致命不稳定。
昂贵的环境准备。 我们观察到，大多数代理工作负载在启动多轮轨迹之前需要准备环境。例如，编码代理需要拉取docker镜像、安装相关软件包和构建代码仓库。此外，如图2c所示，这个准备时间是昂贵的，并且随着并行工作负载数量（即批处理大小）的增加而增加。如果LLM推理引擎需要等到环境完全准备好，这个开销将延长推理系统的端到端延迟。
A2 方法细节
4 ThunderAgent：一个程序感知的代理推理系统
基于第3节的所有发现，我们提出了ThunderAgent，一个用于高吞吐量代理推理的程序感知系统。我们在4.1节中对代理程序（Agentic Program）进行建模，它作为我们调度的主要抽象。4.2节形式化了一个成本模型来指导我们的系统设计。在这些基础上，我们在4.3节详细阐述了我们的KV缓存调度策略，在4.4节介绍了工具资源管理策略。
表1：代理程序的符号摘要。每个程序实例由其身份、执行阶段、工具环境、资源占用和在ThunderAgent中的调度状态来表征。
| 符号 | 描述 |
|---|---|
| P | 代理程序实例 |
| ID | 程序的唯一全局标识符 |
| C | 上下文中的token数量 |
| T | 程序所需的工具环境集合 |
| C | 后端（GPU节点）放置，用于空间局部性 |
| T | 执行阶段：推理（R），行动（A） |
| S | 调度状态：{活跃，暂停，终止} |
4.1 程序抽象
代理程序（Agentic Program）是封装工作流逻辑和系统依赖的基础抽象。 它形式上定义为一个元组 $P = \langle ID, c, \mathcal{T}, \mathcal{L}, \tau, s \rangle$。其中，$ID$ 是唯一的全局标识符。$c$ 表示上下文中的token数量，对应于活跃执行期间的KV缓存内存占用。$\mathcal{T}$ 跟踪程序使用的工具环境集合，当没有程序再需要它们时可以进行垃圾回收。$\mathcal{L}$、$\tau$ 和 $s$ 分别表示节点位置、执行阶段和调度状态，这些信息有助于实现程序级别的KV缓存颠簸减少和跨节点迁移。图3右侧展示了一个元数据示例。ThunderAgent通过与OpenAI风格的端点接口，直接封装现有的LLM引擎和工具编排器。程序ID允许系统区分来自不同代理工作流的请求。我们在附录B中详细说明了将ThunderAgent与现有推理服务集成的简便性。
4.2 成本模型
在多轮代理推理中，只有用于有效预填充和解码的资源才对系统吞吐量有贡献。 我们采用时空积（Space-Time Product, STP）【1, A study of replacement algorithms for a virtual-storage computer, 1966, IBM Systems Journal】作为主要度量，定义为内存占用在处理时间上的积分。一个过程阶段的STP成本形式化为：$\mathrm { Cost _ { x } } = \int _ { 0 } ^ { t _ { x } } M _ { x } ( t ) d t$，其中 $t_x$ 是过程 $x$ 的持续时间。由于内存使用量 $M_x(t)$ 可以直接由LLM中使用的KV缓存token数量来量化，我们将成本模型定义为token数量对时间的积分。代理推理的总成本包括五个不同部分：解码、预填充、重计算、未使用容量和空闲缓存。我们明确区分用于工具执行结果的增量预填充和对历史交互的重计算，后者由于需要重新计算被驱逐的完整上下文的KV缓存而导致成本显著更高。形式上，这产生了以下成本分解：
在这个分解中，$\mathrm{Cost_{decode}}$ 和 $\mathrm{Cost_{prefill}}$ 代表了对推理吞吐量有贡献的有效工作。其余项是浪费的系统开销：$\mathrm{Cost_{recompute}}$ 源于KV缓存颠簸（第3.1节）；$\mathrm{Cost_{unused}}$ 反映了数据并行（DP）推理后端副本间的内存不平衡（第3.2节）；而 $\mathrm{Cost_{caching}}$ 是在外部工具执行期间持有内存时累积的（第3.3节）。
4.3 调度策略
调度策略的优化目标是最小化非生产性开销，从而最大化吞吐量。 基于上述成本模型，我们调度策略的优化目标是最小化非生产性开销部分：$\mathrm{Cost_{recompute}}$、$\mathrm{Cost_{unused}}$ 和 $\mathrm{Cost_{caching}}$，从而最大化吞吐量。
4.3.1 通过程序感知的等待队列减少重计算和缓存成本
KV缓存颠簸是吞吐量下降的主要瓶颈，通过引入程序感知的等待队列来解决。 正如第3.1节和图1b所指出的，KV缓存颠簸是吞吐量下降的主要瓶颈。为了解决这个限制，系统必须通过明确控制活跃程序的数量来最小化 $\mathrm{Cost_{recompute}}$。ThunderAgent通过引入一个程序感知的等待队列来实现这一点。我们的系统利用这个队列来调度程序执行，根据程序的token长度 $c$ 和执行阶段 $\tau$ 来决定哪个程序应该在GPU中执行，哪个应该被换出。这里，我们使用两个基本操作来形式化调度器行为：Restore（恢复）和Pause（暂停）。
* Restore：此操作将一个程序接纳进入活跃执行状态。给定一个程序 $P = \langle ID, c, \mathcal{T}, \mathcal{L}, \tau, s \rangle$，其中 $s = \text{Paused}$ 且 $\mathcal{L} = \emptyset$，Restore(P) 将 $P$ 分配给一个有可用容量的后端 $\mathcal{L}'$ 并更新 $P \gets \langle ID, c, \mathcal{T}, \mathcal{L}', \tau, \mathrm{Active} \rangle$。
* Pause：此操作将一个程序从活跃执行状态中移除。给定一个程序 $P = \langle ID, c, \mathcal{T}, \mathcal{L}, \tau, s \rangle$，其中 $s = \text{Active}$，Pause(P) 将 $P$ 从其后端解绑，释放其KV缓存以供抢占，并更新 $P \gets \langle ID, c, \mathcal{T}, \emptyset, \tau, \mathrm{Paused} \rangle$。
基于这两个操作，我们接下来介绍我们最小化KV缓存颠簸的调度策略。
周期性颠簸检测是关键，因为它能抢先缓解由上下文增长引起的内存压力。 第4.1节中的程序抽象为我们提供了正在行动（acting）的程序的KV缓存大小。值得注意的是，这在请求级系统（如第3节所述）中是不可用的。我们将一个DP后端 $\mathcal{L}$ 的颠簸条件定义为程序内存需求超过总容量的状态：$\mathrm { C } _ { \mathrm { t o t a l } } < \sum _ { p \in \mathcal { L } } c _ { p }$，其中 $\mathrm{C_{total}}$ 表示后端 $\mathcal{L}$ 的KV缓存池的固定token容量。在解码过程中，代理工作流的上下文长度 $c_p$ 快速增长，即使没有新请求到达，也可能在执行中途触发内存颠簸。与仅在工作流到达时检查是否接纳的基线调度器（例如Continuum）不同，我们实现了一个周期性监视器，它以固定的时间间隔 $\Delta t$ 评估内存使用情况，从而能够抢先检测和缓解由上下文增长引起的内存压力。
当颠簸即将发生时，ThunderAgent通过暂停活跃程序来释放内存，反之则恢复暂停的程序以利用可用空间。 当KV缓存颠簸即将发生时，ThunderAgent调用Pause操作来暂停活跃程序，释放内存大小 $\Delta C = \sum_{p \in \mathcal{L}} c_p - \lambda_{\max} \cdot \mathrm{C_{total}}$，直到总内存使用量降到限制 $\lambda_{\max} \cdot \mathrm{C_{total}}$ 以下。相反，当后端有可用空间时，即 $\sum_{p \in \mathcal{L}} c_p < \lambda_{\min} \cdot C_{\mathrm{total}}$，ThunderAgent通过Restore操作从等待队列中恢复暂停的程序，确保恢复的程序使总内存保持在 $\lambda_{\max} \cdot \mathrm{C_{total}}$ 以下。这里，$\lambda_{\max}$ 和 $\lambda_{\min}$ 分别表示内存使用的高水位和低水位线，它们共同形成一个稳定我们调度的滞后窗口。在实践中，我们将这两个值都设置为1，因为程序间共享的提示隐式地保留了足够的内存缓冲区。
通过时间衰减机制，系统在缓存成本和重计算成本之间取得平衡。 通过这种程序级的周期性容量检查，ThunderAgent可以保证在行动（acting）阶段为活跃程序预留内存，从而避免KV缓存颠簸。然而，代价是当程序进行长时间的工具执行时，被行动程序占用的GPU内存是空闲的。为了平衡缓存成本与重计算成本，我们在颠簸检查中加入了一个时间衰减机制，该机制会逐渐降低行动程序token的有效权重。这使得调度器在内存压力上升时可以驱逐长时间空闲的缓存，而不是无限期地持有它们：$\mathrm { C } _ { \mathrm { t o t a l } } < \sum _ { p \in \mathcal { L } , \tau = \mathbf { R } } c _ { p } + \sum _ { q \in \mathcal { L } , \tau = \mathbf { A } } c _ { q } \times f ( t _ { q } )$。具体来说，$t_q$ 是程序 $q$ 在当前步骤中的工具执行时间。$f(t)$ 是一个旨在平衡 $\mathrm{Cost_{caching}}$ 和 $\mathrm{Cost_{recompute}}$ 的时间衰减函数。通过随时间动态降低行动程序的有效内存优先级，$f(t)$ 鼓励调度器驱逐保持空闲的缓存。在E.1节中，我们证明了当工具执行延迟满足无记忆属性（即剩余执行时间与已用时长无关）时，最优的衰减函数 $f(t)$ 呈指数衰减形式。
通过优先驱逐KV缓存最小的程序来最小化重计算成本。 有了上述的驱逐和恢复条件，处理颠簸的剩下问题是确定暂停哪些活跃程序的子集，以使重计算成本最小化。在本段中，我们证明驱逐具有最小KV缓存大小的程序可以得到最优解，详细证明见E.2节。
引理 4.1 (二次重计算成本)：给定一个上下文长度为 $c_i$ 的程序 $P_i$，重新填充其KV缓存所产生的重计算成本与 $c_i$ 成二次方关系，即 $Cost_{recompute} = \int_{0}^{t_{\mathrm{recompute}}} c_i(t) dt \propto c_i^2$。
定义 4.1 (驱逐优化问题)：基于引理4.1，给定一个需要释放的内存量 $\Delta C$，调度器旨在选择一个程序子集 $S$ 进行驱逐，使得释放的容量满足约束，同时最小化总重计算成本。这个优化问题被形式化为：$\operatorname* { m i n } _ { S } \sum _ { i \in S } c _ { i } ^ { 2 } \quad \mathrm { s . t . } \quad \sum _ { i \in S } c _ { i } \geq \Delta C$。目标函数通过选择较小的 $c_i$ 来严格最小化。因此，ThunderAgent的策略是贪婪地暂停和驱逐上下文长度最短的程序。我们将正式证明推迟到附录E.3。基于这些分析，我们在调度器中采用以下分数来恢复和暂停程序：
4.3.2 通过全局程序感知的等待队列减少内存不平衡
ThunderAgent通过统一的全局等待队列来解决跨节点内存不平衡问题。 第3.1节和图2a强调，节点间的内存不平衡会引入显著的 $\mathrm{Cost_{unused}}$，导致在其他节点有足够内存容量的情况下不必要地暂停程序。为此，ThunderAgent将所有后端副本的等待队列统一为一个全局的程序感知等待队列。此设计的关键动机是，$\mathrm{Cost_{unused}}$ 仅在等待队列中有暂停的程序而某些副本有空闲内存时才会产生。此外，一旦一个程序被暂停，其KV缓存被假定为已驱逐，使其重计算成本与节点无关。这使我们能够在不牺牲KV缓存局部性的情况下改善跨节点内存平衡。恢复策略与负载均衡而非严格的KV感知路由对齐，使得暂停的程序可以被分派到任何有可用内存容量的副本。因此，全局队列将未使用成本限制在每个节点在 $\Delta t$ 周期内的 $\mathrm{C_{unused}} < c_{\mathrm{min}} \cdot \Delta t$ 范围内，其中 $c_{\mathrm{min}}$ 代表暂停程序中的最小token长度。ThunderAgent中的调度策略和全局等待队列的概览如图3所示。
4.4 工具资源管理
ThunderAgent管理工具资源以减轻资源泄漏和环境设置开销。 接下来，ThunderAgent减轻了第3.3节中详述的资源泄漏和环境设置开销。
基于钩子的垃圾回收机制严格管理工具资源的生命周期。 我们实现了将工具资源的持久性与代理程序的调度状态 $s$ 严格耦合的生命周期钩子。当一个程序被Terminated（终止）时，收集器会立即触发一个拆卸序列，系统地回收沙箱、网络套接字和计算槽。图2b中活跃磁盘使用情况显示，我们的资源管理策略有效地防止了过量资源的累积，使磁盘内存消耗在整个过程中保持近乎恒定。
异步环境准备技术隐藏了工具环境的初始化开销。 初始化工具执行环境（例如，启动Docker容器和安装依赖）所涉及的延迟可能成为瓶颈。为解决此问题，ThunderAgent监视全局等待队列；当一个高优先级程序（具有高 $S_{\mathrm{restore}}$ 值）接近恢复阈值时，系统会在分配GPU内存之前异步恢复其执行环境。这项技术有效地隐藏了初始化开销，显著减少了像编码代理和科学代理这类工具调用密集型工作负载的端到端延迟，如图2c所示。
A4 实验环境
基准和工作流
我们在多种基准和工作负载上评估ThunderAgent：
1. 编码代理服务：我们在SWEBench-Lite【9, Swe-bench: Can language models resolve real-world github issues?, 2024, URL https://arxiv.org/abs/2310.06770】数据集上部署了OpenHands和mini-SWEAgent。OpenHands代表一个重初始化工作流，每个沙箱的平均磁盘占用超过10GB；而mini-SWEAgent是一个轻量级工作流，占用空间极小（约2GB） 。
2. 其他代理服务：我们在HLE【15, Humanity’s last exam, 2025, URL https://arxiv.org/abs/2501.14249】上应用ToolOrchestra，在ScienceAgentBench 【3, Scienceagentbench: Toward rigorous assessment of language agents for data-driven scientific discovery, 2024, URL https://arxiv.org/abs/2410.05080】上应用OpenHands。这些工作负载涉及由外部API调用和复杂科学模拟驱动的可变延迟 。
3. RL rollout：我们在两个8卡H100节点上，使用相同的模型、工作流和样本进行RL rollout。
模型和部署
- 模型：我们使用GLM-4.6 (355B)【20, Glm-4.5: Agentic, reasoning, and coding (arc) foundation models, 2025, URL https://arxiv.org/abs/2508.06471】 和Qwen-3 (235B)【26, Qwen3 technical report, 2025, URL https://arxiv.org/abs/2505.09388】 。
- 框架：使用OpenHands【23, Openhands: An open platform for ai software developers as generalist agents, 2025, URL https://arxiv.org/abs/2407.16741】和mini-SWEAgent 【27, Swe-agent: Agent-computer interfaces enable automated software engineering, 2024, URL https://arxiv.org/abs/2405.15793】框架 。
- 硬件与量化：模型在8卡H100节点上进行FP8量化，并使用张量并行（TP8）。对于ToolOrchestra【18, Toolorchestra: Elevating intelligence via efficient model and tool orchestration, 2025, URL https://arxiv.org/abs/2511.21689】，我们使用在一 台RTX 5090上托管的FP16精度的Qwen3-8B。
- 部署架构：LLM推理引擎部署在托管模型的GPU集群上，而代理的Docker环境则卸载到专用的CPU集群。
ThunderAgent配置
我们将ThunderAgent的超参数配置为：周期性检测间隔 $\Delta t = 5$ 秒，优先级衰减函数 $f(t) = 2^{-t}$。我们使用vLLM作为LLM推理引擎。吞吐量度量标准为每分钟的步数（steps per minute），其中一步包括工作流的一个推理和行动周期。
基线技术
我们与具有不同调度范式的最先进系统进行比较：
* vLLM (Inference)：一个广泛采用的、请求感知的LLM推理引擎，作为无状态推理性能的基线，不包含任何代理或程序特定的感知能力。
* Continuum (Inference)：当前用于多轮代理工作流的最先进系统。它通过预测工具执行时长并相应地将KV缓存固定在HBM中来减轻KV缓存颠簸。
* vLLM + SGLang Gateway (Distributed Rollout)：用于大规模分布式RL rollout的领先解决方案。SGLang Gateway通过增强跨节点内存平衡和KV缓存命中率来优化分布式推理，使该组合成为分布式RL rollout场景的强大基线。
A4 实验结果
图4：服务评估结果。在三种模型、四种代理工作流和三个数据集上，ThunderAgent显著优于vLLM和Continuum。对于工具调用时间可预测的工作流（例如a, b, d, e），ThunderAgent的性能比vLLM和Continuum高出2.43–3.56倍。对于工具执行时间具有随机性的工作流（例如c, f），ThunderAgent仍然实现了最佳的吞吐量性能。
图5：KV缓存命中率统计。在工具调用时间可预测的情况下（a, b, d, e），ThunderAgent实现了近乎最优（约100%）的命中率；而在工具执行时间随机的情况下（c, f），它动态地牺牲命中率以减少空闲缓存。与vLLM和Continuum相比，它也实现了更高的KV缓存命中率。
5.2 服务评估结果
-
高并发下的高吞吐量：如图4所示，ThunderAgent在高并发水平（例如96个并行程序）下展示了卓越的吞吐量，相比vLLM实现了1.48–3.58倍的加速，相比Continuum实现了1.17–3.31倍的加速。这一增益源于其程序感知的调度器，该调度器维持了近乎最优的KV缓存命中率（在Mini-SWE-Bench和OpenHands上约100%，见图5 a, b, d, e），并实现了环境的异步准备。相比之下，Continuum在高并发下性能下降，其KV缓存命中率从>90%显著降至约60%（图5），因为当内存不足以支持正在进行的请求解码时，不同程序间的请求会相互驱逐KV缓存，导致活跃程序争夺有限内存并引发颠簸。
-
对高并发的鲁棒性：即使并行工作流数量超出GPU内存限制，ThunderAgent也能维持最大可达吞吐量。如图4所示，ThunderAgent确保吞吐量随并行工作流数量增加而保持稳定，而基线系统一旦工作负载超过内存限制，就会出现严重的吞-吐量崩溃。在实际的代理服务中，由于代理环境和工具执行时间的随机性，静态确定最优并行工作流数量以最大化利用率同时限制KV缓存颠簸和缓存成本通常是不可行的。ThunderAgent通过自动适应最大可用容量而无需手动调整来解决此问题，这一能力对稳健的真实世界部署至关重要。
-
跨确定性和随机性工具执行的鲁棒性：ThunderAgent不仅在具有确定性工具模式的工作流中（图4 a, b, d, e）表现优于基线，在高度随机的条件下（图4 c, f）同样如此。这得益于其动态的程序感知等待队列策略。vLLM的请求感知调度器通常没有为行动中的程序预留内存，导致频繁的重计算。相反，Continuum为所有暂停的程序静态预留内存，并错误预测工具执行时间，这在长且不可预测的工具调用中导致昂贵的重计算成本或缓存成本。ThunderAgent通过时间衰减函数 $f(t)$ 来平衡这两者，该函数优先保留工具调用时间短的程序的KV缓存，同时抢先暂停工具执行时间长的程序以防止内存浪费。如图5（右）所示，尽管ThunderAgent在随机设置中KV缓存命中率低于Continuum，但通过确保活跃的GPU利用率，它实现了更高的吞吐量。
5.3 Rollout评估结果
我们在一个双节点H100集群上使用GLM4.6评估了RL rollout（持续3小时）。如表2所示，ThunderAgent能够保持有效的可扩展性，与vLLM + Gateway基线相比，实现了1.79–3.92倍的吞吐量提升，使其对于内存密集型的分布式RL工作负载非常高效。
表2：ThunderAgent GLM-4.6 rollout (N=144) 在2个8卡H100节点上的结果。
| 工作流 | 服务系统 | 吞吐量 |
|---|---|---|
| mini-SWEAgent | vLLM + Gateway | 375.4 |
| mini-SWEAgent | THUNDERAGENT | 671.8 (1.79×) |
| OpenHands | vLLM + Gateway | 69.1 |
| OpenHands | THUNDERAGENT | 270.8 (3.92×) |
5.4 消融研究
图6：ThunderAgent的端到端延迟分解和参数敏感性消融研究。
-
端到端延迟分解：图6a分解了OpenHands rollouts的平均端到端延迟。吞吐量的增益主要来自预填充（prefill）和解码（decode）延迟的减少。此外，工具资源管理策略（第4.4节）贡献了约10%的延迟改进，同时实现了4.2倍的磁盘内存节省。每个步骤的端到端延迟在附录F中进一步讨论。
-
对$\Delta t$和f(t)的消融研究：我们研究了检测周期$\Delta t$和衰减函数$f(t) = x^{-t}$的敏感性。图6b显示了ThunderAgent在单个H100节点上使用GLM4.6作为基础模型离线服务mini-SWEAgent的情况。我们观察到，ThunderAgent在不同参数设置下均能保持高吞吐量，证明了我们方法的鲁棒性。进一步增加$\Delta t$可能会降低KV缓存命中率，从而减少吞吐量，因为颠簸可能在检测间隔中发生。同样，增加$f(t)$中的$x$值会允许更激进地驱逐行动中的程序，这是用重计算成本来换取缓存成本的减少。这会降低吞-吐量，因为工具执行时间短的行动中程序会被过早驱逐。
A5 结论
我们介绍了ThunderAgent，一个基于程序级抽象构建的快速、简单的代理系统，该抽象在每个代理工作流的整个生命周期中跟踪元数据。ThunderAgent利用该程序抽象进行运行时调度和资源管理。具体来说，ThunderAgent动态地在GPU节点间调度程序执行，以减轻KV缓存颠簸和内存不平衡，同时管理工具资源以防止资源泄漏。实验结果表明，ThunderAgent在服务方面比以前的系统快1.48–3.58倍，在RL rollouts方面快1.79–3.92倍。
A6 附录
A 与先前工作的扩展比较
A.1 KV缓存优化
多层KV缓存管理。 为了缓解GPU内存压力，诸如Pensieve【28, Stateful large language model serving with pensieve, 2025, EuroSys ’25】、Continuum【11, Continuum: Efficient and robust multi-turn llm agent scheduling with kv cache time-to-live, 2025, URL https://arxiv.org/abs/2511.02230】、Strata 【25, Strata: Hierarchical context caching for long context language model serving, 2025, URL https://arxiv.org/abs/2508.18572】和ShadowKV 【19, Shadowkv: Kv cache in shadows for high-throughput long-context llm inference, 2025, URL https://arxiv.org/abs/2410.21465】等系统利用了包 括GPU HBM、CPU DRAM和NVMe SSD在内的硬件内存层次结构来进行KV缓存管理。这些分层缓存机制通过将不活跃的KV状态卸载到低层存储，并在请求恢复时将其预取回GPU，从而减轻了瞬时抢占。然而，这些方法的实际效率从根本上受限于设备和主机内存之间的层间带宽。在第5节中显示，在高频代理工作流中，频繁的换入换出操作的开销常常抵消了多层缓存带来的好处。
分布式KV缓存管理。 代理状态的分布式管理给KV缓存的驱逐和抢占策略带来了显著的复杂性。虽然像BanaServe【6, Banaserve: Unified kv cache and dynamic module migration for balancing disaggregated llm serving in ai infrastructure, 2025, URL https://arxiv.org/abs/2510.13223】和LMCache 【12, Lmcache: An efficient kv cache layer for enterprise-scale llm inference, 2025, URL https://arxiv.org/abs/2510.09665】等系统支持跨DP节点的KV缓存传输，但它们在大批量代理服务和rollout中的性能常常受到有限互连带宽的限制。代理工作流中强烈的程序内依赖性，在没有程序级管理的情况下，需要频繁的状态传输，这在服务或rollout期间很容易使网络饱和。为了绕过这些带宽瓶颈， 像vLLM KV-aware router【21, KV-aware Routing — vLLM Production Stack Documentation, 2025, URL https://docs.vllm.ai/projects/production-stack/en/vllm-stack-0.1.5/tutorials/kvaware.html】 和SGLang Model Gateway【33, Sglang: Efficient execution of structured language model programs, 2024, URL https://arxiv.org/abs/2312.07104】等标准推理系统采用了KV感知路由策略，根据前缀局部性或会话ID将请求固定到特定节点。类似地，Vortex 【29, Vortex: Overcoming memory capacity limitations in gpu-accelerated large-scale data analytics, 2025, URL https://arxiv.org/abs/2502.09529】引入了会话感知的预取来最小化跨节点数据传输延迟。然而，这些方法缺乏在DP节点之间动态迁移活跃程序状态的能力。这种工作负载迁移的缺失导致了集群间严重的内存利用不平衡，如图2a所示。托管长时间运行的代理程序的节点无法将状态卸载到空闲的对等节点，导致资源利用碎片化和总吞吐量下降 。
A.2 KV缓存优化的扩展实验结果
关于KV缓存卸载的实验。 我们通过使用LMCache【12, Lmcache: An efficient kv cache layer for enterprise-scale llm inference, 2025, URL https://arxiv.org/abs/2510.09665】作为解决容量限制的潜在方案，研究了KV缓存卸载。虽然理论上卸载通过利用CPU或SSD存储扩展了有效内存空间，但我们使 用vLLM + LMCache的实现揭示了一个关键瓶颈：PCIe带宽不足以支持代理工作负载固有的高频上下文切换和大容量数据传输。如图7a所示，在服务于GLM-4.6模型【20, Glm-4.5: Agentic, reasoning, and coding (arc) foundation models, 2025, URL https://arxiv.org/abs/2508.06471】和mini-SWEAgent框架 【27, Swe-agent: Agent-computer interfaces enable automated software engineering, 2024, URL https://arxiv.org/abs/2405.15793】时，频繁的换入换出操作带来的延迟惩罚抵消了内存容量的好处，导致在重代理工作负载下严重的吞吐量下降 。
关于预填充-解码（PD）分离的实验。 我们还探索了PD分离【34, Distserve: Disaggregating prefill and decoding for goodput-optimized large language model serving, 2024, URL https://arxiv.org/abs/2401.09670】，这是聊天机器人服务中通过将解码阶段与预填充干扰隔离的标准优化。然而，当应用于以持续上下文增长为特征的代理工作负载时，我们观察到PD分离加剧了颠簸。通过将集群划分为仅预填充和仅解码的节点，可用于处理预填充的有效HBM池显著小于统一架构中的池。这种内存碎片化导致系统在更低的并发水平下就达到容量极限并触发颠簸，如图7b所示。这些结果表明，通用的架构优化不能替代一个主动管理工作集的以程序为中心的调度器 。
A.3 扩展代理工作流
异构资源分配与调度。 为了大规模地编排多轮代理与环境的交互，近期的系统如MegaFlow【31, Megaflow: Large-scale distributed orchestration system for the agentic era, 2026, URL https://arxiv.org/abs/2601.07526】、RollArt 【5, Rollart: Scaling agentic rl training via disaggregated infrastructure, 2025, arXiv:2512.22560】【22, Let it flow: Agentic crafting on rock and roll, building the rome model within an open agentic learning ecosystem, 2025, arXiv:2512.24873】、AgentRL【30, Agentrl: Scaling agentic reinforcement learning with a multi-turn, multi-task framework, 2025, arXiv:2510.04206】和VerlTool【8, Verltool: Towards holistic agentic reinforcement learning with tool use, 2025, arXiv:2509.01055】将模型推理与环境执行解耦。虽然这些框架通过专门的服务有效地扩展了环境并发性，但它们表现出粗粒度分离的固有局限性。通过将推理引擎和工具执行器视为孤立的黑盒，这些系统缺乏统一的资源管理，无法将KV缓存的生命周期与环境执行相协调。没有程序级别的细粒度调度，基于分离的方法在代理工作负载中浪费了KV缓存的重用潜力，导致吞吐量次优。
B 系统可移植性与接口抽象
B.1 中间件架构与统一接口
ThunderAgent作为一个程序感知的运行时层，通过程序级抽象协调代理控制流与后端推理引擎。 调度器基于抽象的ProgramState（见表3a）和后端缓存容量视图（见表4）来控制程序状态转换。同时，每个程序只与端点绑定，不依赖于具体的后端实现。
B.2 为什么程序ID很重要
程序ID允许系统检查工作流元数据，实现智能抢占策略。 虽然标准的会话ID作为路由标签，但我们的系统使用程序ID来检查工作流的元数据。这种可见性至关重要：它允许调度器区分有效的工具等待时间与空闲会话，从而实现基于会话的基线所不支持的智能抢占策略。
B.3 ThunderAgent的低开销采用
采用ThunderAgent仅需对请求附加程序ID并发送终止信号。 图8显示，采用ThunderAgent只需要将程序ID附加到请求（包括LLM推理和工具执行），并在程序结束时发送一个带有程序ID的显式释放信号。程序ID为每个请求标记其所属的程序实例以进行调度，而释放信号则允许ThunderAgent在程序终止后回收每个程序的资源。所有其他请求字段和OpenAI风格的API接口保持不变。
表3：程序状态和状态定义。
(a) ProgramState字段。
| 字段 | 类型 | 含义 |
|---|---|---|
| ProgramState | ||
| status | ProgramStatus | 当前生命周期状态。 |
| backend_url | str | 分配的后端端点。 |
| step-count | int | 已执行的步数。 |
| total_tokens | int | 整个历史记录的总token数。 |
(b) ProgramStatus语义。
| 状态 | 含义 |
|---|---|
| ProgramStatus | |
| REASONING | 在GPU上进行推理。 |
| ACTING | 在GPU外执行工具。 |
| PAUSED | 在全局暂停等待集合中。 |
| STOPPED | 已释放；资源已回收。 |
表4：BackendState的关键字段。
| 字段 | 类型 | 含义 |
|---|---|---|
| BackendState | ||
| url | str | 后端端点。 |
| healthy | bool | 用于调度的健康标志。 |
| cache_config | Optional[CacheConfig] | 静态缓存配置（在启动时获取）。 |
| active-program_tokens | int | 此后端上的活跃token占用。 |
C 工具执行时间的可变性
实际的代理工具调用难以表征且通常不可预测。 在一些以代码为中心的场景中（例如，使用SWE-agent【27, Swe-agent: Agent-computer interfaces enable automated software engineering, 2024, URL https://arxiv.org/abs/2405.15793】或OpenHands 【23, Openhands: An open platform for ai software developers as generalist agents, 2025, URL https://arxiv.org/abs/2407.16741】服务SWE-Bench 【9, Swe-bench: Can language models resolve real-world github issues?, 2024, URL https://arxiv.org/abs/2310.06770】），代理主要调用本地、轻量级的工具，工具延迟相对稳定且方差较低。然而，在更广泛和更现实的场景中，例如使用ToolOrchestra 【18, Toolorchestra: Elevating intelligence via efficient model and tool orchestration, 2025, URL https://arxiv.org/abs/2511.21689】服务HLE 【15, Humanity’s last exam, 2025, URL https://arxiv.org/abs/2501.14249】，工作负载更严重地依赖于远程服务工具（表5），使得工具执行时间易变且难以预测。这种易变性主要源于代理运行时之外的因素，如网络抖动、后端负载和排队延迟，以及速率限制，这些因素可能因请求和时间而异 。
经验证实了工具执行时间的重尾分布特性。 我们在图9中凭经验证实了这种行为。对于远程服务工具（以及一些执行工具），中位数和尾部百分位数之间的差距很大：p95和p99显著高于中位数，且尾部可以延伸到数十甚至数百秒。这表明在这些场景中，工具延迟缺乏稳定的中心趋势；相反，重尾行为占主导地位，使得工具延迟预测在实践中本质上是脆弱的。
工具执行的不可预测性使得基于TTL的方法效果不佳，而ThunderAgent的成本模型更具优势。 鉴于工具执行的不可预测性，低估会浪费固定的缓存容量，同时仍会触发过早的KV驱逐，导致恢复时出现颠簸。相反，高估可能导致不必要地驱逐本应保持固定的程序KV。即使工具运行时间完全可预测，现有方法如Continuum【11, Continuum: Efficient and robust multi-turn llm agent scheduling with kv cache time-to-live, 2025, URL https://arxiv.org/abs/2511.02230】仍然使用静态的、基于阈值的规则来决定是否保持KV缓存固定。相比之下，ThunderAgent构建了一个完整的成本建模框架，并动态地权衡$\mathrm{Cost_{recompute}}$和$\mathrm{Cost_{caching}}$ 。
表5：工具类别。
| 工具类别 | 角色 | 主要可变性来源 |
|---|---|---|
| HLE-search | 检索证据 | 远程服务（网络延迟/速率限制） |
| HLE-enhance-reasoning | 模型作为工具调用 | 远程服务 |
| HLE-answer | 最终生成 | 本地LLM推理 |
| SAB-execute-bash | Shell执行 | 沙箱和I/O |
| SAB-execute-ipython_cell | Python单元格执行 | 程序运行时 |
| SAB-str_replace_editor | 文件编辑 | 本地文件系统 |
| SAB-task_tracker | 任务状态跟踪 | 本地文件系统 |
D KV缓存命中率统计与解释
吞吐量损失主要来自重计算和空闲缓存的开销。 在我们的成本分解方程(3)中，代理服务的吞吐量损失主要来自非生产性开销：由颠簸引起的KV重计算（$\mathrm{Cost_{recompute}}$）和外部工具执行期间的空闲KV缓存（$\mathrm{Cost_{caching}}$）。当工具调用时间短且可预测时，行动（acting）阶段只占用KV很短的时间，因此$\mathrm{Cost_{caching}}$很小；因此，避免颠簸是主要目标：更高的KV缓存命中率通常意味着更少的重预填充和更高的吞吐量。
高KV缓存命中率不总能保证高吞吐量，尤其是在工具执行时间多变的情况下。 然而，当工具执行时间高度可变时（见附录C），基于TTL的调度器最终可能会为长时间的工具调用固定KV缓存。虽然这可以减少$\mathrm{Cost_{recompute}}$从而提高KV缓存命中率，但它同时会膨胀$\mathrm{Cost_{caching}}$并降低吞吐量。这有助于解释为什么Continuum【11, Continuum: Efficient and robust multi-turn llm agent scheduling with kv cache time-to-live, 2025, URL https://arxiv.org/abs/2511.02230】在工具密集型工作负载上尽管实现了更高的KV缓存命中率，但性能却可能更差（图4，5）。ThunderAgent通过明确平衡缓存和重计算来适应这些情况。ThunderAgent在第4.3节中为行动程序引入了一个时间衰减函数$f(t)$来权衡$\mathrm{Cost_{caching}}$和$\mathrm{Cost_{recompute}}$；我们在附录E.1中严格推导了$f(t)$的最优函数形式。通过逐渐降低长时间空闲的行动程序的有效内存优先级，调度器驱逐它们的KV缓存以减少空闲缓存成本，同时控制重计算，从而在实践中产生更好的吞吐量（图4） 。
E 扩展理论分析
E.1 周期性颠簸检测的时间衰减函数证明
假设 E.1 (不可预测的工具执行时间)。 对于行动中的程序，我们假设调度器无法可靠地预测给定程序的工具返回时间（见附录C）。因此，衰减函数 $f$ 应仅以时间同质的方式依赖于已过的行动时间 $t$【14, Humanity’s last exam, 2025, URL https://arxiv.org/abs/2501.14249】 。
假设 E.2 (边界条件)。 我们假设时间衰减函数 $f: [0, \infty) \to (0, 1]$ 满足 $f(0) = 1, \lim_{t \to \infty} f(t) = 0$。这些边界条件的直观解释是，当工具执行时间为0时（对应于没有工具调用的多轮交互），所有行动程序都简化为推理程序，因此 $f(t) = 1$。相反，如果工具执行时间是无限的，代理工作流就退化为单轮生成，类似于标准的聊天机器人服务，因为请求永远不会返回进行下一轮交互。在这种情况下，设置 $f(t) = 0$ 使衰减函数与请求级调度策略保持一致。
定理 E.1 (可接受的时间衰减函数)。 在假设E.1和E.2下，我们容量检查函数（方程7）的可接受时间衰减函数 $f$ 必须采用以下形式之一：连续时间下的指数函数，$f(t) = e^{-\lambda t}$ 且 $\lambda > 0$，或离散tick时间下的几何函数，$f(k) = x^{-k}$ 且 $x > 1$。
证明。 我们首先形式化假设E.1所暗示的时间同质属性，然后根据假设E.2中的边界条件推导出可接受的时间衰减函数 $f$。
不可预测工具时间的形式化。 令 $t$ 表示已过的行动时间，以时钟时间（连续时间）或周期性监视器tick（离散时间）度量。根据假设E.1，再等待一个时长 $\Delta$ 后的相对衰减不应依赖于绝对的已过时间 $t$，而只依赖于增量 $\Delta$。我们将其形式化为存在一个函数 $\phi: [0, \infty) \to (0, 1]$，使得对于所有 $t, \Delta \geq 0$，有 $f(t + \Delta) = f(t) \phi(\Delta)$。
半群方程。 在方程13中设 $t = 0$ 并使用边界条件 $f(0) = 1$（来自假设E.2）得到 $\phi(\Delta) = f(\Delta)$。代回后，我们得到乘法半群方程 $f(t + \Delta) = f(t) f(\Delta), \forall t, \Delta \geq 0$。
连续时间情况（指数衰减）。 定义 $h(t) \triangleq \ln f(t)$。对上式两边取对数，得到柯西函数方程 $h(t + \Delta) = h(t) + h(\Delta)$。由于 $f(t) \in (0, 1]$，我们有 $h(t) \leq 0$ 对所有 $t \geq 0$ 成立，这意味着 $h$ 在 $[0, \infty)$ 上有上界。在此有界条件下，柯西函数方程只接受形式为 $h(t) = ct$ 的线性解，其中 $c \in \mathbb{R}$。令 $\lambda \triangleq -c \geq 0$，我们得到 $f(t) = e^{-\lambda t}$。最后，边界条件 $\lim_{t \to \infty} f(t) = 0$（假设E.2）排除了 $\lambda=0$ 的情况，因此 $\lambda > 0$。
离散时间情况（几何衰减）。 在离散时间设置中，已过行动时间以整数tick $k \in \mathbb{Z}_{\geq 0}$ 度量。方程14变为 $f(m+n) = f(m)f(n), \forall m, n \in \mathbb{Z}_{\geq 0}$。设 $n=1$ 得到递推关系 $f(k) = f(k-1)f(1)$。令 $\gamma \triangleq f(1)$，我们有 $f(k) = f(1)^k \triangleq \gamma^k$。边界条件 $\lim_{k \to \infty} f(k) = 0$ 意味着 $0 < \gamma < 1$。等价地，我们可以参数化为 $f(k) = x^{-k}$，其中 $x \triangleq \gamma^{-1} > 1$。证明完毕。
E.2 重计算STP成本的证明
重计算成本与上下文长度的平方成正比。 根据第4.2节的定义，STP重计算成本为 $\mathrm{Cost_{recompute}} = \int_{0}^{t_{\mathrm{recompute}}} c_i(t) dt$。其中，瞬时成本 $c_i(t)$ 与解码步骤成正比（即 $c_i(t) \propto t$）。这种比例关系是因为分块预填充（chunked prefill）在每次迭代中处理恒定数量的KV对，导致累积计算量随时间线性增加。因此，对积分求值得到 $\mathrm{Cost_{recompute}} \propto t_{\mathrm{recompute}}^2$。考虑到关系 $t_{\mathrm{recompute}} = c_i \times T_{\mathrm{decode}} / \mathrm{chunk}$，其中 $T_{\mathrm{decode}}$ 和块大小都是常数，因此可得：$Cost_{\mathrm{recompute}} \propto c_i^2$。
E.3 最小化重计算STP成本的证明
我们使用交换论证法为“最短优先驱逐”策略的最优性提供严格证明。
问题定义。 我们的目标是选择一个要驱逐的暂停程序子集 $S$，使得回收的总内存满足 $\sum_{i \in S} c_i \geq \Delta C$，同时最小化总重计算成本 $J(S) = \sum_{i \in S} c_i^2$。注意，成本函数 $f(x) = x^2$ 是严格凸的且是超加性的（即对于正数 $a, b$，有 $(a+b)^2 > a^2 + b^2$）。
定理。 最小化 $J(S)$ 的最优策略是严格选择具有最小上下文长度 $c_i$ 的程序。
证明。 假设最优集 $S^*$ 不是最短程序的集合，这与结论相矛盾。这意味着存在一个“长”程序 $p_{long} \in S^*$ 和一个“短”程序 $p_{short} \notin S^*$（可用但未被选择），使得 $c_{short} < c_{long}$。我们可以通过交换或分解 $p_{long}$ 来构造一个新集合 $S'$。由于 $c_{long} > c_{short}$，我们可以将 $p_{long}$ 概念化为由一个长度为 $c_{short}$ 的段和一个残差 $r = c_{long} - c_{short}$ 组成。用 $p_{short}$（以及理论上的残差 $r$）替换对 $p_{long}$ 的选择会改变成本。考虑从平方函数的凸性得出的不等式：$c_{long}^2 = (c_{short} + r)^2 = c_{short}^2 + r^2 + 2c_{short}r$。由于 $c_{short} > 0$ 和 $r > 0$，交叉项 $2c_{short}r > 0$。因此：$c_{short}^2 + r^2 < c_{long}^2$。这个不等式意味着将一个大的驱逐目标（$c_{long}$）分解成更小的部分（$c_{short} + r$）会严格减少平方和。在我们的调度器背景下，这意味着如果我们使用一个大程序来满足内存约束 $\Delta C$，我们可以通过将其换成总容量相同但可用的更小程序的组合来严格减小惩罚。通过迭代应用这种交换——用未选择的较小程序替换已选择的较大程序——我们单调地减小成本函数 $J(S)$。只有当没有这种交换可能时，即当 $S$ 完全由具有最小可用上下文长度的程序组成时，成本才达到其全局最小值。
结论。 “最短优先”策略是全局最优的，因为注意力机制的超线性成本（$O(L^2)$）对碎片化的惩罚小于对聚合的惩罚。
F 端到端延迟分析
尽管程序级延迟对自主代理更为重要，但ThunderAgent在每步延迟上也表现出色。 尽管我们在第1节中已指出，对于自主代理和代理式RL rollout，程序级延迟（生成整个工作流所需的时间）远比每步的端到端延迟重要，但我们在此比较了ThunderAgent与vLLM和Continuum的平均每步延迟。图10显示，当在单个H100上服务时，无论是低并行度还是高并行度，使用GLM4.6和Qwen3 235B的mini-SWEAgent和OpenHands，ThunderAgent都显著优于vLLM和Continuum。原因在于，（基线系统）看似通过切换行动中的程序来改善端到端延迟，但实际上它通过引发严重的KV缓存颠簸，延迟了所有正在运行的程序的延迟。
图7：KV缓存卸载和预填充-解码（PD）分离的消融研究
图8：使用ThunderAgent仅需三处改动。
图9：工具执行时间分布。工具执行时间表现出高度可变性且难以预测。
图10：端到端延迟比较
💬 评论讨论
欢迎在这里分享您的想法和见解！