🤖 AI

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

JoyNexus is een verenigde, multi-tenant service voor post-training Vision-Language-Action (VLA) modellen die training, inferentie en omgevingscomponenten ontkoppelt om efficiëntie in het delen van resources, cross-tenant scheduling en groep-batching mogelijk te maken, waardoor de geaggregeerde GPU-tijd wordt verminderd en de benutting wordt verbeterd in vergelijking met traditionele geïsoleerde single-tenant uitvoering.

Oorspronkelijke auteurs: 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

Gepubliceerd 2026-07-20

📖 7 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: 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

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je een wereld voor waarin robots kunnen leren dingen te doen net als mensen: een rommelige kamer zien, de instructie "ruim op" begrijpen, en vervolgens uitzoeken hoe ze het speelgoed moeten oppakken. Dit is het opwindende vakgebied van Vision-Language-Action (VLA) modellen. Denk aan deze modellen als het brein van een robot dat ogen (visie), een stem (taal) en spieren (actie) combineert. Om een robot daadwerkelijk iets nuttigs te laten doen, moeten wetenschappers hem "post-trainen". Dit is als het nemen van een slimme student die algemene feiten kent en hem specifieke vaardigheden aanleren, zoals het strikken van een veter of het openen van een pot.

Het trainen van deze robotbreinen is echter ongelooflijk duur en ingewikkeld. Op dit moment, als een onderzoeker een robot wil trainen, moet hij meestal een enorme, dure computer (een GPU) helemaal voor zichzelf huren. Het is alsof je een hele privé-sportschool huurt om slechts een paar push-ups te doen; de machine staat stil terwijl je gewichten inlaadt of een pauze neemt, en je betaalt toch voor het hele uur. Deze "één robot, één sportschool"-aanpak is verspillend en maakt het voor veel mensen moeilijk om tegelijkertijd te experimenteren met robotleren.

Maak kennis met JoyNexus, een nieuw idee van onderzoekers van JD AI Infra en verschillende universiteiten. Zij stellen een "gedeelde sportschool" voor voor robotbreinen. In plaats van een hele computer te huren, kunnen meerdere onderzoekers dezelfde krachtige machine veilig en efficiënt delen. Het artikel introduceert een systeem dat werkt als een superintelligente coach, waardoor veel verschillende teams tegelijkertijd hun robots kunnen trainen zonder tegen elkaar aan te botsen. Door het werk slim te organiseren, suggereert JoyNexus dat we de totale tijd en energie die nodig is om deze robots te trainen, kunnen verminderen, waardoor geavanceerd robotleren sneller en goedkoper wordt voor iedereen.

De "Gedeelde Sportschool" voor Robotbreinen

Hoe werkt JoyNexus eigenlijk? Stel je een drukke, high-tech sportschool voor. In de oude manier, als je wilde trainen, huurde je een hele kamer met een loopband, gewichten en een spiegel, en jij was de enige die naar binnen mocht. Als je stopte om water te drinken of op je telefoon te kijken, bleef de kamer leeg, maar je betaalde nog steeds voor de hele tijd.

JoyNexus verandert de regels. Het verandert de sportschool in een bruisende, gedeelde ruimte met drie zones:

De Breinzone (Training Model Service): Hier vindt het zware werk plaats. Het "brein" van de robot (het grote, complexe deel dat afbeeldingen en woorden begrijpt) wordt op een centrale, gedeelde plek gehouden. Het is als een enorme, dure loopband die iedereen kan gebruiken.
De Spierzone (Action Module): Elke robot heeft zijn eigen unieke "spieren" of specifieke vaardigheden (zoals een grijper voor een klauw of een wiel voor een auto). In JoyNexus worden deze specifieke onderdelen voor elk team apart gehouden. Je brengt je eigen unieke gewichten mee naar de gedeelde loopband.
De Hindernisbaan (Environment Service): Dit is de simulator waar de robot oefent. Het kan een virtuele keuken zijn, een fabrieksvloer of een woonkamer.

De magie van JoyNexus zit in hoe het het verkeer beheert. Het gebruikt een "Master Service" (als een supergeorganiseerde sportschoolmanager) om te beslissen wie wanneer op de loopband mag. Als Team A wacht tot hun robot een simulatie heeft afgerond, en Team B klaar is om een wiskundige update uit te voeren, wisselt de manager hen direct om zodat de loopband nooit stopt met bewegen.

De "Group Batching" Truc

Een van de coolste functies is iets wat de auteurs group batching noemen. Stel je voor dat je in een koffiebar bent. Als één persoon een latte bestelt, moet de barista de machine starten, de bonen malen en de melk opschuimen, alleen voor die ene kop. Als tien mensen tegelijkertijd lattes bestellen, kan de barista genoeg bonen malen voor alle tien en één grote kan melk opschuimen, wat het proces per kop veel sneller maakt.

JoyNexus doet dit voor robottraining. Vaak sturen verschillende teams kleine verzoeken naar het gedeelde "brein" (het VLA-model). Als het systeem deze één voor één zou verwerken, zou de computer tijd verspillen door het starten en stoppen. In plaats daarvan wacht JoyNexus een fractie van een seconde om te zien of er nog andere verzoeken van andere teams zijn. Als dat zo is, groepeert het ze. Het draait het "gedeelde brein"-gedeelte één keer voor hen allemaal, en splitst de resultaten daarna weer op naar elk team om hun specifieke "spiertraining" te voltooien.

Het artikel laat zien dat dit heel goed werkt wanneer veel teams kleine batches data versturen. In hun simulaties, wanneer ze verzoeken van 8 verschillende teams groepeerden, verbeterde de snelheid van de gedeelde "forward pass" (het deel waar het brein naar de data kijkt) aanzienlijk. Voor sommige modellen maakte dit het gedeelde deel van de training 2,21 keer sneller dan wanneer het één voor één zou gebeuren.

Wat Ze Vonden (en Wat Ze Niet Vonden)

De onderzoekers testten JoyNexus door een scenario te simuleren met vier verschillende teams: drie teams die robots trainen om taken uit te voeren in virtuele omgevingen (zoals het verplaatsen van blokken in een simulatie genaamd LIBERO of ManiSkill) en één team dat alleen oefent met een statische dataset (Supervised Fine-Tuning).

Ze vergeleken deze "gedeelde sportschool"-aanpak met de oude "privé-sportschool"-methode waarbij elk team zijn taken één na de ander uitvoerde. De resultaten waren veelbelovend:

Minder Verspilling: Door het werk te overlappen, verminderde JoyNexus de totale "GPU-tijd" (de tijd dat de dure computer draaide) met 28,3%.
Betere Benutting: De gedeelde computers waren 41,3% van de tijd bezig in de multi-tenant opstelling, vergeleken met slechts 20,8% in de geïsoleerde opstelling. Dat is bijna twee keer zo efficiënt!
Geen Verwarring: Cruciaal is dat het systeem alles veilig hield. Zelfs al deelden de teams het grote brein, hun specifieële "spieren", hun data en hun voortgang waren volledig geïsoleerd. Het artikel laat zien dat de leercurves (hoe snel de robots beter werden) voor elk team exact hetzelfde waren als wanneer ze alleen hadden getraind.

Het is belangrijk om op te merken dat deze resultaten afkomstig zijn van simulaties en workload-tests, niet van een echte wereldimplementatie van duizenden robots. De auteurs suggereren dat deze aanpak zou kunnen geld en tijd besparen, maar ze hebben nog niet bewezen dat het in elke mogelijke echte werkelijkheid perfect zal werken. Ze wijzen er ook op dat hoewel het systeem geweldig is in het delen van middelen, het momenteel vertrouwt op gebruikers die zich aan specifieke regels houden over hoe ze hun data formatteren. Als een team een totaal vreemd, aangepast robotontwerp wil gebruiken dat niet in de standaard "sportschoolregels" past, kan het moeilijker zijn om erbij te passen.

De Toekomst van Robottraining

Het artikel concludeert dat JoyNexus een grote stap is naar het toegankelijk maken van robotleren. In plaats van een miljoen dollar nodig te hebben om een privé-supercomputer te huren, zouden onderzoekers potentieel alleen kunnen betalen voor de tijd die ze daadwerkelijk gebruiken, door de kosten te delen met anderen.

De auteurs zijn echter realistisch. Ze geven toe dat voor dit in de echte wereld te laten werken, we betere manieren nodig hebben om beveiliging te beheren (zodat één team niet per ongeluk de robot van een ander kapotmaakt), prijsstelling (hoeveel te rekenen voor gedeelde tijd) en flexibiliteit (gebruikers hun eigen vreemde simulators laten meebrengen). Ze suggereren dat toekomstige versies van het systeem nog slimmer kunnen worden door middelen automatisch aan te passen op basis van hoe druk de sportschool is.

Kortom, JoyNexus suggereert dat de toekomst van robottraining niet gaat over het bouwen van grotere, geïsoleerde vestingen voor elke onderzoeker. Het gaat over het bouken van een bruisend, efficiënt gemeenschapscentrum waar iedereen samen kan leren, de dure apparatuur kan delen en hun robots sneller in beweging kan krijgen dan ooit tevoren.

Technische Samenvatting: JoyNexus – Service-georiënteerde Multi-tenant Post-training voor VLA-modellen

1. Probleemstelling

De post-training van Vision-Language-Action (VLA) modellen is cruciaal voor het aanpassen van foundation modellen aan diverse robotische belichamingen, simulators en taakdoelstellingen. De huidige cloud computing-paradigma's voor VLA-training kampen echter met aanzienlijke inefficiënties:

Infrastructuurbelasting: Bestaande diensten alloceren doorgaans exclusieve GPU/CPU-bronnen aan een enkele tenant (ofwel via directe verhuur, ofwel via batch-indiening). Dit dwingt gebruikers om complexe infrastructuurafhankelijkheden te beheren, inclusief heterogene modelomgevingen en simulator-sessies.
Resource-inefficiëntie: VLA-modellen zijn vaak beperkt in schaal, wat leidt tot een slechte accelerator-benutting in gedistribueerde opstellingen. Bovendien is het vaste "card-hour" prijsmodel inefficiënt voor korte, iteratieve of grillige workloads die gebruikelijk zijn bij VLA-ontwikkeling (bijv. tijdens rollout, data loading of omgeving-synchronisatie), waarbij GPU's vaak idle blijven.
Gebrek aan Gespecialiseerde Abstracties: Hoewel "Tinker-stijl" service-georiënteerde systemen bestaan voor taalmodel post-training (bijv. OpenTinker, ProRL Agent), adresseren zij niet de specifieke vereisten van VLA post-training, die betrokken is bij simulator-sessies, heterogene actie-schema's, rollout-records en policy-versie-synchronisatie.

2. Methodologie: De JoyNexus Architectuur

JoyNexus herformuleert VLA post-training als een verenigde, multi-tenant service. Het ontkoppelt de Training Model Service, de Inference Model Service en de Environment Service, waardoor tenants toegang hebben tot deze via API's terwijl de provider de gedeelde infrastructuur beheert.

2.1 Kernprincipes van het Ontwerp

Decompositie: Geïnspireerd door de "Lego-stijl" decompositie van modellen zoals StarVLA, scheidt JoyNexus de dure, herbruikbare gedeelde VLM backbone (aanwezig in het geheugen) van de tenant-specifieke actie-modules (adapters, action heads, of policy suffixes).
Service-scheiding:
- Training Model Service: Beheert de gedeelde base model en de tenant-specifieke trainingsstatussen (optimizers, policy versies).
- Inference Model Service: Afhandeling van inference-verzoeken, waarbij de tenant-geïndexeerde serving-statussen worden onderhouden en de geüpdatete parameters worden gesynchroniseerd.
- Environment Service: Beheert interactieve sessies (simulators) en offline datasets, waarbij zowel online interactie als offline data-toegang worden geabstraheerd.
Dual-Queue Scheduling: Het systeem maakt gebruik van een Training Queue en een Inference Queue. Dit ontkoppelt de optimalisatie-datastroom van de latency-gevoelige voorspellingsverzoeken, waardoor gelijktijdige scheduling van Supervised Fine-Tuning (SFT), Reinforcement Learning (RL) en evaluatie mogelijk is.

2.2 Workflow Orchestratie

JoyNexus ondersteunt drie primaire workflows via een Master Service die de intentie van de gebruiker compileert naar backend-configuraties:

Supervised Fine-Tuning (SFT): Tenants leveren offline demonstratie-datasets aan. Het systeem samplet batches, voert het VLA-model uit, berekent de loss en werkt de tenant-specifieke modules bij.
Reinforcement Learning (RL): Een gesloten lus waarbij de policy interageert met een omgeving (via de Environment Service), rollout-records genereert en de policy bijwerkt. De rollout-producer en de actor (trainer) draaien als gelijktijdige lussen en communiceren enkel via de Training Queue.
Evaluatie: Een read-only proces dat een specifieke policy-versie laadt, inference uitvoert tegen een omgeving of dataset, en metrieken registreert zonder parameters bij te werken.

2.3 Multi-Tenant Group Batching

Om de inefficiëntie van kleine, sporadische inference-verzoeken aan te pakken, introduceert JoyNexus group batching voor heterogene VLA-data-schema's.

Mechanisme: Compatibele verzoeken van verschillende tenants worden genormaliseerd naar een gedeelde prefix-representatie (de VLAFeature). Een enkele forward pass wordt uitgevoerd over de gegroepeerde samples voor de gedeelde frozen backbone.
Partitionering: De resulterende features worden vervolgens teruggepartitioneerd naar tenant-specifieke actie-modules voor loss-berekening, backward passes en optimizer-updates.
Scheduling: De Inference Scheduler accumuleert verzoeken op basis van een maximale wachttijd ( $T$ ) en een doel-batchgrootte ( $B$ ) voordat de inference wordt getriggerd, wat een hoge benutting garandeert zonder latency-gevoelige verzoeken oneindig te blokkeren.

2.4 Systeemrobuustheid

Foutisolatie: Een toegewezen Health Manager monitort de services. Gelokaliseerde fouten triggeren in-place restarts van specifieke rollen (bijv. een gefaalde rollout worker) zonder de volledige workload te herstarten of andere tenants te beïnvloeden.
Elastische Schaling: Inference en training services kunnen onafhankelijk van elkaar schalen. Rollout-engines kunnen asynchroon worden toegevoegd of verwijderd om aan de eisen van omgeving-interactie te voldoen zonder het optimalisatieproces te onderbreken.

3. Belangrijkste Bijdragen

Client-Server Service Abstractie: Een nieuwe architectuur die de private computation van de tenant (actie-modules, optimizers) scheidt van de gedeelde infrastructuur (base modellen, omgevingen), waarbij workload-isolatie behouden blijft terwijl fijnmazige resource-scheduling mogelijk is.
Drie-componenten Backend: Een verenigde backend die SFT, RL en evaluatie ondersteunt, waarbij de base modellen in het geheugen blijven en tenant-specifieke modules in geïsoleerde slots worden gemount.
Group Batching voor Heterogene Schema's: Een pipeline die een enkele gedeelde backbone forward pass mogelijk maakt over gegroepeerde samples van verschillende tenants met compatibele data-schema's, wat de throughput aanzienlijk verbetert voor kleine-batch workloads.
Empirische Validatie: Demonstratie van verbeterde resource-benutting en verminderde geaggregeerde GPU-tijd vergeleken met geïsoleerde single-tenant executie.

4. Experimentele Resultaten

De auteurs evalueerden JoyNexus via workload-simulatie en een group-batching pipeline in realistische embodied scenario's.

Resource Efficiëntie: In een simulatie met drie RL-tenants en één SFT-tenant op een 8-GPU node, verminderde JoyNexus de geaggregeerde GPU-tijd met 28,3% vergeleken met een sequentiële single-tenant baseline.
- Training Model Service Benutting: Verhoogd van 20,8% (geïsoleerd) naar 41,3% (multi-tenant), een verbetering van 1,99×.
- Inference Model Service Benutting: Verhoogd van 28,1% naar 37,5%, een verbetering van 1,33×.
Group Batching Prestaties:
- Experimenten met 2–8 tenants en variërende lokale batchgroottes toonden aan dat group batching effectiever wordt naarmate het aantal tenants toeneemt en de lokale batchgroottes afnemen.
- Voor modellen zoals StarVLA-GR00T (2B, 4B, 8B), zorgde group executie voor significante versnellingen in de forward-fase (tot wel 3,24× voor StarVLA-OFT met 8 tenants), primair door de kosten van de gedeelde base model forward pass te amorteren.
Trainingscorrectheid: Analyse van de loss-trajecten bevestigde dat group executie het per-tenant optimalisatiegedrag behoudt. Tenants die getraind werden op verschillende datasets (LIBERO vs. CALVIN) met aparte actie-heads en optimizers vertoonden verwachte loss-descent patronen die identiek zijn aan de seriële executie-baselines.

5. Betekenis en Claims

Het artikel stelt dat JoyNexus een belangrijke stap vormt richting programmeerbare, multi-tenant VLA post-training services. De primaire betekenis ligt in:

Verschuiving van de Last: Het bevrijdt tenants van laag-niveau infrastructuurzorgen (resource-allocatie, model-residency, synchronisatie), waardoor zij zich kunnen concentreren op algoritme-ontwikkeling.
Economische en Technische Efficiëntie: Door cross-tenant scheduling op gedeelde resources mogelijk te maken, adresseert het de inefficiëntie van vaste card-hour prijzen voor grillige VLA-workloads, waardoor high-performance training toegankelijker en kosteneffectiever wordt.
Schaalbaarheid: Het service-georiënteerde ontwerp ondersteunt de gelijktijdige scheduling van diverse workloads (SFT, RL, evaluatie) die voorheen moeilijk gezamenlijk te orkestreren waren vanwege heterogene omgeving- en datavereisten.

De auteurs merken op dat hoewel de huidige prototype deze abstracties grond in bestaande workflows (RLinf, StarVLA) legt, toekomstig werk de dynamische resource-aanpassing, prijsmechanismen en veilige extensiepunten voor door de gebruiker verstrekte code en omgevingen zal verkennen.