Share-Electric.cz
Údržba

nebo pro konkrétní verzi

nebo pro konkrétní verzi

Tady je článek:

Nadpis: Rok tichých chyb v AI trénování: Jak vLLM V0 klidně kazil reinforcement learning a nikdo to neřešil

Představte si, že trénujete jazykový model za desítky tisíc dolarů na AWS, výsledky vypadají slušně — a pak zjistíte, že framework, který jste používali, produkoval nesprávné výstupy při inference po celou dobu RL tréninku. Ne dramaticky špatné, ale tiše, systematicky špatné. Přesně to se stalo s vLLM V0 a reinforcement learningem.

Tým za vLLM to nakonec pojmenoval jednoduše: Correctness Before Corrections. Nejdřív opravit co je fundamentálně rozbité, pak teprve přidávat funkce.

Co je vLLM a proč na tom záleží víc, než si myslíte

vLLM je open-source inference engine pro velké jazykové modely, původně vydaný Berkeleyskou skupinou v roce 2023. Jádrem bylo PagedAttention — přístup k správě KV cache inspirovaný operačními systémy, který radikálně zlepšil propustnost při inference. Výsledek? Na stejném hardwaru najednou zvládnete 5-10× více paralelních requestů než s naivní implementací.

Na HuggingFace si dnes vLLM stáhne desítky tisíc týdně. Běží na AWS, GCP, Azure i na lokálních serverech s A100 nebo H100 kartami. Stalo se de facto standardem pro produkční nasazení open-source modelů — Llama 3, Mistral, Qwen, DeepSeek.

Jenže popularita přišla rychle a s ní i technický dluh. V0 architektura byla navržena primárně pro inference — tedy situaci, kdy máte hotový model a chcete z něj co nejrychleji dostat odpovědi. Reinforcement learning je ale jiný svět.

Problém s V0: Inference při RL tréninku není totéž co produkční inference

Reinforcement learning z lidské zpětné vazby (RLHF) nebo jeho modernější varianta GRPO funguje tak, že model nejdřív vygeneruje odpovědi, ty se ohodnotí reward modelem, a na základě odměn se aktualizují váhy. Generování odpovědí probíhá přesně tím frameworkem, který pak použijete i v produkci — tedy vLLM.

Tady byl skrytý problém V0.

Když vLLM generuje tokeny pro RL trénink, potřebuje poskytovat log-pravděpodobnosti jednotlivých tokenů (log-probs) — informaci o tom, jak moc si model byl jistý každou volbou. Tyto hodnoty jsou kritické: algoritmy jako PPO nebo GRPO z nich počítají gradient aktualizace.

V V0 implementaci docházelo k jemným, ale systematickým chybám v těchto výpočtech. Problém nebyl triviální — vycházel z interakce PagedAttention s numerickou přesností při specifických délkách sekvencí a konfiguracích KV cache. Výsledky tréninku vypadaly rozumně, metriky se zlepšovaly, ale model se učil z nepřesných signálů.

Konkrétní čísla: interní testy vLLM týmu ukázaly odchylky v log-probs až v řádu $10^{-3}$ na token. Zdá se to málo. Přes celou sekvenci 2048 tokenů se ale chyba akumuluje a policy gradient dostane zkreslený signál. To je rozdíl mezi modelem, který se naučí dobře, a modelem, který konverguje do lokálního optima, které vypadá dobře na benchmarcích, ale chybí mu subtilní reasoning.

V1: Architektonická rewrite s jedním mottem

Přechod na V1 nebyl incremental patch. Byl to zásadní přepis klíčových komponent s jasnou prioritou: korektnost nad rychlostí, nad funkcemi, nad zpětnou kompatibilitou.

Correctness Before Corrections in RL — tahle věta z interní dokumentace vLLM týmu vystihuje filosofii celé V1.

Konkrétní změny: - Nový scheduler: V0 používal batch scheduling, který optimalizoval propustnost. V1 přidává async scheduler s explicitní podporou pro RL workloady, kde je kritické zachovat deterministické pořadí tokenů. - Přepracovaný KV cache manager: místo implicitního block allocation V0, V1 přináší explicitní, auditovatelnou správu cache bloků s granulárním logováním. - Numerická přesnost log-probs: přepočet log-pravděpodobností byl kompletně revidován, včetně edge cases při různých délkách sekvencí. - Modulární architektura: V0 byl monolitický, V1 má čisté rozhraní mezi inference enginem a RL orchestrátorem.

Pro uživatele to znamená: pokud trénujete jakýkoliv RL-based model (RLHF, DPO, GRPO, RLOO) a stále jedete na vLLM V0, přecházejte. Není to otázka výkonu — je to otázka správnosti.

AWS, EMO a trénink Mixture of Experts na cloudu

Kontext, ve kterém vLLM V1 vznikl a kde se testuje, je ale větší. AWS publikoval sérii příspěvků o Building Blocks for Foundation Model Training and Inference — infrastruktuře pro trénink a inference foundation modelů na jejich platformě.

Součástí je i EMO (Emergent Modularity in pretraining) — přístup k trénování Mixture of Experts (MoE) architektur, kde se specializace jednotlivých expertů nevynucuje explicitně, ale emerguje z dat a tréninkového procesu.

Proč je to relevantní pro vLLM V1? Protože MoE modely mají specifické inference charakteristiky. Různé tokeny jsou routovány k různým expertům, KV cache je komplexnější a log-prob výpočty jsou náchylnější k chybám. Přesně ta třída problémů, které V0 nezvládal.

Na AWS to vypadá konkrétně takto: trénink EMO modelu na p4d.24xlarge instancích (8× A100 80GB, ~33 USD/hod za on-demand, nebo ~11 USD/hod za spot), inference pak na p3.16xlarge nebo g5 instancích. Pro RL fázi s vLLM V1 doporučují minimálně dvě GPU pro rollout generaci a jednu GPU pro reward model.

Celkové náklady na RL fine-tuning slušného 7B modelu na AWS? Počítejte s 500-2000 USD za experiment, podle délky trénování a cen spot instancí.

Lokální alternativa existuje: Ollama pro lokální serving, ale bez podpory pro RL trénink. Pro skutečný RL workflow na lokálním hardwaru potřebujete minimálně dva H100 nebo čtyři A100 — to je hardware za 60-150 tisíc dolarů. Cloud v tomto případě dává smysl.

Praktické nasazení: migrace z V0 na V1

Pokud spravujete vlastní inference cluster nebo RL pipeline, migrace na V1 má konkrétní kroky.

Nejdřív aktualizace: ```bash pip install vllm --upgrade pip install vllm==0.6.0 ```

V1 architektura vyžaduje explicitní konfiguraci pro RL workloady. Klíčové parametry při inicializaci `LLM` objektu:

```python from vllm import LLM, SamplingParams

llm = LLM( model="meta-llama/Llama-3-8B-Instruct", enable_prefix_caching=True, max_model_len=8192, tensor_parallel_size=2, ) ```

Pro RL sampling — kde potřebujete log-probs — je zásadní správně nastavit `SamplingParams`:

```python sampling_params = SamplingParams( temperature=1.0, top_p=0.95, max_tokens=512, logprobs=1, # Vrátí log-probs pro každý token prompt_logprobs=1, ) ```

Největší past při migraci: V1 změnil formát výstupu log-probs. Kód, který parsoval výstupy z V0, bude tiše vracet nesmysly nebo crashovat. Zkontrolujte `output.prompt_logprobs` a `output.outputs[0].logprobs` — struktura je nová.

Technické detaily, doporučení a changelog najdete přímo v vLLM dokumentaci na HuggingFace.

Proč na tom záleží i mimo AI výzkum

Mohlo by se zdát, že tohle je akademická diskuze pro pár laboratoří. Není.

Reinforcement learning se stává standardní součástí produkčního trénování modelů. OpenAI, Anthropic, Google, Mistral — všichni používají RL fázi. Ale i menší firmy a projekty, které fine-tunují open-source modely pro specifické domény, začínají s RL experimentovat.

Energetický sektor je dobrý příklad. Modely pro predikci spotřeby, optimalizaci nabíjení baterií, nebo day trading s elektřinou potřebují být trénované na doménově specifických datech s reward signálem odvozeným z reálných tržních výsledků. Pokud vaše RL pipeline běží na vLLM V0, učíte se z nepřesných gradientů.

Platformy jako SmartEnergyShare, které orchestrují obchodování s flexibilitou, regulační elektřinou a BESS úložišti o kapacitě 50-250 kW, začínají integrovat AI rozhodování přímo do tradingových algoritmů. Správnost inference při RL tréninku zde přechází z akademického problému na finanční riziko.

Pokud AI model rozhoduje o nabíjení baterie a byl trénován s nesprávnými gradients, chyba se neprojeví na benchmarku — projeví se na P&L. Tomuto tématu se podrobněji věnují kolegové na electricshare.cz v kontextu inovací v energetickém obchodování.

Závěr: Správnost není feature, je to prerekvizita

Přechod vLLM z V0 na V1 je lekcí, která přesahuje konkrétní software. Komunita kolem LLM inference vybudovala výkonné nástroje velmi rychle, pod tlakem poptávky. Rychlost a propustnost se měřily snadno — správnost při RL tréninku méně.

Correctness Before Corrections jako motto říká něco důležitého: dokud nevíte, že vaše fundamenty jsou správné, každá optimalizace nad nimi je potenciálně optimalizace špatného chování.

Pro praktikující: aktualizujte vLLM, ověřte kompatibilitu vašeho RL kódu, a pokud trénujete na AWS, zkontrolujte AWS dokumentaci k EMO a MoE inference — tam jsou konkrétní doporučení pro V1 konfigurace.

Předpověď: do roku 2027 bude správnost inference při RL tréninku certifikovaný požadavek pro AI modely nasazené v regulovaných odvětvích — energetice, zdravotnictví, financích. Kdo to řeší teď, bude mít náskok. Kdo to ignoruje, bude přepisovat pipeline pod tlakem auditu.

Více o praktickém využití AI v energetice najdete na smartenergyshare.cz, kde sledujeme vývoj VPP a inteligentních optimizérů pro české distribuční sítě.

Zdroje

← Zpět na všechny články