先说个真实场景。两年前我接手一个 PPO 项目单机调通只花了半天但把它搬到 8 台机器上活活折腾了两周。不是模型复杂也不是环境卡人而是采样、训练、评估这几个模块之间的数据流动硬生生把代码搅成一锅粥。那次之后我一直在想一个问题RL 的分布式框架为什么不能像监督学习那样大家都跑同一份代码数据自动切分剩下的事全交给底层调度后来我们团队自己动手做了一个叫 Meshy 的 RL 训练框架核心思路就是标题里这八个字角色驱动、SPMD 范式。这篇文章想把它的设计逻辑和落地经验摊开讲清楚。如果你是做 RL 算法的或者正在被分布式训练折腾得睡不着觉又或者只是好奇 SPMD 这套东西在强化学习里能怎么用这篇应该能给你一些不一样的参考。1. 从见鬼的分布式 RL说起为什么跑一个 PPO 比跑一个 GPT 还让人头疼1.1 监督学习那种数据并行在 RL 里根本不够用在开始聊 SPMD 之前得先把这个痛点说透。我们训练一个大模型做监督学习时数据流是非常规整的喂进去一批样本算 loss回传梯度更新参数。不管是数据并行还是张量并行大家都是在切一个静态的数据块谁先谁后不关键算完聚合一下就行。DDP 里一个 all-reduce 就能收工。RL 完全不是这个形状。以 PPO 为例一个最简单的训练循环里至少有五件相互依赖的事在环境里跑策略采集 rollout得到观察、动作、奖励、状态序列把采集结果塞进经验缓冲区按 batch 抽样用采样到的数据做前向计算优势估计和策略损失反向传播更新 actor 和 critic 网络定期评估当前策略的真实水平判断是否收敛这五个环环相扣而且每件事的耗时完全不可预估。环境快的可能 1 毫秒出一帧环境慢的可能要十几秒。如果你做的是多智能体对抗不同智能体的节奏还会互相影响。如果只是在一个进程里顺序执行代码很简单但效率低到没法看。所以 RL 训练天然的出路就是分布式把采样的活交给一堆 worker 去跑把学习的活交给 learner 去跑。可问题来了——怎么让它们协作1.2 过去十年我们一直在给 RL 造角色分工的轮子RL 的分布式框架不是今天才有。我简单过一遍主流方案的演进你会发现它们都指向同一个方向把不同分工的进程做成独立角色再祈祷它们之间的通信别出乱子。参数服务器PS时代pserver 持有全局参数一堆 worker 从 pserver 拉参数跑一段 rollout再把梯度推回 pserver。优点是什么任务都能套缺点是 pserver 是单点且 worker 之间容易因为参数不同步产生严重的数据偏移。Ape-X / R2D2 一票 off-policy 方案把采样器和学习者彻底分离中间靠一个巨大的 replay buffer 衔接。采样器只管狂奔学习者从 buffer 里捞数据训练。这套在 DQN 系算法上表现惊人但对 on-policy 算法就白搭。IMPALA / Seed RL 这类 on-policy 大杀器actor 集群负责采集把 trajectory 异步 push 给 learnerlearner 侧用 V-trace 修正 off-policy 的影响。构造上已经非常接近角色驱动了——actor、learner、queue 各司其职。每一个方案都在解决一个共同的问题如何在复杂任务分解后保持组件间优雅的通信和资源共享。但它们的共同缺点也很明显角色是写死在代码结构里的。如果你想加一个 evaluator 角色、或者给 learner 侧增加第二块梯度同步组你需要去改造通信层、改造数据结构、改造部署脚本。所有通信路径都是显式的和业务逻辑搅在一起。1.3 为什么我一直觉得这个方向不对回顾这些框架你会发现它们本质上都是手动拼装集群程序员负责决定哪个进程跑什么负责决定它们之间用什么端口、什么协议、什么队列来通信甚至要手工管理故障恢复。当训练规模到了几十上百个节点这套手工逻辑的复杂度会直接爆炸。而讽刺的是我们训练 Transformer 的时候根本不需要思考这些问题。不管是 JAX 还是 PyTorch写出一个模型定义一个分片策略框架自动把模型并行、数据并行、流水并行安排得明明白白。模型规模可以轻松从 7B 长到 70B训练代码几乎不用动。这种程序只管逻辑并行交给框架的模式在机器学习领域有一个专门的名字就是 SPMD。我们当时就萌生了一个想法能不能把已经在大模型训练领域被证明好用的 SPMD 哲学搬到 RL 训练里去2. SPMD 范式到底干了什么所有人跑同一份代码数据自动分片2.1 用乐队总谱来理解 SPMD必须先解释清楚 SPMD 是什么。SPMD全称 Single Program Multiple Data单程序多数据。这个概念听起来很高大上其实特别朴素。我一般用一个乐队演出的类比来讲整个乐团拿到的是同一份总谱但小提琴手只盯着自己的声部铜管组只盯着自己的段落。大家演奏的是同一首曲子但各自只处理自己分到的那部分数据。指挥负责让大家对齐节奏谁该进、谁该停、谁该合奏都在总谱里写清楚了。放到计算场景里SPMD 就是说你在所有设备上部署完全相同的程序每台设备只处理自己负责的那块数据。设备之间通过集合通信原语all-gather、all-reduce、send/recv 这一套同步需要同步的信息。程序的执行流程是统一的数据却是分片的。这跟传统分布式最大的区别在于没有主进程和从进程的区分没有谁专门负责协调别人。每个进程都知道自己在整个集群里的 rank也大概知道别人在干什么大家都遵循同一套规则。2.2 监督学习里的 SPMD 为什么能成功SPMD 最成功的实践是在大模型训练领域尤其是 GSPMD 那一挂的工作。你写一段模型代码用 sharding 注解告诉编译器哪些张量切成几份、放在哪些设备上编译器会帮你把计算图自动拆解插入必要的通信操作最后产出一份适合多设备执行的计算图。它的核心优势有三个第一编程体验极好。写代码的人不需要关心数据是怎么在设备间流转的也不需要手工写一堆 all-reduce、batch-send 这种底层逻辑。逻辑上还是一个程序只是数据被切开了。第二天然适合弹性扩缩容。设备数量从 4 变成 8只要把分片维度改一下程序还是同一份剩下的交给规划器重新安排。第三可解释性强。因为所有设备执行的是同一个程序出问题的时候可以从 rank 0 开始逐行分析非常容易复现和调试。2.3 但 RL 的情况远比切张量复杂那时候我最大的困惑也是在这里RL 不是单纯的多卡矩阵乘法RL 是一个包含环境交互、数据生成、模型更新、评估决策的完整闭环。环境交互这一步天生是异质的——每个环境实例跑在不同的 CPU 线程、不同的 GPU 设备甚至不同的机器上返回数据的形状、时间、数量全都不一样。这些交互结果根本没法提前分片。而且 RL 训练中存在明显的角色功能差异actor 角色需要吞吐量极高的前向推理能力learner 角色需要吞吐量极高的大规模参数更新能力evaluator 角色则需要比较稳定的推理和指标统计。如果你硬要用同一个程序把所有角色都套进去那等于逼着 learner 去跑网络前向逼着 actor 去做梯度同步——这显然不合理。所以问题变成了能不能设计一个框架它保留 SPMD单一程序、自动分片的舒服体验同时又允许用户声明性地区分不同角色的行为这正是 Meshy 想做的事情。2.4 把角色做成 SPMD 里的第一性原则Meshy 的做法是角色不是一个会被硬编码进通信层的东西角色就是用户程序本身的一个抽象接口。你写一个角色它里面可以包含任意逻辑——可以是采样的逻辑可以是训练的逻辑也可以是评估的逻辑。每个角色内部遵循 SPMD 规则不管有多少设备在执行这个角色它们跑的是同一份代码。这样的话actor 集群就是在 SPMD 模式下运行采样程序learner 集群是在 SPMD 模式下运行训练程序evaluator 集群是在 SPMD 模式下运行评估程序。角色之间不再依赖手工配置的地址和端口硬编码通信而是通过框架统一提供的数据通道来进行数据交换。这听起来简单实现起来却是一个分水岭。我们团队在砍掉第三版设计稿之后才找到最舒服的抽象方式。3. 角色驱动的真正含义把采样器、学习器、评估器都变成第一公民3.1 传统架构里角色是隐式的在动手设计 Meshy 之前我们仔细复盘了以前写的训练脚本发现了一个规律绝大多数 RL 代码里角色其实是隐式的。什么意思就是你的主训练循环里既包含着 rollout 的采集逻辑也包含着模型更新的逻辑可能还夹杂着每隔多少步打印一次统计信息、每隔多少步保存一次 checkpoint 的逻辑。你嘴上说 actor 和 learner 分离但代码层面上它们全挤在一个 Python 进程里。后来你把它拆成了两个脚本train.py 和 replay.py可它们之间的通信协议完全靠你自己设计——共享内存RedisgRPC文件这些方案都能跑但致命的弱点是你再想加一个新的角色时得重新设计一整套通信协议。如果有一天你发现采样的吞吐不够想从 32 个 actor 扩到 128 个你得去改 actor 的服务发现逻辑改 learner 的数据接收窗口改部署脚本里的端口范围。这哪里是做研究这简直是运维事故预演。3.2 Meshy 里角色是一等抽象一个角色 一段逻辑 一组资源声明Meshy 把角色这个概念提升到了一等公民的地位。在我们最终的抽象设计里定义一个角色所需的最小信息其实只有三样第一角色自己的执行逻辑。一个 Python 函数或者一个类描述这个角色做什么事。它是一个完整的、符合 SPMD 语义的程序段。第二这个角色需要的资源。需要多少设备、每个设备多少显存、是否需要 GPU、是否需要大内存、是否需要独立的 CPU 环境池。第三这个角色要发布和订阅的数据模式。也就是说它产生什么样的数据、消费什么样的数据。比如 actor 角色会发布 trajectorieslearner 角色会订阅 trajectories 并发布新的模型权重快照。这三样东西加在一起构成一个完整的角色描述。框架在拿到这份描述之后自动完成设备资源分配、通信管道建立、数据流连接这些底层活。用户完全不用关心某个 actor 在哪个节点上也不关心 learner 和 actor 之间走的是 NCCL 还是 gRPC。上面说的这个设计模式非常重要因为它把 RL 分布式训练从写一套分布式系统的工程变成了描述你的计算图让框架来执行。3.3 角色与角色之间只交换数据契约不感知彼此存在这里有一点很难做好但一旦做到了整个体验会起飞角色之间不应该互相感知对方的存在。传统架构里actor 要发数据给 learner它心里必须明确知道我在给 learner 发数据。一旦 learner 扩容到 4 个 rankactor 侧的发送逻辑就必须跟着改。这是个典型的耦合问题。Meshy 让角色之间解耦的方式是引入数据契约的概念。actor 不用知道它发的 trajectories 被谁消费它只需要往一个名为 trajectory_stream 的逻辑通道里写数据就行。learner 也不用关心有 32 个 actor 还是 128 个 actor 在往这个通道里写它只需要按契约从这个通道里读数据。框架会负责适配下游所有角色的消费速度和上游的产生速度自动平衡这些差异。你品一下这里面的味道这其实跟消息队列MQ的设计哲学很像。但区别在于MQ 往往丢掉了高性能背景下的细粒度控制和分片感知而 Meshy 里这个数据通道是可以感知底层设备拓扑的——它能知道哪些数据应该留在同一台机器的显存里直接传递哪些需要跨节点传输。这比丢进 Redis 让 learner 自己捞要高好几个数量级。3.4 角色驱动带来的实际红利扩采样集群变成一行配置角色驱动带来的最实际的好处在扩容场景里体现得最明显。以前我们给实验加采样资源流程是申请机器、配好 Python 环境、写好 actor 启动脚本、在 learner 侧加白名单 IP、重启 learner 的接收队列、检查模型权重文件是否有条件同步……整套下来至少两小时。在 Meshy 里扩容 actor 集群就是改一个数字那么简单。你声明 actor 角色需要 128 个设备框架就会自动寻找空闲节点拉起 128 份 actor 程序注册到对应的数据契约里完成和 learner 的连接。整个过程里不需要改 learner 的任何代码不需要改 actor 的任何逻辑因为 actor 和 learner 都只是角色描述的一个实例。我们后来在 50 个节点规模上做了一次实测把一个正在跑的大规模 off-policy RL 任务的采样集群从 64 个 actor 动态扩张到 192 个整个过程花了不到 3 分钟采样吞吐直接翻了接近 2.5 倍训练稳定没有中断。这就是角色驱动的力量它把分布式系统的复杂性藏在了框架内部让用户重新回到算法逻辑本身。4. Meshy 怎么把 SPMD 和角色驱动揉在一起工程实现与踩坑记录4.1 统一设备抽象每个角色内部都是 SPMD角色之间由数据平面拼接现在问题来了SPMD 强调单一程序角色驱动强调多角色分工。这俩表面上是矛盾的方向Meshy 是怎么揉在一起的答案是分层。下层是设备抽象层上层是数据平面层。先看设备抽象层。Meshy 内部遵循 GSPMD 的分片理念所有参与方无论角色所处的设备都被抽象成一个多维度逻辑设备网格。角色定义中可以声明自己需要的是这个网格中的一个子块或全部。假设你有一台 8 卡机器你可以让 learner 角色占满 8 张卡也可以把它切成两半——前 4 张卡跑 learner后 4 张卡跑 role-buffer 的预取。角色内部的一切并行策略都由 SPMD 编译器自动决策。你写一个模型更新函数在 learner 角色里声明模型参数按数据并行方式切分到 4 个设备框架自动插入梯度 all-reduce。你写一个策略前向函数在 actor 角色里声明批量维度被切到 8 个设备上框架自动把 batch 分片并插入推理结果的 all-gather。数据平面层负责角色之间的异步数据传输。每个角色都可以发布一个数据流也可以订阅其他角色发布的数据流。框架在构建时会根据物理负载自动决定每条数据流的传输方式同一节点内的用共享内存或 NVLink跨节点的用 RDMA 或 TCP 封装的通信库。角色不需要关心流底层的传输方式。4.2 值得肯定的工程细节规划器如何避免跨角色循环死锁一个我踩了很久才解决的问题是角色间数据流可能形成环形依赖时SPMD 的集合通信会导致隐藏死锁。举个例子actor 产生数据给 learnerlearner 训练完成后把新权重广播回 actor。看起来是一条直线。但如果你在角色之间设置了多个数据流比如 actor 每次还会发送一个当前策略的统计摘要给 evaluatorevaluator 又把评估结果回传给 learner同时 learner 又把定时更新通知回传给 actor……这时整个数据依赖已经变成了一张环状图。在传统框架里这种环上如果某两个节点执行了不同步的集合通信整个集群会卡死而且不会报错像一台突然熄火的发动机进程全活着job 就是不动。Meshy 的解决办法是在 Commit 阶段做一次数据依赖分析。每个角色在启动前会把自己的数据订阅关系上报规划器会做一次整体 DAG 检查一旦发现环状依赖直接拒绝启动并且在日志里把环路数据流完整打印出来。这个设计在开发阶段帮我们避免了无数个小时的干瞪眼。有一次一个新同学提交代码写到一半把两个角色的订阅关系写反了跑起来之后数据根本不流动他抓了半天头。最后看了一眼启动日志上面明确写着 detected circular dependency between stream A and stream B一秒钟就定位了问题。4.3 实测性能对比SPMD 范式到底快在哪里说点真实的数据。我们在内部任务上做了一组对比测试同一个 PPO 任务使用同样节点和 GPU 数量一边跑基于传统 actor-learner 架构改造的baseline用 gRPC 传数据一边跑 Meshy。对比项传统 actor-learner 架构Meshy角色驱动SPMD12 卡采样吞吐帧/秒约 145k约 198klearner 侧数据到达峰值延迟平均约 328ms平均约 41ms框架侧 CPU 占用占单核百分比约 470%约 210%新增 32 个 actor 的耗时需要重启 learner约 15 分钟动态注册约 30 秒训练中断概率24 小时出现过 3 次小故障稳态运行无中断这个提升不是某一个大优化带来的而是整个设计范式带来的系统性收益。最核心的差异在于传统架构多了一步数据先出进程、再进进程的序列化和网络传输每一步都有拷贝开销而 Meshy 里如果数据流的上下游恰好被规划器安排在同一台机器的同一块 GPU 上可以直接通过设备内指针传递零拷贝完成。可以说这套架构把用户从手动考虑跨进程数据传输里彻底解放了出来。4.4 避坑指南三个我踩得最惨的坑说过优点也得说说坑。没有框架能让你完全逃避分布式系统的物理规律。这里记录三个我们踩得最深的坑。第一个坑是变量长度数据的切分失衡。RL 采集的轨迹天然变长有的 episode 长有的短。如果把这样一个变长 tensor 按 batch 维度直接分片到多个设备经常会出现某个设备负载特别高、其他设备空转的情况。我们现在会在深渊采集入口做一次按长度的负载均衡再进入 SPMD 切分器效果好很多但偶尔还是需要引入排序预处理来压榨最后 10% 的均衡度。第二个坑是小 batch 场景下通信放大。SPMD 适合大张量因为它把通信藏在计算里。但 RL 里的某些步骤比如单步环境推理batch 极小可能是 4 条轨迹凑一起。这时如果还按 SPMD 规则强制走集合通信通信延迟反而会淹没计算时间。后来我们在框架里增加了数据流粒度感知模块对小数据不做强制分片而是走共享内存直传。这个策略让短序列任务的整体吞吐回升了约 35%。第三个坑是混合角色时的资源抢占。当 actor 和 learner 共享同一个物理节点时如果设备网格划分不当actor 的内存预取和 learner 的显存分配会互相挤压导致整机 OOM。我们现在在角色定义里增加了虚拟内存水位线声明框架会在调度时优先把高内存占用的角色分散到不同的物理节点。这个配置不写小规模测试没问题上到大规模必出事故。4.5 容错恢复不必整个任务重来RL 训练动不动就是几十个小时最怕中途某个节点硬件坏了或者某个 actor 进程被 OOM killer 杀掉。以前这种场景基本等于白跑整个任务从 checkpoint 恢复损失好几个小时。Meshy 的角色驱动 SPMD 组合天然适合做局部容错。当一个 actor 角色实例异常退出时框架能通过心跳机制检测角色缺失然后自动找一个空闲节点重新拉起这个角色并利用 SPMD 的数据分片机制只恢复与该角色相关的数据切片。learner 不需要感知整个变化继续训练唯一需要在内存中保留的是最近一段时间的经验缓冲数据这部分可以通过角色数据契约做定期快照。我们在 128 actor 规模下做过 20 次随机 kill -9 测试平均恢复时间 40 秒左右训练最多丢失不到 2 分钟的采样数据。这对于长周期 RL 任务来说体感上已经比以前挂一次重来一发好了太多。5. 迁移建议与个人体会什么项目适合上 Meshy 这套东西5.1 三个适合上车的典型场景如果你手里有项目正卡在下面这三种情况我会强烈建议你认真评估角色驱动 SPMD 这套方案。第一种on-policy 算法的大规模扩展项目。PPO、IMPALA、类似方案actor 集群一扩再扩learner 侧频繁出现数据堆积需要精细的背压和资源调度。角色驱动带来的采样能力和训练能力独立扩缩容是致命的竞争力。第二种多智能体 RL 项目。多智能体任务天然需要多种角色并存有的智能体负责探索有的负责防守它们的策略更新频率、观察空间各不相同。把每个智能体抽象成一个角色各跑各的数据契约框架层自动处理他们之间的消息交互研究效率能提升一大截。第三种团队里有多个算法并行迭代的中台化场景。强烈推荐抽象角色注册中心那一套因为多个项目可以共享同一套环境采集基础设施不同实验只需更改各自的模型更新角色订阅切换实验成本极低。我们内部已经做到了3 分钟切换一个实验配置这在以前是不敢想的。5.2 两个不适合的场景也不是所有任务都适合往 Meshy 上靠。如果你的项目只是单机、单卡模型只有几十兆环境采样也不重那直接写一个单进程训练循环反而是最优解。引入角色抽象只会增加心智负担。还有一种情况是环境交互本身就是完全确定性的、极快的小型任务比如一些 toy 环境每一步只需要微秒级处理时间。这种场景里SPMD 那套设备网格抽象、数据契约规划的开销反而会成为瓶颈。我们统一建议小而快的任务走单进程大而复杂的任务才考虑上框架。5.3 我对角色驱动 SPMD 的真实思考做 Meshy 这一年多最大的收获不是把 RL 训练跑得多快而是重新理解了复杂系统需要什么。RL 训练框架的复杂度主要来自异构性代码要横跨采样、学习、评估三个语义完全不同的领域资源要横跨 CPU、GPU、内存、网络多个维度时间上要横跨秒级交互和小时级训练的尺度。过去我们一直试图用更精细的手工管道来管理这种异构性结果管道本身成了整个系统里最脆弱的环节。角色驱动的做法是承认异构性的存在然后把它装进统一的抽象容器里。每个角色都有明确的职责和资源边界角色之间的通信不依赖彼此存在而是通过数据契约建立弱连接。SPMD 的做法是为每个角色内部的并行提供通用的执行模型不管这个角色是在做推理、采样还是梯度更新它都遵循同一套数据分片、设备协作的规则。把这两者合在一起得到的不是又一个 RL 分布式框架而是一种更自然的心智模型你不需要把 RL 当分布式系统来设计你只需要把自己的算法逻辑分成几个角色剩下的并行、通信、容错全部交给框架处理。如果你现在正准备写下一个 RL 项目的训练框架我的建议很简单别一上来就设计协议、开端口、想消息格式。先把你算法里的角色画清楚再想它们之间交换什么数据然后动手。你会发现很多时候问题没有你想象的那么复杂。
先说个真实场景。两年前我接手一个 PPO 项目单机调通只花了半天但把它搬到 8 台机器上活活折腾了两周。不是模型复杂也不是环境卡人而是采样、训练、评估这几个模块之间的数据流动硬生生把代码搅成一锅粥。那次之后我一直在想一个问题RL 的分布式框架为什么不能像监督学习那样大家都跑同一份代码数据自动切分剩下的事全交给底层调度后来我们团队自己动手做了一个叫 Meshy 的 RL 训练框架核心思路就是标题里这八个字角色驱动、SPMD 范式。这篇文章想把它的设计逻辑和落地经验摊开讲清楚。如果你是做 RL 算法的或者正在被分布式训练折腾得睡不着觉又或者只是好奇 SPMD 这套东西在强化学习里能怎么用这篇应该能给你一些不一样的参考。1. 从见鬼的分布式 RL说起为什么跑一个 PPO 比跑一个 GPT 还让人头疼1.1 监督学习那种数据并行在 RL 里根本不够用在开始聊 SPMD 之前得先把这个痛点说透。我们训练一个大模型做监督学习时数据流是非常规整的喂进去一批样本算 loss回传梯度更新参数。不管是数据并行还是张量并行大家都是在切一个静态的数据块谁先谁后不关键算完聚合一下就行。DDP 里一个 all-reduce 就能收工。RL 完全不是这个形状。以 PPO 为例一个最简单的训练循环里至少有五件相互依赖的事在环境里跑策略采集 rollout得到观察、动作、奖励、状态序列把采集结果塞进经验缓冲区按 batch 抽样用采样到的数据做前向计算优势估计和策略损失反向传播更新 actor 和 critic 网络定期评估当前策略的真实水平判断是否收敛这五个环环相扣而且每件事的耗时完全不可预估。环境快的可能 1 毫秒出一帧环境慢的可能要十几秒。如果你做的是多智能体对抗不同智能体的节奏还会互相影响。如果只是在一个进程里顺序执行代码很简单但效率低到没法看。所以 RL 训练天然的出路就是分布式把采样的活交给一堆 worker 去跑把学习的活交给 learner 去跑。可问题来了——怎么让它们协作1.2 过去十年我们一直在给 RL 造角色分工的轮子RL 的分布式框架不是今天才有。我简单过一遍主流方案的演进你会发现它们都指向同一个方向把不同分工的进程做成独立角色再祈祷它们之间的通信别出乱子。参数服务器PS时代pserver 持有全局参数一堆 worker 从 pserver 拉参数跑一段 rollout再把梯度推回 pserver。优点是什么任务都能套缺点是 pserver 是单点且 worker 之间容易因为参数不同步产生严重的数据偏移。Ape-X / R2D2 一票 off-policy 方案把采样器和学习者彻底分离中间靠一个巨大的 replay buffer 衔接。采样器只管狂奔学习者从 buffer 里捞数据训练。这套在 DQN 系算法上表现惊人但对 on-policy 算法就白搭。IMPALA / Seed RL 这类 on-policy 大杀器actor 集群负责采集把 trajectory 异步 push 给 learnerlearner 侧用 V-trace 修正 off-policy 的影响。构造上已经非常接近角色驱动了——actor、learner、queue 各司其职。每一个方案都在解决一个共同的问题如何在复杂任务分解后保持组件间优雅的通信和资源共享。但它们的共同缺点也很明显角色是写死在代码结构里的。如果你想加一个 evaluator 角色、或者给 learner 侧增加第二块梯度同步组你需要去改造通信层、改造数据结构、改造部署脚本。所有通信路径都是显式的和业务逻辑搅在一起。1.3 为什么我一直觉得这个方向不对回顾这些框架你会发现它们本质上都是手动拼装集群程序员负责决定哪个进程跑什么负责决定它们之间用什么端口、什么协议、什么队列来通信甚至要手工管理故障恢复。当训练规模到了几十上百个节点这套手工逻辑的复杂度会直接爆炸。而讽刺的是我们训练 Transformer 的时候根本不需要思考这些问题。不管是 JAX 还是 PyTorch写出一个模型定义一个分片策略框架自动把模型并行、数据并行、流水并行安排得明明白白。模型规模可以轻松从 7B 长到 70B训练代码几乎不用动。这种程序只管逻辑并行交给框架的模式在机器学习领域有一个专门的名字就是 SPMD。我们当时就萌生了一个想法能不能把已经在大模型训练领域被证明好用的 SPMD 哲学搬到 RL 训练里去2. SPMD 范式到底干了什么所有人跑同一份代码数据自动分片2.1 用乐队总谱来理解 SPMD必须先解释清楚 SPMD 是什么。SPMD全称 Single Program Multiple Data单程序多数据。这个概念听起来很高大上其实特别朴素。我一般用一个乐队演出的类比来讲整个乐团拿到的是同一份总谱但小提琴手只盯着自己的声部铜管组只盯着自己的段落。大家演奏的是同一首曲子但各自只处理自己分到的那部分数据。指挥负责让大家对齐节奏谁该进、谁该停、谁该合奏都在总谱里写清楚了。放到计算场景里SPMD 就是说你在所有设备上部署完全相同的程序每台设备只处理自己负责的那块数据。设备之间通过集合通信原语all-gather、all-reduce、send/recv 这一套同步需要同步的信息。程序的执行流程是统一的数据却是分片的。这跟传统分布式最大的区别在于没有主进程和从进程的区分没有谁专门负责协调别人。每个进程都知道自己在整个集群里的 rank也大概知道别人在干什么大家都遵循同一套规则。2.2 监督学习里的 SPMD 为什么能成功SPMD 最成功的实践是在大模型训练领域尤其是 GSPMD 那一挂的工作。你写一段模型代码用 sharding 注解告诉编译器哪些张量切成几份、放在哪些设备上编译器会帮你把计算图自动拆解插入必要的通信操作最后产出一份适合多设备执行的计算图。它的核心优势有三个第一编程体验极好。写代码的人不需要关心数据是怎么在设备间流转的也不需要手工写一堆 all-reduce、batch-send 这种底层逻辑。逻辑上还是一个程序只是数据被切开了。第二天然适合弹性扩缩容。设备数量从 4 变成 8只要把分片维度改一下程序还是同一份剩下的交给规划器重新安排。第三可解释性强。因为所有设备执行的是同一个程序出问题的时候可以从 rank 0 开始逐行分析非常容易复现和调试。2.3 但 RL 的情况远比切张量复杂那时候我最大的困惑也是在这里RL 不是单纯的多卡矩阵乘法RL 是一个包含环境交互、数据生成、模型更新、评估决策的完整闭环。环境交互这一步天生是异质的——每个环境实例跑在不同的 CPU 线程、不同的 GPU 设备甚至不同的机器上返回数据的形状、时间、数量全都不一样。这些交互结果根本没法提前分片。而且 RL 训练中存在明显的角色功能差异actor 角色需要吞吐量极高的前向推理能力learner 角色需要吞吐量极高的大规模参数更新能力evaluator 角色则需要比较稳定的推理和指标统计。如果你硬要用同一个程序把所有角色都套进去那等于逼着 learner 去跑网络前向逼着 actor 去做梯度同步——这显然不合理。所以问题变成了能不能设计一个框架它保留 SPMD单一程序、自动分片的舒服体验同时又允许用户声明性地区分不同角色的行为这正是 Meshy 想做的事情。2.4 把角色做成 SPMD 里的第一性原则Meshy 的做法是角色不是一个会被硬编码进通信层的东西角色就是用户程序本身的一个抽象接口。你写一个角色它里面可以包含任意逻辑——可以是采样的逻辑可以是训练的逻辑也可以是评估的逻辑。每个角色内部遵循 SPMD 规则不管有多少设备在执行这个角色它们跑的是同一份代码。这样的话actor 集群就是在 SPMD 模式下运行采样程序learner 集群是在 SPMD 模式下运行训练程序evaluator 集群是在 SPMD 模式下运行评估程序。角色之间不再依赖手工配置的地址和端口硬编码通信而是通过框架统一提供的数据通道来进行数据交换。这听起来简单实现起来却是一个分水岭。我们团队在砍掉第三版设计稿之后才找到最舒服的抽象方式。3. 角色驱动的真正含义把采样器、学习器、评估器都变成第一公民3.1 传统架构里角色是隐式的在动手设计 Meshy 之前我们仔细复盘了以前写的训练脚本发现了一个规律绝大多数 RL 代码里角色其实是隐式的。什么意思就是你的主训练循环里既包含着 rollout 的采集逻辑也包含着模型更新的逻辑可能还夹杂着每隔多少步打印一次统计信息、每隔多少步保存一次 checkpoint 的逻辑。你嘴上说 actor 和 learner 分离但代码层面上它们全挤在一个 Python 进程里。后来你把它拆成了两个脚本train.py 和 replay.py可它们之间的通信协议完全靠你自己设计——共享内存RedisgRPC文件这些方案都能跑但致命的弱点是你再想加一个新的角色时得重新设计一整套通信协议。如果有一天你发现采样的吞吐不够想从 32 个 actor 扩到 128 个你得去改 actor 的服务发现逻辑改 learner 的数据接收窗口改部署脚本里的端口范围。这哪里是做研究这简直是运维事故预演。3.2 Meshy 里角色是一等抽象一个角色 一段逻辑 一组资源声明Meshy 把角色这个概念提升到了一等公民的地位。在我们最终的抽象设计里定义一个角色所需的最小信息其实只有三样第一角色自己的执行逻辑。一个 Python 函数或者一个类描述这个角色做什么事。它是一个完整的、符合 SPMD 语义的程序段。第二这个角色需要的资源。需要多少设备、每个设备多少显存、是否需要 GPU、是否需要大内存、是否需要独立的 CPU 环境池。第三这个角色要发布和订阅的数据模式。也就是说它产生什么样的数据、消费什么样的数据。比如 actor 角色会发布 trajectorieslearner 角色会订阅 trajectories 并发布新的模型权重快照。这三样东西加在一起构成一个完整的角色描述。框架在拿到这份描述之后自动完成设备资源分配、通信管道建立、数据流连接这些底层活。用户完全不用关心某个 actor 在哪个节点上也不关心 learner 和 actor 之间走的是 NCCL 还是 gRPC。上面说的这个设计模式非常重要因为它把 RL 分布式训练从写一套分布式系统的工程变成了描述你的计算图让框架来执行。3.3 角色与角色之间只交换数据契约不感知彼此存在这里有一点很难做好但一旦做到了整个体验会起飞角色之间不应该互相感知对方的存在。传统架构里actor 要发数据给 learner它心里必须明确知道我在给 learner 发数据。一旦 learner 扩容到 4 个 rankactor 侧的发送逻辑就必须跟着改。这是个典型的耦合问题。Meshy 让角色之间解耦的方式是引入数据契约的概念。actor 不用知道它发的 trajectories 被谁消费它只需要往一个名为 trajectory_stream 的逻辑通道里写数据就行。learner 也不用关心有 32 个 actor 还是 128 个 actor 在往这个通道里写它只需要按契约从这个通道里读数据。框架会负责适配下游所有角色的消费速度和上游的产生速度自动平衡这些差异。你品一下这里面的味道这其实跟消息队列MQ的设计哲学很像。但区别在于MQ 往往丢掉了高性能背景下的细粒度控制和分片感知而 Meshy 里这个数据通道是可以感知底层设备拓扑的——它能知道哪些数据应该留在同一台机器的显存里直接传递哪些需要跨节点传输。这比丢进 Redis 让 learner 自己捞要高好几个数量级。3.4 角色驱动带来的实际红利扩采样集群变成一行配置角色驱动带来的最实际的好处在扩容场景里体现得最明显。以前我们给实验加采样资源流程是申请机器、配好 Python 环境、写好 actor 启动脚本、在 learner 侧加白名单 IP、重启 learner 的接收队列、检查模型权重文件是否有条件同步……整套下来至少两小时。在 Meshy 里扩容 actor 集群就是改一个数字那么简单。你声明 actor 角色需要 128 个设备框架就会自动寻找空闲节点拉起 128 份 actor 程序注册到对应的数据契约里完成和 learner 的连接。整个过程里不需要改 learner 的任何代码不需要改 actor 的任何逻辑因为 actor 和 learner 都只是角色描述的一个实例。我们后来在 50 个节点规模上做了一次实测把一个正在跑的大规模 off-policy RL 任务的采样集群从 64 个 actor 动态扩张到 192 个整个过程花了不到 3 分钟采样吞吐直接翻了接近 2.5 倍训练稳定没有中断。这就是角色驱动的力量它把分布式系统的复杂性藏在了框架内部让用户重新回到算法逻辑本身。4. Meshy 怎么把 SPMD 和角色驱动揉在一起工程实现与踩坑记录4.1 统一设备抽象每个角色内部都是 SPMD角色之间由数据平面拼接现在问题来了SPMD 强调单一程序角色驱动强调多角色分工。这俩表面上是矛盾的方向Meshy 是怎么揉在一起的答案是分层。下层是设备抽象层上层是数据平面层。先看设备抽象层。Meshy 内部遵循 GSPMD 的分片理念所有参与方无论角色所处的设备都被抽象成一个多维度逻辑设备网格。角色定义中可以声明自己需要的是这个网格中的一个子块或全部。假设你有一台 8 卡机器你可以让 learner 角色占满 8 张卡也可以把它切成两半——前 4 张卡跑 learner后 4 张卡跑 role-buffer 的预取。角色内部的一切并行策略都由 SPMD 编译器自动决策。你写一个模型更新函数在 learner 角色里声明模型参数按数据并行方式切分到 4 个设备框架自动插入梯度 all-reduce。你写一个策略前向函数在 actor 角色里声明批量维度被切到 8 个设备上框架自动把 batch 分片并插入推理结果的 all-gather。数据平面层负责角色之间的异步数据传输。每个角色都可以发布一个数据流也可以订阅其他角色发布的数据流。框架在构建时会根据物理负载自动决定每条数据流的传输方式同一节点内的用共享内存或 NVLink跨节点的用 RDMA 或 TCP 封装的通信库。角色不需要关心流底层的传输方式。4.2 值得肯定的工程细节规划器如何避免跨角色循环死锁一个我踩了很久才解决的问题是角色间数据流可能形成环形依赖时SPMD 的集合通信会导致隐藏死锁。举个例子actor 产生数据给 learnerlearner 训练完成后把新权重广播回 actor。看起来是一条直线。但如果你在角色之间设置了多个数据流比如 actor 每次还会发送一个当前策略的统计摘要给 evaluatorevaluator 又把评估结果回传给 learner同时 learner 又把定时更新通知回传给 actor……这时整个数据依赖已经变成了一张环状图。在传统框架里这种环上如果某两个节点执行了不同步的集合通信整个集群会卡死而且不会报错像一台突然熄火的发动机进程全活着job 就是不动。Meshy 的解决办法是在 Commit 阶段做一次数据依赖分析。每个角色在启动前会把自己的数据订阅关系上报规划器会做一次整体 DAG 检查一旦发现环状依赖直接拒绝启动并且在日志里把环路数据流完整打印出来。这个设计在开发阶段帮我们避免了无数个小时的干瞪眼。有一次一个新同学提交代码写到一半把两个角色的订阅关系写反了跑起来之后数据根本不流动他抓了半天头。最后看了一眼启动日志上面明确写着 detected circular dependency between stream A and stream B一秒钟就定位了问题。4.3 实测性能对比SPMD 范式到底快在哪里说点真实的数据。我们在内部任务上做了一组对比测试同一个 PPO 任务使用同样节点和 GPU 数量一边跑基于传统 actor-learner 架构改造的baseline用 gRPC 传数据一边跑 Meshy。对比项传统 actor-learner 架构Meshy角色驱动SPMD12 卡采样吞吐帧/秒约 145k约 198klearner 侧数据到达峰值延迟平均约 328ms平均约 41ms框架侧 CPU 占用占单核百分比约 470%约 210%新增 32 个 actor 的耗时需要重启 learner约 15 分钟动态注册约 30 秒训练中断概率24 小时出现过 3 次小故障稳态运行无中断这个提升不是某一个大优化带来的而是整个设计范式带来的系统性收益。最核心的差异在于传统架构多了一步数据先出进程、再进进程的序列化和网络传输每一步都有拷贝开销而 Meshy 里如果数据流的上下游恰好被规划器安排在同一台机器的同一块 GPU 上可以直接通过设备内指针传递零拷贝完成。可以说这套架构把用户从手动考虑跨进程数据传输里彻底解放了出来。4.4 避坑指南三个我踩得最惨的坑说过优点也得说说坑。没有框架能让你完全逃避分布式系统的物理规律。这里记录三个我们踩得最深的坑。第一个坑是变量长度数据的切分失衡。RL 采集的轨迹天然变长有的 episode 长有的短。如果把这样一个变长 tensor 按 batch 维度直接分片到多个设备经常会出现某个设备负载特别高、其他设备空转的情况。我们现在会在深渊采集入口做一次按长度的负载均衡再进入 SPMD 切分器效果好很多但偶尔还是需要引入排序预处理来压榨最后 10% 的均衡度。第二个坑是小 batch 场景下通信放大。SPMD 适合大张量因为它把通信藏在计算里。但 RL 里的某些步骤比如单步环境推理batch 极小可能是 4 条轨迹凑一起。这时如果还按 SPMD 规则强制走集合通信通信延迟反而会淹没计算时间。后来我们在框架里增加了数据流粒度感知模块对小数据不做强制分片而是走共享内存直传。这个策略让短序列任务的整体吞吐回升了约 35%。第三个坑是混合角色时的资源抢占。当 actor 和 learner 共享同一个物理节点时如果设备网格划分不当actor 的内存预取和 learner 的显存分配会互相挤压导致整机 OOM。我们现在在角色定义里增加了虚拟内存水位线声明框架会在调度时优先把高内存占用的角色分散到不同的物理节点。这个配置不写小规模测试没问题上到大规模必出事故。4.5 容错恢复不必整个任务重来RL 训练动不动就是几十个小时最怕中途某个节点硬件坏了或者某个 actor 进程被 OOM killer 杀掉。以前这种场景基本等于白跑整个任务从 checkpoint 恢复损失好几个小时。Meshy 的角色驱动 SPMD 组合天然适合做局部容错。当一个 actor 角色实例异常退出时框架能通过心跳机制检测角色缺失然后自动找一个空闲节点重新拉起这个角色并利用 SPMD 的数据分片机制只恢复与该角色相关的数据切片。learner 不需要感知整个变化继续训练唯一需要在内存中保留的是最近一段时间的经验缓冲数据这部分可以通过角色数据契约做定期快照。我们在 128 actor 规模下做过 20 次随机 kill -9 测试平均恢复时间 40 秒左右训练最多丢失不到 2 分钟的采样数据。这对于长周期 RL 任务来说体感上已经比以前挂一次重来一发好了太多。5. 迁移建议与个人体会什么项目适合上 Meshy 这套东西5.1 三个适合上车的典型场景如果你手里有项目正卡在下面这三种情况我会强烈建议你认真评估角色驱动 SPMD 这套方案。第一种on-policy 算法的大规模扩展项目。PPO、IMPALA、类似方案actor 集群一扩再扩learner 侧频繁出现数据堆积需要精细的背压和资源调度。角色驱动带来的采样能力和训练能力独立扩缩容是致命的竞争力。第二种多智能体 RL 项目。多智能体任务天然需要多种角色并存有的智能体负责探索有的负责防守它们的策略更新频率、观察空间各不相同。把每个智能体抽象成一个角色各跑各的数据契约框架层自动处理他们之间的消息交互研究效率能提升一大截。第三种团队里有多个算法并行迭代的中台化场景。强烈推荐抽象角色注册中心那一套因为多个项目可以共享同一套环境采集基础设施不同实验只需更改各自的模型更新角色订阅切换实验成本极低。我们内部已经做到了3 分钟切换一个实验配置这在以前是不敢想的。5.2 两个不适合的场景也不是所有任务都适合往 Meshy 上靠。如果你的项目只是单机、单卡模型只有几十兆环境采样也不重那直接写一个单进程训练循环反而是最优解。引入角色抽象只会增加心智负担。还有一种情况是环境交互本身就是完全确定性的、极快的小型任务比如一些 toy 环境每一步只需要微秒级处理时间。这种场景里SPMD 那套设备网格抽象、数据契约规划的开销反而会成为瓶颈。我们统一建议小而快的任务走单进程大而复杂的任务才考虑上框架。5.3 我对角色驱动 SPMD 的真实思考做 Meshy 这一年多最大的收获不是把 RL 训练跑得多快而是重新理解了复杂系统需要什么。RL 训练框架的复杂度主要来自异构性代码要横跨采样、学习、评估三个语义完全不同的领域资源要横跨 CPU、GPU、内存、网络多个维度时间上要横跨秒级交互和小时级训练的尺度。过去我们一直试图用更精细的手工管道来管理这种异构性结果管道本身成了整个系统里最脆弱的环节。角色驱动的做法是承认异构性的存在然后把它装进统一的抽象容器里。每个角色都有明确的职责和资源边界角色之间的通信不依赖彼此存在而是通过数据契约建立弱连接。SPMD 的做法是为每个角色内部的并行提供通用的执行模型不管这个角色是在做推理、采样还是梯度更新它都遵循同一套数据分片、设备协作的规则。把这两者合在一起得到的不是又一个 RL 分布式框架而是一种更自然的心智模型你不需要把 RL 当分布式系统来设计你只需要把自己的算法逻辑分成几个角色剩下的并行、通信、容错全部交给框架处理。如果你现在正准备写下一个 RL 项目的训练框架我的建议很简单别一上来就设计协议、开端口、想消息格式。先把你算法里的角色画清楚再想它们之间交换什么数据然后动手。你会发现很多时候问题没有你想象的那么复杂。
