Příklad výstupu EMO monitoring sidecar
Směs expertů, která se naučila sama sobě vládnout: EMO mění pravidla trénování LLM
Většina výzkumníků v oblasti velkých jazykových modelů se na chvíli zarazí, když se jich zeptáte, kolik parametrů jejich model skutečně "používá" při inferenci. Odpověď je totiž překvapivá: u klasické husté architektury to jsou všechny. U Mixture of Experts (MoE) je to zlomek — a právě tady vstupuje do hry EMO.
EMO, celým jménem Emergent Modularity through pretraining, není jen další varianta MoE architektury. Je to způsob, jak nechat model, aby si sám rozhodl, která část jeho "mozku" se kdy zapne — bez toho, aby mu to člověk explicitně naprogramoval. Výsledkem je systém, který je levnější na provoz, snáze udržovatelný a překvapivě stabilní při nasazení na AWS infrastruktuře.
Co je EMO a proč na tom záleží
Klasické MoE modely fungují jednoduše: máte síť routerů, která pro každý token vybere 2-8 "expertů" z celkového fondu třeba 64 nebo 128 specializovaných podsítí. GPT-4 je pravděpodobně MoE. Mistral 8x7B je definitivně MoE. Problém klasického přístupu spočívá v tom, že modularita je vynucená — router se trénuje souběžně s experty a celý systém musí konvergovat najednou.
EMO přistupuje k problému jinak. Během předtrénování se modelu nedává pevná routovací logika. Místo toho se vytváří podmínky, za nichž modularita emerge — vzniká organicky jako vedlejší produkt trénovacího procesu. Experti se specializují proto, že to je efektivnější, ne proto, že jim to někdo nařídil.
Konkrétně: výzkumníci z AWS AI Labs publikovali výsledky, kde EMO model s 47 miliardami parametrů dosahuje srovnatelné přesnosti jako hustý model s 70 miliardami parametrů — ale při inferenci aktivuje jen 13 miliard. To je přibližně 5násobný výpočetní úsporný faktor na token. Na praktické úrovni to znamená, že instanci ml.p4d.24xlarge na AWS lze použít tam, kde byste jinak potřebovali cluster.
Modely a checkpointy z tohoto výzkumu jsou dostupné na HuggingFace, kde si je může každý prohlédnout, porovnat nebo použít jako základ pro fine-tuning.
Jak AWS postavil infrastrukturu pro EMO trénink
"Building Blocks for Foundation Model Training and Inference on AWS" — to je název programu, v jehož rámci AWS otevřel část své interní toolchainové sady pro výzkum. EMO byl jedním z prvních modelů, které ji plně využily od nuly.
Praktická architektura trénování EMO vypadá takto:
Hardware: Cluster SageMaker HyperPod na instancích p4de.24xlarge (8× A100 80GB). Komunikační backplane přes EFA (Elastic Fabric Adapter) s propustností 400 Gb/s mezi nody. Při trénování modelu v rozsahu 47B parametrů autoři použili 512 GPU po dobu přibližně tří týdnů.
Software stack: FSDP (Fully Sharded Data Parallelism) přes PyTorch, FlashAttention-2 pro attention mechanismy a vlastní fork Megatronu pro pipeline parallelismus. Routovací logika EMO je implementována jako oddělená komponenta, která se přidává k základní transformer architektuře — není pevně zadrátovaná do jádra.
Checkpoint management: SageMaker s3-backed checkpointy každých 500 kroků. Při výpadku nodu se trénink obnoví z předchozího checkpointu — bez ztráty více než 15 minut práce. Toto je klíčové pro MoE modely, protože jejich stav je výrazně složitější než u hustých modelů (každý expert má vlastní váhy).
Zajímavý detail z technické dokumentace: EMO trénování vyžaduje speciální úpravu learning rate scheduleru. Protože se modularita vynořuje postupně, je potřeba delší "warm-up" fáze a konzervativnější decay. Autoři skončili na warm-up 2000 kroků oproti standardním 400-800 pro srovnatelné husté modely.
vLLM V1: Proč byla V0 v podstatě technický dluh
Souběžně s výzkumem EMO probíhalo i přepracování vLLM — open-source inference enginu, který je de facto standardem pro nasazení LLM v produkci. Přechod z V0 na V1 je dobrým příkladem toho, jak dramaticky se prostředí změnilo za méně než dva roky.
vLLM V0 vzniklo v roce 2023 jako důkaz konceptu pro PagedAttention — techniku, která zásadně zlepšila využití GPU paměti při inferenci. Fungovalo, ale bylo postavené na předpokladech, které přestávají platit: synchronní zpracování requestů, centralizovaný KV cache manager, žádná podpora pro speculative decoding nebo multi-modal vstupy.
V1 staví celou architekturu od nuly s principem "Correctness Before Corrections" — což je poměrně sebereflexivní název pro framework, jehož předchůdce měl v produkci pár záludných race conditions. Konkrétní změny:
- Async execution engine: requesty se zpracovávají asynchronně, batch scheduler funguje jako samostatný process
- Disaggregated KV cache: prefill a decode fáze mohou běžet na různých instancech (kritické pro MoE, kde se experti nenačítají celí do VRAM)
- Nativní podpora pro speculative decoding: draft model může být jiný než target model — relevantní pro EMO, kde "draft" může být menší hustý model
- Čistší plugin API: přidání nového modelu (třeba EMO architektury) nevyžaduje hacky v jádru
Pro provozovatele AI služeb je přechod na V1 bolestivý — staré konfigurace nefungují, část PyThon API se změnila. Ale výkon při zpracování long-context EMO modelů je o 40-60 % lepší oproti V0 na stejném hardware.
Údržba: Kde EMO a vLLM V1 opravdu svítí
Teď k praktické stránce věci — a tady je ta část, která technické manažery zajímá nejvíce.
MoE modely mají v tradičním nasazení reputaci nočních můr na údržbu. Expert routing vytváří nerovnoměrné využití GPU paměti, load balancing mezi experty driftuje v průběhu doby, a pokud jeden expert začne "dominovat" (tzv. expert collapse), model se tiše zhorší bez jakékoliv explicitní chybové zprávy.
EMO řeší expert collapse na úrovni tréninku — ale co se děje po nasazení?
Autoři integrovali do modelu monitoring routovacích statistik jako first-class feature. Každých N tokenů se loguje distribuce aktivací expertů. Pokud se distribuce vzdálí od baseline o více než 2 standardní odchylky, systém vydá alert. V praxi to vypadá takto:
```bash {"timestamp": "2026-05-18T09:00:00Z", "expert_utilization": [0.12, 0.14, 0.09, 0.11, ...], "entropy": 3.47, "alert": null} {"timestamp": "2026-05-18T09:05:00Z", "expert_utilization": [0.31, 0.02, 0.08, 0.01, ...], "entropy": 1.82, "alert": "DISTRIBUTION_DRIFT"} ```
Druhý záznam by v produkčním systému spustil automatický rebalancing — nebo minimálně upozornění, že je třeba zkontrolovat kvalitu vstupních dat.
Pro týmy, které provozují inference na AWS, je klíčové nastavit CloudWatch alerty na tyto metriky hned od začátku. Zpětné dohledávání problémů přes logy je v MoE systémech exponenciálně těžší než u hustých modelů.
Samostatnou kapitolou je fine-tuning EMO modelů. LoRA (Low-Rank Adaptation) funguje, ale vyžaduje zvláštní zacházení s routovací vrstvou — tu nechcete adaptovat, protože byste přepsali emergentní modularitu, která se tvořila týdny. Správný přístup je zmrazit router a adaptovat pouze experty. Na HuggingFace PEFT knihovně to v praxi znamená přidat router parametry do `modules_to_save` místo `target_modules`.
Open-source alternativy a reálné náklady
Ne každý má přístup k 512 A100 GPU. Dobrou zprávou je, že EMO přístupy se pomalu přesouvají i do menších modelů.
Mixtral 8x7B je stále nejdostupnějším MoE modelem pro vlastní provoz. Přes Ollama ho rozjedete na serveru se dvěma GPU A10G (každý 24 GB VRAM) za přibližně 180 000 Kč na nákup hardware, nebo za 3-5 USD/hodina na AWS. Výkon odpovídá přibližně 30-miliardovému hustému modelu za cenu 13-miliardového.
Dario Mistral 8x22B je náročnější — potřebujete čtyři GPU s dostatkem VRAM (ideálně 4× A100 80 GB), ale na HuggingFace je volně dostupný a pro anglické texty překonává většinu dostupných open-source hustých modelů.
EMO v čisté podobě je zatím přístupný přes AWS SageMaker JumpStart nebo přes Bedrock API, kde ceny za input/output token jsou srovnatelné s Claude 3 Haiku. Pro experimentování je přiměřená investice; pro produkci je nutná důkladná cost-benefit analýza.
Detailní srovnání architektury MoE modelů a jejich využití v energetickém sektoru najdete na SmartEnergyShare.info, kde jsme mapovali, jak AI inference ovlivňuje predikci spotřeby v distribuovaných energetických systémech.
Co to znamená pro budoucnost inference
Emergent modularity je víc než technický trick. Je to signál, že trénovací dynamika samotná může nahradit část explicitního inženýrského návrhu. Pokud model dokáže sám identifikovat, které části jeho architektury by měly být specializované, otevírá to cestu k modelům, které se automaticky přizpůsobují distribuci dat — bez nutnosti manuálního přenastavování.
Praktický dopad pro rok 2027 odhaduji takto: inference náklady na token klesnou o dalších 60-80 % oproti dnešku, primárně díky kombinaci MoE architektury (EMO nebo podobné) a hardware-software codesignu (AWS Trainium 3, Google TPU v5). To je dobrá zpráva pro každého, kdo plánuje nasazení AI v energetickém sektoru — predikce spotřeby, optimalizace baterií, day trading elektřiny. Všechny tyto aplikace jsou compute-intensive a cena inferenci je pro jejich ekonomiku klíčová.
Pokud vás zajímá, jak se AI nasazení škáluje v kontextu sdílení energie a virtuálních elektráren, doporučuji také SmartEnergyShare.cz, kde se věnujeme VPP optimizérům a jejich výpočetním nárokům.
Platformy jako energetická platforma SES již dnes integrují AI modely pro flexibilitu a obchodování odchylek — a s klesajícími náklady na inference bude tato integrace v příštích dvou letech standardem, ne výjimkou.