- Alibabas Qwen3.5-Modellfamilie bietet verschiedene Größen von 0.8B bis 397B und unterstützt multimodale hybride Inferenz sowie 256K Kontext
- Unsloth stellt alle Qwen3.5-Modelle mit Dynamic 2.0 GGUF-Quantisierung bereit, die sich über llama.cpp oder LM Studio lokal ausführen lassen
- Zwischen Thinking-Modus und Non-thinking-Modus kann umgeschaltet werden; kleine Modelle (0.8B~9B) sind standardmäßig auf den Non-thinking-Modus gesetzt
- Für jedes Modell sind die benötigte RAM/VRAM-Kapazität und empfohlene Einstellungswerte (temperature, top_p usw.) angegeben; die 27B- und 35B-Modelle lassen sich auch in einer Mac-Umgebung mit 22GB ausführen
- Unsloth GGUF verbessert die Leistung durch verbesserte Quantisierungsalgorithmen und imatrix-Daten, ist jedoch nicht mit Ollama kompatibel
Überblick über Qwen3.5
- Qwen3.5 ist eine von Alibaba veröffentlichte neue LLM-Serie, die von 0.8B·2B·4B·9B (klein) bis 27B·35B·122B·397B (groß) reicht
- Unterstützt multimodale hybride Inferenz und verarbeitet 201 Sprachen sowie eine Kontextlänge von 256K
- Zeigt hohe Leistung bei Agent Coding, Vision, Dialogen und Aufgaben mit langem Kontext
- Die 35B- und 27B-Modelle lassen sich auch auf Macs mit 22GB RAM ausführen
- Alle GGUF-Dateien verwenden verbesserte Quantisierungsalgorithmen und neue imatrix-Daten
- Leistungsverbesserungen bei Chat, Coding, langem Kontext und Tool-Calling
- MXFP4-Schichten wurden in einigen GGUFs (Q2_K_XL, Q3_K_XL, Q4_K_XL) entfernt
Hardware-Anforderungen
- Laut Tabelle sind die minimalen Speicheranforderungen je nach Modellgröße angegeben
- Beispiel: 0.8B~2B-Modelle benötigen 3GB, 9B benötigt 5.5GB (bei 3-bit), 35B-A3B benötigt 17GB
- 397B-A17B benötigt bei 3-bit 180GB und bei 4-bit 214GB
- Für optimale Leistung sollte der Gesamtspeicher (RAM+VRAM) größer sein als die Größe der Modelldatei
- Falls das nicht ausreicht, ist eine Ausführung per SSD/HDD-Offloading möglich, allerdings mit Geschwindigkeitsverlust
- 27B ist die Wahl mit Fokus auf Genauigkeit, 35B-A3B die Wahl mit Fokus auf Geschwindigkeit
Empfohlene Einstellungen
- Maximales Kontextfenster: 262,144 (mit YaRN auf bis zu 1M erweiterbar)
- presence_penalty: 0.0~2.0 (zur Verringerung von Wiederholungen; je höher, desto eher leichte Leistungseinbußen möglich)
- Ausgabelänge: 32,768 Token empfohlen
- Die Einstellungswerte unterscheiden sich je nach Thinking-Modus und Non-thinking-Modus
- Thinking-Modus: für allgemeine Aufgaben temperature=1.0, für Coding 0.6
- Non-thinking-Modus: für allgemeine Aufgaben temperature=0.7, für Inferenzaufgaben 1.0
- Kleine Modelle (0.8B~9B) haben Reasoning standardmäßig deaktiviert
- Zur Aktivierung
--chat-template-kwargs '{"enable_thinking":true}' verwenden
Tutorial zu Ausführung und Inferenz
- Alle Modelle werden in einer Dynamic 4-bit MXFP4_MOE GGUF-Version bereitgestellt
- Verfahren für lokale Inferenz mit llama.cpp
- Neueste Version von GitHub installieren und per Option
-DGGML_CUDA GPU/CPU auswählen
- Modell von Hugging Face herunterladen (
hf download unsloth/Qwen3.5-XXB-GGUF)
- Mit den Befehlen
llama-cli oder llama-server ausführen
- Ausführung ist auch in LM Studio möglich
- Nach dem Suchen des Modells GGUF herunterladen und den Thinking-Umschalter per YAML-Datei aktivieren
- Nach einem Neustart kann die Umschaltfunktion verwendet werden
Zusammenfassung der Ausführung je Modell
- Qwen3.5-35B-A3B: Schnelle Inferenz mit Dynamic 4-bit auf 24GB RAM/Mac möglich
- Qwen3.5-27B: Auf 18GB RAM/Mac ausführbar
- Qwen3.5-122B-A10B: Läuft in einer Umgebung mit 70GB RAM/Mac
- Qwen3.5-397B-A17B:
- 3-bit: 192GB RAM, 4-bit: 256GB RAM erforderlich
- Mit einer Kombination aus 24GB GPU + 256GB RAM werden mehr als 25 Token pro Sekunde erzeugt
- Leistungsklasse ähnlich wie Gemini 3 Pro, Claude Opus 4.5 und GPT-5.2
Inferenzserver und API-Integration
- Über
llama-server als OpenAI-kompatible API bereitstellbar
- Mit der Python-Bibliothek
openai können Anfragen an den lokalen Server gesendet werden
- Beispiel: Verwendung des Endpunkts
"http://127.0.0.1:8001/v1";
- Tool Calling wird unterstützt
- Funktionsaufrufe für die Ausführung von Python-Code, Terminal-Befehlen, mathematischen Operationen usw. möglich
- Beispielcode für
unsloth_inference() wird bereitgestellt
Benchmark-Ergebnisse
- Unsloth-GGUF-Benchmark
- Qwen3.5-35B Dynamic quant erreicht in den meisten Bit-Bereichen SOTA-Leistung
- Mehr als 150 KL-Divergence-Tests, insgesamt 9TB GGUF-Daten verwendet
- Bei 99.9% KLD die höchste Leistung auf der Pareto Frontier
- Qwen3.5-397B-A17B
- In Drittanbieter-Tests von Benjamin Marie
- Original 81.3%, UD-Q4_K_XL 80.5%, UD-Q3_K_XL 80.7%
- Weniger als 1 Prozentpunkt Genauigkeitsverlust, etwa 500GB Speichereinsparung
- Q3 wird als speichersparende, Q4 als stabile Option empfohlen
Weitere Funktionen
- Befehle zum Aktivieren/Deaktivieren von Reasoning vorhanden (
--chat-template-kwargs)
- Integration mit Claude Code / OpenAI Codex möglich
- Über den Tool Calling Guide lässt sich Tool Calling mit lokalen LLMs einrichten
- Nicht mit Ollama kompatibel, nur auf llama.cpp basierende Backends werden unterstützt
2 Kommentare
Ich nutze auf dem HX370 das 27B-Modell, und die Ergebnisse sind ganz ordentlich.
Hacker-News-Kommentare
Ich habe Qwen3.5 9B auf einer ASUS 5070ti 16G mit LM Studio ausprobiert, und es läuft mit etwa 100 tok/s sehr stabil.
Es ist schneller als die meisten Online-LLM-Dienste, und die Ausgabequalität entspricht dem Benchmark-Niveau.
Es ist das erste Mal, dass ich auf Consumer-Hardware ein im Alltag tatsächlich nutzbares Modell laufen sehe.
Ich nehme an, dass damit kein Usability-Vergleich mit Spitzenmodellen wie Sonnet oder Opus gemeint ist.
Für Coding-Aufgaben brauche ich mindestens 100k Context.
Bei mir lief es in eine Endlosschleife, deshalb habe ich es deaktiviert, und auch mit verschiedenen Parametern ließ sich das nicht beheben.
Die Qualität liegt auf dem Niveau von Sonnet 4.0 im Sommer 2025, und in ik_llama.cpp ist auch die Geschwindigkeit sehr gut.
Die Orchestrierung scheint ziemlich wichtig zu sein.
Es heißt zwar „All uploads use Unsloth Dynamic 2.0“, aber bei den tatsächlichen Optionen gibt es IQ4_XS, Q4_K_S, Q4_K_M und weitere Varianten.
Ohne eine Erklärung der jeweiligen Trade-offs ist das verwirrend.
Auf einem Mac mini M4 16GB nutze ich meist Qwen3-4B-Instruct-2507-Q4_K_M, während Qwen3.5-4B-UD-Q4_K_XL deutlich gesprächiger ist.
Die Anforderungen sind natürlich je nach Nutzer unterschiedlich, aber eine Tabelle mit Einstellungen und Speicherverbrauch nach Modell/Hardware wäre hilfreich.
Selbst auf Reddit gibt es kaum konkrete Setup-Beispiele.
Ich verfolge das Thema seit drei Monaten und habe dabei eher mehr Verwirrung als Klarheit gefunden.
Aktuell nutze ich das coder-model der qwen CLI in der Cloud und warte auf ein stromsparendes lokales Modell.
Dort gibt es einen Vergleich von KL-Divergence im Verhältnis zum Speicherplatz auf der Festplatte für Q4_K_XL und Q4_K_M.
Q4_0 und Q4_1 sind zwar schnell, werden aber wegen geringerer Genauigkeit inzwischen nicht mehr empfohlen.
Q4_K_M und UD-Q4_K_XL sind nahezu identisch, wobei _XL etwas größer ist.
Für Qwen3.5 gibt es dort aber noch keine Daten.
Möglicherweise lag das daran, dass es mit Rust-Code arbeiten musste.
Als ich qwen3.5-35b-a3b in 6bit auf einer 4090 laufen ließ, waren die Ergebnisse ziemlich gut.
Derzeit nutze ich 8bit qwen3.5-27b als Haupt-Engine und bin zufrieden.
Jedes Mal, wenn ein neues Open Model erscheint, teste ich die Geschwindigkeit von PP (Prompt Processing) und TG (Token Generation) mit llama-cpp/server.
Die Tests liefen auf einem MacBook M1 Max 64GB in einer Claude-Code-Umgebung mit 15–30K Context.
Bei Qwen3.5-30B-A3B ist die TG-Geschwindigkeit nur etwa halb so hoch wie bei Qwen3-30B-A3B.
Dank sliding window attention braucht Qwen3.5 zwar wenig RAM und liefert gute Antwortqualität, aber bei 33k Context ist es langsam.
Die Details sind in diesem Dokument zusammengefasst.
In meinem persönlichen Benchmark habe ich mit Claude Opus gegen die DeepSeek API bewertet.
Qwen3.5 35B A3B (q8_0, thinking) erreicht 92,5 %, Q4_K_M (thinking) etwa 90 %.
Ich hatte erwartet, dass das dichte 27B-Modell höher liegen würde, daher war das überraschend.
Allerdings basiert dieser Wert auf einer Bewertung von One-Shot-Antworten und bildet Agenten-Iterationen nicht ab.
Eine logische Inkonsistenz im Prompt könnte das Reasoning von 27B beeinträchtigt haben.
Mit dem Thinking-Trace ließe sich die Ursache vermutlich debuggen.
Ich habe Qwen3.5 9B auf der CPU für OCR und Textbereinigung ausprobiert, und dafür ist es ziemlich brauchbar.
Allerdings funktionierte GPU-Offloading nicht richtig, sodass es auf einer 1650 Ti mit 4GB VRAM zu einem Speicherüberlauf kam.
Das ging mit dem Befehl
sudo apt install nvidia-driver-570.Das 35B-Modell läuft ungefähr mit derselben Geschwindigkeit wie das 4B-Modell, ist aber deutlich leistungsfähiger.
Allerdings ist qwen3.5 nur etwa halb so schnell wie qwen3.
Insgesamt bin ich trotzdem zufrieden.
Ich betreibe Qwen3.5:0.8b auf einem Orangepi Zero 2w problemlos nur auf der CPU.
Wenn ich Vulkan-GPU nutzen will, lasse ich qwen3.5:2b mit zeroclaw auf einem Meta Quest 3 laufen.
Dadurch habe ich in Low-Power-Umgebungen mehrere hundert Dollar gespart.
Ich würde empfehlen, lokale Modelle auch einmal auf gebrauchten Android-Smartphones auszuprobieren.
Ich frage mich, ob es irgendwo das 9B-Modell als Hosting-Angebot gibt.
In einem geschäftlichen Umfeld ist GPU-Miete schwierig, und auf OpenRouter gibt es keine kleinen Modelle.
Es wäre schön, wenn es ein runpod-serverless-Template gäbe.
Mich interessiert auch, ob das 9B-Modell auf einer 4090 mit 8bit oder 6bit mit niedriger Latenz laufen kann.
Ich habe Qwen3.5 35B-A3B auf einer RTX 3050 8GB ausprobiert, und es ist ziemlich reaktionsschnell und erledigt auch Coding-Aufgaben gut.
Bei der vorherigen Version gab es Probleme mit Schleifen beim Tool-Einsatz, aber das scheint in der neuen Version behoben zu sein.
Die tok/s-Werte wären auch interessant.
Selbst auf einem RTX-3060-Laptop könnte das als lokaler Server gut funktionieren.
Ich hätte nicht gedacht, dass ein lokales Modell das so gut kann.
Mich würde interessieren, wie sich das 397B-A17B-Modell im Vergleich zu Frontier schlägt.
Vermutlich braucht man dafür Hardware, die für die meisten Leute außer Reichweite ist.
Persönlich finde ich das 122B-Modell in Bezug auf Privatsphäre und Kosteneinsparung bereits mehr als zufriedenstellend.
Ich frage mich, ob dieses Modell auf einem alten 4xV100-Tesla-Server laufen würde.
Die fp-bezogenen Einstellungen sind kompliziert, daher ist das aus Anfängersicht schwer zu verstehen.