《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推演场景下相比vLLMSGLang Gateway提升1.79–3.92倍。KV缓存命中率接近100%可预测工具场景在随机工具场景中通过权衡缓存命中与计算效率仍保持更高吞吐。磁盘内存节省高达4.2倍。扩展到8节点64×H100时吞吐量接近线性增长。与KV缓存卸载技术如HiCache兼容进一步缓解内存压力。4. 理论分析与消融研究成本模型定义了时空积STP成本将总成本分解为解码、预填充、重计算、未使用容量、空闲缓存五部分调度器以最小化后三者为目标。时间衰减函数推导在工具执行时间不可预测且无记忆性的假设下严格证明指数衰减是唯一合理的形式。驱逐策略证明通过交换论证证明最短优先驱逐在二次重计算成本模型下全局最优。消融实验验证了全局队列、衰减函数形式、驱逐策略、检测周期等各组件对性能的贡献。5. 系统可移植性与采用情况ThunderAgent只需在请求中附加program_id并在程序结束时发送释放信号即可集成对现有API改动极小。已被SkyRLRL训练框架和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耦合。尽管智能体工作流涉及多轮模型和工具请求但这些组件在逐请求的基础上分别调度和分配资源缺乏对整个工作流的端到端认知。这种设计带来了三个关键挑战KV缓存抖动在高并发下的内存压力下请求感知系统为了给其他并发程序的解码请求腾出空间会反应性地驱逐在其工具执行间隔内的程序的KV缓存而无法预见到智能体工作流中未来的重用。因此当工具调用完成时系统需要重新运行预填充以恢复其整个交互历史。重新预填充的成本使智能体工作流的平均端到端延迟增加了高达 7.14× 见图1b并降低了吞吐量。跨节点内存不平衡请求感知引擎在多节点推理设置中存在利用率不平衡的问题。现有引擎将来自同一智能体工作流的所有请求固定到一个节点以最大化KV缓存命中率。然而随着智能体工作流中上下文长度快速且不可预测地增长在这种路由策略下一些节点达到容量上限而其他节点则利用不足。工具生命周期无感知请求感知编排器难以决定何时释放和准备工具执行所需的资源和环境。因此未使用的沙箱和API服务器持续占用关键的磁盘空间和网络端口导致资源累积耗尽和系统故障。同时智能体工作流在推理前必须等待极长的设置时间。这项工作介绍了THUNDERAGENT一个采用端到端视图的智能体推理系统以实现高吞吐量的智能体服务和RL推演。我们的具体贡献如下程序抽象我们将智能体工作流抽象为智能体程序。智能体程序是一个一等调度单元它跨越多次模型调用和工具执行而持续存在并向运行时暴露语义状态。一个程序跟踪工作流的标识符、执行阶段即推理或行动、调度状态、总令牌数和工具资源等元数据。此抽象将调度与执行后端例如vLLM/SGLang/TensorRT-LLM解耦从而能够无缝集成新的工作流。程序感知调度器基于程序抽象我们将智能体推理调度形式化为一个约束优化问题以最小化重计算和缓存开销并在GPU内存容量的约束下最大化预填充和解码吞吐量。我们引入了两个关键机制(a)状态感知暂停如果执行后端遇到内存压力我们选择性地暂停那些处于行动阶段即等待工具返回的程序而不是任意驱逐KV缓存。通过利用程序元数据我们的调度器可以识别并优先保留那些即将恢复推理从而需要其KV缓存的程序。(b)动态迁移我们通过使所有数据并行DP节点共享一个全局程序感知等待队列而非强制来自一个程序的请求始终发送到同一节点从而在DP GPU节点之间迁移智能体程序以缓解内存不平衡。程序感知工具资源管理在长时程智能体工作负载中工具环境是持久性资源其管理不善直接限制了持续吞吐量。通过跟踪执行依赖关系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 定义为一个元组图3ThunderAgent概述。我们展示了调度状态和内存管理之间的转换。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 周期内 Cunusedcmin⋅Δ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编码智能体服务。我们在 SWEBench-Lite [10] 上部署 OpenHands 和 mini-SWEAgent。OpenHands 代表一个重初始化工作流每个沙箱的平均磁盘占用超过 10GB而 mini-SWEAgent 是一个轻量级工作流占用空间小每个沙箱 2GB。通用智能体服务。我们在 HLE [16] 上应用 ToolOrchestra在 ScienceAgentBench [4] 上应用 OpenHands。这些工作负载涉及由外部 API 调用和复杂科学模拟驱动的可变延迟。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-8BFP16 精度托管在一个 RTX 5090 上。我们在不同的集群上部署 LLM 推理引擎和 Docker。LLM 推理引擎在托管模型的 GPU 集群上运行而智能体 Docker 环境则卸载到专用的 CPU 集群。ThunderAgent 配置。我们将 THUNDERAGENT 配置为超参数 Δt5优先级衰减 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, eTHUNDERAGENT 优于 vLLM 和 Continuum 高达 2.43−3.56×。对于表现出随机工具执行时间的工作流c, fTHUNDERAGENT 仍然实现了最佳的吞吐性能。对高并发的鲁棒性能。即使并行工作流数量超出 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 工作负载非常高效。表 2GLM-4.6 推演 N144 在 2×H100 节点上。工作流服务系统吞吐量 (步/分钟)mini-SWEAgentvLLM Gateway375.4mini-SWEAgentTHUNDERAGENT671.8 (1.79×)OpenHandsvLLM Gateway69.1OpenHandsTHUNDERAGENT270.8 (3.92×)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 参数敏感性的消融研究。