Qwen3.8-27B: Frontier-Coding auf der eigenen Grafikkarte

Anfang August veröffentlichte Alibaba mit Qwen3.8-Max sein bisher grösstes Sprachmodell. 2,4 Billionen Parameter, davon rund 95 Milliarden pro Token aktiv, eine Million Tokens Kontext und ein deutlicher Fokus auf Coding, Agenten und längere autonome Arbeitsabläufe.¹

Das Modell war zunächst nur über Alibabas Infrastruktur verfügbar. Gleichzeitig kündigte das Qwen-Team etwas an, das für die Open-Weight-Szene wesentlich interessanter war: Die Gewichte sollten folgen.

Und nicht nur die des 2,4-Billionen-Modells.

Zusammen mit Qwen3.8-Max kündigte Alibaba auch Qwen3.8-27B an, eine wesentlich kleinere Variante mit 27 Milliarden Parametern. Genau auf dieses Modell wartete die Selfhosting-Community. Qwen3.6-27B hatte sich bereits einen ziemlich guten Ruf als lokales Coding- und Agentenmodell erarbeitet.

Die Veröffentlichung dauerte ein paar Tage länger als angekündigt. Zuerst erschienen die Gewichte von Qwen3.8-2.4T-A95B, am Freitag folgte schliesslich Qwen3.8-27B.²³

Bei Hugging Face lief vorher sogar ein Countdown.

Das sagt einiges darüber aus, welche Bedeutung Modelle dieser Grössenklasse inzwischen haben.

Das interessante Modell hat 27 Milliarden Parameter

2,4 Billionen Parameter sehen in einer Pressemitteilung beeindruckend aus.

Für lokales AI Engineering ist die Zahl eher theoretischer Natur.

Qwen3.8-Max ist ein Mixture-of-Experts-Modell mit ungefähr 95 Milliarden aktiven Parametern. Auch wenn bei jeder Inferenz nur ein Bruchteil der gesamten Gewichte aktiv ist, müssen die 2,4 Billionen Parameter irgendwo liegen.

Das ist kein Modell, das man mal eben auf einer RTX 5090 startet.

Qwen3.8-27B ist dagegen ein dichtes Modell. Alle 27 Milliarden Parameter werden bei der Inferenz verwendet. Das ist rechnerisch weniger effizient als ein MoE mit vergleichbarer Gesamtgrösse, hat aber einen grossen praktischen Vorteil: Die Hardwareanforderungen sind berechenbar und liegen noch in einer Grössenordnung, die normale Workstations erreichen.²

Das Modell ist ausserdem multimodal und verarbeitet neben Text auch Bilder. Der native Kontext beträgt 262.144 Tokens und lässt sich auf ungefähr eine Million Tokens erweitern.²

Damit wird die Kombination interessant:

27 Milliarden Parameter
262k nativer Kontext
multimodal
Thinking
Tool Use
agentisches Coding
Open Weights

Vor zwei Jahren hätte man für diese Liste noch mehrere Modelle und ziemlich viel Infrastruktur gebraucht.

Heute kann sie auf einem Desktop-PC laufen.

Qwen setzt weiter auf die Hybridarchitektur

Auch bei der Architektur bleibt Qwen seiner aktuellen Linie treu.

Die 27B-Modelle verwenden keine reine Transformer-Architektur mehr, bei der jede Schicht vollständige Self-Attention berechnet. Stattdessen kombiniert Qwen Gated DeltaNet mit klassischen Attention-Schichten.²

Der Aufbau reduziert vereinfacht gesagt den Aufwand bei langen Kontexten.

Das ist gerade bei 262.000 Tokens relevant. Eine klassische Attention-Architektur wird mit wachsendem Kontext schnell teuer, sowohl beim Rechenaufwand als auch beim KV-Cache.

Qwens Hybridansatz verwendet deshalb überwiegend lineare beziehungsweise rekurrente Schichten und streut dazwischen vollständige Attention-Layer ein.

Das erklärt auch eine Besonderheit beim lokalen Betrieb: Das Modell selbst mag auf eine 24-GB-Karte passen, 262.000 Tokens Kontext passen deshalb noch lange nicht automatisch dazu.

Gewichte und Kontext konkurrieren um denselben VRAM.

Die Benchmarks sehen ziemlich gut aus

Wie üblich hat Qwen zusammen mit dem Modell eine grössere Benchmarktabelle veröffentlicht.

Und wie üblich sollte man sie mit der nötigen Vorsicht lesen.

Die Tendenz ist trotzdem deutlich.

Bei mehreren Coding- und Agenten-Benchmarks verbessert sich Qwen3.8-27B gegenüber Qwen3.6-27B erheblich. Die folgenden Werte stammen aus der von Qwen veröffentlichten Evaluation und sind damit Herstellerangaben, keine unabhängigen Messungen.²

Benchmark	Qwen3.6-27B	Qwen3.8-27B	Opus 4.6 Max
Terminal-Bench 2.1	63,4	73,0	78,2
SWE-bench Pro	53,5	61,7	53,4
NL2Repo-Bench	36,2	42,3	47,6
DeepSWE 1.1	—	42,2	—
QwenSWEBench	—	79,0	63,8

Gerade SWE-bench Pro ist bemerkenswert.

Qwen3.8-27B erreicht dort laut Qwen 61,7 Punkte. Claude Opus 4.6 Max liegt in derselben veröffentlichten Vergleichstabelle bei 53,4.

Das bedeutet nicht, dass Qwen3.8-27B plötzlich grundsätzlich besser programmiert als Claude Opus.

So funktionieren Benchmarks nicht.

Aber ein 27B-Open-Weight-Modell überhaupt in derselben Tabelle sinnvoll mit einem kommerziellen Frontier-Modell vergleichen zu können, wäre vor nicht allzu langer Zeit schon eine ziemlich gewagte Idee gewesen.

Bei Terminal-Bench ist Opus weiterhin deutlich vorne. Bei NL2Repo ebenfalls.

Das Bild ist also wesentlich interessanter als ein simples „Qwen schlägt Claude“.

Qwen3.8-27B ist nicht überall Frontier-Niveau.

Es kommt aber bei einzelnen realistischen Software-Engineering-Aufgaben erstaunlich nahe heran.

Ein Benchmark ist kein Programmierer

Gerade bei Coding-Modellen ist es verführerisch, aus solchen Tabellen direkt eine Rangliste abzuleiten.

Das funktioniert nur begrenzt.

Qwen verwendet für einige Tests konkrete Agent-Harnesses. Andere Anbieter veröffentlichen Ergebnisse mit anderen Toolsets, anderen maximalen Kontextgrössen, anderen Sampling-Parametern und teilweise anderen Versionen derselben Datensätze.

61,7 gegen 53,4 ist deshalb keine physikalische Messung wie 61,7 km/h gegen 53,4 km/h.

Für die Praxis sind andere Dinge mindestens genauso wichtig:

Wie zuverlässig editiert das Modell bestehende Dateien?

Verliert es nach 40 Tool Calls den Faden?

Erkennt es eigene Fehler?

Führt es Tests tatsächlich aus?

Überarbeitet es Code, wenn eine erste Lösung nicht funktioniert?

Wie viel Kontext braucht es dafür?

Wie viele Tokens verbrennt es beim Nachdenken?

Diese Eigenschaften bekommt man aus einem Leaderboard nur teilweise heraus.

Die ersten Erfahrungsberichte aus der lokalen Community fallen allerdings auffällig positiv aus. Besonders Coding, Tool Use und längere agentische Aufgaben werden immer wieder genannt.

Gleichzeitig taucht eine Kritik ebenfalls regelmässig auf:

Qwen3.8 denkt gerne sehr lange nach.

Thinking kann teuer werden, auch wenn Tokens kostenlos sind

Das klingt bei einem lokalen Modell zunächst paradox.

Wenn das Modell auf der eigenen GPU läuft, kostet ein zusätzlicher Output-Token schliesslich keine API-Gebühr.

Kostenlos ist er trotzdem nicht.

Er kostet Zeit.

Qwen3.8 unterstützt unterschiedliche Reasoning-Stufen. Je höher das Thinking Budget, desto länger darf das Modell eine Aufgabe intern bearbeiten.

Bei schwierigen Coding-Aufgaben kann das sinnvoll sein.

Bei einfachen Aufgaben wird es schnell absurd.

Aus frühen Community-Tests gibt es Beispiele, bei denen das Modell zehntausende Tokens in Planung, Implementierung, Tests und erneute Überarbeitung steckt.

Für einen autonomen Coding-Agenten ist das nicht unbedingt schlecht. Wenn ich eine Aufgabe abgebe und das Modell danach zehn Minuten selbstständig programmiert, testet und Fehler korrigiert, ist mir das möglicherweise lieber als eine schnelle, aber falsche Antwort.

Für:

Schreibe mir eine equals()-Methode.

brauche ich dagegen keine philosophische Abhandlung über Objektidentität.

Die Wahl des Reasoning Levels wird deshalb bei lokalen Agenten genauso wichtig wie die Wahl des Modells selbst.

Quantisierung macht aus 27B ein Desktop-Modell

Unquantisiert benötigt Qwen3.8-27B deutlich mehr Speicher, als typische Consumer-Grafikkarten besitzen.

Mit Quantisierung ändert sich das.

Dabei werden die Modellgewichte nicht mehr mit 16 oder 32 Bit Genauigkeit gespeichert, sondern beispielsweise mit vier, fünf oder acht Bit. Der Speicherbedarf sinkt entsprechend stark.

Das kostet prinzipiell Genauigkeit.

Wie viel davon in der Praxis relevant ist, hängt allerdings stark vom Quantisierungsverfahren und vom jeweiligen Modell ab.

Kurz nach Veröffentlichung waren bereits zahlreiche GGUF-Varianten verfügbar. Unsloth veröffentlichte praktisch unmittelbar eigene Quantisierungen und gibt für seine kleinsten brauchbaren Varianten einen Speicherbedarf ab ungefähr 17 GB an.⁴

Damit wird es interessant für normale Grafikkarten.

Grob sieht die Landschaft so aus:

Variante	Ungefährer Speicherbedarf nur für Gewichte	Sinnvolle Hardware
BF16	> 50 GB	Workstation / Multi-GPU
Q8	~30 GB	32-GB-GPU oder mehr
Q5	~20–22 GB	24-GB-GPU
Q4	~17 GB	20–24 GB, aggressiver auch 16 GB
sehr aggressive 3/4-Bit-Quants	< 16 GB möglich	16-GB-Karten

Hinzu kommt der KV-Cache.

Und der wird bei langen Kontexten relevant.

24 GB reichen. Für alles reichen sie nicht.

Die Aussage „Qwen3.8 läuft auf 24 GB VRAM“ ist korrekt und gleichzeitig etwas irreführend.

Das Modell läuft.

Aber 262.144 Tokens Kontext gleichzeitig im VRAM zu halten, ist eine andere Geschichte.

Für die vollständigen Attention-Schichten wächst der KV-Cache mit der Kontextlänge. Aus der veröffentlichten Architektur ergibt sich bei FP16-KV für den vollen nativen Kontext eine Grössenordnung von rund 16 GB zusätzlich zu den Gewichten.²

Das bedeutet:

~17–22 GB Modell
+
mehrere GB KV-Cache
+
Runtime-Overhead

Auf einer RTX 3090 oder 4090 mit 24 GB muss man sich deshalb entscheiden.

Entweder eine kleinere Quantisierung.

Oder weniger Kontext.

Oder quantisierter KV-Cache.

Oder Teile des Modells beziehungsweise des Caches liegen im normalen RAM.

Das ist kein spezielles Qwen-Problem. Es zeigt nur wieder, warum „Modell passt in VRAM“ bei LLMs eine ziemlich unvollständige Aussage ist.

Für Coding-Agenten sind 64k oder 128k Kontext ohnehin oft sinnvoller als 262k ungefiltertes Repository.

Context Engineering verschwindet nicht, nur weil das Modell theoretisch eine Million Tokens akzeptiert.

Blackwell bekommt eine eigene Abkürzung

Besonders interessant für aktuelle Nvidia-Hardware ist NVFP4.

Das Format ist für Blackwell-GPUs optimiert und verwendet sehr niedrig aufgelöste Floating-Point-Gewichte, kombiniert mit zusätzlichen Skalierungsinformationen.⁵

Unsloth hatte eine entsprechende Qwen3.8-Quantisierung praktisch zum Release fertig.⁴

Der praktische Vorteil ist weniger Speicherbedarf und auf passender Hardware hoher Durchsatz. Gleichzeitig ist das Ökosystem noch jung genug, dass Runtime, Kernel und Quantisierungsvariante einen erheblichen Unterschied machen können.

Ein lokales 27B-Modell muss jedenfalls längst nicht mehr mit fünf Tokens pro Sekunde vor sich hin kriechen.

Und dann gibt es noch MTP

Qwen trainiert seine neueren Modelle mit Multi-Token Prediction.

Ein klassisches autoregressives Modell erzeugt konzeptionell:

Token 1
-> Token 2
-> Token 3
-> Token 4

Jeder Schritt hängt vom vorherigen ab.

Mit Multi-Token Prediction lernt das Modell zusätzlich, mehrere zukünftige Tokens vorauszusagen. Eine Inference Engine kann diese Vorhersagen für speculative decoding verwenden.

Wenn sie stimmen, werden mehrere Tokens auf einmal akzeptiert.

Das erhöht die effektive Generierungsgeschwindigkeit, ohne dafür ein zweites grosses Draft-Modell starten zu müssen.

Gerade bei lokalem Coding ist das interessant. Quellcode ist vergleichsweise vorhersehbar. Ein Modell kann bei:

public static void main(

recht gut erraten, wie es weitergeht.

Die Unterstützung dafür ist direkt nach einem Model Release allerdings erfahrungsgemäss noch etwas experimentell. llama.cpp, vLLM und SGLang entwickeln sich momentan fast genauso schnell wie die Modelle, die sie ausführen sollen.

Wer Qwen3.8 am ersten Wochenende installiert hat, durfte deshalb auch wieder die traditionelle Open-Weight-Erfahrung geniessen:

Modell veröffentlicht.

Runtime unterstützt es fast.

GitHub Issue.

Patch.

Neuer Build.

Jetzt geht es.

Open Weights sind hier mehr als ein Marketingpunkt

Die offene Veröffentlichung ist für mich fast genauso relevant wie die Benchmarkzahlen.

Das Modell kann lokal betrieben und in eigene Anwendungen integriert werden. Für Unternehmen entsteht damit eine Alternative zu API-Modellen, bei der Prompts und Dokumente das eigene System nicht verlassen müssen.

Das ist nicht für jede Anwendung automatisch besser.

Eine lokale GPU kostet Geld. Inference muss betrieben werden. Updates, Monitoring und Skalierung verschwinden nicht.

Aber die Kostenstruktur ändert sich.

Bei einer API bezahle ich:

Tokens

Bei Selfhosting bezahle ich:

Hardware
+ Strom
+ Betrieb

Dafür wird der einzelne zusätzliche Token praktisch kostenlos.

Genau bei agentischen Workloads kann das interessant werden.

Ein Coding-Agent, der bei einer Aufgabe 80.000 Reasoning-Tokens produziert, ist über eine API möglicherweise teuer.

Lokal ist er hauptsächlich langsam.

Das ist ein ziemlich anderer Trade-off.

Qwen3.8-Max ist trotzdem interessant

Der kleine Bruder sollte nicht völlig vom eigentlichen Flaggschiff ablenken.

Qwen3.8-Max ist mit 2,4 Billionen Parametern und 95 Milliarden aktiven Parametern eines der grössten öffentlich verfügbaren Modelle überhaupt.¹³

Alibaba positioniert es ausdrücklich für lange autonome Abläufe, Coding und professionelle Wissensarbeit. Das Modell unterstützt eine Million Tokens Kontext und soll Aufgaben über sehr lange Agententrajektorien bearbeiten können.

In Qwens eigener Evaluation erreicht Max beispielsweise 86,6 Punkte auf Terminal-Bench 2.1.¹

Das ist Frontier-Territorium.

Aber die praktische Bedeutung der offenen Gewichte ist eine andere als beim 27B-Modell.

Niemand lädt 2,4 Billionen Parameter herunter, weil er noch etwas Platz auf seiner Gaming-GPU hat.

Open Weights sind hier vor allem für Forschungseinrichtungen, Unternehmen und Betreiber grösserer GPU-Infrastruktur relevant.

Beim 27B-Modell bedeuten Open Weights dagegen tatsächlich:

huggingface download
llama.cpp
fertig

Zumindest nachdem man die üblichen Release-Day-Probleme gelöst hat.

Der interessante Wettbewerb findet inzwischen lokal statt

Qwen3.8-27B ist nicht das beste Sprachmodell der Welt.

Das muss es auch nicht sein.

Die spannendere Frage ist, wie gross der Abstand zwischen einem lokal betreibbaren Modell und den kommerziellen Frontier-Modellen noch ist.

Vor zwei Jahren war die Antwort einfach: sehr gross.

Heute hängt sie von der Aufgabe ab.

Bei komplexem Reasoning, schwierigen Agentenabläufen und manchen Coding-Aufgaben bleiben Claude, GPT und andere Frontier-Modelle vorne.

Bei anderen Aufgaben liegt Qwen3.8-27B überraschend nahe dran oder erreicht in den veröffentlichten Benchmarks sogar bessere Ergebnisse.

Und das auf Hardware, die ursprünglich für Computerspiele verkauft wurde.

Das ist für mich die eigentlich bemerkenswerte Entwicklung.

Nicht, dass Alibaba ein Modell mit 2,4 Billionen Parametern trainiert hat, sondern dass parallel dazu ein Modell mit 27 Milliarden Parametern erscheint, bei dem man ernsthaft darüber diskutieren kann, ob für einen Coding-Agenten überhaupt noch eine Cloud-API notwendig ist.

Fazit

Qwen3.8 zeigt ziemlich gut, wie schnell sich die Open-Weight-Landschaft momentan bewegt.

Das Max-Modell demonstriert, dass auch Modelle in der absoluten Frontier-Grössenklasse nicht zwangsläufig geschlossen bleiben müssen.

Qwen3.8-27B ist für die Praxis aber wahrscheinlich wichtiger.

27 Milliarden Parameter sind gross genug, um anspruchsvolle Coding- und Agentenaufgaben zu lösen, aber klein genug, um quantisiert auf einer einzelnen Consumer-GPU zu laufen.

Dazu kommen Multimodalität, langer Kontext und steuerbares Reasoning.

Die Benchmarks sehen hervorragend aus. Wie viel davon sich im Alltag bestätigt, werden die nächsten Wochen zeigen.

Bereits jetzt ist aber eine Grenze sichtbar verschoben worden: Lokale Modelle müssen nicht mehr nur daran gemessen werden, ob sie für ihre Grösse erstaunlich gut sind.

Bei einem Modell wie Qwen3.8-27B kann man für einzelne Workloads inzwischen ernsthaft prüfen, ob das grosse API-Modell überhaupt noch einen ausreichenden Mehrwert bietet.

Footnotes#

1. Qwen / Alibaba: Qwen3.8-Max announcement and evaluation, August 2026. ↩ ↩² ↩³

2. Qwen: Qwen3.8-27B, Hugging Face, August 2026. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

3. Qwen: Qwen3.8-2.4T-A95B, Hugging Face, August 2026. ↩ ↩²

4. Unsloth: Qwen3.8-27B NVFP4, Hugging Face, August 2026. ↩ ↩²

5. NVIDIA: Introducing NVFP4 for efficient and accurate low-precision inference. ↩