ThunderAgent: A Simple, Fast and Program Aware Agentic Inference System

Source #

• Workflow version: v2
• Material type: research-paper
• Canonical source: arXiv 2602.13692
• Title: ThunderAgent: A Simple, Fast and Program-Aware Agentic Inference System
• Authors: Hao Kang, Ziyang Li, Weili Xu, Xinyu Yang, Yinfang Chen, Junxiong Wang, Beidi Chen, Tushar Krishna, Chenfeng Xu, Simran Arora
• arXiv: abstract
• HTML: arXiv HTML v3
• PDF: arXiv PDF
• TeX Source: arXiv source v3
• Code/Project: ThunderAgent repository；project page
• Code snapshot: main@7ddc8610270e56d3b109eed8796b3a4360fc67c9，committed 2026-06-05
• Downstream integrations: NVIDIA Dynamo PR #9448；SkyRL PR #1645
• OpenReview / Review page: ICML 2026 forum
• Venue page: ICML 2026 poster 62040；Spotlight
• Submitted: 2026-02-14
• Published / updated: 2026-02-14 / 2026-06-30
• Current version read: arXiv v3
• Version / revision read: arXiv v3 source、PDF 与 main@7ddc861；OpenReview metadata observed 2026-07-13
• Accessed: 2026-07-13
• Subjects: Operating Systems (cs.OS); Multiagent Systems (cs.MA)

作者与关系 #

• Hao Kang: Georgia Institute of Technology.
• Ziyang Li: Individual Researcher.
• Weili Xu: University of Illinois Urbana-Champaign；历史机构：Zhejiang University, Together AI.
• Xinyu Yang: Carnegie Mellon University.
• Yinfang Chen: University of Illinois Urbana-Champaign.
• Junxiong Wang: Together AI；历史机构：Cornell University.
• Beidi Chen: Carnegie Mellon University；历史机构：Amazon Scholar, FAIR / Meta, Stanford University, Rice University.
• Tushar Krishna: Georgia Institute of Technology；历史机构：MIT, Harvard University, Princeton University, IIT Delhi, Intel.
• Chenfeng Xu: Together AI；历史机构：University of California, Berkeley, The University of Texas at Austin.
• Simran Arora: Together AI；历史机构：Stanford University, Caltech.

阅读目标与判断边界 #

本笔记关注：

1. ThunderAgent 如何把多轮 agent workflow 抽象成可调度对象。
2. program-aware scheduler 如何在 KV 复用、重算和跨节点负载之间做权衡。
3. 论文实验对 online agentic serving 与 RL rollout infrastructure 的启发。

判断边界：

• 本文主要评估 agentic serving / rollout 吞吐，模型能力提升不作为评估目标。
• 论文给出了系统实现、开源仓库和多 workload 实验，但 baseline 调参细节、不同 orchestrator 配置和统计置信区间披露有限。
• HTML 版本有少量公式渲染缺失，本笔记对关键公式以 TeX source 和 PDF 为准。

论文脉络 #

1. 研究问题、背景和价值 #

agentic workflow 的实际运行形态是多轮循环：LLM 生成动作，外部工具执行，工具结果再进入下一轮上下文。论文考察的部署由 request-level serving engine 与独立 tool orchestrator 组成，前者处理 chat completion 和 KV，后者处理 Docker、端口与文件系统资源。在所测高并发 agent workload 中，跨组件状态缺少统一表示，论文据此归纳三类系统损耗：

1. KV cache thrashing：工具调用期间，当前 program 的 KV cache 可能被别的 decode request 挤出；工具返回后又要对完整历史重新 prefill。论文在 Figure 1 中报告 re-prefill 可使平均端到端 latency 增加到最高 $7.14\times$。
2. 跨节点内存不均衡：KV-aware / session-aware routing 用固定 placement 保留 KV locality，也减少了跨节点重新平衡的自由度。论文 Figure 2(a) 的两节点 OpenHands rollout 在 90 分钟内有 37 分钟的节点内存差超过 20%，峰值为 51%；该观测支持上下文长度和工具等待高度异质的场景，无法直接推广到均匀、大量 session 的负载。
3. tool lifecycle obliviousness：当 LLM engine 与 tool orchestrator 之间缺少 termination 和 preparation 信号时，已结束 program 的 sandbox、端口和磁盘资源可能继续保留，后续 program 也可能同步等待环境初始化。

这篇论文的价值在于把 “agentic workflow 是 serving runtime 的一等对象” 具体化为系统 API、调度状态、cost model 和可运行实现。

2. 已有解决方案与不足 #

论文主要对照三类方案：

• vLLM / SGLang 这类 request-level engine：论文将其作为擅长 batching、prefill/decode 调度和 KV block 管理，但缺少跨请求 program phase、tool wait 与 termination signal 的执行层。
• KV-aware routing / session pinning：可以提升同一 session 的 KV 命中率；当 session 的 KV footprint、生命周期和恢复时刻高度异质时，固定 placement 会限制负载迁移。session 数量充足且分配考虑真实 KV footprint 时，节点负载仍可能接近平衡。
• Continuum / tiered KV cache / offloading：用 TTL、工具时长预测或 CPU/NVMe cache 降低 KV 丢失成本。论文的高频 agent context-switching 实验显示 TTL 误差、offload/prefetch 带宽和 stale cache 占用会限制收益；这一结果依赖具体模型、互连与 workload。

ThunderAgent 的设计方向是让调度器直接看到 program 粒度的状态，减少对请求历史、session id 或 tool timeout 的间接推断。

3. 作者可能的思考路径 #

作者从 agent workload 的生命周期出发：一次 agent 任务跨多个 LLM request 和多个 tool execution，因此论文选择整条 program 的 GPU 与工具资源生命周期作为分析单位。只观察当前 request 的 runtime 无法直接区分正在等待工具的 acting program 与即将继续 decode 的 reasoning program，于是需要一个状态对象记录：

• 当前 program 属于 reasoning 还是 acting；
• context token count 对应多少 KV footprint；
• program 当前绑定到哪一个 backend；
• 工具资源是否存在、是否需要预热、何时可回收；
• program 是否 active、paused 或 terminated。

这样 scheduler 可以在高并发下做主动 pause / restore，避免只在 backend 触发被动 KV eviction 后才反应。

4. 核心假设或切入点 #

ThunderAgent 的核心切入点是 LLM Program：

$$P=\langle \mathit{ID},c,\mathcal{T},\mathcal{L},\tau,s\rangle$$

其中 $\mathit{ID}$ 是 program id，$c$ 是上下文 token 数和 KV footprint，$\mathcal{T}$ 是工具环境集合，$\mathcal{L}$ 是 backend placement，$\tau$ 是 phase（Reasoning $\mathbf{R}$ 或 Acting $\mathbf{A}$），$s$ 是 status（Active、Paused、Terminated）。

这个抽象使得 runtime 可以用显式状态做三类决策：

1. 论文提出可选的 elapsed-time decay，使 acting KV 的有效预留权重随等待时间下降；当前公开实现默认关闭该选项，并将它用于恢复侧容量判断。
2. reasoning program 即将继续 decode 时，优先保留或恢复其 KV。
3. paused program 的 KV 已经释放后，可以放入全局队列并在有容量的节点重新 prefill；这一步对应释放 KV 后的重新 placement，执行时不会把 live KV 跨节点迁移。

5. 方法 / 系统 / 理论框架 #

ThunderAgent 由 program-aware scheduler 和 tool resource manager 组成。

Cost model. 论文用 Space-Time Product 衡量资源占用：

$$\mathrm{Cost}_x=\int_0^{t_x}M_x(t)\,dt$$

总成本分解为：

$$\mathrm{Cost}_{\mathrm{total}}\approx \mathrm{Cost}_{\mathrm{decode}}+ \mathrm{Cost}_{\mathrm{prefill}}+ \mathrm{Cost}_{\mathrm{recompute}}+ \mathrm{Cost}_{\mathrm{unused}}+ \mathrm{Cost}_{\mathrm{caching}}$$

其中 decode / prefill 被归为有效工作，recompute、unused、caching 被归为开销项。论文用这组分项组织后续机制：shortest-first 对应 recompute，global waiting queue 对应 unused，time decay 对应 caching。

写作作用与边界。 这组总成本分解为方法章节提供全局 accounting 视角，$\mathrm{Cost}_{\mathrm{total}}$ 的作用接近 cost taxonomy 和章节路线图。ThunderAgent runtime 未直接累计或求解五项总和；实际调度使用 program phase、token length、elapsed acting time 与 backend capacity 等局部代理信号。因此，正文中的“optimization target”应理解为设计目标，当前实现没有对应的统一数值优化器。

STP 积分本身可以测量一段资源占用的 memory-time，例如以 token-second 或 GB-second 为单位。五项总和未进一步给出互斥的归因边界、相对权重和统一求解过程；在固定容量与固定观察时长下，若全部 memory-time 都被划入“使用”或“未使用”，总量还可能退化为 $C\times T$，无法单独区分调度策略。直接进入局部推导的是 $\mathrm{Cost}_{\mathrm{recompute}}\propto c^2$，其适用边界在 shortest-first 小节单独审计。

这类写法可以复用于系统论文，但应依次补齐四个环节：

1. 定义统一资源单位，并固定 workload、完成量或观察时长。
2. 将 productive work 与 overhead 分解为边界明确、尽量不重叠的成本项。
3. 为每个可控开销指定局部代理量、系统机制和实验指标。
4. 明确区分概念性 accounting、runtime heuristic 与实际求解的 optimization objective；若将总式声明为可执行目标，还需报告各分项测量或给出求解过程。

Pause / restore. restore 把 paused program 绑定到某个 backend 并激活：

$$P\leftarrow\langle \mathit{ID},c,\mathcal{T},\mathcal{L}',\tau,\mathrm{Active}\rangle$$

pause 解绑 backend 并释放 KV：

$$P\leftarrow\langle \mathit{ID},c,\mathcal{T},\varnothing,\tau,\mathrm{Paused}\rangle$$

周期性 thrashing detection. 基础判断是当前 backend 的 KV 需求超过容量：

$$C_{\mathrm{total}}<\sum_{p\in\mathcal{L}}c_p$$

若超过容量，scheduler 需要释放：

$$\Delta C=\sum_{p\in\mathcal{L}}c_p-\lambda_{\max}C_{\mathrm{total}}$$

恢复阈值为：

$$\sum_{p\in\mathcal{L}}c_p < \lambda_{\min}C_{\mathrm{total}}$$

论文实现中 $\lambda_{\max}$ 和 $\lambda_{\min}$ 均设为 $1$，并用 shared prompt 预留 buffer。

Acting program 的时间衰减。 工具执行时长不稳定，ThunderAgent 对 acting program 的有效 KV footprint 加上时间衰减：

$$C_{\mathrm{total}} < \sum_{p\in\mathcal{L},\tau=\mathbf{R}}c_p + \sum_{q\in\mathcal{L},\tau=\mathbf{A}}c_q f(t_q)$$

$t_q$ 是当前 step 已经过的 tool execution time。Appendix F.1 在“衰减只依赖 elapsed time”、time-homogeneous 相对衰减和边界条件下，推导出连续时间指数形式或离散 tick 几何形式；该定理约束函数形状，未给出最优衰减率或最优 keep / evict 策略。论文配置采用 $f(t)=2^{-t}$，检测周期 $\Delta t=5$。

令加权后的有效预留量为：

$$D_{\mathrm{eff}} = \underbrace{\sum_{\tau=\mathbf R}c_p}_{\text{reasoning 全额预留}} + \underbrace{\sum_{\tau=\mathbf A}c_qf(t_q)}_{\text{acting 衰减预留}}.$$

$D_{\mathrm{eff}}>C_{\mathrm{total}}$ 表示加权后的 KV reservation 超出 backend 的虚拟预留预算。当前公开实现用它排除该 backend 的 _greedy_resume() 候选；物理 pause 由另一条不带衰减的容量检查独立触发。$D_{\mathrm{eff}}\le C_{\mathrm{total}}$ 只表示存在虚拟恢复余量，无法证明真实 KV 占用安全。

这里的右侧不表示历史累计成本。真实物理占用是：

$$D_{\mathrm{physical}} = \sum_{\tau=\mathbf R}c_p + \sum_{\tau=\mathbf A}c_q, \qquad D_{\mathrm{physical}}\ge D_{\mathrm{eff}}.$$

$c_qf(t_q)$ 只表示 acting KV 中继续受到调度器保护的份额；$c_q(1-f(t_q))$ 被视为压力出现时可以回收的份额。在 shared-prefix deduction 与 per-program buffer 口径一致时，$D_{\mathrm{physical}}\ge D_{\mathrm{eff}}$；虚拟预留量处于预算内时，真实占用仍可能超过容量。

当前公开仓库 main@7ddc861 把这两层检查分开实现：

1. BackendState.remaining_capacity_with_decay() 计算 $C_{\mathrm{total}}-D_{\mathrm{eff}}$，只供 _greedy_resume() 做 optimistic resume。若结果为负，该 backend 不接收更多 paused program。
2. _scheduled_check() 随后调用不带衰减的 remaining_capacity()。若真实 token accounting 超出容量，才进入 _pause_until_safe()。
3. _pause_until_safe() 先 pause 最短的 acting program，再处理最短的 reasoning program；释放量按真实 $c_q$ 计算。

这与论文 Section 4.3 中“decayed check governs both Pause and Restore”的抽象描述存在实现层差异。当前代码将 decay 用作恢复侧的 overbooking / replacement policy，物理安全由完整 token 量保证；use_acting_token_decay 也是默认关闭的可选配置。

例如 $C_{\mathrm{total}}=100$，reasoning KV 为 60，一条 acting program 的真实 KV 为 40：

• 工具刚启动时 $f(0)=1$，$D_{\mathrm{eff}}=60+40=100$，acting KV 全额受到保护。
• 等待一段时间后若 $f(t)=0.25$，$D_{\mathrm{eff}}=60+40\times0.25=70$。调度器把 10 视为保留量，把其余 30 视为可回收容量。
• 若 waiting queue 中有一条 20-token reasoning program，decayed headroom 为 30，因此 _greedy_resume() 可以恢复它。恢复后 $D_{\mathrm{eff}}=90\le100$，真实占用升到 $D_{\mathrm{physical}}=120$。
• 随后的真实容量检查发现超出 20，pause 这条 40-token acting program 后，物理占用降到 80。时间衰减的实际作用是允许 ready reasoning work 替换 long-idle acting KV。

这个例子展示了 replacement effect：elapsed-time decay 先释放虚拟 headroom，不带衰减的容量检查随后释放整条 acting KV。衰减式不负责排列驱逐对象；当前实现使用 phase priority 与 shortest-first，多个 acting program 之间没有直接按 $t_q$ 排序。

这个式子描述调度器的有效保留权重，实际 KV footprint 仍由 $c_q$ 决定，历史已经占用的 HBM 也不构成当前决策成本。reasoning program 正在 decode / prefill，按完整 $c_p$ 计入容量压力；acting program 正在等待工具，暂时不贡献 GPU 有效工作，其 reservation weight 随等待时间下降。

因此，时间衰减应理解为 KV reservation aging policy。它的当前决策依据仍应是未来边际收益与未来机会成本：继续保留 KV 可以省去未来 re-prefill / recompute，但继续占用 HBM 会挤出其他 reasoning program。Elapsed acting time 本身并不等同于剩余工具时间预测；在严格 memoryless 工具时长下，已等待时间不会改变剩余时间分布。论文附录的指数 / 几何衰减推导实际依赖两个额外假设：衰减只依赖 elapsed time，并满足 time-homogeneous 相对衰减 $f(t+\Delta)=f(t)f(\Delta)$，再加上 $f(0)=1,\lim_{t\to\infty}f(t)=0$ 的边界条件。

Shortest-first eviction. 论文把重算 STP 写成与上下文长度平方成比例：

$$\mathrm{Cost}_{\mathrm{recompute}} = \int_0^{t_{\mathrm{recompute}}}c_i(t)\,dt \propto c_i^2$$

释放容量时的优化问题是：

$$\min_S\sum_{i\in S}c_i^2 \quad\text{s.t.}\quad \sum_{i\in S}c_i\ge\Delta C$$

平方关系来自论文采用的 STP 近似：chunk size 固定时，重算时间随上下文长度 $c_i$ 近似线性增加，重算过程中的 KV footprint 从 0 增长到 $c_i$，因此“平均 footprint $\times$ 重算时间”与 $c_i^2$ 同阶。实际 kernel、chunking、batch shape 和 memory bandwidth 会改变这一近似。

Appendix F.3 进一步声称 shortest-first 对上述离散子集问题全局最优，这个证明需要额外条件。整条 program 不可分割且允许超额释放时，凸 item cost 本身无法保证升序 greedy 最优。例如候选长度为 $\{4,6,7\}$、目标 $\Delta C=7$ 时，shortest-first 先选 4 再选 6，成本为 52；直接选择 7 的成本为 49。附录 exchange argument 使用了“拆分长 program”或“由短 program 精确替换”的步骤，系统操作并不支持任意拆分，也未保证短 program 组合具有相同释放量。因此，本笔记把 $c_i^2$ 视为偏向短 program 的局部依据，把 shortest-first 视为经 Appendix G.3 两个 workload 支持的 heuristic，不采用无条件全局最优结论。

论文给出的抽象打分为：

$$S_{\mathrm{restore}}(P)=\frac{1}{c_P}+\mathbb{I}(\tau=\mathbf{R})$$

$$S_{\mathrm{pause}}(P)=\frac{1}{c_P}+\mathbb{I}(\tau=\mathbf{A})$$

这等价于先按 phase 决定大方向：pause acting 优先、restore reasoning 优先；同一类内再做 shortest-first。main@7ddc861 的 pause 路径保留这一优先级，restore 路径增加了 new-program 中间优先级，并先按优先组选择候选，再以 Best Fit Decreasing (BFD，递减最佳适配) 将较大候选放入剩余容量最大的 backend。论文公式适合解释设计偏好，无法完整描述当前恢复实现。

全局 program-aware waiting queue. paused program 的 KV 已释放后，恢复位置不再受原 backend 限制，可以进入全局队列等待任意节点容量。论文给出一个 unused cost 上界：

$$C_{\mathrm{unused}}<c_{\min}\Delta t$$

这个上界依赖固定检测周期和最小 paused program 长度等建模条件。系统机制是在 KV 已释放后重新选择恢复节点并执行 re-prefill，因而重新获得 placement 自由度；它适合节点间存在闲置容量且 re-prefill 成本可接受的负载。session 分布均匀或上下文极长时，收益需要重新测量。

Tool resource management. 工具侧有两项机制：

• hook-based garbage collection：program 进入 Terminated 时触发 teardown，回收 sandbox、socket、磁盘和计算资源。
• asynchronous environment preparation：scheduler 监控全局队列；高优先级 program 接近 restore threshold 时，在分配 GPU memory 前异步恢复工具环境。这里使用队列优先级和阈值信号，没有预测工具剩余执行时间。

论文 Section 4.4 给出机制级描述，Section 5.4 将整组 tool resource management 归因为约 10% 的 latency 改善，并报告 $4.2\times$ disk memory savings。论文未分别隔离 GC 与异步准备的收益，也未展开 teardown 幂等性、失败重试、共享环境引用计数和错误恢复协议，因此这两项结论依赖具体 orchestrator 与 workload。

公开实现边界与下游移植。 三层材料需要分别阅读：

1. 论文 v3 在 Section 4.3-4.4 定义 decayed capacity check、phase-first pause / restore、全局 waiting queue、hook-based GC 与异步环境准备。
2. ThunderAgent main@7ddc861 的核心 ThunderAgent/ 包实现 program_id 解析、program 状态、backend 容量统计、全局 waiting queue、pause / restore、BFD placement 和 /release_program。其中 /release_program 清理 scheduler 中的 program/KV accounting；sandbox、socket、disk teardown 与 environment prewarm 由 vendored workload/orchestrator 的具体集成承担。
3. NVIDIA Dynamo PR #9448 将 program scheduler 作为 opt-in experimental service 合入 Dynamo，改用真实 token accounting、trajectory_id 和严格的 non-decayed resume gate。PR 报告 Pi + Dynamo 相对 KV-routing-only baseline 提升 12% 至 16%，同时明确更广泛 multi-worker repeats 仍属后续工作。该移植支持 program abstraction 的可迁移性，并表明 Dynamo 实验性集成可以在不启用 elapsed-time decay 的配置下工作；该 PR 没有比较各 decay 策略的普适优劣。

证据定位：论文 Section 4.3-4.4、Section 5.4；ThunderAgent/app.py::release_program、ThunderAgent/backend/state.py::remaining_capacity_with_decay、ThunderAgent/scheduler/router.py::_scheduled_check/_greedy_resume；Dynamo PR #9448。

6. 结论链条 #

论文的结论链条可以概括为：

1. agent workflow 有 persistent KV state 与 persistent tool state。
2. 在论文所测高并发 workload 中，request-level 调度与独立 tool orchestration 对应 re-prefill、HBM imbalance 和 tool resource leakage。
3. LLM Program 把 workflow id、phase、tokens、placement、tool resources 和 status 合成统一调度对象。
4. STP taxonomy 为 phase-first、shortest-first 和 global restore 提供设计动机；runtime 实际执行局部启发式，没有求解五项总成本。
5. 公开核心包将 program scheduler 实现为 vLLM / SGLang 上层 middleware；agent 侧需要 program_id 与 termination signal，backend capacity 查询已经进入 scheduler，tool teardown / preparation 仍由相应 orchestrator 提供。

关键实验/定理 #

结果 1：高并发 serving 吞吐 #

• 设置：OpenHands、mini-SWEAgent、ToolOrchestra、ScienceAgentBench 等 agent workflow；GLM-4.6 355B、Qwen3 235B、Qwen3-8B；GPU 集群与工具环境分离部署。
• Baseline：vLLM request-level serving、Continuum multi-turn serving。
• 指标：steps per minute；一个 step 包含 reasoning 与 acting。
• 证据定位：Section 5.2，Figures 4 与 5；Appendix G 的 KV hit-rate 与 tool-latency 分析。
• 结果：在论文列出的模型、workflow 与并发 sweep 中，ThunderAgent 相对 vLLM 达到 $1.48\times$ 到 $3.58\times$，相对 Continuum 达到 $1.17\times$ 到 $3.31\times$。
• 对照是否可比：同一子实验使用相同模型、agent workflow、数据与 GPU 配置；论文未完整披露 vLLM / Continuum 的版本、调参网格、随机种子和置信区间，因此属于 workload-matched、实现细节部分可比。
• 支持的最窄结论：在论文列出的高并发 tool-use workloads 和配置中，program-aware scheduler 提高了持续 steps/min，并避免部分 baseline 在 KV 容量饱和后的吞吐下降。
• 解读：Figures 4-5 支持 program-aware scheduling 在这些高并发 tool-use workload 中提高 steps/min。可预测工具设置下有四组接近 100% KV hit；随机工具设置下，较低 KV hit 与较高吞吐同时出现。倍率依赖 workload、并发、baseline 配置和工具环境，无法直接外推到一般 agent service。

结果 2：RL rollout 吞吐 #

• 设置：GLM-4.6 rollout，$N=144$，两台 $8\times$H100 节点。
• Baseline：vLLM + SGLang Gateway。
• 指标：steps per minute。
• 证据定位：Section 5.3，Table 2。
• 结果：

Workflow	Serving system	Throughput	Speedup
mini-SWEAgent	vLLM + Gateway	375.4	1.00x
mini-SWEAgent	ThunderAgent	671.8	1.79x
OpenHands	vLLM + Gateway	69.1	1.00x
OpenHands	ThunderAgent	270.8	3.92x

• 对照是否可比：两组使用相同 GLM-4.6、workflow、$N=144$ 和两台 $8\times$H100；差异落在 ThunderAgent 与 vLLM + SGLang Gateway 的 serving stack。论文未报告重复运行方差或 baseline tuning 细节。
• 支持的最窄结论：ThunderAgent 在这两个固定模型的 rollout-serving workload 上将采样侧 steps/min 提升到 $1.79\times$ 和 $3.92\times$。
• 解读：该表直接支持固定模型采样侧的 sustained steps/min 提升。论文未在此实验中测量完整 RL 训练 wall-clock、最终 policy quality 或 policy lag，因而不能把 rollout 吞吐倍率等同为端到端训练加速倍率。

结果 3：组件消融 #

• 设置：GLM-4.5-fp8 + mini-SWEAgent，H100 节点，高并发 program。
• Baseline：vanilla vLLM。
• 指标：steps per minute。
• 证据定位：Appendix G.4，Table 7。
• 结果：

组件	Throughput
vLLM baseline	375
+ local program-aware scheduling	602
+ global waiting queue (ThunderAgent)	672

• 对照是否可比：三行保持 GLM-4.5-fp8、mini-SWEAgent、两台 H100 节点和 144 并发 program，只增量启用 local scheduling package 与 global queue，属于同实现内的递增消融。
• 支持的最窄结论：在该配置中，local scheduling package 将 375 提升到 602 steps/min，global queue 再提升到 672；该表能够分离 package 级增量，无法分离 decay、phase priority 与 shortest-first 的各自贡献。
• 解读：在这一组 GLM-4.5-fp8 + mini-SWEAgent 配置中，local scheduling package 贡献了大部分增量，global waiting queue 提供剩余增量。该消融把 phase priority、shortest-first 与 decay 合并在 local package 内，无法单独归因其中任一机制。

实验设置与 baseline 审计 #

维度	记录
模型与初始化	GLM-4.6 355B、Qwen3 235B、Qwen3-8B；部分实验使用 GLM-4.5-fp8 / MiniMax M2.5。
数据与任务	SWE-Bench Lite、ToolOrchestra on HLE、OpenHands on ScienceAgentBench、R2E-Gym。
RL / 训练配置	主要评估固定模型的 rollout serving；Table 2 未包含 policy update、训练收敛或最终任务质量。
系统配置	ThunderAgent 作为 middleware 接在 agent client 与 vLLM / SGLang backend 之间；工具环境可由 Docker / Kubernetes 等提供。
框架基座 / paper base	推理 backend 使用 vLLM；分布式 rollout baseline 使用 SGLang Gateway；agent loop 使用 OpenHands、mini-SWEAgent 与 ToolOrchestra；工具环境在独立 CPU cluster 上运行。
框架版本与证据来源	论文未固定 vLLM、SGLang Gateway、Docker 或 Kubernetes 版本；本次代码审计固定 ThunderAgent 7ddc861，并将 Dynamo PR #9448 与 SkyRL PR #1645 作为下游集成证据。
框架改动范围	核心改动位于 OpenAI-compatible middleware、program/backend state、capacity accounting、pause/restore scheduler 和 profiling；通用 tool teardown/prewarm manager 未出现在固定的核心包快照中。
技术报告训练配置	不适用，本文是 systems paper。
训练硬件与拓扑	主要报告 H100 集群；附录含 A100 portability；rollout 表使用两台 $8\times$H100 节点。
并行方式与框架	vLLM backend；附录讨论 SGLang HiCache、SGLang Model Gateway、NVIDIA Dynamo、SkyRL。
训练数据规模与组成	不适用。
训练过程与超参	调度参数包括检测周期 $\Delta t=5$、时间衰减 $f(t)=2^{-t}$。
训练时间 / GPU hours / 成本	未给出完整 cost accounting。
未披露项	各 baseline 的完整调参网格、容器编排配置、随机种子、置信区间和失败重试策略。
评测协议	steps per minute；每个 step 包含 LLM reasoning 与 tool acting。
统计报告	多图表报告吞吐和 latency breakdown，但缺少标准误差 / CI。
Baseline 是否 tuned	论文覆盖 vLLM、Continuum、vLLM + SGLang Gateway；调参细节有限。
Baseline 是否 compute-matched	大体在相同模型和硬件下比较；工具环境和 CPU cluster 配置细节仍影响复现。
Baseline 是否 implementation-matched	ThunderAgent 与 baseline 都运行实际 agent workload；Continuum / Gateway 的具体实现版本和参数需要复验。
Baseline 是否覆盖强替代方案	覆盖主流 request serving、multi-turn agent serving 和 gateway routing；KV offload 与 PD disaggregation 放在附录讨论。
Baseline 是否存在弱化风险	session pinning、TTL 和 tool-duration prediction 对 workload 分布敏感；不同调参可能改变差距。
结论边界	直接证据覆盖论文列出的多轮 tool-use agent、模型、硬件与高并发 serving / rollout 配置；短单轮 chat、低并发、不同网络和不同 sandbox 栈需要独立评估。

证据链强度评估 #

强证据 #

• 论文直接测了实际 agent workflow，证据强于只使用 synthetic prompt length distribution。
• serving 与 RL rollout 两类场景都给出端到端 steps/min 结果。
• 消融把 local program-aware scheduling 与 global waiting queue 两个 package 的增量拆开；在 mini-SWEAgent 配置中，前者从 375 提升到 602 steps/min，后者继续提升到 672。
• 开源仓库、SkyRL 与 NVIDIA Dynamo 集成提供了实现和移植参考；Dynamo PR 进一步给出 KV-routing-only 对照和 reference-code drift 记录，完整复现仍需要固定 backend、orchestrator 与 workload 配置。

中等强度证据 #

• 时间衰减的指数 / 几何形式来自 time-homogeneous semigroup 与边界条件；该推导没有给出最优衰减率，也没有证明 elapsed time 能预测剩余工具时长。
• $c^2$ 重算 STP 依赖固定 chunk size 与线性时间近似；shortest-first 在两个 workload 的消融中优于 random / longest-first，但 Appendix F.3 的离散全局最优证明缺少可分割或精确替换条件。
• tool resource manager 整体带来约 10% latency 改善和 $4.2\times$ disk memory savings；GC 与异步 preparation 未分别消融，固定的公开核心包也没有通用 tool manager，因此结果依赖论文实验中的具体 orchestrator、初始化和清理策略。

需要谨慎的推论 #

• ThunderAgent 提升 throughput；单个用户请求的即时响应体验仍需用 tail latency / fairness 指标单独评估。
• 低 KV hit rate 在某些随机工具 workload 下仍可能对应更高吞吐，因为它减少了 stale acting program 占用 HBM；因此 cache hit rate 需要和 completed steps、recompute tokens、HBM occupancy 一起判断。
• 若某个 online agent service 的工具调用非常短、上下文很小、并发较低，program-aware scheduling 的收益会下降。

OpenReview / 审稿意见吸收 #

• Page type: official-review
• Match confidence: high
• Observed at: 2026-07-13
• Venue status: ICML 2026 Spotlight；OpenReview 作者 profile、作者主页和项目 README 相互印证，arXiv 当前版本为 v3。
• Public reviews: OpenReview forum 与 ICML metadata 可确认；forum/API 在观察时触发 challenge，完整评审正文未进入证据集。
• Ratings / confidence: 未可靠获取。
• Reviewer consensus: 未评估；当前可访问材料不足以重建 reviewer consensus。
• Main criticisms: 未可靠获取。
• Author response: 未可靠获取。
• 对可信度的影响: ICML Spotlight、开源实现和两个下游移植提高系统贡献与可迁移性的可信度；baseline 调参、统计稳健性、tool manager 复现和失败案例仍需独立复验。

本地讨论补充 #

1. 讨论收敛点 #

• 对 online agentic server，若请求会经历多轮 tool use、prefill 和 decode，Memory / Compute 设备亲和有价值，但亲和对象应从单个 request 提升到 program / trajectory。
• 严格把请求发回原始 instance 可以保 KV，但在 session 长度、工具等待时间和活跃模式高度异质时，会降低调度自由度，使部分节点积累更多 KV footprint 或突发恢复请求。若 workload 足够均匀、session 数很大且分配依据包含真实 KV footprint，这种 imbalance 会减弱。
• ThunderAgent 的时间衰减属于无预测器的保留优先级老化策略，应避免把它解读为历史成本追责或严格的剩余工具时间预测器。更精确的策略应比较继续保留 KV 的未来 recompute saving 与继续占用 HBM 的未来机会成本。
• 轻量级预测器可以作为补充特征。Appendix G.2 的三组 workload 中，exponential decay 在 mini-SWEAgent 与 ScienceAgent 上较好，linear decay 在近确定性的 OSWorld 上较好；生产默认值仍需按 tool latency 分布验证。

2. Elapsed time 是否能支持 KV 保留决策 #

已经发生的缓存占用属于 sunk cost，不应进入当前时刻的 keep / evict 比较。设工具总时长为 $T$，当前已等待 $t$，剩余时长为 $R_t=T-t\mid T>t$，KV footprint 为 $c$。从当前时刻开始，继续保留的近似成本是：

$$J_{\mathrm{keep}}(t) = \mathbb E\!\left[ \int_0^{R_t}\lambda_{\mathrm{HBM}}(t+u)c\,du \middle|X,T>t \right],$$

其中 $\lambda_{\mathrm{HBM}}$ 是当前负载下 HBM 的 shadow price，$X$ 包含工具类型、输入规模、队列状态和进度信号。驱逐的近似成本是：

$$J_{\mathrm{evict}}(t) = p_{\mathrm{return}}(t,X) \left(C_{\mathrm{recompute}}(c)+C_{\mathrm{restore}}\right).$$

合理策略在 $J_{\mathrm{keep}}(t)<J_{\mathrm{evict}}(t)$ 时保留 KV。式中没有已经发生的 $ct$；elapsed time 只通过剩余时长条件分布、返回概率或当前系统压力产生作用。

这给出三种不同情形：

1. Memoryless / exponential latency：$R_t$ 的分布与 $t$ 无关，因此 $\mathbb E[R_t\mid T>t]$ 不随已等待时间变化。单靠 $t$ 不能预测未来还要等待多久；若 HBM shadow price 也不变，最优二元决策不会只因时间流逝而翻转。
2. Decreasing-hazard / heavy-tail latency：等待越久，样本越可能来自 slow mode，条件剩余时长可能上升。此时降低 aged KV 的保留优先级具有统计依据，混合快慢工具的服务常出现这种现象。
3. Increasing-hazard 或近确定性 latency：等待越久通常意味着越接近完成，条件剩余时长下降。固定衰减可能提前驱逐即将复用的 KV；论文在 OSWorld 上观察到 linear decay 优于 exponential，与这一边界一致。

ThunderAgent 的 $c_qf(t_q)$ 表达 effective reservation weight。它没有改变真实 footprint $c_q$，也没有直接估计 $R_t$；权重下降会允许更多 reasoning program 进入，随后在真实内存压力上升时促使 acting KV 被回收。Appendix F.1 从 time-homogeneous 相对衰减、$f(0)=1$ 和 $f(\infty)=0$ 推导指数 / 几何形式。该定理说明满足这些假设的函数形状，衰减率和 keep / evict 的最优阈值仍需 workload 与系统压力决定。

因此，论文机制可以作为高并发、未知或重尾工具时长下的 reservation-aging 候选 heuristic。若生产系统能观测工具类别、RPC queue、下载进度、编译阶段或 deadline，更直接的 score 是：

$$S_{\mathrm{keep}} = p_{\mathrm{return}} \left(C_{\mathrm{recompute}}(c)+C_{\mathrm{restore}}\right) -\lambda_{\mathrm{HBM}}c\,\mathbb E[R_t\mid X,T>t],$$

当 $S_{\mathrm{keep}}>0$ 时保留，并在预测不可用时退化为 elapsed-time decay。该设计把未来重算收益、未来 HBM 机会成本和预测不确定性放在同一决策量中。

3. 修正后的理解 #

• agentic inference 的关键状态包括 prompt tokens、tool phase、tool environment、backend placement 和 program termination。
• KV cache 复用和设备亲和需要和 HBM occupancy 一起优化；缓存命中率是中间指标，完成 workflow step 的吞吐是主指标。
• RL rollout 场景下，program-aware serving 可能通过采样速度影响 policy lag；ThunderAgent 实验没有测量这一训练闭环效应。

4. 后续复验指标 #

• per-program token count、phase、tool duration、pause / restore 次数、re-prefill token 数。
• 每个 backend 的 KV occupancy、active reasoning program 数、acting program cached footprint。
• steps/min、program completion time、P50/P90/P99 per-step latency、tool environment init / teardown time。
• paused program 是否迁移、迁移后的 re-prefill cost、全局队列等待时间。
• 按 tool type 估计 survival curve、hazard 和 mean residual life，比较 elapsed-only decay 与 feature-conditioned remaining-time predictor。
• 记录每次 keep / evict 时的 $J_{\mathrm{keep}}$、$J_{\mathrm{evict}}$ 代理值，并对照后验真实 tool return time、recompute tokens 与被挤出的 reasoning work。
• rollout/trainer logprob consistency 与 batch nondeterminism 指标，特别是在 RL 训练闭环中。

主要启发 #

• 实现这类 program-aware 调度时，agent server API 需要暴露 program_id / trajectory_id、phase 或 tool-use state，以及 termination signal。
• 对多轮 tool-use agent，调度器应把 “保 KV” 当作带成本的动态决策。
• 在多节点部署里，workflow-level global queue 能在 KV 已释放后恢复 placement 自由度；收益条件包括节点负载异质、其他节点存在空闲容量且 re-prefill 成本可接受。
• tool resource manager 和 GPU KV scheduler 共享 lifecycle 后，GPU 释放与 Docker / port / disk 回收才能使用同一 program termination signal；具体回收仍由 orchestrator 执行。

局限 #

1. 论文主要以 throughput 为中心，用户交互型场景中的 tail latency / fairness 需要额外策略。
2. 时间衰减函数依赖不可预测工具时长假设；对于高度可预测的工具，如固定截图周期，线性或更任务特定的 decay 可能更合适。
3. shortest-first 的 $c^2$ 近似有局部直觉和两组 workload 消融支持；Appendix F.3 的离散全局最优证明未处理 whole-program eviction 的 overshoot 反例。
4. 全局队列通过允许 paused program 跨节点恢复降低 imbalance，但会带来 re-prefill 和 placement 决策复杂度；低并发或极长上下文场景需要重新评估。
5. 工具环境管理收益依赖具体 orchestrator、镜像大小、文件系统和 sandbox 生命周期；不同生产环境需要单独压测。
6. 论文没有完整给出统计置信区间和 baseline 调参细节，复现时应固定版本、容器配置和 workload seed。

跨论文关系 #

• 作者关系：Beidi Chen 连接 CMU Infini AI Lab；Hao Kang 与 Tushar Krishna 建立 Georgia Tech systems 线。
• 与 2607.03333 SPORK：ThunderAgent 在 program/session 粒度调度 KV、tool lifecycle 与 placement；SPORK 在单个 turn 内从共享 prefix KV 发起 self-probe，让工具执行覆盖剩余 decode。组合部署时，program-aware scheduler 还需识别 probe priority、shared-prefix affinity、工具取消和 foreground decode contention。
• 与 Grape：ThunderAgent 处理 program lifecycle、工具等待、KV pause / restore 和多节点 placement；Grape 处理 LLM-only workflow 内部的跨 task 增量 prefill、微任务 batch 和关键路径 KV 抢占。一种可组合设计是由 program-level scheduler 管外部工具阶段，再由 Grape 式 engine 调度已就绪的 LLM 微任务；现有论文尚未验证这一组合。
• 与已有论文的主题关系：2405.19888 Parrot 和 2511.02749 Span Query 都把上层结构暴露给 serving runtime；ThunderAgent 暴露的是 program lifecycle、tool phase 和 KV state。
• 与已有论文的方法或系统关系：2511.14617 Seer、2512.22560 RollArt、slime 官方项目 和 2409.19256 HybridFlow 都处理 rollout infrastructure；ThunderAgent 聚焦 agent serving / rollout engine 的 KV 与工具生命周期。
• 与 kernel / attention 侧系统关系：2308.16369 Sarathi 优化 prefill-decode 执行层，ThunderAgent 优化 workflow scheduling 层，两者可以组合。
• 与一致性和复现实验关系：2605.14220 TIM/VeXact 与 2025-09-10 TML inference determinism 提醒 rollout backend 的 batch、KV 和重算路径会影响训练闭环；ThunderAgent 若用于 RL，应记录 pause/restore/recompute 对 logprob 和 sampler 的影响。
• 跨论文关系定位：记录 ThunderAgent / Program-Aware Agentic Inference，并扩展 RLHF systems、LLM application serving、self-improving agents 与 serving/kernel 关系。

Reference Intake Brief #

Target #

• Intended target system: 新增论文笔记与 papers-index.md。
• Existing related assets: content/utility/papers-index.md；2405.19888 Parrot、2511.02749 Span Query、2511.14617 Seer、2512.22560 RollArt。
• Proposed form: 新建独立 Markdown 文档，并更新索引和作者数据。

Reusable Elements #

1. LLM Program 抽象：$\langle \mathit{ID},c,\mathcal{T},\mathcal{L},\tau,s\rangle$ 可复用于 agentic server 设计文档。
2. STP cost decomposition 可复用于组织 KV cache / device affinity / rollout scheduler 的 accounting；作为评估指标前需补齐互斥归因、workload 归一化和分项测量。
3. pause / restore / global waiting queue 可复用于多节点 agentic serving 的设计讨论。

Risks #

• Copyright/over-copying: 本笔记使用概括与少量公式重述，未复制大段论文文本。
• Unsourced or unverifiable claims: OpenReview 评审正文未吸收；作者历史机构只使用可公开核验来源或本地既有档案；Dynamo PR 的 12% 至 16% 属于该 PR 报告的单组移植结果。
• Tone/brand mismatch: 采用本地论文存档语气，避免营销化表述。
• Safety/compliance issues: 该论文是系统效率工作，无直接滥用操作细节。
• Overlap with existing assets: 与 Parrot / Span Query / Seer / RollArt 交叉，但层级不同；对应论文的关系章节负责区分。

Skipped #

Material	Reason
OpenReview 完整 reviewer comments	当前环境访问 OpenReview forum/API 触发 challenge，无法可靠读取。
旧版 v1 的作者脚注差异	本笔记以 2026-06-30 的 arXiv v3 为准。

Recommendation #

Decision: merge

Why: 本轮以 arXiv v3、固定代码 commit、ICML metadata 和下游集成重新核验，保留 program-aware scheduling 的核心贡献，同时收紧 time decay、shortest-first 最优性、rollout 加速和 tool resource manager 的证据边界。