V0 startup
Tichá katastrofa v AI tréninku: Jak buggy inference engine zruinuje celý váš reinforcement learning pipeline
Představte si, že trénujete model s GRPO dvacet hodin, utratíte pěkných pár tisíc korun za GPU čas, a výsledek je horší než základní model. Přesně to se stalo desítkám týmů v průběhu roku 2024 a 2025 — a viník? Ne špatný reward model, ne špatná data. Samotný inference engine vLLM V0 produkoval nedeterministické výstupy, které RL trénink spolehlivě sabotovaly.
vLLM přechod z V0 na V1 není jen upgrade. Je to filozofická změna: nejdřív správnost, teprve pak opravy.
Co bylo špatně s vLLM V0 a proč na tom záleží
vLLM V0 byl revoluce v roce 2023. PagedAttention vyřešil fragmentaci KV cache, throughput se znásobil. Jenže architektura byla postavená na jednom principu: maximální rychlost za každou cenu. Scheduler V0 dělal agresivní preemption — přerušoval sekvence uprostřed generování, odkládal je na disk (swap), a pak pokračoval dál.
Problém číslo jedna: preempce rozbíjela deterministiku. Stejný prompt, stejné parametry, jiný výsledek — záviselo na tom, jak plný byl GPU paměti v momentě inference. Pro produkční chatbot je to nepříjemné. Pro RL trénink je to katastrofa.
RL metody jako PPO, GRPO nebo DPO potřebují stabilní reference policy. Pokud váš inference engine při každém běhu vygeneruje mírně odlišné token probability distributions — i při temperature=0 — reward model dostane jiné inputy při evaluaci vs. při tréninku. Gradient updates se pak snažíte opravit chybu, která ve skutečnosti neexistuje, jen ji vytvořil scheduler.
Konkrétně: v GRPO pipeline, kde generujete G odpovědí na jeden prompt a počítáte relativní reward, stačí aby 2 ze 4 generací měly mírně posunuté pravděpodobnosti (kvůli non-deterministickému scheduling) a reward signal je zašuměný natolik, že model místo učení diverguje. To není teorie — to je reportovaný bug v GitHub issues vLLM z října 2024.
vLLM V1: Nová architektura scheduleru
V1 přichází s kompletně přepsaným schedulerem. Klíčové změny:
Unified KV Cache Manager nahrazuje původní dvouvrstvý systém. V0 měl oddělené bloky pro CPU a GPU swap, přechod mezi nimi byl zdrojem race conditions. V1 má jednotný adresní prostor s deterministickými eviction policies.
Nový scheduler bez preemption-by-default: V1 scheduler dělá preemption pouze jako explicitní fallback, nikoliv jako optimalizaci. Výsledek? Stejný prompt + stejné seed = stejné tokeny. Vždy. Testováno na H100 i A100, replikovatelnost je >99.99% při identical GPU state.
Chunked prefill je teď first-class citizen. V0 ho měl jako experimental flag, V1 ho implementuje správně s ohledem na attention masking. Pro dlouhé kontexty (32K+) tohle není jen optimalizace — je to rozdíl mezi správnými a nesprávnými attention patterns.
Async output processing byl přesunut mimo kritickou cestu scheduleru. V V0 byl výpočet log probabilities synchronní operace, která blokovala scheduler. To vysvětlovalo, proč při high-concurrency workloadech docházelo ke ghost latency spikům i bez swappingu.
Pro RL training to znamená: pokud spouštíte vLLM jako inference server pro online RL (generování rollouts v průběhu tréninku), V1 vám konečně dá konzistentní pravděpodobnostní distribuce, které potřebujete pro korektní gradient výpočet.
Praktický dopad: Jak migrovat a co otestovat
Migrace z V0 na V1 není trivální. Pár věcí, na které narazíte:
```bash python -m vllm.entrypoints.openai.api_server \ --model meta-llama/Llama-3-8B \ --tensor-parallel-size 2
# V1 startup — engine class se změnil python -m vllm.entrypoints.openai.api_server \ --model meta-llama/Llama-3-8B \ --tensor-parallel-size 2 \ --enable-v2-block-manager # V1 scheduler ```
Co zkontrolovat po migraci:
- Deterministika: Spusťte stejný prompt 10x s temperature=0, seed=42. Výsledky musí být bit-for-bit identické. Pokud ne, máte problém v konfiguraci nebo GPU driver version.
- Memory overhead: V1 KV cache manager má cca 8-12% vyšší memory overhead kvůli metadata. Na 80GB A100 tím přijdete zhruba o 7-9GB effective KV cache. Plánujte podle toho.
- Throughput rozdíl: U single-request latency V1 je zpravidla o 5-15% pomalejší než V0. U batch inference je to naopak — V1 má lepší batching a může být 10-20% rychlejší při high concurrency. Pro RL rollout generation (typicky batch=64-256) je V1 výhodnější.
Test pro RL correctness — nejjednodušší verifikační skript:
```python from vllm import LLM, SamplingParams import torch
llm = LLM(model="meta-llama/Llama-3.1-8B", seed=42) params = SamplingParams(temperature=0.0, max_tokens=50)
outputs_1 = llm.generate(["Vysvětli Pythagorovu větu"] 8, params) outputs_2 = llm.generate(["Vysvětli Pythagorovu větu"] 8, params)
for o1, o2 in zip(outputs_1, outputs_2): assert o1.outputs[0].text == o2.outputs[0].text, "NON-DETERMINISTIC!" assert o1.outputs[0].logprobs == o2.outputs[0].logprobs, "LOGPROB MISMATCH!"
print("V1 correctness: OK") ```
Pokud tohle failne na V0 — a failne, zkoušeli jsme — víte proč váš PPO trénink konverguje tak špatně.
HuggingFace TRL knihovna (dostupná na HuggingFace) v nejnovějších verzích explicitně doporučuje V1 pro online DPO a GRPO. Není to coincidence.
Correctness First: Proč to není jen technický detail
Za celý přístup "correctness before corrections" stojí jedna prostá pravda o strojovém učení: garbage in, garbage out. Ale v RL kontextu je to ještě víc komplikované.
Klasický supervised learning má statický dataset. Chyba v inference enginu ovlivní evaluaci, ale trénovací data zůstanou konzistentní. RL online trénink je jiný — trénovací data jsou generované inference enginem. Pokud engine dělá chyby, tyto chyby vstupují do reward výpočtu, gradient výpočtu, a přes weight update zpět do modelu. Zpětná vazba je okamžitá a kumulativní.
Analogie? Představte si, že trénujete šachového agenta, ale šachovnice občas náhodně přesouvá figurky o jedno pole. Agent se naučí "správně" hrát na rozbité šachovnici, ale na normální šachovnici bude hrát špatně. Přesně tohle se děje, když trénujete RL na non-deterministickém inference enginu.
Figure AI nedávno ukázal humanoidní roboty, které zvládají balení zásilek v Amazon skladu. Za tím stojí rozsáhlý RL trénink v simulaci i na reálném hardware. Jeden z inženýrů Figure AI v přednášce zmínil, že přechod na deterministické inference backendy byl klíčový pro reprodukovatelnost jejich reward curves. Nejde tedy o akademický problém — nejrychleji rostoucí robotické firmy světa řeší přesně tohle.
Paralela existuje i v energetice. AI systémy jako Smart Energy Share používají prediktivní modely pro day trading elektřiny a optimalizaci bateriových úložišť BESS 50-250 kW. Pokud inference engine pro tyto modely produkuje nedeterministické výstupy, cenové predikce jsou zašuměné a obchodní rozhodnutí suboptimální — přesně stejný mechanismus jako v RL. Správnost inference vrstvy není luxus, je to základ funkčního AI systému.
Širší kontext: Inference infrastruktura pod tlakem
Íránský požadavek na poplatky za podmořské internetové kabely v Hormuzském průlivu z tohoto měsíce je jen součástí většího trendu: infrastruktura, na které běží AI, se stává geopolitickým nástrojem. Databázové servery, GPU clustery, inference endpoints — to vše závisí na fyzické konektivitě, která prochází potenciálně problematickými oblastmi.
Pro týmy, které provozují produkční RL trénink na cloud infrastruktuře, tohle přidává nový rozměr reliability planování. Non-deterministický inference engine kombinovaný s network partitioning (způsobeným geopolitickými incidenty) je recept na katastrofu. V1 deterministika alespoň eliminuje jeden zdroj nestability.
Open-source alternativy k vLLM existují — Ollama je populární pro lokální deployment, ale nemá async batching vhodný pro RL rollouts. SGLang je alternativa s podobnými zárukami deterministiky jako V1. LMDeploy od Shanghai AI Lab je třetí možnost, primárně optimalizovaná pro Qwen modely.
Pro produkční RL trénink zůstává vLLM V1 nejsilnější volbou z pohledu ekosystému, dokumentace a integrace s HuggingFace TRL. Cena na Lambdalabs: H100 SXM5 = 2,49 USD/hod, A100 80GB = 1,29 USD/hod. Full RL run na 8B modelu s GRPO typicky stojí 50-150 USD podle délky tréninku.
Pokud vás zajímá, jak AI inference ovlivňuje energetické systémy a smart grid management, podívejte se na SmartEnergyShare.info nebo na analýzy bateriových úložišť pro AI datacentry na BESS Global Blog.
Závěr: Správnost je předpoklad, ne vlastnost
vLLM V1 není "lepší V0". Je to přiznání, že rychlost bez správnosti je bezcenná — nebo hůř, aktivně škodlivá. "Correctness before corrections" by mělo být mottem každého, kdo dělá RL trénink v roce 2026.
Praxe: pokud stále používáte V0 pro jakýkoliv RL pipeline, přemigrujte. Věnujte půl dne na verifikaci deterministiky a memory profiling. Pak spusťte baseline RL run a porovnejte reward curves. Skoro zaručeně uvidíte čistší konvergenci.
A pokud vás Spider-Noir ve finálním traileru jako klasický villain naučil něco — pak to, že největší nepřátelé jsou ti, kteří vypadají jako přátelé. V0 vypadal rychle a fungující. Za tím se ale skrývaly chyby, které mohly zničit měsíce RL práce.