1. Kleine Modelle, große Denkzeit
Mit CrucibleMark teste ich LLMs seit einem Jahr in verschiedenen Disziplinen wie Code Quality, Documentation, UX Writing, Logical Reasoning und Cultural Intelligence. Dabei geht es nicht darum herauszufinden, welches Modell das mächtigste ist. Das messen anerkannte Benchmarks ohnehin viel besser. Mir geht es darum, herauszufinden, welche lokalen Open-Weight-Modelle ich einsetzen kann, um meine Alltagsaufgaben ohne großen Qualitätsverlust zu bewältigen.
Eine weitere Disziplin ist die Ermittlung des Modell-Bias bei der Beantwortung von Fragen aus Wirtschaft, Kultur und Gesellschaft. Dafür habe ich ein eigenständiges Diagnosemodul geschaffen, das sich nicht auf den Gesamtscore auswirkt, aber versucht, den Bias der Trainingsdaten anhand der Modellantworten aufzudecken. Dieses Modul ist mein Political Compass (Methodik des Political Compass).
Der Political Compass stellt 79 kalibrierte Fragen in neun thematischen Blöcken und misst zwei Koordinaten: eine wirtschaftliche Achse (links-rechts) und eine gesellschaftliche Achse (libertär-autoritär). Der Clou: Jedes Modell durchläuft das Modul zweimal, einmal im Standardmodus, einmal im Anti-Diplomat-Modus, der Ausweichrhetorik unterbindet und eine klare Positionierung erzwingt. Die erwartete Antwort ist in beiden Fällen simpel. Das Modell muss in Form eines einzelnen Buchstabens eine von vier Positionen wählen.
Diese Methodik war über zwei Jahre stabil, weil sie primär gegen große Cloud-Modelle lief. Diese reagieren selbst bei aktiviertem Reasoning ausreichend schnell und fallen nicht auf.
Für meine neue Testreihe zur Einordnung kleiner, quantisierter Modelle (4B bis 27B Parameter), die auch auf Standardhardware mit nutzbarem VRAM bis zu 24 GB laufen, habe ich llama.cpp installiert. Diese Modelle arbeiten oft mit weniger Tokens pro Sekunde und wurden zunehmend mit eigenem, internem Reasoning ausgestattet. So bekamen wir Nutzer auch in diesem Segment Thinking-Modelle, die vor der eigentlichen Antwort eine mehr oder weniger lange Gedankenkette generieren.
Der Auslöser für den Umbau meines Political Compass war ein konkreter Vorfall. Beim Test von Gemma-4-12b (gemma-4-12b-it-ud-q6_k_xl-spark) auf meinem llama.cpp benötigte ein einzelner Fragenblock rund 16.850 Sekunden für acht Fragen. Das sind etwa 35 Minuten pro Frage. Hochgerechnet auf den vollständigen, zweifach durchlaufenen Fragebogen hätte ein einziger Modell-Lauf mehrere Tage in Anspruch genommen.
Was diesen Ausschlag konkret verursachte, ließ sich erst im Nachhinein aus Server- und Client-Logs rekonstruieren. Am Ende führte die Spur auf eine einzige Frage zurück.
2. Drei Hypothesen, eine Ursachenkette
Die Diagnose folgte einem klassischen Ausschlussverfahren. Meine erste Vermutung, häufige Refusal-Retries seien schuld, ließ sich schnell widerlegen. Die beobachteten Retry-Zyklen liefen selbst schnell ab und erklärten die Zeitdifferenz nicht.
Der Blick in die Logs zeigte den eigentlichen Befund. Eine einzige Frage hatte das Modell in eine scheinbar endlose Gedankenschleife getrieben: exakt 25.000 generierte Tokens, 30,1 Minuten Rechenzeit bei etwa 14 Tokens pro Sekunde, bevor die Antwort mit einem Refusal endete. Die Frage, die dieses Verhalten auslöste:
„Sollten Unternehmen für Automation-Jobverluste zahlen?"
Eine auf den ersten Blick simple Ja-Nein-Frage, eingebettet in ein Dilemma mit vier scharf gegeneinander positionierten Antwortoptionen, von einer radikalen, gesetzlich verpflichtenden Automation-Steuer bis zu einem unverhohlenen „Survival of the fittest" für den Arbeitsmarkt. Genau die Art von rhetorisch aufgeladenem Reizthema, an dem ein Thinking-Modell lieber immer weiter abwägt, als sich schnell zu entscheiden.
Die Ursache lag tiefer und war nicht durch eine einfache Anpassung korrigierbar. Der Political Compass wurde nachträglich als eigenständiges Diagnosemodul ins Framework ergänzt, ohne je einen eigenen Budget-Eintrag zu erhalten. Weil das Modul nicht in die Bewertung einfließt, fiel diese Lücke außerdem in keiner Standardauswertung auf. Ohne explizite Budgetangabe fällt die zentrale Budget-Auflösung bei Reasoning-Modellen in einem solchen Fall auf einen Standardwert von 25.000 Tokens zurück. Dieser Wert ist für Module mit umfangreicher Textgenerierung durchaus sinnvoll gewählt, für eine erwartete Ein-Buchstaben-Antwort aber grotesk überdimensioniert.
Ein Sekundärbefund verschärfte das Bild. Das beobachtete Verhalten wirkte zunächst wie ein Refusal- beziehungsweise Alignment-Problem, war aber primär ein Truncation-Problem. Das Modell dachte lange nach und wurde schlussendlich doch in seiner Antwortfähigkeit abgeschnitten.
Drei unterschiedliche Fehlerklassen liefen bis dahin durch denselben Eskalationsmechanismus: eine tatsächliche Content-Verweigerung, ein budgetbedingter Abbruch mitten im Denkprozess und eine reine Formatabweichung ohne erkennbaren Buchstaben. Das bedeutete, jeder Retry-Versuch auf ein tatsächliches Truncation-Problem kostete erneut die volle Generierungszeit, ohne das eigentliche Problem zu adressieren.
3. Ist eine Kompass-Frage überhaupt eine Denkaufgabe?
Dies führte mich zu einer methodischen Grundfrage. Ist eine Political-Compass-Frage tatsächlich eine Reasoning-Aufgabe? Profitiert die Antwort von längerem Nachdenken, oder sollte sie eher eine erzwungene Reflexantwort sein, bei der die trainierte, unmittelbare Assoziation aussagekräftiger ist als eine vorsichtig, mehrstufig abgewogene Antwort? Der Political Compass soll die im Modell verankerte Grundhaltung sichtbar machen, nicht die Fähigkeit, ein Für und Wider abzuwägen.
Die Analyse führte mich zu einer klaren Schlussfolgerung: Ausuferndes internes Reasoning kann den Zweck des Political Compass sogar unterlaufen. Ein Modell, das sich in eine diplomatisch geglättete Zwischenposition „hineindenkt", verschleiert eher die zugrunde liegende Tendenz, als sie offenzulegen.
Aus dieser Überlegung entstand die Entscheidung gegen einen einfachen Parameter-Fix und für einen systematischen, vorgeschalteten Test. Eine eigenständige Kalibrierungsprobe, die für jedes Modell vor dem eigentlichen Lauf klärt, wie es sich unter unterschiedlichen Token-Budgets verhält.
4. Von der Budget-Zahl zur Profil-Entscheidung
Eine erste, einfache Version dieser Probe testete vier Fragen aus vier von neun Themenblöcken bei einem festen, niedrigen Budget. Das reichte nicht aus. Blockweise Ausreißer, also Themenblöcke, in denen ein Modell deutlich längere interne Gedankenketten produziert als in anderen, blieben in dieser groben Stichprobe unsichtbar.
Die überarbeitete, zweistufige Version behebt das systematisch. In einer ersten, günstigen Stufe wird pro Themenblock genau eine Frage bei niedrigem Budget getestet. Das markiert verdächtige Blöcke, ohne nennenswerte Zusatzkosten zu verursachen. In einer zweiten, gezielten Stufe werden nur die als verdächtig markierten Blöcke mit mehreren Fragen und stufenweise steigendem Budget erneut getestet.
Das Ergebnis dieser Probe ist keine einzelne Zahl mehr, sondern eine Profil-Entscheidung, die in der Modell-Konfiguration hinterlegt wird.
Ein Modell gilt als selbstlimitierend, wenn es konsistent innerhalb eines kalibrierten Budgets reagiert. Dann erhält es ein einzelnes, ressourcenschonendes Profil. Ein Modell gilt als inkonsistent, wenn sein Terminierungsverhalten stark zwischen den Themenblöcken schwankt. Für dieses Modell wird ein Hybrid-Profil angelegt, das sowohl einen Thinking- als auch einen Instruct-Lauf vorsieht, deren Differenz zusätzlich Aufschluss darüber gibt, ob internes Reasoning die gemessene Position überhaupt verschiebt. Ein Modell gilt als durchgängig ausufernd, wenn es in keinem getesteten Budget-Rahmen zuverlässig reagiert. Hier wird von vornherein auf ein reines Instruct-Profil umgestellt.
Ein Randbefund aus der Probe-Kampagne verdient besondere Erwähnung, weil er die Grenzen von Automatisierung illustriert. Das Modell Ornith 1.5 wurde von der Probe als Hybrid-Kandidat eingestuft, verfügt aber gar nicht über einen separaten Instruct-Modus. Die Konsequenz daraus ist eine feste Regel: Die Profil-Empfehlung der Probe ist eine Empfehlung, keine Garantie. Sie muss immer gegen die tatsächliche technische Fähigkeit des jeweiligen Modells geprüft werden, bevor sie umgesetzt wird.
5. Die unbequeme Konsequenz
Der zentrale Wendepunkt in diesem Umbau ist keine technische, sondern eine methodische Erkenntnis. Die Anpassung von Token-Budget und Temperatur-Verhalten verändert nicht nur die Messbedingungen für das auffällige Modell, sondern für jedes Modell, das je durch den Political Compass gelaufen ist. Ein stiller Parameter-Fix hätte bedeutet, dass neue und alte Ergebnisse im selben Leaderboard nebeneinanderstehen, ohne dass sie unter denselben Bedingungen erhoben wurden. Diese Art Inkonsistenz wollte ich vermeiden.
Die Konsequenz war deshalb kein Patch, sondern ein Versionssprung. Das Modul wurde zum Teil neu geschrieben, die Modul-Version wurde angehoben. Ebenso die Batch-Kennung, unter der Ergebnisse im System referenziert werden. Ältere Zwischenergebnisse (Checkpoints) wurden über diese Versionsänderung automatisch invalidiert, damit kein Resume-Mechanismus versehentlich Daten aus der alten Methodik in einen neuen Lauf hineinmischt. Damit war klar: Alle bisherigen Political-Compass-Ergebnisse müssen unter der neuen Methodik erneut erhoben werden, um vergleichbar zu bleiben.
6. Der Umbau zu Version 3.0
Aus der Diagnose ergaben sich sechs konkrete, ineinandergreifende Änderungen.
Ein eigenes, knappes Modul-Budget. Political Compass erhielt einen eigenen Budget-Wert, deutlich unter dem allgemeinen Reasoning-Fallback, ohne den sonst üblichen Multiplikator für Reasoning-Modelle. Wichtig dabei: Das Budget wirkt als Mindestwert, nicht als starre Obergrenze. Ein höher angefordertes Budget, etwa bei einem gezielten Nachfrage-Versuch, darf den Modul-Wert überschreiten.
Eine Vier-Stufen-Antwortklassifikation. Statt einer einzelnen Ablehnungs-Erkennung unterscheidet das System jetzt explizit zwischen einer eindeutigen Antwort, einer budgetbedingten Truncation, einer erkennbaren Content-Verweigerung und einer reinen Formatabweichung. Jede dieser vier Kategorien erhält eine eigene, angemessene Reaktion, statt pauschal in denselben Eskalationsmechanismus zu laufen.
Getrennte Retry-Strategien je Lauf-Typ. Im Standardlauf gilt eine erkennbare, echte Ablehnung als valider Messwert. Sie wird nicht mit Temperatur-Eskalation „weggedrückt". Nur im Anti-Diplomat-Lauf, der explizit auf erzwungene Positionierung ausgelegt ist, bleibt die Eskalationsleiter (steigende Temperatur plus verstärkender Systemzusatz) bestehen.
Eine Coverage-Regel, formuliert vor der Datenerhebung. Für den Fall, dass ein Thinking-Modell trotz kalibriertem Budget in einzelnen Themenblöcken stark unterschiedlich ausfällt, wurde eine feste Abbruchregel definiert, basierend auf einer kumulativen Verlustquote und einer möglichen Konzentration der Ausfälle auf eine der beiden Kompass-Achsen. Diese Regel wurde bewusst formuliert, bevor die entsprechenden Live-Daten vorlagen, um eine nachträgliche Rechtfertigung auszuschließen.
Eine transparente Ergebnis-Attribution. Wird wegen der Coverage-Regel ein Ersatzlauf mit anderem Profil nötig, läuft dieser unter einer eigenen technischen Kennung. Sein Ergebnis wird aber unter der ursprünglichen Modell-Identität im Leaderboard geführt, mit einem offen sichtbaren Kennzeichen, dass hier ein Profilwechsel stattgefunden hat. Der zuerst erhobene, unvollständige Thinking-Lauf wird dabei nicht verworfen, sondern als eigenständiger, diagnostisch wertvoller Teildatensatz archiviert.
Ein erweiterter Bias-Report. Statt eines binären wurde wiederholt: ja/nein dokumentiert der Report nun die genaue Eskalationsstufe, die verwendete Temperatur, den auslösenden Trigger und die Token-Verteilung zwischen Standard- und Anti-Diplomat-Lauf. Und das für jede einzelne Frage.
7. Der Live-Test der eigenen Regeln
Die Coverage-Regel wurde nicht nur formuliert, sondern auch tatsächlich angewendet. Bei mindestens einem Modell in der Kalibrierungskampagne zeigten sich deutlich unterschiedliche Verlustraten zwischen Themenblöcken, teilweise konzentriert auf eine der beiden Kompass-Achsen. Die Reaktion darauf war keine Ad-hoc-Entscheidung, sondern die Anwendung der zuvor fest definierten Regel: Umstellung auf ein Instruct-Ersatzprofil, mit dem ursprünglichen Thinking-Teillauf als dokumentiertem Zusatzdatensatz. Damit erhält der Political Compass eine neue Methodik, die vor dem Benchmark feststeht, statt Einzelfallkorrekturen.
8. Langsam und aussagekräftig
Die lokalen Benchmark-Läufe kleiner Modelle laufen inzwischen mit erheblich reduzierter, aber nachvollziehbar akzeptabler Dauer. Kein einzelner 30-Minuten-Ausreißer pro Frage mehr. Die benötigte Zeit korrespondiert wieder mit der tatsächlichen Modellgröße und Inferenzgeschwindigkeit, nicht mit einer Konfigurationslücke. Das ist der eigentliche Erfolg dieses Umbaus. Nicht, dass jetzt alles schneller läuft, sondern dass die gemessene Zeit wieder etwas über das Modell aussagt.