京东AI用一套"共享厨房"彻底改变机器人训练方式，效率提升近一倍

机器人正在悄悄改变我们的日常生活，但训练一个能真正“干活”的机器人，背后的代价远比外人想象的要昂贵得多。这篇研究要解决的，正是这个被大多数人忽视的“幕后成本”问题。

把机器人的大脑比作一位厨师，它需要先在顶级厨艺学校接受通用培训——学会刀工、火候、调味，这对应的是“预训练”阶段，消耗了大量资源，但让这位厨师拥有了扎实的基本功。然而，不同餐厅（不同任务、不同机器人身体结构、不同模拟器环境）需要这位厨师掌握各自的专门菜系，于是还需要额外的“岗前培训”，这就是论文中所说的“后训练”（Post-Training）阶段。问题来了：目前，每家餐厅都要独立包下整个厨房，从采购设备到雇用清洁工，全套自己搞定，即便厨师只用到厨房一小会儿，租金却一分不少。这种模式，既贵又浪费。

京东研究团队提出的解决方案，叫做JoyNexus。它的核心思路是把这间昂贵的厨房改造成一个“共享厨房”：多家餐厅同时入驻，共用同一套昂贵的锅炉、烤箱和冷藏设备，每家只需带上自己的秘制调料包（各自专属的“动作模块”）。这套方案不仅降低了每家餐厅的使用成本，更关键的是，当A餐厅的厨师在等食材到货（模拟器在跑环境交互）时，厨房的炉灶并不闲着，B餐厅的厨师可以立刻顶上来，整个厨房的利用率就大幅提升了。实验数据显示，与原来各家独立包厨房的方案相比，JoyNexus让GPU训练时间总量减少了28.3%，训练侧的GPU利用率接近翻倍（提升1.99倍），推理侧也提升了1.33倍。

一、机器人“大脑”的两层结构：共用骨干，各有特色

要理解JoyNexus为什么可行，先要搞清楚现代机器人AI的一个关键特点。

当前最先进的机器人视觉-语言-动作模型（简称VLA模型，可以理解为机器人的“大脑”），其结构天然分成两个部分。第一部分是一个庞大的“视觉语言底座”，负责看图、理解文字指令，这部分非常昂贵，通常有数十亿个参数，相当于厨师经过多年训练才积累的通用厨艺直觉。第二部分是一个相对轻量的“动作模块”，负责把底座产生的理解翻译成实际的机械臂动作，这就像是针对某种特定菜系添加的专门技能包。研究团队注意到，在后训练阶段，大多数情况下这个昂贵的底座是被“冻结”的，不会被修改，只有那个轻量的动作模块才会更新。这意味着：不同任务的多个训练进程，完全可以共用同一份底座，只需分别维护各自的动作模块就够了。

论文参考了StarVLA提出的“乐高式”组合设计思路——视觉语言底座和动作模块像乐高积木一样可以自由拼插。这种设计使得JoyNexus的“共享厨房”方案具备了坚实的技术基础：昂贵的公共设施（底座）永久驻留，不同租客（租户）带来各自的调料包（动作模块），互不干扰，却共用火力。

在后训练这个阶段，有三种典型的训练流程需要支持。一是监督微调（SFT），相当于给厨师看大量示范视频，然后让他模仿；二是强化学习（RL），相当于让厨师在模拟器里真实下厨，根据“菜好不好吃”的即时反馈来自我改进；三是评估（Evaluation），相当于让厨师完成一道考核菜，只记录成绩，不修改厨艺。这三种流程共享大量底层基础设施，却有着不同的数据来源和参数更新方式，JoyNexus的核心工作之一就是把这三者统一纳入同一套服务框架之中。

二、三大服务组件：推理、训练、环境，各司其职又紧密协作

JoyNexus的整体架构如同一家运转顺畅的大型厨房，其中有三个核心部门协同工作。

第一个部门是训练模型服务（Training Model Service），可以把它理解为“炒菜区”。这里驻留着那个永不修改的昂贵底座模型，同时为每个租户（训练任务）维护着各自的动作模块和优化器状态（相当于各自的调料罐和炒菜秘籍）。当一个训练任务被调度执行时，炒菜区的工人（论文称之为“actor”）会激活对应租户的调料罐，完成梯度更新，然后把更新结果打包导出，但共享的底座模型既不会被复制也不会被修改。

第二个部门是推理模型服务（Inference Model Service），相当于“出菜区”。这里同样驻留着底座模型，同时保存每个租户的最新动作模块权重，负责接收环境观测数据（机器人的“眼睛”看到了什么），并快速预测下一步应该执行的动作。出菜区和炒菜区之间有一个同步机制：每当某个租户的动作模块在炒菜区更新之后，新的参数会被推送到出菜区，让后续的环境交互使用最新的策略。

第三个部门是环境服务（Environment Service），相当于“备料区”。它既包含各种模拟器（LIBERO、ManiSkill、RoboTwin等机器人仿真环境，相当于各种食材产地），也包含离线数据集（已有的示范数据，相当于备好的半成品食材）。在线强化学习的租户需要通过备料区不断产生新的“原料”（轨迹数据），而监督微调的租户则直接从半成品货架上取货，绕过了繁琐的实时备料流程。

将这三个部门串联起来的，是两条独立的传送带：训练队列和推理队列。训练队列承载的是大批量、非实时敏感的训练任务（轨迹数据或示范批次），推理队列承载的是小批量、对延迟敏感的实时动作预测请求。两条队列独立运行，互不阻塞，这意味着某个租户在等待环境产生新数据时，其他租户的训练任务可以无缝占用炒菜区的算力，这正是整体利用率得以提升的关键所在。

整个厨房的“大厨长”（Master Service，主服务）负责统筹全局：验证每个新租户的任务规格是否合法，为其分配独立的“调料罐”槽位（tenant slot），并将高层语义指令（“我要做一批强化学习训练”）翻译成底层的具体操作序列。租户只需要告诉大厨长自己想要什么结果，底层的资源调度、进程管理、参数同步，全部由服务方负责，这正是论文强调的“服务化”理念的核心——让用户专注于算法设计，而非基础设施搭建。

三、三种训练流程的统一调度：同一套管道，不同的食材

以一家运营着多条流水线的工厂来理解JoyNexus的调度逻辑会更直观。

强化学习流程形成了一个闭环。轨迹生产者不断地在模拟器里运行当前策略，收集机器人与环境交互的完整轨迹，然后把这些数据放入训练队列的对应分区。与此同时，策略更新者（actor）从训练队列中取出已经准备好的轨迹数据，执行梯度更新，然后把新参数推送给推理服务，让下一批轨迹采集使用更新后的策略。这两个流程——轨迹采集和策略更新——是真正异步并行的，采集下一批数据不需要等待上一批的训练完成，就像工厂里送货的卡车和组装生产线同时运转，互不等待。为了防止策略更新得太快导致早期采集的数据“过时”，系统设置了一个“新鲜度检查”：如果发现某批轨迹数据对应的策略版本与当前版本的差距超过了设定阈值（论文实验中设为128步），这批数据就会被丢弃，不进行训练，确保强化学习的数据质量。

监督微调流程则相对简单。数据生产者从离线数据集中抽取示范样本，直接放入训练队列并标记为“就绪”，actor使用完全相同的消费逻辑处理这些数据。由于示范数据与当前策略无关，不存在“过时”的问题，因此不需要新鲜度检查。更重要的是，监督微调的任务可以在强化学习租户等待环境响应时无缝插入，填补炒菜区本来会闲置的空档，这正是跨租户调度效率提升的直接来源。

评估流程最为轻量——它根本不在训练队列中创建任何条目。评估只调用推理服务和环境服务，使用固定版本的策略走一遍模拟器，记录成功率等指标，全程不改动任何模型参数。一个关键的设计细节是：评估任务在启动时就锁定当前策略版本，不会随着训练的进行而悄悄切换到新版本，确保一次评估观测的始终是同一个版本的策略表现。

在任务调度优先级上，系统默认按照先进先出的顺序处理训练任务，但支持配置优先级，高优先级任务可以插队。针对监督微调可能“霸占”队列的风险（因为离线数据随时可用，而在线轨迹需要等模拟器），系统为每个租户设置了“最多同时在飞任务数”限制，防止某个离线租户把整个训练队列都塞满，挤占在线强化学习租户的资源。

四、跨租户“拼单”：一次计算，多家共享

进入JoyNexus最具创意的设计细节：组批（Group Batching）机制。

在标准的单租户场景下，每个训练请求或推理请求都独立占用底座模型做一次完整的前向计算。考虑这样一个极端情况：8个不同任务的租户，每个只有1条数据，于是底座模型要被反复调用8次，每次都在重复几乎相同的图像编码和语言理解计算，就像8个人各自走进超市，各自把同一张购物清单背了一遍，各自出门结账，没有任何一步是共享的。

JoyNexus的组批机制就是把这8个人凑成一组：把各自的数据规范化为统一的“VLAFeature”格式（标准化的特征表示），然后拼成一个大批次，送入底座模型做一次完整的前向计算。底座模型的输出特征会被切分，分别送往各自租户的专属动作模块，做后续的解码和损失计算，梯度各算各的，优化器各更新各的，彼此完全独立。这就像8个人凑单叫了一辆共享班车，到了目的地附近各自步行回家——核心的“长途”路段只跑了一次，效率大幅提升。

这套机制能行的前提是：VLA模型都在大规模数据集上预训练，因此普遍采用了统一的数据原型格式，不同任务的数据在经过各自的租户预处理器（Tenant Preprocessor）处理后，能够转换成兼容的共享前缀表示。只有兼容的请求才会被合并入同一个组，不兼容的请求仍然独立处理，系统会做严格的兼容性检查。

在推理队列中，调度策略借鉴了经典的排队理论：设定一个最大等待时间T和目标批次大小B，调度器按先进先出的顺序收集请求，一旦等待时间达到T或当前批次大小达到B，就立即触发一次批量推理。这样既能保证延迟不会无限积压，也能保证计算效率不因批次过小而浪费。

需要特别说明的是，组批机制主要用于推理队列，而非训练队列。这是因为训练任务本身通常已经包含了多条轨迹数据，批次规模天然较大，不那么需要跨任务合并；而推理请求往往来自单个环境的单步动作预测，批次极小，跨租户合并的收益才最为显著。

五、实验验证：数字背后的真实故事

研究团队通过两组实验来检验JoyNexus的实际效果。

第一组实验在一台8块GPU的服务器上搭建了一个真实的多租户场景：3个强化学习租户分别使用LIBERO、ManiSkill配置1和ManiSkill配置2三种模拟器，同时还有1个监督微调租户持续提交离线数据。GPU资源按2-2-4的方式划分：2块GPU用于训练模型服务的actor，2块用于推理模型服务，4块用于运行模拟器环境。所有租户共享同一个驻留的底座模型（StarVLA with Qwen3-VL-4B），各自维护独立的动作头、价值头、优化器状态和策略版本。

对比基准是“独立单租户”方案：每个任务各自独占一台更小的服务器（1-1-2的GPU配置），任务之间串行执行，先跑完LIBERO，再跑ManiSkill 1，再跑ManiSkill 2，最后追加同等量的SFT工作。

从执行轨迹来看，独立方案暴露了一个明显的规律性浪费：推理GPU在actor更新时无事可做，actor在模拟器慢慢跑环境时也无所事事，两者的空闲期交替出现，却无法互相填补。JoyNexus则通过三个RL租户的异步轨迹采集流并行推进，并在RL租户等待环境时把SFT任务填入actor的空档，让整个系统几乎没有无效的等待期。最终，多租户方案在完成同等训练量的情况下，总GPU时间比串行单租户方案减少了28.3%，整体效率提升1.39倍。从利用率角度看，训练模型服务的GPU利用率从20.8%跃升至41.3%，推理模型服务从28.1%提升至37.5%。训练侧的提升幅度更大（近乎翻倍），主要原因是三个RL任务的轨迹产生节奏各有差异，相互错开，再加上SFT任务持续填补空档，共同制造了大量的“叠加利用”机会。

第二组实验专门评估组批机制的效果，在受控模拟条件下测试了不同租户数量（2、4、6、8个）和不同本地批次大小（1、2、4、8条数据）的组合。实验使用了StarVLA的两个变体（QwenGR00T和QwenOFT）以及OpenPI（π0.5）三种代表性VLA模型，数据分别来自LIBERO和CALVIN两个不同的机器人数据集，模拟异构多租户的真实场景。

规律相当清晰：租户越多、本地批次越小，组批带来的加速效果越显著。以8租户、本地批次大小4的典型场景为例，针对共享底座前向计算阶段，StarVLA-GR00T（4B）加速约2.21倍，StarVLA-OFT加速约3.24倍（因其动作模块极为轻量，底座计算占总时间比例更高），OpenPI加速约1.71倍。更大的底座模型在组批下受益更明显，因为底座计算在总计算中占比更大，分摊的收益也越多。

研究团队还特别验证了一个核心关切：组批会不会让不同租户的训练互相串扰，导致损失曲线偏离？实验使用4个OpenPI租户（2个训LIBERO，2个训CALVIN），对比组批和串行执行下各租户的损失曲线变化。结果显示，两种模式下的损失曲线几乎完全重合——早期快速下降，随后稳定收敛，组批版本与串行版本的轨迹贴合度极高。这证明了共享底座前向计算并不会污染各租户私有的梯度和优化器状态，每个租户都在独立、纯净地更新自己的动作模块。

六、系统可靠性保障：健康管理与弹性扩缩

一套为企业提供长期稳定服务的系统，还必须解决可靠性问题，JoyNexus在这方面也做了专门设计。

系统引入了一个专属的“健康管理器”，持续通过心跳信号和错误报告监控所有服务组件的状态。一旦某个局部组件发生故障，系统执行“就地重启”而非“全局重启”——只终止出问题的那个角色，在现有资源分配范围内重新部署，从最近一次记录的进度恢复，其他组件和其他租户的工作不受影响。只有当故障波及共享协调组件，或者局部恢复尝试超出预算，才会触发全局重启。这种设计把故障影响范围控制到最小，对于多租户环境尤为重要，因为一个租户的局部问题不应该打断其他所有租户的工作进程。

弹性扩缩能力解决的是另一个现实问题：不同任务在不同阶段对推理算力的需求差异悬殊，强化学习在密集采样阶段需要大量推理资源，评估阶段相对空闲。JoyNexus支持异步地动态增加或回收推理引擎：扩容时，新的推理引擎启动后先与当前租户的策略权重同步，再逐步纳入服务池；缩容时，引擎先耗尽已有请求再释放资源。并发的扩缩操作会被序列化处理，保证服务一致性，并允许在部分失败时安全回滚。整个过程对租户侧的训练逻辑完全透明，无需修改任何代码。

监控体系采用集中式设计，各工作节点异步地把指标事件发送给专属的监控服务（如ClearML或WandB），而不是把监控逻辑嵌入每个训练或推理组件中。监控内容分三类：供Master Service做调度决策的控制信号（如队列深度、策略新鲜度）；供用户做实验分析的学习信号（如训练损失、评估分数）；以及供运维人员诊断性能瓶颈的系统信号（如服务健康度、权重同步开销、GPU利用率）。检查点和工作清单独立存储在各租户的输出目录中，即便临时运行态被释放，实验结果仍然可复现和可审计。

七、与同类研究的关系：站在前人肩膀上，填补空白

JoyNexus并非凭空而来，它的设计灵感主要来自被称为“Tinker风格”的服务化范式。Tinker系统的核心理念是：让用户用服务原语来表达微调逻辑，而不是手动管理工作进程分布、模型初始化和权重搬运——关键不在于远程执行，而在于职责分离：用户负责组合学习程序，服务方负责资源分配、模型驻留、调度、同步和持久化。

近年来，这套理念被延伸到语言模型后训练领域。OpenTinker研究了智能体强化学习中的职责分离，ProRL Agent提出了面向多轮智能体RL的“rollout即服务”，MARLaaS通过共享底座模型加租户私有LoRA适配器实现了多租户RL即服务，MinT研究了大量LLM的托管训练与服务基础设施。这些系统主要针对语言模型；而VLA后训练额外需要模拟器会话管理、异构动作模式、轨迹记录、评估协议、适配器清单和策略版本同步，之前的框架并未覆盖这些需求。据研究团队所知，JoyNexus是第一个专为完整VLA特定后训练生态设计的Tinker风格系统，涵盖了SFT、RL、轨迹采集、评估、参数导出和推理同步的全流程。

在分布式训练框架层面，Megatron-LM的张量并行、ZeRO的内存优化、DeepSpeed-Chat和OpenRLHF的RLHF流水线，以及HybridFlow的分层API编排，都是JoyNexus可以在底层使用的计算基础。RLinf将逻辑RL工作流与物理执行计划分离，RLinf-VLA将其专化到VLA强化学习，RL-VLA?展示了异步模拟器、生成器和训练器组的加速效果，这些都是JoyNexus集成的本地VLA RL栈的重要组成部分。在多租户推理方面，Punica和S-LoRA实现了共享底座下的多适配器批量推理，dLoRA动态编排请求和适配器——这些都可以作为JoyNexus推理后端的具体实现，而JoyNexus在其之上提供了服务边界、双队列调度、租户私有状态和环境交互等更高层次的抽象。

说到底，这项研究的意义不在于发明了全新的机器人算法，而在于解决了一个长期被忽视的“管道问题”。高质量的机器人AI训练之所以昂贵，不仅因为计算量大，更因为现有的云服务模式把大量算力浪费在等待和空转上。JoyNexus用“共享厨房”的思路，让多个训练任务的闲置时间互相填补，在不牺牲任何租户隔离性和训练正确性的前提下，把整体资源利用率提升到了接近翻倍的水平。

对普通用户来说，这意味着未来购买机器人AI训练服务时，可能不再需要租下整台服务器、自己搭建所有基础设施，而是像使用云文档一样，只为实际用掉的算力付费，剩下的交给平台自动调度。对服务提供商来说，同一批硬件能够服务更多客户，收益更高，固定资产的效率得到充分发挥。对整个机器人AI生态来说，降低后训练的门槛意味着更多团队可以负担得起迭代实验，加速这个领域的技术进步。

当然，论文也坦诚地指出了现有方案的局限性。目前租户的资源路由在执行期间基本固定，缺乏根据实时信号动态调整的能力；定价和优先级机制还需要进一步设计，才能在商业场景中实现租户成本、平台收益和服务保障三者之间的平衡；用户灵活性和安全隔离之间的张力也有待解决——允许用户上传自定义Docker环境或覆盖奖励函数会提升适配性，但也引入了安全和性能契约方面的挑战。未来的改进方向还包括：基于观测到的任务模式动态组建训练组，实现更智能的调度；以及在租户授权的前提下，利用跨租户的数据相关性做数据增强或迁移学习，让服务底座真正成为一个共同进化的智识资产。

Q&A

Q1：JoyNexus是什么，和普通的GPU云服务有什么区别？

A：JoyNexus是京东研究团队开发的多租户VLA模型后训练服务框架。普通GPU云服务通常给每个用户分配独占的GPU资源，用户需要自己搭建所有训练基础设施，GPU在等待数据或环境响应时会空转浪费。JoyNexus则让多个用户共享同一套底座模型和调度系统，在一个用户等待模拟器响应时，另一个用户的训练任务可以立即占用空闲算力，整体GPU利用率接近翻倍。

Q2：多租户共享底座模型会不会导致不同任务的训练互相干扰？

A：不会。JoyNexus的核心设计原则是在共享昂贵底座计算的同时，每个租户的动作模块参数、梯度、优化器状态和策略版本都完全独立。论文通过实验验证了这一点：4个不同任务的租户在组批模式下的损失曲线，与各自独立串行执行时几乎完全一致，证明共享前向计算不会污染私有的梯度更新过程。

Q3：VLA模型的后训练为什么比普通语言模型训练更麻烦？

A：VLA模型后训练额外需要管理模拟器会话（机器人在虚拟环境里实际“动起来”才能产生训练数据），这意味着数据不是随时可用的，而是需要等待环境交互完成才能获得。不同机器人任务还有各自不同的动作格式、传感器数据格式和评估指标，异构程度远高于纯文本模型。加上强化学习需要不断在推理、环境交互和训练之间循环切换，基础设施的复杂度大幅提升，这正是JoyNexus专门为这个场景设计的原因。