vLLM přepsalo svůj motor od základu — a právě proto AI trénink konečně funguje správně
Představte si, že celý rok trénujete model pomocí reinforcement learningu, jenže výsledky jsou podivně nestabilní. Odměnová funkce vypadá správně, data máte kvalitní, hardware běží. A přesto model občas generuje nesmysly, které do trénovacího procesu vnášejí šum. Pak zjistíte, že problém nebyl v modelu samotném — byl v inference enginu, přes který všechno protékalo.
Přesně tenhle scénář přiměl tým za projektem vLLM přepisovat celou architekturu. Výsledek se jmenuje vLLM V1 a jeho motto je neformálně: correctness before corrections. Tedy nejdřív správné výsledky, teprve pak opravy chování modelu.
Co se vlastně pokazilo ve V0
vLLM V0 byl revoluční, když v roce 2023 přišel s PagedAttention — mechanismem, který rozsekal KV cache do stránek podobně jako virtuální paměť v OS. Throughput vystřelil nahoru, latence klesla, a komunita se přeorientovala z Triton Inference Serveru i FasterTransformeru. Celé roky byl vLLM de facto standardem pro produkční serving velkých jazykových modelů.
Jenže architektura V0 vznikla v době, kdy nikdo moc nepočítal s RLHF (reinforcement learning from human feedback) nebo ještě agresivnějšími variantami jako GRPO a PPO nad vlastním inference looperem. Tam se začaly projevovat jemné chyby.
Konkrétně: V0 používal asyncní scheduler, který za určitých podmínek způsoboval nedeterminismus ve výstupech. Při stejném vstupu, stejném seedu a stejných parametrech mohl model vrátit různé tokeny — v závislosti na tom, jak byl batch složen a v jakém pořadí requesty dorazily. Pro běžný chatbot? Nepostřehnutelné. Pro RL trénink, kde každý vygenerovaný token ovlivňuje reward signal? Katastrofa.
Navíc V0 měl problémy s tzv. prefix caching při multi-step sampling — tedy situaci, kdy jeden prompt generujete vícekrát se vzorkováním, abyste dostali různé trajektorie pro RL. Cache se invalidovala neprediktivně, throughput padal a trénink se protahoval zbytečně.
V1: nová architektura od základu
vLLM V1 přišel s kompletním přepisem scheduleru a execution enginu. Klíčové změny:
Deterministický výstup — scheduler V1 zaručuje, že při stejném vstupu a seedu dostanete vždy stejný výstup, bez ohledu na batching. Zní to triviálně, ale implementačně to vyžadovalo přepracovat celé plánování tokenů a způsob, jakým se KV cache alokuje.
Unified executor — V0 měl oddělené cesty pro CPU a GPU execution s různými edge casy. V1 zavádí jednotný executor model, kde GPU a CPU sdílejí společné rozhraní. Výsledek: méně bugů, jednodušší debugging a konzistentnější chování.
Disaggregated prefilling — tohle je velká věc pro velké deploymenty. V1 umožňuje oddělit prefill fázi (zpracování promptu) od decode fáze (generování tokenů) na různý hardware. Prefill je compute-bound, decode je memory-bandwidth-bound — má tedy smysl je škálovat nezávisle. V praxi to znamená, že při RL tréninku můžete mít dedikovaný cluster pro prefill a menší počet GPU pro sampling.
Nový KV cache manager — místo stránek fixní velikosti V1 zavádí flexibilnější bloky s lepší cache hit rate. Při RLHF, kde opakovaně vzorkujete ze stejných promptů (system prompt + partial responses), tohle dramaticky šetří paměť.
Proč na tom záleží při RL tréninku
Reinforcement learning nad LLM funguje zhruba takto: vezmeš prompt, necháš model vygenerovat odpověď, ohodnotíš ji reward modelem nebo člověkem, a výsledek použiješ k aktualizaci vah. Pak to celé opakuješ milionkrát.
Problém je, že celý tento loop je extrémně citlivý na přesnost inference. Pokud inference engine zavede byť malý nedeterminismus nebo subtilní chybu v attention maskování, reward signal se zkontaminuje. Model se učí z "opravených" dat, které ve skutečnosti odrážejí bugy v enginu, ne skutečné chování.
Právě proto je "correctness before corrections" tak důležité. V RL opravujete (corrections) chování modelu pomocí zpětné vazby — ale pokud samotná inference není správná (correctness), opravujete špatné věci.
Tohle není jen akademická diskuze. Firmy jako Mistral AI, Cohere nebo menší výzkumné týmy, které si trénují vlastní modely pomocí open-source stacku (vLLM + TRL + DeepSpeed), narážely na tyhle problémy prakticky. Na Redditu a Discordu vLLM komunity se pravidelně objevovaly dotazy typu "proč mi RL trénink diverguje i s malým learning ratem?" — a část odpovědí vedla právě k inference bugy.
Prakticky: jak migrovat z V0 na V1
Pokud provozujete vLLM v produkci nebo pro trénink, migrace na V1 není triviální. Pár konkrétních věcí:
```bash # Instalace V1 (od verze 0.6.x je V1 výchozí pro nové projekty) pip install vllm>=0.6.0
# Spuštění serveru s V1 enginem vllm serve meta-llama/Llama-3.1-8B-Instruct \ --tensor-parallel-size 2 \ --enforce-eager # pro debugging, v produkci vypnout ```
Důležité: V1 mění chování `--max-num-seqs` a způsob chunked prefill. Pokud máte vyladěné parametry pro V0, pravděpodobně je budete muset přeladit. Doporučený postup je začít s výchozími hodnotami a postupně optimalizovat.
Pro RL workloady konkrétně doporučuji podívat se na `--enable-chunked-prefill` (výchozí v V1) a `--max-num-batched-tokens`. Kombinace těchto dvou parametrů nejvíc ovlivňuje throughput při vzorkování.
Alternativa k vLLM pro inference je Ollama — skvělá pro lokální experimenty a prototypování, ale pro produkční serving nebo RL trénink v clusteru vLLM stále dominuje. HuggingFace nabízí TGI (Text Generation Inference) jako další alternativu s jiným trade-off profilem — dostupné přes HuggingFace.
OlmoEarth v1.1 a efektivita nové generace modelů
Mezitím, co vLLM řeší inference engineering, přichází jiný aspekt rovnice: modely samotné jsou efektivnější. OlmoEarth v1.1 od Allen Institute for AI je dobrý příklad trendu — rodina modelů optimalizovaná pro vědecké a klimatické datasety, přičemž v1.1 přináší zhruba 30% snížení inference costs oproti předchůdci při zachování kvality.
Tohle je relevantní právě v kontextu RL tréninku: čím efektivnější model, tím více kroků RL tréninku si můžete dovolit za stejný rozpočet. OlmoEarth je dostupný na HuggingFace, plně open-source (Apache 2.0), a je to ukázkový příklad toho, jak komunita tlačí hranice efektivity bez zavírání modelů za paywall.
Pro organizace, které chtějí trénovat domain-specific modely (třeba pro energetiku nebo průmysl), je OlmoEarth v1.1 zajímavý jako starting checkpoint — místo Llamy nebo Mistral máte model předtrénovaný na vědeckých datech, což může urychlit fine-tuning na specializované domény.
Geopolitika zasahuje do AI infrastruktury
Irán minulý týden vznesl požadavek, aby Big Tech — tedy Google, Meta, Amazon — platily poplatky za podmořské kabely procházející Hormuzským průlivem. Na první pohled to vypadá jako vzdálená diplomatická pitomost, ale má to přímý dopad na latenci a spolehlivost inference v celém regionu Středního východu a části Asie.
Podmořské kabely jsou páteř internetu. Hormuzský průliv je kritický bod, přes který prochází provoz mezi Evropou, Indií a jihovýchodní Asií. Pokud by Irán skutečně vymáhal poplatky nebo — v horším scénáři — omezil provoz, inference endpointy závislé na cloudové infrastruktuře (AWS, GCP, Azure) by pocítily degradaci.
Pro organizace provozující vlastní inferenci — ať už lokálně nebo v edge cloudech — je tohle argument pro hybridní architekturu: primární výpočet na vlastním hardware, cloudový fallback jen pro špičky. Přesně tohle řeší energetická platforma SES v kontextu energetiky — decentralizace rozhodování, lokální výpočetní kapacita, resilience vůči výpadkům centrální infrastruktury.
Ironicky, ve stejném týdnu federální porota v San Franciscu jednomyslně rozhodla, že Musk žaloval OpenAI příliš pozdě — po zákonné lhůtě. Tahle kauza ukazuje, jak rychle se AI průmysl pohybuje: cokoliv, co se stalo před dvěma lety, je z právního hlediska téměř prehistorie.
Co to znamená pro české vývojáře a firmy
Česká AI komunita je relativně malá, ale aktivní. Firmy, které dnes experimentují s RL tréninkem nebo custom fine-tuningem (typicky fintech, healthtech, nebo průmysl), se setkávají se stejnými problémy jako velcí hráči — jen s menším rozpočtem na debugging.
Praktické doporučení: pokud provozujete inference v lokálním clusteru a uvažujete o RL fine-tuningu, přejděte na vLLM V1 ještě před zahájením tréninku. Zpětná migrace uprostřed experimentu je bolestivá. Kombinace vLLM V1 + TRL (Transformer Reinforcement Learning library od HuggingFace) + LoRA adaptéry je dnes nejdostupnější cesta k vlastnímu RLHF bez milionového rozpočtu.
Hardware realita: RL trénink je těžší než standardní supervised fine-tuning. Potřebujete víc paměti (běží vám inference + training forward/backward pass), víc úložiště (ukládáte více checkpointů), a více času. Minimální setup pro smysluplný experiment s 7B modelem: 2x A100 80GB nebo 4x RTX 4090. Na méně to zvládnete jen s agresivní kvantizací a gradient checkpointingem.
Energetická stránka věci: GPU cluster pro RL trénink spotřebovává řádově 3-8 kW na hodinový experiment. Při delších tréninkových runech to není zanedbatelné — o optimalizaci nákladů na energie a využití přebytků FVE pro výpočetní workloady se více dozvíte třeba na electricshare.cz nebo sdilenienergie.info.
Závěr: správnost není volitelná funkce
vLLM V1 není jen vylepšení — je to přiznání, že předchozí architektura měla fundamentální limitace pro nové use casy. Průmysl se posunul od "jak rychle generujeme tokeny" k "jak správně trénujeme přes inference loopu". Tohle přesunutí priorit je zdravé.
Pokud je jedna věc jistá: firmy, které vsadí na open-source inference stack (vLLM, Ollama, SGLang) a vlastní hardware, budou mít v příštích dvou letech výrazně nižší náklady než ty závislé na cloudových API. Modely jsou stále dostupnější, inference enginy lepší, a hardware dostupnější. Jediná bariéra je know-how.
A geopolitická nestabilita kolem podmořských kabelů ten argument pro lokální infrastrukturu jen posiluje.