#14 · Eine vollwertige Office-Assistenz auf einer einzelnen GPU: Qwen 3.8 27B

27 Milliarden Parameter, ein großes Kontextfenster, aktives Reasoning: Das Modell erzeugt vor der eigentlichen Antwort erst eine Gedankenkette. Und darunter steckt eine einzelne RTX 3090 mit 24 GB. Diese Kombination läuft bei uns im Dauerbetrieb und decodiert 57,31 tok/s bei kurzem Prompt und 58,64 tok/s bei rund 81.000 Tokens Kontext.

Qwen 3.8 27B ist dabei kein beliebiges Modell dieser Größe. Artificial Analysis, ein Analysehaus, das Sprachmodelle nach einem einheitlichen Verfahren prüft und das Ergebnis zu einer einzigen Kennzahl verdichtet, führt es in seinem Intelligence Index mit 34 — und damit auf Platz eins unter 140 offen verfügbaren Modellen seiner Größenklasse, in der der Median bei 7 liegt. Die nackte Zahl sagt für sich wenig, weil sie an der Version des Index hängt; der Rang sagt viel. Stark ist es dort beim Programmieren und beim Tool-Calling, also beim Aufrufen von Werkzeugen und Systemen über definierte Schnittstellen. Das ist eine veröffentlichte Fremdeinstufung, keine eigene Messung — aber es sind genau die beiden Disziplinen, auf denen Büroautomatisierung aufsetzt. Wer Dokumente erzeugen, Systeme bedienen und strukturiert arbeiten soll, muss vor allem verlässlich Werkzeuge aufrufen können.

Es ist außerdem ein dichtes Modell, und diese Eigenschaft entscheidet darüber, ob es auf eine einzelne Karte passt. Sie wirkt in zwei Richtungen: Sie kostet Tempo, und sie macht genau die Quantisierung verkraftbar, die das Modell überhaupt erst dorthin bringt.

Der Nachteil zuerst. Dicht heißt: kein Mixture-of-Experts, also keine Experten, die beim Erzeugen eines Tokens ausgelassen werden könnten. 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.

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 Nebenpfad — der Drafter — schlägt mehrere Tokens auf einmal vor, das Zielmodell prüft sie gesammelt und übernimmt, was passt. Bei korrekter Verifikation bleibt die Ausgabeverteilung des Zielmodells erhalten; beschleunigt wird nur ihre Berechnung. Für Qwen 3.8 gibt es dafür einen Drafter nach dem MTP-Verfahren, also nach Multi-Token Prediction: der Vorhersage mehrerer Tokens in einem Schritt. Er lässt sich in zwei Fassungen betreiben, und unsere Benchmarkkampagne stellt beide gegeneinander — den eingebauten Drafter des Modells, in den Tabellen als „eingebautes MTP“, und einen vollständigen Drafter aus einer eigenen Datei. Im Dauerbetrieb läuft die eigene Datei in Q4_0.

Ein festes Paket aus Modell, Drafter, Engine und Serverflags nennen wir im Folgenden ein Profil. Das übernommene sieht so aus:

Zwei Zeilen brauchen einen Zusatz. Ein Slot bedeutet, dass der Server genau eine Anfrage zur Zeit bearbeitet. Der KV-Cache ist der Zwischenspeicher, in dem der Server den bereits gelesenen Kontext hält, damit er ihn nicht für jedes neue Token erneut durchrechnen muss; er liegt hier ebenfalls quantisiert vor, in q4_0. Die zweite RTX 3090 derselben Maschine bedient ein anderes Modell und ist an dieser Messung nicht beteiligt: Alle Zahlen unten stammen von einer Karte.

Der Ausgleich: dichte Modelle vertragen Q4

Dreimal steht in dieser Tabelle eine Vier: beim Zielmodell, beim Drafter und beim KV-Cache. Daran hängt die ganze Übung. Grob gerechnet belegt ein 27-Milliarden-Parameter-Modell bei acht Bit pro Gewicht rund 27 GB — mehr, als die Karte überhaupt hat. Bei vier Bit ist es die Hälfte, und erst dann bleibt neben dem Gewichtssatz noch Platz für den Drafter und für 131.072 Tokens Kontext.

Damit steht die naheliegende Frage im Raum, ob die Halbierung das Modell dümmer macht. Bei einem dichten Modell fällt der Verlust gering aus, und der Grund ist derselbe, der beim Decode so weh tut. Alle Gewichte werden gleichmäßig genutzt, also verteilt sich auch der Quantisierungsfehler gleichmäßig. Veröffentlichte Benchmarks liegen zwischen Q8 und Q4 bei dichten Modellen typischerweise ein bis zwei Prozent auseinander, und unsere Betriebserfahrung passt dazu: Bei einem anderen dichten 27B aus der Qwen-Reihe haben wir zwischen Q4 und Q8 keinen spürbaren Qualitätsunterschied bemerkt. Systematisch gemessen haben wir das nicht.

Bei Mixture-of-Experts-Modellen haben wir das deutlich anders erlebt. Dort entscheidet ein kleiner Router, welche Experten ein Token bearbeiten — bei MiniMax M2.5 acht von 256. Wird dieser Router ungenau quantisiert, wählt er die falschen Experten aus, und dann hilft es nichts mehr, dass die Experten selbst in Ordnung sind. Dazu kommt, dass ein einzelner Experte klein ist, bei diesem Modell rund 0,6 Milliarden Parameter, und bei drei bis vier Bit kaum noch Präzision für seine Spezialisierung übrig behält. Beides war im Betrieb zu sehen: Bei 3,28 Bit pro Gewicht befolgte MiniMax M2.5 einfache Instruktionen nicht mehr, bei 4,08 Bit verlor es den Gesprächsfaden innerhalb einer einzigen Runde.

Für die Frage, was auf eine Karte passt, ist das der eigentliche Unterschied. Ein MoE-Modell wirkt auf dem Papier wie der bessere Kandidat für knappen Speicher, weil pro Token weniger Gewichte bewegt werden — es muss aber trotzdem vollständig geladen werden und verträgt die dafür nötige Quantisierung schlechter. Das dichte 27B ist im Decode teurer und lässt sich dafür auf vier Bit eindampfen.

Wo so ein Modell bei uns schon arbeitet

Das ist für uns keine Laborfrage geblieben. Die dichte Vorgängergeneration läuft bei uns seit Monaten in Q4 im Büroalltag, und zwar dort, wo die Daten das Haus nicht verlassen sollen. Unsere Assistenz im Sekretariat entwirft damit Geschäftsbriefe und nutzt das Modell in browsergestützten Sitzungen, um Daten im CRM-System zu pflegen und herauszusuchen. Die Rückmeldung von dort: begeistert.

Das ist Betriebserfahrung und kein Benchmark — aber es sind Monate davon, an echten Aufgaben, mit einem dichten 27B in vier Bit.

Wie gemessen wurde

Alle Werte dieses Artikels stammen aus demselben Aufbau. Ein Messskript startet jede Konfiguration, schickt einen Aufwärmlauf voraus und misst danach drei Durchläufe mit je 256 Ausgabetokens; in den Tabellen erscheinen sie als TG1 bis TG3. Jede Konfiguration durchläuft dabei zwei Szenarien, die wir hier Kurzlauf und Langlauf nennen: einmal mit einem kurzen Prompt, einmal mit rund 81.000 Tokens Vorlauf im Kontext. Alle Tabellenwerte sind Mediane aus den drei Durchläufen.

Die Anfragen des Skripts bringen ihre Sampling-Parameter selbst mit und überschreiben damit die Servervorgaben: Temperatur 1,0, top_p 0,95, top_k 0, min_p 0, keine Wiederholungsstrafe. Wer mit anderem Sampling, anderem Prompt, kaltem statt warmem Cache oder anderer Ausgabelänge misst, misst etwas anderes.

Zum Langlauf gehört noch eine Anmerkung zur Buchhaltung. In unserem Messprotokoll trägt er den festen Namen „100k“ — ein standardisiertes Etikett, keine gemessene Größe. Tokenisiert lagen die tatsächlichen Läufe dieses Modells bei 80.900 bis 82.000 Prompt-Tokens. Das einmalige Einlesen eines solchen Prompts, der Prefill, umfasste beim ersten, kalten Durchlauf 80.873 Tokens und lief mit 824,96 tok/s in 98,03 Sekunden durch.

Der Lauf, der den Zuschlag bekam

Die letzte Spalte der beiden Tabellen zeigt die Akzeptanzrate: den Anteil der vom Drafter vorgeschlagenen Tokens, die das Zielmodell bei der Prüfung übernommen hat. An ihr hängt, ob sich die Spekulation auszahlt.

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 im Kurzlauf, 76,3 Prozent im Langlauf. Der Drafter trifft mit viel Vorgeschichte deutlich häufiger richtig. Dass diese höhere Trefferquote die zusätzliche Arbeit am größeren KV-Cache aufwiegt, ist unsere Lesart der beiden Tabellen; einen kontrollierten Nachweis dafür haben wir nicht geführt.

Gegenüber dem Ausgangsstand der Kampagne — 262k Kontext, q4-KV, eingebauter MTP-Drafter bei Tiefe 2 — gewinnt der Kurzlauf 7,8 Prozent und der Langlauf 63,9 Prozent. Bezahlt wird das mit dem halbierten serverseitigen Kontextfenster: 131.072 statt 262.144 Tokens.

Der eigentliche Hebel steckt in der Engine

Den größten Einzelbeitrag liefert die Engine, noch vor der Wahl des Drafters. Dafür haben wir zwei Builds von llama.cpp bei sonst gleichen Einstellungen verglichen — q4-KV, 131k Kontext, eingebauter MTP-Drafter der Tiefe 4. „Stock“ ist der unveränderte Upstream-Build, „Patch“ unser eigener Stand mit acht zusätzlichen Patches:

Bei kurzem Prompt passiert praktisch nichts, bei tiefem Kontext steigt der Median um rund 51 Prozent. Von den acht Patches sind vor allem vier relevant; sie heißen im Code Ampere-MMQ-Pfad, quantisierter-KV-Flash-Attention-Pfad, konfigurierbarer MMVQ/MMQ-Crossover und Small-Batch-MMQ-Tuning, und 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 Langlauf übernahm das Zielmodell vom vollen Drafter bei Tiefe 3 529 von 693 vorgeschlagenen Tokens, also 76,3 Prozent. 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.

Der zweite Versuch, mehr Tempo zu holen, scheiterte an der Sprache. Ein schlankerer Testdrafter bestand alle 26 technischen Strukturprüfungen, erreichte auf unseren deutschsprachigen Testprompts im Langlauf 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

Die verlockendste Konfiguration der ganzen Kampagne stapelt zwei Spekulationsverfahren übereinander: den MTP-Drafter und zusätzlich ein N-Gram-Modul. Dieses Modul sucht die zuletzt erzeugte Tokenfolge im vorhandenen Kontext und schlägt vor, was dort schon einmal darauf folgte.

In einer Datei-Editiersession über acht Runden zahlte sich das aus. Der Durchsatz stieg im Mittel von 92,7 auf 215,8 tok/s, über die letzten drei Runden von 93,6 auf 230,4 tok/s. Das ist rund das 2,3-Fache, und es passt zum Mechanismus: Eine Sitzung, in der dieselbe Datei Schritt für Schritt überarbeitet wird, liefert genau solche Wiederholungen.

Im Langlauf unseres Messskripts kehrte sich das um. Dieselbe Kombination fiel dort von 58,64 auf 42,74 tok/s, bei hoher Streuung zwischen den Durchläufen. Auch wiederholungsreiche Prompts lösen N-Gram-Treffer aus, und deren Prüfung durch das Zielmodell kann teurer werden als ein gewöhnlicher MTP-Schritt. In unserem Profil bleibt das N-Gram-Modul deshalb abgeschaltet: Es lässt sich bei Bedarf zuschalten, startet aber nicht von selbst. Ob es sich lohnt, zeigt erst ein Messlauf mit den eigenen, typischen Prompts.

Was das Denken kostet

Reasoning ist in diesem Profil standardmäßig aktiv. 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 Smoke-Test antwortete das Modell damit exakt mit OK. Ohne diese Option kann ein knapp bemessenes max_tokens-Budget vollständig im Denkanteil aufgehen — die Anfrage endet dann, bevor die eigentliche Antwort beginnt. Zwei weitere Grenzen des Profils sind praktisch ebenso relevant: Es 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

Die Kampagne hat Laufzeit, Stabilität und Durchsatz geprüft, nicht die inhaltliche Qualität der Antworten. Auch wie viel dieses Modell in Q4 gegenüber Q8 verliert, haben wir nicht gemessen; dass der Verlust bei dichten Modellen klein ist, ist breit belegt, unser eigenes Urteil dazu stammt aber aus dem Betrieb. 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 keine Prüfung der Antwortqualität und erst recht keine Sicherheitsprüfung.

Ebenfalls offen bleiben: Wir haben ausschließlich Text geprüft, Vision ist nicht aktiv. Tool-Schemas nimmt die Engine über das Chat-Template an, aber eine Performancekampagne ersetzt keine vollständige Prüfung des Tool-Callings. 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 — denn bei stochastischem Sampling kann eine einzelne gelungene Antwort schlicht Glück sein.

Was bleibt

Ein dichtes 27B mit 131k Kontextfenster und aktivem Reasoning läuft auf einer einzelnen RTX 3090 und decodiert bei 81.000 Tokens Kontext so schnell wie bei kurzem Prompt. Zwei Entscheidungen tragen das. Q4_K_M bringt den Gewichtssatz überhaupt erst auf die Karte, und weil das Modell dicht ist, kostet diese Quantisierung nach allem, was wir bisher sehen, wenig. Den Rest holt das 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.

Was wir damit nicht gezeigt haben, ist, wie gut die Antworten sind. Dafür fehlt uns noch die Messreihe; genau dort fängt die nächste an.