Jetzt sind wir auch in Finnland bekannt: zwei Tage und eine Nacht auf LUMI

Jetzt sind wir auch in Finnland bekannt.

Mein erster Artikel über LUMI weckte direkt die Aufmerksamkeit des Teams der LUMI AI Factory. Am Sonntag veröffentlichte es einen eigenen Beitrag über Alpha Industries: Czechia's Alpha Industries validates LUMI's power and sustainability in their initial test. So wurde mein erster tschechischer Versuch innerhalb weniger Tage zu einer Geschichte auf der offiziellen finnischen Website der europäischen KI-Infrastruktur.

Darüber habe ich mich ehrlich gefreut. Zugleich wollte ich herausfinden, ob sich auch der zweite Akt lohnen würde.

Am Montagmorgen wurde LUMI nach einer Sicherheitsabschaltung wiedereröffnet. In den nächsten 38 Stunden führte ich drei Experimente durch, testete zehn vorgefertigte Hypothesen, kompilierte eine benutzerdefinierte Inferenz-Engine für AMD, ließ ein Modell mit etwa 753 Milliarden Parametern auf einem einzelnen Knoten laufen und ließ über Nacht mehrere Systeme laufen, um wissenschaftliche Fragen auf Doktorandenniveau zu lösen.

Einige Hypothesen bestätigten sich. Andere scheiterten so überzeugend, dass gerade sie zum interessantesten Teil des Ergebnisses wurden.

LUMI in Kajaani. Hinter der markanten blauen Verkleidung arbeitet die europäische Infrastruktur, auf der diese Experimente liefen.

Das ganze Experiment in einem Satz: Ein großes Modell ist nicht automatisch das beste, die 4-Bit-Komprimierung schadet nicht allen Modellen gleichermaßen und mehr Nachdenken kann die Qualität um 15 Punkte steigern oder um 27 Punkte verringern.

Zunächst vier Begriffe, einfach erklärt

Modellfusion ist eine KI-Jury. Mehrere Modelle antworten unabhängig voneinander, ein weiteres Modell prüft ihre Antworten und fügt sie zu einer endgültigen Lösung zusammen.

Quantisierung ist Komprimierung. Anstatt jeden Wert in 16 Bits zu speichern, verwenden wir etwa 4 Bits. Das Modell benötigt weniger Speicher, kann jedoch einige Funktionen verlieren.

Reasoning, also schrittweises Denken, bedeutet, dass das Modell vor der endgültigen Antwort einen längeren internen Lösungsweg durchläuft. Bei schwierigen Aufgaben kann das stark helfen, kostet aber Zeit, Energie und Token.

Ein Benchmark ist ein standardisierter Test mit bekannten richtigen Antworten. Dadurch muss die Qualität nicht von einer anderen KI beurteilt werden.

Warum schreibe ich Hypothesen im Voraus auf?

Vor jedem Experiment habe ich die erwarteten Ergebnisse und die Regeln, nach denen ich sie bewerten würde, aufgeschrieben. Es ist eine einfache Versicherung gegen Selbsttäuschung. Sie schreiben die Prognose vor dem Start auf und können nach dem Ergebnis nicht mehr behaupten, dass dies genau das ist, was Sie erwartet haben.

Im ersten und dritten Experiment wurden zehn Hypothesen aufgestellt. Einige wurden bestätigt, andere nur teilweise und drei verliefen anders als ich erwartet hatte. Das ist keine Schande. Dies ist der Grund, das Experiment überhaupt durchzuführen.

Experiment 1: Modellfusion ein zweites Mal

Im Juni habe ich auf einer einzelnen RTX 5090 gezeigt, dass eine Fusion der lokalen Modelle Qwen und GLM 98 von 100 Punkten erzielte und damit die einzelnen Konfigurationen übertraf. Auf LUMI wiederholte ich denselben Test mit voller BF16-Genauigkeit, denselben Prompts und derselben Aufgabe.

Ich habe neu 60 Punkte mit einem deterministischen Skript gegen die richtige Lösung ausgewertet. Die restlichen 40 Punkte wurden von einem Grenzmodell außerhalb des getesteten Panels bewertet. Und da ich neulich zu Recht kritisiert wurde, dass Qwen eine Jury bewertete, der er selbst angehörte, habe ich unabhängige Richter hinzugefügt.

Ergebnis in einer vordefinierten, offenen Aufgabe, daher kein allgemeines Modellranking. Fusion blieb an der Spitze, belegte dieses Mal jedoch gemeinsam mit dem eigenständigen Qwen den ersten Platz.

Die Fusion erreichte 99/100. Der beste eigenständige Qwen kam auf dasselbe Ergebnis. Das ist eine wichtige Nuance: Die Replikation bestätigte, dass die Fusion eine hervorragende Lösung bewahrt und schlechte Kandidaten herausfiltern kann, nicht aber, dass sie in jedem Durchlauf zwingend das beste Panelmitglied übertrifft.

Diese Robustheit war jedoch nicht kostenlos. Ein degenerierter Kandidat führte den Richter nicht in die Irre, doch seine 15.000 Token Rauschen vergrößerten die Richtereingabe auf 31.000 Token und verdoppelten ungefähr die Prefill-Kosten. Die praktische Empfehlung ist einfach: Kandidaten mit den Failure-Flags TRUNCATED oder REPETITION vor der Fusion filtern oder kürzen.

Der Mechanismus funktionierte jedoch genau wie vorgesehen. Der Richter vertraute selbstbewussten Behauptungen nicht, sondern rechnete sie nach. Ein Kandidat schrieb beispielsweise, 20 + 5 = 25 entspreche 29. Der Richter entlarvte diese „Verifizierung“ und verwarf die Lösung. Auch Modelle können bluffen.

Vier verschiedene Juroren wählten dieselbe Siegerstiftung. Bei der Aufgabe mit objektiver Lösung spiegelte sich die eigene Befangenheit des Richters nicht im Urteil wider. Die Qualität der Synthese war jedoch unterschiedlich: Der große Qwen2.5-72B kopierte fast nur den Gewinner, während die kleineren Juroren selbst aus den schwächeren Antworten aktiv nützliche Teile extrahierten.

Überraschung: Die Inferenz-Engine verändert das Verhalten des Modells

GLM-4.7-Flash hatte im Juni über llama.cpp 38 Punkte erreicht. Auf LUMI fiel das Modell mit vLLM und in der genaueren BF16-Darstellung auf 9 Punkte. Bei niedriger Temperatur geriet es in eine Schleife und gab 15.000 Token einer Zahlenfolge aus.

Die gleichen Gewichte sind also nicht das ganze Modell. Auch die Engine, ihre Version, Konversationsvorlage, Temperatur und Grenzwerte beeinflussen das Ergebnis. Von nun an protokolliere ich alle diese Daten für jede Ausgabe.

Experiment 2: 753 Milliarden Parameter auf einem einzelnen Knoten

Am Abend kam der mutigere Teil. GLM-5.2 verfügt laut Modellkarte über 753 Milliarden Parameter, von denen etwa 40 Milliarden pro Token aktiviert werden. Bei voller Genauigkeit würden die Gewichte ungefähr 1,5 TB Speicher benötigen. Ich verwendete eine rund 4,5 Bit große Variante mit 435 GB.

Ein LUMI-G-Knoten bietet vier physische AMD-MI250X-Beschleuniger, also acht eigenständige Rechen-GCDs, und insgesamt 512 GB schnellen HBM-Speicher. Das Modell passte also, allerdings ohne großen Spielraum.

In vLLM verfügte diese 4-Bit-Variante auf der Hardware nicht über ausreichend optimierte Kernel. Daher kompilierte ich llama.cpp mit dem HIP-Backend direkt für die LUMI-Architektur. Das Ergebnis waren 17 Token pro Sekunde. Das ist eine interaktiv nutzbare Geschwindigkeit für ein Modell, das nicht einmal annähernd in eine normale Workstation passt.

Der erste Versuch scheiterte dennoch. Das Laden einer 435-GB-Datei über mmap aus dem parallelen Lustre-Dateisystem machte auch nach 40 Minuten keinen Fortschritt. Der Schalter --no-mmap verkürzte denselben Ladevorgang auf etwa fünf Minuten. Ein großer Teil der HPC-Erfahrung sieht genau so aus: stundenlange Suche, ein Schalter, ein achtfacher Unterschied.

Was antwortete der Riese auf die Frage nach dem Sinn des Lebens?

Als erste Aufwärmfrage stellte ich ihm: „Was ist der Sinn des Lebens?“ Er antwortete mit überraschender Nüchternheit: „Sinn ist nicht etwas, das da draußen als zu findendes Objekt existiert. Vielmehr wird der Sinn des Lebens geschaffen und wahrgenommen.“ Dann kam der Existentialismus, Frankls Betonung von Arbeit, Liebe und Einstellung zum Leiden sowie die biologische Perspektive des Überlebens und der Fortsetzung des Lebens.

Es handelt sich nicht um ein wissenschaftliches Ergebnis, sondern eher um ein kleines Porträt des Modells. Aber es ist charmant, dass es im ersten Satz des 753-Milliarden-Supercomputersystems nicht um Leistung ging. Ihr ging es darum, dass wir selbst Sinn schaffen müssen.

Die vollständigen und komprimierten GLMs waren nicht dasselbe Modell

Dann habe ich beiden Versionen unseren offenen Testauftrag gegeben. Das vollständige GLM-5.2 über API erreichte eine manuelle Schätzung von etwa 95/100. Er machte einen Fehler, widerlegte ihn mit einer ehrlichen Berechnung, fand die richtige Regel und benannte sich schließlich dort, wo er falsch dachte.

Die quantisierte Version endete bei etwa 50/100. Sie hat die Scheckberechnungen oft nur vorgetäuscht. Sie schrieb Gleichungen, die nicht aufgingen, und bemerkte es nicht.

Unterdessen verlor 4-Bit-Qwen im ersten Experiment nur 2 bis 4 Punkte gegen BF16. So kann die gleiche Komprimierung für ein Modell nahezu harmlos und für ein anderes unerlässlich sein. Ohne Messung kann weder die Anzahl der Parameter noch die Größe der Datei ermittelt werden.

Experiment 3: Eine Nacht mit GPQA Diamond

Eine offene Aufgabe ist nur eine Anekdote. Deshalb ergänzte ich über Nacht GPQA Diamond, einen Benchmark mit naturwissenschaftlichen Fragen auf Doktorandenniveau aus Biologie, Chemie und Physik. Die Antworten reichen von A bis D und die richtige Option ist bekannt, sodass wir keinen KI-Richter benötigen.

Vor dem Start habe ich 60 der insgesamt 198 Fragen geschichtet, ihre Kennungen gespeichert und einen Startwert von 42 festgelegt. Wo der Verkehr es erlaubte, wurden drei Startwerte ausgeführt. Ich veröffentliche den Inhalt der Fragen nicht, um den Maßstab zu schützen.

Genauigkeit im strengen Modus. Die Balken zeigen 95 % Wilson-Intervalle. Vollständige Systeme und Qwen-Varianten haben 180 Antworten, lokales GLM Q4 60; Daher sollten knappe Ergebnisse nicht als endgültige Ranglisten interpretiert werden.

Das beste Ergebnis erzielte der vollständige GLM-5.2 mit hohem Reasoning-Budget: 89,4 %. Das liegt nahe am Herstellerwert von 91,2 % aus der offiziellen Modellkarte. Der deutlich kleinere Qwen3.6-27B erreichte ohne Reasoning 86,7 %. Die Differenz von 2,7 Prozentpunkten ist kleiner als die statistische Unsicherheit dieser Stichprobe.

Das ist wichtig. Das Modell mit 27 Milliarden Parametern kam dem Modell mit 753 Milliarden Gesamtparametern bei dieser speziellen Aufgabe sehr nahe. Das bedeutet nicht, dass er im Allgemeinen genauso fähig ist. Dies bedeutet, dass für diese Art von Abfrage möglicherweise ein viel kleineres System ausreichend ist.

Bei Qwen mit Reasoning gehört neben den strikten Wert von 82,8 % noch eine wichtige Zahl: 94,0 % bei den abgeschlossenen Antworten. Die Lücke zeigt, wie stark die Auslieferbarkeit das strikte Ergebnis beeinflusste: 31 von 180 Läufen lieferten innerhalb des Limits von 30.000 Token keine endgültige Auswahl.

Reasoning half dem vollständigen Modell und schadete dem komprimierten

Dieselbe Modellfamilie, aber ein gegensätzlicher Reasoning-Effekt. Im Q4-Zweig erreichten 35 von 60 Antworten das Limit von 8.000 Token. Das Diagramm misst daher sowohl die Fähigkeit als auch die praktische Auslieferbarkeit innerhalb eines festen Budgets.

Für das vollständige GLM erhöhte das Denken den Wert von 74,4 auf 89,4 %. Beim 4-Bit-GLM hingegen sank er von 80 auf 53 %.

Die wahrscheinlichste Erklärung entspricht der Studie Quantization Meets Reasoning: Quantisierungsfehler können früh in der Argumentationskette auftreten und werden durch weitere Schritte verstärkt. Die neuere Arbeit Quantized Reasoning Models Think They Need to Think Longer, but They Do Not beschreibt dasselbe Muster unnötigen Weiterdenkens: Aggressive Quantisierung verlängerte die Reasoning-Ketten, während die Genauigkeit sank. In unserem Lauf überschritten 35 von 60 Antworten das Limit von 8.000 Token. Daher kann ich nicht sagen, dass die Kompression allein den gesamten Rückgang verursacht hat. Die Daten zeigen jedoch eindeutig, dass diese spezielle Q4-Konfiguration für langes Reasoning innerhalb eines praktischen Budgets ungeeignet ist.

Tomáš Mikolov und ThinkingCap: Weniger denken, besser liefern

Ich nahm auch das neue ThinkingCap-Qwen3.6-27B von BottleCap AI in den Nachttest auf, an dessen Forschung Tomáš Mikolov beteiligt ist. Das Ziel ist nicht, Qwen klüger zu machen. Das Modell soll früher stoppen, unnötige Schleifen vermeiden und dieselbe Qualität mit weniger Token erreichen.

Genau darin ist Tomáš Mikolov schon lange stark: Effizienz, nicht nur das Streben nach einem größeren Modell.

Dieselben 60 Fragen und drei Seeds. Das Diagramm zeigt strikte Genauigkeit, durchschnittliche Ausgabetoken, mediane Latenz und abgeschnittene Antworten in allen vier Modi.

Der wichtigste Punkt ist: Bei dieser konkreten Aufgabe erzielte der gewöhnliche Qwen ohne Reasoning mit 86,7 % das beste strikte Ergebnis. ThinkingCap ohne Reasoning kam auf 82,2 %. Nach dem Einschalten von Reasoning kehrte sich die Reihenfolge um: ThinkingCap erreichte 84,4 %, Qwen 82,8 %.

Bei Qwen senkte Reasoning den strikten Wert somit von 86,7 auf 82,8 %. Dazu trug der Anstieg abgeschnittener Antworten von 11 auf 31 von 180 erheblich bei; der Reasoning-Zweig verwendete ein Limit von 30.000 Token. Bei ThinkingCap erhöhte Reasoning den Wert dagegen von 82,2 auf 84,4 %. Derselbe Schalter führte bei zwei verwandten Modellen zu gegensätzlichen Ergebnissen.

Mit aktiviertem Reasoning verbrauchte ThinkingCap durchschnittlich 7.312 Token gegenüber 15.097 beim ursprünglichen Qwen, eine Ersparnis von 52 %. Die mediane Latenz sank von 1.189 auf 403 Sekunden und die Zahl abgeschnittener Antworten von 31 auf 9. Damit erfüllte ThinkingCap sein zentrales Versprechen: Innerhalb eines begrenzten Budgets lieferte es häufiger eine vollständige Antwort.

Vergleichen wir nur die abgeschlossenen Reasoning-Antworten, erreichte der ursprüngliche Qwen 94 %, ThinkingCap dagegen 88,9 %. Qwen hatte also die höhere Obergrenze, konnte sie innerhalb des festen Budgets aber häufiger nicht ausliefern.

Mein Urteil fällt daher bewusst nüchtern aus: ThinkingCap ist in diesem Pilotversuch kein klügerer Qwen. Es ist ein disziplinierterer Qwen. In der Produktion kann es gerade deshalb wertvoller sein, weil es weiß, wann es aufhören muss. Für Aufgaben mit nahezu unbegrenztem Zeitbudget und dem Ziel maximaler Leistungsfähigkeit blieb die ursprüngliche Version stärker.

Budgetierung für das Denken ist eine separate Fähigkeit

Ich habe das Antwortlimit in der Nacht dreimal erhöht, weil ich es ursprünglich als Vermutung festgelegt hatte. Qwen konnte 30.000 Token für eine schwierige Frage verbrauchen und erreichte dennoch nicht die endgültige Auswahl von A bis D.

Daraus ergaben sich drei Kennzahlen:

1. Streng: Hartes Limit. Eine unvollständige Antwort ist Null. Misst die Einsatzfähigkeit innerhalb des Budgets.
2. Budget-erzwungen: Das Modell weiß, wie viele Token es noch hat und muss die Antwort schließen. Es misst die Haushaltsführung.
3. Unbegrenzt: Das Modell kann sehr lange denken. Es misst eher die Obergrenze der Fähigkeiten als ein praktisches Produkt.

Wie der Vergleich der drei Metriken ausging

Der endgültige Rettungspool enthielt 40 eindeutige Qwen-Läufe, die in den getesteten Modi ihr Limit überschritten hatten und in der strict Metrik daher null Punkte erhielten. Beim budget-forced Wiederholungsversuch erhielt das Modell 5.000 Token und die ausdrückliche Anweisung, seine Antwort abzuschließen. Es rettete 11 von 40 Versuchen korrekt (27,5 %). Die unbounded Variante hatte eine Obergrenze von 100.000 Token und ein Zeitfenster von ungefähr 85 Minuten auf dem Knoten. Sie schloss nur 13 von 40 Versuchen ab und beantwortete 8 korrekt (20 %).

Der erzwungene Abschluss löste in diesem Rettungspool somit mehr Überläufe als nahezu unbegrenztes Denken, und das zu einem Bruchteil der Rechenkosten. Etwa zwei Drittel der schwierigsten Versuche lieferten selbst mit dem außergewöhnlich hohen Limit keine brauchbare Schlussfolgerung. „Nicht geschafft“ bedeutete hier meist nicht „brauchte etwas mehr Platz“, sondern „konnte sich nicht rechtzeitig entscheiden“.

Der Pool enthielt Überläufe aus beiden getesteten Qwen-Modi. Werden die Rettungen nur in den vollständigen Reasoning-Zweig zurückgerechnet, steigt dessen Ergebnis von 82,8 % strict auf 86,1 % capability mit Budget Forcing und 87,2 % mit dem unbounded Lauf. Letzterer gewann nur 1,1 Prozentpunkte bei unvergleichlich höheren Zeit- und Rechenkosten. Für die Praxis ist daher ein festes Budget mit erzwungenem Abschluss besser als eine weitere Erhöhung des Limits. Qwen erreicht damit ungefähr das Niveau seiner Variante ohne Reasoning (86,7 %), allerdings zu wesentlich höheren Kosten.

Die Arbeit Scaling LLM Test-Time Compute Optimally zeigt, dass ein kleineres Modell mit gut verteilter Rechenzeit ein deutlich größeres übertreffen kann. Unser Ergebnis ergänzt eine praktische Folgerung: Diese Zeit muss klug aufgeteilt werden. Eine bloße Erhöhung des Limits ist keine Strategie.

Was die zehn Hypothesen zeigten

Nicht einmal vier Slots brachten eine Vervierfachung der Leistung

Die Gesamtgeschwindigkeit blieb bei etwa 16 bis 17 Token pro Sekunde. Bei diesem großen MoE-Modell wurde die Speicherbandbreite eines einzelnen Streams ausgeschöpft, und zusätzliche Steckplätze führten nicht zu der erwarteten Skalierung.

Ich habe erwartet, dass mehr gleichzeitige Slots den Durchsatz um mindestens das 1,5-fache steigern würden. Ich habe 16, 17 und 17 Token pro Sekunde für einen, zwei bzw. vier Slots gemessen. Praktisch eine gerade Linie.

Dies entspricht einem bekannten Problem der MoE-Inferenz: Batching kann mehr Experten aktivieren und den Druck auf den Speicherdurchsatz erhöhen. Beschrieben ist es beispielsweise in der Arbeit Lynx. Daher werde ich für weitere Benchmarks keine Slots auf einem einzelnen Knoten hinzufügen. Ich teile die Abfragen auf mehrere Replikate auf mehreren Knoten auf.

Was ist schief gelaufen?

Etwa ein Drittel von etwa 35 Aufträgen scheiterte innerhalb von zwei Tagen. Fast immer meine Schuld, nicht die von LUMI.

• Bei einem Health Check ohne den Parameter -f galt die Antwort 503 Loading model fälschlich als gesunder Server. Achtzig Fragen gingen dadurch verloren.
• Das HTTP-Timeout war kürzer als bei der längsten Generation. Nach 30 Minuten verwarf der Kunde die Antwort, an der das Modell 50 Minuten lang arbeitete.
• Ich habe die Antwortgrenzen dreimal unterschätzt. Das war der teuerste systematische Fehler.
• Der Befehl pkill beendete sich zweimal selbst.
• Die signierten Hugging Face-Adressen liefen ab, bevor die 46-GB-Datei heruntergeladen wurde und der Client ohne Fehler hängen blieb.
• Die multimodale Feinabstimmung verfügte nicht über vollständige Prozessordateien. Die richtige Lösung bestand darin, sie vom Grundmodell zu ergänzen.
• Auf einem gemeinsam genutzten Knoten könnte ein fremder Prozess den gemeinsam genutzten Speicher unter einem laufenden vLLM bereinigen.

Ich habe alle Fehler im Format „Symptom“, „Ursache“, „Behebung“ und „Vorbeugung“ aufgeschrieben. Dies könnte am Ende eines der wertvollsten Ergebnisse sein. Ein anderes Team muss nicht mehr die gleichen Studiengebühren zahlen.

Wie viel hat das alles gekostet?

Einschließlich fehlgeschlagener Läufe, Korrekturen, Replikate, nächtlicher Jobs und der abschließenden unbounded Läufe verbrauchte ich etwa 55 GPU-Stunden der zugewiesenen 5.000, also rund 1,1 % der Zuteilung. Die externe API kostete ungefähr 350 CZK.

Dies ist vielleicht das am wenigsten intuitive Ergebnis. Ernsthafte Pilotforschung an einem europäischen Supercomputer muss nicht teuer sein, wenn Hypothesen im Voraus geschrieben werden, Durchläufe wiederholbar sind und tote Jobs schnell gestoppt werden.

Der Zugang ist nicht großen Laboren vorbehalten

Den Zugang zu LUMI erhielt ich mit Unterstützung von Jakub Siwek und dem tschechischen Team von IT4Innovations, das den Einstieg in die LUMI AI Factory vermittelt. Ich begann mit der kleinsten Playground-Zuteilung von 5.000 GPU-Stunden. Laut Jakub schafft der erfolgreiche Abschluss eines kleineren Programms zugleich eine Grundlage für den Antrag auf die Stufe mit mehr als 50.000 GPU-Stunden. Das ist keine automatische Eintrittskarte, doch ein Pilot liefert genau das, was ein größerer Antrag benötigt: einen funktionierenden Workflow, erste Daten und den Nachweis, dass die Rechenleistung sinnvoll genutzt wird.

Auch die Wartezeit war diesmal überschaubar. Kleine Entwicklungsjobs starteten innerhalb von Sekunden bis Minuten. Die Verzögerung von etwa zweieinhalb Stunden am Montag entstand durch Sicherheitswartung an der gesamten Infrastruktur, nicht durch eine normale Warteschlange.

Für Unternehmen und Entwickler ist die Botschaft ermutigend: Der Weg zu einem Supercomputer muss nicht mit dem Kauf von Hardware oder einem Großlabor-Förderantrag beginnen. Er beginnt mit einer guten Frage, einigen vorab notierten Hypothesen und dem Kontakt zur nationalen AI Factory.

Was wird in der Praxis daraus werden?

Jakub Siwek von IT4Innovations hat mich während des Experiments gefragt, wohin das alles langfristig führt. Die Antwort ist einfach: zur Entscheidungskarte für den Einsatz von KI für angemessenes Geld.

Wann reicht ein kleines offenes Modell? Wann hilft die Fusion mehrerer kleiner Modelle? Wann lohnt sich der Aufpreis für ein großes Modell? Wann sollte Reasoning aktiviert werden? Und woher wissen wir, ob die Komprimierung gerade die Fähigkeit beschädigt hat, die wir benötigen?

Auf Basis dieser Daten kann ein intelligenter Router für HyperProstor entstehen. Er sendet jede Anfrage an das günstigste System, das sie voraussichtlich lösen kann. Nur die schwierigsten Fälle werden an einen teuren Spezialisten weitergereicht. RouteLLM zeigt, dass ein ähnliches Routing die Kosten deutlich senken und zugleich den Großteil der Qualität erhalten kann. Ich möchte diese Idee mit meinen eigenen Daten, mehreren Modellen und realen Geschäftsaufgaben testen.

Es gibt auch eine europäische Dimension. Unternehmen haben oft Angst vor AMD, weil sie ihre Modelle im NVIDIA-Ökosystem entwickelt haben. Für das Training ist der Unterschied immer noch erheblich. Für den Betrieb vorgefertigter offener Modelle ist die Eintrittsbarriere jedoch geringer als traditionell angenommen. Innerhalb von zwei Tagen habe ich Qwen, GLM, ThinkingCap und das quantisierte 435-GB-Modell auf europäischer AMD-Hardware ausgeführt. Ich musste sie nicht noch einmal unterrichten. Ich brauchte die richtigen Container, Motoren und einige teuer gefundene Schalter.

Der erste Artikel zeigte, dass ich eine Verbindung zu LUMI herstellen und eine Stapelverarbeitung ausführen konnte. Letzteres zeigt etwas Interessanteres: dass man ehrliche, wiederholbare offene Modellforschung zur europäischen Infrastruktur durchführen und Ergebnisse erzielen kann, die nicht nur eine Neufassung von Anbietertabellen sind.

Und es fängt gerade erst an.

Methodischer Hinweis

Dies ist ein Pilotprojekt, keine endgültige Rangliste. Der offene Test in Experiment 1 enthielt eine Aufgabe. Der GPQA-Teil funktionierte bei 60 von 198 Fragen und nicht alle Konfigurationen hatten die gleiche Anzahl an Wiederholungen. Daher nutze ich die Ergebnisse, um über die nächste Stufe zu entscheiden, ohne zu sagen, dass ein Modell im Allgemeinen das andere übertrifft.

Der nächste Schritt besteht darin, die Anzahl der Jobs zu erhöhen, weitere Seeds hinzuzufügen, Konfidenzintervalle zu melden und die Fusion mit ebenso teuren Basismethoden zu vergleichen. Erst dann kommt der eingelernte Router an die Reihe.

Quellen und Daten

• LUMI AI Factory: Tschechiens Alpha Industries bestätigt die Leistungsfähigkeit und Nachhaltigkeit von LUMI
• LUMI-G-Knotendokumentation
• GLM-5.2: Modellkarten- und Hersteller-Benchmarks
• 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 und Modellkarte
• LMSYS: RouteLLM

Ich habe die Experimente mit Fable 5 unter meiner eigenen Aufsicht orchestriert. Hypothesen, Entscheidungsregeln, JSONL-Rohprotokolle, Engine-Versionen und Ergebnisse pro Abfrage werden im Projekt gespeichert. Aufgrund der Integrität des Benchmarks veröffentliche ich den Inhalt der GPQA-Fragen selbst nicht.