Qwen3.8-27B ist das Modell, auf das ich lange gewartet habe. Die Community feierte es sofort als lokalen Klassenprimus. Endlich fühlten sich die Antworten rund an, es erkennt den Kontext und liefert fast immer das erwartete Ergebnis. Nur eines nervt im Alltag: Für dieses Ergebnis braucht es eine lange Denkphase mit viel Tokenoutput, und wenn's mal schnell gehen soll, kostet das viel Zeit. Und wenn mich etwas stört, suche ich nach Abhilfe.
Der Wunsch zur Optimierung
Angefangen hat diese Geschichte mit einer simplen Beobachtung. Mein neues Alltagsmodell lief auf meinem Asus GX10 (Spark-Supercomputer) anfangs mit einem Peak von etwa 20 bis 24 Token pro Sekunde. Das ist nicht schnell, aber ok, bedenkt man das Ergebnis. Nur braucht es für dieses Ergebnis eine deutliche Denkphase mit hohem Tokenausstoß. Also wartete ich auf das nächste vLLM-Update und hoffte auf mehr Tempo.
Und tatsächlich tat sich etwas. Auf einer gepatchten Version 0.28.1-rc1 schoss der Peak zwischenzeitlich auf bis zu 40 Token pro Sekunde, ein echter Ausreißer nach oben. Mit dem aktuellen, stabilen 0.29.0 pendelt sich der Peak bei 34 bis 38 Token pro Sekunde ein. Spürbar besser als am Anfang, aber leicht unter dem kurzen Zwischenhoch. Nicht jedes Update der vLLM-Engine oder der NVIDIA-Treiber bringt Verbesserung. Diesmal war es eher ein Auf und Ab.
Und selbst diese 34 bis 38 Token pro Sekunde sind nur der Spitzenwert. Mein Dashboard mittelt ohnehin nur über ein 5-Sekunden-Fenster, der reale Durchschnitt über eine ganze Denkphase liegt spürbar darunter. Bei Qwen3.8-27Bs Denkleistung bleibt der gefühlte Geschwindigkeitszuwachs also moderat. Umso mehr freute mich die Nachricht vom ersten Fine-Tune mit optimiertem Tokenverbrauch, einer Optimierung, die genau diese Schwäche ausgleichen sollte, ohne die Qualität zu verschlechtern.
Drei Kandidaten, eine Hoffnung
Zuerst probierte ich den Uncensored-Quant von OrcaRouter, eine abliterated Version von Qwen3.8-27B, bei der gezielt die Refusal-Mechanismen aus den Gewichten entfernt wurden. Ich wollte wissen, ob so ein Alignment-Eingriff nebenbei auch das Tokenverhalten verändert. Modell laden, auf meine Umgebung optimieren, testen. Das Ergebnis überzeugte nicht genug für einen Wechsel.
Meine große Hoffnung hieß danach Signal 3.8 27B von AgentionAI, explizit als Reasoning-Effizienz-Fine-Tune von Qwen3.8-27B beworben. Andere hatten das Problem also auch bemerkt und arbeiteten an einer Lösung. Ich lud das Modell, optimierte es auf meine Hardware und maß die Ergebnisse. Auch hier blieb der erhoffte Sprung aus.
Eine Woche später fiel mir Swift-Qwen3.8-27B-NVFP4 von UkisAI auf HuggingFace auf. Die Quantisierer sprachen mit einer eindrucksvollen Grafik von über 50 % weniger Thinking-Tokens und entsprechend schnelleren Antwortzeiten. In ihren X-Beiträgen feierten sie das Modell mit ihrer Community, fast wie einen Befreiungsschlag gegen Qwens Overthinking-Problem. Genug Motivation für einen dritten Anlauf. Auch dieses Ergebnis brachte keinen Fortschritt. Übrig blieb nur die Erkenntnis, dass lautes Marketing auf X zumindest Aufmerksamkeit bringt.
Mein Setup zur Einordnung
Jetzt stellt sich die Frage, wie ich zu meinem Ergebnis komme. Bevor ich überhaupt ein Urteil fälle, durchläuft jedes neue Modell dieselbe Prozedur. Auf meinem Asus GX10 übernimmt mein Hermes-Agent das komplette Setup mit vLLM (alternativ auch llama.cpp), voll automatisiert. Er fährt Smoke-Tests, variiert systematisch Parameter wie Temperatur, MTP-Speculative-Decoding-Werte und Batch-Größen und misst dabei die erzielte Tokens-pro-Sekunde-Rate gegen die Antwortqualität. Das Ziel bleibt immer gleich: die schnellste TPS-Zahl bei gleichbleibender Qualität finden.
Die Messwerte bekommt Hermes über mein Dashboard, das zur Laufzeit verschiedene Werte der Maschine und der Inferenz ausgibt. So kann er die Modelleinstellungen optimieren und gleichzeitig die Auswirkungen auf LLM und Umgebung überwachen. Ein vollständiger Tuning-Durchlauf dauert realistisch zwischen einer halben und einer Dreiviertelstunde. Bei komplexeren Architekturen wie Swifts Hybrid-Attention-Setup dauert es deutlich länger, weil einzelne Sweep-Stufen bei kaltem Cache über 900 Sekunden brauchen können, bevor der Watchdog eingreift.
Für Swift-Qwen3.8-27B-NVFP4 lief das Tuning über vier Sweep-Stufen: Speculative-Tokens, maximale parallele Sequenzen, Batch-Größe und GPU-Speicherauslastung. Der beste Fund: num_speculative_tokens=5 statt Qwen3.8-27Bs Standardwert von 3. Diese Einstellung brachte im Sweep ein Plus von 6 % TPS gegenüber dem niedrigsten getesteten Wert.
Der erste Dämpfer
Dann kam der erste A/B-Test gegen meinen Daily-Driver Qwen3.8-27B, einen Unsloth-Quant. Das Ergebnis war nicht berauschend. Klar, ein Modell performt auf einem Spark-Prozessor anders als auf einer RTX PRO 6000 Blackwell. Trotzdem musste der viel beworbene Leistungszuwachs doch irgendwie spürbar werden.
Bei meinem Test brach die TPS-Rate gegenüber dem Unsloth-Quant aber regelrecht ein, von einer Steigerung keine Spur. Beim Single-Stream war Swift-Qwen3.8 bei kurzen Prompts 15,8 % langsamer, bei langen Prompts sogar 30,5 % langsamer als mein reguläres Setup. Selbst unter Last mit vier parallelen Streams, meiner typischen Hermes/KiLo-Alltagslast, blieb Swift-Qwen3.8-27B bei mittellangen Prompts fast 38 % zurück.
Die TPS-Rate ist aber nur die eine Seite der Medaille. Über 50 % Tokenersparnis hätte den Geschwindigkeitsverlust schließlich noch kompensieren können. Das Ergebnis war ernüchternd: Über alle Prompt-Klassen hinweg produzierte das Modell nur 3,8 % weniger Token, viel zu wenig, um die gesunkene TPS-Rate auszugleichen. Ein Ergebnis fehlte noch: die Qualitätsmessung im Benchmark.
Der zweite Dämpfer
Auch hier blieb die Überraschung aus. Im CrucibleMark-Leaderboard landete Swift auf Rang 14 im Silber-Bereich, während mein Daily-Driver nach der vLLM-Optimierung auf Rang 3 im Gold-Bereich liegt. Nur 2,27 Punkte Rückstand im Gesamtscore, aber ein Qualitätseinbruch, den ich zum Geschwindigkeitseinbruch nicht auch noch tolerieren will. Der Rückstand verteilt sich zudem nicht gleichmäßig. Ausgerechnet im ToolUse-Modul, für Agentic-Workflows in dieser Gewichtsklasse eine der wichtigsten Fähigkeiten, verliert Swift-Qwen3.8 fast 13 Punkte gegenüber dem Unsloth-Qwen3.8. Da fällt kaum noch ins Gewicht, dass es auch bei Code Quality und Logical Reasoning spürbar abfällt.
Nur in einer Kategorie glänzt Swift-Qwen gegenüber meinem Daily-Driver wirklich: im CLI-Test. Hier erzielt es 95 von 100 Punkten, deutlich mehr als Qwen3.8-27Bs 79,67 Punkte. Doch schon 80 Punkte bescheinigen einem Modell eine gute CLI-Fähigkeit, also relativiert sich auch dieses Plus.
Mein Fazit nach den drei Versuchen: Weder das Uncensored-Modell noch Signal 3.8 27B noch Swift-Qwen3.8 konnten das Versprechen einlösen, Qwen3.8-27B in dieser Gewichtsklasse abzulösen. Das kaum merkliche Kürzen des Denkmarathons konnte den Substanzverlust in den anderen Kategorien nicht aufwiegen. Zumindest nicht auf meiner Hardware.
Ein Modell, aber zwei Welten
Und damit kommen wir zum Kern der Sache. UkisAI hat Swift auf einer NVIDIA RTX PRO 6000 Blackwell entwickelt und optimiert, einer Workstation-Karte mit 96 GB dediziertem GDDR7-Speicher und rund 1,8 TB/s Speicherbandbreite. Mein Asus GX10 dagegen läuft mit dem GB10-Superchip von NVIDIA: 128 GB LPDDR5x als unified memory, geteilt zwischen CPU und GPU, mit gerade einmal etwa 273 GB/s Speicherbandbreite.
Das ist kein kleiner Unterschied, das ist Faktor 6,5. Eine RTX PRO 6000 kann Modellgewichte und KV-Cache so schnell durch den Speicher schaufeln, dass sich zusätzliche Speculative-Decoding-Drafts (Swifts MTP=5) ganz anders auszahlen. Die Validierung der Extra-Tokens kostet dort kaum Zeit, weil genug Bandbreite übrig bleibt. Auf dem Spark ist genau diese Bandbreite der Flaschenhals. Jeder zusätzliche Draft-Validierungs-Zyklus konkurriert um dieselbe schmale Datenleitung wie das eigentliche Decoding. Was auf der Workstation-Karte Zeit spart, kostet auf dem Spark zusätzliche Zeit.
Das erklärt auch, warum UkisAIs Zahlen (bis zu 58 % weniger Tokens und x1,95 Geschwindigkeitszuwachs) auf meiner Hardware nicht nur ausbleiben, sondern sich ins Gegenteil verkehren. Das ist kein Marketing-Bluff. Es ist ein Hardware-Kontext, der in meiner Prozessorklasse schlicht nicht mitgeliefert wird. Meine Konsequenz: Bei zukünftigen Fine-Tune-Versprechen frage ich künftig zuerst, auf welcher Hardware das Ergebnis gemessen wurde, und ob mein Setup davon überhaupt profitiert.
Was am Ende bleibt
Nach diesem Ausflug bleibt die Erkenntnis, mit dem zufrieden zu sein, was ich bereits nutze. Qwen3.8-27B ist eben ein bisschen redseliger beim Denken, aber am Ende verlässlich in genau den Kategorien, die für mich zählen. Die Alibaba-Techniker haben ihr 27B-Modell offensichtlich bereits sehr nah ans Optimum für diese Gewichtsklasse gebracht. Der Thinking-Overhead ist kein Konstruktionsfehler. Er ist der Preis dafür, dass ein vergleichsweise kleines Modell auf dem Niveau eines Opus 4.6 performt, einem deutlich größeren, proprietären Frontier-Modell des Vorjahres.