ThunderAgent: A Simple, Fast and Program-Aware Agentic Inference System——一个简单、快速且具有程序感知能力的智能体推理系统

《ThunderAgent: 一个简单、快速且具有程序感知能力的智能体推理系统》主要针对当前大语言模型（LLM）驱动下的多轮智能体工作流存在的系统效率问题，提出了一套全新的端到端推理系统。以下是全文的核心研究内容总结：

1. 研究背景与问题

随着LLM被用于构建复杂的自主智能体（如编程助手、科研智能体等），这些智能体在执行任务时会反复进行“推理-工具调用-再推理”的多轮交互。现有系统通常将LLM推理引擎（如vLLM）和工具编排器（如Kubernetes）松散组合，以“请求”为单位独立调度资源，缺乏对整个工作流的全局认知。这导致了三大核心问题：

• KV缓存抖动：高并发下，系统为给新请求腾空间，会频繁驱逐正在等待工具返回的程序的KV缓存，导致工具返回后需要重新计算整个历史上下文，延迟增加高达7.14倍。

• 跨节点内存不平衡：为最大化缓存命中，同一智能体的所有请求被固定在同一节点，但不同工作流的上下文长度差异巨大，导致某些节点内存过载而其他节点闲置，利用率失衡可达51%。

• 工具生命周期无感知：系统无法有效管理工具执行环境（如Docker容器），导致资源泄漏（磁盘占满）和长时间的环境准备延迟。

2. 核心贡献：ThunderAgent系统

作者提出了ThunderAgent，一个“程序感知”的智能体推理系统，核心创新包括：

（1）程序抽象

将每个智能体工作流抽象为一个“智能体程序”（Agentic Program），作为一等调度单元。该程序包含唯一ID、上下文长度、执行阶段（推理/行动）、调度状态、工具环境集合等元数据。这使得系统能够从端到端视角管理整个工作流的生命周期。

（2）程序感知调度器

• 周期性抖动检测：定期检查各节点内存使用，当预测到即将超限时，主动暂停部分程序，避免被动驱逐。

• 状态感知暂停与恢复：优先暂停处于“行动”（等待工具）阶段的程序，优先恢复处于“推理”阶段的程序，以减少无效缓存占用。

• 最短优先驱逐策略：理论证明，当必须驱逐时，优先驱逐上下文最短的程序，能使重计算成本（与上下文长度的平方成正比）最小化。

• 时间衰减机制：对于长时间等待工具返回的程序，逐步降低其KV缓存的内存优先级，在缓存保留和重计算之间动态平衡。

• 全局等待队列：所有节点共享一个队列，暂停的程序可以被调度到任意有闲置内存的节点恢复，从而缓解跨节点内存不平衡。

（3）程序感知工具资源管理

• 异步环境准备：在程序即将恢复前，提前在后台准备Docker、依赖库等工具环境，隐藏初始化延迟。

• 生命周期垃圾回收：程序终止时立即回收其占用的沙箱、网络端口等资源，防止累积泄漏。

3. 实验评估

作者在多种智能体工作负载上进行了全面测试：

• 工作负载：包括编码智能体（SWE-Agent、OpenHands）、路由智能体（ToolOrchestra）、科学发现智能体（ScienceAgentBench），以及RL推演场景。

• 硬件：从单卡RTX5090到8×H100、64×H100集群。

• 对比基线：vLLM（请求感知基线）和Continuum（当前SOTA多轮智能体系统）。

主要结果：

• 服务场景下，吞吐量相比vLLM提升1.48–3.58倍，相比Continuum提升1.17–3.31倍。

• RL推演场景下，相比vLLM+SGLang Gateway提升1.79–3.92倍。

• KV缓存命中率接近100%（可预测工具场景），在随机工具场景中通过权衡缓存命中与计算效率，仍保持更高吞吐。

• 磁盘内存节省高达4.2倍。

• 扩展到8节点（64×H100）时，吞吐量接近线性增长。

• 与KV缓存卸载技术（如HiCache）兼容，进一步缓解内存压力。

4. 理论分析与消融研究

• 成本模型：定义了时空积（STP）成本，将总成本分解为解码、预填充、重计算、未使用容量、空闲缓存五部分，调度器以最小化后三者为目标。

• 时间衰减函数推导：在工具执行时间不可预测且无记忆性的假设下，严格证明指数衰减是唯一合理的形式。

• 驱逐策略证明：通过交换论证，证明最短优先驱逐在二次重计算成本模型下全局最优。

• 消融实验验证了全局队列、衰减函数形式、驱逐策略、检测周期等各组件对性能的贡献。

5. 系统可移植性与采用情况

• ThunderAgent只需在请求中附加program_id并在程序结束时发送释放信号即可集成，对现有API改动极小。

• 已被SkyRL（RL训练框架）和NVIDIA Dynamo（分布式推理框架）等开源项目采用。

ThunderAgent通过引入程序级抽象和端到端的资源感知调度，从根本上解决了现有请求级系统在智能体推理中的缓存抖动、内存不平衡和工具资源泄漏问题，显著提升了大规模智能体服务和RL训练的系统效率，为自主智能体的规模化部署提供了高效、可持续的基础设施支撑。这里是自己的论文阅读记录，感兴趣的话可以参考一下，如果需要阅读原文的话可以看这里，如下所示：

项目地址在这里，如下所示：

摘要

大型语言模型（LLM）现已被用于驱动复杂的多轮智能体工作流。现有系统通过松散地组合独立组件（例如，LLM推理引擎（如vLLM）和工具编排器（如Kubernetes））来运行智能体推理。尽管智能体工作流涉及多个LLM和工具请求，但这些系统在逐请求的基础上分别调度和分配资源，缺乏对工作流的端到端认知。这导致了KV缓存和工具执行环境管理的次优。为应对这些挑战，我们提出了THUNDERAGENT，一个快速、简单且具有程序感知能力的智能体推理系统。我们首先将智能体工作流抽象为LLM程序，从而实现对异构资源的统一视图，这些资源包括KV缓存、系统状态以及磁盘内存和网络端口等外部工具资产。基于此抽象，THUNDERAGENT引入了一个程序感知调度器和一个工具资源管理器，旨在最大化KV缓存命中率、缓解内存不平衡并支持异步环境准备。在编码、路由和科学发现智能体上的评估表明，与最先进的推理系统相比，THUNDERAGENT在服务中实现了 1.5−3.6× 的吞吐量提升，在强化学习（RL）推演中实现了 1.8−3.9× 的提升，并节省了高达 4.2× 的磁盘内存。为促进可复现性和支持未来发展，我们在以下地址开源了THUNDERAGENT的系统实现：https://github.com/ThunderAgent- org/ThunderAgent。

1 引言

语言模型的最新进展将其应用从基础聊天机器人扩展到了复杂智能体 [21, 27]。这些智能体通过将长程推理与外部工具调用（例如，编译器、检索器）交错进行，来解决编码 [8, 10] 和计算机使用 [2, 25] 等领域的现实问题，通常作为无需实时人工干预即可执行多步骤工作流的自主系统运行。然而，随着处理的智能体请求数量增加，现代推理系统的吞吐量会下降（图1a）。同时，在强化学习（RL）中，推演（rollout）占据了总挂钟时间的70%以上 [5, 18]。

随着智能体工作流在规模上日益自主化，整体系统效率由持续吞吐量而非尾部延迟决定，而在人机交互应用中，用户体验通常由用户响应时间主导。因此，更高的吞吐量通过将硬件成本分摊到更多已完成的工作流上，直接降低了服务成本。此外，在异步RL中，更高的推演吞吐量减轻了用于数据收集的参数与正在更新的参数之间的策略滞后。这使得模型能够从陈旧性减少的数据中学习，从而提升收敛速度和最终策略质量 [5, 17, 18, 33]。

图1：随着并行工作流数量（即批量大小）增加，ThunderAgent与先前智能体推理系统的性能比较。我们在8xH100 GPU集群上评估了在SWE-Bench Lite上服务于SWE-Agent的GLM-4.6 MoE模型（图a和b）以及SWE-Agent、OpenHands和ToolOrchestra（图c）。结果表明：(a) 当前的推理系统在大批量大小下无法维持高吞吐量。(b) 吞吐量下降主要由低KV缓存命中率导致，这增加了端到端请求延迟。(c) 通过减少KV缓存抖动和管理工具执行资源的生命周期，THUNDERAGENT相比先前推理系统实现了高吞吐量。

然而，当前的智能体推理系统由于是从独立组件松散组合而成，因此提供的吞吐量次优：一个现成的模型推理引擎（例如，vLLM [11] 或 SGLang [34]）与一个通用工具编排器（例如，Kubernetes）耦合。尽管智能体工作流涉及多轮模型和工具请求，但这些组件在逐请求的基础上分别调度和分配资源，缺乏对整个工作流的端到端认知。这种设计带来了三个关键挑战：

1. KV缓存抖动：在高并发下的内存压力下，请求感知系统为了给其他并发程序的解码请求腾出空间，会反应性地驱逐在其工具执行间隔内的程序的KV缓存，而无法预见到智能体工作流中未来的重用。因此，当工具调用完成时，系统需要重新运行预填充以恢复其整个交互历史。重新预填充的成本使智能体工作流的平均端到端延迟增加了高达 7.14× （见图1b），并降低了吞吐量。

2. 跨节点内存不平衡：请求感知引擎在多节点推理设置中存在利用率不平衡的问题。现有引擎将来自同一智能体工作流的所有请求固定到一个节点，以最大化KV缓存命中率。然而，随着智能体工作流中上下文长度快速且不可预测地增长，在这种路由策略下，一些节点达到容量上限，而其他节点则利用不足。

3. 工具生命周期无感知：请求感知编排器难以决定何时释放和准备工具执行所需的资源和环境。因此，未使用的沙箱和API服务器持续占用关键的磁盘空间和网络端口，导致资源累积耗尽和系统故障。同时，智能体工作流在推理前必须等待极长的设置时间。

这项工作介绍了THUNDERAGENT，一个采用端到端视图的智能体推理系统，以实现高吞吐量的智能体服务和RL推演。我们的具体贡献如下：

1. 程序抽象：我们将智能体工作流抽象为智能体程序。智能体程序是一个一等调度单元，它跨越多次模型调用和工具执行而持续存在，并向运行时暴露语义状态。一个程序跟踪工作流的标识符、执行阶段（即推理或行动）、调度状态、总令牌数和工具资源等元数据。此抽象将调度与执行后端（例如，vLLM/SGLang/TensorRT-LLM）解耦，从而能够无缝集成新的工作流。

2. 程序感知调度器：基于程序抽象，我们将智能体推理调度形式化为一个约束优化问题，以最小化重计算和缓存开销，并在GPU内存容量的约束下最大化预填充和解码吞吐量。我们引入了两个关键机制：(a)状态感知暂停：如果执行后端遇到内存压力，我们选择性地暂停那些处于行动阶段（即等待工具返回）的程序，而不是任意驱逐KV缓存。通过利用程序元数据，我们的调度器可以识别并优先保留那些即将恢复推理（从而需要其KV缓存）的程序。(b)动态迁移：我们通过使所有数据并行（DP）节点共享一个全局程序感知等待队列，而非强制来自一个程序的请求始终发送到同一节点，从而在DP GPU节点之间迁移智能体程序以缓解内存不平衡。

3. 程序感知工具资源管理：在长时程智能体工作负载中，工具环境是持久性资源，其管理不善直接限制了持续吞吐量。通过跟踪执行依赖关系，THUNDERAGENT将I/O密集型环境初始化与LLM推理重叠进行。对于已完成的程序，我们实现了一个生命周期感知的垃圾回收器，利用程序终止信号来回收诸如Docker沙箱和网络端口等工具资源。因此，这防止了累积资源泄漏，并确保了THUNDERAGENT中持续的高吞吐量智能体推理。

上述贡献在请求感知推理引擎内无法实现。在没有程序状态和工作流依赖关系的显式表示的情况下，请求感知调度器无法区分临时工具等待与程序终止，也无法将GPU内存与程序级资源调度协调起来。

我们在不同的智能体工作负载上评估了THUNDERAGENT。对于服务场景，我们在HLE-Bench [16] 上评估作为路由智能体的ToolOrchestra [19]，在SWE-bench [10] 上评估作为编码智能体的SWE-Agent [28] 和 OpenHands [24]，以及在ScienceAgentBench [4] 上评估作为科学发现智能体的OpenHands，实现了如图1c所示的1.48-3.58倍的吞吐量提升。对于RL推演，我们进一步在分布式GPU节点上测试了编码智能体，与先前最先进的系统相比，实现了1.79-3.92倍的提升。

除了这些结果，我们还在常见的大规模部署设置下评估了THUNDERAGENT。如附录中详述，THUNDERAGENT的吞吐量在多达64个H100 GPU上随多个工作副本的数量呈近线性扩展（第A.3节），并且在与KV缓存卸载结合时仍然有效（第A.4节）。THUNDERAGENT已被SkyRL和NVIDIA Dynamo等开源框架采用（第A.6节）。

2 背景

在本节中，我们提供有关支持智能体推理的特性和现有方法的背景知识。

2.1 当前智能体工作流的系统特性

2.2 现有的智能体推理系统

先前的工作侧重于优化智能体推理中的各个组件，包括LLM推理引擎或工具编排器（第A.1节，第A.2节），但很少有工作能够跨GPU、CPU和远程资源为智能体工作流提供端到端优化。

Autellix 将多轮智能体工作流建模为仅限GPU的程序，并在一个中心进程表中跟踪累积的GPU执行时间 [14]。然而，它忽略了工作流局部性，允许并发工作流激进地驱逐其他程序的KV缓存，从而在重负载下触发KV缓存抖动。

Continuum 是另一个为多轮智能体工作流设计的近期服务系统 [12]。它采用生存时间（TTL）机制将KV缓存固定在HBM中，从而在工具执行期间减轻上下文抖动。然而，它未能解决KV缓存驱逐问题。第一个原因是大多数工具需要不可预测的时间（例如，ToolOrchestra [19] 中的远程模型API、代码智能体中的编译器以及计算机使用智能体的Web应用程序 [36]）。这些不可预测的工具在Continuum中由于错误的TTL估计而触发严重的抖动以及滞留的KV缓存内存。此外，一旦运行工作流的解码内存超过GPU限制，系统也会抢占并驱逐被固定的KV缓存。这导致了不可避免的抖动和相应的吞吐量下降，如图1a所示。

这些局限性突显了需要一个简单快速的智能体推理系统。我们设想这样的系统作为新兴智能体推理系统（例如，Zhang等人 [32]）的一个程序感知调度层。

3 现有智能体推理系统中的挑战

本节剖析了将vLLM与Kubernetes结合作为多轮智能体推理的代表性基线，并综合了其关键低效之处。值得注意的是，这些已识别的局限性无法通过替换推理引擎来解决，而是需要新的程序感知抽象。默认情况下，我们使用GLM 4.6模型在两个8×H100 GPU节点上进行OpenHands RL推演。

3.1 KV缓存抖动

智能体工作流在执行期间表现出很高的理论KV缓存重用率。然而，在现有的LLM服务系统中，每一步都作为一个独立的、无状态的请求来服务。在高并发下，这种请求级调度导致KV缓存在工具执行期间被频繁驱逐，以便容纳新到达的请求，从而引发重复的驱逐和重新预填充，我们称之为KV缓存抖动。

如图1b所示，随着并行工作流数量的增加，这种抖动加剧。由此导致的缓存命中率下降会触发频繁且代价高昂的重新预填充，即在工具完成后必须重新计算前缀。这种冗余显著增加了每个请求的端到端延迟，与非抖动设置相比高达 7.14×，导致了严重的吞吐量下降。

3.2 跨节点内存不平衡

当前用于跨工作副本路由请求的策略也是次优的。现有的多轮调度器 [22, 34] 为了最大化缓存重用，贪婪地将请求分配给具有最高KV缓存局部性的目标。然而，这种策略忽略了内存负载可能在不同节点间变得不平衡的事实。例如，vLLM [22] 中的KV感知路由器将来自同一智能体工作流的所有请求发送到同一节点。由于不同的工作流可能表现出高度异构的KV足迹和执行生命周期，这种策略常常导致节点间严重的内存不平衡，一些节点过载，而其他节点则利用率较低。类似地，SGLang中的缓存感知路由器通过一个路由器端的基数树来近似工作节点的KV状态，以此进行路由。在高智能体并发下，由KV抖动引起的工作节点端驱逐使得这棵树变得陈旧，从而导致缓存重用效果差和跨节点不平衡。

如图2a所示，在90分钟的智能体RL推演快照中，两个DP节点之间的内存使用差异在超过37分钟的时间里超过 20%，达到 51% 的峰值不平衡。

3.3 工具生命周期无感知

当前的智能体推理系统不会将外部工具编排器的生命周期与LLM推理引擎同步，导致工具编排器端出现无声的资源浪费和延迟开销。

资源泄漏和未使用的沙箱。图2b显示，总磁盘空间消耗随处理的工作流数量线性增加，最终超出系统容量。这是因为当工作流完成时，未使用的资源（例如，已完成工作负载的Docker镜像）不会被回收。这种低效的垃圾回收会导致长时间运行的智能体推理工作负载出现致命的系统不稳定。

昂贵的环境准备。我们观察到，大多数智能体工作流在启动多轮轨迹之前需要准备环境。例如，编码智能体需要拉取Docker、安装相关包和构建代码库。此外，这种准备时间成本高昂，并且会随着并行工作负载数量的增加而增加，如图2c所示。如果LLM推理引擎需要等待环境完全准备好，这种开销将延长推理系统的端到端延迟。

图2：当前智能体推理系统内存不平衡和工具资源管理问题的演示。我们使用GLM 4.6模型在SWEBench-Lite上，通过两个8×H100 GPU节点评估了vLLM + Kubernetes在OpenHands RL推演中的表现。观察结果显示：(a) 在90分钟的推演测试中，应用vLLM KV感知路由时，最大内存不平衡可达到51%。(b) 未能对工具执行环境进行垃圾回收，导致资源使用逐渐超出系统容量。(c) 随着并行工作流数量的增加，平均工具执行环境准备时间快速增长。

4 ThunderAgent：一个具有程序感知能力的智能体推理系统

基于第3节的所有发现，我们提出了THUNDERAGENT，一个用于高吞吐量智能体推理的程序感知系统。我们在第4.1节中对智能体程序进行建模，这是我们调度的主要抽象。第4.2节形式化了一个指导我们系统设计的成本模型。在这些基础之上，我们在第4.3节详述了我们的KV缓存调度策略，在第4.4节详述了工具资源管理策略。

表1：智能体程序的符号总结。每个程序实例由其标识、执行阶段、工具环境、资源占用和调度状态来表征。

4.1 程序抽象

智能体程序作为一个基础抽象，封装了智能体工作流的逻辑执行流和系统级依赖关系。形式上，我们将一个智能体程序 P 定义为一个元组：

图3：ThunderAgent概述。我们展示了调度状态和内存管理之间的转换。THUNDERAGENT每隔 ΔtΔt 时间定期查询每个数据并行后端的状态。此处，后端#1触发抖动，而后端#3未被充分利用。然后，所有后端共享的全局等待队列将行动中的程序#2暂停并回收至队列，同时释放推理中的程序#6和#9，以停止后端#1中的KV缓存抖动并减少后端#3的内存不平衡。

THUNDERAGENT通过接口与OpenAI风格端点对接，直接封装了现有的LLM引擎和工具编排器。程序ID允许系统区分来自不同智能体工作流的请求。我们在附录B中详述了将THUNDERAGENT与现有推理服务集成的简便性。

4.2 成本模型

在多轮智能体推理过程中，只有用于活跃预填充和解码的资源才对系统的有效吞吐量有贡献，而重计算、已用容量和空闲缓存则构成资源浪费。我们将其纳入GPU资源消耗的成本模型中，该模型将有效成本与非生产性使用区分开来。我们采用时空积（STP）[1] 作为主要指标，定义为内存占用在处理时间上的积分。处理阶段 x 期间的STP成本形式化为：

在此分解中，Costdecode 和 Costprefill 代表对推理吞吐量有贡献的有效工作。其余项是浪费的系统开销：Costrecompute 源于KV缓存抖动（第3.1节）；Costunused 反映了数据并行（DP）推理后端副本间的内存不平衡（第3.2节）；Costcaching 在外部工具执行期间持有内存时累积（第3.3节）。

4.3 调度策略

基于上述成本模型，我们调度策略的优化目标是最小化非生产性开销部分：Costrecompute、Costunused 和 Costcaching，从而最大化吞吐量。

4.3.1 通过程序感知等待队列减少重计算和缓存成本

如第3.1节和图1b所述，KV缓存抖动是吞吐量下降的主要瓶颈。为解决此限制，系统必须通过显式控制活跃程序的数量来最小化 Costrecompute。THUNDERAGENT通过引入一个程序感知等待队列来实现这一点。我们的系统利用此队列来调度程序执行，根据其令牌长度 c 和执行阶段 τ 来决定哪些程序应在GPU上执行，哪些应被交换出去。在此，我们使用两个原语操作来形式化调度器行为：恢复（Restore）和暂停（Pause），具体如下。

通过这种程序级周期性容量检查，THUNDERAGENT可以通过为行动阶段的活跃程序保留内存来保证不会发生KV缓存抖动。然而，权衡之处在于，当程序参与长时间运行的

工具执行时，行动程序占用的GPU内存是空闲的。为了在缓存成本与重计算成本之间取得平衡，我们在抖动检查中引入了一个时间衰减机制，该机制逐步降低行动程序令牌的有效权重。这使得调度器能够在内存压力上升时，驱逐长时间空闲的缓存，而不是无限期地保留它们：

4.3.1 通过程序感知等待队列减少重计算和缓存成本（续）

通过最短优先驱逐最小化 Costrecompute。在确定了上述驱逐和恢复条件后，处理抖动时剩下的问题是决定暂停哪些活跃程序子集，以使重计算成本最小化。在本段中，我们证明驱逐具有最小 KV 缓存大小的程序会产生最优解，详细证明见第 F.2 节。

其中指示函数 I(⋅) 强制优先考虑程序的执行状态 (τ) 而非上下文长度。两种机制都遵循最短优先策略以最小化重计算成本。然而，状态指示器 II 确保调度器优先暂停行动（Acting）程序，从而通过回收缓存内存来最小化 Costcaching，同时优先恢复推理（Reasoning）程序以最大化 Costdecode + Costprefill。

4.3.2 通过全局程序感知等待队列减少内存不平衡

第 3.1 节和图 2a 强调，跨节点的内存不平衡引入了显著的 Costunused，导致尽管其他节点有足够的内存容量，程序仍被不必要地暂停。为此，THUNDERAGENT 将所有后端副本的等待队列统一为一个全局程序感知等待队列。

此设计的关键动机在于，Costunused 仅在暂停程序留在等待队列中而某些副本有空闲内存时才会出现。此外，一旦程序被暂停，其 KV 缓存假定已被驱逐，使其重计算成本与节点无关。这使得我们能够在不牺牲 KV 缓存局部性的情况下改善跨节点内存平衡。恢复策略与负载均衡而非严格的 KV 感知路由保持一致，使得暂停的程序能够在有可用内存容量的工作副本上恢复。因此，全局队列将未使用成本限制为对于每个节点，在 Δt 周期内 Cunused<cmin⋅Δt，其中 cmincmin​ 表示暂停程序中最小令牌长度。THUNDERAGENT 中调度策略和全局等待队列的概述见图 3。

4.4 工具资源管理

接下来，THUNDERAGENT 缓解了第 3.3 节中详述的资源泄漏和环境设置开销。

基于钩子的垃圾回收。我们实现了生命周期钩子，将工具资源的持久性与智能体程序的调度状态 s 严格耦合。当一个程序终止（Terminated）时，回收器会触发一个立即的拆卸序列，系统地回收沙箱、网络套接字和计算槽。图 2b 中的活跃磁盘使用情况显示，我们的资源管理策略有效防止了过量资源的累积，并随时间维持了近恒定的磁盘内存消耗。

异步环境准备。初始化工具执行环境（例如，启动 Docker 容器和安装依赖项）所涉及的延迟可能成为一个瓶颈。为解决此问题，THUNDERAGENT 监视全局等待队列；当一个高优先级程序（高 Srestore​）接近恢复阈值时，系统在 GPU 内存分配之前异步恢复其执行环境。这种技术有效地隐藏了初始化开销，显著减少了像编码智能体和科学智能体这类工具调用密集型工作负载的端到端延迟，如图 2c 所示。

5 实验

在本节中，我们在多样化的智能体工作流上评估 THUNDERAGENT，包括编码、路由和科学研究智能体，以及在从 RTX5090 到 H100 集群的多种硬件配置上的 RL 推演。此外，我们在第 5.4 节进行了广泛的消融研究，以分解端到端系统运行时并描述调度器超参数 ΔtΔt 和 f(t)f(t) 的敏感性。

5.1 实验设置

基准和工作流。我们在不同的基准和工作流上评估 THUNDERAGENT：

1. 编码智能体服务。我们在 SWEBench-Lite [10] 上部署 OpenHands 和 mini-SWEAgent。OpenHands 代表一个重初始化工作流，每个沙箱的平均磁盘占用超过 10GB，而 mini-SWEAgent 是一个轻量级工作流，占用空间小（每个沙箱 2GB）。

2. 通用智能体服务。我们在 HLE [16] 上应用 ToolOrchestra，在 ScienceAgentBench [4] 上应用 OpenHands。这些工作负载涉及由外部 API 调用和复杂科学模拟驱动的可变延迟。

3. RL 推演。我们在两个 8×8× H100 节点上对 RL 推演应用相同的模型、工作流和样本。

模型和部署。我们使用 GLM-4.6 (355B) [21] 和 Qwen-3 (235B) [27] 模型，并结合 OpenHands [24] 和 mini-SWEAgent [28] 框架。模型量化至 FP8，并在 8× H100 节点上使用张量并行 (TP8)。对于 ToolOrchestra [19]，我们使用 Qwen-3-8B，FP16 精度，托管在一个 RTX 5090 上。

我们在不同的集群上部署 LLM 推理引擎和 Docker。LLM 推理引擎在托管模型的 GPU 集群上运行，而智能体 Docker 环境则卸载到专用的 CPU 集群。

ThunderAgent 配置。我们将 THUNDERAGENT 配置为超参数 Δt=5，优先级衰减 f(t)=2−t，如第 4.3 节所定义。我们采用 vLLM 作为我们的 LLM 推理引擎。我们使用每分钟步骤数作为吞吐量指标，其中一个步骤包括工作流的一个推理和行动周期。

基线技术。我们与具有不同调度范式的现有最先进系统进行比较：

• vLLM (推理)：一个广泛采用的、请求感知的 LLM 推理引擎，作为推理性能的无状态基线，不包含任何智能体或程序特定的感知。

• Continuum (推理)：当前针对多轮智能体工作流的最先进系统。它通过预测工具执行持续时间并相应地将 KV 缓存固定到 HBM 来缓解 KV 缓存抖动。

• vLLM + SGLang Gateway (分布式推演)：大规模分布式 RL 推演的领先解决方案。SGLang Gateway 通过增强跨节点内存平衡和 KV 缓存命中率来优化分布式推理，使其成为分布式 RL 推演设置的有力基线。

5.2 服务评估结果

高并发下的高吞吐量。图 4 显示，THUNDERAGENT 在高并发水平（例如，96 个并行程序）下展现出卓越的吞吐量，在不同基础模型和数据集上，相比 vLLM 实现了 1.48−3.58× 的加速，相比 Continuum 实现了 1.17−3.31× 的加速。这一提升源于我们的程序感知调度器，它维持了近最优的 KV 缓存命中率（对于 Mini-SWE-Bench 和 OpenHands 约为 100%100%，见图 5 a, b, d, e），并支持环境的异步准备。相比之下，Continuum 在高并发下性能下降。如图 5 所示，其 KV 缓存命中率从 >90% 显著下降至约 60%。这是因为当没有足够内存用于进行中请求的解码时，Continuum 在不同程序的请求之间遭受 KV 缓存驱逐。结果，活跃程序竞争有限的内存并触发抖动。

图 4：服务评估结果。THUNDERAGENT 在三种模型、四种智能体工作流和三个数据集上均优于 vLLM 和 Continuum。对于工具调用时间可预测的工作流（a, b, d, e），THUNDERAGENT 优于 vLLM 和 Continuum 高达 2.43−3.56×。对于表现出随机工具执行时间的工作流（c, f），THUNDERAGENT 仍然实现了最佳的吞吐性能。

对高并发的鲁棒性能。即使并行工作流数量超出 GPU 内存限制，THUNDERAGENT 仍能维持最大可达到的吞吐量。如图 4 所示，THUNDERAGENT 确保吞吐量随并行工作流数量保持稳定，而基线系统一旦工作负载超过内存限制，就会遭受严重的吞吐量崩溃。在实践中，由于智能体环境和工具执行持续时间的随机性，确定最优的并行工作流数量以在有限的 KV 缓存抖动和缓存成本下最大化利用率是不可行的。THUNDERAGENT 通过自动适应最大可用容量来解决此问题，无需手动调整，这一能力对于稳健的部署至关重要。

在确定性和随机性工具执行中的鲁棒性。THUNDERAGENT 不仅在具有确定性工具模式的工作流中优于基线（图 4 a, b, d, e），而且在高度随机条件下也表现优异（图 4 c, f）。这得益于我们动态的程序感知等待队列策略。vLLM 的请求感知调度器通常不为行动中的程序保留内存，导致频繁的重计算。相反，Continuum 为所有暂停的程序静态保留内存，并错误预测工具执行时间。这些在长时间、不可预测的工具调用期间导致昂贵的 Costrecompute 或 Costcaching。THUNDERAGENT 通过时间衰减函数 f(t) 来平衡它们，该函数优先为短工具调用的程序保留 KV 缓存，同时抢先暂停具有长工具执行时间的程序以防止内存浪费。如图 5（右侧）所示，尽管在随机环境中 THUNDERAGENT 的 KV 缓存命中率低于 Continuum，但它通过确保活跃的 GPU 利用率实现了更高的吞吐量。

5.3 推演评估结果

我们使用 GLM4.6 在一个双节点 H100 集群上评估 RL 推演。表 2 显示 THUNDERAGENT 能够维持有效的可扩展性，相比 vLLM + Gateway 基线实现了 1.79−3.92× 的吞吐量提升，使其对于内存密集型分布式 RL 工作负载非常高效。

表 2：GLM-4.6 推演 N=144 在 2×H100 节点上。

5.4 消融研究

端到端延迟分解。图 6a 分解了 OpenHands 推演的平均端到端延迟。吞吐量的提升主要源于预填充和解码延迟的减少。此外，工具资源管理策略（第 4.4 节）对延迟改进贡献了约 10%，同时提供了 4.2× 的磁盘内存节省。每步端到端延迟的进一步讨论见附录 E。

6 结论

我们介绍了 THUNDERAGENT，一个快速、简单的智能体系统，构建在程序级抽象之上，该抽象在智能体工作流的整个生命周期中跟踪元数据。THUNDERAGENT 利用程序抽象进行运行时调度和资源管理。具体来说，THUNDERAGENT 跨 GPU 节点动态调度程序执行，以缓解 KV 缓存抖动和内存不平衡，同时管理工具资源以防止资源泄漏。实验结果表明，与服务相关的 THUNDERAGENT 相比先前系统性能提升了 1.48−3.58×，与 RL 推演相关的性能提升了 1.79−3.92×。

图 6：端到端延迟分解和 THUNDERAGENT 参数敏感性的消融研究。