Tunix 把 Agent 训练也变成高吞吐反馈循环章节1×0:08今天的事件1:02为什么同步循环会浪费硬件1:50Tunix 的第一处改动:异步收集轨迹2:41第二处改动:rollout 和训练解耦3:36Agent 和环境也要分开4:42观测不能只看 TPU 利用率5:32对团队落地的三个建议6:34一句话判断0:007:130:08主持谷歌开发者博客在 7 月 21 日发布了一篇文章,主题是用 Tunix 扩展智能体强化学习,也就是 Agentic RL 的训练吞吐。Tunix 是谷歌基于 JAX 的大语言模型后训练库,最新这部分工作的重点,不在于再加一个更复杂的奖励函数,而在于解决一个很具体、也很容易被低估的问题:Agent 一旦开始多轮调用工具,训练硬件会长时间等着环境返回结果。 在传统的语言模型训练里,模型连续生成一段文本,计算过程比较规整。Agent 的训练却会变成这样:模型先做一次决策,接着执行代码、查询数据库、访问网页,等环境返回观察结果,再继续生成下一步。只要外部工具慢一点,TPU 就可能停在那里。谷歌把这件事归结为 rollout,也就是轨迹生成阶段的基础设施瓶颈。1:02主持先把一个常见的同步方案想清楚。系统同时启动一批 Agent,等这一批轨迹全部跑完,再把结果交给训练器。问题是,每条轨迹的长度和环境延迟都不一样。有的 Agent 很快结束,有的要多调几次工具,整批数据只能等最慢的那条。谷歌把这里的空档叫作 execution bubbles,把长尾拖慢整批任务的现象叫作 straggler effect。 这和普通的批处理有点像:你安排了十个人一起出发,九个人已经回来了,但仓库要等第十个人回来才开始下一轮。对 Agent 来说,这个等待还会直接转化成昂贵加速器的空转。训练循环看上去在持续运行,真正消耗预算的却可能是模型没在算,而是在等环境。1:50主持Tunix 的第一处改动,是引入异步轨迹采集引擎。它用基于 asyncio 的 Rollout Orchestrator 管理大量并发的 Agent 和环境交互。当某一条轨迹暂停,等待主机侧工具执行时,推理引擎可以马上去给其他活跃轨迹生成 token。文章还提到,它接入了面向 TPU 的 vLLM 和 SGLang JAX,用异步请求处理来避免采样过程被单条轨迹卡住。 这里的工程重点不是「让 Agent 更聪明」,而是把几类等待重叠起来:模型推理在跑,工具调用在跑,奖励计算也在推进。原来是一条轨迹走完再轮到下一条,现在变成许多轨迹交错前进。对多轮 Agent 来说,这个变化很实在,因为环境延迟从一个全局阻塞点,变成了可以被并发隐藏的局部延迟。2:41主持仅仅把 rollout 做成异步还不够。训练器本身也不能继续等一整批轨迹齐活。Tunix 把两边拆成一个持续运行的生产者和消费者流水线。 生产者是异步 rollout 编排器,谁先完成一条轨迹,就先把它放进高吞吐队列。消费者是 Agentic RL Learner,持续从队列里取数据。像 GRPO 这种需要多条推理路径来计算组内优势的算法,Tunix 会在运行过程中动态地把已经完成的轨迹组成合适的组。一个轨迹组凑齐,就可以后处理、打分,然后直接送进训练器,不必等所有并行任务同时到达。 这一步对 Loop Engineering 的启发很直接:循环的吞吐不应该由最慢的一条路径定义。你需要把「生成轨迹」「等待环境」「计算奖励」「更新策略」看成四个可以流水化的阶段,再决定队列放在哪里、批次什么时候形成、哪些延迟能够被隐藏。3:36主持Tunix 还把 Agent 层和 Environment 层拆开。Agent 层负责提示词格式化、动作生成和对话历史,环境层负责多轮 episode 的生命周期、观察结果路由和奖励处理。仓库里提供了 Task Environment 和 Tool Environment,也允许团队通过 Base Task Environment 接入自己的外部系统。 这个边界的价值在于,换环境时不用重写训练主流程。今天接一个数学验证器,明天换成 Bash 终端,训练代码仍然可以沿用,变化集中在交互逻辑和奖励定义上。对工程团队来说,接口稳定比示例数量更重要。至少要明确三件事:初始观察怎么产生,一次动作如何推进环境,轨迹结束时资源怎么清理。 另外,Tunix 保留了多轮边界上的特殊 token,试图保证 Token In、Token Out,也就是模型看到的输入和吐出的输出在格式上严格对应。这个细节不漂亮,却很关键。Agent 训练最怕的就是环境接入以后,消息边界、工具结果和奖励对不上,最后你以为在优化策略,其实是在优化一套被拼坏的数据。4:42主持谷歌给 Tunix 加的另一层能力,是持续运行的轻量观测。传统的 XProf 可以看到很深的算子级 trace,但开销较高,更适合短时间、间歇式捕获。Tunix 试图把领域相关的强化学习指标和 TPU 时间线放在一起看,再用 Perfetto trace 观察多轮 Agent 训练的分阶段执行。 这个方向值得注意,因为 Agent 的瓶颈通常不在一个算子里。你可能看到 TPU 利用率下降,却不知道是网页搜索慢、工具进程排队、奖励函数计算慢,还是轨迹分组策略让训练器吃不饱。更有用的观测至少应该回答:每条轨迹在环境里等了多久,工具调用占了多少时间,奖励计算是否形成长尾,队列有没有积压,训练器有没有断粮。5:32主持如果你正在搭建 Agentic RL,第一步不要急着追求更大的并发数。先把一次多轮训练画成时间线,明确模型推理、工具执行、观察返回、奖励计算和参数更新各自占了多少时间。没有这张图,所谓吞吐优化很容易变成调参猜谜。 第二,把 rollout 和 learner 的接口先固定下来。轨迹应该是可以独立排队、打分和重放的对象,训练器不应该知道每个环境内部怎么工作。这样你才有机会替换环境、增加并发,或者在失败后只重跑受影响的轨迹。 第三,把评估口径说清楚。谷歌这篇文章给出的是架构和机制说明,原文没有公布具体的吞吐提升百分比,也没有给出一组可直接复现的基准数字。官方仓库把 Tunix 标成 V2 Release,同时注明项目仍在积极开发。所以现在更适合把它当作一套值得研究的训练基础设施设计,而不是已经证明在所有任务上更快的结论。6:34主持Tunix 带来的变化,可以浓缩成一句话:Agent 的反馈循环开始像一个分布式系统来设计,等待、队列、长尾、环境接口和观测,都和模型本身一样重要。 今天你可以带走一个检查问题:你的 Agent 训练变慢时,究竟是模型算得慢,还是整个循环在等最慢的工具和最晚到达的轨迹?先把这个问题测出来,再谈换模型、加显卡,或者改奖励函数。