Together AI 发布 ThunderAgent：智能体推理吞吐最高提升 2.5 倍

摘要

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

关键结果

→ 单节点吞吐提升超过 2 倍，高并发下 P50 延迟降低约 10 倍
→ 8 节点上加速 2.4 倍，从 16 到 64 块 GPU 近乎线性扩展
→ 即插即用：只需一个 program_id 字段，兼容 OpenAI，可与现有引擎级优化（如投机解码）配合使用

ThunderAgent 被 ICML 2026 接收为 Spotlight 论文。

本论文由 Georgia Institute of Technology、University of Illinois Urbana-Champaign、Carnegie Mellon University 和 Together AI 的研究人员合作完成。

LLM 正越来越多地作为智能体部署。Claude Code、Codex 和 OpenClaw 等系统会进行推理、调用工具、读取结果，然后再次推理，往往在完成任务前要经历数十轮。训练这类智能体需要大规模合成数据生成，因为自然网络语料库不包含多轮、使用工具的智能体轨迹。为了生成像我们最近发布的 CoderForge 这样的智能体数据集，我们需要在高并发下运行智能体推理。

然而，现有推理引擎在请求级别进行调度，每个 LLM 调用都是一个独立单元，并不知道自己属于一个更长的多轮工作流。当智能体因工具调用而暂停时，其 KV 缓存可能被驱逐，以便为其他请求腾出空间，而当智能体恢复时又必须从头重新计算。这导致 SGLang、vLLM 和 TensorRT-LLM 等引擎在高并发服务智能体工作负载时出现根本性低效，包括 KV 缓存抖动、多节点间工作负载不均衡以及工具管理中的资源浪费。在本博客中，我们聚焦最关键的问题：KV 缓存抖动。更全面的讨论请参阅我们的论文。

是什么阻碍了大规模智能体推理

智能体工作流在两个阶段之间交替：GPU 密集的推理阶段，模型正在生成 token；以及 GPU 空闲的行动阶段，智能体正在等待编译器等工具返回。当数百个智能体并发运行时，它们的 KV 缓存在每个阶段都会增长，争夺有限的 GPU 内存。在这种内存压力下，像 vLLM 这样的传统推理引擎会使用简单策略驱逐 KV 缓存：最近最少使用，而不考虑该缓存是否会在几秒后再次被需要。

结果是一个恶性循环。智能体 A 因工具调用而暂停。它的 KV 缓存被驱逐，以便为智能体 B 的预填充腾出空间。当智能体 A 的工具返回时，引擎必须从头重新计算智能体 A 的整个对话历史，这反过来又驱逐了智能体 C 上下文的缓存。在高并发下，这种驱逐与重算的级联可能导致严重的吞吐量和延迟下降。我们将此问题称为 KV 缓存抖动。

单纯向问题投入更多 GPU 节点并不能完全解决它。现有的多节点路由器（如 SGLang Model Gateway）将每个 agent 固定到某个节点上，以保持缓存局部性。但由于 agentic 上下文长度增长不可预测，一些节点被分配了长上下文的 agent，导致内存耗尽，而另一些节点则闲置、容量有余。过载的节点仍然面临抖动。

采用 KV 缓存卸载同样无法解决问题。LMCache 和 HiCache 等策略将 KV 缓存卸载到 CPU 内存或磁盘，这扩大了总缓存容量，但只是推迟了抖动。当并发 agent 的工作集超过所有可用存储层级时，驱逐会重新开始，同样的恶性循环再次出现。

在内存压力下，请求级引擎会在 agent 因工具调用而暂停的那一刻驱逐其 KV 缓存，然后在恢复时必须重新计算整个对话，进而驱逐下一个 agent 的缓存，级联形成恶性循环。

ThunderAgent 如何解决抖动问题

请求级引擎无法自行解决抖动，因为它们从来看不到一系列 LLM 调用属于同一个更长的工作流。ThunderAgent 补上了这一缺失的视角。ThunderAgent 是一个轻量级调度层，位于 agentic 客户端与推理后端之间。它将每个 agentic 工作流抽象为一个可调度的程序，跟踪其执行阶段、KV 缓存占用和节点放置。

ThunderAgent 通过程序级调度缓解 KV 缓存抖动：它监控每个节点的内存压力，并有选择地暂停低优先级工作流，以减少竞争缓存的程序数量。并发程序减少后，剩余活跃工作流获得显著更高的 KV 缓存命中率和更低的延迟。当被暂停的工作流准备恢复时，ThunderAgent 通过全局等待队列将其路由到可用容量最多的节点，从而在集群范围内平衡负载。

对于多节点部署，ThunderAgent 用全局等待队列取代了基于会话的静态节点固定。当被暂停的工作流准备恢复时，ThunderAgent 将其请求路由到可用容量最多的节点。这种路由策略平衡了 KV 缓存局部性与多节点工作负载均衡之间的权衡，既实现了高效的缓存利用，又实现了集群内均匀的负载分布。

除了多节点可扩展性之外，ThunderAgent 还兼容 KV 缓存卸载，将 GPU HBM、CPU RAM 和磁盘存储中的 KV 缓存容量视为统一池。虽然仅靠卸载只能推迟而不能消除抖动，但 ThunderAgent 的暂停与恢复策略无论底层存储层级如何都依然有效。

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

评估

我们将 ThunderAgent 集成到内部的合成数据生成流水线中，这正是支撑 CoderForge 等数据集的同一套 harness 和基础设施，其中数百个 LLM 编码 agent 在数十轮交互中并发地与沙箱环境交互，以生成轨迹。

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

在单台 8×H100 节点上使用 HiCache 卸载时的单节点吞吐量和延迟，在并发 64 到 192 范围内扫描。ThunderAgent 保持吞吐量且延迟近乎持平，而基线则出现退化。

我们将评估扩展到多节点集群，在最多 8 个 H100 节点上与 SGLang Gateway 进行对比。如图所示，ThunderAgent 的吞吐量随 GPU 节点数量近乎线性扩展，从 16 个 GPU 扩展到 64 个 GPU 时，从 671 步/分钟增长到 2,248 步/分钟。同时，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 可以帮助您从相同的硬件中获得免费的加速。试试看，并告诉我们效果如何。