🤖 AI

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

JoyNexus è un servizio unificato e multi-tenant per modelli Vision-Language-Action (VLA) post-addestramento che disaccoppia i componenti di addestramento, inferenza e ambiente per abilitare la condivisione efficiente delle risorse, lo scheduling cross-tenant e il batching di gruppo, riducendo così il tempo GPU aggregato e migliorando l'utilizzo rispetto alla tradizionale esecuzione isolata a singolo tenant.

Autori originali: 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

Pubblicato 2026-07-20

📖 7 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: 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

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immaginate un mondo in cui i robot possono imparare a fare le cose proprio come gli esseri umani: vedere una stanza disordinata, comprendere l'istruzione "pulisci" e poi capire come raccogliere i giocattoli. Questo è l'eccitante campo dei modelli Vision-Language-Action (VLA). Pensate a questi modelli come al cervello di un robot che combina occhi (visione), una voce (linguaggio) e muscoli (azione). Per far sì che un robot faccia effettivamente qualcosa di utile, gli scienziati devono "post-addestrarlo". Questo è come prendere uno studente intelligente che conosce fatti generali e insegnargli abilità specifiche, come allacciarsi le scarpe o aprire un barattolo.

Tuttamente, insegnare a questi cervelli robotici è incredibilmente costoso e complicato. Attualmente, se un ricercatore vuole addestrare un robot, di solito deve affittare un computer enorme ed costoso (una GPU) tutto per sé. È come affittare un'intera palestra privata solo per fare qualche flessione; la macchina rimane inattiva mentre carichi i pesi o aspetti una pausa, e comunque paghi per l'intera ora. Questo approccio "un robot, una palestra" è uno spreco e rende difficile per molte persone sperimentare con l'apprendimento robotico contemporaneamente.

Entra in gioco JoyNexus, un'idea nuova proposta dai ricercatori di JD AI Infra e diverse università. Propongono una "palestra condivisa" per i cervelli dei robot. Invece di affittare un intero computer, più ricercatori possono condividere la stessa macchina potente in modo sicuro ed efficiente. Il documento presenta un sistema che agisce come un coach super intelligente, permettendo a molti team diversi di addestrare i propri robot simultaneamente senza scontrarsi tra loro. Organizzando il lavoro in modo intelligente, JoyNexus suggerisce che possiamo ridurre il tempo totale e l'energia necessari per addestrare questi robot, rendendo l'apprendimento robotico avanzato più veloce e meno costoso per tutti.

La "Palestra Condivisa" per i Cervelli dei Robot

Quindi, come funziona davvero JoyNexus? Immaginate una palestra frenetica e hi-tech. Nel vecchio metodo, se volete allenarvi, affittate un'intera stanza con un tapis roulant, pesi e uno specchio, e sarete gli unici autorizzati a entrare. Se vi fermate per bere acqua o controllare il telefono, la stanza rimane vuota, ma pagate comunque per tutto il tempo.

JoyNexus cambia le regole. Trasforma la palestra in uno spazio condiviso e vivace con tre zone principali:

La Zona del Cervello (Servizio di Addestramento del Modello): Qui avviene il lavoro pesante. Il "cervello" del robot (la parte grande e complessa che comprende immagini e parole) è mantenuto in un punto centrale e condiviso. È come un tapis roulant gigante ed estremamente costoso che tutti possono usare.
La Zona dei Muscoli (Modulo d'Azione): Ogni robot ha i suoi "muscoli" unici o abilità specifiche (come una pinza per un artiglio o una ruota per un'auto). In JoyNexus, queste parti specifiche sono tenute separate per ogni team. Portate i vostri pesi unici sul tapis roulant condiviso.
Il Percorso a Ostacoli (Servizio di Ambiente): Questo è il simulatore dove il robot si esercita. Potrebbe essere una cucina virtuale, un pavimento di fabbrica o un soggiorno.

La magia di JoyNexus sta nel modo in cui gestisce il traffico. Utilizza un "Servizio Master" (come un gestore di palestra super organizzato) per decidere chi va sul tapis roulant e quando. Se il Team A è in attesa che il proprio robot finisca una simulazione, e il Team B è pronto per fare un aggiornamento matematico, il manager li scambia istantaneamente in modo che il tapis roulant non si fermi mai.

Il Trucco del "Group Batching"

Una delle caratteristiche più interessanti è qualcosa che gli autori chiamano group batching (raggruppamento per lotti). Immaginate di essere in un bar. Se una persona ordina un latte macchiato, il barista deve avviaar la macchina, macinare i chicchi e montare il latte solo per quella singola tazza. Se dieci persone ordinano lattea macchiato contemporaneamente, il barista può macinare abbastanza chicchi per tutte e dieci e montare un unico grande contenitore di latte, rendendo il processo molto più veloce per ogni tazza.

JoyNexus fa questo per l'addestramento dei robot. Spesso, diversi team inviano piccole richieste al "cervello" condiviso (il modello VLA). Se il sistema elaborasse le richieste una alla volta, il computer sprecherebbe tempo avviandosi e fermandosi. Inveve, JoyNexus aspetta una frazione di secondo per vedere se altri team hanno richieste. Se ne hanno, le raggruppa. Esegue la parte del "cervello condiviso" una sola volta per tutti loro, poi suddivide i risultati per tornare a ciascun team per finire l'addestramento dei propri "muscoli" specifici.

Il documento mostra che questo funziona molto bene quando molti team inviano piccoli lotti di dati. Nelle loro simulazioni, quando hanno raggruppato le richieste di 8 team diversi, la velocità della "passata in avanti" condivisa (la parte in cui il cervello guarda i dati) è migliorata significativamente. Per alcuni modelli, questo ha reso la parte condivisa dell'addestramento 2,21 volte più veloce rispetto al farlo uno alla volta.

Cosa Hanno Trovato (e Cosa Non Hanno Trovato)

I ricercatori hanno testato JoyNexus simulando uno scenario con quattro team diversi: tre team che addestrano robot per compiti in ambienti virtuali (come spostare blocchi in una simulazione chiamata LIBERO o ManiSkill), e un team che si esercita semplicemente con un dataset statico (Supervised Fine-Tuning).

Hanno confrontato questo approccio della "palestra condivisa" con il vecchio metodo della "palestra privata" in cui ogni team eseguiva i propri compiti uno dopo l'altro. I risultati sono promettenti:

Meno Sprechi: Sovrapponendo il lavoro, JoyNexus ha ridotto il "tempo GPU" totale (il tempo in cui il costoso computer era in funzione) del 28,3%.
Migliore Utilizzo: I computer condivisi sono stati occupati il 41,3% del tempo nella configurazione multi-tenant, rispetto al solo 20,8% nella configurazione isolata. È quasi il doppio dell'efficienza!
Nessuna Confusione: Fondamentalmente, il sistema ha mantenuto tutto al sicuro. Anche se i team condividevano il grande cervello, i loro "muscoli" specifici, i loro dati e i loro progressi erano completamente isolati. Il documento mostra che le curve di apprendimento (quanto velocemente i robot diventavano bravi) per ogni team erano esattamente le stesse che avrebbero avuto se si fossero addestrati da soli.

È importante notare che questi risultati derivano da simulazioni e test di carico di lavoro, non da un dispiegamento reale di migliaia di robot. Gli autori suggeriscono che questo approccio potrebbe risparmiare denaro e tempo, ma non hanno ancora dimostrato che funzionerà perfettamente in ogni possibile scenario del mondo reale. Evidenziano anche che, sebbene il sistema sia ottimo nel condividere le risorse, attualmente si basa sul fatto che gli utenti rispettino regole specifiche su come formattare i propri dati. Se un team volesse usare un design di robot totalmente strano e personalizzato che non rientra nelle regole standard della "palestra", potrebbe essere più difficile integrarsi.

Il Futuro dell'Addestramento Robotico

Il documento conclude che JoyNexus è un grande passo verso la rendere l'apprendimento robotico accessibile. Invece di aver bisogno di un milione di dollari per affittare un supercomputer privato, i ricercatori potrebbero potenzialmente pagare solo per il tempo che effettivamente utilizzano, condividendo i costi con altri.

Tuttavia, gli autori sono realistici. Ammettono che, affinché questo funzioni nel mondo reale, abbiamo bisogno di modi migliori per gestire la sicurezza (perché un team non danneggi accidentalmente il robot di un altro), il prezzo (quanto addebitare per il tempo condiviso) e la flessibilità (permettere agli utenti di portare i propri simulatori particolari). Suggeriscono che le versioni future del sistema potrebbero diventare ancora più intelligenti, regolando automaticamente le risorse in base a quanto è impegnata la palestra.

In breve, JoyNexus suggerisce che il futuro dell'addestramento dei robot non è costruire fortezze più grandi e isolate per ogni ricercatore. Si tratta di costruire un centro comunitario vivace ed efficiente dove tutti possono imparare insieme, condividere l'attrezzatura costosa e far muovere i propri robot più velocemente che mai.

Riepilogo Tecnico: JoyNexus – Servizio Orientato ai Servizi Multi-Tenant per il Post-Training di Modelli VLA

1. Definizione del Problema

Il post-training di modelli Vision-Language-Action (VLA) è fondamentale per adattare i modelli di base a diversi embodiment robotici, simulatori e obiettivi di task. Tuttavia, gli attuali paradigmi di calcolo nel cloud per il post-training dei VLA presentano significative inefficienze:

Onere Infrastrutturale: I servizi esistenti tipicamente allocano risorse esclusive GPU/CPU a un singolo tenant (sia tramite noleggio diretto che tramite sottomissione di batch). Ciò costringe gli utenti a gestire complesse dipendenze infrastrutturali, inclusi ambienti di modelli eterogenei e sessioni di simulazione.
Inefficienza delle Risorse: I modelli VLA sono spesso di scala moderata, il che porta a una scarsa utilizzazione degli acceleratori nelle configurazioni distribuite. Inoltre, il modello di prezzo fisso "a ore di scheda" è inefficiente per carichi di lavoro brevi, iterativi o a raffiche (bursty), comuni nello sviluppo VLA (ad esempio, durante il rollout, il caricamento dei dati o la sincronizzazione dell'ambiente), dove le GPU rimangono spesso inattive.
Mancanza di Astrazioni Specializzate: Sebbene esistano sistemi orientati ai servizi in stile "Tinker" per il post-training di modelli linguistici (ad esempio, OpenTinker, ProRL Agent), essi non affrontano i requisiti specifici del post-training dei VLA, che comporta sessioni di simulazione, schemi di azione eterogenei, record di rollout e sincronizzazione delle versioni delle policy.

2. Metodologia: L'Architettura JoyNexus

JoyNexus inquadra il post-training dei VLA come un servizio unificato e multi-tenant. Decoppia il Servizio del Modello di Training, il Servizio del Modello di Inferenza e il Servizio dell'Ambiente, consentendo ai tenant di accedere a questi tramite API mentre il provider gestisce l'infrastruttura condivisa.

2.1 Principi di Design Core

Decomposizione: Ispirandosi alla decomposizione "stile Lego" di modelli come StarVLA, JoyNexus separa il backbone VLM condiviso (residente in memoria), che è costoso e riutilizzabile, dai moduli di azione specifici del tenant (adapter, teste di azione o suffissi della policy).
Separazione dei Servizi:
- Servizio del Modello di Training: Mantiene il modello base condiviso e gli stati di training specifici del tenant (ottimizzatori, versioni della policy).
- Servizio del Modello di Inferenza: Gestisce le richieste di inferenza, mantenendo gli stati di serving indicizzati per tenant e sincronizzando i parametri aggiornati.
- Servizio dell'Ambiente: Gestisce le sessioni interattive (simulatori) e i dataset offline, astrendo sia l'interazione online che l'accesso ai dati offline.
Scheduling a Doppia Coda: Il sistema utilizza una Coda di Training e una Coda di Inferenza. Questo decoppia il flusso di dati di ottimizzazione dalle richieste di predizione sensibili alla latenza, permettendo lo scheduling concorrente di Supervised Fine-Tuning (SFT), Reinforcement Learning (RL) ed valutazione.

2.2 Orchestrazione del Workflow

JoyNexus supporta tre workflow primari attraverso un Master Service che compila l'intento dell'utente in configurazioni di backend:

Supervised Fine-Tuning (SFT): I tenant forniscono dataset di dimostrazione offline. Il sistema campiona i batch, esegue il modello VLA, calcola la perdita e aggiorna i moduli specifici del tenant.
Reinforcement Learning (RL): Un ciclo chiuso in cui la policy interagisce con un ambiente (tramite il Servizio dell'Ambiente), genera record di rollout e aggiorna la policy. Il produttore di rollout e l'attore (trainer) girano come cicli concorrenti, comunicando solo tramite la Coda di Training.
Valutazione: Un processo di sola lettura che carica una specifica versione della policy, esegue l'inferenza contro un ambiente o un dataset e registra le metriche senza aggiornare i parametri.

2.3 Group Batching Multi-Tenant

Per affrontare l'inefficienza delle piccole e sporadiche richieste di inferenza, JoyNexus introduce il group batching per schemi di dati VLA eterogenei.

Meccanismo: Le richieste compatibili provenienti da diversi tenant vengono normalizzate a una rappresentazione a prefisso condiviso (la VLAFeature). Un singolo passaggio in avanti (forward pass) viene eseguito sul backbone condiviso congelato per i campioni raggruppati.
Partizionamento: Le feature risultanti vengono poi partizionate nuovamente verso i moduli di azione specifici del tenant per il calcolo della perdita, i passaggi all'indietro (backward passes) e gli aggiornamenti dell'ottimizzatore.
Scheduling: L'Inference Scheduler accumula le richieste in base a un tempo di attesa massimo ( $T$ ) e a una dimensione del batch target ( $B$ ) prima di attivare l'inferenza, garantendo un'alta utilizzazione senza bloccare indefinitamente le richieste sensibili alla latenza.

2.4 Robustezza del Sistema

Isolamento dei Guasti: Un Health Manager dedicato monitora i servizi. I guasti localizzati innescano riavvii in loco di ruoli specifici (ad esempio, un worker di rollout fallito) senza riavviare l'intero carico di lavoro o influenzare altri tenant.
Scalabilità Elastica: I servizi di inferenza e di training possono scalare indipendentemente. I motori di rollout possono essere aggiunti o rimossi asincronamente per adattarsi alle richieste di interazione con l'ambiente senza interrompere il processo di ottimizzazione.

3. Contributi Chiave

Astrazione Servizio Client-Server: Un'architettura innovativa che separa il calcolo privato del tenant (moduli di azione, ottimizzatori) dall'infrastruttura condivisa (modelli base, ambienti), mantenendo l'isolamento del carico di lavoro pur consentendo uno scheduling delle risorse granulare.
Backend a Tre Componenti: Un backend unificato che supporta SFT, RL e valutazione, dove i modelli base rimangono residenti in memoria e i moduli specifici del tenant vengono montati in slot isolati.
Group Batching per Schemi Eterogenei: Una pipeline che consente un singolo forward pass del backbone condiviso attraverso campioni raggлотti da diversi tenant con schemi di dati compatibili, migliorando significativamente il throughput per i carichi di lavoro a piccoli batch.
Validazione Empirica: Dimostrazione di una migliore utilizzazione delle risorse e di una riduzione del tempo GPU aggregato rispetto all'esecuzione isolata a singolo tenant.

4. Risultati Sperimentali

Gli autori hanno valutato JoyNexus attraverso la simulazione di carichi di lavoro e una pipeline di group-batching in scenari incarnati (embodied) realistici.

Efficienza delle Risorse: In una simulazione con tre tenant RL e un tenant SFT su un nodo con 8 GPU, JoyNexus ha ridotto il tempo GPU aggregato del 28,3% rispetto a un baseline a singolo tenant sequenziale.
- Utilizzazione del Servizio del Modello di Training: È aumentata dal 20,8% (isolato) al 41,3% (multi-tenant), un miglioramento di 1,99×.
- Utilizzazione del Servizio del Modello di Inferenza: È aumentata dal 28,1% al 37,5%, un miglioramento di 1,33×.
Prestazioni del Group Batching:
- Gli esperimenti con 2–8 tenant e dimensioni di batch locali variabili hanno mostrato che il group batching diventa sempre più efficace all'aumentare del numero di tenant e al diminuire delle dimensioni dei batch locali.
- Per modelli come StarVLA-GR00T (2B, 4B, 8B), l'esecuzione di gruppo ha fornito accelerazioni significative nella fase di forward (fino a 3,24× per StarVLA-OFT con 8 tenant), principalmente ammortizzando il costo del forward pass del backbone condiviso.
Correttezza del Training: L'analisi della traiettoria della perdita ha confermato che l'esecuzione di gruppo preserva il comportamento di ottimizzazione per ogni tenant. I tenant addestrati su dataset diversi (LIBERO vs. CALVIN) con teste di azione e ottimizzatori separati hanno mostito pattern di discesa della perdita attesi, identici ai baseline di esecuzione seriale.

5. Significato e Rivendicazioni

Il paper sostiene che JoyNexus rappresenti un passo significativo verso i servizi di post-training VLA programmabili e multi-tenant. La sua importanza primaria risiede nel:

Spostamento dell'Onere: Libera i tenant dalle preoccupazioni infrastrutturali di basso livello (allocazione delle risorse, residenza del modello, sincronizzazione), permettendo loro di concentrarsi sullo sviluppo di algoritmi.
Efficienza Economica e Tecnica: Abilitando lo scheduling cross-tenant su risorse condivise, affronta l'inefficienza del pricing fisso a ore di scheda per i carichi di lavoro VLA a raffiche, rendendo l'addestramento ad alte prestazioni più accessibile e conveniente.
Scalabilità: Il design orientato ai servizi supporta lo scheduling concorrente di diversi carichi di lavoro (SFT, RL, valutazione) che erano precedentemente difficili da orchestrare insieme a causa dei requisiti eterogenei di ambiente e dati.

Gli autori osservano che, sebbene l'attuale prototipo fondi queste astrazioni in workflow esistenti (RLinf, StarVLA), il lavoro futuro esplorerà l'aggiustamento dinamico delle risorse, i meccanismi di pricing e i punti di estensione sicuri per il codice e gli ambienti forniti dagli utenti.