gfx1151Dense 27Bgemessen 16.08.2026

Qwen3.8-27B auf Strix Halo

Von 7,7 zu 30,9 tok/s — Faktor 4,0. Zwei unabhängige Hebel, keine Qualitätseinbußen. Der vollständige Optimierungsleitfaden für Dense-27B-Modelle auf AMD Strix Halo.

30,9

tok/s Code

mit MTP · IQ4_XS · ROCm

25,0

tok/s Prosa

mit MTP · IQ4_XS · ROCm

13,3

tok/s Basis

IQ4_XS · ohne MTP

4,0×

Faktor

gegen Q8_0-Ausgangslage

Ryzen AI MAX+ PRO 395 · Radeon 8060S (40 CUs) · LPDDR5X-8533 (128 GB) · ROCm gfx1151 · llama.cpp ≥ b10419

Die Reise: von 7,7 zu 30,9 tok/s

Zwei völlig unabhängige Optimierungen, die sich multiplizieren. Kein Hexenwerk, keine Treiber-Magie — nur Physik und kluge Algorithmen.

1
Ausgangslage: Q8_0
Vorher 7,7 tok/sNachher 7,7 tok/s+0 %
Qwen3.8-27B als Q8_0-Quant — 28 GB Gewichte, volle Bandbreiten-Auslastung. Keine Optimierung möglich, die Hardware ist am Limit.
2
Hebel 1: IQ4_XS-Quantisierung
Vorher 7,7 tok/sNachher 13,3 tok/s+73 %
Das Modell schrumpft von 28 auf 15 GB. Dadurch halbiert sich die Speicherlast pro Token — die GPU muss nur noch 15 GB statt 28 GB durch ihren Bus bewegen. Ergebnis: 92 % der theoretischen Bandbreiten-Grenze.
3
Hebel 2: MTP Speculative Decoding
Vorher 13,3 tok/sNachher 30,9 tok/s+132 %
Qwen3.8 hat eine eingebaute Multi-Token-Prediction-Schicht. Der Rater generiert 3–4 Tokens in einem Durchgang, das Hauptmodell verifiziert sie. Bei Code liegt die Trefferquote bei ~73 % — 3,2 Tokens pro Verification-Durchgang. Mathematisch identisch zur normalen Generierung, keine Qualitätseinbuße.

Empfohlene Konfiguration (bash)

$QUANT=IQ4_XS BACKEND=rocm ./run.sh start

Die Bandbreiten-Wand

Warum ist ein Dense-27B-Modell der ungünstigste Fall für Strix Halo? Und warum sind MoE-Modelle so viel schneller?

Quant	Größe	Theoretisch	Gemessen	Ausnutzung
IQ4_XS	14,6 GiB	~14,5 t/s	13,3 t/s	92 %
UD-Q4_K_XL	17,1 GiB	~12,5 t/s	12,0 t/s	96 %
Q8_0	28,0 GiB	~7,7 t/s	7,7 t/s	100 %

Dense 27B = Worst Case

Jedes einzelne Token muss alle 27 Mrd. Parameter durch den Speicherbus bewegen. Die GPU kann nicht schneller rechnen, als das RAM liefert. Die 7,7 tok/s bei Q8_0 sind physikalisch das absolute Maximum — kein Backend, kein Treiber, keine Optimierung kann das ändern.

MoE ändert die Rechnung

Zum Vergleich: qwen3-coder:30b (MoE, A3B) liefert 69 tok/s. Nur 3 Mrd. aktive Parameter pro Token. Die Datei ist zwar 23 GB groß, aber die GPU muss nur einen Bruchteil laden. Dateigröße ≠ Geschwindigkeit bei MoE.

IQ4_XS gegen Q8_0 — der Quanten-Kompromiss

Beide liegen auf der Platte, umschaltbar per QUANT=. Die Entscheidung ist einfach.

IQ4_XS — Standard

15 GB — halbiert die Speicherlast gegenüber Q8_0
13,3 tok/s Basis — 30,9 mit MTP
1–2 % Perplexity-Verlust (Literaturwert) — im Alltag nicht wahrnehmbar
Tool-Calling: 10/10 Punkte im Hart-Test

Q8_0 — nur für Präzision

28 GB — doppelt so groß, kein Platz für Nebenmodelle
7,7 tok/s — 35–43 % langsamer als IQ4_XS
Gegenüber BF16 praktisch verlustfrei
MTP wirkt relativ stärker (2,61× gegen 2,32×)

Leistung je Quant und Backend

Quant	Backend	pp512 (t/s)	tg128 (t/s)
IQ4_XS	rocm	434,6	13,38
IQ4_XS	vulkan-perf	385,2	13,32
IQ4_XS	vulkan	378,4	13,29
UD-Q4_K_XL	rocm	403,0	11,70
UD-Q4_K_XL	vulkan-perf	388,1	11,98
UD-Q4_K_XL	vulkan	372,5	11,98
Q8_0	rocm	388,4	7,72
Q8_0	vulkan-perf	345,7	7,74
Q8_0	vulkan	325,0	7,76

Das Backend ist bei der Generierung irrelevant — 13,29 gegen 13,38 sind unter 1 %. Beim Prompt-Processing gewinnt ROCm +15 % (compute-bound). Bei ≥ 8 parallelen Requests dreht sich das Bild.

Konfigurationswechsel (bash)

$# IQ4_XS (Standard)

$QUANT=IQ4_XS BACKEND=rocm ./run.sh start

$# Q8_0 (höchste Präzision)

$QUANT=Q8_0 BACKEND=rocm ./run.sh start

MTP Speculative Decoding — der eigentliche Hebel

Qwen3.8 hat eine eingebaute Multi-Token-Prediction-Schicht (mtp_num_hidden_layers: 1). Kein separates Draft-Modell, kein Tokenizer-Mismatch. Einfach --spec-type draft-mtp.

Wie es funktioniert: Der Rater generiert 3–4 Tokens in einem Durchgang. Das Hauptmodell verifiziert sie alle parallel. Bei Code ~73 % Trefferquote — die getroffenen Tokens sind geschenkt, kein zusätzlicher Speicherdurchlauf nötig. Das Ergebnis ist mathematisch identisch mit normaler Generierung.

Modell	Prompt-Art	Ohne	Mit MTP	Faktor
IQ4_XS	Code	13,29	30,85	2,32×
IQ4_XS	Prosa	13,28	25,02	1,88×
Q8_0	Code	7,69	20,03	2,61×
Q8_0	Prosa	7,69	14,34	1,86×

Code profitiert mehr

Strukturierte Texte (Einrückung, Klammern, Boilerplate) sind leichter zu raten. Bei Code 2,32×, bei Prosa 1,88×. Die Trefferquote liegt bei Code bei ~73 %, bei Prosa etwas tiefer.

Q8_0 profitiert relativ mehr

Auf Q8_0 wirkt MTP mit 2,61× stärker, weil pro Durchgang mehr Speicher bewegt wird. Das Einsparen von Durchgängen bringt hier mehr. Absolut bleibt IQ4_XS mit 30,9 tok/s vorn.

MTP aktivieren (bash)

$# Standard-Start mit MTP

$./run.sh start

$# Oder manuell im Container:

$llama-server --model Qwen3.8-27B-IQ4_XS.gguf \

$ --spec-default --spec-type draft-mtp \

$ --fa 1 --no-mmap --split-mode layer

Tool-Calling: llama-server gegen Ollama

Der Hart-Test mit 10 Fällen — derselbe Test wie im großen Modellvergleich. Das überraschende Ergebnis: der Stack entscheidet, nicht das Modell.

Modell	Quant	Stack	Punkte	Ø Antwortzeit
Qwen3.8-27B	IQ4_XS	llama-server	10/10	4,2 s
DeepSeek V4 Flash	IQ2_M	llama-server	10/10	8,4 s
glm-4.7-flash	—	Ollama	10/10	4,1 s
DeepSeek V4 Flash	IQ2_M	Ollama	8/10	14,6 s

Der wichtigste Befund steht in der letzten Zeile. Dasselbe Modell (DeepSeek V4 Flash), dasselbe Quant (IQ2_M), derselbe Test — über Ollama 8/10 und 14,6 s, über llama-server 10/10 und 8,4 s. Die zwei Fehler (nur ein Host-Aufruf bei drei; plex zu plexmediaserver korrigiert) lagen am Stack, nicht am Modell. Ollamas Chat-Template bzw. Tool-Parser verliert Aufrufe und normalisiert eigenmächtig Parameter.

Qualitativ gleichauf

Zur ursprünglichen Frage „ist DeepSeek qualitativ besser“: bei gleichem Stack sind beide fehlerfrei. Qwen3.8 ist doppelt so schnell und braucht ein Sechstel des Speichers.

Einschränkungen

Der Test misst Tool-Call-Präzision, nicht Wissen, Reasoning oder lange Ketten. 10 Fälle trennen zwei fehlerfreie Modelle nicht. Thinking war bei beiden aus — mit aktivem Thinking könnte das Bild anders aussehen.

Praxishinweis für Agenten. Wo Tool-Calling zählt, ist llama-server die messbar bessere Wahl — oder der Ornith-Fix via ollama_toolfix.py.

Qwen3.8 gegen DeepSeek V4 Flash

V4 Flash hat einen eigenen DSpark-Drafter (11 GB Zusatzdatei), der block-parallel rät. Die Erwartung: Überholspur. Die Realität: Qwen3.8 mit MTP ist schneller — bei einem Sechstel des Speicherbedarfs.

Modell	Verfahren	Code (t/s)	Prosa (t/s)	Speicher	Faktor
Qwen3.8-27B IQ4_XS	MTP	30,85	25,02	15 GB	2,32×
DeepSeek V4 Flash IQ2_M	DSpark	21,91	15,65	95 GB	1,43×

Qwen3.8 gewinnt praktisch

30,9 gegen 21,9 tok/s — bei einem Sechstel des Speichers. Für die allermeisten Aufgaben reicht die Qualität von Qwen3.8 völlig aus. Der Preis für DeepSeek sind 95 GB plus 11 GB Drafter.

Warum DSpark schwächer wirkt

Bei MoE aktiviert jeder geratene Token andere Experten — die Verifikation eines 5er-Blocks kostet viel mehr. Dazu drückt das grobe IQ2_M-Quant die Trefferquote des bf16-Drafters. Und das Modell ist ohnehin schnell: 15,3 t/s ohne Speculative Decoding bei 95 GB — das ist die MoE-Effizienz.

Speicher wird eng. 90 GB Modell + 11 GB Drafter = 101 GB. Bei 117 GB gesamt wird das eng, solange Ollama noch ein Modell hält. run.sh warnt vorher. Ein Lauf dauert wegen zweimal 90 GB Laden gut eine halbe Stunde.

DeepSeek-Profil starten (bash)

$PROFILE=ds4 ./run.sh start

$./spec-test.py ds4

KV-Cache: klein, aber fein

Qwen3.8 hat eine besondere Architektur: Nur 16 der 64 Layer sind echte Attention-Layer. Der Rest ist Gated DeltaNet mit konstantem State. Der Cache ist dadurch erstaunlich klein.

Kontext	f16	q8_0
32k	~2,0 GiB	~1,1 GiB
262k	~16 GiB	~8,5 GiB

Selbst der volle 262k-Kontext passt neben dem Modell locker in die 128 GB. KV-Cache auf q8_0 halbiert den Speicherbedarf ohne Nachteil.

KV-Cache niemals auf q4_0/q4_1. Bei dieser Architektur bricht der Prefill um Faktor 20 ein (llama.cpp #27109). q8_0 ist unbetroffen und halbiert den Cache gegenüber f16 ohne Nachteil.

KV-Cache-Optimierung (bash)

$# Empfohlen: q8_0 KV-Cache

$--cache-type k:q8_0 --cache-type v:q8_0

$# Für maximale Kontextlänge (262k) bei minimalem Speicher

$--ctx-size 262144 --cache-type k:q8_0 --cache-type v:q8_0

Fallstricke — was schiefgehen kann

Aus eigener Erfahrung dokumentiert. Die meisten Probleme sind bekannt und vermeidbar. Alle Fallstricke der Seite, nach Symptom sortiert: /fallstricke.

blockierend

KV-Cache q4_0/q4_1

Bei dieser Architektur bricht der Prefill um Faktor 20 ein (llama.cpp #27109). q8_0 ist sicher.

blockierend

Split-Mode: layer, nicht tensor

Mit MTP führt --split-mode tensor zu Lockups (#27122). layer ist stabil.

blockierend

-fa 1 und --no-mmap sind Pflicht

Ohne FlashAttention Abstürze, ohne --no-mmap massive Einbrüche. Diese Flags sind auf Strix Halo nicht optional.

wissenswert

Vision ist defekt

Auf AMD AI Max als defekt gemeldet (#27124). Der Textpfad läuft, Multimodalität wurde hier nicht verifiziert. Die mmproj-Datei liegt bereit, aber ungetestet.

tückisch

Thinking-Mode ist Default

Per Default ist reasoning_effort: xhigh. Bei knappem max_tokens kommt leerer Content zurück. Abschalten: {"enable_thinking": false} oder reasoning_effort: "none".

wissenswert

llama.cpp ≥ b10419

Das System-llama.cpp ist zu alt. Alles läuft über die kyuz0-Container (aktuell b10450). Wer selbst baut, muss ≥ b10419 ziehen.

Werkzeuge: Kurzbefehl und Live-Dashboard

Zur Messreihe gehören zwei Werkzeuge, die Betrieb und Überwachung vereinfachen.

ki — der Kurzbefehl

Ein einziger Befehl, der alles fragt: Modell, Backend, Speculative Decoding, Kontext und Aktion. Zeigt den fertigen Befehl an und startet ihn. Läuft schon ein Server, bietet er direkt den Monitor an. Kein Hänger wie llama-cockpit.

monitor.py — Live-Dashboard

Öffnet sich automatisch nach dem Start. Zeigt live: Zustand (BEREIT/PREFILL/DECODE), Decode in t/s mit Verlaufskurve, Prefill mit Fortschrittsbalken, Draft-Trefferquote, Kontext- und GPU-Auslastung. Beenden mit q.

Zustand: DECODE | 28,4 tok/s | Ø 26,1 | Max 32,7

Datei	Zweck
cockpit.py	Auswahlmenü: Modell, Backend, Spec, Kontext, Aktion
monitor.py	Live-Dashboard: Prefill/Decode, Draft-Trefferquote, GPU
run.sh	llama-server im Container: start\|stop\|status\|logs\|shell
bench.sh	Matrix Quant × Backend → ERGEBNISSE.md
spec-test.py	Speculative Decoding mit/ohne; Profil als Argument
autorun.sh	wartet auf Download, startet dann bench.sh

Schnellstart (bash)

$# Ein Befehl für alles

$ki

$# Oder direkt starten

$./run.sh start

Alle Messungen auf Fedora 44 · Kernel 7.1.6 · ROCm gfx1151 · llama.cpp b10450 · LPDDR5X-8533 · Ryzen AI MAX+ PRO 395 · Radeon 8060S (40 CUs)
Quelle: QWEN38-STRIX-HALO.md · gemessen 16. August 2026

Ausgangslage: Q8_0

Hebel 1: IQ4_XS-Quantisierung

Hebel 2: MTP Speculative Decoding

Dense 27B = Worst Case

MoE ändert die Rechnung

IQ4_XS — Standard

Q8_0 — nur für Präzision

Leistung je Quant und Backend

Code profitiert mehr

Q8_0 profitiert relativ mehr

Qualitativ gleichauf

Einschränkungen

Qwen3.8 gewinnt praktisch

Warum DSpark schwächer wirkt

KV-Cache q4_0/q4_1

Split-Mode: layer, nicht tensor

-fa 1 und --no-mmap sind Pflicht

Vision ist defekt

Thinking-Mode ist Default

llama.cpp ≥ b10419

ki — der Kurzbefehl

monitor.py — Live-Dashboard