Warum sich mein Leaderboard neu sortiert hat: Ein Erfahrungsbericht über Tokenhunger, verschwiegene Antworten und die Tücken von OpenRouter

Aufrüsten für ein Modell, das viel verspricht

Ich habe kürzlich meinen lokalen Stack aufgerüstet, der im Kern aus einem Asus Ascent GX10 besteht. Der Grund dafür war mein Qualitätsanspruch. Nachdem ich vor einigen Monaten von meinem 24 GB Shared Memory MacBook M4 auf den Asus GX10 mit 128 GB Shared Memory gewechselt bin, konnte ich endlich größere Modelle laufen lassen, von Qwen 3.6-27B bis hin zu GPT-OSS-120B. Die Modelle liefen schneller, die Ergebnisse wurden besser, aber es fehlte immer noch die Qualität, die ich erwartete.

Auch die Veröffentlichung von Qwen3.8-27B, einem Modell, das einen riesigen Schritt nach vorn machte und die Community begeisterte, ließ bei mir noch Wünsche offen. So konnte ich weiterhin nicht auf die zusätzliche Nutzung von Onlinemodellen wie GLM5.3 als Codereviewer verzichten. Das widersprach allerdings meinem Anspruch auf eine datenschutzkonforme Nutzung von LLMs auf meiner eigenen Infrastruktur.

Parallel beobachtete ich die Ergebnisse des „großen" lokalen Open Weight Modells Qwen3.8-Flash-Next und die Quantisierungsbemühungen um mein bevorzugtes Modell GLM5.3-Flash. Dieses Modell war in seiner veröffentlichten Größe jenseits des Speicherbereichs zweier geclusterter Nvidia Spark LLM-Server. Findige Quantisierer schafften es aber letztlich doch, das Modell auf 186 GB zu quantisieren. So konnte die Community GLM5.3-Flash mit einem Spark-Dualsetup doch im lokalen Stack laufen lassen.

Dann kam der August, und erneut explodierten die Preise für lokale LLM-Hardware. Kostete mein Asus GX10 vor zwei Monaten stattliche 4300 Euro, kostete es jetzt schon 7300 Euro beim gleichen Anbieter. Das machte meine Überlegung zur Aufstockung meiner LLM-Hardware zunichte. Umso erfreuter war ich, ein auslaufendes Angebot zu finden. Es war zwar immer noch gut 1000 Euro teurer als vor ein paar Tagen, aber angesichts des Ramageddon und der zu erwartenden hohen Preise schlug ich zu.

Der Gewinn dieser Investition war endlich die lokale Nutzung von Qwen 3.8 Flash Next, dem Open Weight Vorschaumodell zu Qwen 3.8 Flash mit der gleichen Architektur wie die zukünftige Qwen-4-Familie, und mein besonders geschätztes GLM 5.3 Flash. Beide Modelle sind aus meiner Sicht wirklich ernstzunehmende lokale Intelligenz. Im Benchmark punktet Qwen3.8-Flash-Next zwar deutlich vor GLM5.3-Flash. Vergleicht man aber die technische Dimension der beiden Modelle, wird schnell klar, dass GLM 5.3 Flash das stärkere Modell ist, wenn es um Denktiefe und Kontextfenster geht. Auch beim Weltwissen spricht der größere Parameter-Count für sich. Letztlich landen beide Modelle im Benchmark auf den vorderen Plätzen und in ziemlich guter Gesellschaft.

Das Modell, das schlechter war, als es sein sollte

Nach dem Setup wollte ich es wissen und ließ beide Modelle durch den Benchmark laufen. Nach dem ersten Test schnitt GLM5.3-Flash deutlich schlechter ab als Qwen3.8-Flash-Next. Mein Benchmark orientiert sich zwar nur an Alltagsaufgaben, für Intelligenz- und Mathetests gibt es ja andere Benchmarks, aber dass GLM so gar nicht in die Top 20 wollte, ließ auch einen Fehler im Prozess vermuten.

Die Antwort lag im Tokenhunger des Modells. Dieses Phänomen ist mir erstmals vor etwa einem Jahr bei den ersten GPT-Thinking-Modellen aufgefallen, und es trifft einen blinden Fleck in der Urkonzeption von CrucibleMark. Als ich den Benchmark entworfen habe, gab es kaum Thinking-Modelle im lokalen Betrieb, also habe ich ein gedeckeltes Tokenbudget als Steuerungsinstrument eingebaut.

Mein Gedanke war, Modelle im Rahmen eines simulierten produktiven Einsatzes auch kostenseitig vergleichbar zu machen. Denn Tokens haben einen Preis, und dieser sollte bei meinem standardisierten Fragekatalog miterfasst werden.

Heute sieht die Welt anders aus. Modelle mit dichtem Weltwissen können knapp und präzise antworten, nutzen dabei eine immense Denkdichte und entwickeln einen sehr großen Speicherhunger. Zum Betrieb dieser Modelle braucht es teure Rechenzentren. Kleinere, sparsamere Modelle, die auf lokalen Recheneinheiten laufen, erreichen ihre Spitzenleistung aber oft nur durch umfangreiches Denken. Sie verwerfen, hinterfragen und setzen zur Beantwortung neu an, bevor sie ein Ergebnis zusammenführen. Das produziert enorme Mengen an Denktokens, von den ersten GPT-Modellen bis zu meinem GLM 5.3 Flash. Und hier lag mein Konzeptfehler: Mein Benchmark kappte die Denktiefe. Das war ein Relikt aus der Urkonzeption. Interessant dabei ist, dass selbst ich lieber längere Kaffeepausen in Kauf nehme, um ein wirklich durchdachtes Ergebnis zu bekommen, als mich mit einer halbgaren, schnellen Antwort zufriedenzugeben, die ich später im Refactoring wieder auseinandernehmen muss.

Mein Benchmark maß also nicht die reale Modellfähigkeit auf meiner Hardware, sondern er maß das Ergebnis im Rahmen des alten Tokendeckels.

Wenn 32.000 Tokens spurlos verschwinden

Thinking-Modelle denken vor der eigentlichen Antwort. Normalerweise endet das Denken, und der Antworttext folgt. Manchmal aber hört das Denken nicht auf: Das Modell erzeugt Reasoning-Tokens ohne Ende, bis das Budget erschöpft ist. Der sichtbare Antworttext bleibt leer oder besteht aus Fragmenten, den Denk-Krümeln. Der Judge bewertet dann die Leere, und der Score stürzt auf ein bis zwei Prozent ab, obwohl das Modell die Aufgabe eigentlich beherrscht.

Der konkrete Auslöser für die Nachbesserung war das Ergebnis einer konkreten Recherche: GLM-5.3 verbrannte auf einer UX-Writing-Aufgabe das komplette Budget von 32.000 Tokens und erzielte mit der Antwort 1,05 Prozent. Der Benchmark wertete das Ergebnis technisch korrekt als Modellantwort, nur konnte das Modell gar nicht richtig antworten, da diese abgeschnitten wurde.

Eine Ausreißer-Analyse über alle versionierten Ergebnisdateien machte sichtbar, wie groß das Problem tatsächlich war: 47 Asset-Läufe über 22 Modelle erlitten messbaren Score-Schaden:

Das war kein Einzelfall, sondern systematisches Verhalten einer ganzen Modellklasse, die mein Messrahmen bis dahin fälschlich als Modellversagen deutete. Meine früheren Optimierungsversuche hatten das Problem nicht an der Wurzel gepackt:

• Ein statisches Override pro Modell erforderte Wissen, das erst aus Messungen entsteht, und wirkte dann als Sonderfall neben der Modellbeschreibung.
• Präventive Reasoning-Caps über OpenRouter deckeln auch legitimes Denken und bremsen die Modelle.
• Ein einstufiger Re-Ask mit erhöhtem Budget scheiterte bei hartnäckigen Fällen erneut am Deckel.

Keiner der drei Ansätze schrieb die gewonnene Erkenntnis zurück in die Modellbeschreibung, und so machte jeder Benchmark-Lauf dieselbe Erfahrung erneut.

Ein Update gegen das Vergessen

Nach dieser Erkenntnis habe ich eine Eskalationsleiter eingeführt. Statt eines statischen Deckels klettert ein Retry nach dem Auslösen auf die nächste Token-Verbrauchsstufe, erst 24.000, dann 32.000 Tokens. Absolute Stufen statt Multiplikatoren, damit kalibrierte Startbudgets nicht explodieren. Ausgelöst wird die Eskalation bei vier gleichzeitigen Bedingungen: Abbruch wegen Token-Limit, leerer sichtbarer Output, ein erkennbares Reasoning-Signal und fehlender Probe-Kontext (die Leiter greift nur bei echten Testaufgaben, nicht beim anfänglichen Reasoning-Check eines Modells).

Zwei Eigenschaften machen daraus Mess-Infrastruktur statt Flickwerk:

• Sie lernt. Eine erfolgreich eskalierte Stufe wandert als cot_budget_calibration in die Model Card. Der nächste Lauf startet direkt dort, statt erneut zu klettern. Die Kalibrierung gilt modulübergreifend, ist im Run-Header sichtbar und landet als CSV-Spalte in jedem Report.

• Sie trennt Messgrenze von Modellversagen. Erschöpft die höchste Stufe ohne sichtbaren Output, gibt es 0 Prozent, mit voller Traceability im Audit-Log. Der Judge bleibt strikt qualitätsbezogen und bewertet niemals die Token-Last selbst.

Ergänzt wird das durch einen Last-Resort-Modus: ein letzter Einzelversuch mit einem geöffneten Budget von 48.000 Tokens, bewusst ohne Card-Kalibrierung. Er bleibt ein dokumentierter Ausnahmefall mit Warn-Block im Report und eigenen CSV-Spalten, durch den Judge bewertbar, aber unter außergewöhnlichen Ressourcenbedingungen entstanden.

Eine letzte Lücke schloss erst der Live-Betrieb: GLM-5.3 lieferte nach 32.000 verbrannten Tokens bei einem Folgeauftritt rund 300 Zeichen Antwort-Krümel statt Leere. Damit umging es sowohl Leiter als auch Last-Resort, weil der Trigger nur auf leeren Content reagierte. Der Judge bewertete die Krümel als 1,05-prozentige Antwort. Seither gilt: Sichtbarer Output unter 500 Zeichen bei Token-Abbruch plus Reasoning-Signal zählt als Reasoning-only Truncation. Substanzieller Output ab dieser Schwelle bleibt akzeptiert. Die Vergleichbarkeit bleibt dabei gewahrt: kein Best-of-2, keine nachträgliche Notenverbesserung durch bloße Wiederholung.

Das Ergebnis der Live-Verifizierung auf dem historischen Trigger-Fall (GLM-5.3, UX-Writing, fünf Aufgaben): alle fünf Aufgaben korrekt beantwortet, im Durchschnitt 79,8 Prozent, Gesamtkosten 33 Cent. Die frühere Katastrophen-Aufgabe liegt jetzt bei 78,75 Prozent statt 1,05 Prozent, bei null Fehl-Triggern in den restlichen, gesunden Läufen. Betroffen von der ganzen Problemklasse waren 22 von 152 Modellen im Leaderboard, rund 14 Prozent. Für die große Mehrheit ändert sich nichts. Für die betroffene Minderheit ist es der Unterschied zwischen einer zufälligen Score-Katastrophe und einer nachvollziehbaren, kalibrierten Ausnahmesituation.

Ernüchterung beim Test der Top 20

Nach der Umstellung habe ich konsequent die komplette Top 20 neu getestet und dabei ein Verhalten entdeckt, das nichts mit der Tokenleiter zu tun hatte. Modelle, die in früheren Benchmarks vernünftig geantwortet hatten, sortierten sich beim erneuten Benchmarking an anderen, schlechteren Positionen ein. Das sah verdächtig nach Modell-Degradation aus.

Der entscheidende Kontrollpunkt war meine lokale Vergleichsgruppe: neun selbst gehostete Modelle, feste Gewichte, identische vLLM-Config, identischer Judge, identische Assets. Wenn die aktualisierte Messpipeline stabil läuft, müssen deren Positionen konstant bleiben. Und genau das taten sie, abgesehen von einer absoluten Abweichung von ±0,5 Punkten, die ich als reines Rauschen werte:

Die Cloud-Modelle hingegen verschoben sich im selben Zeitraum um −3 bis −4,6 Punkte. Der Unterschied zwischen beiden Gruppen war genau die eine Variable, die bei meinen lokalen Modellen nicht existiert: der Provider-Host.

Der Judge selbst, claude-haiku-4-5-20251001, blieb über alle Läufe identisch, und rund 50 Assets über alle Modelle hinweg landeten bei exakt ±0,0 Delta: identische Antworten führten zu identischen Scores. Auch das höhere Budget selbst war nicht die Ursache. Ein A/B-Kontrolltest mit drei Budgetstufen (20.000 / 25.000 / 32.000 Tokens) auf demselben Prompt reproduzierte das September-Phänomen in keiner Variante. Die Tokenleiter hat im Gegenteil die Scores gerettet statt sie zu senken, so etwa bei mimo-v2.5 reasoning_5b: von 16,0 Prozent (August-Burn ohne Leiter) auf 82,8 Prozent (mit Eskalations-Tokenleiter).

Ein Anbieter, den ich nie gewählt hatte

Als ich die ursprnglichen Tests gemacht habe, meist kurz nach Veröffentlichung eines Modells, hat mich OpenRouter noch zum Hersteller selbst geroutet. Zu diesem Zeitpunkt gab es bei vielen Open Weight Modellen noch keine alternativen Anbieter. Wochen später, haben weitere Anbieter dieselben Modelle aufgenommen, und OpenRouter routet standardmäßig zum günstigsten Anbieter. Im Wettbewerb erkauft man sich aber oftmals günstigere Preise durch angepasste Serving-Einstellungen. Und das hat das Ergebnis deutlich sichtbar verändert.

Als Lösung habe ich die Tests mit fest gesetztem Hersteller-Routing wiederholt. Und selbst dann konnte ich nennenswerte Schwankungen bei MiniMax M3 feststellen. Ob bei MiniMax M3 Servereinstellungen verändert wurden, konnte ich nicht recherchieren.

OpenRouter ist ein Gateway: Dasselbe Modell wird von wechselnden Upstream-Hosts serviert. Xiaomis Mimo-v2.5 läuft am Tag des Re-Benchmarks über sechs Hosts (GMICloud, DeepInfra, Xiaomi, StreamLake, Novita, Venice), Minimax-M3 sogar über dreizehn. Ein Host-Pinning-Test mit identischem Prompt zeigte, wie unterschiedlich diese Hosts tatsächlich antworten:

Bei einer deutschsprachigen Aufgabe streut die Sprachtreue zwischen 0,10 und 0,62, je nachdem, welcher Server zufällig geantwortet hat. Bei MiniMax M3 zeigte sich derselbe Effekt an einem konkreten Score-Einbruch: Eine CLI-Aufgabe (knapper Bash-Output erwartet) fiel von 100 auf 58 Prozent, weil CoreWeave und GMICloud den knappen Einzeiler lieferten (115 bzw. 106 Zeichen), während Venice, Together und StreamLake einen ausführlich kommentierten Block produzierten (516 bis 931 Zeichen). Identischer Prompt, identischer Benchmark-Code. Der Score-Unterschied entstand allein durch den Antwortstil des zufällig bedienenden Servers.

Claude Opus 5 und die Mauer aus Verweigerungen

Ein unabhängiges Muster betraf Claude Opus 5, und hier lag die Ursache nicht bei OpenRouter, sondern beim Anbieter Anthropic selbst. Im Logical-Reasoning-Modul (11 Assets aus Reasoning- und Metacognition-Aufgaben) stieg die Refusal-Rate bei identischen Prompts von 2 auf 8 verweigerte Antworten. Neu verweigert wurden eine Reasoning-Aufgabe (zuvor 99,2 Prozent, jetzt 0) und alle fünf Metacognition-Aufgaben (zuvor 68 bis 97 Prozent, jetzt durchweg 0). Das drückte den Modulscore von 68,6 auf 26,4 Prozent, während alle anderen Module stabil blieben (Code 81,9, Documentation 86,0). Auch das ist kein Mess- oder Budget-Effekt, sondern eine serverseitige Sicherheitsverschärfung bei Anthropic unter unverändertem Modellnamen. Es ist derselbe Ursachentyp wie bei OpenRouter, nur dass hier Anthropic selbst das Verhalten verändert hat.

Eine tiefere Analyse der Metacognition-Verweigerungen im Nachgang zeigte den exakten Auslöser. Nicht der Aufgabeninhalt, sondern die vorgegebene <thought>-Tag-Formatanweisung im Prompt löste die Verweigerung aus. Das belegte ein weiterer A/B-Test, der versionsübergreifend bei Opus 5 und 5.5 griff.

Was das für das Leaderboard bedeutet

Mit diesen drei voneinander unabhängigen, aber klar unterscheidbaren Ursachen lässt sich die Neusortierung des Scoreboards nachvollziehbar erklären:

Ein einheitlicher Judge-Shift würde alle Module gleichermaßen treffen. Genau das zeigt sich hier nicht: MiMo V2.5 verliert bei Documentation (−14,3) und Content (−11,3), während Logical Reasoning steigt (+3,3). Minimax-M3 verliert bei CLI (−9,3), während Documentation steigt (+3,3). Das Muster zeigt verändertes Antwortverhalten, nicht veränderte Bewertung.

Ich habe daraufhin im CrucibleMark das Hersteller-Pinning als Regel eingeführt, jeweils mit allow_fallbacks: false, damit ein Test fehlschlägt statt stillschweigend über einen anderen Host zu laufen. Außerdem protokolliert jetzt eine neue CSV-Spalte upstream_provider pro Request, welcher Host tatsächlich geantwortet hat. Künftige Routing-Ereignisse sind damit nachvollziehbar.

Der gepinnte Kontroll-Re-Run bestätigte die Diagnose doppelt: Unter dem Hersteller-Host verschwanden Burns, Content-Filter-Abbrüche und Sprach-Mixing vollständig, und die Scores kehrten Richtung August-Bewertung zurück. Die verbleibende Lücke ordne ich normaler Varianz zwischen zwei zeitlich auseinanderdriftenden Benchmark-Läufen plus dem Config-Delta zwischen kalibriertem 32k-Start und dem alten 20k-Cap zu.

Fazit

Mein Benchmark CrucibleMark hat in den vergangenen Monaten verschiedene Iterationen durchlaufen. Sollte er ursprünglich die Blackbox „LLM" durchleuchten und ihr Verhalten für den Beobachter nachvollziehbar machen, ist das erklärte Ziel heute, die Leistungsfähigkeit in Abhängigkeit vom gemessenen Verhalten zu ermitteln. Immer noch möchte ich wissen, welches Open Weight Modell ich als Alternative zu teuren kommerziellen Angeboten einsetzen kann.

Die Neusortierung des Leaderboards hat drei Gesichter: Sie zeigt, wo die Tokenleiter tokenhungrige Modelle endlich fair misst, wo OpenRouter-Routing die Vergleichbarkeit unterminiert, wenn man nicht explizit den Hersteller-Host erzwingt, und wo ein Anbieter selbst, hier Anthropic, sein Modellverhalten ändert, ohne dies im Modellnamen zu kommunizieren. Für mich bedeutet das: Ein Benchmark ist nie fertig kalibriert, solange die Infrastruktur darunter sich weiterentwickelt. Die Tokenleiter mit Gedächtnis und das Hersteller-Pinning sind die aktuelle Antwort auf diese Entwicklung, nicht als einmalige Reparatur, sondern im Rahmen der Evolution der Mess-Infrastruktur.