JoyNexus turns VLA post-training into a shared service

JoyNexus treats VLA post-training as a shared service instead of a collection of reserved machines.

The system separates training, inference, and environment services. A shared base model stays resident while each tenant keeps private action modules, optimizer state, rollout records, and policy versions. Tenants can call semantic APIs for supervised fine-tuning, reinforcement learning, rollout, and evaluation. 1

Robot-model workloads are often small, bursty, and uneven. JoyNexus groups compatible requests that share a model-facing prefix, runs one backbone forward pass, then routes the outputs back to the right tenant. In the paper's workload simulation, this reduced aggregate GPU time by 28.3% and raised GPU-time efficiency by 1.39x. Average training-service GPU utilization moved from 20.8% to 41.3%; inference moved from 28.1% to 37.5%. These are simulation results, not a production-throughput guarantee. 1

Start with OpenVLA 7B in a represented simulator or robot setup. Keep the base model loaded, store trainable state by tenant, add FIFO queues with a target batch size and maximum wait, and split each shared forward pass back into tenant outputs. OpenVLA's public model card includes the checkpoint and training code, and describes an image-plus-language input that returns robot actions. 2

Measure GPU utilization, aggregate GPU time, queue wait, and per-tenant loss before adding more infrastructure. One hard limit remains: OpenVLA says unseen robot embodiments need demonstrations and fine-tuning, so start in a supported simulation or collect a small dataset. 2

The interesting product decision is where to put the boundary: share the expensive backbone, keep tenant-specific state private, and make the scheduler visible enough to debug.