简介(未完成)
rlhf 和 llm-reasoning 这两个方向有什么区别吗?prompt 的难度和 response 的长度。以往我们使用 rlhf 的场景主要是:安全问题、诗歌创作修复韵脚问题、简单的代码数学问题等,往往都是几百个 token 就搞定的任务。现在不一样了,模型的一条回复就达到了上万个 token,这会让显存压力和解码时长陡增。作为应对,vllm 或 sglang 已经成为 rlhf 框架的标配。最初我也认为 grpo 省掉 critic_model 这一点并不关键,现在看来我还是只考虑了算法和数据的视角,并没有充分理解到额外维护一个和 actor_model 相同规模的 critic_model,对训练框架的稳定性有多大的挑战。当模型 size 和 response_len 逐渐增大,“训练效率和预防训练过程中莫名其妙的 OOM ”就是复现 r1 工作中最大的难点(对,就是莫名其妙,在程序断了之前,你不会知道明明限制了最大 response_len,为啥它还会 OOM)。
理念
豆包大模型团队发布全新 RLHF 框架,现已开源! 待细读。
在深度学习中,数据流(DataFlow)是一种重要的计算模式抽象,用于表示数据经过一系列复杂计算后实现特定功能。神经网络的计算就是典型的 DataFlow ,可以用计算图(Computational Graph)来描述,其中节点代表计算操作,边表示数据依赖。大模型 RL 的计算流程比传统神经网络更为复杂。在 RLHF 中,需要同时训练多个模型,如 Actor 、Critic 、参考策略(Reference Policy)和奖励模型(Reward Model),并在它们之间传递大量数据。这些模型涉及不同的计算类型(前向反向传播、优化器更新、自回归生成等),可能采用不同的并行策略。传统的分布式 RL 通常假设模型可在单个 GPU 上训练,或使用数据并行方式,将控制流和计算流合并在同一进程中。这在处理小规模模型时效果良好,但面对大模型,训练需要复杂的多维并行,涉及大量分布式计算,传统方法难以应对。
大模型 RL 本质上是一个二维的 DataFlow 问题:high-level 的控制流(描述 RL 算法的流程)+ low-level 的计算流(描述分布式神经网络计算)。近期开源的 RLHF 框架,如 DeepSpeed-Chat、OpenRLHF采用了统一的多控制器(Multi-Controller)架构。各计算节点独立管理计算和通信,降低了控制调度的开销。然而,控制流和计算流高度耦合,当设计新的 RL 算法,组合相同的计算流和不同的控制流时,需要重写计算流代码,修改所有相关模型,增加了开发难度。与此前框架不同,HybridFlow 采用了混合编程模型,控制流由单控制器(Single-Controller)管理,具有全局视图,实现新的控制流简单快捷,计算流由多控制器(Multi-Controller)负责,保证了计算的高效执行,并且可以在不同的控制流中复用。