Qwen3.8-27B im On-Premise-Test: frontier-nahes Agentic Coding auf einer einzigen 24-GB-GPU
Mit Qwen3.8-27B steht seit dem 14. August 2026 erstmals ein dichtes Multimodal-Modell unter Apache 2.0 bereit, das 4-Bit-quantisiert auf eine einzelne RTX 3090 oder 4090 passt – bei Benchmarkwerten, die vor einem Jahr Frontier-Niveau waren. Wir rechnen VRAM-Budget, Kontextlänge und Durchsatz konkret durch.
RTX 3090 @ 250 W
Ja, Qwen3.8-27B läuft auf einer 24-GB-Karte – aber nur 4-Bit-quantisiert: Die Q4_K_M-Gewichte belegen 17,11 GB, mit Runtime-Puffern und 8K bis 32K Kontext real 19 bis 21 GB. Die BF16-Gewichte umfassen 55,58 GB.
Das volle native Kontextfenster von 262.144 Tokens passt dagegen nicht auf 24 GB; dafür sind 34 GB und mehr nötig. Und die kursierenden 114 Tokens/s stammen aus einem stark gepatchten vLLM-Stack, nicht aus einer Standardinstallation.
Am 14. August 2026 um 15:00 UTC hat Alibabas Qwen-Team Qwen3.8-27B veröffentlicht – ein dichtes Vision-Language-Modell mit exakt 27.781.427.952 Parametern, mit Vision-Encoder rund 28 Milliarden. Innerhalb von Tagen stand der GGUF-Build auf Platz 3 der Trending-Modelle bei Hugging Face; die Community meldete über eine Million Downloads. Die Zahl ist nicht von Qwen bestätigt, aber der Trend ist eindeutig.
Interessant ist das Modell für den Mittelstand aus einem sehr konkreten Grund: Es ist das erste Modell dieser Leistungsklasse, das man in ein bestehendes Rack schieben kann, ohne vorher einen sechsstelligen Hardware-Antrag zu schreiben. Dieser Artikel rechnet nach, was das praktisch bedeutet – und wo die Marketing-Erzählung „passt auf eine 24-GB-Karte" zu kurz greift.
Was Qwen3.8-27B ist – und warum die Lizenz zählt
Qwen3.8-27B ist ein dichtes Modell, kein Mixture-of-Experts. Alle 27,78 Milliarden Parameter sind bei jedem Token aktiv. Das ist für den Eigenbetrieb ein Vorteil: Der Speicherbedarf ist vorhersehbar, es gibt kein Expert-Routing, das bei kleinen Batch-Größen ineffizient wird, und die Quantisierung verhält sich gutmütig.
Bild- und Videoverarbeitung sind nativ im selben Modell verankert, nicht über eine vorgeschaltete OCR-Pipeline. Für typische Mittelstandsaufgaben – Screenshots aus einem ERP-System interpretieren, Konstruktionszeichnungen auslesen, Weboberflächen agentisch bedienen – ist das der praktisch relevantere Teil als die reine Textqualität.
Apache 2.0 ist hier kein Detail
Die Gewichte stehen unter Apache 2.0. Das bedeutet: kommerzielle Nutzung, Modifikation und Weitergabe ohne Nutzerzahl-Schwellen, ohne Umsatzgrenzen, ohne Namensnennungspflicht im Produkt. Wer schon einmal die Lizenzbedingungen einer „Community License" durch die Rechtsabteilung getrieben hat, weiß, wie viel Projektzeit dieser eine Unterschied spart. Ein Fine-Tune auf eigenen Daten darf behalten und intern weitergegeben werden – ein Punkt, der bei restriktiveren Lizenzen regelmäßig scheitert.
Dazu kommt der reasoning_effort-Parameter: Das Modell lässt sich zwischen kurzem und ausführlichem Denkaufwand umschalten. Bei API-Anbietern ist das ein Kostenhebel. Im Eigenbetrieb ist es ein Latenz- und Auslastungshebel – dieselbe Karte bedient bei niedrigem Effort deutlich mehr gleichzeitige Anfragen.
VRAM-Budget richtig rechnen: Gewichte plus KV-Cache plus Overhead
Der häufigste Fehler bei der Hardware-Planung ist, nur die Gewichtsgröße zu betrachten. Das VRAM-Budget besteht aus drei Posten: Gewichte, KV-Cache und Runtime-Overhead (Aktivierungen, CUDA-Kontext, Fragmentierung). Als Faustregel gilt ein Aufschlag von 30 bis 50 Prozent auf die reine Gewichtsgröße.
Qwen selbst veröffentlicht nur zwei Builds: BF16 mit 55,58 GB (51,76 GiB, 18 Shards) und einen offiziellen FP8-Build mit 30,88 GB (28,76 GiB, blockweise quantisiert; rund 3,08 Mrd. Parameter bleiben in BF16). Sämtliche GGUF-Varianten stammen von Dritten – Unsloth und andere – und sind von Qwen nicht validiert. Wer sie produktiv einsetzt, sollte das eigene Eval-Set vorher und nachher durchlaufen lassen.
| Build | Gewichte | Herkunft | Passt auf |
|---|---|---|---|
| BF16 | 55,58 GB | Qwen (offiziell) | 80 GB (H100/H200) |
| FP8 | 30,88 GB | Qwen (offiziell) | 48 GB (L40S, RTX Pro 6000) |
| Q8_0 | 29,05 GB | Drittanbieter-GGUF | 48 GB |
| Q6_K | 22,88 GB | Drittanbieter-GGUF | 32 GB |
| Q5_K_M | 19,83 GB | Drittanbieter-GGUF | 24 GB (knapp) |
| Q4_K_M | 17,11 GB | Drittanbieter-GGUF | 24 GB (Sweet Spot) |
| NVFP4 | ca. 16,5 GB | nur Blackwell | 24/32 GB Blackwell |
| Q3_K_XL / Q2_K_XL | 13,44 / 10,68 GB | Drittanbieter-GGUF | 16 GB, Qualitätsverlust |
Warum langer Kontext hier überhaupt bezahlbar ist
Die Architektur erklärt den Rest. Qwen3.8-27B hat 64 Layer bei einer Hidden Size von 5.120, aufgebaut als 16-fache Wiederholung des Musters: dreimal Gated DeltaNet mit FFN, einmal Gated Attention mit FFN. Nur diese 16 Attention-Layer führen einen klassischen KV-Cache; die übrigen 48 Layer nutzen lineare Attention mit O(n)-Komplexität.
Genau das ist der Grund, warum die KV-Zahlen ungewöhnlich niedrig aussehen – sie sind es tatsächlich. Pro Sequenz in BF16: rund 0,5 GB bei 8K, rund 2 GB bei 32K, rund 8 GB bei 128K und rund 16 GB bei 262K. Ein FP8-KV-Cache halbiert das jeweils.
Die ehrliche 24-GB-Rechnung: Q4_K_M-Gewichte 17,1 GB + Runtime-Puffer + KV-Cache für 8K bis 32K Kontext ergeben real 19 bis 21 GB. Das passt. Der volle native 262K-Kontext passt nicht – dafür werden 34 GB und mehr gebraucht, weil allein der KV-Cache 16 GB belegt. Wer sparsamer fahren will: IQ4_XS liegt bei 15,7 GB Gewichten und rund 17,5 GB praktisch.
Das native Kontextfenster umfasst 262.144 Tokens und lässt sich per YaRN auf bis zu 1.000.000 skalieren. Wichtig: Qwen weist ausdrücklich darauf hin, dass statisches YaRN die Qualität bei kurzem Kontext verschlechtert. YaRN gehört also in ein separates Deployment für Langdokument-Aufgaben, nicht dauerhaft in die Standardkonfiguration.
Benchmarks einordnen statt abschreiben
Die von Qwen veröffentlichten Werte sind beeindruckend: Terminal-Bench 2.1 = 73,0, SWE-bench Pro = 61,7, LiveCodeBench v6 = 90,3, OSWorld-Verified = 84,3. Dazu GPQA Diamond 89,2, CharXiv Reasoning 90,2, AndroidWorld 81,9, Vision2Web 62,9, DeepSWE 1.1 42,2 und SWE-MM 38,6.
Der Sprung gegenüber dem Vorgänger Qwen3.6-27B ist real und groß:
| Benchmark | Qwen3.6-27B | Qwen3.8-27B | Claude Opus 4.8 | GPT-5.6 |
|---|---|---|---|---|
| Terminal-Bench 2.1 | 63,4 | 73,0 | 78,9 | 88,8 |
| SWE-bench Pro | 53,5 | 61,7 | 79,2 | 64,6 |
| LiveCodeBench v6 | 83,9 | 90,3 | – | – |
| OSWorld-Verified | 63,9 | 84,3 | – | – |
| DeepSWE 1.1 | 13,3 | 42,2 | – | – |
Was diese Zahlen nicht sagen
Sämtliche Startwerte stammen von Qwen selbst. Mehrere Tests sind hausintern oder modifiziert, und zum Launch gab es keine unabhängige Reproduktion. Das ist kein Vorwurf – das ist Branchenstandard –, aber es verbietet, die Werte als neutral gemessen zu behandeln.
Unabhängige Aggregatoren zeichnen ein differenzierteres Bild. BenchLM gibt 72,5 von 100 Punkten gesamt (Rang 14 von 225), Agentic 70,1 (Rang 6 von 137), Multimodal 79,8 (Rang 8 von 34) – aber Knowledge nur 49,0 (Rang 57 von 60). Das Modell ist stark im Handeln und schwach im Wissen. Für ein selbst gehostetes Coding- und Agentensystem ist das genau die richtige Verteilung; als reines Frage-Antwort-Modell über Faktenwissen ist es die falsche Wahl. Mit RAG gegen die eigene Dokumentenbasis fällt die Wissensschwäche kaum ins Gewicht.
Und im direkten Vergleich mit der Spitze bleibt eine Lücke: 73,0 gegen 78,9 (Claude Opus 4.8) und 88,8 (GPT-5.6) auf Terminal-Bench 2.1. „Frontier-nah" trifft es – „Frontier" nicht. Wer aus dieser Differenz ein Betriebsmodell ableiten will, sollte außerdem wissen, dass Kurzaufgaben-Benchmarks die Fähigkeiten bei stundenlangen Agentenläufen systematisch überschätzen: Fehler akkumulieren dort, wo ein 15-Minuten-Task noch sauber durchläuft.
Durchsatz in der Praxis: Single-User gegen 64 parallele Requests
Die viel zitierten Durchsatzzahlen stammen aus dem Apache-2.0-Repo syv-ai/qwen38-27b-rtx3090. Getestet wurde auf einer RTX 3090 mit 250 W Power-Limit unter vLLM 0.27.1:
- ca. 114 Tokens/s Single-User bei Default-Sampling und 64K Kontext
- 118 bis 124 Tokens/s bei Greedy Decoding
- 95 bis 100 Tokens/s bei 150K Kontext
- ca. 1.035 Tokens/s Steady-State-Decode bei 64 parallelen Requests
- 948 Tokens/s End-to-End bei realistischen Batch-Mustern
Der Ehrlichkeits-Absatz: Was dahintersteckt
Diese Werte sind mit einer Standardinstallation von vLLM nicht reproduzierbar. Der Referenz-Stack nutzt int4-Gewichte mit int8-Tensor-Core-GEMMs, einen fp16-DeltaNet-State, MTP-Speculative-Decoding mit eigenem Draft-Vokabular, einen kalibrierten int4-lm_head und Split-KV-Verify-Attention. Das ist gepatchtes vLLM plus eigene Requantisierungs-Skripte – nicht „vLLM mit ein paar Flags". Wer die 114 Tokens/s in ein Angebot schreibt, ohne diesen Aufwand einzupreisen, verkauft eine Zahl, die im Betrieb nicht ankommt. Realistisch sollte man für den Aufbau und die Validierung eines solchen Stacks mehrere Personentage veranschlagen – oder mit Stock-vLLM starten und die konservativeren Werte kommunizieren.
Der Sprung von 114 auf über 1.000 Tokens/s aggregiert zeigt aber unabhängig vom Tuning das Grundprinzip: Bei Einzelnutzung ist eine GPU speicherbandbreitenlimitiert und die Recheneinheiten langweilen sich. Erst Continuous Batching füllt sie. Für die Kapazitätsplanung heißt das: Nicht mit dem Single-User-Wert rechnen, sondern mit dem aggregierten Durchsatz geteilt durch die realistische Gleichzeitigkeit.
Konfigurationsempfehlungen für vLLM
Die Modellkarte empfiehlt SGLang und vLLM als Serving-Stacks. Für vLLM haben sich in unseren Projekten vier Stellschrauben als entscheidend erwiesen:
--max-model-lenam realen Bedarf ausrichten. Das ist der wichtigste Hebel überhaupt. vLLM allokiert den KV-Cache-Pool anhand dieses Werts. Wer 262144 einträgt, weil das Modell es kann, verschenkt auf einer 24-GB-Karte die gesamte Batching-Kapazität. Für Coding-Assistenz und RAG reichen 32768 bis 65536 in fast allen Fällen.--gpu-memory-utilizationbewusst setzen. Der Default von 0,90 ist auf dedizierten Servern konservativ, auf Workstations mit Desktop-Session dagegen riskant. Auf einer reinen Inferenz-Karte sind 0,92 bis 0,95 machbar, wenn nichts anderes auf der GPU läuft.- Prefix-Caching aktivieren. Bei RAG-Lasten mit stabilem System-Prompt und wiederkehrenden Dokumentkontexten spart
--enable-prefix-cachingeinen erheblichen Teil der Prefill-Zeit. Bei rein interaktiven Chats mit stark variierendem Prompt-Anfang bringt es wenig. - KV-Cache-Quantisierung auf FP8. Halbiert den KV-Bedarf und erkauft damit entweder mehr Kontext oder mehr parallele Sequenzen. Die Qualitätseinbuße ist bei diesem Modell in unseren Tests gering – validieren Sie es dennoch gegen das eigene Eval-Set.
Beim Sampling nennt die Modellkarte konkrete Werte: Im Thinking-Modus temperature=1.0, top_p=0.95, top_k=20. Im Non-Thinking-Modus temperature=0.7, top_p=0.80, top_k=20, presence_penalty=1.5. Diese Werte sind kein Vorschlag zum Herumprobieren – Abweichungen führen bei Qwen-Modellen reproduzierbar zu Endlosschleifen und Repetitionen.
Hardware-Pfade: von der Einzelkarte bis zum vollen Kontextfenster
Welche Kartenklasse für welches Szenario nötig ist, lässt sich anhand gemessener Werte recht klar abgrenzen:
| Setup | Format | Durchsatz | Eignung |
|---|---|---|---|
| RTX 5090 (32 GB), SGLang | NVFP4 | > 200 t/s | bester Preis-Leistungs-Punkt |
| RTX 3090 (24 GB), gepatcht | int4 | ca. 114 t/s | Einstieg, hoher Tuning-Aufwand |
| 2 × RTX 4090 | 4-Bit, TP=2 | ca. 80 t/s | mehr Kontext, nicht mehr Speed |
| 24-GB-Blackwell + MTP | NVFP4 | ca. 50 t/s | Workstation-Einstieg |
| Strix Halo, 128 GB Unified | Q8 | 7–10,5 t/s | Experimente, kein Produktivbetrieb |
| 12-GB-GPU + CPU-Offload | 4-Bit | 3,26–4,53 t/s | unbrauchbar für Agenten |
Für den Vollausbau gilt: FP8 mit rund 28 bis 31 GB verlangt die 48-GB-Klasse (L40S, RTX Pro 6000), BF16 mit rund 56 GB die 80-GB-Klasse (H100/H200). Wer das volle 262K-Fenster bei mehreren gleichzeitigen Nutzern braucht, kommt an einem Mehrkarten-Setup nicht vorbei – nicht wegen der Gewichte, sondern wegen des KV-Cache-Pools.
Zur Preislage Ende August 2026: Die RTX 5090 hat eine UVP von 1.999 USD, ist am Markt aber weitgehend ausverkauft. Ein M4 Pro Mac mini mit 48 GB und 1 TB liegt bei 2.499 USD, ebenso das Mac-Studio-Basismodell mit M4 Max – interessante Optionen für Entwicklerarbeitsplätze, aber wegen der Speicherbandbreite kein Ersatz für eine Server-GPU. Wie sich die Anschaffung gegen laufende API-Kosten rechnet, lässt sich mit unserem TCO-Rechner für GPU-Hardware durchspielen.
Abgrenzung zur großen MoE-Variante
Am selben Tag erschien mit Qwen3.8-Max eine Mixture-of-Experts-Variante – intern als Qwen3.8-2.4T-A95B geführt: rund 2,4 Billionen Gesamtparameter, davon rund 95 Milliarden aktiv pro Token. Wer die Namen verwechselt, plant an der Realität vorbei, denn die beiden Modelle sind unterschiedliche Produkte in fast jeder Hinsicht.
- Lizenz: Qwen3.8-Max steht nicht unter Apache 2.0. Sie ist im Wesentlichen API-only beziehungsweise unter einer eigenen, umsatzabhängigen Lizenz verfügbar.
- Kosten: Als API 2 USD je Million Input-Tokens und 6 USD je Million Output-Tokens. Bei Agentenlasten mit langem Kontext summiert sich das schnell.
- Hardware: Selbst bei aggressiver 1-Bit-Quantisierung werden rund 397 GB Speicher benötigt – also ein Cluster, keine Karte und kein einzelner Server.
Genau diese Abgrenzung ist das eigentliche Argument für die dichte 27B-Variante: Sie ist das größte Qwen-Modell, das ein mittelständisches Unternehmen realistisch im eigenen Rack betreiben, selbst quantisieren, feintunen und ohne Lizenzrisiko in ein Produkt einbauen kann. Alles darüber ist – für diese Zielgruppe – wieder eine Cloud-Entscheidung mit allen Datenschutzfragen, die damit zurückkommen.
Fazit: für wen sich der Aufwand lohnt
Qwen3.8-27B ist die derzeit interessanteste Option für Unternehmen, die Coding-Assistenz, Dokumentenverarbeitung mit Bildanteil oder agentische Automatisierung im eigenen Haus betreiben wollen. Die Kombination aus Apache 2.0, nativer Multimodalität und einem Speicherprofil, das auf bezahlbare Hardware passt, gibt es in dieser Form sonst nicht.
Realistisch bleiben sollte man bei drei Punkten: Die Benchmarkwerte sind Herstellerwerte, das Wissensprofil ist schwach, und die spektakulären Durchsatzzahlen setzen einen erheblich gepatchten Serving-Stack voraus. Wer mit 32 GB oder mehr VRAM plant, spart sich einen Großteil dieses Tuning-Aufwands. Für die Planung Ihrer Hardware und die Integration in eine eigene KI-Chat-Plattform unterstützen wir Sie gern – von der Kartenauswahl bis zum produktiven Serving.
Quellen & Primärbelege
Alle Zahlen, Fristen und Produktangaben in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Primärquellen geprüft.
- Hugging Face – Qwen/Qwen3.8-27B Modellkarte: Parameterzahl, Architektur, Kontextfenster, Benchmarks, Sampling-Empfehlungen
- Hugging Face – Qwen3.8-27B-FP8 Offizieller FP8-Build, 30,88 GB, blockweise Quantisierung
- GitHub – syv-ai/qwen38-27b-rtx3090 Referenz-Stack und Durchsatzmessungen auf RTX 3090 mit vLLM 0.27.1
- kingy.ai – Specs, Benchmarks, Local Hardware Benchmark-Vergleich und Vorgänger-Delta
- kingy.ai – Local Hardware Requirements Quantisierungsleiter und VRAM-Bedarf je Build
- RunPod – Qwen3.8-27B on a single 24GB worker Architektur, KV-Cache-Layer-Verteilung, 24-GB-Rechnung
- YottaLabs – Specs & Hardware Requirements Hardware-Pfade, Durchsatz je Kartenklasse
- BenchLM – Qwen3.8-27B Unabhängige Aggregat-Bewertung, Kategorie-Rankings
- Studio Global – Key Details & Benchmarks Release-Zeitpunkt, Adoption, MoE-Abgrenzung
- Context Studios – Hardware Guide Marktpreise, Offload-Messwerte, Serving-Empfehlungen
Häufig gestellte Fragen zu Qwen3.8-27B
Läuft Qwen3.8-27B wirklich auf einer RTX 4090?
Ja, 4-Bit-quantisiert und bei moderatem Kontext. BF16, FP8 und das volle 262K-Kontextfenster passen nicht auf 24 GB.
Wie viele Nutzer bedient eine einzelne Karte?
Mit getuntem vLLM sind rund 1.000 Tokens pro Sekunde aggregiert bei 64 parallelen Requests gemessen worden – die Nutzerzahl hängt stark von Kontextlänge und Antwortlänge ab.
Ist Apache 2.0 für kommerzielle Nutzung ausreichend?
Ja. Apache 2.0 erlaubt kommerzielle Nutzung, Modifikation und Weitergabe ohne Nutzerzahl- oder Umsatzgrenzen – anders als diverse Community-Lizenzen.
Was bringt der reasoning_effort-Parameter?
Er steuert, wie viel Denkaufwand das Modell betreibt. Im Eigenbetrieb ist das ein direkter Hebel auf Latenz und GPU-Auslastung statt auf die Rechnung.
Qwen3.8-27B im eigenen Rack betreiben
Wir dimensionieren die passende GPU-Hardware, richten das Serving ein und validieren die Modellqualität gegen Ihre eigenen Aufgaben – on-premise, DSGVO-konform, ohne API-Abhängigkeit.