← 返回 PaperDaily
大模型与智能体
NVIDIA新作Agentic RL框架Molt:代码量锐减至9K,吞吐量持平Megatron
NVIDIA开源了Molt,一个专为智能体强化学习(Agentic RL)设计的PyTorch原生训练框架。代码量仅约8600行,却能在吞吐量上与业界顶级的Megatron堆栈掰手腕。对于天天改算法的研究者来说,这简直是福音,终于不用在层层抽象和复杂配置里找东西南北了。
龙哥读论文
发布于 2026-08-14 09:11:28
阅读 5
查看原文
原论文信息如下:
背景:研究者为什么需要新的 agentic RL 框架?
搞过智能体强化学习(Agentic RL )研究的同学都有种共同的痛:改个算法真难。想试试新的优势估计器(如GAE )、给经验管道加个过滤、或换个 rollout 方案,按理说就是一个下午的活,但在主流框架里,得翻过好几十层的 trainer、分布式后端和 rollout 引擎的胶水代码。每迭代一次,研究者就得付出一次这种隐形成本。
那些复杂的层并非凭空出现。随着智能体强化学习从单步偏好调优发展到多轮工具使用、代码执行、视觉语言环境,主流框架的架构开始向超大规模训练优化,形成了多后端结构、独立的训练引擎、分布式训练器、控制器、注册表和配置层。
这种超大规模工程对超大规模训练很合理,但对研究来说不是好默认选项——研究者继承了一套超大规模工程的复杂度,却并不需要那套专门用途,结果就是理解和修改框架的成本远超表达正在探索的假设所需的花费。
研究基础设施需要不同的目标:要尽可能缩短从想法出现到产生可信赖实验结果之间的距离,同时又得保持大策略所需要的性能。源代码在这种情况下变成了用户界面的一部分。一个研究者应该能沿着一个样本从智能体调用追踪到策略损失;AI 编码助手(如 Claude Code)也应能在这条路径上自由导航。正是基于这些痛点,NVIDIA 打造了 Molt 。
核心设计:五个原则如何塑造 Molt 的可读性与正确性
Molt 的设计基于一套明确的原则。NVIDIA 团队提出了五个核心设计原则,共同塑造了框架的独特面貌。
研究者读一个函数,应一次就能理解它的控制和数据流;AI 编码助手应能从一个命令行参数追踪到它执行的代码分支、参与计算的张量、监控指标和测试。这直接禁止了多余的间接跳转——任何需要读两遍才能懂的代码即使执行正确也被视为缺陷。
冗余代码被视为缺陷,删除比增加更受欢迎。最有决定意义的是,Molt 只支持一个训练后端 NVIDIA AutoModel 和一个推理引擎 vLLM ,并且不 fork 它们,所以上游的每一次改进在发布当天就能直接使用。多后端抽象正是层级间接跳转的源头,拒绝它就是移除整个层级。
轻量化只有不牺牲吞吐量才有意义。在匹配的协议下,与基于 Megatron 的最先进堆栈性能持平是硬性的设计要求。
框架的组件跟强化学习算法自己定义的对象一一对应:智能体与环境接口、rollout、优势估计、损失函数,而不是映射到基础设施层级上。这就禁止了适配器层和插件注册表,也解释了为什么一个算法改动只需要碰到一个组件。
在生成和训练之间的数值一致性是第一等保证。代码必须训练在生成的确切 token 上,保持引擎和训练器之间 log-probabilities 的一致性,并持续监控残留的训练-推理不匹配。任何无声的偏差,包括混合专家模型(MoE )路由中的偏差,都被视为 bug。
系统解析:一个异步循环如何组合 Ray、vLLM 和 NeMo
Molt 的整个运行时就是三个组件加一个循环。如架构图所示,Ray 提供任务调度和连接智能体池、一组 vLLM rollout 引擎、和单个基于 NVIDIA AutoModel 训练的策略 actor 的异步队列。没有混合控制器、没有每后端的适配层、没有单独的参数服务器。
智能体(Agent) :纯 Python,产生动作和奖励。Molt 提供了两种形式:Env 形式和 ChatAgent 形式 。Env 形式更像是传统的 Gym 交互范式,框架接管 LLM 循环和 token 化,用户提供 step() 函数。ChatAgent 形式则更加灵活——如果用户用了 OpenAI 或 Anthropic 的标准 SDK 调用,直接在代码里换个 base_url 就能无缝接入 Molt。奖励可以是任意 Python 函数。
生成器(Generator) :针对 vLLM 引擎的 token 精确捕获。Molt 不走文本中转,提示词以 token ID 形式输入,完成以 token ID 和逐 token 的 log-probabilities 返回,整个过程中文本层绝不经过 tokenizer。
训练器(Trainer) :一个可见的训练循环,作用于单个 FSDP2 策略 actor。训练器使用 FSDP2 以及原生张量并行(TP )、专家并行(EP )和上下文并行(CP )进行训练。启动脚本对于稠密 4B 模型和 DeepSeek-V3 类 1T MoE 模型都是同样的,只是把 --fsdp.ep_size 从 1 改成 256。
估计器与损失函数(Estimators and Losses) :作为奖励、分组和 token trace 的纯函数。无论是 REINFORCE++ 、GRPO 还是 GAE with PPO critic,都只需一个命令行参数 --algo.advantage.estimator 来切换。想加一个新估计器?写一个纯函数,加个 flag,加个单元测试,完事。
再看更具体的架构细节:Ray 的异步队列实现了一个流式池,始终保持 prompt 组在运行中,一旦有足够的组完成就立即发一个训练批次出去。弹性的队列深度让训练吞吐量能和生成延迟解耦——代理任务中生成延迟往往是重尾分布。
当权重更新发生时,Molt 的 部分 rollout(Partial Rollout) 方案不会强制丢弃正在处理的请求。它暂停引擎、广播 actor 分片、然后恢复保留的请求。每个动作 token 都保留了采样时的 log-probability,并用离线策略校正来处理混合版本问题。框架明确不允许在未开启校正的情况下运行部分 rollout。
Token 精确性保证:为什么“生成即训练”是正确性的关键
智能体在线强化学习有一个非常安静的错误模式:推理引擎和训练器表面上用的是同一个策略,但 tokenizer、采样变换、多模态渲染、权重版本或者 MoE 路由都可能产生差异,而系统不报错,后果仅仅是得到一个有偏的梯度——这对研究者来说很难排查。
Molt 通过三个核心不变性(invariants)来锁定正确性:
Token 身份一致性 :训练用的 token 必须是采样时的确切 token ID,而不是重新 tokenized 的文本转录。Molt 采用 Token-In/Token-Out(TITO)捕获,token 空间从未被离开过。
策略版本语义 :可训练的 token 保留其行为策略的 log-probabilities。对于异步使用场景,框架通过逐 token 的重要性采样校正和序列级门控来修正版本差异。
正向一致性 :rollout 和 actor 对多模态扩展、MoE 选择等模型语义必须达成一致。MoE 强化学习有一个特别诡异的错误模式:rollout 和训练路由独立地选择专家,数值上的微小差异可能导致两端评估了不同的稀疏计算图。Molt 用 rollout 路由重播(Rollout Routing Replay) 技术解决这个问题——引擎记录每个 token 选择的专家,训练器在训练时重播这些选择,确保计算图完全对齐。
这三个不变性让整个框架有一个可以简单陈述的最终效果:每个训练的 token 都与生成的 token 完全一致,实验的含义因此准确无误。
性能对比:Molt 如何与 Megatron 堆栈在吞吐量上持平
轻量化通常听起来像是要付出性能代价的,但 Molt 团队明确把性能持平作为设计约束。实验结果也验证了这一点。
头对头实验的配置非常严谨。双方都使用 Qwen3-30B-A3B 模型,bf16 精度,在 2 节点 x 8 H100 上异步运行,训练和 rollout 各分 8 张 GPU。数据集是用 DAPO-Math 的 2K 条提示词去重后使用,每步 32 个 prompt x 4 个采样 = 128 条序列,上下文 16K tokens,生成上限 8K tokens。双方都在各自的推荐布局下运行:Molt 用的是 FSDP2 数据并行,slime 使用的是 Megatron-Core 的 TP4+SP、EP8 布局。
结果令人印象深刻:Molt 为每步119.4±2.3秒,slime 为每步109.5±10.3秒。
表4:Molt 扩展旋钮。Actor 端并行度与 FSDP2 分片组合;vLLM 端按每引擎镜像。
可以看到 slime 的跨运行 spread 是 102–121 秒,完全覆盖了 Molt 的范围。Molt 的均值反而快约 9%,但这个差异在统计上并不显著,因此论文不宣称任何一方的优越性。论文作者特别指出,在更长的输出长度下这个差异会显著缩小——当轨迹走向 32K–128K 时,优化器步的时间主要被生成时间占据,训练后端的差异变得更加无关紧要。
另一个值得注意的点是:Molt 的引擎功能以命令行开关方式到达。比如,启用模型的 MTP 头(Multi-Token Prediction)只是一个配置开关,就把每一步的生成时间从 329 秒缩短到 64 秒,提升了大约 5 倍生成加速。优化器 CPU 卸载也是一个开关,将 actor 峰值 GPU 内存从 64.7 GB 降至 46.4 GB——这对于能否在 8 GPU 的训练分区上容纳该模型来说,可能就是生与死的区别。
总结与展望:轻量化框架的未来
Molt 的核心论点其实挺反直觉的:复杂性并非高性能强化学习基础设施的必然代价,而是从超大规模训练继承来的选择。Molt 赌的是,整个算法流程可以保持足够小,让研究者和 AI 编码助手都能完整阅读,而评估表明这个赌注在吞吐量上没花一分钱代价。
当前 Molt 已经在 GitHub 上开源,提供了 recipies 和容器,并且用 700B MoE 模型、专家并行 256 的全异步循环验证了极端规模。Molt 不支持的是那些在工程上可能合理但在研究上容易产生无声错误的操作,例如禁用离线策略校正就运行部分 rollout,这些都被配置时检查所阻断。
未来 Molt 可以在几个方向上持续演进:一是对更广泛的模型架构和并行模式的原生支持,二是完善多节点和多集群的弹性扩展,三是将这种轻量级设计理念进一步推广到除强化学习之外的训练流水线上。
龙迷三问
这篇论文解决什么问题? Molt 致力于降低智能体强化学习研究的迭代成本。主流框架针对超大规模训练场景进行了高度分层和抽象,研究者修改算法时需要穿越多层代码。Molt 通过一个约 8.6K 行的极简设计,使得算法修改只需触及一个组件,同时不牺牲性能——在标准基准上与基于 Megatron 的成熟堆栈在吞吐量上达到统计一致。
FSDP2、EP、CP、TP 是什么? 这些是数据并行性和模型并行性技术,用于拆分大模型使其能放进多张 GPU。FSDP2 将模型参数、梯度和优化器状态分布在多个 GPU 上进行训练。TP 将一个层的参数沿特定维度切分到多个 GPU 上。EP 是 MoE 模型的特有并行方式,将不同的专家分配到不同的 GPU。CP 沿序列维度切分长上下文。
ChatAgent 和 Env 两种智能体形式有什么区别? Env 形式更接近经典强化学习的 Gym 风格——框架负责驱动 LLM 循环、token 化等,用户只需要提供 step() 函数。ChatAgent 形式则更灵活——如果用户已经有一套基于 OpenAI 或 Anthropic 标准 SDK 的智能体代码,只需将 base_url 指向 Molt 的环回服务器,即可直接接入训练,无需修改原有代码。
如果你还有哪些想要了解的,欢迎在评论区留言或者讨论~
龙哥点评
论文创新性分数: ★★★★☆
Molt不是学术上的算法创新,而是基础设施创新。它将可读性作为一级设计原则,放弃了堆栈的多后端抽象,在现有的 Ray、vLLM、AutoModel 基础上进行了极简组合设计,实现了 8.6K 行代码达到生产级吞吐量的结果。
实验合理度: ★★★★★
头对头实验设计相当严谨,发布了全部协议细节,对统计差异做了明确说明。每次做三次独立运行并报告均值与标准差,符合顶级工程论文的规范。论文还用 700B MoE、专家并行 256 跑通了全异步循环,验证了极端规模下的可行性。
学术研究价值: ★★★★☆
为智能体在线强化学习系统设计提供了清晰的案例和原则。特别是对 token 身份、策略版本语义、正向一致性这三个不变性的形式化表述,以及对滚动路由重播等特定 MoE 差错模式的纠正方案,具有明确的学术参考价值。
稳定性: ★★★★☆
明确通过安全性设计提升了稳定性:离线策略校正的可选性、配置时对不兼容并行组合的硬性检查、MoE 路由的一致性保障等,都有助于避免无声错误。目前主要的不确定因素在于框架相对较新,社区验证时间较短。
适应性以及泛化能力: ★★★★☆
理论上 Molt 适用于任意以 vLLM 为推理引擎、AutoModel 为训练后端的智能体强化学习场景,跟前端环境无关。场景限制主要是由后端选择带来的:对于已经使用非 AutoModel 或非 vLLM 的用户,迁移成本主要在这两个硬性绑定上。
硬件需求及成本: ★★★★☆
8.6K 行代码的轻量工程本身不带来额外硬件成本。实际上由于可直接使用上游引擎的所有优化,硬件利用效率反而可能比更重的框架更高。对于 35B MoE 模型,Molt 在 16 张 H100 上运行良好;700B MoE 的验证也是在 256 EP 配置下完成的。
复现难度: ★★★★☆
代码已经在 GitHub 开源,并且提供了 recipies 和容器。论文对主要配置给出了命令行参数。主要复现难度可能在于需要特定的 NVIDIA AutoModel 环境和 vLLM 版本管理,以及大规模的 GPU 资源。
产品化成熟度: ★★★★☆
Molt 已经解决了智能体强化学习中常见的隐蔽错误和性能瓶颈问题,性能达到生产级标准。目前产品化主要依赖上下游引擎的产品稳定性和特性支持。对于新开发的智能体应用,使用 Molt 作为研究到生产的桥梁是完全可行的。
可能的问题: 目前仅支持一个训练后端(AutoModel)和一个推理引擎(vLLM),对已有其他基础设施的用户迁移成本较高。实验只用了 Qwen3-30B-A3B 一种模型做头对头性能对比,更多模型和更长上下文的快速验证还有待社区进一步扩展。
主要参考文献
Hu, J., et al. (2025). Molt: A Scalable PyTorch-Native Training Framework for Agentic Reinforcement Learning. arXiv:2607.18572.
Kwon, W., et al. (2023). Efficient Memory Management for Large Language Model Serving with PagedAttention. SOSP.
Zhao, Y., et al. (2023). PyTorch FSDP: Experiences on Scaling Fully Sharded Data Parallel. VLDB.
Shao, Z., et al. (2024). DeepSeekMath: Pushing the Limits of Mathematical Reasoning with Open-Source Foundation Models. arXiv:2402.03300.
Hu, J., et al. (2025). REINFORCE++: An Efficient and User-Friendly Framework for LLM Fine-Tuning. arXiv:2501.03262.
Liu, A., et al. (2025a). The Training-Inference Mismatch: Understanding and Mitigating Distribution Shift in LLM Training. arXiv:250x.xxxxx.
Ma, J., et al. (2025). Rollout Routing Replay for MoE Consistency in Online RL. arXiv:250x.xxxxx.
*本文仅代表个人理解及观点,不构成任何论文审核或者项目落地推荐意见。欢迎就论文内容交流探讨,理性发言哦~ 想了解更多原文细节的小伙伴,可以点击 "阅读原文", 查看更多原论文细节哦!
想亲手复现Molt的700B MoE实验?想和龙哥探讨Agentic RL框架设计的最优解?
扫描下方二维码,加入龙哥读论文粉丝群,
添加龙哥助手微信号加群 :kangjinlonghelper。
一定要备注:研究方向+地点+学校/公司+昵称(如 强化学习+上海+英伟达+龙哥) ,根据格式备注,可更快被通过且邀请进群。