Back to News

Meshy: SPMD-style RL training framework without central orchestrator

#rl#training-framework#spmd#distributed-systems

A technical blog post introduces Meshy, an SPMD-style reinforcement learning training framework that models inference, training, rollout, and teacher roles as independent services, eliminating the need for a central orchestrator like Ray. Data flows through a unified TransferQueue, and topology is derived locally at startup, supporting fully asynchronous training while remaining compatible with synchronous training. The framework aims to reduce RPC calls, simplify debugging, and improve performance compared to single-controller designs.

Coverage timeline

  1. 机器之心机器之心

    在过去的几年里,LLM RL 系统的工作负载发生了巨大的变化。早期的 RLHF 围绕同步训练展开:模型按固定顺序进行生成、打分和训练,每个阶段之间有着明确的同步边界。如今,系统还需要处理异步生成、持续训练、多轮 Agent 以及与外部环境的交互 —— 那些在同步执行中原本隐含的状态、版本和故障边界,现在都必须显式地进行管理。 以 verl [1] 为典型代表的 Single-Controller 架构,用顺序程序表达异构的分布式计算,有效解决了同步 RLHF 时代最重要的编排问题。但一旦执行不再严格同步、任务开始跨越多轮训练,Single-Controller 就会逐渐从简化系统的抽象,变成数据传输和任务调度的阻碍。 越来越多的系统正在把通用的分布式编排框架从核心执行引擎的默认依赖中剥离,类似的解耦也发生在推理基础设施中。vLLM 在 V1 引擎中为多机张量并行和流水线并行提供了不依赖 Ray 的原生执行路径:各节点分别启动 vLLM 进程,由 PyTorch torch.distributed 建立跨节点进程组。 Meshy 正是在这一背景下提出的:我们将 Inference、Training、Rollout 和 Teacher 等角色建模为独立服务,不再将分布式编排框架作为 RL 系统的中心。所有样本数据通过统一的 TransferQueue [4] 数据面在服务之间流动,控制流程由数据来驱动,拓扑则由各进程在启动时在本地按相同配方推导,因此使得 RL 的流程更接近预训练框架常用的 SPMD 设计。 Meshy 结构天然支持全异步训练,同时兼容传统的同步训练。相比 Single Controller 设计,Meshy 避免了诸多的 RPC 调用,摆脱了沉重的分布式框架 Ray,在故障排查、性能、持续集成和代码简洁度上,都具有较大的优势。 blog:https://maydomain.notion.site/meshy-blog-zh Github: https://github.com/OpenBMB/Meshy 背景 2.1 经典 RLHF 流水线 以 PPO 为例,一轮传统的 RLHF 训练大致如下: Prompts | v Actor Rollout ──> Reference / Reward / Critic Forward | v Advantage