Qwen 3.8: Reasoning macht aus 137 Sekunden 21 Minuten

Qwen 3.8 27B brauchte 21 Minuten für ein Pelikan-SVG, das ohne Reasoning nach 137 Sekunden fertig war. Simon Willisons Praxistests legen das Kernproblem des Modells offen: nicht, ob es eine Aufgabe lösen kann, sondern ob es den nötigen Denkaufwand richtig einschätzt.

Die offizielle Model Card beschreibt ein unter Apache 2 lizenziertes Modell mit 27 Milliarden Parametern, Bildverarbeitung, Codegenerierung, Tool-Nutzung und einer maximalen Kontextlänge von 262.144 Tokens. Willison führte es als quantisierte 17-GB-Datei aus und dokumentierte die standardmäßige Reasoning-Einstellung xhigh in seinem Testbericht.

Diese Voreinstellung verlagert die Entscheidung über den Ressourceneinsatz vom Nutzer auf das Modell. Das Risiko beschränkt sich nicht auf langsamere Antworten. Routineaufgaben können dasselbe Reasoning-Budget verbrauchen wie Probleme mit mehreren voneinander abhängigen Schritten. Das ist, als würde man für die Auswahl einer Türklinke einen Architekturausschuss einberufen.

Willison testete einen 17 GB großen Q4_K_M-Build über LM Studio auf einem MacBook Pro mit M5 Max und 128 GB RAM sowie auf einem NVIDIA DGX Spark. Auf dem Spark kamen zusätzlich Durchläufe mit llama-server hinzu. Seine Prompts umfassten SVG-Erzeugung, Bounding Boxes für Bilder, den Bau eines Browser-Tools und einen Coding-Agent-Workflow mit Pi.

Pi und LM Studio hatten dabei unterschiedliche Aufgaben. Pi steuerte den Coding-Agent-Workflow, LM Studio führte das lokale Modell aus. Diese Trennung ist wichtig: Das Verhalten eines Agenten und die Leistung der Modellbereitstellung sind zwei verschiedene Schichten des Stacks.

Die Serving-Konfiguration beeinflusste die Ergebnisse, noch bevor die Ausgabequalität eine Rolle spielte. Laut Willisons Bericht verbrauchte das Reasoning selbst bei einfachen Anfragen das standardmäßige Kontextlimit von LM Studio mit 8.192 Tokens vollständig. Eine Erhöhung auf 262.144 Tokens verhinderte diesen Fehler, beseitigte aber nicht den Rechenaufwand für das Reasoning.

Mehr Kontext löste also ein Kapazitätsproblem, kein Effizienzproblem. Ein größeres Token-Budget lässt das Modell länger weiterdenken. Es belegt nicht, dass dieses zusätzliche Denken nützlich ist. Wer beide Fehlerbilder gleich behandelt, optimiert am falschen Regler.

Der deutlichste Kostenvergleich stammt aus dem Prompt mit einem Pelikan auf einem Fahrrad. Willison protokollierte mit dem standardmäßigen Reasoning 22.276 Reasoning-Tokens, 3.223 Ausgabe-Tokens und 21 Minuten Laufzeit. Ohne Reasoning erzeugte das Modell 3.715 Ausgabe-Tokens in 137 Sekunden. Willison bewertete die langsamere Variante als sein bislang bestes lokal erzeugtes Pelikan-SVG, aber nicht als gut genug, um eine etwa neunmal längere Wartezeit zu rechtfertigen.

Die Aufgabe zur visuellen Benutzeroberfläche zeigt, warum Reasoning nicht einfach überall abgeschaltet werden kann. In Willisons Test skalierte der Durchlauf mit Reasoning die Bildkoordinaten von 0 bis 1000 korrekt und zeichnete beschriftete Bounding Boxes. Allerdings fügte das Modell eine nicht angeforderte Beispielszene hinzu. Die Variante ohne Reasoning funktionierte fast, platzierte die Boxen jedoch falsch.

Beide Prompts machen das Routing-Problem sichtbar. Eine eng umrissene Generierungsaufgabe profitierte von höherer Geschwindigkeit, während die mehrstufige Implementierung zusätzliches Reasoning brauchte. Eine einzige Voreinstellung kann beide Aufgabentypen nicht effizient abdecken, weil die Kosten eines Fehlers je nach Anfrage unterschiedlich ausfallen.

Willison berichtete außerdem, dass Qwen in seinem Datasette-Projekt eine Coding-Agent-Schleife über mehrere Dateien abschloss. Das Modell erstellte und testete zudem einen Python-Konverter für das JSONL-Transkript einer Pi-Sitzung. Diese Durchläufe sind relevant, weil lokale Agenten langen Kontext, Codegenerierung und zuverlässige Tool-Aufrufe in einem Modell benötigen. Die von Qwen veröffentlichten Benchmarks weisen einen solchen vollständigen Workflow allein nicht nach.

Die Aussagekraft dieser Ergebnisse ist klar begrenzt. Wie im Testbericht von Willison dokumentiert, handelt es sich um die Prompts eines einzelnen Nutzers auf zwei Maschinen, nicht um einen kontrollierten Vergleich. Das Modell war quantisiert, die Reasoning-Konfigurationen erzeugten unterschiedliche Artefakte und die Ausgabequalität wurde anhand weniger Durchläufe bewertet. Qwens veröffentlichte Benchmark-Angaben wurden in diesem Test nicht unabhängig überprüft.

Damit können auch die gemessenen Latenzen nur begrenzt verallgemeinert werden. Sie zeigen, dass die Konfiguration das Nutzungserlebnis dominieren kann. Einen universellen Schwellenwert, ab wann sich Reasoning lohnt, liefern sie nicht. Für die Praxis heißt das: Erfolgsquote und Verzögerung müssen gemeinsam gemessen werden. Keine der beiden Größen beschreibt die Qualität für sich allein vollständig.

Auch die Bereitstellung spielt eine Rolle. Willison maß in LM Studio etwa 15 bis 30 Tokens pro Sekunde. Auf dem Spark war der Multi-Token-Prediction-Modus von llama.cpp seinen Angaben zufolge rund 72 % schneller als die standardmäßige GGUF-Konfiguration von LM Studio. Die verbleibende Begrenzung führte er teilweise auf die Speicherbandbreite zurück, da das Modell eine dichte Architektur verwendet und kein Mixture-of-Experts-Design.

Entwickler sollten den Reasoning-Aufwand deshalb pro Aufgabe steuern, statt ihn als globalen Qualitätsschalter zu behandeln. Niedrigere Einstellungen passen zu Formatierung, Extraktion und einfacher Generierung. Tieferes Reasoning ist sinnvoller für Coding-Agenten, Tool-Orchestrierung und Aufgaben, bei denen ein gescheiterter erster Versuch teurer ist als zusätzliche Latenz. Bevor geringe Geschwindigkeit allein dem Modell zugeschrieben wird, sollten außerdem Kontextlimits und MTP-Serving getestet werden.

Qwen 3.8 27B bündelt Bildverarbeitung, Coding und Tool-Nutzung in einem lokalen Open-Weight-Paket mit 17 GB. Die konkrete Frage lautet: Können Runtimes für jede Aufgabe die passende Reasoning-Tiefe wählen, damit schwierige Arbeit zuverlässig gelingt, ohne dass ein einfaches SVG 21 Minuten dauert?