
模型能力的下一段增长,不只发生在参数里,也发生在 rollout、reward、训练引擎、环境反馈和权重同步组成的系统里。
昨天《训推工坊:以 verl 代码库走读 AI Infra》第 24 篇《Checkpoint Engine:训练权重如何同步给推理引擎》刚刚发布。今天是周日,正好借这个节点做一次阶段总结。
上一次做阶段总结,系列刚写到 Agent Loop。那篇文章获得了很高的阅读量。之后,后台几乎每天都在新增不少关注,早期文章也在持续被读到,整个系列的阅读量还在往上走。
先认真说一句感谢。
也特别感谢到了周末,仍愿意抽时间关注 AI 进展、阅读这类长文的朋友。愿意在休息时间继续追问训练、推理和 Agent 基础设施,本身就是这个系列能够持续写下去的重要原因。
感谢每一位愿意读长文、看架构图、顺着源码继续追问的读者。基础设施文章不天然轻松,也很难靠一句结论讲完。大家持续阅读、转发和讨论,让我越来越确定:不是读者不愿意读源码,而是大家需要一张能把算法、推理和分布式系统连起来的地图。
写到第 24 篇,我对这个系列也有了一个更清晰的判断:理解 verl 的意义,已经不只是学会一个后训练框架,而是借一套真实代码,理解 AI 能力如何被一个 train/serve 系统持续生产出来。
很多人第一次接触 verl,是因为 DeepSeek-R1、GRPO 或数学推理,容易把它理解成一个服务算法研究的训练工具。但从最新公开资料看,verl 已经进入模型公司、云与算力平台、互联网应用、开发者工具和 Agent 项目的共同技术视野。
verl 官方 README 将 ByteDance、Anyscale、LMSys、阿里 Qwen、上海 AI Lab、京东、微软研究院、StepFun、Amazon、LinkedIn、美团、小米、NVIDIA Research、百川、Moonshot AI、百度、Snowflake、Skywork.ai、JetBrains 等列为 “adopted and contributed by”。这个合并表述包含采用方与贡献方,不能把名单里的每一家都等同于公开的生产部署案例;但它足以说明,verl 面对的已经不是单一实验室里的单一算法问题,而是一组跨公司的后训练基础设施问题。
一些公开项目给出了更具体的落点:豆包 1.5 Pro 的 RL scaling preview、Seed-Thinking-v1.5 和 DAPO 都在官方 README 中明确关联到 verl;OpenManus-RL、Microsoft rStar2-Agent、Search-R1、verl-tool 等项目,则把它扩展到多环境 Agent、工具调用、搜索和软件工程任务。verl 正在从“训练一个会答题的模型”,走向“训练一个能够推理、使用工具并在环境中完成任务的策略”。
具身智能是这条路线向物理世界延伸的直接例子。SimpleVLA-RL 明确建立在 veRL 之上,把 rollout 改造成多环境并行渲染、机器人动作生成和环境交互;VLA-RFT 与 DeepThinkVLA 的公开代码也保留或扩展了 verl 的 PPO 训练栈。更关键的是,verl v0.8.0 已把原来的 VLA 实验代码迁移成独立的 verl-vla项目,定位就是覆盖人类在环数据采集、微调与强化学习的统一 VLA 后训练框架,最新代码已经出现 Pi0.5、GR00T N1.6、LIBERO 评测和数据采集工作流。
这些公开项目不能证明每一家未披露技术栈的具身智能创业公司都已生产部署 verl,但它们已经证明:verl 的数据流、rollout、环境交互、训练引擎和权重更新抽象,正在被机器人与 VLA 训练复用。对具身智能创业团队而言,这类框架正在从“可以关注”变成需要认真评估的基础设施候选。
对个人来说,这正是走读 verl 的长期价值。你获得的不是某个版本的 API 记忆,而是一张从 reasoning model、coding agent、search agent、GUI agent 一直延伸到 VLA 和机器人的认知地图。所谓做大模型时代的先锋,不是比别人更早转发一个模型名称,而是更早看懂不同热点背后的共同系统结构,并能判断下一次能力迁移会把瓶颈推向哪里。
过去谈大模型竞争,最容易看到的是参数规模、预训练数据和 benchmark。现在,更多能力开始由后训练阶段塑造:模型要学会长程推理、使用工具、进入环境、接受可验证反馈,再把新的策略快速接回下一轮生成。
先看这张图。重点不是某个模型或框架谁更领先,而是三股变化如何共同把系统压力推向中间的后训练基础设施。

模型能力竞争正在把系统压力推向后训练基础设施
第一股变化是 reasoning RL。OpenAI 在介绍 o1 时明确把能力增长和大规模强化学习、更多思考时间联系起来;DeepSeek-R1 展示了大规模 RL 如何激发推理行为,也同时暴露了重复、可读性和语言混杂等问题;Qwen3 的公开训练流程则把 reasoning RL、thinking mode fusion 和 general RL 放进同一条后训练路线。它们的技术方案并不相同,但共同说明了一件事:后训练不再只是把模型“调得更听话”,而是在塑造推理和行动能力。
第二股变化是 Agent 从“回答问题”走向“完成任务”。一旦模型开始搜索、写代码、调用工具、操作 GUI、进入 sandbox,或者根据视觉与机器人状态输出动作,训练数据就不再只有 prompt 和 final answer。系统还要保存多轮 observation、tool response、action、token mask、环境状态和 reward metadata。一次 rollout 也不再是一个整齐的批量推理请求,而可能是一批长度不同、会失败、会重试的交互轨迹。
第三股变化是模型和硬件继续变复杂。MoE、长上下文、多模态以及 GPU/NPU 等异构后端,让训练侧需要 FSDP、Megatron、Context Parallel 和 offload,让 rollout 侧需要 vLLM、SGLang、TensorRT-LLM 等推理引擎。两侧还必须在每轮更新后交换权重、管理 KV cache,并处理显存和通信拓扑。
这三股变化汇合后,真正困难的问题就出现了:谁组织数据流?谁调度不同角色的 worker?生成和训练怎样共享或拆分资源?新权重怎样及时送到 rollout replicas?环境和 reward 出错时,系统怎样定位?
这些问题,正是 verl 源码最值得读的地方。
截至,现在verl GitHub 仓库已有约 2.2 万 stars,最新正式版本是 2026 年 6 月发布的 v0.8.0。star 数不能证明生产成熟度,但版本内容比热度更能说明方向。
v0.8.0 不只是增加几个算法名称。它继续扩展统一训练引擎、vLLM/SGLang/TensorRT-LLM rollout、Checkpoint Engine、TransferQueue、fully async trainer 和 on-policy distillation;同时把 coding、search、GUI agent RL 以及多轨迹 Agent Loop 推进到更明确的位置。换句话说,项目演进的主线正在从“实现一个 PPO/GRPO trainer”,走向“组织训练、生成、环境和数据传输的系统”。
外部生态也在快速迭代。vLLM 在 2026 年 7 月 11 日发布 v0.25.0,SGLang 在 7 月 10 日发布 v0.5.15;NVIDIA NeMo RL 已发布 v0.6.0,其官方文档同样把 policy training、fast inference、reward environment 和多类 RL actor 的资源协调放在同一套设计里。
这不是说所有项目最终会长成同一种架构。相反,它说明 rollout 引擎、训练后端、环境执行、权重更新和异步数据流正在形成各自快速演进的边界。框架会变化,接口会变化,但理解这些边界的能力会留下来。
这个系列一直没有按 API 列表展开,而是沿一次后训练系统真正流动的路径往下读。
下面这张图把前 24 篇压成四组。看图时重点关注每组最下方的“读完后获得什么”:文章的目标不是让读者记住更多名词,而是让每个名词回到它改变的数据、资源和运行时边界。

前 24 篇已经建立的四层系统地图
第一组从全局地图开始,解释为什么后训练不是一个训练脚本。HybridFlow、Single Controller、ResourcePool、WorkerGroup 和 DataProto 共同回答:一轮 RL step 的控制流、数据流和资源角色怎样被组织起来。
第二组把算法翻译成工程合同。PPO、GRPO、DAPO、KL、clip、entropy、reward 和 dataset schema,不再只是论文术语,而会落到 advantage、mask、loss、batch 字段和配置分支里。
第三组把推理重新放回训练。rollout 是训练时的推理服务;vLLM、SGLang 和 TensorRT-LLM 是可替换后端;KV cache、sleep/resume、Agent Loop、tool calling、sandbox 和长尾轨迹共同决定样本怎样产生。
第四组进入训练引擎与分布式核心。FSDP/FSDP2、Megatron/MCore、EngineRegistry、mini/micro/dynamic batch、Sequence Parallel 和 Checkpoint Engine,解释大模型如何被切开训练,又怎样把更新后的 actor 权重送回推理引擎。
到第 24 篇,读者已经可以沿着这样一条路径读代码:
dataset row
-> DataProto
-> controller / WorkerGroup
-> rollout server / Agent Loop
-> reward / advantage / actor update
-> training engine
-> Checkpoint Engine
-> next rollout
这条路径比记住某个类名更重要。它让我们能够追问:一个训练效果变化,究竟来自 reward、mask 还是 rollout policy?一次性能下降,究竟卡在 generation、actor update、data movement 还是 weight sync?
理解 verl,并不等于认定它是唯一答案。这个系列选择 verl,是因为它把现代后训练系统最关键的边界集中暴露在同一个代码库里。
看下面这张图时,先看中间的 controller/dataflow,再看上下两侧。训练后端和 rollout 后端可以替换,工具与环境可以扩展,但系统仍要处理数据合同、资源调度、权重同步和端到端性能。

verl 把后训练系统的关键边界放进同一张源码地图
这张图也解释了为什么只懂一个局部越来越不够。
只懂算法公式,可能看不到 rollout 数量、response length 和 mask 怎样改变显存与吞吐;只懂训练并行,可能忽略推理长尾让训练 GPU 等待;只懂推理服务,可能低估每轮权重更新、KV cache 释放和策略新鲜度的成本;只看集群利用率,又可能错过 controller 序列化、DataProto 搬运和异步队列里的尾延迟。
而 verl 提供了一个很好的观察窗口:算法目标如何变成字段,字段如何穿过 controller,worker 如何占用资源,rollout 如何生成轨迹,训练引擎如何更新参数,新权重又如何回到推理侧。读懂这条链路,才更容易判断成本、瓶颈和架构取舍。
如果你第一次看到这个系列,不必一次读完 24 篇。
最重要的不是阅读顺序完全一致,而是始终带着四个问题:它出现在一轮 RL step 的哪里?它消费和产生什么数据?它占用什么资源?它把瓶颈推向了哪里?
第 24 篇结束后,一次 RL step 的主要结构已经闭环。接下来的第 25 至 30 篇会进入性能、规模与生产化:如何 profiling 一次 RL step,吞吐瓶颈究竟在哪里,Data movement 为什么可能成为隐藏成本,TransferQueue 怎样把控制流和数据流解耦,fully async policy 如何在速度、样本新鲜度和 off-policy 之间取舍,以及 671B/MoE 级别训练会放大哪些系统问题。
这也是整个系列下一阶段最想回答的问题:系统能跑通之后,怎样让它可观察、可扩展、可解释地持续运行?
最后,再次感谢每一位新关注和一直跟读的朋友。不断增长的阅读量,是对这个系列最直接的鼓励,也提醒我继续把事实核准、把图画清楚、把源码和行业变化真正连起来。
AI 时代最稀缺的,可能不是再背一套框架 API,而是理解模型能力究竟怎样被系统生产出来。
能更早建立这张认知地图,才是“先锋”真正有价值的部分。
这也是《训推工坊》会继续写下去的原因。