作者YZY, QJW, ZYC, LHJ from DeepLink Group Shanghai AI LabTL;DRRLightning 是一个面向具身强化学习的统一训练框架旨在解决单机原型开发与分布式规模化训练割裂的问题。它通过 Runtime Adapter、双层控制器和细粒度资源编排让研究者可以用同一套接口完成从算法验证到多机多卡扩展的全过程无需重写分布式逻辑同时针对具身 RL 中高频环境交互和异构组件协同进行了专门优化在保证收敛效果的前提下实现了更高的训练吞吐与接近线性的扩展能力人形控制任务从 1 节点扩展到 8 节点实现 81.4% 线性扩展效率OpenVLA 操作任务保持与基线一致收敛精度的同时将训练吞吐提升了 30% 。框架开源地址https://github.com/DeepLink-org/RLightning一、问题背景具身强化学习的核心范式是让 Agent 在物理环境中高频交互、采集数据、更新策略。这个过程看似直接但在工程层面存在几个让研究者头疼的问题原型开发与分布式扩展的割裂。算法研究者习惯在单机单进程下写代码、调 bug。一旦验证可行要扩展到多卡集群进行规模化训练往往需要重写大量分布式通信和调度逻辑。现有框架在这两端各有侧重Stable Baselines3、RSL-RL 擅长快速原型验证但缺乏分布式扩展能力Ray RLlib 具备分布式基础设施但工程复杂度高且未针对具身场景适配RLinf 等框架针对具身场景做了设计但其原生分布式架构在算法原型阶段引入了额外的门槛。具身 RL 的数据交互密度远超 LLM RL。LLM 领域的 RL如 PPO、GRPO 瓶颈主要在大模型并行、长序列推理和梯度计算。而具身 RL 的核心瓶颈在于环境交互吞吐。例如在Humanoid任务中采样频率可达数百 Hz系统需要持续、高频地在仿真器与策略模型之间做数据通信。异构生态碎片化。不同仿真器IsaacLab、MuJoCo、ManiSkill、不同模型规模MLP 到数十亿参数的 VLA、不同任务类型运动控制 vs 操作任务现有框架缺乏统一适配能力。RLightning 正是针对这些问题而设计的具身 RL 框架。二、设计思路总览RLightning 的核心设计理念是统一原型开发与分布式扩展。上层编程接口不因运行模式改变而改变底层通过运行时适配自动处理单机与分布式的差异。系统采用四层架构Application Layer面向用户的编程接口用于构建 RL 应用、实现策略算法、定制组件Controller Layer由 Engine全局编排和 WorkerGroup组内调度组成的双层控制器Worker Layer实际执行计算的工作单元——Env、Policy、Buffer 三类 Worker 可独立扩展Runtime Resource Layer运行时适配与资源调度对上层完全透明RLightning 有三个主要的设计1Runtime Adapter 实现零代码迁移2双层控制器 数据流解耦实现灵活调度3细粒度资源编排提升硬件利用率。三、统一编程接口写单进程代码集群规模运行1. Runtime Adapter透明的运行时适配RLightning 的解法是在底层引入 Runtime Adapter 层。这一层屏蔽了 Worker 创建、调用、通信等底层细节的差异使得上层编程接口在单机和分布式模式下完全一致。用户只需编写一个标准的 Python 入口脚本from RLightning import builder, launch def main(config): env_group builder.build_env_group(config) policy_group builder.build_policy_group(policy_cls, config) buffer builder.build_data_buffer(buffer_cls, config) engine builder.build_engine(env_group, policy_group, buffer, config) engine.run() launch(main, config_path)通过builderAPI 构建 env_group、policy_group、buffer组装成 engine 后调用run()。这段代码在单机和集群上是同一份。扩展规模时只需修改配置文件中 Worker 的数量和 runtime 模式。例如从单卡切换到 8 节点 64 卡不需要改动任何算法代码框架自动完成分布式后端的映射与部署。2. 组件扩展机制RLightning 定义了BaseEnv、BasePolicy、BaseBuffer三个抽象基类规范了组件间的接口和数据交互协议。用户要接入自定义仿真器或算法只需继承对应基类、实现必要方法、注册即可——不需要修改框架代码。这种松耦合设计也使得在同一个训练流水线中混合不同类型的环境和策略成为可能。四、双层控制器与数据流解耦具身 RL 涉及仿真器、策略模型、数据缓存等多类异构组件。这些组件之间存在高频交互和不同步执行rollout 阶段 Env 和 Policy 需要数百 Hz 的交互频率train 阶段需要从 Buffer 中采样并做梯度更新weight sync 阶段需要将更新后的参数广播到所有推理 Worker。不同 RL 算法on-policy vs off-policy对这些阶段的执行顺序和同步要求也不同。1. Engine全局工作流编排Engine 是 RL 流水线的全局编排器将 RL 工作流组织为四个阶段rollout推理策略与环境高频交互采集经验数据update_dataset训练策略从 Buffer 中采样数据train在采样数据上执行前向与反向计算更新模型参数sync_weights将更新后的权重同步到推理策略Engine 内部的Stage Coordinator负责控制各阶段的触发顺序和同步语义。它支持两种模式严格顺序执行适用于 on-policy 算法如 PPO确保 rollout 使用最新策略异步流水线并行适用于 off-policy 算法rollout 和 train 可以并行执行以最大化吞吐。同时也可用于调控 Actor 和 Learner 之间的 off-policy 程度在训练稳定性和收敛效率之间取得平衡2. WorkerGroup组内细粒度调度WorkerGroup 封装了一组同类型的 Worker对上暴露批量接口对内负责任务分发和结果聚合。在分布式模式下WorkerGroup 本身不持有实际数据而是管理数据引用的收集与分发协调 Worker 之间的点对点数据传输。WorkerGroup 内部有两个关键优化模块BatchRouter负责将输入 batch 分发到各 Worker支持三种路由策略State-aware routing状态感知路由支持有状态和无状态两种模式。对于需要多轮推理且要保持 Worker 亲和性的场景如 RNN 策略请求会被持续路由到同一个 WorkerLoad-balancing routing负载均衡路由动态监控各 Worker 的负载水平优先将任务分派到低负载节点Node-affinity routing节点亲和路由优先将请求路由到与调用方同节点的 Worker减少跨节点通信延迟AsyncIOHandler采用异步收集机制持续提取已完成的结果并流式下发到下游将 batch 的输入和输出解耦。相比同步模式下必须等待所有 Worker 完成才返回结果这种方式避免了被最慢 Worker 拖慢整个 batch 的长尾延迟问题。这种双层设计的好处在于研究者只需通过 Engine 接口关注粗粒度的工作流编排先 rollout 再 train底层的异步 IO、流水线并行、路由策略等细节由数据流层自动处理。实测数据表明在人形运动控制任务上开启异步 IO 和流水线优化后8 节点 64 卡的端到端吞吐相比关闭优化时提升至 3.75 倍。五、细粒度资源编排1. 核心思想不同类型的 Worker 在计算量、通信模式、执行顺序上差异很大。RLightning 的 Resource Manager 允许各 Worker 类型独立扩展——Env Worker、Policy Worker、Buffer Worker 的数量可以根据任务特点分别配置而非简单地按节点等比放大。2. 两种放置策略Resource Manager 提供两种核心放置策略Disaggregate分离策略训练组件Learner Buffer与采样组件Env Actor物理隔离到不同资源池。适合异步训练场景最大化减少组件间资源争用提升 GPU 吞吐Colocate共置策略训练与采样组件共享同一资源池。适合同步训练场景策略稳定性要求较高时使用3. Rollout 阶段的进一步优化在 rollout 阶段Env 和 Actor 之间需要高频交互。RLightning 引入env_strategy参数进行更细粒度的调度Default 模式Env 和 Actor Worker 各占独立 GPU 资源Device-Colocate 模式Env 和 Actor Worker 共享 GPU 设备利用时分复用和硬件级资源共享提升设备利用率4. Onload/Offload 机制对于顺序执行的组件例如同一个 GPU 上先做推理再做训练RLightning 支持动态加载/卸载机制——当某个组件不活跃时将其从 GPU 卸载为活跃组件腾出显存和算力从而实现计算资源的时间复用。系统支持 Auto自动规划和 Manual手动控制两种模式。Auto 模式下Resource Manager 自动发现集群资源并创建 Ray Placement Group 进行组件放置Manual 模式下用户可以精确控制每个组件的放置位置。六、实验验证RLightning 在两类具有代表性的具身 RL 任务上进行了评估。选择这两类任务的原因是它们覆盖了具身 RL 的两种典型场景小模型 高频交互的人形运动控制任务和大模型 推理密集的VLA 操作任务。1. 人形全身控制任务实验在 8 节点 RTX 4090 集群上进行使用 IsaacLab 仿真器策略网络为MLP构成的小模型对比基线为 BeyondMimic。单卡性能在单进程模式下RLightning 的 rollout 吞吐为 53,850 samples/s与 BeyondMimic 的 61,399 samples/s 处于同一量级验证了框架本身不引入额外开销。分布式可扩展性从 1 节点到 8 节点rollout 吞吐从 122,833 提升到 800,563 samples/s实现6.51 倍加速对应 81.4% 的线性扩展效率。从单卡到 8 节点仅通过修改config而未改动任何代码框架的 rollout 吞吐实现了近15 倍的提升。2. OpenVLA RL 操作任务实验使用VLA作为策略模型在 ManiSkill 仿真器上训练对比基线为 RLinf。在精度上 RLightning 与 RLinf 的收敛趋势完全一致。在相同训练步数下两者达到相同的测试集成功率。这验证了 RLightning 的系统优化不以算法收敛为代价。在系统性能上RLightning 将训练吞吐量提升了30%以上。这表明在同等硬件配置下RLightning能以更快的速度达到等效收敛加速具身模型迭代。框架开源地址https://github.com/DeepLink-org/RLightning未来我们将持续迭代支撑更多前沿的AI研究需求。欢迎社区使用并提出宝贵的意见。