这项由京东JDT AI Infra联合北京大学、北京航空航天大学、北京理工大学、清华大学共同开展的研究以预印本形式发布于2026年7月17日论文编号为arXiv:2607.16074v1感兴趣的读者可通过该编号查阅完整原文。机器人正在悄悄改变我们的生活但训练一个能够真正干活的机器人背后的代价远比外人想象的要昂贵得多。这篇研究所要解决的正是这个被大多数人忽视的幕后成本问题。把机器人的大脑比作一名厨师它需要先在顶级厨艺学校接受通用培训——学会刀工、火候、调味这对应的是我们所说的预训练阶段消耗了大量资源但让这位厨师拥有了扎实的基本功。然而不同餐厅不同任务、不同机器人身体结构、不同模拟器环境需要这位厨师掌握各自的专门菜系于是还需要额外的岗前培训这就是论文中所说的后训练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用于训练模型服务的actor2块用于推理模型服务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-GR00T4B加速约2.21倍StarVLA-OFT加速约3.24倍因其动作模块极为轻量底座计算占总时间比例更高OpenPI加速约1.71倍。更大的底座模型在组批下受益更明显因为底座计算在总计算中占比更大分摊的收益也越多。研究团队还特别验证了一个核心关切组批会不会让不同租户的训练互相串扰导致损失曲线偏离实验使用4个OpenPI租户2个训LIBERO2个训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环境或覆盖奖励函数会提升适配性但也引入了安全和性能契约方面的挑战。未来的改进方向还包括基于观测到的任务模式动态组建训练组实现更智能的调度以及在租户授权的前提下利用跨租户的数据相关性做数据增强或迁移学习让服务底座真正成为一个共同进化的智识资产。有兴趣深入了解技术细节的读者可以通过arXiv编号2607.16074查阅完整论文包括详细的伪代码实现和更多实验数据。QAQ1JoyNexus是什么和普通的GPU云服务有什么区别AJoyNexus是京东研究团队开发的多租户VLA模型后训练服务框架。普通GPU云服务通常给每个用户分配独占的GPU资源用户需要自己搭建所有训练基础设施GPU在等待数据或环境响应时会空转浪费。JoyNexus则让多个用户共享同一套底座模型和调度系统在一个用户等待模拟器响应时另一个用户的训练任务可以立即占用空闲算力整体GPU利用率接近翻倍。Q2多租户共享底座模型会不会导致不同任务的训练互相干扰A不会。JoyNexus的核心设计原则是在共享昂贵底座计算的同时每个租户的动作模块参数、梯度、优化器状态和策略版本都完全独立。论文通过实验验证了这一点4个不同任务的租户在组批模式下的损失曲线与各自独立串行执行时几乎完全一致证明共享前向计算不会污染私有的梯度更新过程。Q3VLA模型的后训练为什么比普通语言模型训练更麻烦AVLA模型后训练额外需要管理模拟器会话机器人在虚拟环境里实际动起来才能产生训练数据这意味着数据不是随时可用的而是需要等待环境交互完成才能获得。不同机器人任务还有各自不同的动作格式、传感器数据格式和评估指标异构程度远高于纯文本模型。加上强化学习需要不断在推理、环境交互和训练之间循环切换基础设施的复杂度大幅提升这正是JoyNexus专门为这个场景设计的原因。
京东AI用一套“共享厨房“彻底改变机器人训练方式，效率提升近一倍
这项由京东JDT AI Infra联合北京大学、北京航空航天大学、北京理工大学、清华大学共同开展的研究以预印本形式发布于2026年7月17日论文编号为arXiv:2607.16074v1感兴趣的读者可通过该编号查阅完整原文。机器人正在悄悄改变我们的生活但训练一个能够真正干活的机器人背后的代价远比外人想象的要昂贵得多。这篇研究所要解决的正是这个被大多数人忽视的幕后成本问题。把机器人的大脑比作一名厨师它需要先在顶级厨艺学校接受通用培训——学会刀工、火候、调味这对应的是我们所说的预训练阶段消耗了大量资源但让这位厨师拥有了扎实的基本功。然而不同餐厅不同任务、不同机器人身体结构、不同模拟器环境需要这位厨师掌握各自的专门菜系于是还需要额外的岗前培训这就是论文中所说的后训练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用于训练模型服务的actor2块用于推理模型服务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-GR00T4B加速约2.21倍StarVLA-OFT加速约3.24倍因其动作模块极为轻量底座计算占总时间比例更高OpenPI加速约1.71倍。更大的底座模型在组批下受益更明显因为底座计算在总计算中占比更大分摊的收益也越多。研究团队还特别验证了一个核心关切组批会不会让不同租户的训练互相串扰导致损失曲线偏离实验使用4个OpenPI租户2个训LIBERO2个训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环境或覆盖奖励函数会提升适配性但也引入了安全和性能契约方面的挑战。未来的改进方向还包括基于观测到的任务模式动态组建训练组实现更智能的调度以及在租户授权的前提下利用跨租户的数据相关性做数据增强或迁移学习让服务底座真正成为一个共同进化的智识资产。有兴趣深入了解技术细节的读者可以通过arXiv编号2607.16074查阅完整论文包括详细的伪代码实现和更多实验数据。QAQ1JoyNexus是什么和普通的GPU云服务有什么区别AJoyNexus是京东研究团队开发的多租户VLA模型后训练服务框架。普通GPU云服务通常给每个用户分配独占的GPU资源用户需要自己搭建所有训练基础设施GPU在等待数据或环境响应时会空转浪费。JoyNexus则让多个用户共享同一套底座模型和调度系统在一个用户等待模拟器响应时另一个用户的训练任务可以立即占用空闲算力整体GPU利用率接近翻倍。Q2多租户共享底座模型会不会导致不同任务的训练互相干扰A不会。JoyNexus的核心设计原则是在共享昂贵底座计算的同时每个租户的动作模块参数、梯度、优化器状态和策略版本都完全独立。论文通过实验验证了这一点4个不同任务的租户在组批模式下的损失曲线与各自独立串行执行时几乎完全一致证明共享前向计算不会污染私有的梯度更新过程。Q3VLA模型的后训练为什么比普通语言模型训练更麻烦AVLA模型后训练额外需要管理模拟器会话机器人在虚拟环境里实际动起来才能产生训练数据这意味着数据不是随时可用的而是需要等待环境交互完成才能获得。不同机器人任务还有各自不同的动作格式、传感器数据格式和评估指标异构程度远高于纯文本模型。加上强化学习需要不断在推理、环境交互和训练之间循环切换基础设施的复杂度大幅提升这正是JoyNexus专门为这个场景设计的原因。
