Tak už jsme slavní i ve Finsku: dva dny a jedna noc na LUMI

Tak už jsme slavní i ve Finsku.

Můj první článek o LUMI zaujal přímo tým LUMI AI Factory. V neděli o Alpha Industries vydali vlastní text s titulkem Czechia's Alpha Industries validates LUMI's power and sustainability in their initial test. Z českého prvního pokusu se tak během několika dnů stal příběh na oficiálním finském webu evropské AI infrastruktury.

Měl jsem z toho upřímnou radost. A taky chuť zjistit, jestli druhé dějství bude stát za to.

V pondělí ráno se LUMI po bezpečnostní odstávce znovu otevřelo. Během následujících 38 hodin jsem spustil tři experimenty, otestoval deset předem zapsaných hypotéz, zkompiloval vlastní inferenční engine pro AMD, rozběhl model s přibližně 753 miliardami parametrů na jediném uzlu a nechal několik systémů přes noc řešit vědecké otázky doktorské úrovně.

Některé hypotézy vyšly. Jiné spadly tak přesvědčivě, že právě ony jsou nejzajímavější částí výsledku.

LUMI v Kajaani. Pod výrazným modrým opláštěním pracuje evropská infrastruktura, na které experimenty běžely.

Celý experiment jednou větou: Velký model není automaticky nejlepší, 4bitová komprese nepoškozuje všechny modely stejně a více přemýšlení může kvalitu zvednout o 15 bodů, nebo ji o 27 bodů srazit.

Nejdřív čtyři pojmy pro normální lidi

Fúze modelů je porota. Několik AI odpoví nezávisle a další model jejich odpovědi ověří a složí z nich finální řešení.

Kvantizace je komprese. Místo ukládání každé hodnoty v 16 bitech použijeme přibližně 4 bity. Model zabere méně paměti, ale může ztratit část schopností.

Reasoning neboli přemýšlení znamená, že si model před finální odpovědí vytváří delší vnitřní postup. U těžkých úloh to může výrazně pomoci, ale stojí to čas, energii a tokeny.

Benchmark je standardizovaná písemka se známými správnými odpověďmi. Díky tomu nemusí kvalitu posuzovat jiná AI.

Proč si hypotézy zapisuji předem

Před každým experimentem jsem zapsal očekávané výsledky i pravidla, podle kterých je vyhodnotím. Je to jednoduchá pojistka proti sebeklamu. Predikci zapíšete před spuštěním a po výsledku už nemůžete tvrdit, že jste přesně tohle čekali.

V prvním a třetím experimentu tak vzniklo deset hypotéz. Některé se potvrdily, některé jen částečně a tři dopadly opačně, než jsem očekával. To není ostuda. To je důvod, proč experiment vůbec dělat.

Experiment 1: fúze modelů podruhé

V červnu jsem na jedné RTX 5090 ukázal, že fúze lokálních modelů Qwen a GLM dosáhla 98 bodů ze 100 a překonala jednotlivé konfigurace. Na LUMI jsem stejný test zopakoval v plné BF16 přesnosti, se stejnými prompty a stejnou úlohou.

Nově jsem 60 bodů hodnotil deterministickým skriptem proti správnému řešení. Zbylých 40 bodů posuzoval frontier model mimo testovaný panel. A protože mi minule právem vytýkali, že Qwen hodnotil porotu, jejímž byl sám členem, přidal jsem nezávislé soudce.

Skóre v jedné předem definované otevřené úloze, proto nejde o obecný žebříček modelů. Fúze zůstala na špici, ale tentokrát se o první místo dělila se samostatným Qwenem.

Fúze získala 99/100. Stejně dopadl i nejlepší samostatný Qwen. To je důležitá nuance: replikace potvrdila, že fúze výborné řešení nezničí a dokáže odfiltrovat špatné kandidáty, nikoli že v každém běhu nutně porazí nejlepšího člena panelu.

Robustnost ale nebyla zadarmo. Jeden zdegenerovaný kandidát soudce nezmátl, jeho 15 000 tokenů šumu však nafouklo vstup soudce na 31 000 tokenů a přibližně zdvojnásobilo cenu prefillu. Praktické doporučení je proto jednoduché: před fúzí filtrovat nebo zkrátit kandidáty s failure flagy TRUNCATED a REPETITION.

Mechanismus ale vyšel přesně. Soudce nevěřil sebevědomým větám, přepočítal si je. Jeden kandidát například napsal, že 20 + 5 = 25, což se prý shoduje s 29. Soudce tuto „verifikaci“ odhalil a řešení odmítl. Zrádci jsou zjevně i mezi modely.

Čtyři různí soudci vybrali stejný vítězný základ. U úlohy s objektivním řešením se tedy zaujatost vlastního soudce na verdiktu neprojevila. Lišila se ale kvalita syntézy: velký Qwen2.5-72B vítěze téměř jen zkopíroval, zatímco menší soudci aktivně vytáhli užitečné části i ze slabších odpovědí.

Překvapení: inferenční engine mění chování modelu

GLM-4.7-Flash měl v červnu přes llama.cpp 38 bodů. Na LUMI přes vLLM a v přesnější BF16 reprezentaci spadl na 9. Při nízké teplotě se zacyklil a vypsal 15 000 tokenů číselné řady.

Stejné váhy tedy nejsou celý model. Výsledek ovlivňuje i engine, jeho verze, šablona konverzace, teplota a limity. Od této chvíle loguji všechny tyto údaje ke každému výstupu.

Experiment 2: 753 miliard parametrů na jediném uzlu

Večer přišla odvážnější část. GLM-5.2 má podle modelové karty 753 miliard parametrů, z nichž se u každého tokenu aktivuje zhruba 40 miliard. V plné přesnosti by váhy potřebovaly přibližně 1,5 TB paměti. Já jsem použil 4,5bitovou variantu o velikosti 435 GB.

Jeden uzel LUMI-G nabízí čtyři fyzické akcelerátory AMD MI250X, tedy osm samostatných výpočetních GCD, a dohromady 512 GB rychlé HBM paměti. Model se tedy vešel, ale bez velké rezervy.

Ve vLLM neměla tato 4bitová varianta na daném hardwaru vhodně optimalizované kernely. Zkompiloval jsem proto llama.cpp s HIP backendem přímo pro architekturu LUMI. Výsledek byl 17 tokenů za sekundu. To je interaktivně použitelná rychlost pro model, který se do běžné pracovní stanice nevejde ani vzdáleně.

První pokus přesto selhal. Načítání 435GB souboru přes mmap z paralelního úložiště Lustre se po 40 minutách stále nehýbalo. Přepínač --no-mmap zkrátil stejné načtení na přibližně pět minut. Velká část HPC zkušenosti vypadá přesně takto: hodiny hledání, jeden přepínač, osminásobný rozdíl.

Co odpověděl obr na otázku po smyslu života?

Jako první zahřívací otázku jsem mu položil: „Jaký je smysl života?“ Odpověděl překvapivě střízlivě: „Smysl není něco, co by existovalo někde venku jako objekt k nalezení. Smysl života se spíše tvoří a vnímá.“ Potom prošel existencialismus, Franklův důraz na dílo, lásku a postoj k utrpení i biologickou perspektivu přežití a pokračování života.

Není to vědecký výsledek, spíš malý portrét modelu. Ale je půvabné, že první věta 753miliardového systému na superpočítači nebyla o výkonu. Byla o tom, že smysl si musíme vytvořit sami.

Plný a komprimovaný GLM nebyly stejný model

Pak jsem oběma verzím zadal naši otevřenou testovací úlohu. Plný GLM-5.2 přes API dosáhl ručního odhadu kolem 95/100. Udělal chybu, poctivým výpočtem si ji vyvrátil, našel správné pravidlo a nakonec sám pojmenoval, kde uvažoval špatně.

Kvantizovaná verze skončila přibližně na 50/100. Kontrolní výpočty často jen předstírala. Psala rovnice, které neseděly, a nevšimla si toho.

Přitom 4bitový Qwen v prvním experimentu ztratil proti BF16 jen 2 až 4 body. Stejná komprese tedy může být pro jeden model téměř neškodná a pro jiný zásadní. Bez měření to nelze poznat podle počtu parametrů ani podle velikosti souboru.

Experiment 3: noc s GPQA Diamond

Jedna otevřená úloha je anekdota. Proto jsem přes noc přidal GPQA Diamond, benchmark vědeckých otázek na úrovni doktorského studia z biologie, chemie a fyziky. Odpovědi jsou A až D a správná možnost je známá, takže nepotřebujeme AI soudce.

Před spuštěním jsem stratifikovaně vylosoval 60 z celkových 198 otázek, uložil jejich identifikátory a nastavil seed 42. Kde to provoz dovolil, proběhly tři seedy. Obsah otázek nezveřejňuji kvůli ochraně benchmarku.

Přesnost ve strict režimu. Úsečky ukazují 95% Wilsonovy intervaly. Plné systémy a Qwen varianty mají 180 odpovědí, lokální GLM Q4 60; blízká skóre se proto nesmějí číst jako definitivní pořadí.

Nejlepší výsledek měl plný GLM-5.2 s vysokým reasoningem: 89,4 %. To je blízko vendor hodnotě 91,2 % z jeho oficiální modelové karty. Malý Qwen3.6-27B bez přemýšlení dosáhl 86,7 %. Rozdíl 2,7 procentního bodu je při tomto vzorku menší než statistická nejistota.

To je důležité. Model se 27 miliardami parametrů se na této konkrétní úloze dostal velmi blízko modelu se 753 miliardami celkových parametrů. Neznamená to, že je obecně stejně schopný. Znamená to, že pro tento typ dotazu může být mnohem menší systém dostatečný.

U Qwenu s reasoningem stojí vedle strict skóre 82,8 % ještě důležité číslo: 94,0 % z dokončených odpovědí. Rozdíl ukazuje, jak silně strict výsledek ovlivnila doručitelnost: 31 ze 180 běhů nedodalo finální volbu do limitu 30 000 tokenů.

Přemýšlení pomohlo plné verzi a uškodilo komprimované

Stejná rodina modelu, ale opačný efekt reasoningu. U Q4 větve 35 z 60 odpovědí narazilo na limit 8 000 tokenů, takže graf měří zároveň schopnost i praktickou doručitelnost v daném rozpočtu.

U plného GLM zvedlo přemýšlení skóre z 74,4 na 89,4 %. U 4bitového GLM naopak spadlo z 80 na 53 %.

Nejpravděpodobnější vysvětlení odpovídá studii Quantization Meets Reasoning: kvantizační chyba se může objevit brzy v řetězci uvažování a další kroky ji zesilují. Novější práce Quantized Reasoning Models Think They Need to Think Longer, but They Do Not navíc popisuje stejný vzorec přemýšlení navíc: agresivní kvantizace prodlužovala řetězce úvah, zatímco přesnost klesala. V našem běhu 35 z 60 odpovědí přeteklo limit 8 000 tokenů. Nemohu tedy tvrdit, že komprese sama způsobila celý propad. Data ale jasně říkají, že tato konkrétní Q4 konfigurace není pro dlouhý reasoning v praktickém rozpočtu vhodná.

Tomáš Mikolov a ThinkingCap: méně přemýšlet, lépe doručit

Do nočního testu jsem přidal i nový ThinkingCap-Qwen3.6-27B od BottleCap AI, na jehož výzkumu se podílí Tomáš Mikolov. Jeho cíl není udělat Qwen chytřejší. Má ho naučit zastavit se dřív, omezit zbytečné smyčky a dojít ke stejné kvalitě s menším počtem tokenů.

Tohle je přesně oblast, ve které je Tomáš Mikolov dlouhodobě silný: efektivita, nikoli jen honba za větším modelem.

Stejných 60 otázek, tři seedy. Graf ukazuje strict přesnost, průměrný počet výstupních tokenů, medián latence a uříznuté odpovědi ve všech čtyřech režimech.

Nejdůležitější pointa je, že pro tuto konkrétní úlohu měl nejlepší strict výsledek obyčejný Qwen bez reasoningu: 86,7 %. ThinkingCap bez reasoningu dosáhl 82,2 %. Po zapnutí reasoningu se jejich pořadí otočilo: ThinkingCap získal 84,4 %, zatímco Qwen 82,8 %.

U Qwenu tedy reasoning strict skóre snížil z 86,7 na 82,8 %. Výrazně se na tom podílel růst uříznutých odpovědí z 11 na 31 ze 180; u reasoning větve šlo o limit 30 000 tokenů. U ThinkingCapu naopak reasoning skóre zvedl z 82,2 na 84,4 %. Stejný přepínač měl u dvou příbuzných modelů opačný výsledek.

V reasoning režimu spotřeboval ThinkingCap v průměru 7 312 tokenů proti 15 097 u původního Qwenu. To je úspora 52 %. Medián latence klesl z 1 189 na 403 sekund a počet uříznutých odpovědí z 31 na 9. Splnil tak svůj hlavní slib: v omezeném rozpočtu častěji doručil hotovou odpověď.

Pokud srovnáme jen dokončené reasoning odpovědi, původní Qwen dosáhl 94 %, ThinkingCap 88,9 %. Qwen tedy měl vyšší strop, ale v pevném rozpočtu ho častěji nestihl doručit.

Můj verdikt je tedy přesně opačný než reklamní superlativ: ThinkingCap není v tomto pilotu chytřejší Qwen. Je to ukázněnější Qwen. V produkci může být cennější právě proto, že ví, kdy přestat. Pro úlohy, kde dovolíte téměř neomezený čas a hledáte nejvyšší strop, zůstala původní verze silnější.

Rozpočet na přemýšlení je samostatná schopnost

Třikrát jsem v průběhu noci zvedal limit odpovědi, protože jsem jej původně nastavil odhadem. Qwen dokázal u těžké otázky spotřebovat i 30 000 tokenů a přesto nedojít k finální volbě A až D.

To vedlo ke třem metrikám:

1. Strict: Tvrdý limit. Nedokončená odpověď je nula. Měří nasaditelnost v rozpočtu.
2. Budget-forced: Model ví, kolik tokenů mu zbývá, a musí odpověď uzavřít. Měří hospodaření s rozpočtem.
3. Unbounded: Model může přemýšlet velmi dlouho. Měří spíš horní hranici schopností než praktický produkt.

Jak souboj metrik dopadl

Finální záchranný pool obsahoval 40 unikátních Qwen běhů, které přetekly limit napříč testovanými režimy a ve strict metrice proto získaly nulu. Při budget-forced opakování dostal model 5 000 tokenů a výslovný příkaz odpověď uzavřít. Správně zachránil 11 ze 40 pokusů (27,5 %). Varianta unbounded měla strop 100 000 tokenů a přibližně 85minutové časové okno na uzlu. Dokončila jen 13 ze 40 pokusů a správně jich měla 8 (20 %).

Nucený závěr tedy v tomto záchranném poolu vyřešil víc přetečení než téměř neomezené přemýšlení, a to za zlomek výpočetní ceny. Přibližně dvě třetiny nejtěžších pokusů nedokončily použitelnou úvahu ani s mimořádně vysokým limitem. „Nestihl“ zde většinou neznamenalo „potřeboval trochu víc místa“, ale „nedokázal včas rozhodnout“.

Pool zahrnoval přetečení z obou testovaných Qwen režimů. Když se záchrana započítá pouze do celé reasoning větve, její skóre se posune ze strict 82,8 % na capability 86,1 % s budget forcingem a 87,2 % s unbounded během. Druhá varianta přidala jen 1,1 procentního bodu za nesrovnatelně vyšší čas a výpočetní náklady. Pro praxi proto vychází lépe pevný rozpočet a vynucený závěr než další navyšování limitu. Qwen se tak dostává přibližně na úroveň své varianty bez reasoningu (86,7 %), jen podstatně dráž.

Práce Scaling LLM Test-Time Compute Optimally ukazuje, že menší model může s dobře rozděleným výpočetním časem překonat mnohem větší. Náš výsledek přidává praktický dovětek: ten čas se musí rozdělit chytře. Samotné navýšení limitu není strategie.

Co ukázalo deset hypotéz

Ani čtyři sloty neudělaly čtyřnásobný výkon

Agregovaná rychlost zůstala přibližně 16 až 17 tokenů za sekundu. U tohoto velkého MoE modelu narazil jediný stream na propustnost paměti a další sloty nepřinesly očekávané škálování.

Čekal jsem, že více souběžných slotů zvedne propustnost alespoň 1,5krát. Naměřil jsem 16, 17 a 17 tokenů za sekundu pro jeden, dva a čtyři sloty. Prakticky rovná čára.

To odpovídá známému problému MoE inference: batching může aktivovat více expertů a zesílit tlak na paměťovou propustnost. Popisuje to například práce Lynx. Pro další benchmarky proto nebudu přidávat sloty na jednom uzlu. Rozdělím otázky mezi více replik na více uzlech.

Co se nepovedlo

Přibližně třetina z asi 35 jobů během dvou dnů selhala. Skoro vždy mojí chybou, nikoli chybou LUMI.

• Health check bez parametru -f považoval odpověď 503 Loading model za zdravý server. Osmdesát dotazů tak odešlo do prázdna.
• HTTP timeout byl kratší než nejdelší generace. Klient po 30 minutách zahodil odpověď, na které model pracoval 50 minut.
• Limity odpovědí jsem třikrát podhodnotil. To byla nejdražší systematická chyba.
• Příkaz pkill si dvakrát zabil sám sebe.
• Podepsané adresy Hugging Face vypršely dřív, než se stáhl 46GB soubor, a klient zůstal viset bez chyby.
• Multimodální finetune neměl kompletní procesorové soubory. Správným řešením bylo doplnit je ze základního modelu.
• Na sdíleném uzlu mohl cizí proces uklidit sdílenou paměť pod běžícím vLLM.

Všechny chyby jsem sepsal ve formátu příznak, příčina, oprava a prevence. To může být nakonec jeden z nejcennějších výstupů. Další tým už nemusí platit stejné školné.

Kolik to celé stálo

Včetně neúspěšných běhů, oprav, replik, nočních dobírek a závěrečných unbounded běhů jsem spotřeboval přibližně 55 GPU-hodin z přidělených 5 000, tedy asi 1,1 % alokace. Externí API stálo zhruba 350 Kč.

To je možná nejméně intuitivní výsledek. Seriózní pilotní výzkum na evropském superpočítači nemusí být drahý, když jsou hypotézy zapsané předem, běhy jsou obnovitelné a nefunkční joby se rychle zastaví.

Přístup není jen pro velké laboratoře

Na LUMI jsem se dostal díky Jakubu Siwkovi a českému týmu IT4Innovations, který zprostředkovává vstup do LUMI AI Factory. Začal jsem nejnižší playground alokací 5 000 GPU-hodin. Dobře dokončený menší program je podle Jakuba také cestou k žádosti o úroveň 50 000+ GPU-hodin. Není to automatická vstupenka, ale pilot vytvoří přesně to, co větší žádost potřebuje: funkční workflow, první data a důkaz, že přidělený výkon umíte využít.

Ani čekání tentokrát nebylo dramatické. Menší vývojové joby startovaly v řádu sekund až minut. Pondělní zdržení přibližně dvě a půl hodiny způsobila bezpečnostní údržba celé infrastruktury, nikoli běžná fronta.

Pro firmu nebo vývojáře z toho plyne docela povzbudivá zpráva: cesta k superpočítači nemusí začínat nákupem hardwaru ani grantem pro obří laboratoř. Začíná dobrou otázkou, několika předem zapsanými hypotézami a kontaktem na národní AI Factory.

Co z toho bude v praxi

Jakub Siwek z IT4Innovations se mě během experimentu zeptal, kam to celé dlouhodobě vede. Odpověď je jednoduchá: k rozhodovací mapě pro nasazování AI za rozumné peníze.

Kdy stačí malý otevřený model? Kdy pomůže fúze několika malých? Kdy je výhodnější připlatit za velký model? Kdy zapnout reasoning? A jak poznat, že komprese poškodila právě schopnost, kterou potřebujeme?

Na těchto datech může vzniknout chytrý router pro HyperProstor. Každý dotaz pošle nejlevnějšímu systému, který na něj pravděpodobně stačí. Jen nejtěžší případy eskaluje k drahému specialistovi. RouteLLM ukazuje, že podobné směrování může výrazně snížit cenu při zachování většiny kvality. Já chci tuto myšlenku ověřit na vlastních datech, více modelech a skutečných firemních úlohách.

Je tu i evropský rozměr. Firmy se často bojí AMD, protože své modely vyvíjely v ekosystému NVIDIA. Pro trénování je ten rozdíl stále významný. Pro provoz hotových otevřených modelů je ale vstupní bariéra menší, než se traduje. Během dvou dnů jsem na evropském AMD hardwaru provozoval Qwen, GLM, ThinkingCap i 435GB kvantizovaný model. Nemusel jsem je znovu učit. Potřeboval jsem správné kontejnery, enginy a několik draze nalezených přepínačů.

První článek ukázal, že se na LUMI dokážu připojit a rozběhnout dávkové zpracování. Ten druhý ukazuje něco zajímavějšího: že na evropské infrastruktuře lze dělat poctivý, opakovatelný výzkum otevřených modelů a získat výsledky, které nejsou jen přepisem vendor tabulek.

A teprve teď to začíná.

Metodická poznámka

Jde o pilot, nikoli konečný žebříček. Otevřený test v experimentu 1 obsahoval jednu úlohu. GPQA část pracovala s 60 z 198 otázek a ne všechny konfigurace měly stejný počet opakování. Výsledky proto používám k rozhodnutí o další fázi, nikoli k tvrzení, že jeden model obecně poráží druhý.

Další krok je rozšířit počet úloh, přidat více seedů, reportovat intervaly spolehlivosti a porovnat fúzi proti stejně drahým baseline metodám. Teprve potom přijde na řadu naučený router.

Zdroje a data

• LUMI AI Factory: Czechia's Alpha Industries validates LUMI's power and sustainability
• Dokumentace uzlu LUMI-G
• GLM-5.2: modelová karta a vendor benchmarky
• GPQA: A Graduate-Level Google-Proof Q&A Benchmark
• Li et al. (2025): Quantization Meets Reasoning
• Lotfi et al. (2026): Quantized Reasoning Models Think They Need to Think Longer, but They Do Not
• Snell et al. (2024): Scaling LLM Test-Time Compute Optimally
• Gupta et al. (2026): Lynx: Efficient MoE Inference
• BottleCap AI: ThinkingCap-Qwen3.6-27B a modelová karta
• LMSYS: RouteLLM

Experimenty jsem orchestroval s Fable 5 pod vlastním dohledem. Hypotézy, rozhodovací pravidla, surové JSONL logy, verze enginů a per-otázkové výsledky jsou uložené v projektu. Obsah samotných GPQA otázek kvůli integritě benchmarku nezveřejňuji.