gfx1151PROFIL-v13 Modelle · 8 Messpfade

Benchmarks — die Spitzenmodelle

Diese Seite vergleicht die aktuellen Spitzenmodelle auf dieser Hardware: Qwen3.8-Flash-Next, Qwen3.8-27B und DeepSeek V4 Flash. Nicht die historische Breite aller jemals hier gemessenen Modelle, sondern die drei, die gegeneinander antreten — mit Architektur, Quantisierung, Speicherbedarf, Decode- und Prefill-Rate und dem Tool-Call-Score aus QWEN38-STRIX-HALO.md. Was nicht gemessen ist, steht als nicht gemessen da und wird nicht geschätzt.

Spitzenmodelle im Vergleich

Drei Modelle, die aktuell auf dieser Maschine laufen — und die Arten, wie sie gefahren werden können. Aufgeschlüsselt nach Betriebsart, weil Engine und Drafter die Zahlen mehr verschieben als die Modellgröße. Fehlt ein Wert, steht nicht gemessen und keine Schätzung. Die Quellen jeder Zahl stehen unter der jeweiligen Karte.

Qwen3.8-Flash-Next: zwei Halogen-Stände unter identischen Bedingungen

Prompt-Stufe in Tokens · Median aus 3 Läufen · kalter Prompt-Cache

Halogen 0.17.3 · Checkpoint v2Halogen 0.18.19 · Checkpoint v2

Stufe 512

942 t/s

1.174 t/s

Stufe 4096

1.634 t/s

1.994 t/s

Stufe 16384

1.908 t/s

2.145 t/s

UMA 117 GiB, 120 W, Median aus 3 Läufen, kalter Prompt-Cache. Gleicher Checkpoint v2, nur die Runtime wechselte. Stufe 512 im 0.18.19-Lauf nicht eingeregelt (518 Tokens). Quellen: halogen-0.17.3-v2.json · halogen-0.18.19-v2.json.

Qwen3.8-Flash-Next

125 B, sparse MoE · Halogen-Checkpoint v2 (vorher w4b)

62,1 GiB Checkpoint v2 · 41,6 GiB gemessener Systemverbrauch, unter 0.18.7 noch 26,6 GiB (w4b: 68 GiB · 36,9 GiB)

passt mit Luft in die 117 GiB

llama.cpp (Gegenwert, gemessen gegen Halogen 0.11.3)

Drafter: nicht dokumentiert

Decode

26,1 t/s

12k Prompt-Tokens, identischer Prompt wie Halogen

Prefill

413 t/s

12k Prompt-Tokens

Tool-Call

nicht gemessen

Halogen 0.18.19 (Checkpoint v2)

Drafter: MTP-Draft-Head (eingebaut)

Decode

81,83 / 76,08 / 66,27 t/s

kalibrierte Stufen 512 / 4096 / 16384 (518 / 4098 / 16478 Prompt-Tokens, 512 nicht eingeregelt), Median aus 3 Läufen, UMA 117 GiB · 0.18.7: 74,24 / 70,93 / 63,94 t/s · 0.17.3: 60,25 / 58,58 / 58,59 t/s

Prefill

1174,18 / 1993,57 / 2144,72 t/s

dieselben Stufen, kalter Prompt-Cache (Cache-Busting) · 0.18.7: 1060,87 / 1886,33 / 1990,04 t/s · 0.17.3: 941,75 / 1634,1 / 1908,49 t/s

Tool-Call

nicht gemessen

Halogen 0.14.0 (w4b)

Drafter: MTP-Draft-Head (eingebaut)

Decode

53,73 / 54,46 / 50,96 t/s

kalibrierte Stufen 512 / 4096 / 16384 (518 / 4098 / 16478 Prompt-Tokens), Median aus 3 Läufen, UMA 117 GiB — gleiche Bedingungen wie 0.17.3, 0.18.7 und 0.18.19

Prefill

385,51 / 1049,04 / 1375,53 t/s

dieselben Stufen, kalter Prompt-Cache (Cache-Busting)

Tool-Call

nicht gemessen

› Quellen

Modell: bench/ergebnisse/halogen-0.18.19-v2.json · halogen-0.18.7-v2.json · halogen-0.14.0-maxtok16384.json · modell, speicher
llama.cpp (Gegenwert, gemessen gegen Halogen 0.11.3): Decode src/data/halogen.ts · halogenLeistung · Prefill src/data/halogen.ts · halogenLeistung · Tool-Call QWEN38-STRIX-HALO.md · Tool-Call-Vergleich enthält dieses Modell nicht
Halogen 0.18.19 (Checkpoint v2): Decode bench/ergebnisse/halogen-0.18.19-v2.json · halogen-0.18.7-v2.json · halogen-0.17.3-v2.json · Prefill bench/ergebnisse/halogen-0.18.19-v2.json · halogen-0.18.7-v2.json · halogen-0.17.3-v2.json · Tool-Call kein Tool-Call-Test für diesen Pfad belegt
Halogen 0.14.0 (w4b): Decode bench/ergebnisse/halogen-0.14.0-maxtok16384.json · Prefill bench/ergebnisse/halogen-0.14.0-maxtok16384.json · Tool-Call kein Tool-Call-Test für diesen Pfad belegt

Qwen3.8-27B

dense, 27 B · IQ4_XS

14,6 GiB (15 GB in der Messung)

passt locker, lässt Raum für Kontext und KV-Cache

llama.cpp (llama-server, ROCm)

Drafter: keiner

Decode

13,38 t/s

tg128, llama-bench, Backend rocm

Prefill

434,6 t/s

pp512, llama-bench, Backend rocm

Tool-Call

10/10

Ø 4,2 s Antwortzeit, Stack llama-server

llama.cpp + Speculative Decoding

Drafter: MTP (1 Slot)

Decode

30,85 t/s Code · 25,02 t/s Prosa

MTP-Faktor 2,32 (Code) bzw. 1,88 (Prosa) gegen 13,29/13,28 t/s Basis

Prefill

nicht gemessen

Tool-Call

nicht gemessen

› Quellen

Modell: QWEN38-STRIX-HALO.md · Quant-Tabelle, Messung 1
llama.cpp (llama-server, ROCm): Decode QWEN38-STRIX-HALO.md · Messung 1 · Prefill QWEN38-STRIX-HALO.md · Messung 1 · Tool-Call QWEN38-STRIX-HALO.md · Tool-Call-Vergleich
llama.cpp + Speculative Decoding: Decode QWEN38-STRIX-HALO.md · Messung 2 (MTP) · Prefill für den MTP-Pfad nicht separat gemessen · Tool-Call Tool-Call-Test ohne MTP-Angabe, nicht auf diesen Pfad übertragbar

DeepSeek V4 Flash

MoE, 284 Mrd. Parameter · UD-IQ2_M

95 GB Dateigröße · 90 GB Modell + 11 GB Drafter ≈ 101 GB bei --no-mmap

passt nur in 2 Bit und nur, wenn kein anderes Modell geladen ist — Fallstrick `ds4-platzangst`

llama.cpp (llama-server)

Drafter: keiner

Decode

15,34 t/s Code · 15,37 t/s Prosa

16.08.2026, ohne Speculative Decoding

Prefill

nicht gemessen

Tool-Call

10/10

Ø 8,4 s Antwortzeit, Stack llama-server

llama.cpp + Speculative Decoding

Drafter: DSpark (11 GB, block-parallel, 5er-Blöcke)

Decode

21,91 t/s Code · 15,65 t/s Prosa

DSpark-Faktor 1,43 (Code) bzw. 1,02 (Prosa) — schwächer als MTP bei Qwen3.8

Prefill

nicht gemessen

Tool-Call

nicht gemessen

Ollama 0.32.5

Drafter: keiner

Decode

nicht gemessen

Prefill

nicht gemessen

Tool-Call

8/10

Ø 14,6 s Antwortzeit — derselbe Test, anderer Stack

› Quellen

Modell: QWEN38-STRIX-HALO.md · DS4-Profil · src/data/fallstricke.ts · ds4-platzangst
llama.cpp (llama-server): Decode QWEN38-STRIX-HALO.md · DS4-Profil, Ergebnis · Prefill für dieses Modell nicht gemessen · Tool-Call QWEN38-STRIX-HALO.md · Tool-Call-Vergleich
llama.cpp + Speculative Decoding: Decode QWEN38-STRIX-HALO.md · DS4-Profil, Ergebnis · Prefill für dieses Modell nicht gemessen · Tool-Call für den DSpark-Pfad nicht gemessen
Ollama 0.32.5: Decode auf diesem Stack nicht gemessen · Prefill auf diesem Stack nicht gemessen · Tool-Call QWEN38-STRIX-HALO.md · Tool-Call-Vergleich

Architekturangaben (dense, sparse MoE, Parameterzahl) stammen aus den Modellbeschreibungen der Quellen, nicht aus den Messprotokollen.

Einordnung

Sechs Punkte, die aus den Zahlen oben folgen. Jeder Punkt ist an eine Quelle gebunden; was nicht belegt ist, steht nicht da.

Das größte Modell gewinnt nicht.

125 B, 284 B oder 27 B — die schnellste Decode-Rate dieser Liste kommt nicht vom größten Modell: DeepSeek V4 Flash (284 B) erreicht mit DSpark 21,91 t/s. Vorn liegt das sparse MoE Qwen3.8-Flash-Next unter Halogen 0.18.19 mit 66,27 t/s bei 16k Prompt. Unter den llama.cpp-Pfaden führt das kleinste Modell, Qwen3.8-27B mit MTP (30,85 t/s).

bench/ergebnisse/halogen-0.18.19-v2.json · QWEN38-STRIX-HALO.md · Messung 2, DS4-Profil

DeepSeek V4 Flash ist größer, passt nur in 2 Bit — und liegt mit Drafter hinter dem viel kleineren Qwen3.8-27B.

Ohne Drafter liegt V4 Flash mit 15,34 t/s sogar knapp vor dem dichten Qwen3.8-27B (13,38 t/s), weil als MoE pro Token weniger Gewicht bewegt wird. Sobald beide mit Draft-Modellen laufen, dreht sich das um: 30,85 t/s (Qwen + MTP) gegen 21,91 t/s (V4 Flash + DSpark) bei einem Sechstel des Speicherbedarfs.

QWEN38-STRIX-HALO.md · DS4-Profil, Praktische Folge

Flaschenhals ist die Speicherbandbreite, nicht die Rechenleistung.

Q8_0 mit 28 GiB erreicht 7,7 t/s — das sind rund 216 GB/s, die Ausnutzung steht bei 100 %. Backend, Treiber und Flags ändern an der Decode-Rate unter 1 % (13,29 vs 13,38 t/s). Beim Prefill, der compute-bound ist, gewinnt ROCm dagegen klar mit +15 %.

QWEN38-STRIX-HALO.md · Bandbreiten-Tabelle · src/data/hardware.ts

Sparse-MoE-Modelle gewinnen.

Dense 27 B in IQ4_XS: 13,38 t/s. MoE auf derselben Maschine: 69 t/s (qwen3-coder:30b) und 51 t/s (glm-4.7-flash). Bei MoE sagt die Dateigröße nichts über die Geschwindigkeit aus, nur über den Speicherbedarf — V4 Flash liefert 15,3 t/s bei 95 GB, wo die naive Bandbreitenrechnung 2,3 t/s ergäbe.

QWEN38-STRIX-HALO.md · Bandbreiten-Wand, DS4-Profil

Die Stack-Wahl entscheidet über dasselbe Modell.

DeepSeek V4 Flash, derselbe Test: über llama-server 10/10 bei 8,4 s, über Ollama 8/10 bei 14,6 s. Der Unterschied liegt am Stack, nicht am Modell.

QWEN38-STRIX-HALO.md · Tool-Call-Vergleich · src/data/fallstricke.ts · ollama-vs-llama-server

Größere DeepSeek-V4-Quantisierungen sprengen den Speicher.

90 GB Modell plus 11 GB Drafter sind rund 101 GB bei `--no-mmap`. Die Maschine meldet 117 GiB gesamt, aber wenn Ollama in dem Moment noch ein anderes Modell hält, ist der Platz längst belegt. IQ2_M ist hier keine Geschmacksfrage, sondern die einzige Quantisierungsstufe, die überhaupt reinpasst.

src/data/fallstricke.ts · ds4-platzangst · QWEN38-STRIX-HALO.md · DS4-Profil, Speicher

Wie gemessen wird — PROFIL-v1

Seit strix-bench v1 (2026-09-20) laeuft alles ueber ein festes PROFIL-v1: gleiche Prompttexte, gleiche Ausgabelaenge, gleicher Aggregationsmodus. Ohne dieses Profil sind Zahlen aus verschiedenen Protokollen nicht vergleichbar — die Regeln sind der Grund, warum man die Werte ueberhaupt gegeneinander stellen darf.

Kennzahl	Definition
ttft_ms	(t1 − t0) · 1000 — t0 unmittelbar vor dem Absenden der POST, t1 beim ersten SSE-Chunk mit nicht-leerem delta.content
prefill_tps	prompt_tokens / (t1 − t0)
decode_tps	completion_tokens / (t2 − t1) — t2 beim letzten empfangenen Daten-Chunk, vor [DONE]
peak_mem_gib	hoechster waehrend des Laufs gemessener Systemverbrauch (MemTotal − MemAvailable), 20 ms getaktet — nicht der Prozess-Speicher

Die Regeln des Profils

Regel	Grund
Ausgabe auf exakt 256 Tokens, EOS unterdrueckt (ignore_eos)	Sonst beendet das Modell die Antwort, wann es will, und die Decode-Zeit ist nicht mehr vergleichbar.
Reasoning/Thinking abgeschaltet	Denkketten verschieben Tokens von der Ausgabe in den unsichtbaren Teil und verfaelischen beide Raten.
Cache-Busting: eindeutiger Kennwert vor jedem Prompt	Sonst trifft der Praefix-Cache und der Prefill ist eine Messung von nichts.
Ein Aufwaerm-Lauf, verworfen	Der erste Lauf enthaelt Initialisierung, Page-Faults und Kalte-Pfade.
Median ueber die Messlaeufe, nicht Mittelwert und nicht Bestwert	Der Median traegt keine Ausreisser nach oben durch.
Feste Prompttexte aus dem Repo	Gleiche Promptlaenge und gleicher Inhalt, sonst ist die Stufe keine Stufe.
Kalibrierung ueber Sonde (max_tokens=1, usage.prompt_tokens), Toleranz 1 %	Die Zielstufe ist eine Vorgabe an den Tokenizer, kein Ergebnis. Ohne Sonde misst man eine andere Promptlaenge als angegeben.

Quelle: bench/PROFIL-v1.md

Protokollierte Messläufe

halogen-0.11.9-qwen38-flash-next.json2026-09-20 14:45unkalibriertUMA 48 GiB120 W3 Laeufe

Qwen3.8-Flash-Next (125B, w4b, 68 GiB) · halogen 0.11.9 · Peak 39.554 GiB

Stufe	Prompt-Tokens	Completion	TTFT	Prefill	Decode	Peak
512	768	256	1574.97 ms	487.63 t/s	45.17 t/s	39.484 GiB
4096	5392	256	4888.38 ms	1103.02 t/s	43.93 t/s	39.467 GiB
16384	18467	256	13814.6 ms	1336.77 t/s	40.39 t/s	39.518 GiB

Die Stufen sind Zielwerte, keine Token-Zahlen: die 4096er Stufe ergibt getokenized 5392 Prompt-Tokens, die 16384er Stufe 18467. Vergleiche ueber Stufen sind damit ohne Kalibrierung keine Vergleiche ueber gleiche Promptlaengen.

halogen-0.11.9-kalibriert-4096.json2026-09-20 17:24kalibriertUMA 48 GiB120 W1 Lauf

Qwen3.8-Flash-Next (125B, w4b, 68 GiB) · halogen 0.11.9 · Peak 39.654 GiB

Stufe	Prompt-Tokens	Completion	TTFT	Prefill	Decode	Peak
4096	4098	256	4059.02 ms	1009.6 t/s	26.1 t/s	39.655 GiB

Kalibrierung aktiv (Toleranz 1 %, max. 8 Iterationen): der Prompt wird so lange ergaenzt, bis usage.prompt_tokens die Zielstufe trifft — hier 4098 statt 5392. Auffaellig: der Decode-Wert liegt mit 26,1 t/s deutlich unter den 43,9 t/s des Laufs von 14:45, und das bei kuerzerem Prompt. Das ist aus den Protokollen nicht erklaert. Ein einzelner Lauf ohne Vergleichslaufen ist keine Grundlage fuer eine Rangfolge — die Zahl steht hier, nicht die Deutung.

halogen-0.12.3-maxtok16384.json2026-09-21 19:30kalibriertUMA 117 GiB120 W3 Laeufe

Qwen3.8-Flash-Next (125B, w4b, 68 GiB) · halogen 0.12.3 · Peak 31.199 GiB

Stufe	Prompt-Tokens	Completion	TTFT	Prefill	Decode	Peak
16384	16478	256	11733.31 ms	1404.38 t/s	43.48 t/s	30.985 GiB

Kalibrierung aktiv: 18469 -> 16480 Tokens in 3 Iterationen, Abweichung 0,59 % bei 1 % Toleranz; nachgemessen 16478. Nicht vergleichbar mit den 0.11.9-Protokollen oben: andere Runtime-Version und andere UMA-Aufteilung (117 GiB statt 48 GiB). PROFIL-v1 nennt die UMA-Aufteilung als haeufigste Ursache fuer sich widersprechende Zahlen auf dieser Maschine, also ist das kein Detail. Der Decode-Wert (43,48 t/s bei 16478 Prompt-Tokens) steht gegen 40,39 t/s bei 18467 Tokens vom 20.09. — unterschiedliche Promptlaenge, kein Stufenvergleich. Der Peak liegt mit 31,0 GiB deutlich unter den 39,5 GiB der 48-GiB-UMA-Laeufe; warum, ist aus dem Protokoll nicht erklaert.

halogen-0.14.0-maxtok16384.json2026-09-26 09:23kalibriertUMA 117 GiB120 W3 Laeufe

Qwen3.8-Flash-Next (125B, w4b, 68 GiB) · halogen 0.14.0 · Peak 36.951 GiB

Stufe	Prompt-Tokens	Completion	TTFT	Prefill	Decode	Peak
512	518	256	1343.66 ms	385.51 t/s	53.73 t/s	36.078 GiB
4096	4098	256	3906.44 ms	1049.04 t/s	54.46 t/s	36.913 GiB
16384	16478	256	11979.36 ms	1375.53 t/s	50.96 t/s	36.908 GiB

Alle drei Stufen kalibriert. Die 512er Stufe ist nicht eingeregelt: bestes Ergebnis nach 8 Sonden 520 statt 512 Tokens (1,6 % bei 1 % Toleranz), nachgemessen 518 — als solcher gekennzeichnet. Gleiche UMA-Aufteilung (117 GiB), gleiche TDP und gleiches HALOGEN_MAX_TOK wie der 0.12.3-Lauf, deshalb an der 16384er Stufe direkt vergleichbar: Decode 50,96 gegen 43,48 t/s bei 16478 Prompt-Tokens in beiden Laeufen. Laut Changelog ist 0.14.0 die Version mit dem neuen MTP-Draft-Head (Tiefe 2).

halogen-0.17.3-v2.json2026-10-09 21:12kalibriertUMA 117 GiB120 W3 Laeufe

Qwen3.8-Flash-Next (125B, Checkpoint v2, 62,1 GiB) · halogen 0.17.3 · Peak 25.661 GiB

Stufe	Prompt-Tokens	Completion	TTFT	Prefill	Decode	Peak
512	516	256	547.91 ms	941.75 t/s	60.25 t/s	25.346 GiB
4096	4097	256	2507.19 ms	1634.1 t/s	58.58 t/s	25.291 GiB
16384	16477	256	8633.54 ms	1908.49 t/s	58.59 t/s	24.926 GiB

Alle drei Stufen innerhalb der 1-%-Toleranz kalibriert. UMA, TDP und HALOGEN_MAX_TOK wie beim 0.14.0-Lauf; zusaetzlich protokolliert ist HALOGEN_CACHE_BRANCHES=3 — es betrifft nur die Zahl der Cache-Eintraege und greift bei kaltem Cache nicht. Anders ist der Checkpoint: v2 statt w4b. Runtime- und Checkpoint-Wechsel stecken also beide in der Differenz und sind aus diesem Protokoll nicht getrennt. Gegen 0.14.0 bei gleicher Promptlaenge: Prefill 1908 gegen 1376 t/s (16k), 1634 gegen 1049 t/s (4k), Decode 58,6 gegen 51,0 t/s (16k). Der Peak liegt mit 25,7 GiB rund 11 GiB unter dem 0.14.0-Lauf; warum, ist aus dem Protokoll nicht erklaert.

halogen-0.18.5-v2.json2026-10-16 09:30kalibriertUMA 117 GiB120 W3 Laeufe

Qwen3.8-Flash-Next (125B, Checkpoint v2, 62,1 GiB) · halogen 0.18.5 · Peak 26.055 GiB

Stufe	Prompt-Tokens	Completion	TTFT	Prefill	Decode	Peak
512	518	256	490.03 ms	1057.08 t/s	77.04 t/s	24.675 GiB
4096	4098	256	2130.08 ms	1923.87 t/s	67.18 t/s	25.464 GiB
16384	16478	256	8139.96 ms	2024.33 t/s	62.83 t/s	25.148 GiB

Gleicher Aufruf wie der 0.17.3-Lauf (UMA 117 GiB, 120 W, HALOGEN_MAX_TOK=16384, HALOGEN_CACHE_BRANCHES=3) und gleicher Checkpoint v2 — die Differenz geht damit allein auf die Runtime. Die 512er Stufe ist nicht eingeregelt: bestes Ergebnis nach 8 Sonden 520 statt 512 Tokens, nachgemessen 518 — als solcher gekennzeichnet. Gegen 0.17.3: Prefill 2024 gegen 1908 t/s (16k), 1924 gegen 1634 t/s (4k), 1057 gegen 942 t/s (512); Decode 62,8 gegen 58,6 t/s (16k), 67,2 gegen 58,6 t/s (4k), 77,0 gegen 60,3 t/s (512). Laut Changelog stoppt die MTP-Kette ab 0.18.5 beim ersten unsicheren Draft-Token, das hilft kurzen Kontexten am meisten. Die Zwischenversionen 0.17.4 und 0.18.3 sind nicht einzeln gemessen.

halogen-0.18.7-v2.json2026-10-17 09:24kalibriertUMA 117 GiB120 W3 Laeufe

Qwen3.8-Flash-Next (125B, Checkpoint v2, 62,1 GiB) · halogen 0.18.7 · Peak 26.579 GiB

Stufe	Prompt-Tokens	Completion	TTFT	Prefill	Decode	Peak
512	518	256	488.28 ms	1060.87 t/s	74.24 t/s	25.15 GiB
4096	4098	256	2172.47 ms	1886.33 t/s	70.93 t/s	26.153 GiB
16384	16478	256	8280.23 ms	1990.04 t/s	63.94 t/s	26.197 GiB

Gleicher Aufruf und gleicher Checkpoint v2 wie die Laeufe 0.17.3 und 0.18.5. Die 512er Stufe ist wie bei 0.18.5 nicht eingeregelt (bestes Ergebnis 520 statt 512 Tokens, nachgemessen 518). Gegen 0.18.5: Prefill 1990 gegen 2024 t/s (16k), 1886 gegen 1924 t/s (4k), 1061 gegen 1057 t/s (512); Decode 63,9 gegen 62,8 t/s (16k), 70,9 gegen 67,2 t/s (4k), 74,2 gegen 77,0 t/s (512). Alle Differenzen liegen innerhalb der Laufspannen (Decode 4k: 11 %) — kein messbarer Unterschied. Der Changelog-Fix fuer kurze Antworten (#186) wirkt am Ende einer Antwort; das Profil erzwingt 256 Ausgabe-Tokens mit ignore_eos und kann ihn deshalb nicht zeigen. Die Zwischenversion 0.18.6 ist nicht einzeln gemessen.

halogen-0.18.19-v2.json2026-10-30 08:25kalibriertUMA 117 GiB120 W3 Laeufe

Qwen3.8-Flash-Next (125B, Checkpoint v2, 62,1 GiB) · halogen 0.18.19 · Peak 41.613 GiB

Stufe	Prompt-Tokens	Completion	TTFT	Prefill	Decode	Peak
512	518	256	441.16 ms	1174.18 t/s	81.83 t/s	40.836 GiB
4096	4098	256	2055.61 ms	1993.57 t/s	76.08 t/s	41.367 GiB
16384	16478	256	7683.06 ms	2144.72 t/s	66.27 t/s	41.582 GiB

Gleicher Aufruf und gleicher Checkpoint v2 wie die Laeufe 0.17.3, 0.18.5 und 0.18.7. Die 512er Stufe ist wie zuvor nicht eingeregelt (bestes Ergebnis 520 statt 512 Tokens, nachgemessen 518). Gegen 0.18.7: Prefill 2145 gegen 1990 t/s (16k), 1994 gegen 1886 t/s (4k), 1174 gegen 1061 t/s (512) — bei Prefill-Spannen unter 1,1 % ein echter Zuwachs. Decode 66,3 gegen 63,9 t/s (16k, Spanne 9,7 %), 76,1 gegen 70,9 t/s (4k, Spanne 6,2 %), 81,8 gegen 74,2 t/s (512, Spanne 3,3 %) — nur bei 512 klar ausserhalb der Spanne. Der Peak liegt mit 41,6 GiB rund 15 GiB ueber 0.18.7; der Wert ist der Systemverbrauch, nicht der Prozess, und aus dem Protokoll nicht erklaert. Die Zwischenversionen 0.18.9 bis 0.18.17 sind nicht einzeln gemessen.

Lesart. Alle Werte sind Mediane aus den JSON-Protokollen unter bench/ergebnisse/. Hostname, Endpunkt und lokale Dateipfade aus den Protokollen sind bewusst nicht uebernommen. UMA-Aufteilung und TDP stehen an jedem Lauf dabei: zwei Laeufe mit unterschiedlichen Werten darin sind keine vergleichbaren Messungen, auch wenn Modell und Runtime gleich aussehen.

Halogen gegen llama.cpp

Halogen ist eine proprietäre Inferenz-Engine von peonist-ai, gebaut fuer gfx1151. Der Vergleich mit llama.cpp laeuft ueber zwei Kennzahlen, die man getrennt betrachten muss.

Kennzahl	Kontext	Halogen	llama.cpp	Faktor
Prefill	12k Tokens Prompt, Halogen 0.11.3	1340 t/s	413 t/s	3,2×
Decode	Token-Ausgabe, Halogen 0.11.3	33.5 t/s	26.1 t/s	1,28×

Quelle: src/data/halogen.ts · halogenLeistung. Details, Cache-Fixes und Update-Ablauf: /halogen.

Benchmarks — die Spitzenmodelle

Spitzenmodelle im Vergleich

Qwen3.8-Flash-Next

Qwen3.8-27B

DeepSeek V4 Flash

Einordnung

Das größte Modell gewinnt nicht.

DeepSeek V4 Flash ist größer, passt nur in 2 Bit — und liegt mit Drafter hinter dem viel kleineren Qwen3.8-27B.

Flaschenhals ist die Speicherbandbreite, nicht die Rechenleistung.

Sparse-MoE-Modelle gewinnen.

Die Stack-Wahl entscheidet über dasselbe Modell.

Größere DeepSeek-V4-Quantisierungen sprengen den Speicher.

Wie gemessen wird — PROFIL-v1

Die Regeln des Profils

Protokollierte Messläufe

Halogen gegen llama.cpp

Detailseiten

Qwen3.8-27B Deep-Dive→

Halogen→

Bild & Sprache→

Fallstricke→