Davidmg0815/Qwen3.8-27B-MTP-GGUF

Qwen3.8-27B GGUF — mit separatem MTP-Draft

GGUF-Konvertierung von Qwen/Qwen3.8-27B, gebaut aus den BF16-Originalgewichten. Der Grund für dieses Repo ist die Datei qwen3.8-27b-MTP-Q8_0.gguf: der Multi-Token-Prediction-Kopf als eigenständiges Draft-Modell, direkt nutzbar mit --spec-type draft-mtp.

Die MTP-Gewichte stecken im Upstream-Checkpoint (mtp_num_hidden_layers in der config.json), werden von den üblichen GGUF-Repos aber nicht als getrennte Datei ausgeliefert — und ohne getrennte Datei kann llama-server sie nicht als Draft laden.

Dazu kommt, was dieses Repo von einer reinen Formatkonvertierung unterscheidet: alle Zahlen unten sind auf derselben Maschine selbst gemessen, mit offengelegtem Messgerüst unter bench/ und protokollierten Fehlern in METHODIK.md.

---

Was drei RTX 3080 leisten

Der Aufbau ist bewusst unspektakulär: drei gebrauchte RTX 3080 mit je 20 GB, zusammen 60 GB VRAM, an einem EPYC 7F32 mit acht Kernen. Keine H100, keine NVLink-Brücke, Ampere von 2020. Was dabei herauskommt:

	Ergebnis	Bedingungen
MATH-500	98,0 %	150 Aufgaben, Q8_0, ein Durchlauf, 24k Budget
HumanEval+	88,4 – 90,2 %	164 Aufgaben, mit Ausführung geprüft
Tempo, Denktext	54,7 t/s	Q8_0 mit MTP-Draft
Tempo, Fließtext	39,5 t/s	Q8_0 mit MTP-Draft
Kontext	262.144 Token	voller trainierter Kontext, KV-Cache q8_0
Belegt	31,2 von 60 GB	Modell 27,3 + Draft 2,7 + KV/Puffer

Ein 27B-Modell in Q8_0 — also praktisch ohne Qualitätsverlust gegenüber den Originalgewichten, siehe unten — läuft hier mit vollem trainiertem Kontext und lässt noch die Hälfte des Speichers frei. Der Engpass auf so einer Karte ist nicht die Rechenleistung, sondern die Speicherbandbreite: für jedes einzelne Token müssen sämtliche Gewichte einmal durch den Speicher. Genau da setzt der MTP-Draft an, und genau deshalb liegt der Rest dieser Seite auf Messungen statt auf Versprechen.

Dateien

Datei	Größe	BPW	Zweck
qwen3.8-27b-Q8_0.gguf	27,3 GB	8,50	Zielmodell — empfohlen
qwen3.8-27b-Q6_K.gguf	21,0 GB	6,57	kleinere Alternative
qwen3.8-27b-MTP-Q8_0.gguf	3,0 GB	—	MTP-Draft für spekulatives Dekodieren
qwen3.8-27b-mmproj-F16.gguf	0,9 GB	—	Vision/Video-Projektor

Die MTP-Tensoren sind aus den Zielmodellen entfernt (--no-mtp) und liegen ausschließlich in der Draft-Datei. Ziel- und Draft-Datei gehören zusammen.

Welches Zielmodell? Q8_0 ist das genauere, Q6_K das schnellere. Ohne Draft, gleiche Einstellungen: Q6_K 23,7 t/s gegen Q8_0 19,6 t/s — Q6_K liegt 21 Prozent vorn, weil 21 GB nun mal schneller gelesen sind als 27 GB. In der Qualität ist zwischen beiden nichts nachweisbar (siehe unten), die Wahl ist also eine reine Tempofrage.

Verwendung

llama-server \
  -m qwen3.8-27b-Q8_0.gguf \
  --mmproj qwen3.8-27b-mmproj-F16.gguf \
  -md qwen3.8-27b-MTP-Q8_0.gguf \
  --spec-type draft-mtp --spec-draft-n-max 3 --spec-draft-ngl 99 \
  --ctx-size 97000 --parallel 1 \
  --n-gpu-layers 99 --tensor-split 1,1,1 \
  --cache-type-k q8_0 --cache-type-v q8_0 \
  --flash-attn on --jinja

Ohne Spekulation einfach -md und die drei --spec-*-Schalter weglassen. Ohne Bildeingabe zusätzlich --mmproj weglassen.

Denktiefe steuern. Qwen3.8 kennt genau drei Stufen — low, medium, xhigh — und xhigh ist zugleich die Voreinstellung. Ein high gibt es nicht; die Chat-Vorlage verwirft unbekannte Werte still. Gesetzt wird es je Anfrage:

{"chat_template_kwargs": {"reasoning_effort": "xhigh"}}

Zum Abschalten genügt weder ein /no_think im Prompt noch ein enable_thinking auf oberster Ebene der Anfrage — beides wird ignoriert. Es muss in chat_template_kwargs stehen:

{"chat_template_kwargs": {"enable_thinking": false}}

---

Was MTP tatsächlich bringt

Beide Läufe mit identischer Konfiguration (Q8_0, 97K Kontext, eine Session), einziger Unterschied ist das Draft-Modell. Deutsche Prompts, je 2–3 Durchgänge, ausgewertet wird der Median. Die Zahlen kommen aus timings.predicted_per_second bzw. timings.draft_n / draft_n_accepted, die llama-server pro Anfrage selbst meldet.

Textsorte	ohne Draft	mit Draft	Faktor	Draft-Trefferquote
Denktext (Reasoning)	19,6 t/s	54,7 t/s	2,79×	—
Wiederholung	22,9 t/s	62,0 t/s	2,71×	85,0 %
Aufzählung	23,0 t/s	61,6 t/s	2,68×	93,1 %
Übersetzung	22,9 t/s	51,8 t/s	2,26×	70,9 %
Struktur / JSON	23,0 t/s	47,6 t/s	2,07×	59,7 %
Fachtext	23,0 t/s	41,7 t/s	1,81×	48,0 %
Code	23,0 t/s	41,1 t/s	1,79×	48,9 %
Fließtext	22,9 t/s	39,5 t/s	1,72×	44,5 %
Kreativtext	23,0 t/s	35,9 t/s	1,56×	37,4 %

Gesamt über die acht Textsorten: 57,3 % Trefferquote (4.491 von 7.842 Draft-Token).

Der wichtigste Befund

Ohne Draft ist die Rate völlig flach — 22,9 bis 23,0 t/s, egal was man generiert. Mit Draft spreizt sie sich um Faktor 1,7 auseinander, weil die Trefferquote massiv an der Textsorte hängt: vorhersagbarer Text wird zu über 90 Prozent korrekt geraten, freier Kreativtext nur zu gut einem Drittel.

Wer MTP an einem Aufzählungs-Benchmark misst, kommt auf 2,7× und überschätzt den Nutzen für normale Chatlast deutlich. Der realistische Wert für Fließtext-Dialog liegt bei rund 1,7×.

Denktext ist der große Gewinner. Die oberste Zeile stammt aus dem MATH-500-Lauf mit vollem Reasoning und ist mit 2,79× der höchste gemessene Wert überhaupt. Schrittweises Rechnen ist offenbar außerordentlich gut vorhersagbar. Das ist praktisch relevant, weil Reasoning-Modelle den Großteil ihrer Token im Denkteil verbrauchen — genau dort, wo der Draft am besten trifft.

Was der Draft kostet

• 3,0 GB auf der Platte
• rund 2,7 GB VRAM ([spec] estimated memory usage of draft model is 2678.78 MiB bei 97K Kontext; 1.953 MiB bei 4K)
• Ladezeit steigt kaum — 7 bis 27 Sekunden je nach Kontextgröße

Deutlich mehr als etwa der Gemma-4-12B-Draft mit 0,5 GB. Wer knapp an VRAM ist, muss das einplanen.

---

MATH-500: 98,0 % in einem Durchlauf

150 Aufgaben, gleichmäßig über den Datensatz gegriffen (MATH-500 ist nach Thema sortiert, die ersten 150 wären fast nur Precalculus). Q8_0, reasoning_effort: xhigh, Budget 24.000 Token je Aufgabe, MTP-Draft aktiv.

Ergebnis: 147 von 150 = 98,0 %. Ein Durchlauf, ein Budget, keine Nachmessung.

Stufe	richtig
L1	8/8
L2	32/33
L3	36/36
L4	35/35
L5	36/38

Median 53,3 Token/s, im Schnitt 1.890 Token je Aufgabe, eine einzige Aufgabe lief ins Limit.

Die drei Ausfälle, einzeln aufgemacht

Aufgabe	geliefert	erwartet	was es wirklich ist
intermediate_algebra/558 (L5)	3<\lambda\le 4	(3,4]	dieselbe Menge, andere Notation
number_theory/410 (L2)	0{,}35625	.35625	dieselbe Zahl, LaTeX-Gruppierung
intermediate_algebra/1350 (L5)	(nichts)	14	volle 24.000 Token, keine Antwort

Zwei der drei sind Artefakte des Antwortvergleichs, kein Rechenfehler. Über alle 150 Aufgaben hinweg hat dieser Lauf kein einziges falsches Ergebnis geliefert — entweder stimmte die Antwort, oder es kam gar keine.

Die beiden Notationsfälle sind inzwischen im Vergleicher abgedeckt (mit Gegenproben, die weiterhin falsch bleiben müssen: (3,4] gegen 3\le\lambda\le 4 unterscheidet sich im Randverhalten und zählt weiter als Fehler). Die 98,0 % oben sind trotzdem die unbereinigte Zahl, gemessen mit dem Vergleicher, der zur Laufzeit aktiv war. Bereinigt wären es 149/150.

Es war das Budget, nicht das Können

Dieselben 150 Aufgaben, dasselbe Modell, dieselben Einstellungen — nur das Token-Budget unterscheidet sich:

Budget	richtig	am Limit
8.000 Token	138 / 150 = 92,0 %	10
24.000 Token	147 / 150 = 98,0 %	1

Sechs Prozentpunkte, ohne dass das Modell etwas anders gerechnet hätte. Der Grund steckt in der Verteilung des Token-Bedarfs:

	Token je Aufgabe
Median	610
75. Perzentil	1.563
90. Perzentil	5.384
darüber	bis über 14.000

Eine Vorabmessung an zwölf Aufgaben ergab ein Maximum von 4.274 Token — im 8.000er-Lauf lagen 20 von 150 darüber. Aus einer kleinen Stichprobe lässt sich das nötige Budget nicht ableiten. Wer MATH-500 mit knappem Limit fährt, misst, ob der Rechenweg ins Budget passt, nicht ob das Modell rechnen kann.

Die vollständige Aufarbeitung der Fehlschläge aus dem 8.000er-Lauf — mit Aufgabentext, Musterlösung und gelieferter Antwort — steht in FEHLERANALYSE.md.

Reasoning bringt auf MATH-500 nichts

Derselbe Lauf noch einmal, mit enable_thinking: false, gleiches Budget:

Lauf	richtig	Token je Aufgabe	am Limit
Reasoning xhigh, 24k	147 / 150 = 98,0 %	1.890	1
ohne Reasoning, 24k	146 / 150 = 97,3 %	1.431	0

Gepaart ausgewertet (beide Läufe bearbeiten dieselben Aufgaben, nur die diskordanten Paare tragen Information):

exakter McNemar:  4 : 3   p = 1,0000

Vier Aufgaben löst nur der Reasoning-Lauf, drei nur der andere. Das ist exakt das, was Zufall produziert. Bei ausreichendem Budget ist auf MATH-500 kein Reasoning-Effekt nachweisbar — der Denkmodus kostet hier 32 Prozent mehr Token für nichts.

Das korrigiert eine frühere Behauptung dieser Seite. Wir hatten „+16 Punkte durch Reasoning" berichtet. Dieser Vergleich war wertlos: der Lauf ohne Reasoning bekam damals 1.600 Token, der mit Reasoning 8.000. Gemessen wurde also der Budget-Unterschied, nicht der Denkmodus. Bei gleichem Budget bleibt davon nichts übrig.

Ein qualitativer Unterschied bleibt allerdings sichtbar: der Reasoning-Lauf lieferte über 150 Aufgaben kein einziges falsches Ergebnis, der Lauf ohne Reasoning zwei (3 statt 6, und eine Antwort, die sich nicht extrahieren ließ). Die Quoten sind gleich, die Fehlerarten nicht.

Einordnung gegen publizierte Werte

Vorab die wichtigste Auskunft: MATH-500 ist bei den Spitzenmodellen weitgehend ausgemustert. Der Datensatz gilt als gesättigt, und die großen Labore berichten stattdessen AIME, HMMT oder HLE. Für Claude Opus 4.6 und Grok 4.2 existiert keine MATH-500-Zahl; was dort kursiert, sind Werte für andere Datensätze.

Modell	MATH-500	Quelle
DeepSeek-R1	97,3 %	offizielles R1-Paper
Gemini 3 Pro	96,4 %	vals.ai, eigenes Gerüst
Qwen3.8-27B Q8_0 — diese Messung	98,0 %	hier, 150 von 500 Aufgaben
Llama 4 Maverick (400B)	88,1 %	nur Sekundärquellen

Diese Zeilen sind nicht gegeneinander aufrechenbar. Drei Gründe, jeder für sich groß genug, um die Reihenfolge zu drehen:

1. Anderer Grader. vals.ai bewertet mit der Parserlogik aus PRM800K, wir mit einem eigenen Antwortvergleich. Wie groß dieser Effekt ist, wissen wir aus eigener Erfahrung ziemlich genau: allein die Reparatur unseres Vergleichs hat vier bis sechs Prozentpunkte gebracht, ohne dass ein einziges Modell etwas anders gerechnet hätte.
2. Anderer Umfang. 150 gleichmäßig gegriffene Aufgaben gegen die vollen
3. Unbekanntes Token-Budget. Bei uns fallen zehn Aufgaben allein deshalb durch, weil das Denken nicht ins Budget passte. Wie die anderen damit umgehen, steht nirgends.

Für Llama 4 kursieren zudem widersprüchliche Werte (Behemoth mal 92,4, mal 95,0) — ein Zeichen, dass hier von Sekundärquelle zu Sekundärquelle abgeschrieben wird. Die Zeile steht deshalb unter Vorbehalt.

Was man trotzdem ablesen kann: ein 27-GB-Modell auf drei gebrauchten Karten landet in derselben Größenordnung wie Modelle, die auf Rechenzentren laufen. Nicht davor — aber der Abstand ist kleiner, als die Preisschilder vermuten lassen.

Der entzensierte Ableger kostet keine Mathematik

Neben unserer eigenen Konvertierung gibt es HauhauCS' „Aggressive"-Fassung desselben Modells. Die naheliegende Sorge bei jedem Uncensoring lautet: Was kostet der Eingriff an Fähigkeit? Für Mathematik ist die Antwort gemessen — dieselben 150 Aufgaben, dasselbe Budget, dieselben Sampler:

Modell	MATH-500	am Limit	Token/Aufgabe
unser Q8_0	147 / 150 = 98,0 %	1	1.890
HauhauCS Aggressive Q8_K_P	148 / 150 = 98,7 %	0	1.993

gepaart, exakter McNemar:  2 : 3   p = 1,0000

Kein nachweisbarer Unterschied. Zwei Aufgaben löst nur unseres, drei nur deren — bei fünf diskordanten Paaren ist das Rauschen. Bemerkenswert daran ist, dass hier gleich zwei Dinge zugleich anders sind: das Uncensoring-Verfahren und die Quantisierung (Q8_K_P statt Q8_0, 29,3 statt 26,6 GB). Beides zusammen bewegt die Trefferquote nicht.

Aufschlussreicher als die Quote ist, woran sie jeweils scheitern. Von den fünf Aufgaben, in denen sie sich unterscheiden, sind drei bloße Schreibweisen — (3,4] gegen 3<\lambda\le 4, .35625 gegen 0{,}35625, 16/49 gegen \frac{16}{49} im Vektor. Rechnet man die heraus, stehen beide bei 149 von 150. Übrig bleibt je ein echter Fehlschlag, und die sind von verschiedener Art: unseres frisst sich an einer Level-5-Aufgabe fest und liefert nach 24.000 Token nichts; deren rechnet eine Level-3-Aufgabe falsch.

Was hier NICHT gemessen wurde: Code, Instruktionsbefolgung, Halluzinationsneigung. Mathematik ist der robusteste Teil eines Modells — dass sie hält, beweist nicht, dass alles hält. Bei einem ersten Vision-Versuch antwortete die entzensierte Fassung auf eine deutsche Frage englisch; ein Einzelfall, aber genau die Sorte Nebenwirkung, die man bei Uncensoring erwartet.

Der MTP-Kopf steckt dort im Hauptmodell

Ein Blick in die Tensorlisten erklärt einen Größenunterschied, den man den Dateinamen nicht ansieht:

Datei	Tensoren
unser Hauptmodell (mit --no-mtp konvertiert)	851
HauhauCS Q8_K_P	866

Die 15 zusätzlichen heißen blk.64.nextn.* — das ist der Multi-Token-Prediction-Kopf. Er liegt dort im Hauptmodell, obwohl daneben noch eine eigene MTP-Datei ausgeliefert wird. Wer beides zusammen lädt, hält 18 Tensoren doppelt im Speicher.

Nachzählen kann das jeder:

from gguf import GGUFReader
r = GGUFReader("modell.gguf")
print(len(r.tensors), [t.name for t in r.tensors if "nextn" in t.name])

Das hat einen praktischen Vorteil und einen Nachteil. Vorteil: Dort genügt --spec-type draft-mtp ohne zweite Datei — der Kopf wird direkt genutzt. Nachteil: Das Hauptmodell trägt die 2,7 GB immer mit, auch wenn man gar keine Spekulation will. Unsere Trennung per --no-mtp war ursprünglich eine Aufräumentscheidung; der Tensorvergleich zeigt, dass sie auch Speicher spart.

Zwei Beschleunigungspfade, gemessen

HauhauCS liefert zusätzlich ein FastMTP-Sidecar von 0,9 GB und beziffert es mit „+21 bis +35 Prozent" gegenüber dem eingebetteten Kopf. Wir haben beide auf derselben Maschine gegeneinander gemessen — dasselbe Modell, dieselben acht Textsorten, drei Durchgänge je Sorte:

Textsorte	eingebetteter Kopf	FastMTP-Sidecar
Struktur / JSON	39,4 t/s	48,0 t/s	+21,8 %
Code	39,1 t/s	46,7 t/s	+19,4 %
Wiederholung	48,6 t/s	57,5 t/s	+18,3 %
Aufzählung	48,9 t/s	57,2 t/s	+17,0 %
Kreativtext	35,4 t/s	38,6 t/s	+9,0 %
Fließtext	32,3 t/s	33,6 t/s	+4,0 %
Fachtext	35,2 t/s	34,3 t/s	−2,6 %
Übersetzung	45,6 t/s	42,5 t/s	−6,8 %
Trefferquote gesamt	56,8 %	46,4 %

Die Behauptung trifft zu, aber nur für strukturierten Text. Bei JSON, Code und Aufzählungen liegt der Gewinn bei 17 bis 22 Prozent; bei Fließtext ist er im Rauschen, bei Fachtext und Übersetzung sogar negativ. Das Muster ist stimmig: Die Trefferquote sinkt (46,4 statt 56,8 Prozent), das Tempo steigt trotzdem — das kleinere Draft rät schlechter, ist aber so viel billiger, dass es sich bei vorhersagbarem Text lohnt. Auf die Qualität wirkt sich das nicht aus, weil das Hauptmodell jeden Entwurfstoken verifiziert.

Das Sidecar braucht ein gepatchtes llama.cpp. Sein output.weight hat 32.768 statt 248.320 Vokabeleinträge; ein Standard-Binary bricht ab mit check_tensor_dims: tensor 'output.weight' has wrong shape. Wir hielten die Datei zunächst für defekt — falsch: HauhauCS liefert einen Patch mit, der eine d2t-Tabelle einführt und das Draft-Vokabular gezielt trimmt. Der Patch ist nicht upstream, muss also nach jedem llama.cpp-Update neu angewendet werden. Wer diese Wartungslast nicht will, nimmt den eingebetteten Kopf: der läuft mit jedem aktuellen Standard-Build.

Die Varianten unterscheiden sich nicht

Das ist der zweite große Befund dieser Messreihe, und er gilt in beiden Fächern.

HumanEval+

Alle 164 Aufgaben, sieben Varianten, identische Bedingungen. Bewertet wird durch Ausführen: jede gelieferte Funktion läuft gegen den vollständigen EvalPlus-Testblock, der die HumanEval-Originaltests um etwa das Achtzigfache erweitert.

Variante	bestanden	Quote	Token/s
Qwen3.6-27B UD-Q6_K_XL	149/164	90,9 %	25,1
Qwen3.6-27B Uncensored Q6_K_P	148/164	90,2 %	26,9
Qwen3.8-27B Q6_K	148/164	90,2 %	27,9
Qwen3.6-27B Q6_K	146/164	89,0 %	27,6
Qwen3.8-27B Q8_0	145/164	88,4 %	19,5
Qwen3.8-27B BF16	145/164	88,4 %	13,2
Qwen3.6-27B Q5_K_M	145/164	88,4 %	31,3

Die gesamte Spanne beträgt vier Aufgaben von 164. Aussagekräftig ist hier nicht der Vergleich der Quoten, sondern der gepaarte Vergleich: weil alle Varianten dieselben Aufgaben bearbeiten, tragen nur die Aufgaben Information, bei denen genau eine von beiden besteht. Über alle 21 Paarungen mit dem exakten McNemar-Test: keine einzige signifikant, der kleinste p-Wert liegt bei 0,219.

Noch deutlicher wird es beim Blick auf die Aufgaben selbst:

• 135 der 164 Aufgaben lösen alle sieben Varianten
• 9 Aufgaben löst keine einzige (HumanEval/32, 76, 91, 101, 127, 132, 145, 154, 163)
• nur 20 Aufgaben unterscheiden überhaupt — und dort geht es mal so, mal so aus

Die scheinbare Rangfolge entsteht ausschließlich aus diesen 20 Wackelkandidaten. Wer daraus ein „Modell A ist besser als B" liest, liest Rauschen.

MATH-500, dieselben Varianten

Ohne Reasoning, Budget 1.600 Token, deshalb absolut niedriger — für den Vergleich untereinander ist das unproblematisch, weil alle dasselbe Limit bekommen.

Variante	Quote	abgeschnitten	Token/s
Qwen3.8-27B BF16	77,3 %	31/150	10,8
Qwen3.8-27B Q6_K	76,7 %	32/150	22,4
Qwen3.6-27B Q6_K	76,7 %	33/150	22,0
Qwen3.8-27B Q8_0	76,0 %	34/150	18,6

Auch hier gepaart geprüft: 0 von 6 Paarungen signifikant. Die Spanne sind zwei Aufgaben von 150.

Was man daraus mitnehmen kann

Quantisierung kostet hier nichts. BF16 (51 GB), Q8_0 (27 GB) und Q5_K_M (19 GB) landen bei HumanEval+ auf exakt 145 von 164, bei MATH-500 innerhalb von zwei Aufgaben. Von 51 auf 19 Gigabyte heruntergerechnet — kein messbarer Qualitätsverlust, aber 13,2 gegen 31,3 Token/s. Die unquantisierte Variante ist für diesen Zweck reine Verschwendung. Genau das macht 60 GB VRAM zu einer brauchbaren Grundlage: man braucht die großen Formate nicht.

Qwen3.8 schlägt Qwen3.6 bei Code nicht. Die neue Generation liegt im selben Bereich. Wer wegen Code aufrüstet, tut es umsonst; die Verbesserungen liegen woanders — Vision, MTP-Kopf, Kontextlänge, Denktiefe.

Einordnung gegen publizierte Werte

Modell	HumanEval+
Phi-4 Reasoning (Microsoft)	92,9 %
Qwen3.8-27B Q6_K — diese Messung	90,2 %
Llama 3 405B Instruct	89 %
Qwen3.8-27B Q8_0 — diese Messung	88,4 %
Granite 3.3 8B Base	86,1 %
Kimi K2 Base	80,3 %

Diese Zahlen sind nicht eins zu eins mit den Leaderboards vergleichbar. Drei Abweichungen vom offiziellen EvalPlus-Verfahren: die Aufgabe wird im Chat-Format gestellt („Vervollständige diese Funktion") statt als reine Textvervollständigung; Temperatur 0,2 statt greedy; und der Code wird aus Markdown-Zäunen geschält. Jeder Punkt kann einige Prozent bewegen, meist nach oben. Wer vergleichen will, nimmt die Zahl als Hausmessung, nicht als Leaderboard-Eintrag.

Das Fehlerbild ist gesund: bei Q8_0 sind von 19 Fehlschlägen 15 AssertionError, also echte Logikfehler. Dazu je ein TypeError, SyntaxError, IndexError und eine Zeitüberschreitung — kein Muster, das auf ein kaputtes Testgerüst hindeutet.

Das komplette Messgerüst liegt unter bench/ samt Selbsttests: einer prüft das Aufgaben-Harness gegen bekannt richtige und bekannt falsche Lösungen, einer die EvalPlus-Ausführung gegen die mitgelieferten Referenzlösungen (25/25 grün), einer den Antwortvergleich der Mathematik gegen 39 bekannte Schreibweisenfälle und alle Musterlösungen gegen sich selbst. Ohne diese Prüfung misst ein Benchmark unter Umständen nur die eigenen Denkfehler — bei uns hat allein ein zu strenger Antwortvergleich vier bis sechs Prozentpunkte gekostet, siehe METHODIK.md.

---

Durchsatz im Vergleich

Sieben 27B-Varianten unter identischen Bedingungen — 16K Kontext, eine Session, kein Draft, --tensor-split 1,1,1, KV-Cache q8_0, Temperatur 0,2:

Variante	Größe	Token/s
Qwen3.6-27B Q5_K_M	19 GB	26,4
Qwen3.6-27B Q6_K	21 GB	23,9
Qwen3.8-27B Q6_K	21 GB	23,7
Qwen3.6-27B Uncensored Q6_K_P	22 GB	23,1
Qwen3.6-27B UD-Q6_K_XL	24 GB	21,1
Qwen3.8-27B Q8_0	27 GB	19,6
Qwen3.8-27B BF16	51 GB	11,5

Der Zusammenhang ist schlicht: mehr Gigabyte, weniger Token pro Sekunde.

Die BF16 läuft auf drei RTX 3080 — knapp. 51,3 GB Gewichte belegen 16,7 / 16,8 / 17,7 GB der drei Karten, macht 51,2 von 60 GB. Mit 16K Kontext bleibt genug für KV-Cache und Puffer. Sie kostet 40 Prozent Tempo gegenüber Q8_0, ohne dass sich irgendwo ein Qualitätsvorsprung gezeigt hätte.

Kontextlänge und KV-Cache — ab 48 GB hört die Abwägung auf

Auf kleineren Karten zwingt der KV-Cache zu einer Entscheidung: weniger Bits im Cache, dafür mehr Kontext. Auf 60 GB stellt sich diese Frage nicht mehr, weil vorher das Modell selbst deckelt. n_ctx_train liegt bei Qwen3.8-27B bei 262.144 Token; darüber meldet llama.cpp:

llama_context: n_ctx_seq (384000) > n_ctx_train (262144)
  -- possible training context overflow

Mit q8_0 erreicht man auf 60 GB bereits den vollen trainierten Kontext. Ein Wechsel auf q5_1 oder q4_0 bringt hier keine Kontextlänge mehr, sondern nur freies VRAM — nützlich für mehr parallele Sitzungen, nicht für längere Eingaben. Auf 24 oder 32 GB sieht das anders aus, dort ist die Abwägung real.

Der Kontext ist dabei praktisch gratis: dieselbe Konfiguration mit 4K statt 97K lieferte im Rahmen der Messstreuung dieselben Werte (58,8 gegen 60,5 t/s bei Aufzählungen).

Ein Fallstrick beim KV-Quant: q5_1 hat auf diesem Build keinen Flash-Attention-Kern und fällt still auf CPU-Attention zurück. Die Generierungsrate sieht dabei fast normal aus — der Einbruch zeigt sich nur im Prefill. Nach jeder Änderung am KV-Format also mit einem langen Prompt nachmessen, nicht mit einem kurzen.

Flash-Attention mit quantisiertem KV-Cache: bitte selbst nachmessen

llama.cpp-Issue #24485 beschreibt einen stillen Rückfall auf CPU-Attention, wenn ein quantisierter KV-Cache mit Flash-Attention kombiniert wird und der Build ohne GGML_CUDA_FA_ALL_QUANTS=ON erzeugt wurde. Keine Warnung, aber 25- bis 45-fach langsamerer Prefill. Das Issue wurde als not planned geschlossen — das Verhalten bleibt also bestehen.

Unser Build ist nicht betroffen. Der Test dauert fünf Minuten: derselbe Prompt (8.933 Token), einmal mit q8_0-Cache, einmal mit f16.

KV-Cache	Prefill	Generierung
q8_0	2.111,7 Tok/s	22,8 Tok/s
f16	2.142,7 Tok/s	23,0 Tok/s

1,4 Prozent Abstand — kein Rückfall. Wichtig: an der Generierungsrate sieht man den Fehler nicht. Die ist durch die Speicherbandbreite begrenzt und ändert sich kaum; nur die Prefill-Rate deckt das Problem auf. Das dürfte der Grund sein, warum der Fehler in vielen Aufbauten unbemerkt bleibt.

Nebenbefund: --flash-attn off mit quantisiertem KV-Cache stürzt auf diesem Build ab (Speicherzugriffsfehler), statt sauber abzulehnen.

Zwei Hinweise für Ampere-Besitzer

FP8 läuft auf Ampere nicht nativ. SM 8.6 hat keine FP8-Tensorcores, die gibt es erst ab SM 8.9. Qwens FP8-Release lässt sich dort nur dequantisiert fahren — Speicher gespart, Tempo nicht. Für GGUF ist das gegenstandslos, weil Q8_0 und Q6_K reine Integer-Formate mit nativen Ampere-Kernen sind.

vLLM und drei GPUs: Tensor-Parallelität geht nicht, Pipeline-Parallelität schon. Das Modell hat 24 Attention-Heads, aber nur 4 KV-Heads, und tensor_parallel_size muss die Head-Zahl teilen — 4 durch 3 geht nicht auf. pipeline_parallel_size kennt diese Beschränkung nicht: Pipeline-Parallelität teilt Layer statt Attention-Köpfe und erlaubt sogar ungleiche Aufteilungen, dasselbe Prinzip wie --tensor-split in llama.cpp. Mit --pipeline-parallel-size 3 nutzt vLLM alle drei Karten.

Testaufbau

• 3× NVIDIA RTX 3080 20 GB — Ampere, SM 8.6, zusammen 60 GB
• AMD EPYC 7F32, 8 Kerne / 16 Threads
• llama.cpp Build 10423 (a94d563ed), Container ghcr.io/ggml-org/llama.cpp:full-cuda
• --tensor-split 1,1,1, KV-Cache q8_0, --flash-attn on
• Eine Session (--parallel 1), 97.024 Token Kontext
• Belegt: 31,2 GB von 60 GB — Modell 27,3 + Draft 2,7 + KV/Puffer

Wie diese Dateien gebaut wurden

# Zielmodell ohne MTP-Tensoren
convert_hf_to_gguf.py Qwen3.8-27B/ --outfile tmp-BF16.gguf --outtype bf16 --no-mtp

# nur der MTP-Kopf, als Draft
convert_hf_to_gguf.py Qwen3.8-27B/ --outfile qwen3.8-27b-MTP-Q8_0.gguf --outtype q8_0 --mtp

# Vision/Video-Projektor
convert_hf_to_gguf.py Qwen3.8-27B/ --outfile qwen3.8-27b-mmproj-F16.gguf --outtype f16 --mmproj

# quantisieren
llama-quantize tmp-BF16.gguf qwen3.8-27b-Q8_0.gguf Q8_0 16
llama-quantize tmp-BF16.gguf qwen3.8-27b-Q6_K.gguf Q6_K 16

Die Flags --mtp und --no-mtp sind neu; ältere llama.cpp-Builds kennen sie nicht. Die Architektur Qwen3_5ForConditionalGeneration (Qwen3.8 nutzt sie unverändert weiter) erbt supports_mtp_export = True über Qwen3_5TextModel → _LinearAttentionVReorderBase → Qwen3NextModel → _QwenMtpMixin.

Quelle: Qwen/Qwen3.8-27B in BF16 (51,3 GB, 16,00 BPW), nicht das FP8-Release — also keine doppelte Quantisierung.

Reproduzieren

# Tempo je Textsorte
python3 bench/bench_mtp.py --port 8290 --runs 3 --max-tokens 300 --out ergebnis.md

# MATH-500 mit vollem Reasoning
python3 bench/bench_mathe.py --port 8291 --modell "Q8_0" --satz math500 \
  --grenze 150 --reasoning --effort xhigh --max-tokens 8000 --out ergebnis.json

# HumanEval+ mit Ausführung
python3 bench/bench_humaneval.py --port 8291 --modell "Q8_0" --out ergebnis.json

# vorher immer: Selbsttests des Messgerüsts
python3 bench/selftest.py && python3 bench/selftest_he.py && python3 bench/selftest_mathe.py

Einzelmessungen schwanken um etwa ±6 Prozent, deshalb Median statt Einzelwert.

Lizenz

Apache 2.0, wie das Basismodell. Alle Rechte am Modell liegen beim Qwen-Team / Alibaba Cloud. Dieses Repo enthält ausschließlich formatkonvertierte Gewichte, kein zusätzliches Training und keine Änderung am Verhalten.