← 返回 2026-07-21

JoyNexus：面向服务的VLA模型多租户后训练系统 JoyNexus: Service-Oriented Multi-Tenant Post-Training for VLA Models

Haoran Sun, Wentao Zhang, Junyang Hua, Hedan Yang, Yongjian Guo, Yifei Zhang, Xiaolong Xiang, Mingxi Luo, Jing Long, Chen Zhao, Chen Zhou, Wanting Xu, Qiming Yang, Hui Zhang, Song Wang, Xiaodong Bai, Shuai Di, Xu Chu, Xiaotie Deng, Yicheng Gong, Junwu Xiong 📅 2026-07-17 👍 8 2026-07-25 18:30
GPU调度 VLA模型 后训练 多租户服务 强化学习 系统架构
arXiv HuggingFace PDF

将VLA后训练重构为多租户服务，解耦训练/推理/环境并组批调度，GPU时间降28%

前置知识

VLA模型（视觉-语言-动作模型）

VLA模型把多模态输入（视觉观测、语言指令、机器人状态、可选历史）经共享的感知-语言骨干网络编码为潜在表示，再由体感专用的动作模块（action expert，如扩散/流匹配头、MLP或投影头）映射为机器人动作序列。代表模型有OpenVLA、π0/π0.5、GR00T、StarVLA等。当前主流VLA常把预训练视觉-语言基座（VLM）冻结、只更新动作模块，这正是多租户共享基座的前提。

本文整个系统都围绕VLA模型的SFT、RL、评估后训练展开，理解VLA“冻结基座+租户私有动作模块”的结构是理解为何能共享前向、为何适合组批以及租户槽位设计的基础。

多租户服务与Tinker范式

Tinker式系统把模型后训练通过可编程API暴露给用户，同时隐藏分布式执行细节：用户组合学习程序，服务方负责资源分配、模型常驻、调度、同步与持久化。多租户（multi-tenant）指多个用户共享同一套常驻基座模型与基础设施，但各自保留私有的适配器、优化器状态、rollout记录与策略版本，互不干扰。

JoyNexus正是把Tinker范式首次完整搬到VLA生态的多租户系统，理解这一范式才能理解“基座常驻+租户槽位+双队列”的设计动机以及它与传统独占GPU或批量提交的区别。

VLA后训练工作流（SFT/RL/评估）

SFT用离线演示数据（观测、指令、状态、目标动作）监督微调可训练模块并导出适配器检查点；RL以在线/模拟环境为数据源，策略推理产生动作、与环境交互产生转移/奖励/终止信号写入rollout记录，再由训练作业消费这些记录做RL更新并同步推理策略；评估只读、加载某版本策略绑定环境跑推理记录指标、不更新参数。三者复用模型推理、环境交互、数据交换等相同组件。

JoyNexus的核心贡献是用统一的解耦服务把这三种工作流编排起来，理解它们的异同（数据来源、是否更新参数、是否需要环境与同步）是理解双队列和异步生产者-消费者循环的前提。

组批（Group Batching）

组批把来自不同租户、schema异构但共享兼容“模型面向前缀”的请求，规范到统一的VLAFeature表示并拼接成一个大batch，只对冻结基座做一次共享前向，再把输出特征切回各自的动作模块做解码/损失/更新。它借鉴SGLang/vLLM的动态批，但专门处理VLA异构schema与单token推理，并用最大等待时间 $T$ 与目标批大小 $B$ 的触发策略。

组批是本文提升推理/前向阶段利用率的核心机制，理解它才知道为什么“租户越多、本地批越小”时收益越大，以及它为何只用于推理队列而非训练队列。

参数高效微调与流匹配动作头

参数高效微调（如LoRA）冻结大基座、只训练少量适配器参数，使多租户能共享同一常驻基座而各自持有轻量模块。流匹配（flow matching）是一类生成式动作解码头，把从噪声分布到动作分布建模为连续流、学习速度场，用于GR00T/π系列等VLA；与之相对，OFT用小线性层做动作解码。

本文把动作头视为租户私有模块、把VLM视为常驻基座，且实验对比了流匹配头（GR00T）与线性头（OFT）在不同基座/动作专家比例下组批收益的差异，理解这些才能读懂实验结论。

研究动机

现有VLA（视觉-语言-动作）模型后训练的基础设施范式存在根本低效。云服务商通常把整组GPU/CPU独占地租给单个租户，或接收批量任务提交。这两种方式虽把执行控制权完全交给用户，却迫使他们自行处理复杂的分布式训练依赖，对同时涉及异构模型与模拟器环境的VLA工作尤为吃力。更关键的是，按“卡时”（card-hour）计费的固定模式对短促、突发、迭代式的VLA工作负载极不友好：在rollout采集、数据加载、评估、环境同步期间GPU常处于空闲。由于VLA模型规模通常中等，租户自研分布式训练又常导致加速器利用率低下，既对租户昂贵，也让服务商难以高效填满算力。

本文的目标是本文的目标是设计统一的多租户服务JoyNexus，覆盖VLA的监督微调（SFT）、强化学习（RL）和评估全流程，让多个租户的这些工作负载并发共享常驻基座模型而互不干扰。系统需把训练模型服务、推理模型服务、环境服务三者解耦，各自通过API访问，基座模型常驻内存、每个租户拥有独立的动作模块“槽位”。租户既能调用训练/rollout/评估等高层语义API，也能用低层API组合自定义算法。目标是让租户聚焦算法本身、由平台统一调度会话、路由、动作模块状态、检查点与策略版本，并通过跨租户调度与组批降低总GPU时间、提升服务利用率。

与已有工作不同的是，本文的独特切入角度是把“Tinker风格”的服务化范式首次完整地搬到VLA生态。已有Tinker式系统（OpenTinker、ProRL Agent、MinT、AReaL、MARLaaS等）主要针对语言模型或文本智能体的后训练，把rollout-as-a-service与训练服务分离；但VLA后训练额外要求模拟器会话、异构动作schema、rollout记录、评估协议、适配器清单（adapter manifest）和策略版本同步等一等公民概念。据作者所知，JoyNexus是首个为完整VLA后训练生态（SFT、RL、rollout、评估、参数导出、推理同步）设计的Tinker式系统，其依据是三个洞察：VLA的RL/SFT/评估共享同一套基础设施；参数高效后训练通常冻结共享VLM基座、只更新租户私有动作模块；服务化设计天然支持并发调度与组批。

核心方法

JoyNexus的总体思路是“把意图留在客户端和控制面、把昂贵的共享运行时留在执行面”。系统采用客户端-服务器结构：用户声明基座模型、任务类型、可训练参数化、环境/数据集和调度要求并提交工作负载规格。控制面的Master Service验证意图并编译成租户作用域的工作负载——其租户创建器对规格做严格校验、为每个租户推导确定性的schema签名、再编译成后端配置；工作负载编排器按RL/SFT/评估的语义物化所需服务角色与生命周期。执行面包含三类常驻服务：训练模型服务（更新worker称为actor）、推理模型服务、环境服务，都建立在共享的冻结VLM基座之上，每个租户挂载独立的动作模块槽位、优化器状态与策略版本。资源管理器把长驻服务放入加速器placement group并监控健康。两层API（低层原语+高层语义声明）共同构成可编程接口，典型实验采用2-2-4的GPU布局（2卡训练actor、2卡推理、4卡环境模拟）。

核心创新点在于用三大解耦服务+双队列+组批来重构多租户VLA后训练，这与“每个租户独占GPU”或“批量提交”有本质区别。第一，把训练模型服务、推理模型服务、环境服务三者彻底解耦：基座模型常驻、租户私有动作模块以槽位形式挂载，训练只导出该租户的参数载荷而从不复制基座。第二，引入训练队列（Training Queue，按训练作业粒度承载优化数据流）与推理队列（Inference Queue，承载时延敏感预测请求）的双路分离，使同一个训练消费者能交替处理RL与SFT作业，而rollout/评估走独立调度路径。第三，组批（group batching）：把兼容的异构租户请求规范到统一的“模型面向前缀”表示（VLAFeature），只做一次共享基座前向，再把输出特征切回各自动作模块，从而摊薄占主导的共享前向开销。

方法步骤详情

方法步骤如下。步骤1-RL闭环：rollout侧循环reserve作业→执行rollout（环境reset/step加predict）→queue_put轨迹到训练队列分区；actor侧独立lease就绪作业→train_job（queue_get/train_batch做优化步）→export_params导出该租户载荷→load_weights同步动作模块权重到推理服务→queue_clear释放分区。两侧只经作业状态与队列分区耦合，采集下一条rollout无需等上一条训练完成；用128个actor微批的陈旧度界限制在途rollout落后当前策略的程度。步骤2-SFT路径：复用同一生产者-消费者形状，生产者只sample演示数据、立即mark_ready、无需load_weights，可与RL作业在同一actor交替。步骤3-评估路径：只读，不建训练队列分区、不调用优化器、不推进策略版本，仅在调用时一次性解析缓存参数版本。步骤4-组批：推理调度器用最大等待时间 $T$ 与目标批大小 $B$，等待达 $T$ 或批达 $B$ 即触发；训练侧用FIFO+优先级+每租户-任务策略的在途作业数限制防离线数据挤占在线训练。

技术新颖性

技术新颖性体现在四方面。其一，JoyNexus是首个面向完整VLA后训练生态的Tinker式系统，把SFT、RL、rollout、评估、参数导出与推理同步统一在租户私有工作负载与常驻共享服务之上，而OpenTinker/MARLaaS等仅覆盖语言模型。其二，双队列解耦——训练队列承载优化数据流、推理队列承载时延敏感预测，使RL在线rollout、SFT离线批次、评估只读请求能在同一后端并发交织而互不阻塞。其三，常驻基座+租户槽位模型：训练只导出租户私有动作模块载荷、基座既不复制也不进入载荷，天然支持参数高效多租户适配（冻结VLM、更新action expert）。其四，针对VLA异构schema的组批：与LLM统一的token模态不同，VLA请求schema各异且多为单token推理，系统把请求规范到统一的VLAFeature前缀、在拼接点合并、再分发到各自action expert，并用基于排队论的 $T$-$B$ 触发策略，这是对动态批（SGLang/vLLM）在VLA场景的专门化设计。

Representative VLA post-training workflows
Figure 2: Representative VLA post-training workflows
JoyNexus service architecture
Figure 3: JoyNexus service architecture
Core APIs of the Training/Inference/Environment-Queue services
Figure 4: Core APIs of the Training/Inference/Environment-Queue services
Detailed multi-tenant runtime flow
Figure 5: Detailed multi-tenant runtime flow
Simplified asynchronous RL logic
Figure 6: Simplified asynchronous RL logic
Simplified asynchronous SFT logic
Figure 7: Simplified asynchronous SFT logic
Multi-tenant group batching
Figure 8: Multi-tenant group batching

实验结果

实验分两部分。第一部分真实多租户负载模拟：StarVLA+Qwen3-VL-4B基座、单8卡节点、4租户（3个RL：LIBERO+两个ManiSkill；1个SFT），2-2-4布局（2卡actor、2卡推理、4卡环境），actor全局微批256（每卡128）、推理批上限128，RL轮询准入、每租户最多2在途作业、活动rollout每租户1个全局3个、陈旧度界128微批，对照为1-1-2孤立单租户轨迹。结果显示多租户把总GPU时间降28.3%、GPU时间效率提升1.39×；表1中训练模型服务利用率从20.8%升至41.3%（1.99×），推理模型服务从28.1%升至37.5%（1.33×），训练侧增益更大正因离线SFT租户能在RL租户等环境时空闲填满actor。第二部分受控组批实验对比串行（重复基座前向）与组批（合并兼容请求做一次共享前向）。图10表明收益随租户数增、本地批减而增大；8租户批4时（图11）StarVLA-GR00T 2B/4B/8B分别获2.01×/2.21×/2.18×前向加速，OpenPI 1.71×，QwenOFT因动作模块相对基座可忽略高达3.24×。图12中四OpenPI租户的组批损失曲线与串行高度吻合，证明组批保持各租户优化行为隔离性。

Average utilization of the shared Training and Inference Model Service GPUs
Table 1: Average utilization of the shared Training and Inference Model Service GPUs
Trace-based comparison of multi-tenant vs isolated single-tenant execution
Figure 9: Trace-based comparison of multi-tenant vs isolated single-tenant execution
Shared-forward throughput speedup under mixed-schema multi-tenant training
Figure 10: Shared-forward throughput speedup under mixed-schema multi-tenant training
Forward-stage breakdown for representative models (8 tenants, batch 4)
Figure 11: Forward-stage breakdown for representative models (8 tenants, batch 4)
查看结构化数据
任务指标本文基线提升
多租户端到端GPU时间效率 GPU时间效率（相对单租户基线） 1.39×（总GPU时间降28.3%） 孤立单租户串行执行（1-1-2布局） GPU时间降低28.3%
训练模型服务GPU利用率 平均利用率 41.3%（多租户JoyNexus） 20.8%（孤立单租户） 1.99×
推理模型服务GPU利用率 平均利用率 37.5%（多租户JoyNexus） 28.1%（孤立单租户） 1.33×
共享前向阶段吞吐（StarVLA-GR00T 4B，8租户批4） 前向阶段吞吐加速（组批/串行） 2.21× 1.0×（串行） 2.21×
共享前向阶段吞吐（StarVLA-OFT，8租户批4） 前向阶段吞吐加速（组批/串行） 3.24× 1.0×（串行） 3.24×

局限与改进

作者明确承认若干局限。第一，虽支持模型服务的动态增删，但租户工作负载在执行期间基本仍绑定固定的路由与资源分配，缺乏基于运行时信号（队列压力、模拟器时延、租户优先级）的动态路由与资源再分配能力。第二，组批的效率测量只隔离了可共享的前向阶段，并未声明端到端训练吞吐的提升，因为租户私有的反向传播与优化器更新仍各自进行、无法共享。第三，实验中的“隔离”仅指模型与优化状态的分离，而非安全或性能隔离，多租户共享GPU可能延长单个租户的墙钟时间。第四，定价与产品化机制尚未设计，缺少兼顾租户成本、平台利用率与服务保证的计费/优先级策略。第五，异构schema的canonicalization仅在mask、动作维度、相机槽位、状态约定能保持各租户语义时才允许共享，否则可能破坏正确性——这是潜在但未被量化讨论的风险。

独立分析的弱点

独立分析的弱点。其一，真实负载实验规模偏小：仅单8卡节点、4租户、90分钟窗口，1.39×/28.3%的提升能否在更大集群和更多租户下保持或放大未经验证；改进方向是用数百租户、跨多节点placement group做压力测试，并报告尾时延与公平性。其二，组批仅作用于推理队列，训练队列用简单FIFO+优先级，未利用schema兼容性做动态训练分组；可设计感知schema、批大小、截止期与资源压力的训练分组调度器。其三，安全与性能隔离薄弱——作者自述“隔离仅指状态分离”，用户可上传Docker/外部环境/自定义训练代码，缺少沙箱、攻击检测与性能契约，这对商用多租户是硬伤，应引入容器级隔离与配额。其四，组批加速来自基座前向主导，但当基座变小或动作专家变大（如OpenPI的2B PaliGemma+更大action expert）时收益显著下降（1.71×），说明方法对架构比例敏感；可针对不同架构做自适应分组阈值。其五，缺乏与真实商业多租户训练平台或更强基线（如Punica/S-LoRA式多适配器批服务）的直接对比。

未来方向

作者提出的未来方向集中在四点。动态资源调整：让运行时信号动态调整服务路由与资源分配而不改变用户可见的算法语义，响应队列压力、模拟器时延与租户优先级。定价与产品化：设计用量计费与优先级感知定价，平衡租户成本、平台利用率与服务保证。用户灵活性与隔离：为用户提供多种迁移路径（平台模拟器、上传Docker、外部环境API、覆盖数据处理/奖励/rollout/训练代码），并定义安全扩展点、沙箱规则、攻击检测与性能契约；异构VLA SFT的schema canonicalization也需谨慎处理mask、动作维度、相机槽位与状态约定。服务感知算法设计：在租户许可与隐私保护下跨用户检测相关数据集/任务/动作schema，用于数据增强、迁移或更好初始化，并设计基于观察到的schema、批大小、截止期与资源压力的动态训练分组调度器。基于成果可延伸的方向还包括：把组批扩展到训练队列的梯度聚合、与Punica/S-LoRA式多适配器服务融合、以及在异构加速器拓扑下的弹性placement。

复现评估

复现评估：论文未提供公开代码仓库或镜像，附录A给出高层API伪代码（rollout/actor异步循环、阶段租约与陈旧度检查），但核心的Master Service、Twinkle系统、RLinf客户端工作流、训练/推理队列实现均为内部系统，难以直接复现。数据方面，实验用的是公开的LeRobot风格数据集LIBERO（modelscope lerobot/libero）与CALVIN（Koorye/calvin-abc-d-lerobot），以及公开模型StarVLA（QwenGR00T/QwenOFT）、OpenPI（π0.5），这些可获取。算力门槛明确：真实负载实验需单8-GPU节点做2-2-4布局，组批实验涉及2B/4B/8B三种QwenGR00T规模，对中等规模团队可承担但需多卡。关键超参（actor微批256、推理批上限128、每RL租户最多2在途作业、rollout每租户1/全局3、陈旧度界128微批、SFT预取16批）已披露，足以构想复现路径，但因依赖未开源的调度与服务内核，端到端复现难度高，更适合复现其组批前向加速的受控子实验。

论文图表

Adapted from Figure 2 of StarVLA. Representative VLA model structures
Figure 1: Adapted from Figure 2 of StarVLA. Representative VLA model structures

展示四类典型VLA结构：StarVLA-FAST（FAST头）、StarVLA-OPT（MLP头）、StarVLA-GR00T（DiT流匹配头+噪声输入）及第四种变体。共同点是预训练视觉-语言基座（VL Foundation Model）接收图像与文本，再连接动作专用解码模块输出动作序列。

阐明了“冻结VLM基座+可插拔动作头”的Lego式分解，正是JoyNexus把基座常驻、动作模块按租户挂载这一设计的依据。

Figure 12: Per-tenant training-loss trajectories under group and serial execution

对比4个OpenPI(π0.5)租户（两LIBERO+两CALVIN、本地批2）在组批与串行下的逐租户训练损失曲线，组批曲线紧密贴合串行基线，均呈早期下降后稳定。

证明组批在共享前向的同时保持了各租户独立的模型与优化状态、不破坏逐租户优化行为，是正确性验证。