🤖 AI

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

JoyNexus est un service unifié et multi-locataire pour les modèles de vision-langage-action (VLA) post-entraînement qui découple les composants d'entraînement, d'inférence et d'environnement afin de permettre le partage efficace des ressources, l'ordonnancement inter-locataires et le traitement par lots de groupe, réduisant ainsi le temps GPU global et améliorant l'utilisation par rapport à l'exécution traditionnelle isolée à locataire unique.

Auteurs originaux : 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

Publié 2026-07-20

📖 8 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : 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

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez un monde où les robots peuvent apprendre à faire des choses tout comme les humains : voir une pièce en désordre, comprendre l'instruction « ranger » et ensuite trouver comment ramasser les jouets. C'est le domaine passionnant des modèles de Vision-Langage-Action (VLA). Considérez ces modèles comme le cerveau d'un robot qui combine les yeux (la vision), une voix (le langage) et les muscles (l'action). Pour qu'un robot puisse réellement faire quelque chose d'utile, les scientifiques doivent le « post-entraîner ». C'est comme prendre un étudiant intelligent qui connaît des faits généraux et lui enseigner des compétences spécifiques, comme nouer une chaussure ou ouvrir un bocal.

Cependant, enseigner à ces cerveaux de robots est incroyablement coûteux et complexe. Actuellement, si un chercheur veut entraîner un robot, il doit généralement louer un ordinateur massif et coûteux (un GPU) pour lui tout seul. C'est comme louer une salle de sport privée entière juste pour faire quelques pompes ; la machine reste inactive pendant que vous chargez vos poids ou que vous faites une pause, et vous devez quand même payer pour toute l'heure. Cette approche « un robot, une salle de sport » est gaspilleuse et rend difficile l'expérimentation du apprentissage robotique pour de nombreuses personnes en même temps.

Entrez en scène JoyNexus, une nouvelle idée proposée par des chercheurs de JD AI Infra et de plusieurs universités. Ils proposent une « salle de sport partagée » pour les cerveaux de robots. Au lieu de louer un ordinateur entier, plusieurs chercheurs peuvent partager la même machine puissante de manière sûre et efficace. Le papier présente un système qui agit comme un entraîneur super intelligent, permettant à de nombreuses équipes d'entraîner leurs robots simultanément sans qu'elles ne se rentrent dedans. En organisant intelligemment le travail, JoyNexus suggère que nous pouvons réduire le temps et l'énergie nécessaires pour entraîner ces robots, rendant l'apprentissage de robots avancés plus rapide et moins cher pour tout le monde.

La « Salle de Sport Partagée » pour les Cerveaux de Robots

Alors, comment JoyNexus fonctionne-t-il réellement ? Imaginez une salle de sport animée et de haute technologie. Dans l'ancienne méthode, si vous vouliez vous entraîner, vous loueriez une pièce entière avec un tapis roulant, des poids et un miroir, et vous seriez le seul autorisé à y entrer. Si vous vous arrêtiez pour boire de l'eau ou consulter votre téléphone, la pièce restait vide, mais vous payiez quand même pour tout le temps.

JoyNexus change les règles. Il transforme la salle de sport en un espace partagé et animé avec trois zones principales :

La Zone Cerveau (Service de Modèle d'Entraînement) : C'est là que se déroule le gros du travail. Le « cerveau » du robot (la partie grande et complexe qui comprend les images et les mots) est conservé dans un endroit central et partagé. C'est comme un tapis roulant géant et coûteux que tout le monde peut utiliser.
La Zone Muscle (Module d'Action) : Chaque robot possède ses propres « muscles » uniques ou compétences spécifiques (comme une pince pour une griffe ou une roue pour une voiture). Dans JoyNexus, ces parties spécifiques sont gardées séparées pour chaque équipe. Vous apportez vos propres poids uniques sur le tapis roulant partagé.
Le Parcours d'Obstacles (Service d'Environnement) : C'est le simulateur où le robot s'entraîne. Cela peut être une cuisine virtuelle, un sol d'usine ou un salon.

La magie de JoyNexus réside dans la gestion du trafic. Il utilise un « Service Maître » (comme un gérant de salle de sport super organisé) pour décider qui va sur le tapis roulant et quand. Si l'Équipe A attend que son robot finisse une simulation, et que l'Équipe B est prête à faire une mise à jour mathématique, le gestionnaire les échange instantanément pour que le tapis roulant ne s'arrête jamais.

L'Astuce du « Groupement par Lots »

L'une des fonctionnalités les plus cool est ce que les auteurs appellent le groupement par lots (group batching). Imaginez que vous êtes dans un café. Si une personne commande un latte, le barista doit démarrer la machine, moudre les grains et faire mousser le lait juste pour cette tasse. Si dix personnes commandent des lattes en même temps, le barista peut moudre assez de grains pour les dix et faire mousser une grande carafe de lait, ce qui rend le processus beaucoup plus rapide par tasse.

JoyNexus fait cela pour l'entraînement des robots. Souvent, différentes équipes envoient de petites requêtes au « cerveau » partagé (le modèle VLA). Si le système traitait ces requêtes une par une, l'ordinateur perdrait du temps à démarrer et s'arrêter. Au lieu de cela, JoyNexus attend une fraction de seconde infime pour voir si d'autres équipes ont des requêtes. Si c'est le cas, il les regroupe. Il exécute la partie « cerveau partagé » une seule fois pour toutes, puis sépare les résultats pour revenir à chaque équipe afin de terminer l'entraînement de leur « muscle » spécifique.

Le papier montre que cela fonctionne très bien lorsque de nombreuses équipes envoient de petits lots de données. Dans leurs simulations, lorsqu'ils ont regroupé les requêtes de 8 équipes différentes, la vitesse de la « passe avant » partagée (la partie où le cerveau regarde les données) s'est considérablement améliorée. Pour certains modèles, cela a rendu la partie partagée 2,21 fois plus rapide qu'en les faisant une par une.

Ce Qu'Ils Ont Trouvé (et Ce Qu'Ils N'Ont Pas Trouvé)

Les chercheurs ont testé JoyNexus en simulant un scénario avec quatre équipes différentes : trois équipes entraînant des robots pour effectuer des tâches dans des environnements virtuels (comme déplacer des blocs dans une simulation appelée LIBERO ou ManiSkill), et une équipe pratiquant simplement avec un ensemble de données statiques (Apprentissage Supervisé par Ajustement Fin).

Ils ont comparé cette approche de « salle de sport partagée » à l'ancienne méthode de la « salle de sport privée » où chaque équipe exécutait ses tâches les unes après les autres. Les résultats sont prometteurs :

Moins de Gaspillage : En superposant le travail, JoyNexus a réduit le « temps GPU » total (le temps pendant lequel l'ordinateur coûteux fonctionnait) de 28,3 %.
Meilleure Utilisation : Les ordinateurs partagés étaient occupés 41,3 % du temps dans la configuration multi-locataire, contre seulement 20,8 % dans la configuration isolée. C'est presque le double d'efficacité !
Pas de Confusion : Crucialement, le système a maintenu la sécurité de tout. Même si les équipes partageaient le gros cerveau, leurs « muscles » spécifiques, leurs données et leurs progrès étaient complètement isolés. Le papier montre que les courbes d'apprentissage (la vitesse à laquelle les robots s'améliorent) pour chaque équipe étaient exactement les mêmes que si elles s'étaient entraînées seules.

Il est important de noter que ces résultats proviennent de simulations et de tests de charge de travail, et non d'un déploiement réel de milliers de robots. Les auteurs suggèrent que cette approche pourrait économiser de l'argent et du temps, mais ils n'ont pas encore prouvé qu'elle fonctionnerait parfaitement dans tous les scénarios réels possibles. Ils soulignent également que, bien que le système soit excellent pour partager les ressources, il repose actuellement sur le fait que les utilisateurs respectent des règles spécifiques sur la manière de formater leurs données. Si une équipe souhaite utiliser un design de robot totalement étrange et personnalisé qui ne rentre pas dans les règles standard de la « salle de sport », cela pourrait être plus difficile.

L'Avenir de l'Entraînement des Robots

Le papier conclut que JoyNexus est un grand pas vers la rendre l'apprentissage des robots accessible. Au lieu d'avoir besoin d'un million de dollars pour louer un supercalculateur privé, les chercheurs pourraient potentiellement payer uniquement pour le temps qu'ils utilisent réellement, en partageant les coûts avec d'autres.

Cependant, les auteurs sont réalistes. Ils admettent que pour que cela fonctionne dans le monde réel, nous avons besoin de meilleures façons de gérer la sécurité (pour qu'une équipe ne casse pas accidentellement le robot d'une autre), la tarification (combien charger pour le temps partagé) et la flexibilité (permettre aux utilisateurs d'apporter leurs propres simulateurs bizarres). Ils suggèrent que les futures versions du système pourraient devenir plus intelligentes, en ajustant automatiquement les ressources en fonction de l'occupation de la salle de sport.

En bref, JoyNexus suggère que l'avenir de l'entraînement des robots n'est pas de construire des forteresses isolées et plus grandes pour chaque chercheur. Il s'agit de construire un centre communautaire animé et efficace où tout le monde peut apprendre ensemble, partager l'équipement coûteux et faire bouger ses robots plus rapidement que jamais auparavant.

Résumé Technique : JoyNexus – Service de Post-Entraînement Multi-Tenant pour Modèles VLA

1. Énoncé du Problème

Le post-entraînement des modèles Vision-Language-Action (VLA) est crucial pour adapter les modèles de fondation à divers types d'incarnations robotiques, simulateurs et objectifs de tâches. Cependant, les paradigmes actuels de calcul en nuage pour l'entraînement VLA font face à des inefficacités significatives :

Fardeau d'Infrastructure : Les services existants allouent généralement des ressources GPU/CPU exclusives à un seul locataire (soit via la location directe, soit via la soumission de lots). Cela force les utilisateurs à gérer des dépendances d'infrastructure complexes, incluant des environnements de modèles hétérogènes et des sessions de simulation.
Inefficacité des Ressources : Les modèles VLA sont souvent de taille modérée, ce qui entraîne une faible utilisation des accélérateurs dans les configurations distribuées. De plus, le modèle de tarification fixe par « heure-carte » est inefficace pour les charges de travail courtes, itératives ou par rafales courantes dans le développement VLA (par exemple, lors du déploiement, du chargement de données ou de la synchronisation de l'environnement), où les GPU restent souvent inactifs.
Manque d'Abstractions Spécialisées : Bien que des systèmes orientés service de type « Tinker » existent pour le post-entraînement des modèles de langage (ex. : OpenTinker, ProRL Agent), ils ne traitent pas les exigences spécifiques du post-entraînement VLA, qui implique des sessions de simulateur, des schémas d'action hétérogènes, des enregistrements de déploiement (rollout) et la synchronisation des versions de politiques.

2. Méthodologie : L'Architecture JoyNexus

JoyNexus reformule le post-entraînement VLA comme un service multi-tenant unifié. Il découple le Service de Modèle d'Entraînement, le Service de Modèle d'Inférence et le Service d'Environnement, permettant aux locataires d'y accéder via des API tandis que le fournisseur gère l'infrastructure partagée.

2.1 Principes de Conception Fondamentaux

Décomposition : Inspiré par la décomposition de type « Lego » de modèles comme StarVLA, JoyNexus sépare le backbone VLM partagé coûteux et réutilisable (résident en mémoire) des modules d'action spécifiques au locataire (adaptateurs, têtes d'action ou suffixes de politique).
Séparation des Services :
- Service de Modèle d'Entraînement : Maintient le modèle de base partagé et les états d'entraînement spécifiques au locataire (optimiseurs, versions de politique).
- Service de Modèle d'Inférence : Gère les requêtes d'inférence, maintenant les états de service indexés par locataire et synchronisant les paramètres mis à jour.
- Service d'Environnement : Gère les sessions interactives (simulateurs) et les jeux de données hors ligne, abstrayant à la fois l'interaction en ligne et l'accès aux données hors ligne.
Ordonnancement par Double File d'Attente : Le système utilise une File d'Attente d'Entraînement et une File d'Attente d'Inférence. Cela découple le flux de données d'optimisation des requêtes de prédiction sensibles à la latence, permettant l'ordonnancement simultané du Fine-Tuning Supervisé (SFT), de l'Apprentissage par Renforcement (RL) et de l'évaluation.

2.2 Orchestration du Flux de Travail

JoyNexus prend en charge trois flux de travail principaux via un Service Maître qui compile l'intention de l'utilisateur en configurations backend :

Fine-Tuning Supervisé (SFT) : Les locataires fournissent des jeux de données de démonstration hors ligne. Le système échantillonne des lots, exécute le modèle VLA, calcule la perte et met à jour les modules spécifiques au locataire.
Apprentissage par Renforcement (RL) : Une boucle fermée où la politique interagit avec un environnement (via le Service d'Environnement), génère des enregistrements de déploiement et met à jour la politique. Le producteur de déploiement (rollout producer) et l'acteur (trainer) fonctionnent comme des boucles concurrentes, communiquant uniquement via la File d'Attente d'Entraînement.
Évaluation : Un processus en lecture seule qui charge une version spécifique de la politique, exécute l'inférence contre un environnement ou un jeu de données, et enregistre les métriques sans mettre à jour les paramètres.

2.3 Group Batching Multi-Tenant

Pour remédier à l'inefficacité des requêtes d'inférence petites et sporadiques, JoyNexus introduit le group batching (regroupement par lots) pour les schémas de données VLA hétérogènes.

Mécanisme : Les requêtes compatibles provenant de différents locataires sont normalisées vers une représentation à préfixe partagé (le VLAFeature). Une seule passe directe (forward pass) est exécutée sur le backbone partagé gelé pour les échantillons groupés.
Partitionnement : Les caractéristiques résultantes sont ensuite partitionnées vers les modules d'action spécifiques au locataire pour le calcul de la perte, les passes arrière (backward passes) et les mises à jour de l'optimiseur.
Ordonnancement : L'ordonnanceur d'inférence accumule les requêtes en fonction d'un temps d'attente maximal ( $T$ ) et d'une taille de lot cible ( $B$ ) avant de déclencher l'inférence, garantissant une utilisation élevée sans bloquer indéfiniment les requêtes sensibles à la latence.

2.4 Robustesse du Système

Isolation des Défaillances : Un Gestionnaire de Santé dédié surveille les services. Les échements localisés déclenchent des redémarrages sur place de rôles spécifiques (par exemple, un travailleur de déploiement défaillant) sans redémarrer l'ensemble de la charge de travail ou affecter les autres locataires.
Évolutivité Élastique : Les services d'inférence et d'entraînement peuvent évoluer indépendamment. Les moteurs de déploiement peuvent être ajoutés ou supprimés de manière asynchrone pour correspondre aux demandes d'interaction avec l'environnement sans interrompre le processus d'optimisation.

3. Contributions Clés

Abstraction de Service Client-Serveur : Une architecture novatrice qui sépare le calcul privé du locataire (modules d'action, optimiseurs) de l'infrastructure partagée (modèles de base, environnements), maintenant l'isolation des charges de travail tout en permettant un ordonnancement fin des ressources.
Backend à Trois Composants : Un backend unifié supportant le SFT, le RL et l'évaluation, où les modèles de base restent résidents en mémoire et les modules spécifiques au locataire sont montés dans des emplacements isolés.
Group Batching pour Schémas Hétérogènes : Un pipeline permettant une seule passe directe du backbone partagé à travers des échantillons groupés de différents locataires avec des schémas de données compatibles, améliorant considérablement le débit pour les charges de travail à petits lots.
Validation Empirique : Démonstration d'une meilleure utilisation des ressources et d'une réduction du temps GPU global par rapport à une exécution isolée par locataire.

4. Résultats Expérimentaux

Les auteurs ont évalué JoyNexus via une simulation de charge de travail et un pipeline de group batching dans des scénarios incarnés réalistes.

Efficacité des Ressources : Dans une simulation avec trois locataires RL et un locataire SFT sur un nœud à 8 GPU, JoyNexus a réduit le temps GPU global de 28,3 % par rapport à une base de référence mono-locataire séquentielle.
- Utilisation du Service de Modèle d'Entraînement : Est passée de 20,8 % (isolé) à 41,3 % (multi-tenant), soit une amélioration de 1,99×.
- Utilisation du Service de Modèle d'Inférence : Est passée de 28,1 % à 37,5 %, soit une amélioration de 1,33×.
Performance du Group Batching :
- Les expériences avec 2 à 8 locataires et des tailles de lots locaux variables ont montré que le group batching devient de plus en plus efficace à mesure que le nombre de locataires augmente et que les tailles de lots locaux diminuent.
- Pour des modèles tels que StarVLA-GR00T (2B, 4B, 8B), l'exécution groupée a fourni des accélérations significatives de l'étape de passe directe (jusqu'à 3,24× pour StarVLA-OFT avec 8 locataires), principalement en amortissant le coût de la passe directe du backbone partagé.
Correction de l'Entraînement : L'analyse de la trajectoire de la perte a confirmé que l'exécution groupée préserve le comportement d'optimisation par locataire. Les locataires entraînés sur des jeux de données différents (LIBERO vs. CALVIN) avec des têtes d'action et des optimiseurs distincts ont présenté des schémas de descente de perte attendus, identiques aux bases de référence d'exécution sérielle.

5. Signification et Revendications

L'article affirme que JoyNexus représente une étape importante vers des services de post-entraînement VLA programmables et multi-tenants. Sa principale importance réside dans :

Transfert de la Charge : Il libère les locataires des préoccupations d'infrastructure de bas niveau (allocation de ressources, résidence du modèle, synchronisation), leur permettant de se concentrer sur le développement d'algorithmes.
Efficacité Économique et Technique : En permettant l'ordonnancement croisé entre locataires sur des ressources partagées, il répond à l'inefficacité de la tarification fixe par heure-carte pour les charges de travail VLA par rafales, rendant l'entraînement haute performance plus accessible et rentable.
Évolutivité : La conception orientée service permet l'ordonnancement simultané de diverses charges de travail (SFT, RL, évaluation) qui étaient auparavant difficiles à orchestrer ensemble en raison de l'hétérogénéité des exigences d'environnement et de données.

Les auteurs notent que, bien que le prototype actuel fonde ces abstractions sur des flux de travail existants (RLinf, StarVLA), les travaux futurs exploreront l'ajustement dynamique des ressources, les mécanismes de tarification et les points d'extension sécurisés pour le code et les environnements fournis par l'utilisateur.