Alibaba zaprezentowała QwenGyre — framework uczenia ze wzmocnieniem (reinforcement learning) zaprojektowany dla tego, co zespół badawczy firmy nazywa treningiem agentów typu „XLong-horizon”: zadań, w których pojedynczy rollout może trwać godziny, obejmować setki interakcji między modelem a jego środowiskiem oraz zużywać blisko milion tokenów.

Framework odpowiada na zmianę w sposobie wdrażania agentów LLM. Gdy przechodzą oni od rozwiązywania pojedynczych problemów w repozytoriach do budowania całych baz kodu, konwencjonalne potoki online RL napotykają dwie przeszkody. Czasy rolloutów różnią się tak znacznie, że GPU pozostają bezczynne, podczas gdy dokańczanych jest kilka opóźnionych wykonań, a rozgałęziające się ścieżki wykonania generują ogromne ilości redundantnych danych treningowych. Przy horyzontach mierzonych w godzinach i setkach tysięcy tokenów obie przeszkody przekładają się bezpośrednio na zmarnowaną moc obliczeniową: bezczynny sprzęt podczas ogonów rolloutów i zduplikowaney podnoszą koszt każdego uruchomienia treningu.

Elastic Scheduler celuje w niedowykorzystanie GPU

Pierwszy komponent, Elastic Scheduler, rozwiązuje problem niedowykorzystania GPU. Istniejące frameworki zazwyczaj robią jedną z dwóch rzeczy: naprzemiennie przeznaczają całą pulę GPU na rollout i trening (colocate), pozostawiając sprzęt bezczynnym podczas długich ogonów rolloutów, albo statycznie dzielą GPU między dwa etapy (async), co uniemożliwia jednej stronie pożyczenie wolnych mocy drugiej. Każde z tych rozwiązań wymienia jedną formę bezczynności na inną — podejście colocate unieruchamia całą pulę podczas ogonów rolloutów, a podejście async blokuje wolne moce po stronie, która nie może ich wykorzystać.

QwenGyre zamiast tego grupuje sprzęt w niezależnie przełączalne „komórki”, które są realokowane między inferencją a treningiem w miarę zmian objętości niedokończonej pracy rolloutów. Żywe wykonania harnessów nie są nigdy przerywane: żądania modelu są w trakcie lotu przekierowywane do pozostałych silników rolloutów, a pamięci podręczne KV są migrowane przez RDMA (zdalny bezpośredni dostęp do pamięci), tak aby żadne obliczenia nie musiały być powtarzane. Zwolnione komórki dołączają następnie do trwającego kroku treningowego jako dodatkowe repliki data-parallel, pobierając autorytatywne wagi z komórki centralnej, podczas gdy strumieniowy trening rozdziela mikrobatche zgodnie z postępem każdej grupy, tak aby wszystkie komórki kończyły pracę zsynchronizowanie.

Przejścia ról są szybkie. Średnio przełączenie z rolloutu na trening zajmuje 8,5 sekundy, a powrotne 3,5 sekundy — jest to znikome wobec wykonań rolloutów trwających godziny.

Opanowanie rozgałęzionych trajektorii

Drugi komponent, Trajectory Processor, zajmuje się samymi danymi treningowymi. Przy horyzontach XLong harnessy agentów kompresują nasycone konteksty, delegują podzadania sub-agentów i ponawiają nieudane ścieżki, więc jedno wykonanie produkuje rozgałęzione drzewo rozbieżnych ścieżek kontekstu zamiast liniowej trajektorii. Naiwne rozwijanie każdej ścieżki duplikuje wspólne prefiksy i zawyża koszt treningu — obciążenie rosnące wraz z kontekstami liczącymi niemal milion tokenów, jakie te uruchomienia generują.

QwenGyre zamiast tego rekonstruuje wykonanie jako drzewo trajektorii ze wspólnymi prefiksami, zachowując dokładny oryginalny kontekst kondycjonowania każdego wyjścia modelu. Trenowane są wyłącznie tokeny faktycznie wygenerowane przez politykę, a wspólne cele są liczone raz dzięki maskowaniu na drzewie.

Oceniany jest także częściowy postęp: wykonania, które osiągnęły limit czasu, są nadal ewaluowane na podstawie zachowanego stanu ich przestrzeni roboczej, więc częściowe próby niosą istotne nagrody zamiast być odrzucane. Skoro pojedyncze wykonanie może zajmować sprzęt na godziny, to odzyskiwanie zachowuje sygnał, który inaczej zostałby wyrzucony. Przy przyjmowaniu do treningu wybierana jest ograniczona liczba trajektorii na wykonanie — ograniczona priorytetem ról: najpierw główny agent, potem sub-agenci, a na końcu ścieżki podsumowań — a straty tokenowe są uśredniane w obrębie każdego wykonania, tak aby liczba ścieżek nie mogła zaburzać wag.

Wyniki benchmarków

Zastosowany do flagowego modelu Alibaba Qwen 3.8-2.4T przy około 700K tokenów na rollout, QwenGyre podniósł wskaźnik zaliczenia NL2RepoBench z 52,5% do 58,5% w ciągu 48 kroków treningowych, kończąc je w 75,4 godziny wobec 134,6 godziny dla punktu odniesienia async i 91,5 godziny dla punktu odniesienia colocate — przyspieszenia odpowiednio do 1,78× i 1,85×, osiągnięte przy wyrównanych wynikach treningowych punktów odniesienia. Zyski utrzymywały się konsekwentnie we wszystkich trzech ewaluowanych obciążeniach — NL2RepoBench, DeepSWE i TerminalBench — przy równych budżetach GPU.

Odzyskane niemal 60 godzin względem punktu odniesienia async podkreśla,aczego harmonogramowanie ma znaczenie w tej skali: krótszy czas zegarowy przy równych wynikach obniża koszt czasowy każdego cyklu treningowego. Dla czytelników rozważających podobne deklaracje dotyczące infrastruktury istotne są dwa warunki dołączone do tych liczb — wyrównane wyniki treningowe i równe budżety GPU — oraz fakt, że wszystkie dane pochodzą z rolloutów liczących około 700K tokenów, czyli reżimu XLong, dla którego framework został zbudowany.

Źródło: Alibaba's QwenGyre Tackles The Million-Token Problem With Elastic GPU Scheduling For XLong RL za pośrednictwem Metaverse Post.