做网站南昌建站平台塔山双喜

做网站南昌,建站平台塔山双喜,wordpress pdf手册,网站qq访客记录原理作者 | 浮生梦晓知乎 转自 | 对比现有的 RL 训练框架#xff01;原文链接#xff1a;https://zhuanlan.zhihu.com/p/1979237927641949997点击下方卡片#xff0c;关注“大模型之心Tech”公众号戳我- 领取大模型巨卷干货本文只做学术分享#xff0c;已获转载授权#…作者 | 浮生梦晓知乎 转自 | 对比现有的 RL 训练框架原文链接https://zhuanlan.zhihu.com/p/1979237927641949997点击下方卡片关注“大模型之心Tech”公众号戳我- 领取大模型巨卷干货本文只做学术分享已获转载授权欢迎添加小助理微信AIDriver004做进一步咨询前段时间调研了一些 RL 训练框架目前开源社区的 RL 训练框架可以说百花齐放老牌的有 openlhf、trl、unsloth、verl。还有今年新开源的 slime、AReaL、Rlinf、RL2、ROLL 等等肯定还有很多没列出来的就不一一列举也看不过来。由于工作的场景需求是对于 VL 多模态模型进行实际环境的 RL 训练这个过程需要 multi turn因此很多框架可能目前并能很好的适配。重点对 verl、slime、AReaL、RL2 做了代码阅读分析与实际 RL 环境进行适配。这里先说一下我调研框架过程中纠结的一些点。个人看法轻喷点 1各训练框架尺有所短、寸有所长都有各自的架构很好的地方也有相对待完善的方面。目前没有一款可以很好适配多模态模型去做我的需求业务的 agentic rl 训练的框架当然这也不是框架的原因主要在于 agentic 环境与具体业务相关没有办法从框架层面抽象出来一个函数或者类来适配所有的 agentic 环境这也是我从一个框架调研到另一个再到另一个的原因。我一直想找一个社区活跃度比较高对于环境适配代码相对修改较少的框架这里直接说最后选择了 AReaL。我的具体业务环境不展开说了简单来说是需要每个训练样本都有不同的环境状态除了模型的输出内容去环境里执行动作以外还需要框架会话与环境多次交互这一点就卡死了大部分 RL 框架的 agent loop 控制流当然除非做侵入式代码修改但框架更新后 rebase 又很麻烦点 2我比较纠结的是 RL 训练过程中 GPU 的编排问题在 rlhf 和 rlvr 时代听上去很遥远实际上也就是 25 年前半年以及之前训练过程中长尾效应没有 agentic rl 那么明显所以异步 RL 训练的想法并没有在早起成熟的 RL 训练框架中体现出来。之前开源的 RL 框架基本上都是训练和推理同步的架构方案典型代表像 verlverl 实现了这几个模型的简单命令编排但没有改变同步运行的本质也就是整个训练流程都要遵循下图中 1,2,3 来进行先推理后训练。同步的 RL 训练玩的也比较花比如是在相同的 GPU 集群上推理时训练的模型卸载训练时推理的模型卸载这种可以在容器内部署也可以物理上执行。也可以在不同的 GPU 集群上流水线的方案就像 verl但这样就会造成训练效率的低下以及 GPU 空转。因此我对于以同步 RL 训练为主的框架都是浅尝辄止没有深入研究verl 是因为今年 10 月份增加了全异步训练的 monkey patch 才对其源码进行来阅读不过代码中写死了 agentic 的执行流程修改起来代码量不小后面会稍微详细的说一下。点 3数据流向与数据结构其实这也是同步和异步训练带来的一个影响。在 verl 中将传统的 rlhf 训练的流程看成一个数据流图数据在 actor、critic、reference、reward 中进行流转最后来计算 PPO 公式得到损失再对 actor 进行反向传播参照下图为此 verl 专门设计了一种数据格式DataProto[1]从这个数据结构组成上来看并不复杂它是以 batch 为粒度进行数据传输的这在长尾效应不明显的 RL 训练中是高效的但是在 agentic rl 中反而成了一种负担。原因很简单训练的 DataProto 和推理的 DataProto 是否要是同一批数据呢如果是同一批那就要考虑长尾样本的延迟如果不是同一批那这个设计反而代理额外的时延推理的样本异步执行结果再去组成一个 DataProto。verl 源码中是前者的实现[2]但在补丁代码中是使用的后者[3]。点 4异步 RL 训练框架肯定优先级比较高今年开源的几个框架都支持异步 RL 训练但异步会带来效率上的提升但也会存在一些问题首当其冲的就是数据偏移问题换句话说就不是真正的 on policy 训练因为训练的数据可能是更早几轮的策略模型生成的在强化学习训练中大家的共识就是 on policy 效果优于 off policy。另一个问题就是异步 RL 训练占用的 GPU 资源较高相对于同步训练中训练和推理共用 GPU 集群来说异步 RL 训练必须将训练和推理部署在不同的 GPU 上且二者需要去实验来获得一个比例来保证异步 RL 训练和推理尽量的减少 bubble。除了以上内容外从各 RL 训练框架代码中获得了一些关于 RL 的启发认识有的是之前知道但不清楚代码如何去实现也有的是从代码上新认识到的。1、当前几乎所有的 RL 训练框架都是训推分离的也就是训练引擎使用 FSDP、Megatron推理引擎采用 sglang 或者 vllm。训练和推理之间采用 ray 来充当胶水作用就是分配资源分布式远程调度等。RL 训练框架真正实现的是对于数据的管理、训练引擎和推理引擎的调度、模型权重的迁移训练后的模型权重更新到推理引擎训练与推理不同切分方式的适配以及环境的适配。每个框架在这四个方面有不同的侧重比如 verl 侧重在训练引擎和推理引擎的调度包括其为了践行 SPMD 思想类似于 torchrun 和 CUDA 的运行每个设备 rank 上都会有相同的代码而各设备会根据自己的约束来执行各自的那部分代码编写了 single_controller[4]通过封装底层的 ray 代码让用户只需要简单的命令来实现复杂的模型编排部署如下图所示这种模式天然简约。但这种模式在异步 RL 训练反而成了瓶颈异步需要额外的代码去更新权重、处理生产者与消费者的关系保持 SPMD 风格会使得代码量骤增。其他的框架基本上是直接调用 ray通过 placement_group 来分配 GPU 资源remote 来调度。2、RL 训推分离的训练流程中的控制流还是在训练侧也就是训练的控制流代码中其实这非常好理解强化学习训练与正常的 llm 做 sft 和 pre-train 训练区别不大因为都是基于梯度回传的思想来实现的区别就在于损失函数不再是交叉熵且数据的来源需要 rollout 推理生成如下图实现的简单 GRPO 训练代码。因此强化学习训练无需考虑的很神奇如果不考虑效率直接用 pytorch 手动撸或 ai 生成一个小模型的 rl 训练代码也就半天时间。def train_step(): # 1. Model and optimizer model transformers.AutoModelForCausalLM.from_pretrained(「Qwen/Qwen2.5-7B」) optimizer optim.Adam(model.parameters(), lr1e-5) # 2. Data prompts, answers prepare_data() options {n: 8} # 3. Generation and advantage generations model.generate(prompts, **options) grpo_scores calculate_varifiable_rewards(prompts, answers) # 4. Train loss calculate_gradient_policy(generations, grpo_scores) loss.backward() optimizer.step() optimizer.zero_grad()3、关于训练侧更新了 actor 模型的权重后如何将新的模型权重从训练引擎传递给推理引擎这一部分涉及的问题在于训练侧的模型切分方案与推理侧的模型切分方案不一致而模型如果比较大的话权重的传输也是不小的时延。当前比较简单的方案是直接调用 sglang 或者 vllm 的 fast full 接口例如 slime 中代码HTTPS://GitHub.com/THUDM/slime/blob/main/slime/backends/fsdp_utils/update_weight_utils.py#L223AReaL 中代码HTTPS://GitHub.com/inclusionAI/AReaL/blob/main/areal/core/remote_inf_engine.py#L1025从实现的角度来说也比较好理解。感兴趣可以看下面说明比如训练引擎使用 FSDPv2推理引擎使用 sglang则在初始化时会对于训练和推理进行 GPU 资源分配以及传入切分规则dp、tp、sp 等FSDPv2 通过 device mesh 完成模型的切分。sglang 则将切分后的模型权重加载到各 rank每个 rank 会记录自己负责的模型权重的元数据。当 FSDPv2 训练引擎完成一轮训练产生新的模型权重后会从 FSDP 的 torch.DTensor 转成 torch.Tensor每个训练 rank 会将数据广播到推理的 rank推理的 rank 会根据 sglang 初始化时记录的元数据判断这部分权重是否保留如果保留直接将模型权重存入到原模型权重指针地址处覆盖掉旧的模型权重。如果不保留直接丢掉最终完成全部推理 rank 的权重更新。当然这部分会有很多 trick如果直接由训练的 rank 广播给每个推理的 rank则通信的开销会很大一般的常用的 trick 是训练侧会先进行 all-gather将权重分桶按层或按容量在每个 node 的 rank0 上去广播给推理引擎slime 的实现。而上面的 AReaL 代码是使用了分桶传输这样可以降低通信消耗。verl 中当前的方案比较一般既没有 all-gather也没有分桶。另外sglang和verl都实现了router功能直接发给router由router转发给各rank的方案也是一个主流方案。HTTPS://GitHub.com/volcengine/verl/blob/main/verl/workers/rollout/sglang_rollout/http_server_engine.py#L3504、训练引擎与推理引擎存在 gap 的问题这里的 gap 有两种介绍之前需要先说一下 RL 流程RL 训练需要先将指令发送给推理引擎进行 rolloutrollout 得出每个序列轨迹。如果是 on policy 的 RL 训练本应该直接使用 rollout 的轨迹来计算优势进而计算目标函数来进行梯度回传。但当前的训推引擎是分离的sglang 和 vllm 这种推理引擎自己实现的 CUDA 算子以及存在的各种优化包括不限于KV 量化、算子融合、模型编译等。另外也可能训推异构导致硬件计算精度等原因会使得推理引擎得出的序列轨迹里每个 token 的 logits 与训练引擎相同序列轨迹的 logits 存在差异这种差异会使得原本是 on policy 的训练退化成 off policy 的 RL 训练。关于这个 gap 问题多篇论文和博客都有讨论The AI workspace that works for you[5]。解决的方法其实也比较传统既然推理引擎和训练引擎的分布存在差异那直接使用重要性采样来在推理数据分布中拟合训练引擎数据的分布。也有的优化在这个重要性采样上加上 clip防止二者差异过大。也有的 trick 是提前通过数据分布计算出来这个比值在真实训练时加上这样不必重新将轨迹内容放入训练引擎 prefill 重算了。如果是 off policy 的 RL 训练则本来就应该计算重要性采样也就是 rollout 需要记录轨迹的 logits在训练模型上进行 prefill 获得该轨迹在当前策略模型上的 logits 再去做重要性采样这样做出的重要性采样既包含不同版本间策略模型训推分布的差异也包含训推框架之间的差异。基于上面的这个思想推理引擎其实就可以使用量化推理反正无论如何都要计算训推差异重要性采样那使用 fp8 或者 4bit 量化更快推理岂不美哉。实际上我们知道 PPO 中的重要性采样是需要被裁剪的如果重要性采样过大也就是数据差异太大会容易造成训练的不稳定而一旦该数据被 clip 掉则就不在有梯度回传不清楚的看 PPO 的求导公式。所以推理引擎不能一味的追求推理速度而造成输出分布的失真。fp8 或许还可以使用4bit 量化推理目前还没有广泛使用关键就在于 4bit 量化推理带来的分布差异会有些高很容易被裁剪。所以没有任何精度损耗且推理提效的推测解码成了推理引擎的新宠目前各 RL 训练框架都已经适配或正在适配推理引擎的推测解码。上面只提到了 RL 训推的第一个 gap从第一个 gap 可以知道 rollout 出的数据需要在推理引擎重新 prefill 来计算重要性采样这样就引发了第二个 gap即 rollout 出的序列对应的 token 分布与重新 prefill 进行 tokenizer 编码后对应的 token 分布不一致。举个例子如果推理引擎 rollout 得到的序列为:我喜欢吃西红柿。输出的 token 分布为[我喜欢吃西红柿]但是这个训练在训练引擎 prefill 编码时就很可能编码吃[我喜欢吃西红柿]。token 分布都不一致了还怎么去计算重要性采样。所以可以看到所有的 RL 训练框架在 rollout 返回时会同步返回输出的 token ids直接将 token ids 输入给训练引擎避免二次编码的问题。5、环境的适配以及奖励的管理我在调研这几款 RL 框架时尤其注意其 agentic RL 训练的支持对于外部环境的接入模式以及奖励的计算方式毕竟有的奖励是动作粒度从环境中得到的也有的奖励是对于整个轨迹的。在 verl 中的 agent 多轮训练代码逻辑[6]在这里的设计是判断 agent 的状态来选择不同的函数句柄比如 agent 多轮执行过程中可能需要人去输入新的内容也有的是只与环境进行交互代码逻辑如下图这种交互方式实际上涵盖了一般的 agent 多轮的状态比如执行完 self._handle_generating_state 后也就是推理引擎输出了内容会根据输出内容是否解析出 action 执行 function call是否达到最大交互次数来更新 state 的状态进入下一个循环。而在 self._handle_processing_tools_state 中也就是动作给环境执行的函数中是通过 self._call_tool[7]来对这个动作输出 observation。也就是说 verl 当前版本其实还是以工具的视角来进行 agent 多轮训练并且处理流程很多都写死了只能在模型输出的结果里去与工具交互而真实复杂的环境交互可能需要多次交互且每个 rollout 中的环境未必一致verl 当前的 agent loop 相对有些僵化。而在 AReaL 和 slime 中设计就相对巧妙一些在 slime 中可以通过--rollout-function-path 参数可以传递自定义的函数给 rollout[8]self.generate_rollout 就是外部传入的自定义的 rollout 工作流。在 AReaL 中则需要自定义 workflow[9]基类中设定了子类必须实现的函数。在 example 中可以看见很多自定义 workflow 示例例如HTTPS://GitHub.com/inclusionAI/AReaL/blob/main/examples/tir/tir_workflow.py中内容虽然在代码实际调用的是使用 workflow 中的 arun_episode 方法但是这个类实例化时构造函数里是可以做很多工作的比如初始化环境等arun_episode 方法也可以实现自定义复杂的环境交互逻辑。综合来说所有 RL 框架中环境交互的部分都是异步实现的这一点毫无争议不可能每一个样本都阻塞线程。6、异步训练的处理方案这部分就直接拿 AReaL 来说吧 我个人感觉 AReaL 的异步方案是当前主流 RL 训练框架里比较成熟的包括 verl 也专门 pr 了 recipe[10]来实现异步训练。实现上与 AReaL 大差不差还有一些其他方案可以看 verl 的 recipe 上 readme代码实现上也是大同小异。核心思想就是我们熟悉的不能再熟悉的生产者和消费者关系。推理引擎做 rollout 相当于生产者训练引擎需要数据相当于消费者。同步 RL 与异步 RL 的示意图直接截了 AReaL 论文中的图其实没什么好说的从图中就可以看到同步方案会存在很多 bubble且推理时存在训练资源浪费训练时存在推理资源浪费。异步 RL 会交替异步进行每完成一轮就进行一次模型权重更新。对于生产者和消费者的关系模式借用 verl 中图rollout 出的数据会放在一个消息队列中这个管理队列相当于 replay buffer当数据达到一定 batch size 后训练引擎会从这个消息队列中获取数据来进行训练相反如果消息队列中数据不足则训练引擎等待数据生成。需要注意一个参数staleness。这个参数控制着数据是否需要丢弃考虑现实情况有一个任务需要 rollout 非常久当这个任务 rollout 完成时训练引擎已经完成了多次模型权重更新那这个任务的轨迹是之前模型推理出的如果使用这个轨迹进行训练哪怕有重要性采样也容易被裁剪从而导致最后没有梯度。也就是说 staleness 控制着 rollout 数据不能偏离最新模型分布太久一般设为 1-2很早的数据就丢弃掉因为对训练意义不大。staleness 是如何实现数据控制的也很简单每一个 rollout 轨迹都有一个版本号如果版本号与当前最新模型的版本号差距大于 staleness则从消息队列中丢弃。AReaL 中的实现要更复杂很多AReaL 中这部分代码 HTTPS://GitHub.com/inclusionAI/AReaL/blob/main/areal/core/workflow_executor.py HTTPS://GitHub.com/inclusionAI/AReaL/blob/main/areal/core/async_task_runner.py staleness 管理代码HTTPS://GitHub.com/inclusionAI/AReaL/blob/main/areal/core/staleness_manager.py在 AReaL 中共涉及到 4 个队列2 个无界队列_pending_inputs 和_pending_results2 个有界队列 input_queue 和 output_queue。共 4 个线程参与分别是主线程、事件循环线程、生产者线程和消费者线程。数据流向是先流入到_pending_inputs 队列这一步由主线程完成在流入 input_queue 队列这一步由生产者线程完成rollout 管理器从 input_queue 中取数据并执行后将结果存入 output_queue这一步由事件循环线程完成最后从 output_queue 放入_pending_results这一步由消费者线程完成。再从_pending_results 中取结果给训练引擎这一步由主线程完成。之所以这么复杂一部分是便于 staleness 进行管理也考虑到实际执行的 rollout 同时处理数据的能力input_queue 容量代表同时 rollout 的数量防止大批量数据同时传递给 rollout 后。另外这种方案也便于下面讨论的 partial rollout 管理。7、只依靠异步训练并不能很好的解决长尾问题带来的资源浪费和效率低下还需要一个技术方案partial rollout这个方案和异步 RL 训练基本上同时出现也是 AReaL 论文中核心创新方案之一目前也是基本上支持异步 RL 训练的框架都已经实现示意图如下。在上图中可以看到当 rollout 产生 1 个 batch 数据这里是 4后训练引擎异步开始训练当训练引擎完成训练时需要将新的模型权重传递给推理引擎但这时推理引擎还在进行推理任务partial rollout 的含义就是对正在 rollout 过程中的任务进行截断保留已经 rollout 完成的那部分数据暂停推理引擎的使用开始从训练 rank 广播新的模型权重给推理 rank 进行模型参数更新这个过程中训练引擎不受影响继续异步训练。当推理引擎完成参数更新后继续对之前截断的任务进行 rollout也就是说这部分任务 rollout 轨迹前部分是旧策略模型生成的后部分是新策略模型生成的。AReaL 中 input_queue 是进行 rollout 的任务当被截断时连带已经生成的轨迹放入_pending_inputs 队列的队头位置。以上是阅读修改RL训练框架代码后获得的一些启发下面是一些关于RL训练的思考1、老生常谈的RL算法问题当前的LLM的RL算法习惯分为两类序列级奖励算法和token级奖励算法前者有GRPO、DAPO、REINFORCE等算法后者有Decoupled PPO、REINFORCE等。这里不一一介绍根本上都是PPO算法的变体。区别就是对整个轨迹每个token相同的奖励值还是不同的奖励值。LLM是以token为动作粒度进行优化的如果将奖励放在序列维度肯定无法做到精细训练而放到token粒度又很难原因在于很难有一个客观合理的奖励方案去对序列里每个token做奖励反向KL散度的模型蒸馏是一个不错的方案但教师模型很难获取token粒度太小了。实际上我们llm实际执行的动作粒度是多个token组成具体是由业务环境决定的所以如果想做到领域RL最优是否也需要在业务场景的动作粒度上进行奖励才好这一点存疑等待验证。另外RL训练是否也需要分阶段训练比较好比如一开始进行序列级RL训练先不管中间过程是否摆烂保证最后结果的正确性。再进行细粒度的RL训练无论业务动作粒度还是token粒度去调优推理的中间过程还是直接同时关注序列和每个token奖励更好同样等待验证。2、RL奖励和环境就像karpathy说的现在RL成功与否的关键在于环境和奖励环境不说了就是纯工程优化的问题奖励的设置是行业研究的热门主流方案还是llm as judge或者agent as judge只不过用了很多提示词trick。比如在提示词中划分出严格的打分维度让多个闭源模型组成评审团不让llm或者agent打分而是排序等又感觉回到了rlhf时代。但根本上仍无法避免reward hacking的问题为每个任务设置校验规则又无法scaling。只能靠时间去慢慢磨慢慢的把数据收集好训练单独奖励模型或者一点点的做校验规则。最后总结一下这几个RL框架说实话verl和AReaL代码写的很工程化但读起来是真费劲封装太多上手难度比较高。相比slime代码很简洁流程明确我一开始奔着朱子霖大佬去看到slime奈何当时slime刚开始适配FSDPmegatron又不支持vl模型我是vl模型多轮训练的场景更倾向于异步RL训练需要尽快实现一个demo只是粗读了slime代码感觉异步训练这块写的还不是很成熟才跳到verl。但verl的rollout流程太僵化不适用于我的环境因为在环境工具调用前我需要从数据中获取一些状态内容发送给环境来让环境初始化侵入式修改verl又带来额外工作量因此又转向AReaL。AReaL代码是真的难读一个函数高达5-6次的调用但不得不佩服代码质量是真的高。想简单入门的推荐看RL2https://github.com/ChenmienTan/RL2代码逻辑简单很容易理清基本逻辑值得阅读。引用链接[1]DataProto :HTTPS://GitHub.com/volcengine/verl/blob/main/verl/protocol.py#L329[2]前者的实现:https://GitHub.com/volcengine/verl/blob/main/verl/experimental/agent_loop/agent_loop.py[3]使用的后者:https://GitHub.com/volcengine/verl/recipe/fully_async_policy[4]single_controller:HTTPS://GitHub.com/volcengine/verl/blob/main/verl/single_controller/ray/base.py#L328[5]The AI workspace that works for you:https://fengyao.notion.site/off-policy-rl[6]agent 多轮训练代码逻辑:HTTPS://GitHub.com/volcengine/verl/blob/main/verl/experimental/agent_loop/tool_agent_loop.py#L120[7]self._call_tool:HTTPS://GitHub.com/volcengine/verl/blob/main/verl/experimental/agent_loop/tool_agent_loop.py#L433[8]rollout:HTTPS://GitHub.com/THUDM/slime/blob/main/slime/ray/rollout.py#L154[9]自定义 workflow:HTTPS://GitHub.com/inclusionAI/AReaL/blob/main/areal/api/workflow_api.py#L12[10]recipe:HTTPS://GitHub.com/szrlee/verl/tree/yingru/rollout_correction/recipe/fully_async_policy大模型之心Tech知识星球交流社区我们创建了一个全新的学习社区 ——“大模型之心Tech”知识星球希望能够帮你把复杂的东西拆开揉碎整合帮你快速打通从0到1的技术路径。星球内容包含每日大模型相关论文/技术报告更新、分类汇总开源repo、大模型预训练、后训练、知识蒸馏、量化、推理模型、MoE、强化学习、RAG、提示工程等多个版块、科研/办公助手、AI创作工具/产品测评、升学求职岗位推荐等等。星球成员平均每天花费不到0.3元加入后3天内不满意可随时退款欢迎扫码加入一起学习一起卷