Teraz jesteśmy znani także w Finlandii: dwa dni i jedna noc na LUMI

Teraz jesteśmy znani także w Finlandii.

Mój pierwszy artykuł o LUMI zwrócił uwagę zespołu LUMI AI Factory. W niedzielę opublikował on własny tekst o Alpha Industries: Czechia's Alpha Industries validates LUMI's power and sustainability in their initial test. W ciągu kilku dni mój pierwszy czeski eksperyment stał się historią na oficjalnej fińskiej stronie europejskiej infrastruktury AI.

Naprawdę się z tego ucieszyłem. Jednocześnie chciałem sprawdzić, czy drugi akt dorówna pierwszemu.

W poniedziałek rano LUMI zostało ponownie otwarte po wyłączeniu zabezpieczeń. W ciągu następnych 38 godzin przeprowadziłem trzy eksperymenty, przetestowałem dziesięć wcześniej napisanych hipotez, skompilowałem niestandardowy silnik wnioskowania dla AMD, uruchomiłem model zawierający około 753 miliardów parametrów w jednym węźle i przez noc uruchomiłem kilka systemów, aby rozwiązać problemy naukowe na poziomie doktoranckim.

Część hipotez się potwierdziła. Inne upadły tak przekonująco, że właśnie one stały się najciekawszą częścią wyniku.

LUMI w Kajaani. Za charakterystyczną niebieską obudową pracuje europejska infrastruktura, na której przeprowadziłem te eksperymenty.

Cały eksperyment w jednym zdaniu: Duży model nie jest automatycznie najlepszy, 4-bitowa kompresja nie niszczy wszystkich modeli jednakowo, a więcej przemyślenia może podnieść jakość o 15 punktów lub obniżyć ją o 27 punktów.

Najpierw cztery pojęcia w prostych słowach

Fuzja modeli działa jak jury AI. Kilka modeli odpowiada niezależnie, a kolejny sprawdza ich odpowiedzi i łączy je w ostateczne rozwiązanie.

Kwantyzacja to kompresja. Zamiast przechowywać każdą wartość w 16 bitach, używamy około 4 bitów. Model zajmuje mniej pamięci, ale może stracić część możliwości.

Reasoning, czyli rozumowanie, oznacza, że model przed ostateczną odpowiedzią przechodzi przez dłuższy wewnętrzny tok rozumowania. Przy trudnych zadaniach może to bardzo pomóc, ale kosztuje czas, energię i tokeny.

Benchmark to ustandaryzowany test ze znanymi poprawnymi odpowiedziami. Dzięki temu jakości nie musi oceniać inna AI.

Po co spisuję hipotezy z wyprzedzeniem?

Przed każdym eksperymentem spisałem oczekiwane wyniki i zasady, według których będę je oceniał. To prosta polisa ubezpieczeniowa na wypadek samooszukiwania się. Zapisujesz prognozę przed startem, a po wyniku nie możesz już twierdzić, że dokładnie tego się spodziewałeś.

W pierwszym i trzecim eksperymencie postawiono dziesięć hipotez. Część się potwierdziła, część tylko częściowo, a trzy okazały się odwrotne do moich oczekiwań. To nie wstyd. To jest powód, aby w ogóle przeprowadzić eksperyment.

Eksperyment 1: fuzja modelu po raz drugi

W czerwcu pokazałem na pojedynczym RTX 5090, że fuzja lokalnych modeli Qwen i GLM uzyskała 98 punktów na 100 i przewyższyła indywidualne konfiguracje. Na LUMI powtórzyłem ten sam test z pełną precyzją BF16, tymi samymi promptami i tym samym zadaniem.

Niedawno oceniłem 60 punktów za pomocą deterministycznego skryptu względem prawidłowego rozwiązania. Pozostałe 40 punktów zostało ocenionych za pomocą modelu granicznego poza badanym panelem. A ponieważ pewnego dnia słusznie mnie skrytykowano, że Qwen ocenia jury, którego sam był członkiem, dodałem niezależnych sędziów.

Wynik w jednym wstępnie zdefiniowanym zadaniu otwartym, dlatego nie jest to ogólny ranking modelu. Fusion pozostał na szczycie, ale tym razem zremisował na pierwszym miejscu z samodzielnym Qwen.

Fuzja uzyskała 99/100. Najlepszy samodzielny Qwen osiągnął ten sam wynik. To ważny niuans: replikacja potwierdziła, że fuzja zachowuje bardzo dobre rozwiązanie i potrafi odfiltrować słabych kandydatów, a nie że w każdym przebiegu musi pokonać najlepszego członka panelu.

Ta odporność nie była jednak darmowa. Jeden zdegenerowany kandydat nie zmylił sędziego, ale jego 15 000 tokenów szumu powiększyło wejście sędziego do 31 000 tokenów i mniej więcej podwoiło koszt prefillu. Praktyczne zalecenie jest proste: przed fuzją filtrować lub skracać kandydatów z flagami błędów TRUNCATED i REPETITION.

Mechanizm zadziałał jednak dokładnie tak, jak powinien. Sędzia nie zaufał pewnym siebie twierdzeniom, tylko je przeliczył. Jeden z kandydatów napisał na przykład, że 20 + 5 = 25 ma odpowiadać 29. Sędzia zdemaskował tę „weryfikację” i odrzucił rozwiązanie. Modele też potrafią blefować.

Czterech różnych sędziów wybrało tę samą zwycięską fundację. W zadaniu z obiektywnym rozwiązaniem stronniczość sędziego nie znalazła odzwierciedlenia w wyroku. Jednak jakość syntezy była różna: duży Qwen2.5-72B prawie po prostu skopiował zwycięzcę, podczas gdy mniejsi sędziowie aktywnie wydobywali przydatne fragmenty nawet ze słabszych odpowiedzi.

Niespodzianka: silnik wnioskowania zmienia zachowanie modelu

GLM-4.7-Flash zdobył w czerwcu 38 punktów przez llama.cpp. Na LUMI, przez vLLM i w dokładniejszej reprezentacji BF16, wynik spadł do 9. Przy niskiej temperaturze model zapętlił się i wypisał 15 000 tokenów ciągu liczb.

Zatem te same wagi nie są całym modelem. Silnik, jego wersja, szablon rozmowy, temperatura i limity również wpływają na wynik. Od teraz rejestruję wszystkie te dane dla każdego wyjścia.

Eksperyment 2: 753 miliardy parametrów w jednym węźle

Wieczorem przyszła odważniejsza część. Według karty modelu GLM-5.2 ma 753 miliardy parametrów, z czego około 40 miliardów aktywuje się dla każdego tokena. Przy pełnej precyzji wagi wymagałyby około 1,5 TB pamięci. Użyłem wariantu o rozmiarze 435 GB i precyzji około 4,5 bita.

Jeden węzeł LUMI-G oferuje cztery fizyczne akceleratory AMD MI250X, czyli osiem niezależnych jednostek obliczeniowych GCD, oraz łącznie 512 GB szybkiej pamięci HBM. Model się zmieścił, ale bez dużego zapasu.

W vLLM ten 4-bitowy wariant nie miał odpowiednio zoptymalizowanych kerneli dla tego sprzętu. Dlatego skompilowałem llama.cpp z backendem HIP bezpośrednio dla architektury LUMI. Wynik to 17 tokenów na sekundę. To interaktywnie użyteczna prędkość dla modelu, który nawet w przybliżeniu nie zmieści się na zwykłej stacji roboczej.

Pierwsza próba jednak się nie powiodła. Ładowanie pliku 435 GB przez mmap z równoległego systemu plików Lustre po 40 minutach nadal nie posunęło się naprzód. Przełącznik --no-mmap skrócił ten sam proces do około pięciu minut. Duża część doświadczenia z HPC wygląda właśnie tak: godziny poszukiwań, jeden przełącznik, ośmiokrotna różnica.

Co gigant odpowiedział na pytanie o sens życia?

Jako pierwsze pytanie na rozgrzewkę zadałem mu: „Jaki jest sens życia?” Odpowiedział z zaskakującą trzeźwością: „Sens nie jest czymś, co istnieje gdzieś na zewnątrz jako przedmiot, który można znaleźć. Raczej sens życia jest tworzony i postrzegany”. Potem przyszedł egzystencjalizm, nacisk Frankla na pracę, miłość i stosunek do cierpienia, a także biologiczną perspektywę przetrwania i kontynuacji życia.

To nie jest wynik naukowy, lecz mały portret modelu. Mimo to ma swój urok fakt, że pierwsze zdanie systemu z 753 miliardami parametrów nie dotyczyło wydajności. Mówiło o tym, że sens musimy tworzyć sami.

Pełne i skompresowane GLM nie były tym samym modelem

Następnie dałem obu wersjom nasze otwarte zadanie testowe. Pełny GLM-5.2 przez API otrzymał ręczną ocenę około 95/100. Popełnił błąd, obalił go uczciwym obliczeniem, znalazł właściwą regułę i na końcu sam wskazał, gdzie jego rozumowanie było błędne.

Wersja skwantowana zakończyła test z wynikiem około 50/100. Często tylko pozorowała obliczenia kontrolne. Zapisywała równania, które się nie zgadzały, i tego nie zauważała.

Tymczasem 4-bitowy Qwen stracił w pierwszym eksperymencie zaledwie 2 do 4 punktów w stosunku do BF16. Zatem ta sama kompresja może być prawie nieszkodliwa dla jednego modelu i niezbędna dla innego. Bez pomiaru nie można tego poznać po liczbie parametrów ani po rozmiarze pliku.

Eksperyment 3: noc z GPQA Diamond

Jedno otwarte zadanie jest anegdotą. Dlatego z dnia na dzień dodałem GPQA Diamond, test porównawczy pytań naukowych na poziomie doktoranckim z biologii, chemii i fizyki. Odpowiedzi są od A do D i znana jest prawidłowa opcja, więc nie potrzebujemy sędziego AI.

Przed uruchomieniem wylosowałem warstwowo 60 ze 198 pytań, zapisałem ich identyfikatory i ustawiłem seed 42. Tam, gdzie pozwalał na to ruch, wykonałem trzy przebiegi z różnymi seedami. Nie publikuję treści pytań, aby chronić benchmark.

Dokładność w trybie ścisłym. Słupki pokazują 95% przedziałów Wilsona. Pełne systemy i warianty Qwen mają 180 odpowiedzi, lokalny GLM Q4 60; dlatego też bliskie wyniki nie powinny być odczytywane jako ostateczne rankingi.

Najlepszy wynik uzyskał pełny GLM-5.2 z wysokim budżetem na reasoning: 89,4%. Jest to zbliżone do wartości producenta 91,2% z oficjalnej karty modelu. Znacznie mniejszy Qwen3.6-27B bez reasoningu uzyskał 86,7%. Różnica 2,7 punktu procentowego jest mniejsza niż niepewność statystyczna dla tej próby.

To jest ważne. Model z 27 miliardami parametrów był bardzo zbliżony do modelu z 753 miliardami parametrów ogółem w tym konkretnym zadaniu. Nie oznacza to, że ogólnie jest tak samo zdolny. Oznacza to, że dla tego typu zapytań może wystarczyć znacznie mniejszy system.

W przypadku Qwena z reasoningiem obok ścisłego wyniku 82,8% należy podać jeszcze jedną ważną liczbę: 94,0% wśród ukończonych odpowiedzi. Różnica pokazuje, jak silnie na ścisły wynik wpłynęła zdolność dostarczenia odpowiedzi: 31 ze 180 przebiegów nie podało ostatecznego wyboru w limicie 30 000 tokenów.

Reasoning pomógł pełnemu modelowi i zaszkodził skompresowanemu

Ta sama rodzina modeli, ale przeciwny efekt reasoningu. W gałęzi Q4 aż 35 z 60 odpowiedzi osiągnęło limit 8000 tokenów, więc wykres mierzy jednocześnie zdolność modelu i praktyczną możliwość dostarczenia odpowiedzi w danym budżecie.

W pełnym GLM myślenie podniosło wynik z 74,4 do 89,4%. Z drugiej strony dla 4-bitowego GLM spadł z 80 do 53%.

Najbardziej prawdopodobne wyjaśnienie jest zgodne z badaniem Quantization Meets Reasoning: błąd kwantyzacji może pojawić się wcześnie w łańcuchu rozumowania, a kolejne kroki go wzmacniają. Nowsza praca Quantized Reasoning Models Think They Need to Think Longer, but They Do Not opisuje ten sam wzorzec zbędnego myślenia: agresywna kwantyzacja wydłużała łańcuchy rozumowania, podczas gdy dokładność spadała. W naszym przebiegu 35 z 60 odpowiedzi przekroczyło limit 8000 tokenów. Nie mogę więc stwierdzić, że sama kompresja spowodowała cały spadek. Dane wyraźnie jednak pokazują, że ta konkretna konfiguracja Q4 nie nadaje się do długiego reasoningu w praktycznym budżecie.

Tomáš Mikolov i ThinkingCap: myśl mniej, dostarczaj lepiej

Do nocnego testu dodałem także nowy ThinkingCap-Qwen3.6-27B firmy BottleCap AI, w którego badaniach uczestniczy Tomáš Mikolov. Celem nie jest uczynienie Qwena mądrzejszym. Model ma nauczyć się wcześniej zatrzymywać, ograniczać zbędne pętle i osiągać tę samą jakość przy mniejszej liczbie tokenów.

To jest właśnie obszar, w którym Tomáš Mikolov od dawna jest mocny: wydajność, a nie tylko pogoń za większym modelem.

Te same 60 pytań i trzy seedy. Wykres pokazuje ścisłą dokładność, średnią liczbę tokenów wyjściowych, medianę opóźnienia i ucięte odpowiedzi we wszystkich czterech trybach.

Najważniejszy wniosek jest taki, że w tym konkretnym zadaniu najlepszy ścisły wynik uzyskał zwykły Qwen bez reasoningu: 86,7%. ThinkingCap bez reasoningu osiągnął 82,2%. Po włączeniu reasoningu kolejność się odwróciła: ThinkingCap uzyskał 84,4%, a Qwen 82,8%.

W przypadku Qwena reasoning obniżył więc ścisły wynik z 86,7 do 82,8%. Istotnie przyczynił się do tego wzrost liczby uciętych odpowiedzi z 11 do 31 na 180; gałąź reasoningowa miała limit 30 000 tokenów. W przypadku ThinkingCap reasoning podniósł wynik z 82,2 do 84,4%. Ten sam przełącznik dał przeciwne rezultaty w dwóch spokrewnionych modelach.

Przy włączonym reasoningu ThinkingCap zużył średnio 7312 tokenów wobec 15 097 w oryginalnym Qwenie, czyli o 52% mniej. Mediana opóźnienia spadła z 1189 do 403 sekund, a liczba uciętych odpowiedzi z 31 do 9. ThinkingCap spełnił więc główną obietnicę: przy ograniczonym budżecie częściej dostarczał kompletną odpowiedź.

Jeśli porównamy tylko ukończone odpowiedzi reasoningowe, oryginalny Qwen uzyskał 94%, a ThinkingCap 88,9%. Qwen miał zatem wyższy pułap, ale przy stałym budżecie częściej nie zdążył go dostarczyć.

Mój werdykt jest więc celowo powściągliwy: ThinkingCap nie jest w tym pilotażu mądrzejszym Qwenem. Jest bardziej zdyscyplinowanym Qwenem. W produkcji może być cenniejszy właśnie dlatego, że wie, kiedy przestać. W zadaniach z niemal nieograniczonym czasem, w których liczy się najwyższy możliwy poziom, pierwotna wersja pozostała mocniejsza.

Budżetowanie na myślenie to osobna umiejętność

W ciągu nocy zwiększyłem limit odpowiedzi trzy razy, ponieważ pierwotnie ustawiłem go jako domysł. Qwen była w stanie wykorzystać 30 000 tokenów na trudne pytanie i nadal nie dotarła do ostatecznego wyboru od A do D.

W rezultacie uzyskano trzy wskaźniki:

1. Ścisłe: Sztywne ograniczenie. Niepełna odpowiedź to zero. Mierzy możliwość wdrożenia w ramach budżetu.
2. Wymuszone budżetem: Model wie, ile tokenów mu zostało, i musi zakończyć odpowiedź. Mierzy zarządzanie budżetem.
3. Bez ograniczeń: Model może myśleć bardzo długo. Mierzy górną granicę możliwości, a nie praktyczny produkt.

Jak wypadło porównanie trzech metryk

Końcowa pula ratunkowa zawierała 40 unikalnych przebiegów Qwena, które przekroczyły limit w testowanych trybach i dlatego otrzymały zero w metryce strict. W powtórzeniu budget-forced model otrzymał 5000 tokenów i wyraźne polecenie zakończenia odpowiedzi. Poprawnie uratował 11 z 40 prób (27,5%). Wariant unbounded miał pułap 100 000 tokenów i około 85 minut czasu na węźle. Ukończył tylko 13 z 40 prób i poprawnie odpowiedział w 8 przypadkach (20%).

Wymuszone zakończenie rozwiązało więc w tej puli więcej przepełnień niż niemal nieograniczone myślenie, za ułamek kosztu obliczeń. Około dwie trzecie najtrudniejszych prób nie dostarczyło użytecznego wniosku nawet przy wyjątkowo wysokim limicie. „Nie zdążył” zwykle nie oznaczało tu „potrzebował trochę więcej miejsca”, lecz „nie potrafił zdecydować na czas”.

Pula obejmowała przepełnienia z obu testowanych trybów Qwena. Gdy ratunkowe odpowiedzi doliczymy wyłącznie do pełnej gałęzi reasoningowej, jej wynik rośnie z 82,8% strict do 86,1% capability z budget forcingiem i 87,2% z przebiegiem unbounded. Ten drugi wariant dodał tylko 1,1 punktu procentowego przy nieporównywalnie większym czasie i koszcie obliczeń. W praktyce lepiej sprawdza się więc stały budżet z wymuszonym zakończeniem niż dalsze zwiększanie limitu. Qwen osiąga w ten sposób mniej więcej poziom swojej wersji bez reasoningu (86,7%), ale znacznie drożej.

Artykuł Scaling LLM Test-Time Compute Optimally pokazuje, że mniejszy model może uzyskać lepsze wyniki niż znacznie większy przy dobrze rozłożonym czasie obliczeń. Nasz wynik dodaje praktyczny wniosek: ten czas należy mądrze podzielić. Samo zwiększanie limitu nie jest strategią.

Co pokazało dziesięć hipotez

Nawet cztery sloty nie zapewniły czterokrotnej wydajności

Łączna prędkość utrzymywała się na poziomie około 16 do 17 tokenów na sekundę. W przypadku tego dużego modelu MoE pojedynczy strumień wyczerpał przepustowość pamięci, a dodatkowe sloty nie zapewniły oczekiwanego skalowania.

Spodziewałem się, że więcej jednoczesnych gniazd zwiększy przepustowość co najmniej 1,5 razy. Zmierzyłem 16, 17 i 17 tokenów na sekundę odpowiednio dla jednego, dwóch i czterech slotów. Praktycznie linia prosta.

Odpowiada to dobrze znanemu problemowi wnioskowania MoE: przetwarzanie wsadowe może aktywować więcej ekspertów i zwiększyć presję na przepustowość pamięci. Opisano to np. w pracy Lynx. Dlatego nie będę dodawać slotów na pojedynczym węźle do dalszych testów porównawczych. Dzielę zapytania między wiele replik w wielu węzłach.

Co poszło nie tak

Około jedna trzecia z około 35 zadań zakończyła się niepowodzeniem w ciągu dwóch dni. Prawie zawsze moja wina, nie LUMI.

• Kontrola stanu bez parametru -f uznała odpowiedź 503 Loading model za oznakę sprawnego serwera. W ten sposób osiemdziesiąt pytań poszło na marne.
• Limit czasu HTTP był krótszy niż w przypadku najdłuższej generacji. Po 30 minutach klient odrzucał odpowiedź, nad którą model pracował przez 50 minut.
• Trzy razy nie doceniłem limitu odpowiedzi. To był najkosztowniejszy błąd systematyczny.
• Polecenie pkill dwukrotnie zakończyło samo siebie.
• Podpisane adresy Hugging Face wygasły przed pobraniem pliku 46 GB, a klient zawiesił się bez błędów.
• Multimodalne dostrojenie nie zawierało kompletnych plików procesora. Właściwym rozwiązaniem było uzupełnienie ich z modelu podstawowego.
• Na węźle współdzielonym obcy proces może wyczyścić pamięć współdzieloną w ramach działającego vLLM.

Zapisałem wszystkie błędy w formacie symptomów, przyczyn, napraw i zapobiegania. Może się to okazać jednym z najcenniejszych wyników. Inny zespół nie musi już płacić takiego samego czesnego.

Ile to wszystko kosztowało?

Łącznie z nieudanymi uruchomieniami, naprawami, replikami, zadaniami nocnymi i końcowymi przebiegami unbounded zużyłem około 55 godzin GPU z przydzielonych 5000, czyli około 1,1% przydziału. Zewnętrzne API kosztowało około 350 CZK.

To chyba najmniej intuicyjny wynik. Poważne badania pilotażowe na europejskim superkomputerze nie muszą być kosztowne, jeśli hipotezy są pisane z wyprzedzeniem, przebiegi są powtarzalne, a martwe zadania są szybko zatrzymywane.

Dostęp nie jest zarezerwowany dla wielkich laboratoriów

Dostęp do LUMI uzyskałem dzięki Jakubowi Siwkowi i czeskiemu zespołowi IT4Innovations, który pośredniczy w wejściu do LUMI AI Factory. Zacząłem od najniższej alokacji playground wynoszącej 5000 godzin GPU. Według Jakuba dobre ukończenie jednego z mniejszych programów otwiera także drogę do złożenia wniosku o poziom 50 000+ godzin GPU. Nie jest to automatyczna przepustka, ale pilotaż tworzy dokładnie to, czego potrzebuje większy wniosek: działający workflow, pierwsze dane i dowód, że przydzielona moc zostanie dobrze wykorzystana.

Również oczekiwanie nie było tym razem dramatyczne. Małe zadania deweloperskie uruchamiały się w ciągu sekund lub minut. Poniedziałkowe opóźnienie wynoszące około dwóch i pół godziny było skutkiem prac bezpieczeństwa w całej infrastrukturze, a nie zwykłej kolejki.

Dla firmy lub programisty płynie z tego zachęcająca wiadomość: droga do superkomputera nie musi zaczynać się od zakupu sprzętu ani grantu dla ogromnego laboratorium. Zaczyna się od dobrego pytania, kilku hipotez zapisanych z wyprzedzeniem i kontaktu z krajową AI Factory.

Co z tego wyniknie w praktyce?

Jakub Siwek z IT4Innovations zapytał mnie podczas eksperymentu, dokąd to wszystko prowadzi w dłuższej perspektywie. Odpowiedź jest prosta: do mapy decyzyjnej dotyczącej wdrożenia AI za rozsądne pieniądze.

Kiedy wystarczy mały otwarty model? Kiedy połączenie kilku małych pomoże? Kiedy lepiej dopłacić za duży model? Kiedy włączyć rozumowanie? A skąd wiemy, że kompresja uszkodziła potrzebną nam zdolność?

Na tych danych można zbudować inteligentny router dla HyperProstor. Każde zapytanie kierowałby do najtańszego systemu, który prawdopodobnie sobie z nim poradzi. Tylko najtrudniejsze przypadki trafiałyby do drogiego specjalisty. RouteLLM pokazuje, że podobny routing może znacznie obniżyć koszty przy zachowaniu większości jakości. Chcę przetestować ten pomysł na własnych danych, wielu modelach i rzeczywistych zadaniach biznesowych.

Istnieje także wymiar europejski. Firmy często boją się AMD, ponieważ swoje modele rozwijały w ekosystemie NVIDIA. Jeśli chodzi o trening, różnica jest nadal znacząca. Jednak w przypadku funkcjonowania gotowych modeli otwartych bariera wejścia jest mniejsza, niż się tradycyjnie uważa. W ciągu dwóch dni uruchomiłem Qwen, GLM, ThinkingCap i skwantowany model 435 GB na europejskim sprzęcie AMD. Nie musiałem ich znowu uczyć. Potrzebowałem odpowiednich kontenerów, silników i kilku kosztownych przełączników.

Pierwszy artykuł pokazał, że mogę połączyć się z LUMI i uruchomić przetwarzanie wsadowe. To drugie pokazuje coś bardziej interesującego: że można przeprowadzić uczciwe, powtarzalne badania otwartego modelu infrastruktury europejskiej i uzyskać wyniki, które nie są jedynie przepisywaniem arkuszy kalkulacyjnych dostawców.

I to się dopiero teraz zaczyna.

Uwaga metodologiczna

To jest pilotaż, a nie ostateczny ranking. Test otwarty w Eksperymencie 1 zawierał jedno zadanie. Część GPQA zadziałała w przypadku 60 ze 198 pytań i nie wszystkie konfiguracje miały taką samą liczbę powtórzeń. Dlatego na podstawie wyników podejmuję decyzję o kolejnym etapie, nie mówiąc już o tym, że jeden model generalnie bije drugi.

Następnym krokiem jest zwiększenie liczby zadań, dodanie większej liczby seedów, raportowanie przedziałów ufności i porównanie fuzji z równie kosztownymi metodami bazowymi. Dopiero potem przyjdzie czas na wyuczony router.

Źródła i dane

• Fabryka LUMI AI: Czeska Alpha Industries potwierdza moc i zrównoważony rozwój LUMI
• Dokumentacja węzła LUMI-G
• GLM-5.2: model karty i testy porównawcze dostawców
• GPQA: A Graduate-Level Google-Proof Q&A Benchmark
• Li i in. (2025): Quantization Meets Reasoning
• Lotfi i in. (2026): Quantized Reasoning Models Think They Need to Think Longer, but They Do Not
• Snell i in. (2024): Scaling LLM Test-Time Compute Optimally
• Gupta i in. (2026): Lynx: Efficient MoE Inference
• BottleCap AI: ThinkingCap-Qwen3.6-27B i karta modelu
• LMSYS: RouteLLM

Organizowałem eksperymenty z Fable 5 pod własnym nadzorem. Hipotezy, reguły decyzyjne, nieprzetworzone dzienniki JSONL, wersje silnika i wyniki poszczególnych zapytań są przechowywane w projekcie. Nie publikuję treści samych pytań GPQA ze względu na integralność benchmarku.