Alibaba hat QwenGyre vorgestellt, ein Reinforcement-Learning-Framework, das für das konzipiert ist, was das Forschungsteam des Unternehmens „XLong-horizon“-Agententraining nennt: Aufgaben, bei denen ein einzelner Rollout stundenlang laufen kann, hunderte Interaktionen zwischen Modell und Umgebung umfasst und nahezu eine Million Token verbraucht.

Das Framework reagiert auf einen Wandel im Einsatz von LLM-Agenten. Während diese von der Lösung einzelner Repository-Probleme zum Aufbau kompletter Codebasen übergehen, stoßen konventionelle Online-RL-Pipelines auf zwei Hindernisse. Die Rollout-Dauern variieren so stark, dass GPUs untätig bleiben, während einige wenige langsame Ausführungen beendet werden, und verzweigte Ausführungspfade erzeugen gewaltige Mengen redundanter Trainingsdaten. Bei Horizonten von Stunden und hunderttausenden Token führen beide Hindernisse direkt zu verschwendeter Rechenleistung: ungenutzte Hardware während der Rollout-Tails und duplizierte Token erhöhen die Kosten jedes Trainingslaufs.

Elastic Scheduler gegen GPU-Unterauslastung

Die erste Komponente, der Elastic Scheduler, befasst sich mit der GPU-Unterauslastung. Bestehende Frameworks gehen typischerweise einen von zwei Wegen: Sie wechseln einen gesamten GPU-Pool zwischen Rollout und Training hin und her (colocate), wodurch die Hardware während langer Rollout-Tails untätig bleibt, oder sie teilen die GPUs statisch zwischen den beiden Phasen auf (async), washindert, dass eine Seite die freie Kapazität der anderen nutzen kann. Jedes Design tauscht eine Form der Leerlaufzeit gegen eine andere — der Colocate-Ansatz lässt den gesamten Pool während der Rollout-Tails untätig, während der Async-Ansatz freie Kapazität auf der Seite blockiert, die sie nicht nutzen kann.

QwenGyre gruppiert Hardware stattdessen in unabhängig umschaltbare „Cells“, die je nach Umfang der unvollendeten Rollout-Arbeit zwischen Inferenz und Training neu zugewiesen werden. Laufende Harness-Ausführungen werden niemals unterbrochen: Modellanfragen werden mitten in der Ausführung an die verbleibenden Rollout-Engines umgeleitet, wobei KV-Caches über RDMA (Remote Direct Memory Access) migriert werden, sodass keine Berechnung wiederholt werden muss. Frei gewordene Cells treten dem laufenden Trainingsschritt dann als zusätzliche datenparallele Replikate bei und ziehen die autoritativen Gewichte aus einer Core-Cell, während das Streaming-Training Mikro-Batches gemäß dem Fortschritt jeder Gruppe verteilt, sodass alle Cells im Gleichschritt abschließen.

Rollenwechsel erfolgen schnell. Im Durchschnitt dauert der Wechsel von Rollout zu Training 8,5 Sekunden, der Rückwechsel 3,5 Sekunden — vernachlässigbar gegenüber Rollout-Ausführungen, die Stunden dauern.

Verzweigte Trajektorien bändigen

Die zweite Komponente, der Trajectory Processor, kümmert sich um die Trainingsdaten selbst. Bei XLong-Horizonten komprimieren Agent-Harnesses gesättigte Kontexte, delegieren Teilaufgaben an Sub-Agenten und wiederholen fehlgeschlagene Pfade, sodass eine einzelne Ausführung einen verzweigten Baum divergierender Kontexpfade statt einer linearen Trajektorie erzeugt. Das naive Aufspannen jedes Pfades dupliziert gemeinsame Präfixe und erhöht die Trainingskosten — eine Last, die mit den nahezu millionen Token umfassenden Kontexten dieser Läufe wächst.

QwenGyre rekonstruiert die Ausführung stattdessen als präfixgeteilten Trajektorienbaum und bewahrt dabei den exakt ursprünglichen Konditionierungskontext jeder Modellausgabe. Trainiert wird nur auf Token, die tatsächlich von der Policy generiert wurden, und gemeinsame Ziele werden durch On-Tree-Masking nur einmal gezählt.

Auch Teilerfolge werden bewertet: Ausführungen, die ihr Timeout erreichen, werden weiterhin anhand ihres erhaltenen Workspace-Zustands ausgewertet, sodass teilweise Versuche bedeutungsvolle Rewards tragen, statt verworfen zu werden. Da eine einzelne Ausführung Hardware stundenlang belegen kann, bewahrt diese Wiederherstellung ein Signal, das sonst verloren ginge. Bei der Trainingsauf wird pro Ausführung eine begrenzte Anzahl von Trajektorien ausgewählt — begrenzt durch Rollenpriorität, zunächst der Haupt-Agent, dann Sub-Agenten, dann Zusammenfassungspfade — und die Token-Verluste werden innerhalb jeder Ausführung gemittelt, damit die Pfadanzahl die Gewichtung nicht verzerrt.

Benchmark-Ergebnisse

Angewendet auf Alibabas Flaggschiff-Modell Qwen 3.8-2.4T mit rund 700K Token pro Rollout, erhöhte QwenGyre die Bestehensquote bei NL2RepoBench in 48 Trainingsschritten von 52,5 % auf 58,5 % und absolvierte sie in 75,4 Stunden gegenüber 134,6 Stunden bei der Async-Baseline und 91,5 Stunden bei der Colocate-Baseline — Beschleunigungen von bis zu 1,78× bzw. 1,85×, erzielt bei übereinstimmenden Trainingsscores der Baselines. Die Gewinne blieben über alle drei bewerteten Workloads — NL2RepoBench, DeepSWE und TerminalBench — bei gleichen GPU-Budgets konsistent.

Die gegenüber der Async-Baseline zurückgewonnenen fast 60 Stunden unterstreichen, warum Scheduling bei diesem Maßstab eine Rolle spielt: Kürzere Wanduhrzeit bei gleichem Score senkt den Zeitaufwand jedes Trainingszyklus. Für Leser, die ähnliche Infrastrukturbehauptungen abwägen, sind die entscheidenden Details die beiden Bedingungen, die an diese Zahlen geknüpft sind — übereinstimmende Trainingsscores und gleiche GPU-Budgets — sowie die Tatsache, dass alle Zahlen aus Rollouts von rund 700K Token stammen, dem XLong-Regime, für das das Framework gebaut wurde.

Quelle: Alibaba's QwenGyre Tackles The Million-Token Problem With Elastic GPU Scheduling For XLong RL via Metaverse Post.