#14 · Denken ohne Experten: Ein dichtes Qwen 3.8 27B auf einer einzelnen RTX 3090

Ein dichtes Modell mit 27 Milliarden Parametern ist auf einer einzelnen Consumer-GPU normalerweise die unattraktive Wahl. Es besitzt keine Experten, die es beim Decode auslassen könnte; für jedes einzelne Token müssen sämtliche Gewichte durch die Speicherbandbreite. In unserem Budget-Rig aus eBay-Teilen hat uns das schon einmal eingeholt: Ein dichtes 27B aus einer früheren Qwen-Generation kam dort auf zwei RTX 3060 über ungefähr 18 tok/s nicht hinaus.

Qwen 3.8 27B ist ebenfalls dicht: ein Hybridmodell ohne Mixture-of-Experts. Wir haben es auf eine einzelne RTX 3090 mit 24 GB gelegt, eine Benchmarkkampagne über zwölf Konfigurationen gefahren und am Ende ein Profil in den Dauerbetrieb übernommen. Dessen Mediane liegen bei 57,31 tok/s mit kurzem Prompt und bei 58,64 tok/s mit rund 81.000 Tokens Kontext. Die zweite Zahl ist die interessantere.

Was „dicht“ auf einer einzelnen Karte kostet

Beim Decode liest ein dichtes Modell für jedes erzeugte Token seinen kompletten Gewichtssatz. Ein Mixture-of-Experts-Modell mit gleicher Gesamtgröße rührt dagegen pro Token nur einen Bruchteil davon an. Das ist der Grund, weshalb 27B dicht auf schmaler Speicherbandbreite so unangenehm ausfällt und ein 35B-MoE auf derselben Hardware davonzieht.

Gegen diesen Engpass hilft auf der Serverseite vor allem spekulatives Dekodieren. Ein schneller Draft-Pfad schlägt mehrere Tokens auf einmal vor, das Zielmodell prüft sie gesammelt. Bei korrekter Verifikation bleibt die Ausgabeverteilung des Zielmodells erhalten; beschleunigt wird nur ihre Berechnung. Für Qwen 3.8 gibt es dafür einen eigenen MTP-Drafter, den wir als vollständige externe Datei in Q4_0 laden. Damit sieht das qualifizierte Profil so aus:

Die zweite RTX 3090 derselben Maschine bedient ein anderes Modell und ist an dieser Messung nicht beteiligt. Alle Zahlen unten stammen von einer Karte.

Wie gemessen wurde

Unser kanonisches Harness fährt pro Ziel einen Warmup und drei Decode-Läufe mit je 256 Ausgabetokens. Die gespeicherten Payloads überschreiben dabei die Serverdefaults: Temperatur 1,0, top_p 0,95, top_k 0, min_p 0, keine Wiederholungsstrafe. Alle Tabellenwerte sind Mediane aus diesen drei Läufen. Wer mit anderem Sampling, anderem Prompt, anderer Cachewärme oder anderer Ausgabelänge misst, misst etwas anderes.

Ein Wort zur Beschriftung: Das „100k“-Profil heißt so, weil es der standardisierte Zielname des Messprotokolls ist. Nach Tokenisierung lagen die tatsächlichen Läufe dieses Modells bei 80.900 bis 82.000 Prompt-Tokens. Der erste kalte Prefill umfasste 80.873 Tokens und lief mit 824,96 tok/s in 98,03 Sekunden durch.

Der Lauf, der den Zuschlag bekam

Bei 81.000 Tokens Kontext decodiert dieses Profil also nicht langsamer als bei kurzem Prompt. Auffällig ist die parallele Bewegung der Akzeptanzrate: 53,3 Prozent bei kurzem Prompt, 76,3 Prozent bei langem. Der Drafter trifft mit viel Vorgeschichte deutlich häufiger richtig. Dass diese höhere Trefferquote die zusätzliche Cache-Arbeit aufwiegt, ist unsere Lesart der beiden Tabellen; einen kontrollierten Nachweis dafür haben wir nicht geführt.

Gegenüber dem ursprünglichen Ausgangsprofil mit 262k Kontext, q4-KV und dem eingebauten MTP-Drafter bei Tiefe 2 gewinnt der Short-Median 7,8 Prozent und der Long-Median 63,9 Prozent. Bezahlt wird das mit dem halbierten serverseitigen Kontextfenster: 131.072 statt 262.144 Tokens.

Der eigentliche Hebel steckt im Patchstack

Den größten Einzelbeitrag liefert die Engine, noch vor der Wahl des Drafters. Bei identischem q4-KV, 131k Kontext und eingebautem MTP-Drafter der Tiefe 4:

Bei kurzem Prompt passiert praktisch nichts, bei tiefem Kontext steigt der Median um rund 51 Prozent. Relevant sind aus den acht Patches vor allem der Ampere-MMQ-Pfad, der quantisierte-KV-Flash-Attention-Pfad, der konfigurierbare MMVQ/MMQ-Crossover und das Small-Batch-MMQ-Tuning; der Patchstack liegt öffentlich auf GitHub. Ein Hinweis für alle, die reflexhaft auf den neuesten Upstream-Stand aktualisieren: Der gepatchte Build trägt hier die kleinere Nummer.

Drei Draft-Tokens, nicht vier

Die naheliegende Annahme, ein tieferer Draft bringe mehr, hält der Messung nicht stand. Im Long-Profil akzeptierte der volle Drafter bei Tiefe 3 529 von 693 vorgeschlagenen Tokens. Tiefe 4 kam auf 520 von 969 und damit 53,7 Prozent, Tiefe 5 nur noch auf 488 von 1367 beziehungsweise 35,7 Prozent. Die zusätzlichen Draft-Schritte erzeugen mehr Rechenarbeit, als ihre Treffer einsparen.

Eine zweite Variante scheiterte an der Sprache. Ein schlankerer Testdrafter bestand alle 26 technischen Strukturprüfungen, erreichte auf unserer deutschsprachigen Testlast bei langem Kontext aber nur 388 von 1486 akzeptierten Tokens, also 26,1 Prozent. Seine Vokabularauswahl war für englischen technischen Text und Code erzeugt worden und überträgt sich auf eine deutschsprachige Last nicht ausreichend. In den Betrieb ging er nicht.

215,8 tok/s in der Sitzung, 42,74 im Benchmark

Gestapelte Spekulation aus MTP und einem N-Gram-Modul war der verlockendste Arm der ganzen Kampagne. In einer achtteiligen Datei-Editiersession stieg der Durchsatz im Mittel von 92,7 auf 215,8 tok/s, über die letzten drei Turns von 93,6 auf 230,4 tok/s. Das ist rund das 2,3-Fache, und es passt zum Mechanismus: Das Verfahren sucht die zuletzt erzeugte Tokenfolge im vorhandenen Kontext und schlägt vor, was dort darauf folgte. Eine Editiersession liefert genau solche Wiederholungen.

Im kanonischen Long-Profil fiel derselbe Arm von 58,64 auf 42,74 tok/s zurück, mit hoher Streuung. Wiederholungsreiche Prompts lösen N-Gram-Treffer aus, deren Verifikation teurer werden kann als ein gewöhnlicher MTP-Schritt. Der Modus bleibt deshalb außerhalb des Standardprofils erhalten und wird nicht automatisch gestartet. Ein Verfahren, dessen Nutzen so stark am Workload hängt, gehört in die Hand dessen, der den Workload kennt.

Was das Denken kostet

Reasoning ist bei diesem Profil standardmäßig aktiv, und die Engine liefert den Denkanteil in einem eigenen Feld reasoning_content aus, statt ihn in die Antwort zu mischen. Für kurze Antworten lässt er sich pro Anfrage abschalten:

"chat_template_kwargs": {"enable_thinking": false}

Im verifizierten Smoke-Test antwortete das Modell damit exakt mit OK. Ohne diese Option kann ein knapp bemessenes max_tokens-Budget vollständig im Denkanteil aufgehen. Ein Modell, das denkt, kann sein gesamtes Antwortbudget im Denken verbrauchen und danach nichts mehr sagen. Zwei weitere Grenzen des Profils sind praktisch ebenso relevant: Das Profil hat genau einen Slot, parallele lange Anfragen warten also aufeinander, und Eingabe plus Ausgabe teilen sich gemeinsam die 131.072 Tokens.

Was wir ausdrücklich nicht gemessen haben

Der Checkpoint, den wir qualifiziert haben, ist ein Fine-Tune namens Qwen3.8-27B-Uncensored-OrcaRouter. „Uncensored“ ist dabei die Bezeichnung des Fine-Tunes und keine Zusicherung: weder dafür, dass jede Anfrage beantwortet wird, noch dafür, dass Antworten sicher, legal oder sachlich korrekt sind. Quantisierung und Fine-Tuning können Verhalten und Faktentreue verändern.

Ein systematischer, reproduzierbarer Verhaltensvergleich zwischen diesem Fine-Tune und dem offiziellen Qwen3.8-27B liegt bei uns nicht vor. Die Kampagne hat Laufzeit, Stabilität und Durchsatz qualifiziert. Technisch beobachtet haben wir bisher nur, dass Reasoning standardmäßig anfällt, dass das Abschalten des Denkanteils die geforderte knappe Antwort erzeugte und dass die deutschen technischen Benchmarkprompts verstanden und als fortlaufende Listenaufgaben interpretiert wurden. Das ist kein Qualitäts- und erst recht kein Safety-Eval.

Ebenfalls offen bleiben: Die Qualifikation war rein textbasiert, Vision ist nicht aktiv. Tool-Schemas nimmt die Engine über das Chat-Template an, aber eine Performancekampagne ersetzt keinen vollständigen Tool-Calling-Eval. Der interne Endpunkt trägt keine eigene Authentifizierung und gehört deshalb nicht ungeschützt ins Netz. Und wer verbindlich 262k Kontext braucht, muss auf ein anderes Profil ausweichen; der hier gemessene Geschwindigkeitsgewinn gilt für 131k.

Für den kommenden Vergleich haben wir uns dieselbe Disziplin auferlegt, die bei früheren Modellen nötig war: identischer System- und Nutzerprompt, festgehaltene Modell-ID, Samplingparameter und Thinking-Modus, mindestens drei Wiederholungen bei stochastischem Sampling. Eine einzelne schöne Antwort ist ein Eindruck, keine Modelleigenschaft.

Was bleibt

Ein dichtes 27B decodiert auf einer einzelnen RTX 3090 bei 81.000 Tokens Kontext so schnell wie bei kurzem Prompt, mit 131k Kontextfenster und aktivem Reasoning. Der Gewinn kam dabei nicht aus dem Modell, sondern aus seinem Umfeld: gepatchte Engine, q4_0-KV für Ziel und Drafter, ein voller externer MTP-Drafter und eine Draft-Tiefe von drei. Vier war schon zu viel.

Über die Antwortqualität dieses Fine-Tunes können wir bislang nichts Belastbares sagen. So weit reichen die Messungen dieser Kampagne nicht; genau dort fängt die nächste an.