Qwen3.8-27B: ein Spitzenmodell, das dir gehört

Am 14. August 2026 hat Alibaba die offenen Gewichte von Qwen3.8-27B unter Apache 2.0 veröffentlicht. 27 Milliarden Parameter, nativ multimodal, 262K Kontext ab Werk. Ein Modell, das für die tägliche Arbeit gut genug ist und trotzdem auf eine einzelne Maschine passt, die dir gehört. Diese Kombination gab es bisher nicht.

Dank​

Danke an Selim Kirbiyik, der die RTX PRO 6000 zur Verfügung gestellt hat, auf der die GPU-Benchmarks gelaufen sind. Der Dell DGX Spark kam über Fraiss und Cancom Austria zu uns, die uns die Maschine für diese Messungen überlassen haben.

Was dieses Release wirklich ändert​

Die meisten interessanten Open-Weight-Modelle der letzten zwei Jahre waren entweder zu klein, um nützlich zu sein, oder zu groß, um sie selbst zu hosten. Ein Mixture-of-Experts-Modell mit hunderten Milliarden Parametern ist technisch gesehen „offen", aber du brauchst trotzdem ein Rack, um es zu betreiben. Qwen3.8-27B ist ein dichtes Modell, jeder Parameter ist also bei jedem Token aktiv, und 27 Milliarden davon passen in eine Maschine, die weniger kostet als ein Firmenwagen.

Zwei Details sind wichtiger als die Parameterzahl. Das Kontextfenster fasst nativ 262.144 Token und lässt sich mit YaRN-Skalierung auf rund eine Million erweitern. Das reicht, um dem Modell ein komplettes mittelgroßes Repository vorzulegen. Und die Lizenz ist Apache 2.0, keine dieser „offen, aber"-Community-Lizenzen. Du darfst es betreiben, verändern und kommerziell nutzen, auf deiner eigenen Hardware, ohne jemanden zu fragen.

Genau darum geht es uns. Unternehmen kommen zu uns, weil ihre Rechtsabteilung Cloud-KI blockiert hat, nicht weil sie einen GPU-Cluster bauen wollten. Ein leistungsfähiges Modell unter einer freizügigen Lizenz, betrieben auf Hardware, die ihnen ohnehin gehört: So soll KI on-premise aussehen.

Eine ehrliche Einschränkung: Alle Launch-Benchmarks, die du bisher gelesen hast, kommen von Qwen selbst, und mehrere der Suiten sind hauseigen oder angepasst. Das ist kein Vorwurf, so laufen Modell-Launches nun einmal. Es ist aber der Grund, warum wir selbst gemessen haben.

Den llama.cpp-Server aufsetzen​

Im Artikel zum Framework Desktop haben wir noch Ollama verwendet. Inzwischen läuft bei uns auch die tägliche Inferenz auf llama.cpp. Der Grund ist derselbe wie bei diesem Test: Ollama versteckt genau die Stellschrauben, an denen wir drehen wollten. Welche Quantisierungsdatei geladen wird, wie viele Layer auf die GPU gehen, mit welcher Präzision der KV-Cache arbeitet und wie viel Kontext tatsächlich reserviert wird.

llama-server \
  -hf unsloth/Qwen3.8-27B-GGUF:UD-Q4_K_XL \
  --alias qwen3.8-27b \
  --n-gpu-layers 99 \
  --ctx-size 262144 \
  --flash-attn on \
  --parallel 1 \
  --spec-type draft-mtp --spec-draft-n-max 4 \
  --temp 0.7 --top-p 0.8 --presence-penalty 1.5 \
  --host 0.0.0.0 --port 8080
# srv  llama_server: model loaded

Das ist die komplette Konfiguration. --n-gpu-layers 99 schiebt alle Layer auf die GPU, --ctx-size 262144 reserviert den vollen nativen Kontext des Modells, --flash-attn on aktiviert Flash Attention, und --parallel 1 lässt den Server mit einem einzigen Slot laufen.

Die Sampling-Werte sind die, die Qwen für den Nicht-Thinking-Modus empfiehlt. Im Thinking-Modus will Qwen stattdessen --temp 1.0 --top-p 0.95, und der Unterschied ist nicht kosmetisch: Thinking-Modus mit 0.7 macht das Modell wortkarg und merklich schwächer bei mehrstufigem Denken.

Beachte, was nicht dort steht. Es gibt kein --cache-type-k und kein --cache-type-v, der KV-Cache läuft also in voller Präzision. Warum, gleich.

llama-server spricht die OpenAI-API, alles was bei uns vorher auf Ollama gezeigt hat, funktioniert unverändert weiter. Deshalb war der Umstieg schmerzlos.

Die Quants kommen von Unsloth​

Wir haben das Modell nicht selbst quantisiert. Die GGUF-Dateien stammen von unsloth/Qwen3.8-27B-GGUF und wurden mit Unsloth Dynamic V3.0 gebaut.

Kurz gesagt, warum das wichtig ist: Ein flacher 4-Bit-Quant behandelt jeden Layer gleich, was an manchen Stellen Verschwendung und an anderen Zerstörung ist. Ein dynamischer Quant misst, welche Layer empfindlich sind, hält diese auf höherer Präzision und drückt den Rest dafür stärker herunter. Am Ende steht ungefähr dieselbe Dateigröße bei messbar geringerem Qualitätsverlust, und bei einem 27B-Modell in 4 Bit ist das der Unterschied zwischen „taugt zum Programmieren" und „fast, aber ich hätte es schneller selbst geschrieben".

Die vollen BF16-Gewichte liegen bei etwa 55 GB. Die Datei, die bei uns läuft, UD-Q4_K_XL, ist 16,68 GiB groß. Das sollte man deutlich sagen, weil es viele auf dem falschen Fuß erwischt: Wenn die Gewichtsdatei in den VRAM passt, passt noch lange nicht das Modell. KV-Cache, Aktivierungen und der Vision-Encoder wollen zusätzlich Speicher, und beim vollen Kontext von 262.144 Token ist allein der Cache um ein Vielfaches größer als die quantisierten Gewichte. Mit 96 GB auf der Karte war für alles Platz, in voller Präzision, also haben wir den Cache in Ruhe gelassen. Auf einer kleineren GPU ist das der erste Hebel: --cache-type-k q8_0 --cache-type-v q8_0 halbiert ihn ungefähr, auf Kosten der Qualität bei langem Kontext.

Multi-Token Prediction​

Die zwei --spec--Flags im Befehl oben sind der größte Geschwindigkeitshebel in diesem Setup, und sie kosten nichts.

Qwen3.8 wurde mit einer kleinen zusätzlichen Vorhersageschicht trainiert, dem Multi-Token-Prediction-Head, und die steckt bereits im GGUF. llama.cpp nutzt sie als eingebauten Souffleur für spekulatives Dekodieren: Der Souffleur flüstert die nächsten Token voraus, das volle Modell prüft den ganzen Schwung in einem einzigen Durchlauf, und jeder Treffer ist ein Token, den du geschenkt bekommst. Übliches spekulatives Dekodieren braucht dafür ein zweites, kleineres Modell daneben. Hier gibt es kein zweites Modell, und der Draft-Kontext, den llama.cpp daneben aufspannt, kostet nur einen Bruchteil dessen, was das Modell selbst belegt.

--spec-type draft-mtp schaltet das Ganze ein, --spec-draft-n-max legt fest, wie viele Token der Souffleur vorausflüstern darf. Wir sind mit 4 gefahren. Tiefer zu raten ist nicht automatisch besser: Jeder verworfene Vorschlag ist Arbeit, die die GPU umsonst gemacht hat. Der optimale Wert verschiebt sich also mit der Speicherbandbreite und damit, wie vorhersagbar der Text ist. Zwei ist der konservative Startwert, den die meisten Anleitungen nennen. Auf einer Karte dieser Größe hat sich vier ausgezahlt.

Wie sehr, sagt dir der Server direkt. Über eine lange Generierung meldete er 72% angenommene Draft-Token bei einer mittleren angenommenen Länge von 3,89 Token. Über eine ganze Arbeitssitzung schwankte diese Quote zwischen 0,39 und 0,94, im Mittel 0,59. Was das mit dem tatsächlichen Durchsatz macht, steht weiter unten.

--parallel 1 steht dort, weil der Draft-Pfad einen einzelnen Slot will. Mit mehreren Slots sinkt die Trefferquote.

Drei sehr unterschiedliche Maschinen​

Wir haben auf zwei Systemen getestet, die dasselbe Problem von entgegengesetzten Seiten lösen, dazu kam spät eine dritte Maschine.

Das erste ist eine Workstation mit einer NVIDIA RTX PRO 6000 Blackwell Workstation Edition, der Karte von Selim. 96 GB dedizierter VRAM, Compute Capability 12.0. Das Modell, sein KV-Cache beim vollen nativen Kontext und alles Übrige passten gleichzeitig auf die Karte, mit Luft nach oben. Hier läuft llama.cpp über das CUDA-Backend.

Das zweite ist der Framework Desktop aus dem FPGA-Artikel: ein Ryzen AI Max+ 395 (Strix Halo) mit 128 GB LPDDR5X-8000, geteilt zwischen CPU und GPU. Auf dem Papier sind das 256 GB/s über einen 256-Bit-Bus, in der Praxis etwa 215 GB/s. Was das für die Ausgabegeschwindigkeit bedeutet, zeigen die Messungen weiter unten sehr direkt: Decode läuft hier rund sechsmal langsamer als auf der dedizierten Karte. Dafür gibt es mehr nutzbaren Speicher und einen Bruchteil an Stromverbrauch und Lautstärke. Auf dieser Maschine haben wir llama.cpp zweimal gebaut, einmal gegen ROCm und einmal gegen Vulkan. Beide legen die Arbeit auf die integrierte RDNA-3.5-GPU, und welches der beiden vorne liegt, hängt von der Kontexttiefe ab.

Eine dritte Maschine ist spät dazugekommen und bekommt weiter unten einen kurzen eigenen Abschnitt: ein DGX Spark mit NVIDIAs GB10 Grace Blackwell Superchip und 128 GB Unified LPDDR5X. Bisher ist darauf nur der Standard-Benchmark gelaufen, im Rest des Artikels kommt er deshalb nicht vor.

Drei Backends also: CUDA, ROCm und Vulkan, angesteuert mit denselben Flags. Die interessante Frage ist nicht, welche Maschine gewinnt, sondern ob die günstige schnell genug ist, um nützlich zu sein.

Benchmarks​

llama-bench liefert die saubere Grundlinie. Kein spekulatives Dekodieren, kein Chat-Template, kein Client. Nur Prefill und Decode, gemessen bei mehreren Kontexttiefen.

Die -d-Liste ist der Trick, den man sich abschauen sollte. Jeder Wert ist eine Kontexttiefe, die vor der Messung gefüllt wird. Ein einziger Lauf liefert damit die ganze Kurve vom leeren bis zum fast vollen Kontext statt einer Zahl, die nur den Bestfall beschreibt.

pp512 ist Prefill, also wie schnell das Modell liest. tg128 ist Decode, also wie schnell es schreibt.

RTX PRO 6000, CUDA​

llama-bench -m Qwen3.8-27B-UD-Q4_K_XL.gguf -d 0,512,10000,100000,250000
# ggml_cuda_init: found 1 CUDA devices (Total VRAM: 97285 MiB):
#   Device 0: NVIDIA RTX PRO 6000 Blackwell Workstation Edition, compute capability 12.0, VMM: yes

Kontexttiefe	Prefill pp512 (T/s)	Decode tg128 (T/s)
0	4126,92 ± 104,05	74,73 ± 0,14
512	4131,61 ± 124,87	74,79 ± 0,12
10.000	3780,64 ± 99,17	72,13 ± 0,28
100.000	1955,39 ± 28,07	56,97 ± 0,03
250.000	1049,22 ± 9,96	42,29 ± 0,04

Decode merkt von den ersten zehntausend Token kaum etwas und zahlt danach für den Cache: 57 T/s bei 100K, 42 T/s bei 250K. Prefill fällt über dieselbe Spanne um den Faktor vier. Ehrlich gelesen heißt das: Der lange Kontext ist nicht gratis. Aber selbst der schlechteste Wert hier liegt weit über Lesegeschwindigkeit, während die Maschine eine Viertelmillion Token hält.

Framework Desktop, Vulkan gegen ROCm​

Auf dem Framework Desktop haben wir denselben Lauf zweimal gemacht, einmal gegen Vulkan und einmal gegen ROCm. Dieselbe Quant-Datei, dieselben Tiefen.

./llama-bench -hf unsloth/Qwen3.8-27B-GGUF:UD-Q4_K_XL -d 0,512,10000,100000
# ggml_vulkan: 0 = AMD Radeon 8060S Graphics (RADV STRIX_HALO) | uma: 1 | matrix cores: KHR_coopmat
# ggml_cuda_init: found 1 ROCm devices: Device 0: AMD Radeon 8060S Graphics, gfx1151, VRAM: 98304 MiB

Alle Werte in Token pro Sekunde.

Kontexttiefe	Vulkan pp512	Vulkan tg128	ROCm pp512	ROCm tg128
0	365,24 ± 0,47	12,33 ± 0,00	378,24 ± 3,27	12,06 ± 0,01
512	358,86 ± 4,26	12,30 ± 0,00	370,14 ± 3,10	12,04 ± 0,01
10.000	299,01 ± 1,49	11,84 ± 0,00	311,05 ± 2,19	11,66 ± 0,01
100.000	41,57 ± 0,16	9,00 ± 0,00	121,85 ± 0,33	9,05 ± 0,00

Bei kurzem Kontext ist die Wahl des Backends beinahe egal. ROCm liest knapp 4% schneller, Vulkan schreibt gut 2% schneller, beides liegt in einem Bereich, in dem sich die Entscheidung nicht lohnt.

Bei 100.000 Token dreht sich das. Prefill hält unter ROCm 121,85 T/s, unter Vulkan bricht es auf 41,57 T/s ein, Faktor 2,9. Decode ist an derselben Stelle praktisch identisch, 9,05 gegen 9,00 T/s. Das ist die eigentliche Lehre aus dem Vergleich: Das Backend entscheidet nicht darüber, wie schnell die Maschine schreibt, sondern nur darüber, wie schnell sie einen langen Prompt einliest. Wer auf Strix Halo mit kurzen Prompts arbeitet, kann beide nehmen. Wer dem Modell ganze Repositories vorlegt, will ROCm.

Warum sich Decode nicht bewegt, lässt sich nachrechnen. Für jedes Token muss die Gewichtsdatei einmal komplett durch den Speicher, und bei 12,06 bis 12,33 T/s kommt man damit auf gut 200 GB/s. Die Maschine liefert in der Praxis etwa 215 GB/s. Decode läuft hier also am Anschlag der Speicherbandbreite, nicht am Anschlag des Treibers. Daran ändert kein Backend etwas, nur ein anderes Speichersystem.

Im Vergleich mit der RTX PRO 6000 zeigt sich derselbe Effekt von der anderen Seite. Decode liegt über alle gemessenen Tiefen bei ungefähr Faktor sechs zugunsten der dedizierten Karte, er wandert nur von 6,1 auf 6,3, und ein Verhältnis, das sich mit der Tiefe kaum bewegt, ist genau die Signatur einer Bandbreitengrenze. Prefill beginnt bei Faktor elf und öffnet sich bis 100K auf Faktor sechzehn.

Praktisch heißt das: Mit 12 T/s schreibt der Framework Desktop schneller, als eine einzelne Person liest. Was er kostet, ist die Wartezeit vor dem ersten Token. Rechnet man die Kurve hoch, liegt ein kalter Prompt über 100.000 Token auf dieser Maschine im Minutenbereich, auf der RTX PRO 6000 unter einer Minute. Bei Chat und einzelnen Dateien fällt das nicht auf, bei „lies dieses Repository" schon.

Was hier noch fehlt: eine Arbeitssitzung mit MTP-Souffleur auf dieser Maschine. Die Zahlen im nächsten Abschnitt stammen alle von der RTX PRO 6000, und der Faktor von rund 1,8, den spekulatives Dekodieren dort gebracht hat, ist auf Strix Halo nicht gemessen.

DGX Spark, GB10​

./llama-bench -hf unsloth/Qwen3.8-27B-GGUF:UD-Q4_K_XL -d 0,512,10000,100000,250000
# ggml_cuda_init: found 1 CUDA devices (Total VRAM: 124546 MiB):
#   Device 0: NVIDIA GB10, compute capability 12.1, VMM: yes, VRAM: 124546 MiB

Kontexttiefe	Prefill pp512 (T/s)	Decode tg128 (T/s)
0	837,56 ± 8,91	12,56 ± 0,00
512	834,95 ± 7,32	12,54 ± 0,01
10.000	783,19 ± 3,75	12,07 ± 0,01
100.000	502,12 ± 1,31	9,06 ± 0,01
250.000	316,77 ± 1,05	6,43 ± 0,01

Die Decode-Spalte ist die Überraschung. In jeder Tiefe schreibt der GB10 auf zwei Prozent genau so schnell wie der Framework Desktop: 12,56 gegen 12,33 T/s bei leerem Kontext, 9,06 gegen 9,00 bei 100K. Zwei Maschinen aus völlig verschiedenen Preisklassen, dasselbe Ergebnis, weil beide ihre Gewichte aus LPDDR5X ziehen und sonst nichts sie bremst.

Beim Prefill spielt der Spark seine Stärke aus. Er liest bei kurzem Kontext 2,2-mal schneller als der Framework, bei 100K wächst der Abstand auf das 4,1-Fache, dort wo der Vulkan-Pfad des Framework einbricht. Unser Lauf ging außerdem bis 250K, was wir auf dem Framework nicht gemessen haben.

Gegen die RTX PRO 6000 landet er bei ungefähr Faktor fünf beim Prefill und Faktor sechs beim Decode. Dieselbe Bandbreiten-Geschichte, jetzt aus einer dritten Perspektive.

Beim echten Programmieren​

Benchmarks messen Durchsatz. Sie sagen dir nicht, ob sich das Modell im Alltag lohnt.

In den Coding-Suiten aus Qwens eigener Modellkarte (Referenz) liegt Qwen3.8-27B ungefähr auf dem Niveau von Opus 4.6.

Dass sich 27 Milliarden Parameter auf einer Maschine unter deinem Schreibtisch mit einem gehosteten Spitzenmodell messen, ist ein merkwürdiger Satz zum Schreiben. Ob das außerhalb einer Benchmark-Umgebung standhält, ist der Teil, der uns wirklich interessiert. Also haben wir den Server durch eine normale Arbeitssitzung laufen lassen und die Zahlen danach ausgelesen.

96 Anfragen, der Kontext wuchs bis auf gut 101.000 Token, der größte einzelne Prefill umfasste 89.741 Token.

	Median	Spanne
Generierung	134,9 T/s	86 bis 194
Prefill, Prompts über 1.000 Token	2.368 T/s	1.549 bis 3.662
Draft-Trefferquote	0,67	0,39 bis 0,94

Die Zahl zur Generierung ist die, bei der man kurz sitzen bleiben sollte. llama-bench maß 74,7 T/s Decode bei leerem Kontext ohne spekulatives Dekodieren. Im echten Betrieb, mit dem MTP-Souffleur und einem Kontext jenseits von 100K Token, lag der Median bei 134,9 T/s. Das spekulative Dekodieren hat den langen Kontext mehr als bezahlt.

Die Spannweite ist die andere Hälfte der Geschichte, und sie erklärt sich fast vollständig über die Draft-Trefferquote. Anfragen, bei denen 85% oder mehr der vorgeschlagenen Token angenommen wurden, liefen im Median mit 169 T/s und in der Spitze mit 194. Anfragen unter 45% Trefferquote lagen im Median bei 94 T/s. Über alle 96 Anfragen laufen Trefferquote und Durchsatz eng miteinander (r = 0,88).

Das ist die ehrliche Form von spekulativem Dekodieren: kein gleichmäßiger Geschwindigkeitsfaktor, sondern eine Wette, die sich auszahlt, wenn die nächsten Token erratbar sind, und die kostet, wenn sie es nicht sind. Dasselbe Modell, dieselben Flags, Faktor zwei zwischen gutem und schlechtem Fall.

Fazit​

Ein dichtes 27B-Modell unter Apache 2.0 mit einem derart großen Kontextfenster macht aus selbst gehosteter KI eine echte Option statt eines Compliance-Notbehelfs. Praktikabel wird das durch llama.cpp und einen guten dynamischen Quant, und die Builds von Unsloth nehmen dir den Großteil dieser Arbeit ab. Aus 75 T/s werden durch den eingebauten MTP-Souffleur im echten Betrieb im Median 135. Rechne das bei der Hardware-Auswahl mit ein. Ob du eine dedizierte GPU brauchst oder ob geteilter Speicher reicht, entscheidet sich weniger am Schreibtempo als an der Wartezeit vor dem ersten Token und daran, wie viele Leute gleichzeitig auf eine Antwort warten. Der Framework Desktop schreibt für eine einzelne Person schnell genug, liest einen 100K-Prompt aber sechzehnmal langsamer ein als die RTX PRO 6000.

Referenzen​

1. Qwen. (2026). Qwen3.8-27B model card. Abgerufen am 19.08.2026 von Qwen/Qwen3.8-27B