Tak už sme slávni aj vo Fínsku: dva dni a jedna noc na LUMI

Tak už sme slávni aj vo Fínsku.

Môj prvý článok o LUMI zaujal priamo tím LUMI AI Factory. V nedeľu o Alpha Industries vydali vlastný text s titulkom Czechia's Alpha Industries validates LUMI's power and sustainability in their initial test. Z českého prvého pokusu sa tak počas niekoľkých dní stal príbeh na oficiálnom fínskom webe európskej AI infraštruktúry.

Mal som z toho úprimnú radosť. A tiež chuť zistiť, či druhé dejstvo bude stáť za to.

V pondelok ráno sa LUMI po bezpečnostnej odstávke znovu otvorilo. Počas nasledujúcich 38 hodín som spustil tri experimenty, otestoval desať vopred zapísaných hypotéz, skompiloval vlastný inferenčný engine pre AMD, rozbehol model s približne 753 miliardami parametrov na jedinom uzle a nechal niekoľko systémov cez noc riešiť vedecké otázky doktorandskej úrovne.

Niektoré hypotézy vyšli. Iné spadli tak presvedčivo, že práve ony sú najzaujímavejšou časťou výsledku.

LUMI v Kajaani. Pod výrazným modrým opláštením pracuje európska infraštruktúra, na ktorej experimenty bežali.

Celý experiment jednou vetou: Veľký model nie je automaticky najlepší, 4-bitová kompresia nepoškodzuje všetky modely rovnako a viac premýšľania môže kvalitu zdvihnúť o 15 bodov, alebo ju o 27 bodov zraziť.

Najskôr štyri pojmy pre normálnych ľudí

Fúzia modelov je porota. Niekoľko AI odpovie nezávisle a ďalší model ich odpovede overí a zloží z nich finálne riešenie.

Kvantizácia je kompresia. Namiesto ukladania každej hodnoty v 16 bitoch použijeme približne 4 bity. Model zaberie menej pamäte, ale môže stratiť časť schopností.

Reasoning čiže premýšľanie znamená, že si model pred finálnou odpoveďou vytvára dlhší vnútorný postup. Pri ťažkých úlohách to môže výrazne pomôcť, ale stojí to čas, energiu a tokeny.

Benchmark je štandardizovaná písomka so známymi správnymi odpoveďami. Vďaka tomu nemusí kvalitu posudzovať iná AI.

Prečo si hypotézy zapisujem vopred

Pred každým experimentom som zapísal očakávané výsledky aj pravidlá, podľa ktorých ich vyhodnotím. Je to jednoduchá poistka proti sebaklamu. Predikciu zapíšete pred spustením a po výsledku už nemôžete tvrdiť, že ste presne toto čakali.

V prvom a treťom experimente tak vzniklo desať hypotéz. Niektoré sa potvrdili, niektoré len čiastočne a tri dopadli opačne, ako som očakával. To nie je hanba. To je dôvod, prečo experiment vôbec robiť.

Experiment 1: fúzia modelov druhýkrát

V júni som na jednej RTX 5090 ukázal, že fúzia lokálnych modelov Qwen a GLM dosiahla 98 bodov zo 100 a prekonala jednotlivé konfigurácie. Na LUMI som rovnaký test zopakoval v plnej BF16 presnosti, s rovnakými promptami a rovnakou úlohou.

Novo som 60 bodov hodnotil deterministickým skriptom proti správnemu riešeniu. Zvyšných 40 bodov posudzoval frontier model mimo testovaného panelu. A pretože mi minule právom vytýkali, že Qwen hodnotil porotu, ktorej bol sám členom, pridal som nezávislých sudcov.

Skóre v jednej vopred definovanej otvorenej úlohe, preto nejde o všeobecný rebríček modelov. Fúzia zostala na špici, ale tentoraz sa o prvé miesto delila so samostatným Qwenom.

Fúzia získala 99/100. Rovnako dopadol aj najlepší samostatný Qwen. To je dôležitá nuansa: replikácia potvrdila, že fúzia výborné riešenie nezničí a dokáže odfiltrovať zlých kandidátov, nie že v každom behu nutne porazí najlepšieho člena panelu.

Robustnosť však nebola zadarmo. Jeden zdegenerovaný kandidát sudcu nezmiatol, jeho 15 000 tokenov šumu však nafúklo vstup sudcu na 31 000 tokenov a približne zdvojnásobilo cenu prefillu. Praktické odporúčanie je preto jednoduché: pred fúziou filtrovať alebo skrátiť kandidátov s failure flagmi TRUNCATED a REPETITION.

Mechanizmus ale vyšiel presne. Sudca neveril sebavedomým vetám, prepočítal si ich. Jeden kandidát napríklad napísal, že 20 + 5 = 25, čo sa vraj zhoduje s 29. Sudca túto „verifikáciu“ odhalil a riešenie odmietol. Aj modely dokážu blafovať.

Štyria rôzni sudcovia vybrali rovnaký víťazný základ. Pri úlohe s objektívnym riešením sa teda zaujatosť vlastného sudcu na verdikte neprejavila. Líšila sa ale kvalita syntézy: veľký Qwen2.5-72B víťaza takmer len skopíroval, zatiaľ čo menší sudcovia aktívne vytiahli užitočné časti aj zo slabších odpovedí.

Prekvapenie: inferenčný engine mení správanie modelu

GLM-4.7-Flash mal v júni cez llama.cpp 38 bodov. Na LUMI cez vLLM a v presnejšej BF16 reprezentácii spadol na 9. Pri nízkej teplote sa zacyklil a vypísal 15 000 tokenov číselného radu.

Rovnaké váhy teda nie sú celý model. Výsledok ovplyvňuje aj engine, jeho verzia, šablóna konverzácie, teplota a limity. Od tejto chvíle logujem všetky tieto údaje ku každému výstupu.

Experiment 2: 753 miliárd parametrov na jedinom uzle

Večer prišla odvážnejšia časť. GLM-5.2 má podľa modelovej karty 753 miliárd parametrov, z ktorých sa pri každom tokene aktivuje zhruba 40 miliárd. V plnej presnosti by váhy potrebovali približne 1,5 TB pamäte. Ja som použil 4,5-bitový variant s veľkosťou 435 GB.

Jeden uzol LUMI-G ponúka štyri fyzické akcelerátory AMD MI250X, teda osem samostatných výpočtových GCD, a dohromady 512 GB rýchlej HBM pamäte. Model sa teda zmestil, ale bez veľkej rezervy.

Vo vLLM nemal tento 4-bitový variant na danom hardvéri vhodne optimalizované kernely. Skompiloval som preto llama.cpp s HIP backendom priamo pre architektúru LUMI. Výsledok bol 17 tokenov za sekundu. To je interaktívne použiteľná rýchlosť pre model, ktorý sa do bežnej pracovnej stanice nezmestí ani vzdialene.

Prvý pokus napriek tomu zlyhal. Načítanie 435 GB súboru cez mmap z paralelného úložiska Lustre sa po 40 minútach stále nehýbalo. Prepínač --no-mmap skrátil rovnaké načítanie na približne päť minút. Veľká časť HPC skúsenosti vyzerá presne takto: hodiny hľadania, jeden prepínač, osemnásobný rozdiel.

Čo odpovedal obor na otázku po zmysle života?

Ako prvú zahrievaciu otázku som mu položil: „Aký je zmysel života?“ Odpovedal prekvapivo triezvo: "Zmysel nie je niečo, čo by existovalo niekde vonku ako objekt na nájdenie. Zmysel života sa skôr tvorí a vníma." Potom prešiel existencializmus, Franklov dôraz na dielo, lásku a postoj k utrpeniu i biologickú perspektívu prežitia a pokračovania života.

Nie je to vedecký výsledok, skôr malý portrét modelu. Ale je pôvabné, že prvá veta 753-miliardového systému na superpočítači nebola o výkone. Bola o tom, že zmysel si musíme vytvoriť sami.

Plný a komprimovaný GLM neboli rovnaký model

Potom som obom verziám zadal našu otvorenú testovaciu úlohu. Plný GLM-5.2 cez API dosiahol ručný odhad okolo 95/100. Urobil chybu, poctivým výpočtom si ju vyvrátil, našiel správne pravidlo a nakoniec sám pomenoval, kde uvažoval zle.

Kvantizovaná verzia skončila približne na 50/100. Kontrolné výpočty často len predstierala. Písala rovnice, ktoré nesedeli, a nevšimla si to.

Pritom 4-bitový Qwen v prvom experimente stratil proti BF16 len 2 až 4 body. Rovnaká kompresia teda môže byť pre jeden model takmer neškodná a pre iný zásadná. Bez merania to nemožno poznať podľa počtu parametrov ani podľa veľkosti súboru.

Experiment 3: noc s GPQA Diamond

Jedna otvorená úloha je anekdota. Preto som cez noc pridal GPQA Diamond, benchmark vedeckých otázok na úrovni doktorandského štúdia z biológie, chémie a fyziky. Odpovede sú A až D a správna možnosť je známa, takže nepotrebujeme AI sudcu.

Pred spustením som stratifikovane vyžreboval 60 z celkových 198 otázok, uložil ich identifikátory a nastavil seed 42. Kde to prevádzka dovolil, prebehli tri seedy. Obsah otázok nezverejňujem kvôli ochrane benchmarku.

Presnosť v strict režime. Úsečky ukazujú 95% Wilsonovej intervaly. Plné systémy a Qwen varianty majú 180 odpovedí, lokálne GLM Q4 60; blízke skóre sa preto nesmú čítať ako definitívne poradie.

Najlepší výsledok mal plný GLM-5.2 s vysokým reasoningom: 89,4 %. To je blízko vendor hodnote 91,2% z jeho oficiálnej modelovej karty. Malý Qwen3.6-27B bez premýšľania dosiahol 86,7 %. Rozdiel 2,7 percentuálneho bodu je pri tejto vzorke menší ako štatistická neistota.

To je dôležité. Model s 27 miliardami parametrov sa na tejto konkrétnej úlohe dostal veľmi blízko modelu so 753 miliardami celkových parametrov. Neznamená to, že je všeobecne rovnako schopný. Znamená to, že pre tento typ dotazu môže byť oveľa menší systém dostatočný.

Pri Qwene s reasoningom patrí vedľa strict skóre 82,8 % ešte dôležité číslo: 94,0 % z dokončených odpovedí. Rozdiel ukazuje, ako silno strict výsledok ovplyvnila doručiteľnosť: 31 zo 180 behov nedodalo finálnu voľbu v limite 30 000 tokenov.

Premýšľanie pomohlo plnej verzii a uškodilo komprimovanej

• Rovnaká rodina modelu, ale opačný efekt reasoningu. Pri Q4 vetve 35 zo 60 odpovedí narazilo na limit 8 000 tokenov, takže graf meria zároveň schopnosť aj praktickú doručiteľnosť v danom rozpočte.*

Pri plnom GLM zdvihlo premýšľanie skóre z 74,4 na 89,4 %. Pri 4-bitovom GLM naopak spadlo z 80 na 53 %.

Najpravdepodobnejšie vysvetlenie zodpovedá štúdii Quantization Meets Reasoning: kvantizačná chyba sa môže objaviť čoskoro v reťazci uvažovania a ďalšie kroky ju zosilňujú. Novšia práca Quantized Reasoning Models Think They Need to Think Longer, but They Do Not navyše opisuje rovnaký vzorec nadbytočného premýšľania: agresívna kvantizácia predlžovala reťazce úvah, zatiaľ čo presnosť klesala. V našom behu 35 zo 60 odpovedí pretieklo limit 8 000 tokenov. Nemôžem teda tvrdiť, že kompresia sama spôsobila celý prepad. Dáta ale jasne hovoria, že táto konkrétna Q4 konfigurácia nie je pre dlhý reasoning v praktickom rozpočte vhodná.

Tomáš Mikolov a ThinkingCap: menej premýšľať, lepšie doručiť

Do nočného testu som pridal aj nový ThinkingCap-Qwen3.6-27B od BottleCap AI, na ktorého výskume sa podieľa Tomáš Mikolov. Jeho cieľom nie je urobiť Qwen múdrejším. Má ho naučiť zastaviť sa skôr, obmedziť zbytočné slučky a dôjsť k rovnakej kvalite s menším počtom tokenov.

Toto je presne oblasť, v ktorej je Tomáš Mikolov dlhodobo silný: efektivita, nie iba honba za väčším modelom.

Rovnakých 60 otázok, tri seedy. Graf ukazuje strict presnosť, priemerný počet výstupných tokenov, medián latencie a odrezané odpovede vo všetkých štyroch režimoch.

Najdôležitejšie je, že pre túto konkrétnu úlohu mal najlepší strict výsledok obyčajný Qwen bez reasoningu: 86,7 %. ThinkingCap bez reasoningu dosiahol 82,2 %. Po zapnutí reasoningu sa ich poradie otočilo: ThinkingCap získal 84,4 %, zatiaľ čo Qwen 82,8 %.

Pri Qwene teda reasoning znížil strict skóre z 86,7 na 82,8 %. Výrazne k tomu prispel rast odrezaných odpovedí z 11 na 31 zo 180; reasoning vetva mala limit 30 000 tokenov. Pri ThinkingCape naopak reasoning skóre zvýšil z 82,2 na 84,4 %. Rovnaký prepínač mal pri dvoch príbuzných modeloch opačný výsledok.

V reasoning režime spotreboval ThinkingCap v priemere 7 312 tokenov oproti 15 097 pri pôvodnom Qwene. To je úspora 52 %. Medián latencie klesol z 1 189 na 403 sekúnd a počet odrezaných odpovedí z 31 na 9. Splnil tak svoj hlavný sľub: v obmedzenom rozpočte častejšie doručil hotovú odpoveď.

Ak porovnáme iba dokončené reasoning odpovede, pôvodný Qwen dosiahol 94 %, ThinkingCap 88,9 %. Qwen teda mal vyšší strop, ale v pevnom rozpočte ho častejšie nestihol doručiť.

Môj verdikt je teda presne opačný ako reklamný superlatív: ThinkingCap nie je v tomto pilote múdrejší Qwen. Je to ukáznenejšie Qwen. V produkcii môže byť cennejšie práve preto, že vie, kedy prestať. Pre úlohy, kde dovolíte takmer neobmedzený čas a hľadáte najvyšší strop, zostala pôvodná verzia silnejšia.

Rozpočet na premýšľanie je samostatná schopnosť

Trikrát som v priebehu noci zdvíhal limit odpovede, pretože som ho pôvodne nastavil odhadom. Qwen dokázal pri ťažkej otázke spotrebovať aj 30 000 tokenov a napriek tomu nedojsť k finálnej voľbe A až D.

To viedlo k trom metrikám:

1. Strict: Tvrdý limit. Nedokončená odpoveď je nula. Meria nasaditeľnosť v rozpočte.
2. Budget-forced: Model vie, koľko tokenov mu zostáva, a musí odpoveď uzavrieť. Meria hospodárenie s rozpočtom.
3. Unbounded: Model môže premýšľať veľmi dlho. Meria skôr hornú hranicu schopností ako praktický produkt.

Ako dopadol súboj metrík

Finálny záchranný pool obsahoval 40 unikátnych behov Qwenu, ktoré prekročili limit naprieč testovanými režimami a v strict metrike preto získali nulu. Pri budget-forced opakovaní dostal model 5 000 tokenov a výslovný príkaz odpoveď uzavrieť. Správne zachránil 11 zo 40 pokusov (27,5 %). Variant unbounded mal strop 100 000 tokenov a približne 85-minútové časové okno na uzle. Dokončil len 13 zo 40 pokusov a správne odpovedal v 8 prípadoch (20 %).

Vynútený záver teda v tomto záchrannom poole vyriešil viac pretečení než takmer neobmedzené premýšľanie, a to za zlomok výpočtovej ceny. Približne dve tretiny najťažších pokusov nedokončili použiteľnú úvahu ani s mimoriadne vysokým limitom. „Nestihol“ tu väčšinou neznamenalo „potreboval trochu viac miesta“, ale „nedokázal včas rozhodnúť“.

Pool zahŕňal pretečenia z oboch testovaných režimov Qwenu. Keď sa záchrana započíta iba do celej reasoning vetvy, jej skóre sa posunie zo strict 82,8 % na capability 86,1 % s budget forcingom a 87,2 % s unbounded behom. Druhý variant pridal len 1,1 percentuálneho bodu za neporovnateľne vyšší čas a výpočtové náklady. Pre prax preto vychádza lepšie pevný rozpočet a vynútený záver než ďalšie zvyšovanie limitu. Qwen sa tak dostáva približne na úroveň svojej verzie bez reasoningu (86,7 %), len podstatne drahšie.

Práca Scaling LLM Test-Time Compute Optimally ukazuje, že menší model môže s dobre rozdeleným výpočtovým časom prekonať oveľa väčší. Náš výsledok pridáva praktický dovetok: tento čas sa musí rozdeliť múdro. Samotné navýšenie limitu nie je stratégia.

Čo ukázalo desať hypotéz

Ani štyri sloty neurobili štvornásobný výkon

Agregovaná rýchlosť zostala približne 16 až 17 tokenov za sekundu. Pri tomto veľkom MoE modeli narazil jediný stream na priepustnosť pamäte a ďalšie sloty nepriniesli očakávané škálovanie.

Čakal som, že viac súbežných slotov zdvihne priepustnosť aspoň 1,5-krát. Nameral som 16, 17 a 17 tokenov za sekundu pre jeden, dva a štyri sloty. Prakticky rovná čiara.

To zodpovedá známemu problému MoE inferencie: batching môže aktivovať viac expertov a zosilniť tlak na pamäťovú priepustnosť. Popisuje to napríklad práca Lynx. Pre ďalšie benchmarky preto nebudem pridávať sloty na jednom uzle. Rozdelím otázky medzi viac replík na viac uzloch.

Čo sa nepodarilo

Približne tretina z asi 35 jobov počas dvoch dní zlyhala. Skoro vždy mojou chybou, nie chybou LUMI.

• Health check bez parametra -f považoval odpoveď 503 Loading model za zdravý server. Osemdesiat otázok tak odišlo do prázdna.
• HTTP timeout bol kratší ako najdlhšia generácia. Klient po 30 minútach zahodil odpoveď, na ktorej model pracoval 50 minút.
• Limity odpovedí som trikrát podhodnotil. To bola najdrahšia systematická chyba.
• Príkaz pkill si dvakrát zabil sám seba.
• Podpísané adresy Hugging Face vypršali skôr, ako sa stiahol 46GB súbor, a klient zostal visieť bez chyby.
• Multimodálna finetune nemal kompletné procesorové súbory. Správnym riešením bolo doplniť ich zo základného modelu.
• Na zdieľanom uzle mohol cudzí proces upratať zdieľanú pamäť pod bežiacim vLLM.

Všetky chyby som spísal vo formáte príznak, príčina, oprava a prevencia. To môže byť nakoniec jeden z najcennejších výstupov. Ďalší tím už nemusí platiť rovnaké školné.

Koľko to celé stálo

Vrátane neúspešných behov, opráv, replík, nočných úloh a záverečných unbounded behov som spotreboval približne 55 GPU-hodín z pridelených 5 000, teda asi 1,1 % alokácie. Externé API stálo zhruba 350 Kč.

To je možno najmenej intuitívny výsledok. Seriózny pilotný výskum na európskom superpočítači nemusí byť drahý, keď sú hypotézy zapísané vopred, behy sú obnoviteľné a nefunkčné joby sa rýchlo zastavia.

Prístup nie je len pre veľké laboratóriá

Na LUMI som sa dostal vďaka Jakubovi Siwkovi a českému tímu IT4Innovations, ktorý sprostredkúva vstup do LUMI AI Factory. Začal som najnižšou playground alokáciou 5 000 GPU-hodín. Dobre dokončený menší program je podľa Jakuba tiež cestou k žiadosti o úroveň 50 000+ GPU-hodín. Nie je to automatická vstupenka, ale pilot vytvorí presne to, čo väčšia žiadosť potrebuje: funkčný workflow, prvé dáta a dôkaz, že pridelený výkon dokážete využiť.

Ani čakanie tentoraz nebolo dramatické. Menšie vývojové joby štartovali v priebehu sekúnd až minút. Pondelkové zdržanie približne dve a pol hodiny spôsobila bezpečnostná údržba celej infraštruktúry, nie bežná fronta.

Pre firmu alebo vývojára z toho plynie povzbudivá správa: cesta k superpočítaču sa nemusí začínať nákupom hardvéru ani grantom pre obrovské laboratórium. Začína sa dobrou otázkou, niekoľkými vopred zapísanými hypotézami a kontaktom na národnú AI Factory.

Čo z toho bude v praxi

Jakub Siwek z IT4Innovations sa ma počas experimentu spýtal, kam to celé dlhodobo vedie. Odpoveď je jednoduchá: k rozhodovacej mape na nasadzovanie AI za rozumné peniaze.

Kedy stačí malý otvorený model? Kedy pomôže fúzia niekoľkých malých? Kedy je výhodnejšie priplatiť za veľký model? Kedy zapnúť reasoning? A ako spoznať, že kompresia poškodila práve schopnosť, ktorú potrebujeme?

Na týchto dátach môže vzniknúť šikovný router pre HyperProstor. Každý dotaz pošle najlacnejšiemu systému, ktorý naň pravdepodobne stačí. Len najťažšie prípady eskaluje k drahému špecialistovi. RouteLLM ukazuje, že podobné smerovanie môže výrazne znížiť cenu pri zachovaní väčšiny kvality. Ja chcem túto myšlienku overiť na vlastných dátach, viacerých modeloch a skutočných firemných úlohách.

Je tu aj európsky rozmer. Firmy sa často boja AMD, pretože svoje modely vyvíjali v ekosystéme NVIDIA. Na trénovanie je ten rozdiel stále významný. Na prevádzku hotových otvorených modelov je ale vstupná bariéra menšia, než sa traduje. Počas dvoch dní som na európskom AMD hardvéri prevádzkoval Qwen, GLM, ThinkingCap aj 435GB kvantizovaný model. Nemusel som ich znova učiť. Potreboval som správne kontajnery, enginy a niekoľko draho nájdených prepínačov.

Prvý článok ukázal, že sa na LUMI dokážem pripojiť a rozbehnúť dávkové spracovanie. Ten druhý ukazuje niečo zaujímavejšie: že na európskej infraštruktúre možno robiť poctivý, opakovateľný výskum otvorených modelov a získať výsledky, ktoré nie sú len prepisom vendor tabuliek.

A až teraz to začína.

Metodická poznámka

Ide o pilot, nie konečný rebríček. Otvorený test v experimente 1 obsahoval jednu úlohu. GPQA časť pracovala s 60 z 198 otázok a nie všetky konfigurácie mali rovnaký počet opakovaní. Výsledky preto používam na rozhodnutie o ďalšej fáze, nie na tvrdenie, že jeden model všeobecne poráža druhý.

Ďalší krok je rozšíriť počet úloh, pridať viac seedov, reportovať intervaly spoľahlivosti a porovnať fúziu proti rovnako drahým baseline metódam. Až potom príde na rad naučený router.

Zdroje a dáta

• LUMI AI Factory: Czechia's Alpha Industries validates LUMI's power and sustainability
• Dokumentácia uzla 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 som orchestroval s Fable 5 pod vlastným dohľadom. Hypotézy, rozhodovacie pravidlá, surové JSONL logy, verzie enginov a per-otázkové výsledky sú uložené v projekte. Obsah samotných GPQA otázok kvôli integrite benchmarku nezverejňujem.