Qwen3.8-27B mit Claude-Opus-Denkspuren: vier Fine-Tunes im Test, einer hält stand

Gibt es für unser Produktionsmodell Qwen3.8-27B-FP8 eine Variante mit "Claude-Denkmodus" – trainiert auf echten Opus-Reasoning-Traces statt nur auf fertigen Antworten? Ein Blick auf Hugging Face zeigt: ja, ein aktives Community-Ökosystem existiert dafür. Wir haben vier Kandidaten geprüft und den vielversprechendsten gegen unsere eigene Testbatterie laufen lassen.

Vier Kandidaten, eine Vorauswahl

Zwei der vier Projekte fielen schon bei der Durchsicht der Modellkarte durch: eines beschreibt sich selbst als unfertigen Pipeline-Validierungslauf mit nur 12,6 Prozent einer Trainingsepoche, ein zweites belegt seine Denkverbesserung nur mit gesättigten Commonsense-Benchmarks ohne Trainings-Transparenz. Ein drittes Projekt zielt gar nicht auf besseres Denken, sondern auf Zensurentfernung – die eigene Modellkarte gibt zu, dass die Code-Fähigkeit dabei von 7,9 auf 4,3 Prozent HumanEval-Score fällt.

Der vierte Kandidat, barozp/Qwen3.8-27B-Opus-Distill-v2, bestand die Vorauswahl und wurde selbst nachgebaut und getestet.

Ein gefundener und behobener Trainingsfehler

Der Werdegang des Modells ist selbst schon aufschlussreich. Ein Nutzer meldete an Version 1 einen reproduzierbaren Hänger: Gestapelte Formatvorgaben wie "keine Prosa, kein Markdown" schickten das Modell in eine endlose Selbstprüfschleife, das komplette Token-Budget verbrannt, keine Ausgabe. Der Autor fand die Ursache: 83 Prozent der Trainingsdaten waren keine echten Opus-Denkspuren, sondern nachträglich von einem Hilfsmodell erfundene Rekonstruktionen zu einer echten Opus-Antwort. Für Version 2 wurde jede nicht verifizierte Zeile durch die echte Fassung ersetzt, von 14.250 auf 11.716 Zeilen.

Wir haben genau diesen Fall an unserer eigenen Kopie nachgestellt: Version 1 hängt tatsächlich bei 3000 von 3000 Token ohne jede Ausgabe, Version 2 löst dieselbe Aufgabe in 87 von 4096 Token mit sauberem Code.

Ein eigener Testfehler, gefunden bevor die Zahl vertraut wurde

Der erste Testlauf gegen unsere 21-Aufgaben-Batterie kam auf 16 von 21 bestandenen Tests, mit zwei angeblich fehlgeschlagenen Tool-Aufrufen. Eine direkte Nachfrage zeigte: Beide Aufrufe waren korrekt. Der Fehler steckte im eigenen Testskript, das gestreamte Tool-Call-Fragmente roh aneinanderreihte und danach nach einem Teilstring suchte – wenn ein Backend wie llama.cpp einen Wert wie eine Artikelnummer über mehrere Fragmente aufteilt, landet zwischen den Teilen JSON-Syntax, und die Suche schlägt fälschlich fehl. Nach dem Fix, bei deterministischer Temperatur null, kam ein reproduzierbares Ergebnis heraus: 18 von 21, exakt der Wert, den unser Produktionsmodell selbst erreicht.

Drei echte Fehlschläge, jeweils mit gefundener Ursache

Einer der drei verbleibenden Fehlschläge ist kein Rechenfehler, sondern ein Prompting-Effekt: Eine Rabattkettenaufgabe scheitert bei der knappen Anweisung "nur die Zahl", gelingt aber garantiert, sobald explizit nach Zwischenschritten gefragt wird.

Ein zweiter Fehlschlag betrifft eine Zählaufgabe über einen stark repetitiven Text: Das Modell verbraucht bei hoher Denktiefe das komplette Token-Budget im internen Denkprozess, ohne je eine Antwort auszugeben. Das ist kein Merkmal dieses einen Modells, sondern ein bekanntes Betriebsrisiko dieser Reasoning-Einstellung bei erschöpfenden Aufgaben.

Der dritte betrifft das Abschalten des Denkens selbst: Trotz gesetztem enable_thinking:false taucht ein rohes Denk-Tag im sichtbaren Antwortfeld auf. Die erste Vermutung, das sei ein llama.cpp-Eigenheit, hielt der Nachprüfung nicht stand – derselbe Effekt trat identisch auf, als wir denselben Checkpoint im FP8-Format über dieselbe Produktionskonfiguration wie unser 27B-Modell auf vLLM liefen. Der Fehler liegt im Modell selbst: Das Fine-Tuning war durchgehend auf tiefes Denken ausgelegt, und beide Reasoning-Parser vertrauen dem Anfrage-Flag, statt die tatsächliche Ausgabe zu prüfen. Ein funktionierender Workaround: eine Systemprompt-Anweisung statt des API-Flags unterdrückt das Leck zuverlässig, bei gleichbleibend korrekter Antwort.

Freiform-Denkaufgaben: vier von fünf richtig

Auf fünf frisch gestellten, nicht in der Testbatterie enthaltenen Denkaufgaben löste das Modell vier korrekt, jeweils mit einer echten, ungefragten Selbstverifikation über einen unabhängigen Rechenweg. Der eine Fehlschlag betraf eine ungewöhnlich geformte Aufgabe mit einer impliziten Volumengleichung: Die Herleitung setzte eine Randbedingung falsch an, und die eigene Verifikation im Text prüfte nur die eigene, bereits falsche Formel gegen sich selbst – sie konnte den Fehler also nicht auffangen. Bei den vier klassisch geformten Aufgaben – Rate, Wahrscheinlichkeit, Optimierung – funktionierte die Selbstprüfung dagegen zuverlässig.

Stand jetzt

barozp-v2 ist der einzige der vier geprüften Kandidaten, der eine eigene Prüfung übersteht, mit einem noch offenen operativen Fehler vor einer Produktivnahme. Die anderen drei bleiben Beobachtungsfälle oder sind für uns nicht relevant.

Weiterführende Quellen

• Qwen3.8-27B auf Hugging Face