Ready Cohorts: Bounding GPU Opportunity and Avoiding Host Round Trips in LLM-Agent Control
Josef Liyanjun Chen
cs.DC, cs.AI, cs.OS
2026-08-12
实测 851 段真实客服会话,智能体控制步可凑批上 GPU 的机会仅 43%、并发不足一万即归零;把路由决策留在卡上比回主机往返快 1.2 至 2.4 倍,但得同时取消一次主机决策才生效。
LLM 智能体在每次模型调用和工具调用之间,都要做一段小而确定的「控制步」:解析上一步的结果、推进状态机、检查预算与策略、选定下一步路由、发出下一条动作。单步开销远小于一次推理,但当服务同时跑成千上万个会话时,这些步子会持续在 CPU 和 GPU 之间来回横跳。已有生产实测发现,这种主机侧编排落在了关键路径上,还制造了突发式的 CPU 压力。
一个自然的问题随之而来:既然推理已经在 GPU 上,这些确定性的控制步能不能也凑成一批、直接在 GPU 上跑?这篇论文没有给出「能」或「不能」的口号式答案,而是把这个模糊的直觉拆成两道可以分别测量、可以证伪的闸。一是「凑得够不够」,同一类工作能否在截止时间前攒过 GPU 的成批门槛;二是「看得见看不见」,控制链上有多少决策不必把中间结果送回主机。
论文把研究单位明确限定为「确定性的控制迁移」,比一次 LLM 请求、一次工具调用或一整条工作流都要小。它读入带类型的状态和一个已就绪的事件,产出新状态、一条路由,可能还附带一个动作描述符。模型推理、工具执行、对外部效果的最终提交都划在范围之外:GPU 可以算出「该调某个工具」,但论文不让它持有云凭证、创建虚拟机或提交副作用。
第一项研究定义了四个绝不能互相替代的量:
四者满足 F ≤ P ≤ U、A ≤ P。数据来自 Exgentic tau2 数据集的 851 段真实客服会话(航空、零售、电信),共 9031 个 LLM span,每个 span 完成就视作一个候选控制事件,路由键由记录的结果(正常文本、报错、具名工具、多工具)派生,共 70 个路由标签。然后用稳态泊松到达回放到目标并发量 C。主格定在 C=10 万、K=256、截止时间 50 毫秒,且在算 P 之前就冻结。
第二项研究是机制实验,孤立地看第二道闸:一个本来就驻留在 GPU 上的决策,该不该送回主机?三套机制跑在同一份冻结的 CUDA 程序上(每个 agent 16 字节合成状态、两个路由体、每个 epoch 一个全局二值决策)。主机往返:算完谓词,把 4 字节结果拷回主机、同步,再从主机发射选中的路由图。驻留卡上:只发射一个根图,一个单线程选择器在卡上读谓词、尾随发射对应的路径图,连续跑 H 个 epoch 全程不把决策暴露给主机。还有一个只重放神谕序列、省掉谓词与选择的地板,它不是可部署的策略,只是结构基准。
主格的跟踪结果是 F=30.19%、P=43.00%、U=45.85%。精确打包把固定窗口丢掉的机会收回了 81.83%,也就是 P 距离上界 U 还剩 2.85 个百分点。更要紧的是看边界怎么塌:在 K=256、并发量 C 不超过 1 万时,P 在所有截止时间下都是 0;即便 C=10 万,在 10 毫秒和 25 毫秒截止下仍是 0。名义上会话再多,也不等于某条路由能在短预算内攒出够大的一批。
把门槛 K 调低,比放开跨窗口成批更管用。C=1 万、50 毫秒时,K=32 的 P=22.2%,K=64 直接掉到 0;C=10 万时,K 从 32 到 256 对应 66.8%、66.0%、48.4%、43.0%。
机制实验里,驻留卡上在全部 36 个配置里都比主机往返快,比值 1.19 倍到 2.39 倍。主格(N=256、H=32)四块卡的具体数字:
| 部署 | GPU | 驻留卡上 / 主机往返 |
| 本地 | GTX 1660 Ti | 1.71 倍 |
| Modal | L4 | 2.39 倍 |
| RunPod | L4 | 2.06 倍 |
| Lambda | H100 SXM5 | 1.84 倍 |
绝对差是每个 32-epoch 批次省 194 到 363 微秒。但驻留路径仍比神谕地板慢 6.60 到 8.17 倍,这部分未拆解的差距来自谓词、选择器和图开销。全部 1455 万次受测调用,在与独立主机神谕的字段级和逐 epoch 决策比对中完全一致。
最关键的对照是一个负控制:把图的发射从主机挪到一个 GPU 核里,却不取消任何主机决策。这种只换发射点、不取消主机往返的做法,在 5 块卡、60 个配置里全部更慢(1.07 到 1.99 倍)。换句话说,单纯把发射搬进设备图毫无收益,提速只来自真正取消一次匹配的主机决策 epoch。
这篇把「智能体控制能不能上 GPU」从一个口号,变成了两个可以分别测量、可以证伪的量,并老老实实标出了每一步的推理边界。对做 agent 服务的工程师,最直接的实用结论来自那个负控制:别指望靠「在核里发起一次 launch」省事,只有当你同时去掉一次本来要回主机的决策往返时,驻留决策才划算。
但也要泼冷水。论文明确说两套研究的数字不能相乘:跟踪里的 K=256 只是一个扫到的候选门槛,不是驻留机制测出的真实交叉点,跟踪模型里也没有 H=32 这个 horizon。它给出的是「在理想化假设下,离线最优能拿到多少机会」的机会面,以及一个机制方向(把决策留在卡上),而不是任何服务级加速数字。真正的部署价值,也就是 A,要等一个还不存在的有限在线运行时才能测。
作者对局限写得异常坦诚,列几条要紧的。离线最优假设了未来全知、零服务时间、无限容量、无批次上限、截止只卡发射不卡完成,这些在真实系统里都不会成立。跟踪数据只有一个 851 段会话的面板、三个客服领域,且强制稳态泊松到达;三个随机种子衡量的是「给定面板和模型」下的蒙特卡洛波动,不是真实负载人群的置信区间,突发或相关到达都会搬动边界。
更关键的是,路由键只是一个条件代理,不是已验证的语义融合。它省掉了状态机节点、schema、参数、策略上下文和多工具身份,打包数组也没保留每段会话内的顺序约束。所以「43% 能成批」是一个上界式的机会估计,真要执行还得逐路验证可融合性。机制侧只测了一个全局二值决策、一个规则的合成状态数组,真实路由体还需要每事件压缩、可变体、进出处理、动作排序、恢复和 CPU 兜底;计时还把建图、状态重置、结果拷贝、校验都排除了。四块命名部署把 GPU、供应商、宿主、镜像、驱动、区域全混在一起,只能支撑「命名部署」级的效应方向和大小,不能外推到硬件人群。指标也只是批次平均的 cohort-horizon 墙钟时间,不是调用的 P99 或端到端任务时长,也没有调优过的 CPU 基线、CPU 核秒、能耗、成本、模型吞吐、TTFT/TPOT 和任务效用。