Qwen-Modelle 2026: Qwen3.6, Coder-Next, VRAM und RAG

Qwen ist 2026 mehr als eine weitere Modellfamilie neben Llama, Mistral oder Gemma. Die Reihe deckt lokale Chat- und Codingmodelle ebenso ab wie grosse MoE-Systeme, Embeddings und Reranker für Retrieval-Augmented Generation (RAG).

Bei Qwen3.6 gibt es zwei lokale Hauptpfade, die leicht verwechselt werden: Qwen3.6-27B ist ein dichtes Modell, bei dem alle 27 Milliarden Parameter arbeiten. Qwen3.6-35B-A3B ist ein Mixture-of-Experts-Modell mit rund 35 Milliarden Gesamtparametern, von denen pro Token etwa 3 Milliarden aktiv sind. Das dichte 27B zielt stärker auf Qualität bei Coding und komplexer Agentik. Das MoE-Modell ist auf effiziente Inferenz und hohen Durchsatz ausgelegt.

Daneben steht Qwen3-Coder-Next als spezialisierter Coding-Agent. Er gehört nicht zur Qwen3.6-Familie, ist aber gezielt auf lange Tool- und Reparaturschleifen trainiert.

Das macht 35B-A3B nicht zum kleinen Modell und 27B nicht automatisch zum besseren Modell für jeden Einsatz. Speicherbedarf, Geschwindigkeit, Quantisierung und Modellqualität müssen getrennt betrachtet werden.

Kurzfassung

• Coding und Repository-Arbeit: Qwen3.6-27B zuerst prüfen. Unabhängige Gesamtevaluationen sehen es vor 35B-A3B; der konkrete Vorsprung hängt aber vom Agenten-Harness und Thinking-Modus ab.
• Schnelle lokale Agentik und hoher Durchsatz: Qwen3.6-35B-A3B ist wegen seiner rund 3 Milliarden aktiven Parameter der effizientere Kandidat.
• Spezialisierte Coding-Agenten: Qwen3-Coder-Next ist ein eigener 80B-A3B-Pfad für lange Tool-Schleifen, Codeänderungen und Recovery aus fehlgeschlagenen Versuchen.
• Normale Consumer-Hardware: Gute 4-Bit-Quantisierungen sind meist realistischer als die offiziellen FP8-Gewichte. Kontext und Parallelität bleiben begrenzende Faktoren.
• RAG und semantische Suche: Dafür sind Qwen3-Embedding-0.6B, 4B und 8B gedacht. Ein Qwen3-Reranker kann die erste Trefferliste anschliessend neu sortieren.
• Sehr grosse lokale Experimente: Qwen3.5-122B-A10B bleibt relevant, verlangt aber deutlich mehr Speicher und Betriebsaufwand.

Qwen3.6-27B und 35B-A3B: zwei verschiedene Stärken

Beide Qwen3.6-Modelle unterstützen Text und Bilder, einen nativen Kontext von 262.144 Tokens sowie Thinking und Non-Thinking im selben Checkpoint. Beide sind auch als offizielle FP8-Varianten unter Apache 2.0 verfügbar. Die gemeinsame Modellfamilie darf aber nicht über den Architekturunterschied hinwegtäuschen.

Der dichte Aufbau gibt 27B mehr Rechenkapazität pro Token. Das kann bei schwierigen Codeänderungen und langen Handlungsketten helfen, kostet aber Rechenzeit. Beim 35B-A3B liegen zwar alle Gewichte im Speicher, pro Token arbeitet jedoch nur ein kleiner Teil davon. Auf passender Hardware kann das Modell deshalb deutlich mehr Tokens pro Sekunde liefern.

Ist Qwen3.6-27B beim Coding wirklich stärker?

Die kurze Antwort lautet: wahrscheinlich, aber nicht in jedem Setup gleich deutlich.

Qwens eigene Modellkarte weist für 27B höhere Werte bei SWE-bench, Terminal-Bench, SkillsBench und weiteren Agentiktests aus. Solche Herstellerwerte zeigen, worauf ein Modell optimiert wurde. Sie sind kein unabhängiger Beweis.

Ein breiterer Vergleich kommt von Artificial Analysis. Dort erreicht die Reasoning-Variante von Qwen3.6-27B im Intelligence Index 37 Punkte, Qwen3.6-35B-A3B erreicht 32. Der Index umfasst unter anderem Terminal-Bench, SciCode, wissenschaftliches Reasoning und lange Kontexte. Das stützt einen allgemeinen Qualitätsvorsprung des dichten Modells. Es isoliert aber nicht die reine Coding-Leistung, und die gemessene API-Geschwindigkeit ist nicht mit lokaler FP8-Inferenz gleichzusetzen.

Auch öffentliche SWE-bench-Ergebnisse brauchen Kontext. Modell, Agenten-Harness, Prompting, Tools, Retry-Budget und Tokenbudget beeinflussen das Resultat erheblich. Ein stark optimierter Agentenlauf misst nicht nur das Modell.

Die vorsichtige Einordnung lautet deshalb: 27B ist der aussichtsreichere Qualitäts- und Coding-Pfad. 35B-A3B bleibt der stärkere Effizienzpfad. Ein direkter lokaler Vergleich mit identischem Runtime-Stack steht bei AISyndicate noch aus.

Welche Qwen-Modelle sind wofür sinnvoll?

Das ist keine Rangliste. Ein kleineres Modell mit passender Quantisierung und stabilem Runtime-Pfad kann produktiver sein als ein stärkeres Modell, das zu langsam oder unzuverlässig angebunden ist.

Qwen3-Coder-Next: Spezialist für Coding-Agenten

Qwen3-Coder-Next gehört nicht zur Qwen3.6-Familie. Es basiert auf der Qwen3-Next-Architektur und wurde gezielt für agentische Softwareentwicklung nachtrainiert. Das MoE-Modell umfasst 80 Milliarden Parameter, aktiviert pro Token aber nur rund 3 Milliarden. Der native Kontext beträgt 262.144 Tokens. Veröffentlicht sind ein Base- und ein instruction-tuned Modell unter Apache 2.0.

Der Schwerpunkt liegt auf langen Arbeitsketten: Repository verstehen, Dateien ändern, Tests ausführen, Fehler auswerten und einen zweiten Versuch starten. Im technischen Bericht beschreibt Qwen dafür Training mit ausführbaren Entwicklungsumgebungen und mehreren Agenten-Frameworks. Interessant ist auch die dokumentierte Grenze: Training auf einem bestimmten Agenten-Gerüst überträgt sich nicht vollständig auf andere Gerüste. Ein SWE-bench-Wert ist deshalb immer auch ein Ergebnis des verwendeten Harness.

Qwen3-Coder-Next unterstützt nur Non-Thinking. Es gibt keinen sichtbaren Thinking-Modus wie bei Qwen3.6. Für Tool Calls ist der Parser qwen3_coder vorgesehen. Das kann den Betrieb vereinfachen, schliesst den spezialisierten Coder aber als direkten Ersatz für einen allgemeinen Reasoning-Daily-Driver aus.

Unabhängige Evidenz zeichnet kein Bild eines universellen Siegers. Artificial Analysis gibt Qwen3-Coder-Next 21 Punkte im Intelligence Index; Qwen3.6-27B erreicht 37. In spezialisierten Coding-Setups sieht Coder-Next besser aus. Das öffentliche SWE-Rebench führt das Modell als Beispiel dafür, dass sehr grosser Arbeitskontext bei frischen Repository-Aufgaben helfen kann. Solche Resultate hängen stark vom Agenten-Harness ab.

VRAM und Unified Memory: Dense gegen MoE

Bei 35B-A3B führt die Angabe «3B active» leicht in die Irre. Sie beschreibt die Rechenarbeit pro Token, nicht den gesamten Gewichtsspeicher. Grob liegen 35 Milliarden Parameter in BF16 bei rund 70 GB und in FP8 bei rund 35 GB. Runtime-Overhead und KV-Cache kommen hinzu.

Beim dichten 27B-Modell arbeiten alle Parameter pro Token. Die offiziellen FP8-Gewichte liegen grob in der 27-GB-Klasse, benötigen mit Runtime und Cache aber mehr als 27 GB nutzbaren Speicher. Auf einer 24-GB-GPU sind deshalb Community-Quants oder Offloading realistischer als die offizielle FP8-Variante.

Für beide Modelle gilt: 256K Kontext ist eine Fähigkeit, keine kostenlose Standardeinstellung. Der KV-Cache wächst mit Kontext, Parallelität und Serving-Konfiguration. Ein Modell kann auf einer Maschine starten und bei langen Prompts oder mehreren gleichzeitigen Requests trotzdem aus dem Speicher laufen.

Als grobe Orientierung:

• 24 GB VRAM: 4-Bit-Quants mit begrenztem Kontext; 27B und 35B-A3B sind möglich, aber nicht sorglos.
• 48 GB VRAM: offizielle FP8-Gewichte werden realistischer; Cache und Parallelität müssen weiterhin geplant werden.
• 80 GB und mehr oder 128 GB Unified Memory: FP8, grosse Kontexte und belastbare Agenten-Evals werden deutlich praktikabler.
• Qwen3-Coder-Next: Die 80B Gesamtgewichte machen eine starke Quantisierung oder eine grosse Unified-Memory-/Server-Konfiguration nötig. Die 3B aktiven Parameter reduzieren Rechenarbeit, nicht den Gewichtsspeicher.
• Qwen3.5-122B-A10B: bleibt auch quantisiert ein grosser Workstation-, Server- oder Unified-Memory-Workload.

Qwen für RAG: Embeddings und Reranker

Generative Qwen-Modelle beantworten Fragen und erzeugen Code. Embedding-Modelle erledigen eine andere Aufgabe: Sie übersetzen Texte und Suchanfragen in Vektoren, damit ein System semantisch ähnliche Dokumente findet. Reranker bewerten anschliessend die besten Kandidaten genauer.

Qwen bietet beide Familien in drei Grössen an:

Alle drei Qwen3-Embedding-Modelle unterstützen bis zu 32K Tokens und mehrsprachige Aufgaben. Die Dimensionen lassen sich verkleinern, wenn Vektorspeicher und Suchgeschwindigkeit wichtiger sind als das letzte Qualitätsprozent. Bei asymmetrischer Suche ist das Query-Instruct entscheidend: Die Suchanfrage erhält eine Aufgabenbeschreibung, Dokumente werden normal eingebettet. Ohne dieses Format kann ein gutes Modell in einem realen Corpus unnötig schwach wirken.

Im AISyndicate-System läuft Qwen3-Embedding-4B produktiv als lokaler Retrieval-Endpunkt. In unserem Corpus war nicht nur die Modellgrösse wichtig. Query-Instruct, Chunking und der tatsächliche Dokumentbestand hatten grossen Einfluss auf die Trefferqualität. Das ist eine eigene Praxiserfahrung und kein allgemeiner Benchmark.

Ein Reranker ist der optionale zweite Schritt. Er bewertet etwa die ersten 20 bis 100 Treffer des schnellen Vektorabrufs und sortiert sie neu. Das kann bei ähnlichen Dokumenten und schwierigen Fachfragen helfen. Es erhöht aber Latenz und Betriebsaufwand. Qwen3-Reranker gibt es ebenfalls mit 0.6B, 4B und 8B Parametern. Im AISyndicate-Stack ist diese Familie noch nicht lokal getestet.

Eigener Praxisstand: Qwen3.6 auf DGX Spark

Im lokalen AISyndicate-Lab lief Qwen3.6-35B-A3B-FP8 über vLLM als OpenAI-kompatibler Endpoint auf einem ASUS-GX10-/DGX-Spark-System. Der Test deckte 262.144 Tokens Kontext, Tool Calls, strukturierte Antworten und mehrstufige Agenten-Workflows ab.

Qwen3.6-35B-A3B war in diesem Harness stärker als unser vorheriger Qwen3.5-122B-Vergleichspfad. Das ist keine öffentliche Rangliste. Parser, Request-Format, Thinking-Konfiguration und Runtime waren Teil des Ergebnisses.

Eine Sicherheitsgrenze blieb sichtbar: Manipulierte Tool-Ergebnisse können spätere Aktionen beeinflussen. Modelle mit E-Mail-, Kalender- oder Publishing-Rechten brauchen deshalb Policy-Gates und menschliche Freigaben. Gute Codingwerte ersetzen keine Zugriffskontrolle.

Mehr zur Hardware steht im Artikel zur DGX-Spark-Praxis. Für den Runtime-Vergleich ist der Überblick zu vLLM, llama.cpp, Ollama und TensorRT-LLM relevant.

Thinking, Tool Calls und vLLM

Qwen3.6 kann mit demselben Checkpoint im Thinking- und Non-Thinking-Modus arbeiten. Der Schalter erfolgt über das Chat Template; die Prompt-Befehle /think und /nothink sind für diese Generation nicht vorgesehen. Für formatkritische Aufgaben kann Non-Thinking sinnvoller sein. Für komplexe Analyse und Coding ist Thinking der interessantere Pfad.

Beim lokalen Serving entscheidet nicht nur das Modell. Qwen empfiehlt für vLLM unter anderem den Reasoning-Parser qwen3 und den Tool-Call-Parser qwen3_coder. Wenn Parser und Chat Template nicht zusammenpassen, kann Reasoning im sichtbaren Antworttext landen oder ein Tool Call als normaler Text statt als strukturiertes API-Objekt erscheinen.

Darum sollte ein lokaler Test in dieser Reihenfolge erfolgen:

1. Streaming und Non-Streaming prüfen.
2. Thinking und Non-Thinking getrennt testen.
3. Tool Calls und strukturierte Ausgabe validieren.
4. Erst danach lange Kontexte und parallele Requests testen.
5. Schreibende Tools nur mit festen Grenzen freigeben.

Fazit

Qwen deckt inzwischen drei klar unterscheidbare lokale Rollen ab: allgemeine Qualität, effiziente Inferenz und spezialisierte Coding-Agenten. Welcher Pfad passt, entscheidet sich nicht an einer einzelnen Benchmarkzahl, sondern am Zusammenspiel aus Aufgabe, Harness und Hardware.

Für RAG gehören Qwen3-Embedding und Qwen3-Reranker in dieselbe Übersicht, aber nicht in dieselbe Rangliste. Qwen3-Embedding-4B ist ein plausibler lokaler Mittelweg und läuft bei AISyndicate produktiv. Ein Reranker lohnt sich erst, wenn die erste Retrieval-Stufe sauber gemessen wurde.

Die praktische Entscheidung fällt deshalb nicht allein über Parameter oder Benchmarks. Sie fällt über Hardware, Quantisierung, Kontext, Runtime und die konkrete Aufgabe.

Wer den lokalen Stack weiter planen will, findet zusätzliche Details bei Ollama auf dem Mac mini, im Vergleich von Inferenz-Frameworks und im Grundlagenartikel zu Inferenz und Quantisierung.