Skip to content

JoyNexus: Service-Oriented Multi-Tenant Post-Training for VLA Models

🕒 Published (v1): 2026-07-17 00:00 UTC · Source: HuggingFace · link

Why this paper was selected

Multi-tenant post-training service for VLA; novel deployment angle; Wentao Zhang group

Ask a follow-up

Open an assistant pre-loaded with this paper's context.

💬 Ask ChatGPT✦ Ask Claude

TL;DR

JoyNexus is a multi-tenant service framework for post-training Vision-Language-Action (VLA) models that decouples Training, Inference, and Environment services, allowing many tenants to share a resident VLM backbone while keeping their action modules, optimizer states, and policy versions isolated. The key efficiency mechanism is group batching, which enables a single shared backbone forward pass over grouped samples from heterogeneous tenants whose data schemas share a compatible model-facing prefix. Compared to isolated single-tenant execution, JoyNexus reduces aggregate GPU time and improves service utilization.

Problem

Existing cloud compute paradigms (dedicated GPU rental or batch job submission) allocate exclusive resources per tenant. For VLA post-training—which involves bursty, iterative workloads across heterogeneous simulators, embodiments, and task objectives—this results in poor GPU utilization (idle during rollout, data loading, evaluation) and places the burden of managing complex distributed infrastructure on individual users. No prior Tinker-style service framework targeted the full VLA post-training ecosystem (SFT + RL + rollout + evaluation).

Method

JoyNexus separates concerns into three resident execution services behind a Master Service control plane:

  1. Training Model Service: Keeps the shared VLM backbone memory-resident; per-tenant slots hold action modules, optimizer states, and policy versions. A Training Scheduler activates one tenant slot at a time, performs an update, and exports only the tenant's parameter payload (not the backbone).
  2. Inference Model Service: Maintains tenant-indexed serving states; synchronizes updated action-module weights from training; exposes predict and rollout primitives.
  3. Environment Service: Provides session-based reset/step/close for online simulators (LIBERO, ManiSkill, RoboTwin) and a data-producer path for offline SFT datasets; feeds observations to the Inference Queue and returns actions.

The Master Service validates tenant workload specs, derives a deterministic schema signature, compiles specs into backend configurations, and manages two queues: a Training Queue (connects rollout/SFT producers to the training consumer) and an Inference Queue (routes latency-sensitive prediction requests). APIs are two-layered: low-level primitives (train_batch, predict, queue_put/get, etc.) and high-level semantic declarations (RL, SFT, evaluation) compiled by the Master Service.

Group batching: Tenant samples whose data schemas share a compatible model-facing prefix (e.g., same VLM backbone input format) are grouped so a single backbone forward pass covers all of them; only the subsequent action-module heads diverge per tenant. This avoids redundant backbone compute across heterogeneous requests.

Additional mechanisms: centralized Health Manager for partial per-role restarts on failure, and asynchronous elastic scaling of rollout engines without interrupting the training path.

Key Contributions

  • First Tinker-style service framework covering the complete VLA post-training ecosystem (SFT, RL, rollout, evaluation, parameter export, inference synchronization).
  • Client-server service abstraction that isolates tenant-private computation (action modules, optimizer state, policy versions) from shared infrastructure (VLM backbone), with the server controlling resource allocation, placement, and routing.
  • Three-component backend (Training Model Service, Inference Model Service, Environment Service) with a unified scheduling layer (Training Queue + Inference Queue) supporting concurrent multi-tenant workloads.
  • Group batching for heterogeneous VLA data schemas that share a compatible model-facing prefix, enabling one backbone forward pass per group rather than per tenant.
  • Fault isolation via partial in-place role restart and elastic asynchronous rollout scaling without modifying tenant training logic.

Results

  • Compared to isolated single-tenant serial workload processing, JoyNexus achieves higher GPU utilization and reduces aggregate GPU time via cross-tenant scheduling on shared resources (evaluated through workload simulation and a group-batching pipeline in a realistic embodied scenario).
  • Specific numeric throughput or speedup figures are not present in the provided text excerpt.

Limitations

  • No new VLA model, training objective, or benchmark is proposed; JoyNexus is purely infrastructure.
  • Quantitative benchmark numbers (exact GPU-hour reductions, throughput comparisons) are not provided in the available text.
  • Group batching applies only when tenants share a compatible model-facing prefix; tenants with entirely different backbone architectures cannot be co-batched.
  • The current design's tenant-specific modules "primarily instantiate action experts," implying full backbone fine-tuning across tenants is not the primary supported mode.
  • The paper does not address security boundaries between tenants (data leakage through shared backbone activations or gradient side-channels).

Relevance to Vision-Language Models

JoyNexus directly targets the infrastructure layer of VLM-backbone-based embodied models, exploiting the common pattern where the VLM backbone is frozen and reused across tasks while only action heads are updated. The group batching technique is a practically important optimization for scenarios where multiple VLA variants share the same underlying VLM (e.g., different fine-tunes of the same LLaVA or Qwen-VL base), a pattern becoming ubiquitous as organizations deploy fleets of task-specific VLA agents. For researchers tracking VLMs, this paper highlights how parameter-efficient post-training (frozen VLM + lightweight action head) enables resource sharing that is infeasible when the full model is tenant-owned, pointing to a broader trend of VLM-as-shared-backbone infrastructure for downstream embodied and agentic tasks.