作者：大润发杀鱼工

https://zhuanlan.zhihu.com/p/1985812420770428370*

前情提要

窝趴在电脑前下棋的我，突然被微信里 junrong 老师Q到了，说知乎上又刷到了我去年的年终总结，还问我今年什么时候写。ahhh，其实本来是有想写的，可惜这个班害人不浅，到了周末就只想开摆，真的不是我懒 QAQ。回首去年中二地想站在舞台中央，今年我明白了，原来在幕后搬砖就已经耗尽了我全部的力气（bushi）。

闲扯聊完，趁着最近工作强度不大，简单说说我的这一年,从年初开始接触RL训练，上半年参与 Verl 支持前期构建工作，并完成 dpsk-v3 RL 训练的 milestone。下半年入职后在席德多模态做 RL 支持。

整个一年都在和 RL 打交道，也看到了算法、框架、关注点和任务场景的不断迭代更新。下面我也写一些自己想到的对 RL 的观点和理由。以下纯文字概况，不包含技术细节，仅输出观点，欢迎评论区讨论。

Rollout 是 RL 的核心

相比预训练来说，RL 的特点是：

训练数据量少；训练 batch size 一般较小；
训练资源占用少；单个 step 时间长；
rollout 占训练实际时间比重大。

之所以说 rollout 是 RL 的核心，主要在于优化 rollout 的输出时间对整个 RL 训练端到端时间的提升有显著收益。

因为到了 RL 阶段，预训练通常已经在成熟的训练框架下完成了工作，只要保证 RL 阶段的 MFU 能尽量靠齐预训练，就能基本满足预期。

但 RL 阶段训练尚未完全结束，模型可能还没上线发布，它的推理极限在哪里，还需要进一步探索。

另外，大量RL训练的探索，变动的位置均发生在rollout阶段，因此RL的多样性，有很大一部分改动发生在rollout阶段。

同时，rollout 也需要与训练做对齐。rollout 的高吞吐并不是 RL 必要指标，RL 也不追求 TTFT。在异步场景下，只要配置好合适的参数和资源，能够让 rollout 与训练无缝衔接，其实已经是很大的优化了...

Infra 更面向业务

对于预训练来说，训练完一个模型、让 TB 甚至 PB 级数据顺利训完是终极目标。为此，负责预训练的同学需要对从 loader、训练到 ckpt 等各个阶段投入大量人力优化。如果单个 step 能减少 1% 的开销，对于按 GPU 月衡量的任务也有显著收益。

而 RL 是在基础模型的基础上，根据不同的 recipe 训练出若干模型。各模型的能力侧重点也不同：有的擅长 code，有的擅长逻辑，有的擅长 VLM。

相比预训练，RL 的训练链路更花样百出，工程同学写的代码也更偏向“胶水”与实现本身，而不是纯粹的优化。

我觉得 RL 优化力度不高主要有两个原因：

RL 训练步数少，训练时间短：即便每步优化 1%，端到端收益也不会显著。
不同任务优化方向不同：有的希望模型 rollout 更快，有的卡在工具调用或 sandbox 交互，有的打分效率不行，还有的可能是数据 IO 需要优化。优化带来的共享性并不明显，ROI 也不突出。当然，如果某个瓶颈会阻塞所有训练，那我建议赶紧修好它。

框架设计比实际优化更重要

聊完 infra 面向业务，这就引出了一个观点：框架设计比优化本身更重要。

本质上，因为大家在同一个主干上参与训练（rollout -> … -> train），但预期行为却五花八门。如何在共用与分叉之间做有前瞻性的框架设计，并尽可能模块化、插件化地组织代码，对工程和算法都大有益处，也非常考验框架设计者的能力。

对工程同学来说，比如 rollout 的逻辑可能有 n 种。

如果写 n 个 if/else，当然能跑，但维护性和可读性会受到极大影响。

如果以 server 化 + bs1 的方式设计，动态加载 & 自动加载对应的 rollout 逻辑，会更加利于维护和阅读。最近 verl 也废弃了 spmd 模式，进入rl的历史中，也证明了这一点。

对算法同学来说，一个 idea 可能就只是涉及对 rollout 逻辑的改动。好的框架设计可能上午找 GPT 写完代码，下午就能顺利开测。而差的设计则会让不熟悉底层逻辑的算法同学先理几天的线头，极大阻碍实际进度。

说白了，算法同学可以接受优化不够极致的框架，但接受不了易用性差的框架。我跑验证时十几步、百八十步就能快速验证，我需要一个为追求极致优化而牺牲易用性的框架吗？No！（生产场景另说...另外一码事了）

效率、异步和 off-policy

年初的时候，大部分 RL 框架还是同步模式，在一个完整的 FusedWorker 上同时做训练和推理。后来发现，这太慢了，有些 prompt 还卡在 rollout 上。

是否能把这些长尾放到单独节点去，让它慢慢 rollout？对于已经 rollout 完的数据就先训练。这就顺理成章设计出了 partial rollout 和 stream rollout。

在这种情况下效率虽然提高了，但带来了至少一个工程问题和一个算法问题，简单描述一下就是：

工程问题：如何保证不同轮之间的数据管理、参数同步、kvcache 管理。
算法问题：对于 off-policy 的容忍度到底有多高。

总之，效率和精度不可兼得，需要什么就选什么。否则干脆不用专门的推理框架来做 rollout，直接用训练框架，数值精度对上，是不是更香？

Rollout server 化与 agentic RL

前面聊到，将训练和推理分离，是为了解决 rollout 阶段逻辑花样太多的问题。那 rollout 在干什么？这引出了 agentic RL。

对于不同的 agent 任务，agent 需要做的事情也不一样：

专注 math 的 agent 可能需要 sandbox 做 Python 计算；
专注 GUI 的 agent 可能需要电脑桌面动态交互；
专注搜索的 agent 可能需要调用谷歌接口去搜东西。

正因为大家的行为各不相同，而且需要在完成操作后把结果以 token_ids 的方式传给 rollout 处理。相比写在一起的 spmd，用类似分支发散的方法来处理，server 化的结构更自然：只需要发给统一的 proxy，而不用关注背后的 rollout 细节。

最近几个月在知乎看到许多算法博主分享如何选择方便做魔改或支持 agentic RL 训练的框架，也都提到了 server 化…至少说明这是目前 RL 框架必须具备的能力。

RL 训练的稳定性怎么搞

以前我们总关注训练稳定性，一般指机器别坏、网络别断、显卡别掉。但在 RL 场景下，更像是在说训练怎么才能不崩，怎么才能训更多步。

最近 2-3 个月，有很多关于训练稳定性的文章：R3、TIS、GSPO，以及好像在 dpsk v3.2 里也有优化（我还没来得及看）。总的来说目标只有一个：尽可能延迟 RL 训练崩溃。若在指标起飞、打分猛跌时基本宣告这一把训练结束了：要么想办法救一下，要么就再开一把。

至于为什么会崩，我不是专业人士，这里不展开说。但我觉得这也是 RL 训练的一个风向：大家从关注如何训更大模型、如何更快训练模型，转向关注如何训更稳定的模型、如何让模型能训练更多步。

SaaS 化的 RL 服务

最近很火的一个产品（或者也可以称之为概念）：Tinker，作为 TML 最近开源的新工具，我感觉也是未来的发展方向之一。

我目前对它的理解是：它能让 RL 任务在类似 Llama Factory 的仓库里，仅提供数据和模型，就可以借助标准训练流程完成训练。全程不需要操心其他事情。

如果这个 server 能把 RL 训练中最头疼的环境搭建环节跳过，并帮我维护好 reward 相关的处理，让我专注完成 agentic RL…未来可期，我比较看好。

对于非主营大模型业务的团队，若能在 SaaS 平台上完成 RL 训练而不依赖工程同学，这对大模型业务融合有很大帮助。最近接触的几个创业公司好像也在这上面发力。看好，很不错…

碎碎念了…

啊，终于写完了一点自己的感悟。一年时间，感觉确实学了很多东西。席德确实是一个学习的好地方，大家都很好，也都很强，也…很卷。

每次看到自己负责的模块被规模使用时，感觉非常兴奋，也感受到压力。如果不小心写出了 bug，还得花时间去修、去调精度、去平衡，也是相当费时间。在一个功能实现的时候，它距离完成可能只有一半甚至更少，潜在的 bug 和更好的支持可能还需要花同样多的时间。

对明年的自己，也留几个期盼吧：写好代码，写好代码；做一些能创造价值的事情；增加对细节知识的理解。

看到去年中二的年终总结名称，社畜释怀的笑了。年轻就是好，说话都不一样，ahhh。今年说不定就是——泪水打湿猪脚饭，明天还得继续干~~