README.md

---
license: apache-2.0
license_link: https://huggingface.co/Qwen/Qwen3.8-27B/blob/main/LICENSE
base_model:
- Qwen/Qwen3.8-27B
base_model_relation: quantized
pipeline_tag: image-text-to-text
library_name: llama.cpp
language:
- de
- en
tags:
- gguf
- llama.cpp
- mtp
- speculative-decoding
- qwen3
- multimodal
---

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

GGUF-Konvertierung von [Qwen/Qwen3.8-27B](https://huggingface.co/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](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

```bash
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:

```json
{"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:

```json
{"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](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
>    500.
> 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.

## 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.

![HumanEval+ je Variante](bench/quoten-hell.png)

| 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.

![MATH-500 je Variante](bench/mathe-hell.png)

| 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.

![Tempo gegen Qualität](bench/tempo-hell.png)

### 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](METHODIK.md).

---

## Durchsatz im Vergleich

![Durchsatz je Variante](bench/durchsatz-hell.png)

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](https://github.com/ggml-org/llama.cpp/issues/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

```bash
# 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

```bash
# 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.