知乎的大模型训练圈，这周格外热闹。
8月21日，有人提问：单机多卡大模型RL后训练，huggingface/trl和什么框架一起用实现分布式？知乎回答里直接给出三个名字：slime、miles、verl。8月27日，「如何评价开源训练框架AReaL？」这个问题，两天时间积累了近10万阅读。知乎中间这几天，有人一口气发完了25章的AReaL源码走读系列，也有人发出VeRL整体架构的完整解析。
问题不同，焦虑相同：RL后训练走到多卡上了，框架太多，不知道选哪个。
数一下：verl、slime、AReaL、OpenRLHF、TRL、easyr1、Miles、NexRL、Relax、vime……叫得出名字的就有十几个。
为什么今年打起了框架战
不是大家爱造轮子，是负载变了。
两年前数学推理时代，一轮RL训练很简单：rollout生成答案，打分，梯度更新。rollout短平快，同步训练就够用。
到了Agent时代，情况变了。多轮交互、工具调用、长程任务，一条轨迹可以很长，token消耗按数量级上涨。知乎上一篇近4万阅读的回答说得很直白：推理/rollout，已经成为RL训练里的耗时大头。社区现在梳理出四个优化方向：把trainer、rollout worker、推理server拆成异步流水线；用RollPacker、SortedRL这类调度解决超长样本拖慢整个batch；用SPEC-RL这类投机式rollout降低目标模型的解码成本；用Heddle、OrchestrRL做动态调度。知乎围绕的都是一件事：别让GPU闲着。
老的同步架构开始撑不住。verl官方在0.8.0更新说明里承认：框架的架构设计本身是为了math reasoning时代的训练，训练pipeline大量耦合在trainer里，跑过agent训练的同学都知道有多难受，于是直接来了个架构重构，支持同卡同步训练、同卡异步训练和异卡异步训练。知乎slime v0.3.0同样打出「面向Agent时代」的旗号，把fully async训练从example升级为正式功能。
也就是说，这场框架战，本质是在争「训练和推理这两件事，在多卡上怎么摆」。
四条路线地图
把名词剥开，现在的框架大致可以分成四条路线。我的划分标准只有一条：训练和推理怎么摆，中间胶水谁来做。
路线一，HF原生轻量派：TRL。 就是那位提问者的起点。和HuggingFace生态亲和度最好，上手门槛最低，但它的定位一直是算法实验工具，不是大规模生产机器。1-2张卡快速验证一个RL算法想法，TRL没问题；一旦上8卡生产，你会发现分布式部分要自己拼，这也是为什么原问题问的是「和什么一起用」。
路线二，经典编排派：OpenRLHF。 最早基于Ray加vLLM加DeepSpeed架构的开源RLHF框架，把PPO的actor、critic、reward、reference四个模型编排成一个训练循环。知乎社区对它的评价很一致：代码清晰，非常适合学习，很多人RL训练的第一课就是从OpenRLHF开始的。短板是架构偏经典，Agent式的长rollout不是它的主场。
路线三，混合引擎主流派：verl。 字节跳动开源，核心设计是HybridFlow：把RL的控制流和训练的计算流解耦，让算法研究者像写单进程脚本一样定义训练循环。训练侧FSDP和Megatron双后端，推理侧vLLM和SGLang都接，0.8.0重构后同卡同步、同卡异步、异卡异步三种模式齐了。
verl最大的优势是用户基数大、资料多：源码走读、配置教程、GRPO实现拆解，遇到问题基本都能搜到有人写过。8到64卡第一次跑RL生产，verl是不容易出错的选择。
路线四，大规模异步生产派：slime和AReaL。 slime出自智谱与清华THUDM，Megatron加SGLang加Ray的组合，经历过GLM大规模训练的反复验证；v0.3.0把fully async从example级别的能力提升为主目录维护的正式功能，原生支持compact、subagent这类变长训练数据，还重构了PPO，让actor和critic始终共卡，从GRPO切到PPO时不用再为critic多备一套卡。知乎
这个重构的背景，是长程Agent任务让大家重新想起PPO类算法：B站上「GLM-5.2为什么放弃GRPO换回critic-based PPO」「GLM-5.2放弃GRPO回归PPO，DeepSeek的强化学习路线错了吗」这类分析视频，各有几千播放。哔哩哔哩哔哩哔哩
slime v0.3.0还把SGLang的多server配置做了扩展，推理侧从一套参数变成可组合的server、router拓扑，有用户直接拿slime当SGLang的多机启动器，官方原话说得很直白：用户需要的不只是一个RL框架，而是一个能稳定拉起复杂推理拓扑的infra入口。知乎
AReaL出自蚂蚁集团，是fully async RL的先行者。最近有人用25章的源码走读把它拆了个底朝天：三种权重同步策略、同卡共置的AWEX零拷贝传输、让有限显存装下多个大模型的offload/onload，以及v2.0从单控制器到服务网格的微服务化重构。知乎工程复杂度最高，上手门槛也对应最高。
顺带一提：LLaMA-Factory团队的easyr1继承自verl；RadixArk开源的Miles主打企业级MoE强化学习训练，今年5月，RadixArk宣布完成1亿美元种子轮融资，英伟达、AMD、英特尔三家芯片巨头罕见同框。知乎SGLang加Miles这条生态线，正在被算力巨头认真对待。还有NexRL、Relax这些新选手。生态很繁荣，选型很头晕。
怎么选：先回答三个问题
不给唯一正确答案，框架选型和买装备一样，先看场景再看配置。三个问题：
第一问：几张卡？ 1-4张卡跑7B级小模型的算法实验，TRL或easyr1就够，别上复杂度。单机8卡到几十张卡，verl资料库最大、求助成本最低。百卡级以上、MoE、长程任务，团队里有人读得动Megatron源码，再看slime和AReaL。
第二问：是不是Agent任务？ 数学题、代码题、单轮问答这种秒级rollout，同步训练简单可靠。多轮工具调用、环境交互、分钟级轨迹，优先选把异步训练和custom rollout做成一等公民的框架，verl 0.8.0和slime v0.3.0都明确支持。
第三问：团队里有没有系统工程师？ 这一代框架本质上是训练系统和推理系统之间的胶水层，RL框架不该重复造推理和训练的内核，而应该用好vLLM、SGLang和Megatron、FSDP这些社区的力量。知乎verl、OpenRLHF的胶水友好，改造门槛适中；slime、AReaL上限高，但Megatron侧偏重，出了问题得有读源码的能力。纯算法团队追强不追熟，容易吃亏。
值得记住的踩坑信号
讲一个8月的真实案例。有人在单机8×B300上跑异步GRPO，用slime v0.3.1加Megatron-LM加SGLang，模型是Qwen3.5-35B-A3B这种MoE。结果：每一步都要把训练侧更新后的权重同步到推理引擎，这个耗时按步数几何级增长，实测143秒、363秒、966秒、1596秒，一路翻倍。知乎拆开一步约57分钟的时间轴，rollout只占约68秒，其余时间全在空转。
排查过程值得每个工程师收藏。他先怀疑权重同步路径变更是原因，随即意识到：固定路径开销不会每步翻倍，增长本身就说明是累积效应，泄漏、碎片或状态膨胀。然后用py-spy对训练进程连采六次，六次全部卡在同一处：框架给每一个底层NCCL调用都套了一层显存探测，权重同步是逐参数广播，每次广播前都先查一遍可用显存；而开了expandable_segments之后，allocator的segment数量随训练累积增长，遍历统计越来越慢。知乎最讽刺的是，同步期间空闲显存有几十GB，探测本来要服务的清理逻辑一次都没触发，纯开销。
三条经验：一看累积型变慢先看增长曲线，不看绝对值；二修完一处一定要重新采样，开销会搬家到下一个最慢的地方；三同一个bug有三个名字，broadcast、all_gather、_allgather_base，漏掉一个就会回来。
这个案例也说明了RL框架选型的底层难度：训练效率的命门，早就从算力转移到了权重同步和调度上。评估一个框架，别只看能不能跑起来，要看它的权重同步路径、可观测性工具，以及社区里有没有真人在发踩坑记录。
几个值得继续盯的信号
verl 0.8.0的三种异步模式能不能在生产里站住，接下来几个月的社区踩坑记录是风向标；
TRL能不能补上异步rollout这一课，HF生态最庞大的用户群在等这个；
算法层面盯一下「回归PPO」会不会成为长程Agent训练的普遍选择，这决定各家框架的PPO支持是选修还是必修；
算力供给还在放量：英伟达2027财年第二季度营收达962亿美元，同比增长106%。知乎等算力不再这么贵，框架竞争的重心会从卷效率转向卷易用性。
如果你正卡在选型上，我的建议很简单：用手头的卡，一天之内把一个小模型的完整循环跑通，对比rollout占比和权重同步耗时这两个数字。这个测试结果，比任何对比文章都诚实——包括这一篇。
