ServiceNow: pri RL nad vLLM treba najprv opraviť inferenciu, až potom meniť tréning

ServiceNow zverejnilo technicky dôležitý text, ktorý môže mať väčší dopad na tréning reasoning modelov, než naznačuje jeho pomerne úzky titulok. Firma v ňom opisuje migráciu svojho RL pipeline z vLLM V0 na novšiu vetvu V1 a dochádza k záveru, že ešte pred ladením samotnej optimalizačnej schémy treba vyriešiť korektnosť inferenčného backendu. V praxi to znamená, že ak tréning pri reinforcement learningu stojí na chybných alebo nekonzistentných logprobách, model sa môže učiť z pokriveného signálu bez ohľadu na to, ako elegantne vyzerá použitý algoritmus.

Téma je dôležitá preto, že vLLM sa stalo bežnou vrstvou pre rýchlu inferenciu a generovanie rolloutov pri RL tréningu veľkých jazykových modelov. Tréner z neho berie tokenové pravdepodobnosti a z nich počíta policy ratio, KL odchýlku, clipping, entropiu či odmeňovací signál. Ak sa teda zmení spôsob, akým backend tieto čísla vracia, mení sa v skutočnosti samotná tréningová dynamika. ServiceNow opisuje tento problém ako nesúlad medzi tréningom a inferenciou. V čase, keď sa okolo reasoning modelov veľa hovorí o nových RLVR variantoch a odmeňovacích schémach, je to užitočné pripomenutie, že robustnosť stojí aj na nízkoúrovňovej implementácii.

Autori ukazujú, že ich prvý pokus s vLLM V1 neviedol k rovnakej trajektórii učenia ako referenčný beh na vLLM 0.8.5. Až po sérii opráv sa správanie novšej vetvy priblížilo k staršiemu referenčnému nastaveniu. Podľa článku boli rozhodujúce štyri oblasti: spracovanie rollout logprobov, V1-špecifické runtime defaulty, aktualizácia váh počas prebiehajúceho vzorkovania a použitie fp32 lm_head pri finálnej projekcii. Inými slovami, nejde o jednu izolovanú chybu, ale o sústavu detailov, ktoré sa pri vysokorýchlostnom RL tréningu navzájom násobia.

Práve tu sa text ServiceNow odlišuje od čistej release poznámky. Nehovorí len, že nová verzia je rýchlejšia alebo modernejšia, ale že pri RL infraštruktúre treba najprv dosiahnuť zhodu v základných matematických signáloch. Až potom má zmysel robiť závery o tom, či je nový backend lepší alebo horší pre tréning. Tento dôraz na „correctness before corrections“ je z praktického hľadiska veľmi cenný, pretože tímy často pripisujú výkyvy v kvalite tréningu odmeňovacej funkcii, kurikulu alebo voľbe optimizera, hoci skutočný problém môže sedieť v obsluhe logprobov, numerike alebo v runtime parametroch.

Druhý rozmer tejto správy je prevádzkový. ServiceNow prepája blog s projektom PipelineRL, ktorý je zameraný na asynchrónny reinforcement learning s priebežnými aktualizáciami váh počas vzorkovania. Cieľom je držať vysokú priepustnosť inferencie a zároveň nestratiť čerstvosť dát, teda zostať čo najbližšie k on-policy režimu. To je presne oblasť, kde aj malé nekonzistencie v inferenčnom serveri vedia skresliť výsledok. Ak sa váhy menia počas behu a systém paralelne generuje ďalšie dáta, rozdiel medzi „iba rýchlym backendom“ a „korektným backendom“ sa stáva zásadným.

Pre open-source ekosystém je dôležité aj to, že nejde o akademickú hypotézu bez implementačného kontextu. PipelineRL opisuje architektúru s orchestrátorom, inferenčnými servermi, aktormi, predspracovaním, trénerom a verifikátorom. Už z tejto skladby je zrejmé, že reasoning tréning dnes nie je jediný Python skript s optimizerom, ale distribuovaný systém, v ktorom spolu hovoria fronty, GPU worker procesy a komponenty pre overovanie. V takomto prostredí je veľmi ľahké zameniť chybu architektúry za „správanie modelu“. ServiceNow preto nepriamo pripomína, že pokrok v reasoning modeloch nebude závisieť iba od nových benchmarkov, ale aj od disciplinovaného inžinierstva tréningového stacku.

Z pohľadu trhu je to zaujímavé ešte z jedného dôvodu. Čoraz viac laboratórií a startupov prechádza od čistého fine-tuningu k RL režimom, ktoré majú zlepšiť riešenie úloh, prácu s nástrojmi alebo viac-krokové rozhodovanie agentov. V takom prostredí sa rozdiel medzi modelovou inováciou a infraštruktúrnou inováciou zmenšuje. Ak backend vráti nesprávne logproby alebo nastaví defaulty, ktoré menia tréningový signál, výsledkom nemusí byť iba nižší benchmark. Môže to viesť k falošným záverom o tom, či daná RL metóda funguje. A to je problém nielen pre výskum, ale aj pre firmy, ktoré chcú tieto postupy reálne nasadiť.

ServiceNow zároveň ukazuje zdravý spôsob, ako o takýchto problémoch hovoriť verejne. Namiesto všeobecnej frázy o „optimalizácii výkonu“ rozpisuje konkrétne zlyhávacie režimy a pomenúva, čo bolo treba upraviť. Pre komunitu okolo vLLM je to cennejší typ príspevku než ďalší neurčitý benchmark, pretože dáva návod, kde hľadať regresie pri migrácii medzi verziami. Pre tímy, ktoré dnes stavajú RL pipeline nad otvorenou infraštruktúrou, je hlavná lekcia pomerne jasná: ak sa výsledky po migrácii nečakane rozídu, netreba hneď prepisovať tréningový cieľ. Možno je potrebné najprv skontrolovať, či inferenčný motor vracia presne ten signál, z ktorého sa model vlastne učí.

V širšom kontexte ide o ďalší dôkaz, že ďalšia vlna AI konkurencie nebude len o tom, kto má väčší model alebo agresívnejšie RL. Bude aj o tom, kto má presnejšie, auditovateľnejšie a stabilnejšie tréningové potrubie. Keď sa reasoning modely a agenti presúvajú z demo režimu do produkcie, kvalita infraštruktúry prestáva byť podružná. Text ServiceNow je preto dôležitý práve tým, že vracia pozornosť k základnej technickej disciplíne: skôr než opravovať správanie modelu, treba sa uistiť, že backend správne počíta samotnú realitu, z ktorej sa model učí.