ThunderAgent：把每次 Agent 任务当成"程序"调度，把 KV cache 抖动打掉，推理吞吐翻倍
2026 年 7 月 29 日，Together AI 工程团队联合 Georgia Tech、UIUC、CMU 在官方博客发布 Agentic 推理调度框架 ThunderAgent，并同步开源代码与论文（arXiv:2602.13692）。这篇已被 ICML 2026 接收为 Spotlight 论文的工作，直接瞄准当下推理框架在大规模 Agent 并发场景下的一个老毛病：KV cache 抖动（KV cache thrashing）。
背景：现在的 vLLM / SGLang / TensorRT-LLM 为什么在 Agent 场景"水土不服"
文章把问题描述得相当直白——这些主流推理引擎都是「请求级（request-level）」调度器，每一个独立的 LLM 调用对调度器来说就是一个原子单位，看不见这是一个长链路 Agent 任务的一部分。
典型的 Agent 工作流是这样的：
- reasoning 阶段：模型在 GPU 上疯狂吐 token；
- acting 阶段：Agent 在等外部工具返回（比如编译器、搜索、shell），GPU 完全空转。
一个 8 卡 H100 节点同时跑上百个 Agent，每一轮的 KV cache 都在涨。当节点显存吃紧的时候，老调度器机械地按 LRU 踢 cache——Agent A 刚停下来等一个工具调用，它的 KV cache 就被踢掉给 Agent B 让路；几秒后 Agent A 的工具返回，调度器只能从头重新预填它的整段对话历史，又顺手把 Agent C 的 cache 踢掉。这样连锁反应下去，就是 ThunderAgent 命名里的 thrashing（抖动）。
文章的 baseline 数据很扎心：同样 8×H100 + HiCache offload、batch size 192，SGLang 默认调度器吞吐只跑出 390 token/s、平均延迟 65 秒。
ThunderAgent 的解法：把整个工作流抽象成"可调度的程序"
ThunderAgent 不是又写了一个推理引擎，而是在调度粒度上做文章。它是一个轻量级调度层，夹在 Agent 客户端和推理后端之间，引入了一个新概念 ——「程序级（program-level）」调度。
具体三板斧：
- 把 Agent 工作流抽象成 program：调度器维护一张 program table，记录每一个 Agent 程序当前在哪一阶段（reasoning 还是 acting）、占用多少 KV cache、落在哪个节点上。
- 主动暂停低优先级 program：显存吃紧时不是粗暴踢 cache，而是暂停整个低优先级的工作流，让活跃工作的 KV cache 命中率稳住。
- 全局等待队列 + 多节点均衡：被暂停的 program 恢复时，由调度器送到当时空余 KV 容量最大的节点去，而不是死绑在原来的节点。这解决了 SGLang Gateway 那种静态 pin 节点策略在长尾上下文下的内存失衡问题。
另外，ThunderAgent 跟 HiCache / LMCache 这些 KV cache offloading 方案是叠加关系，不是替代。它把 GPU HBM、CPU RAM、磁盘三层 cache 看成"统一池"，offload 不再是缓兵之计，能跟 program-level 调度配合真正"治本"。
数字说话
Together AI 在自家 CoderForge 合成数据生成流水线（上百个 Agent 跑沙箱、几十轮 code trajectory）上做的内部对比：
- 单节点：batch 192 时，吞吐从 SGLang 的 390 token/s 提到 ThunderAgent 的 803 token/s（≈ 2.06×），平均延迟从 65 秒降到 10.6 秒（≈ 6×）。
- 8 节点 64 卡：吞吐从 16 卡 671 steps/min 线性扩到 2,248 steps/min，相对 SGLang Gateway 的领先优势从 2 节点的 1.79× 拉到 8 节点的 2.39×。
- 接入成本极低：论文强调 ThunderAgent 对客户端只需要加一个
program_id字段，用 OpenAI-compatible 接口，对现有 speculative decoding、量化这些优化完全 pass-through。
文章还提到 ThunderAgent 已经被 SkyRL 和 NVIDIA Dynamo 接入——Dynamo 这种 NVIDIA 刚发力的分布式推理框架愿意接，说明 program-level 这个抽象在工业界也会被验证。
所以呢：调度层的"下一个 Transformer 级"机会？
推理框架的演进过去两年基本是**「让单卡跑得更快」这条线（PagedAttention、continuous batching、prefix caching、FlashAttention）；进入 Agent 时代以后，工作负载从「一次性问答」变成「几十轮带工具的长程任务」**，调度器的视野必须从「请求」上提到「程序」。
ThunderAgent 的核心 insight 其实只有一句话：scheduler 一旦能看见"两个相邻 LLM 调用其实属于同一个 Agent"，它就能比 LRU 做更聪明的取舍。这套抽象和 Thompson Sampling、Speculative Decoding 一样属于"看起来朴素，落地就跑出来"的工程 trick——但作者来自 Georgia Tech/UIUC/CMU/Together AI 这套组合，决定了它很快会被主流框架吸收。
对国内搞 Agent Infra 的同学来说，下一个值得盯的也许不是再写一个 inference engine，而是接住 program-level 调度这个抽象——尤其是在 long-horizon 多 Agent 协作或国产 GPU 多卡环境下的中文工程实现，目前公开实现还很稀疏。