🤖 AI

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

JoyNexus ist ein vereinheitlichter, Multi-Tenant-Service für Post-Training Vision-Language-Action (VLA)-Modelle, der die Komponenten Training, Inferenz und Umgebung entkoppelt, um eine effiziente gemeinsame Ressourcennutzung, Cross-Tenant-Scheduling und Gruppen-Batching zu ermöglichen, wodurch die aggregierte GPU-Zeit reduziert und die Auslastung im Vergleich zum traditionellen isolierten Single-Tenant-Durchlauf verbessert wird.

Ursprüngliche Autoren: 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

Veröffentlicht 2026-07-20

📖 7 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: 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

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich eine Welt vor, in der Roboter lernen können, Dinge genau wie Menschen zu tun: ein unordentliches Zimmer zu sehen, die Anweisung „aufräumen“ zu verstehen und dann herauszufinden, wie man das Spielzeug aufhebt. Dies ist das spannende Feld der Vision-Language-Action (VLA)-Modelle. Betrachten Sie diese Modelle als das Gehirn eines Roboters, das Augen (Vision), eine Stimme (Sprache) und Muskeln (Aktion) kombiniert. Um einen Roboter tatsächlich dazu zu bringen, etwas Nützliches zu tun, müssen Wissenschaftler ihn „post-trainen“. Das ist so, als würde man einen klugen Schüler, der allgemeine Fakten kennt, spezifische Fähigkeiten beibringen, wie zum Beispiel das Binden eines Schuhs oder das Öffnen eines Glases.

Das Training dieser Robotergehirne ist jedoch unglaublich teuer und kompliziert. Momentan muss ein Forscher, wenn er einen Roboter trainieren möchte, normalerweise einen massiven, teuren Computer (eine GPU) ganz für sich allein mieten. Es ist so, als würde man eine ganze private Turnhalle mieten, nur um ein paar Liegestütze zu machen; die Maschine steht still, während man seine Gewichte aufstellt oder eine Pause macht, und man zahlt trotzdem für die ganze Stunde. Dieser „Ein Roboter, eine Turnhalle“-Ansatz ist verschwenderisch und macht es vielen Menschen schwer, gleichzeitig an Roboterlernen zu experimentieren.

Hier kommt JoyNexus ins Spiel, eine neue Idee von Forschern der JD AI Infra und mehreren Universitäten. Sie schlagen eine „gemeinsame Turnhalle“ für Robotergehirne vor. Anstatt einen ganzen Computer zu mieten, können mehrere Forscher dieselbe leistungsstarke Maschine sicher und effizient teilen. Die Arbeit beschreibt ein System, das wie ein superintelligenter Trainer fungiert und es vielen verschiedenen Teams ermöglicht, ihre Roboter gleichzeitig zu trainieren, ohne sich gegenseitig in die Quere zu kommen. Durch die geschickte Organisation der Arbeit schlägt JoyNexus vor, dass wir die gesamte Zeit und Energie, die zum Trainieren dieser Roboter benötigt wird, reduzieren können, was das Roboterlernen für alle schneller und kostengieriger macht.

Die „gemeinsame Turnhalle“ für Robotergehirne

Wie funktioniert JoyNexus also eigentlich? Stellen Sie sich eine geschäftige, hochtechnologische Turnhalle vor. Auf die alte Art, wenn Sie trainieren wollten, hätten Sie ein ganzes Zimmer mit Laufband, Gewichten und einem Spiegel gemietet, und Sie wären der Einzige gewesen, der dort hineindarf. Wenn Sie kurz anhielten, um Wasser zu trinken oder auf Ihr Handy zu schauen, stand der Raum leer, aber Sie zahlten trotzdem für die gesamte Zeit.

JoyNexus ändert die Regeln. Es verwandelt die Turnhalle in einen belebten, geteilten Raum mit drei Hauptzonen:

Die Gehirn-Zone (Training Model Service): Hier findet die schwere Arbeit statt. Das „Gehirn“ des Roboters (der große, komplexe Teil, der Bilder und Wörter versteht) wird an einem zentralen, gemeinsamen Ort aufbewahrt. Es ist wie ein riesiges, teures Laufband, das jeder benutzen kann.
Die Muskel-Zone (Action Module): Jeder Roboter hat seine eigenen, einzigartigen „Muskeln“ oder spezifischen Fähigkeiten (wie einen Greifer für eine Klaue oder ein Rad für ein Auto). In JoyNexus werden diese spezifischen Teile für jedes Team separat aufbewahrt. Sie bringen Ihre eigenen, einzigartigen Gewichte zum gemeinsamen Laufband mit.
Der Hindernisparcours (Environment Service): Dies ist der Simulator, in dem der Roboter übt. Es könnte eine virtuelle Küche, ein Fabrikboden oder ein Wohnzimmer sein.

Die Magie von JoyNexus liegt darin, wie es den Verkehr regelt. Es verwendet einen „Master Service“ (wie einen superorganisierten Fitnessstudio-Manager), der entscheidet, wer wann auf das Laufband darf. Wenn Team A darauf wartet, dass sein Roboter eine Simulation abschließt, und Team B bereit ist, eine mathematische Aktualisierung durchzuführen, tauscht der Manager sie sofort aus, sodass das Laufband niemals stoppt.

Der „Group Batching“-Trick

Eines der coolsten Merkmale ist etwas, das die Autoren Group Batching nennen. Stellen Sie sich vor, Sie sind in einem Café. Wenn eine Person einen Latte bestellt, muss der Barista die Maschine starten, die Bohnen mahlen und die Milch aufschäumen, nur für diese eine Tasse. Wenn zehn Personen gleichzeitig Lattes bestellen, kann der Barista genug Bohnen für alle zehn mahlen und eine große Kanne Milch auf einmal aufschäumen, was den Prozess pro Tasse viel schneller macht.

JoyNexus macht dies für das Robotertraining. Oft senden verschiedene Teams kleine Anfragen an das gemeinsame „Gehirn“ (das VLA-Modell). Wenn das System diese einzeln verarbeiten würde, würde der Computer Zeit mit dem Starten und Stoppen verschwenden. Stattdessen wartet JoyNexus einen winzigen Bruchteil einer Sekunde ab, um zu sehen, ob andere Teams ebenfalls Anfragen haben. Wenn ja, gruppiert es diese zusammen. Es führt den „gemeinsamen Gehirn“-Teil einmal für alle aus und teilt die Ergebnisse dann wieder auf, damit jedes Team sein spezifisches „Muskel“-Training fortsetzen kann.

Das Paper zeigt, dass dies sehr gut funktioniert, wenn viele Teams kleine Datenpakete senden. In ihren Simulationen verbesserte sich die Geschwindigkeit des „Forward Pass“ (der Teil, in dem das Gehirn die Daten betrachtet) des gemeinsamen Systems signifikant, wenn Anfragen von 8 verschiedenen Teams gruppiert wurden. Für einige Modelle machte dies den gemeinsamen Teil des Trainings 2,21-mal schneller als bei der Einzelverarbeitung.

Was sie herausgefunden haben (und was nicht)

Die Forscher testeten JoyNexus in einem Szenario mit vier verschiedenen Teams: drei Teams trainierten Roboter für Aufgaben in virtuellen Umgebungen (wie das Bewegen von Blöcken in einer Simulation namens LIBERO oder ManiSkill), und ein Team trainierte lediglich mit einem statischen Datensatz (Supervised Fine-Tuning).

Sie verglichen diesen „gemeinsamen Turnhallen“-Ansatz mit der alten „privaten Turnhallen“-Methode, bei der jede Gruppe ihre Aufgaben nacheinander ausführte. Die Ergebnisse waren vielversprechend:

Weniger Verschwendung: Durch das Überlappen der Arbeit reduzierte JoyNexus die gesamte „GPU-Zeit“ (die Zeit, in der der teure Computer lief) um 28,3 %.
Bessere Auslastung: Die gemeinsam genutzten Computer waren im Multi-Tenant-Setup 41,3 % der Zeit beschäftigt, im Vergleich zu nur 20,8 % im isolierten Setup. Das ist fast die doppelte Effizienz!
Keine Verwirrung: Entscheidend ist, dass das System alles sicher hielt. Obwohl die Teams das große Gehirn teilten, waren ihre spezifischen „Muskeln“, ihre Daten und ihr Fortschritt völlig isoliert. Das Paper zeigt, dass die Lernkurven (wie schnell die Roboter besser wurden) für jedes Team exakt dieselben waren wie beim Training allein.

Es ist wichtig anzumerken, dass diese Ergebnisse aus Simulationen und Workload-Tests stammen, nicht aus einem realen Einsatz mit tausenden von echten Robotern. Die Autoren legen nahe, dass dieser Ansatz Geld und Zeit sparen könnte, aber sie haben noch nicht bewiesen, dass er in jedem möglichen realen Szenario perfekt funktionieren wird. Sie weisen auch darauf hin, dass das System zwar gut beim Teilen von Ressourcen ist, aber derzeit darauf angewiesen ist, dass die Nutzer sich an bestimmte Regeln zur Formatierung ihrer Daten halten. Wenn ein Team ein völlig eigenartiges, individuelles Roboterdesign verwenden möchte, das nicht in die Standard-„Turnhallen“-Regeln passt, könnte es schwieriger sein, sich einzufügen.

Die Zukunft des Robotertrainings

Das Paper kommt zu dem Schluss, dass JoyNexus ein großer Schritt ist, um Roboterlernen zugänglich zu machen. Anstatt eine Million Dollar zu benötigen, um eine private Supercomputer-Ressource zu mieten, könnten Forscher potenziell nur für die Zeit bezahlen, die sie tatsächlich nutzen, indem sie die Kosten mit anderen teilen.

Die Autoren sind jedoch realistisch. Sie geben zu, dass wir für die Umsetzung in der realen Welt bessere Wege für Sicherheit (damit ein Team nicht versehentlich den Roboter eines anderen beschädigt), Preisgestaltung (wie man die Zeit für die gemeinsame Nutzung berechnet) und Flexibilität (den Nutzern zu erlauben, ihre eigenen „eigenartigen“ Simulatoren mitzubringen) benötigen. Sie schlagen vor, dass zukünftige Versionen des Systems noch intelligenter werden könnten, indem sie Ressourcen automatisch basierend auf der Auslastung der Turnhalle anpassen.

Kurz gesagt: JoyNexus legt nahe, dass die Zukunft des Robotertrainings nicht darin besteht, für jeden Forscher immer größere, isolierte Festungen zu bauen. Es geht darum, ein belebtes, effizientes Gemeinschaftszentrum zu schaffen, in dem alle zusammen lernen, die teure Ausrüstung teilen und ihre Roboter schneller als je zuvor in Bewegung setzen können.

Technisches Resümee: JoyNexus – Service-orientiertes Multi-Tenant Post-Training für VLA-Modelle

1. Problemstellung

Das Post-Training von Vision-Language-Action (VLA) Modellen ist entscheidend für die Anpassung von Foundation-Modellen an diverse Roboter-Embodiments, Simulatoren und Aufgabenobjektive. Aktuelle Cloud-Computing-Paradigmen für das VLA-Training stehen jedoch vor erheblichen Ineffizienzen:

Infrastruktur-Belastung: Bestehende Dienste weisen in der Regel exklusive GPU/CPU-Ressourcen einem einzelnen Tenant zu (entweder durch direkte Vermietung oder Batch-Einreichung). Dies zwingt Nutzer dazu, komplexe Infrastruktur-Abhängigkeiten zu verwalten, einschließlich heterogener Modell-Umgebungen und Simulator-Sessions.
Ressourcen-Ineffizienz: VLA-Modelle sind oft moderater Skalierung, was zu einer schlechten Beschleuniger-Auslastung in verteilten Setups führt. Zudem ist das feste „Card-Hour“-Preismodell ineffizient für kurze, iterative oder burstartige Workloads, die im VLA-Development üblich sind (z. B. während des Rollouts, des Datenladens oder der Umgebungssynchronisation), wenn GPUs oft im Leerlauf verbleiben.
Mangel an spezialisierten Abstraktionen: Während „Tinker-Stil“-serviceorientierte Systeme für das Post-Training von Sprachmodellen existieren (z. B. OpenTinker, ProRL Agent), adressieren sie nicht die spezifischen Anforderungen des VLA-Post-Trainings, welches Simulator-Sessions, heterogene Action-Schemas, Rollout-Records und Policy-Versions-Synchronisation umfasst.

2. Methodik: Die JoyNexus-Architektur

JoyNexus definiert das VLA-Post-Training als einen vereinheitlichten, Multi-Tenant-Service um. Es entkoppelt den Training Model Service, den Inference Model Service und den Environment Service, sodass Tenants auf diese via APIs zugreifen können, während der Provider die gemeinsame Infrastruktur verwaltet.

2.1 Kern-Designprinzipien

Dekomposition: Inspiriert von der „Lego-Stil“-Dekomposition von Modellen wie StarVLA, trennt JoyNexus das teure, wiederverwendbare gemeinsame VLM-Backbone (das im Speicher resident ist) von tenant-spezifischen Action-Modulen (Adapter, Action Heads oder Policy-Suffixe).
Service-Trennung:
- Training Model Service: Hält das gemeinsame Basismodell und die tenant-spezifischen Trainingszustände (Optimizer, Policy-Versionen) aufrecht.
- Inference Model Service: Handhabt Inference-Anfragen, indem er tenant-indizierte Serving-Zustände pflegt und aktualisierte Parameter synchronisiert.
- Environment Service: Verwaltet interaktive Sessions (Simulatoren) und Offline-Datensätze, wobei sowohl Online-Interaktion als auch Offline-Datenzugriff abstrahiert werden.
Dual-Queue-Scheduling: Das System nutzt eine Training Queue und eine Inference Queue. Dies entkoppelt den Optimierungs-Datenfluss von latenzsensitiven Vorhersageanfragen und ermöglicht das gleichzeitige Scheduling von Supervised Fine-Tuning (SFT), Reinforcement Learning (RL) und Evaluation.

2.2 Workflow-Orchestrierung

JoyNexus unterstützt drei primäre Workflows durch einen Master-Service, der die Intention des Nutzers in Backend-Konfigurationen kompiliert:

Supervised Fine-Tuning (SFT): Tenants stellen Offline-Demonstrations-Datensätze bereit. Das System sampelt Batches, führt das VLA-Modell aus, berechnet den Loss und aktualisiert die tenant-spezifischen Module.
Reinforcement Learning (RL): Ein geschlossener Kreislauf, in dem die Policy mit einer Umgebung interagiert (über den Environment Service), Rollout-Records generiert und die Policy aktualisiert. Der Rollout-Producer und der Actor (Trainer) laufen als konkurrente Loops und kommunizieren ausschließlich über die Training Queue.
Evaluation: Ein Read-only-Prozess, der eine spezifische Policy-Version lädt, Inference gegen eine Umgebung oder einen Datensatz ausführt und Metriken aufzeichnet, ohne Parameter zu aktualisieren.

2.3 Multi-Tenant Group Batching

Um die Ineffizienz kleiner, sporadischer Inference-Anfragen zu adressieren, führt JoyNexus Group Batching für heterogene VLA-Datenschemata ein.

Mechanismus: Kompatible Anfragen von verschiedenen Tenants werden auf eine gemeinsame Präfix-Repräsentation (das VLAFeature) normalisiert. Ein einzener Forward-Pass wird über die gruppierten Samples für das gemeinsame, eingefrorene Backbone ausgeführt.
Partitionierung: Die resultierenden Features werden dann zurück an die tenant-spezifischen Action-Module partitioniert, um Loss-Berechnungen, Backward-Passes und Optimizer-Updates durchzuführen.
Scheduling: Der Inference Scheduler akkumuliert Anfragen basierend auf einer maximalen Wartezeit ( $T$ ) und einer Ziel-Batchgröße ( $B$ ), bevor er die Inference auslöst, um eine hohe Auslastung zu gewährleisten, ohne latenzsensitive Anfragen unendlich lange zu blockieren.

2.4 System-Robustheit

Fehlerisolation: Ein dedizierter Health Manager überwacht die Services. Lokale Ausfälle lösen in-place Restarts spezifischer Rollen aus (z. B. ein fehlgeschlagener Rollout-Worker), ohne den gesamten Workload neu zu starten oder andere Tenants zu beeinflwirken.
Elastische Skalierung: Inference- und Trainings-Services können unabhängig voneinander skalieren. Rollout-Engines können asynchron hinzugefügt oder entfernt werden, um den Anforderungen der Interaktion mit der Umgebung zu entsprechen, ohne den Optimierungsprozess zu unterbrechen.

3. Zentrale Beiträge

Client-Server-Service-Abstraktion: Eine neuartige Architektur, die die private Berechnung des Tenants (Action-Module, Optimizer) von der gemeinsamen Infrastruktur (Basismodelle, Umgebungen) trennt und so die Arbeitslast-Isolation aufrechterhält, während ein feingranulares Ressourcen-Scheduling ermöglicht wird.
Drei-Komponenten-Backend: Ein vereinheitlichtes Backend, das SFT, RL und Evaluation unterstützt, wobei die Basismodelle im Speicher resident bleiben und tenant-spezifische Module in isolierten Slots montiert werden.
Group Batching für heterogene Schemata: Eine Pipeline, die einen einzigen Forward-Pass des gemeinsamen Backbones über gruppierte Samples verschiedener Tenants mit kompatiblen Datenschemata ermöglicht und dadurch den Durchsatz für Small-Batch-Workloads signifikant verbessert.
Empirische Validierung: Demonstration einer verbesserten Ressourceneffizienz und reduzierter aggregierter GPU-Zeit im Vergleich zur isolierten Single-Tenant-Ausführung.

4. Experimentelle Ergebnisse

Die Autoren evaluierten JoyNexus durch Workload-Simulation und eine Group-Batching-Pipeline in realistischen embodied Szenarien.

Ressourceneffizienz: In einer Simulation mit drei RL-Tenants und einem SFT-Tenant auf einem 8-GPU-Node reduzierte JoyNexus die aggregierte GPU-Zeit um 28,3 % im Vergleich zu einer sequentiellen Single-Tenant-Baseline.
- Training Model Service Auslastung: Erhöhte sich von 20,8 % (isoliert) auf 41,3 % (Multi-Tenant), eine 1,99-fache Verbesserung.
- Inference Model Service Auslastung: Erhöhte sich von 28,1 % auf 37,5 %, eine 1,33-fache Verbesserung.
Group Batching Performance:
- Experimente mit 2–8 Tenants und variierenden lokalen Batch-Größen zeigten, dass Group Batching mit zunehmender Anzahl an Tenants und abnehmenden lokalen Batch-Größen immer effektiver wird.
- Für Modelle wie StarVLA-GR007 (2B, 4B, 8B) lieferte die Gruppen-Ausführung signifikante Speedups in der Forward-Phase (bis zu 3,24× für StarVLA-OFT bei 8 Tenants), primär durch die Amortisierung der Kosten des gemeinsamen Basismodell-Forward-Passes.
Trainingskorrektheit: Die Analyse der Loss-Trajektorie bestätigte, dass die Gruppen-Ausführung das pro-Tenant Optimierungsverhalten bewahrt. Tenants, die auf unterschiedlichen Datensätzen (LIBERO vs. CALVIN) mit separaten Action Heads und Optimizern trainiert wurden, zeigten erwartete Loss-Abstiegsmuster, die identisch mit den seriellen Baseline-Ausführungen waren.

5. Bedeutung und Ansprüche

Das Paper behauptet, dass JoyNexus einen bedeutenden Schritt hin zu programmierbaren, Multi-Tenant VLA-Post-Training-Services darstellt. Die primäre Bedeutung liegt in:

Verlagerung der Last: Es befreit die Tenants von Low-Level-Infrastruktur-Anliegen (Ressourcenallokation, Modell-Residenz, Synchronisation) und ermöglicht es ihnen, sich auf die Algorithmenentwicklung zu konzentrieren.
Ökonomische und technische Effizienz: Durch die Ermöglichung von Cross-Tenant-Scheduling auf gemeinsamen Ressourcen adressiert es die Ineffizienz des festen Card-Hour-Pricing für burstartige VLA-Workloads und macht High-Performance-Training zugänglicher und kosteneffizienter.
Skalierbarkeit: Das Service-orientierte Design unterstützt das gleichzeitige Scheduling diverser Workloads (SFT, RL, Evaluation), die zuvor aufgrund heterogener Umgebung- und Datenanforderungen schwer zu orchestrieren waren.

Die Autoren merken an, dass der aktuelle Prototyp diese Abstraktionen in bestehenden Workflows (RLinf, StarVLA) verankert und zukünftige Arbeiten dynamische Ressourcenanpassungen, Preismechanismen sowie sichere Erweiterungspunkte für benutzerdefinierten Code und Umgebungen untersuchen werden.