Co je to rollout a proč právě on žere peníze
Klasické trénování velkých jazykových modelů funguje jako opisování vzorů. Model dostane předem připravené příklady a snaží se je napodobit. Jenže u reasoningových modelů, které řeší matematiku, programování nebo vícestupňové úlohy, se s tím daleko nedojde — potřebujete, aby si model sám zkoušel různé cesty k řešení a učil se z toho, která fungovala.
Právě tady nastupuje posilované učení (reinforcement learning, RL). Model vygeneruje pro každý úkol několik pokusů o řešení — těm se říká trajektorie — a ty se ohodnotí odměnou. Tyto vygenerované pokusy jsou právě onen rollout. A narozdíl od opisování vzorů se tato tréninková data nevezmou z hotové databáze: pokaždé se musejí vygenerovat znovu, protože model se po každém kroku změní a staré odpovědi už neodpovídají tomu, co umí teď.
Přeloženo do běžného života: je to, jako by se student učil tak, že by před každou kapitolou učebnice musel sám napsat celou písemku, teprve pak by ji učitel opravil a na základě chyb by student zjistil, co se má doučit. Samotné psaní té písemky zabere víc času než učení z ní.
Čísla, která by vás měla zarazit
Autoři přehledu dávají dohromady měření z předchozích studií: v synchronním tréninku, kdy se čeká, až se vygenerují všechny odpovědi, připadá na rollout zhruba 70 % času kroku v jedné studii, 85 % v druhé a přes 90 % u úloh s dlouhými výstupy. Vlastní měření autorů na produkčních datech ukazují menší, ale pořád dominantní podíl: 49 % u běžných odpovědí a 58 % u úloh s dlouhým řetězcem úvah.
Proč tolik? Za prvé, model píše odpovědi token po tokenu, a to prostě trvá. Za druhé, délky odpovědí se divoce liší — jedna matematická úloha zabere 50 tokenů, jiná 5 000. V synchronním režimu čeká celý krok na tu nejdelší odpověď, zatímco zbytek hardwaru stojí nečinně.
Dvě páky, jak to zlevnit — a sedm rodin triků
Studie dělí všechny metody zrychlení do dvou skupin. Systémová páka nechá model generovat stejně, ale zrychlí samotné generování — asynchronní běh, lepší plánování, spekulativní dekódování, které „hádá" další tokeny a pak je jen ověřuje. Algoritmická páka naopak snižuje, kolik generování vůbec potřebujete — vyhazuje úkoly, ze kterých se model nic nenaučí, nebo osekává odpovědi, které by stejně nikam nevedly.
Dohromady autoři mapují sedm technik (od asynchronního řazení přes spekulativní dekódování po výběr a filtrování úloh) proti čtyřem úzkým hrdlům, která v tréninku vznikají: nečinnost mezi generováním a učením, dlouhé konce odpovědí, zbytečné pokusy objevené až po vygenerování a zbytečné úkoly odhalitelné předem.
Právě ten poslední případ je ilustrativní. Když model úkol už spolehlivě umí, nebo ho naopak nezvládne vůbec, všechny vygenerované pokusy dostanou stejnou odměnu — a z pohledu učení se z nich model nic nedozví. Říká se tomu degenerovaná skupina a je to plýtvání, kterému se dá předejít jen tehdy, když obtížnost úkolu odhadnete dřív, než začnete generovat.
Problém není, že by se nezkoušelo — problém je, že se to nedá porovnat
Nejcennější část přehledu není katalog triků, ale rozbor toho, jak se o zrychlení píše. Ze 80 metod jich 50 hlásí jen systémové zrychlení a 17 jen algoritmické. Obě páky zároveň měří jen 12 metod. To znamená, že u drtivé většiny článků nevíte, jestli se model naučil stejně dobře rychleji, nebo jen rychleji generuje odpovědi, ze kterých se naučí míň.
Autoři navíc pojmenovávají pět důvodů, proč se čísla z různých prací nedají srovnat. Nejpěknější příklad: metoda DORA hlásí 8,2× zrychlení samotného rolloutu, ale jen 2,12× celého tréninku — obě čísla jsou správná, jen odpovídají na jinou otázku. Nebo HybridFlow: jediný systém dosáhne rozptylu 1,53× až 20,57× jen podle toho, jak ho nakonfigurujete — to je větší rozdíl, než jaký dělí mnoho konkurenčních metod.
Moje rychlá kontrola přes Amdahlův zákon
Tohle je přesně případ, kdy si číslo umíte dopočítat sami. Jestli rollout tvoří 90 % času kroku, pak i kdybyste ho zrychlili na polovinu, celý krok se zkrátí jen o 45 %, ne o polovinu — zbylých 10 % (odměny, aktualizace vah, synchronizace) se nezmění. A když navíc započítáte, že se s metodou může změnit i počet potřebných kroků, je jediné rozumné měřítko celkové náklady na dosažení cílové kvality. Autoři proto navrhují sjednocenou metriku: náklady v akcelerátorových hodinách na dosažení dané kvality.
Co to znamená pro výzkum i pro Česko a Evropu
Pro laika může tohle všechno znít jako interní technikálie datacenter. Jenže o nic menšího nejde než o to, kolik výpočtu (a tedy peněz a elektřiny) spolkne další generace modelů. Když se dnes o „drahém tréninku" mluví, většina pozornosti padá na předtrénink — a tenhle přehled připomíná, že u přemýšlejících modelů se srovnatelné náklady opakovaně generují i ve fázi, která následuje po něm.
Pro evropské výzkumné projekty a firmy, které post-trainují vlastní modely — a Evropa v tom kvůli snaze o menší závislost na americké a čínské infrastruktuře investuje stále víc — je sjednocený způsob vykazování zrychlení prakticky užitečný: dovolí porovnat, která metoda je skutečně levnější, místo aby se čísla vzájemně přebíjela bez společného jmenovatele. Směrem k praktickému využití míří i konkrétní výsledky, které přehled cituje: metoda PODS dosáhne maximální přesnosti 1,7× dříve, POPO se dostane na úroveň ostatních při zhruba 30 % rozpočtu na generování a TailSieve ukazuje, jak se zrychlení sčítá — 1,67× za chytré řazení a 2,59×, když se k němu přidá spekulace.
Studie zároveň férově přiznává limity. Většina algoritmických metod se testuje skoro výhradně na jednostranných úlohách s jednoznačně ověřitelnou odpovědí, jako je matematika — u agentních úloh s částečnými odměnami se jejich předpoklady rozpadají. A 11 z 80 metod vůbec neuvádí, na jaké úloze byla testována, takže podmínky, za kterých jejich čísla platí, nejsou známé.
Shrnutí: kde se skrývá skutečná úspora
Poselství přehledu se dá shrnout do jedné věty: zrychlení psaní odpovědí je užitečné, ale teprve metrika „náklady na dosaženou kvalitu" řekne, jestli model reálně zlevnil, nebo jen rychleji produkuje data s malou učební hodnotou. Pro kohokoli, kdo trénuje přemýšlející modely, to znamená jediné — přestat hlásit jedno číslo a začít hlásit křivku.
Proč se reasoningové modely trénují jinak než běžné jazykové modely?
Běžné modely se učí napodobováním hotových příkladů. Reasoningové modely potřebují samy zkoušet více cest k řešení a učit se z výsledků, takže část tréninkových dat se generuje za běhu posilovaným učením. Právě toto opakované generování (rollout) je výpočetně nejnáročnější.
Co přesně je degenerovaná skupina a proč vadí?
Když model úkol už spolehlivě zvládá nebo ho vůbec nezvládá, dostanou všechny jeho pokusy stejnou odměnu a z hlediska učení nepřinášejí žádný signál. Model tak spotřebuje plný rozpočet na generování, aniž by se z něj cokoli naučil.
Dá se zrychlení z jednotlivých studií jednoduše sečíst?
Ne. Část metod si konkuruje (útok na stejný zdroj plýtvání) a část si vzájemně podkopává předpoklady, třeba asynchronní běh a spekulativní dekódování. Bez společného měřítka nemá násobení zrychlení žádný smysl.