vLLM V1: Tichá revoluce, která zachránila trénink AI modelů za miliony dolarů

Představte si, že šest měsíců trénujete velký jazykový model na AWS klastru se stovkami GPU. Utratíte přes půl milionu dolarů. A pak zjistíte, že inference engine, který jste používali pro generování trénovacích dat, tiše produkoval nesprávné výstupy. Váš model se naučil chybám. Celý RLHF pipeline byl zkažený od základů.

Přesně tohle se mohlo stát — a pravděpodobně v nějaké podobě stávalo — každé laboratoři, která v roce 2023 a 2024 trénovala modely pomocí reinforcement learningu s vLLM V0. Přechod na vLLM V1 nebyl jen technologický upgrade. Byl to přiznání chyb a radikální přestavba architektury od základu.

Proč správnost inference rozhoduje o osudu RL tréninku

Reinforcement learning z lidské zpětné vazby (RLHF) nebo novější metody jako GRPO (Group Relative Policy Optimization) mají jednu nepříjemnou vlastnost: jsou extrémně citlivé na kvalitu dat generovaných samotným modelem. V klasickém supervised learning vám chybný batch dat pokazí batch. V RL vám chybná inference může pozvolna a neviditelně zkřivit celou reward signal.

Konkrétně: pokud váš sampler při beam search nebo temperature sampling vrací tokeny s mírně nesprávnou pravděpodobností, model se začne učit distribucí, která neodpovídá skutečnému policy. Reward model pak odměňuje nebo trestá akce, které model ve skutečnosti neprovedl tak, jak si myslíte. Výsledek? Model vykazuje degeneraci — halucinácie rostou, instruction following se zhoršuje, nebo se model naučí exploatovat reward model způsoby, které nevypadají problematicky na benchmarkách, ale selhávají v produkci.

vLLM V0 mělo v tomto ohledu několik kategoriálních problémů. Největší z nich: non-deterministické chování při paralelním zpracování, race conditions v KV cache managementu a subtilní chyby v log-probability výpočtech při použití PagedAttention s určitými konfiguracemi dávkování.

Co bylo skutečně rozbité ve V0

PagedAttention — přelomový příspěvek vLLM z roku 2023 — vyřešil problém fragmentace GPU paměti virtuální stránkovou tabulkou pro KV cache. Bylo to geniální. A zároveň to zaneslo komplexnost, která se projevila v hraničních případech.

Konkrétní problémy, které tým zdokumentoval před vydáním V1:

Chunked prefill a log-probs nesoulad. Když je prompt příliš dlouhý a musí se zpracovat ve více chuncích, V0 v některých scénářích vracel mírně odlišné log-probability hodnoty oproti single-pass zpracování. Rozdíly byly v řádu epsilon, ale pro RL algoritmy jako PPO, které pracují s policy ratios (π_new/π_old), to stačilo k destabilizaci tréninku.

Prefix caching a korektnost. V0 implementoval prefix caching agresivně — opakující se část promptu se načetla z cache. Skvělé pro latenci, problematické pro korektnost, pokud se cache invalidace chovala neočekávaně při concurrent requests.

Sampling při beam search. Implementace beam search v V0 nesledovala přesně specifikaci transformers knihovny. Pro produkční inference to bylo irelevantní. Pro RL trénink, kde potřebujete přesnou reprodukovatelnost pro výpočet advantage estimates, to byl zásadní problém.

Vývojáři z DeepMind, Anthropic i menších laboratoří to identifikovali nezávisle na sobě — a řada z nich přešla na jiné inference enginy pro RL fázi, zatímco vLLM používali jen pro produkční serving. Toto rozdělení bylo symptomem problému.

vLLM V1: Architektura postavená na správnosti, ne rychlosti

Klíčová rozhodnutí V1 architektury jsou vidět přímo v kódu a commit history na HuggingFace komunitě. Přestavba prošla třemi hlavními pilíři.

Scheduler přepsal od nuly. V0 scheduler byl reaktivní — reagoval na požadavky jak přicházely a snažil se maximalizovat batch fill rate. V1 scheduler je proaktivní a deterministický. Před každým krokem vytvoří konzistentní plán, který zaručuje, že stejný vstup + seed vždy produkuje stejný výstup. Pro RL trénink to znamená reprodukovatelnost, kterou PPO a GRPO vyžadují.

Logprob pipeline jako first-class citizen. V V1 jsou log-probability výpočty architektonicky odděleny od sampling pipeline a testovány nezávisle. Tím se eliminuje možnost, že optimalizace samplerů nezáměrně změní log-prob values. Nová pipeline prošla rozsáhlými unit testy porovnávajícími výsledky vůči referenční implementaci v PyTorch.

Async-first design. V0 byl synchronní engine s async wrapperem. V1 je async od základu — pomocí asyncio a coroutine-based schedulingu. To eliminovalo celou kategorii race conditions, které trápily V0 při high concurrency workloadech typických pro RL rollout fáze.

Výsledek? Benchmarky ukazují, že V1 je v průměru o 1,7× rychlejší než V0 na identical hardware — ale to je vedlejší produkt. Primárním cílem bylo: správnost. Výkon je bonus.

AWS a stavební bloky pro trénink foundation modelů

Amazon Web Services publikoval v roce 2025 sérii článků o infrastruktuře pro trénink foundation modelů, a vLLM V1 v ní hraje konkrétní roli. AWS tradiční přístup ke scale-out tréninku využívá EC2 P5 instance s H100 GPU (96 GB HBM3 každá), propojené pomocí EFA (Elastic Fabric Adapter) s propustností 3,2 Tb/s.

Pro RLHF pipeline na AWS vypadá standardní setup zhruba takto: tréninkový cluster běží na SageMaker Training Jobs nebo přímo na EC2 P5 instancích s PyTorch FSDP (Fully Sharded Data Parallel). Paralelně běží inference cluster — typicky na menším počtu GPU — který zajišťuje rollouts. Právě zde sedí vLLM V1.

Komunikace mezi tréninkovou a inference vrstvou probíhá přes Redis nebo direct socket spojení. Aktér (model generující odpovědi) sdílí váhy s kritikem periodicky pomocí checkpointů. Celý pipeline může spotřebovat 500 GPU hodin denně pro model velikosti 70B parametrů.

Orientační náklady na AWS: EC2 P5.48xlarge (8× H100) vychází na přibližně 98 USD/hodinu. Týdenní RL trénink 70B modelu tak klidně přijde na 50–100 tisíc dolarů. Chyba v inference enginu způsobující 10% degradaci výkonu modelu představuje přímou ekonomickou ztrátu v desítkách tisíc dolarů.

MoE modely a EMO: Emergentní modularita jako nová hranice

Souběžně s vývojem vLLM V1 probíhá v akademické i průmyslové sféře intenzivní výzkum Mixture of Experts (MoE) architektur s důrazem na to, co výzkumníci nazývají EMO — Emergent Modularity přes pretraining.

Tradiční MoE modely jako Mixtral 8×7B mají routing pevně definovaný: každý token jde k omezenému počtu expertů, router je trénován explicitně k tomu, aby se naučil routovat. EMO výzkum jde jiným směrem — místo aby routování vynucoval, nechává ho emergovat přirozeně z pretraining dynamiky.

Co to znamená prakticky? Výzkumníci z ETH Zurich a několika průmyslových laboratoří ukázali, že pokud trénujete dostatečně velký MoE model s vhodnou regularizací, experti spontánně specializují na různé typy znalostí — jeden cluster expertů zpracovává matematiku, jiný přírodní jazyk, další kód. Tato specializace nebyla explicitně vyžadována — emergovala.

Pro vLLM to přináší nové výzvy. Expert routing je dynamický per-token — a správné logprob výpočty u MoE modelů jsou výrazně složitější než u dense modelů. Jeden z klíčových testů vLLM V1 byl právě na Mixtral architektuře, kde V0 vykazoval chyby v log-prob agregaci přes experty.

Na HuggingFace lze dnes stáhnout několik EMO-inspirovaných MoE modelů v rozmezí 8B–47B parametrů. Pro experimentování s RL fine-tuningem na vlastním hardware doporučuji začít s Mixtral 8×7B s vLLM V1 serverem — a vyhradit minimálně 2× A100 nebo H100 GPU pro 16-bit inference.

Praktické nasazení: Jak na to bez miliardového rozpočtu

Dobrá zpráva: vLLM V1 je open-source a běží i na konzumním hardware. Špatná zpráva: pro RL trénink potřebujete víc než jen inference engine.

Minimální stack pro vlastní RLHF pipeline:

```bash # Instalace vLLM V1 pip install vllm>=0.4.0

# Spuštění inference serveru python -m vllm.entrypoints.openai.api_server \ --model mistralai/Mistral-7B-Instruct-v0.3 \ --dtype bfloat16 \ --enable-chunked-prefill \ --max-model-len 4096 ```

Pro RL trénink pak potřebujete TRL (Transformer Reinforcement Learning) knihovnu od HuggingFace nebo OpenRLHF. Klíčové je napojit vLLM jako rollout engine:

```python from trl import PPOTrainer, PPOConfig # vLLM V1 endpoint jako rollout generator config = PPOConfig( model_name="mistralai/Mistral-7B", use_vllm=True, # použij vLLM pro rollouts vllm_server_host="localhost:8000" ) ```

Na spotřebitelské RTX 4090 (24 GB VRAM) zvládnete RL trénink modelu do 7B parametrů s batch size 4–8. Čas: desítky hodin pro viditelné zlepšení. Na 2× H100 přes cloud (pronájem přibližně 6–8 USD/hodinu za oba) je to věc dní.

LoRA adaptéry výrazně snižují paměťové nároky — s QLoRA a 4-bit kvantizací zvládnete RLHF i na 16 GB VRAM GPU. Výsledný model nebude state-of-the-art, ale pro specializovanou doménu (zákaznická podpora, analýza energetických dat) to může stačit.

Optimalizace energetického portfolia a predikce spotřeby patří k oblastem, kde RLHF výrazně zlepšuje výkonnost modelů. Propojení s platformami jako energetická platforma SES může přinést zajímavé use cases — od automatického obchodování odchylek po optimalizaci nabíjení BESS úložišť. Více o praktickém využití AI v energetice najdete na [BESS Global Blog](https://bess-global-blog.vercel.app).

Co to znamená pro budoucnost

vLLM V1 je víc než upgrade. Je to doklad, že open-source inference infrastruktura dospěla do fáze, kde si výzkum za stovky milionů dolarů nemůže dovolit ji ignorovat. Velké laboratoře jako DeepSeek a Qwen stavějí své RL pipeline na vLLM — a jejich výsledky (DeepSeek-R1, Qwen-2.5) jsou přímým důkazem, že správná inference engine je zásadní proměnná v rovnici.

Pro rok 2026 platí: kdo chce trénovat jazykové modely pomocí RL, musí rozumět inference enginu stejně dobře jako trénovacímu frameworku. Hranice mezi "serving" a "training infrastructure" mizí.

Predikce na závěr: do dvou let bude vLLM nebo jeho přímý nástupce standardní součástí většiny SageMaker pipeline šablon na AWS. A chyba v log-prob výpočtu bude stejně nepřijatelná jako SQL injection ve webové aplikaci.

Pro praktické nasazení AI v energetickém sektoru a detailní návody na sdílení elektřiny se podívejte na ShareElectric.cz.