ThunderAgent: 2x Faster Agentic Inference for Synthetic Data Generation at Scale

ThunderAgent：实现大规模合成数据生成的2倍加速智能体推理

摘要

我们推出了ThunderAgent，这是一个面向高吞吐量智能体推理的系统。通过引入一种新型的程序抽象用于智能体LLM请求调度，ThunderAgent在我们的合成数据生成流水线中实现了单节点吞吐量最高达2.5倍的提升，并在8节点集群上实现了2.4倍的加速效果，且随着GPU节点数量增加，吞吐量呈现接近线性的扩展。

关键成果

→ 单节点吞吐量提升超过2倍，高并发场景下P50延迟降低约10倍 → 8节点集群加速2.4倍，16到64 GPU节点间实现接近线性扩展 → 即插即用：仅需添加一个program_id字段，兼容OpenAI接口，可与现有引擎级优化方案（如推测解码）无缝协作

ThunderAgent已被接收为ICML 2026的焦点论文。

本文由佐治亚理工学院、伊利诺伊大学厄巴纳-香槟分校、卡内基梅隆大学和Together AI的研究人员联合完成。

随着大语言模型越来越多地作为智能体部署，像Claude Code、Codex和OpenClaw这样的系统需要进行多轮推理、调用工具、读取结果并反复推理，通常需要数十轮交互才能完成任务。由于自然网络语料库中不包含多轮交互的工具使用轨迹，训练这些智能体需要大规模的合成数据生成。为了生成我们最近发布的CoderForge等智能体数据集，需要在高并发场景下运行智能体推理。

然而，现有推理引擎在请求级别进行调度，每个LLM调用被视为独立单元，无法识别其属于更长的多轮工作流。当智能体因工具调用而暂停时，其键值缓存可能被驱逐以腾出空间给其他请求，当智能体恢复时需要从头重新计算缓存。这种机制在SGLang、vLLM和TensorRT-LLM等引擎处理高并发智能体工作负载时，会导致根本性效率问题，包括键值缓存抖动、多节点间负载不平衡以及工具管理中的资源浪费。在本文中，我们重点讨论最关键的问题：键值缓存抖动。更多详细讨论请参见我们的论文。

大规模智能体推理面临的关键障碍

智能体工作流在两个阶段之间交替：GPU密集型的推理阶段（模型生成token）和GPU空闲的执行阶段（智能体等待工具如编译器返回结果）。当数百个智能体并发运行时，它们的键值缓存在每个阶段都会增长，争夺有限的GPU内存。在内存压力下，传统推理引擎如vLLM会采用简单策略驱逐键值缓存：无论该缓存是否会在几秒内再次使用，都优先驱逐最近最少使用的缓存。

这会形成恶性循环。智能体A因工具调用暂停，其缓存被驱逐以腾出空间给智能体B的预填充。当智能体A的工具返回结果时，引擎必须从头重新计算智能体A的完整对话历史，这又会驱逐智能体C的上下文缓存。在高并发场景下，这种驱逐和重新计算的级联效应会导致吞吐量和延迟严重退化。我们将这一问题称为键值缓存抖动。

仅通过增加更多GPU节点无法完全解决问题。现有的多节点路由器（如SGLang Model Gateway）会将每个代理固定到特定节点以保持缓存局部性。但由于代理上下文长度不可预测地增长，部分节点会被分配到需要大量内存的长上下文代理，而其他节点则因资源闲置而无法充分利用。过载节点仍会面临缓存抖动问题。

采用键值缓存卸载方案也无法彻底解决问题。LMCache和HiCache等方案通过将键值缓存转移到CPU内存或磁盘来扩展总缓存容量，但这只会延迟抖动的发生。当并发代理的工作集超出所有可用存储层级时，缓存驱逐会重新开始，导致同样的恶性循环。

在内存压力下，请求级引擎会在代理因工具调用暂停时立即驱逐其键值缓存，恢复时必须重新计算整个对话，接着又会驱逐下一个代理的缓存，从而引发连锁反应的恶性循环。

ThunderAgent如何解决缓存抖动问题

请求级引擎无法独立解决抖动问题，因为它们永远无法识别LLM调用序列属于更长的工作流。ThunderAgent补充了这一缺失视角。ThunderAgent是一个轻量级调度层，位于代理客户端和推理后端之间。它将每个代理工作流抽象为可调度程序，跟踪其执行阶段、键值缓存占用和节点部署情况。

ThunderAgent通过程序级调度缓解键值缓存抖动：它监控每个节点的内存压力，选择性暂停低优先级工作流以减少争夺缓存的程序数量。并发程序减少后，剩余活跃工作流的键值缓存命中率显著提升，延迟大幅降低。当暂停的工作流准备恢复时，ThunderAgent通过全局等待队列将其路由到可用容量最多的节点，实现集群负载均衡。

在多节点部署场景中，ThunderAgent用全局等待队列取代基于会话的静态节点绑定。当暂停的工作流准备恢复时，ThunderAgent将其请求路由到可用容量最多的节点。这种路由策略在键值缓存局部性和多节点工作负载平衡之间取得平衡，既实现高效缓存利用，又实现集群负载均衡。

除多节点可扩展性外，ThunderAgent还兼容键值缓存卸载，将GPU HBM、CPU RAM和磁盘存储的键值缓存容量视为统一池。虽然卸载方案只能延迟而无法消除抖动，但ThunderAgent的暂停恢复策略在所有存储层级下均保持有效性。

ThunderAgent位于代理客户端和推理后端之间，将每个工作流抽象为可调度程序。它在程序表中跟踪执行阶段、键值缓存占用和节点部署，在内存压力下暂停低优先级程序，并通过全局等待队列将其恢复到可用容量最多的节点。

评估

我们将ThunderAgent集成到内部合成数据生成流水线中，该流水线与CoderForge等数据集背后的相同框架和基础设施一致，其中数百个LLM编码代理通过数十轮交互与沙盒环境并发协作生成轨迹。

我们对比了 ThunderAgent 与 SGLang 默认调度器在单个 8×H100 节点上的性能，该节点使用 HiCache 进行 KV 缓存卸载。在批量大小为 192 时，SGLang 的吞吐量降至 390 token/s，平均延迟为 65 秒，而 ThunderAgent 实现了 803 token/s 的吞吐量，平均延迟为 10.6 秒，在吞吐量与延迟的权衡中扩展了帕累托前沿。

在单节点上，使用 HiCache 卸载的 8×H100 节点，通过并发数 64 至 192 的测试。ThunderAgent 在保持吞吐量的同时实现了接近平坦的延迟，而基线方案性能下降。

我们将评估扩展到多节点集群，与 SGLang Gateway 在最多 8 个 H100 节点上进行对比。如图所示，ThunderAgent 的吞吐量随着 GPU 节点数量近似线性增长，从 16 个 GPU 到 64 个 GPU 时吞吐量从 671 增长到 2,248 steps/min。同时，ThunderAgent 相比 SGLang Gateway 的加速比随着集群规模扩大而增加，从 2 个节点时的 1.79 倍增加到 8 个节点时的 2.39 倍。当集群规模扩大时，SGLang Gateway 会导致内存不平衡持续加剧，而 ThunderAgent 的全局等待队列会将恢复的工作流路由到具有可用容量的任意节点，从而减少集群范围内的内存不平衡。

从 2 个到 8 个 H100 节点的吞吐量扩展。ThunderAgent 保持近似线性扩展，并扩大了与 SGLang Gateway 的领先优势，从 2 个节点时的 1.79 倍增加到 8 个节点时的 2.39 倍。

结论

核心转变在于将每个代理工作流视为程序而非一系列无关请求。这单一抽象使 ThunderAgent 能够停止 KV 缓存抖动、跨节点平衡负载，并与您已运行的卸载和解码优化保持兼容。这也使系统具备实际部署价值：工作流端到端跟踪无需更改您的推理后端。

除了我们自己的合成数据流水线，ThunderAgent 已被 SkyRL 和 NVIDIA Dynamo 等开源框架采用。我们认为程序抽象是下一代代理推理系统的正确基础，我们期待看到社区基于此构建的创新应用。

立即体验！

ThunderAgent 旨在无缝集成到您现有架构中。它通过 OpenAI 兼容接口与推理后端交互，并可与您已使用的推理优化技术协同工作，如量化和推测解码。唯一需要的客户端更改是添加 program_id 字段以标识每个请求所属的程序。

ThunderAgent 开源且即刻可用：

• GitHub : https://github.com/ThunderAgent-org/ThunderAgent

• 论文 : https://arxiv.org/abs/2602.13692

如果您正在运行大规模代理工作负载，ThunderAgent 可帮助您在相同硬件上实现免费午餐式的加速效果。立即尝试，告诉我们您的使用体验。