Qwen 3.8 lokal heißt bei mir: Qwen3.8-27B als NVFP4-Checkpoint unter SGLang auf einem Nvidia DGX Spark, gemessen mit 50,7 Tokens pro Sekunde beim Decodieren, und ein Terminal-Agent namens Pi davor, der gegen dieses Modell arbeitet. Für die Modellinferenz heißt das: kein Aufruf einer Anbieter-API, kein API-Key. Werkzeuge, die der Agent daneben nutzt, etwa eine Websuche oder ein MCP-Adapter, sprechen weiterhin nach draußen, wenn du sie nicht abschaltest. Dazu kommt ein Setup mit ein paar Stolperfallen, die ich lieber einmal beschreibe, als dass du sie selbst findest.
Ich betreibe mein Business mit einer KI-Belegschaft aus acht KI-Mitarbeitern auf Claude-Basis, das ist meine Produktionsumgebung. Der DGX Spark daneben ist mein Testfeld für eine Frage, die ich für Kunden ehrlich beantworten will: Wie weit kommt ein lokales Modell ohne Cloud? Alles, was ich zu lokaler KI schreibe, sammle ich auf der Seite KI.
Was Qwen 3.8 ist: Varianten, Lizenz, Kontext
Qwen 3.8 ist noch jung, und die Quellenlage dazu ist entsprechend dünn. Nach Angaben von yottalabs.ai und atomic.chat erschien das Modell am 13. oder 14. August 2026.
Es gibt mehrere Größen: ein 27B-Dense-Modell, eine Mixture-of-Experts-Variante mit der Bezeichnung 2.4T-A95B und eine Qwen3.8 Max; atomic.chat nennt zusätzlich eine „Flash Next"-Variante. Bei der Parameterzahl der 27B-Version widersprechen sich die Quellen leicht: codersera.com und atomic.chat schreiben 27 Milliarden, yottalabs.ai spricht von 28 Milliarden. Aufgelöst hat das bisher niemand, ich nenne es trotzdem, damit du nicht selbst darüber stolperst.
Die Lizenz ist Apache 2.0, also frei nutzbar auch für kommerzielle Zwecke; die offizielle Modellkarte führt sie so. Der Kontext liegt laut codersera.com und atomic.chat bei 262.144 Token nativ, über YaRN bis auf eine Million Token erweiterbar. Das deckt sich mit dem, was mein eigener Server meldet: 262k Kontext. Auf der Modellkarte, zitiert von atomic.chat und unsloth.ai, stehen 61,7 Prozent im SWE-bench Pro, 73,0 im Terminal Bench 2.1 und 89,2 Prozent im GPQA Diamond, Werte, die ich selbst nicht nachgeprüft habe und deshalb nur als Herstellerangabe weitergebe.
Mein Setup: Qwen 3.8 lokal unter SGLang auf dem DGX Spark
Meine Hardware ist ein Nvidia DGX Spark mit GB10-Chip und 128 GB Unified Memory, von denen das System rund 119 GB als nutzbar meldet, im Tailnet erreichbar, also über ein privates VPN von jedem meiner Geräte aus ansprechbar. Daneben steht ein MacBook Pro M3 Max mit 64 GB, dazu später mehr.
Als Modell läuft Qwen3.8-27B, Dense, mit 262k Kontext, Tool-Calling, Thinking und Vision, als NVFP4-Checkpoint mit 21,9 GB. Das Setup folgt dem Upstream-Repository hasso5703/dgx-spark-qwen38, das seit dem 21. August 2026 als offizielles SGLang-Cookbook-Rezept für dieses Modell geführt wird. Für höheren Durchsatz läuft Speculative Decoding mit einem DFlash2-Draft-Modell mit. Nach außen spricht der Server sowohl eine OpenAI- als auch eine Anthropic-kompatible API, das war für mich der Hauptgrund für SGLang: Tools, die sonst gegen Claude oder gegen eine OpenAI-kompatible Schnittstelle sprechen, laufen ohne Codeänderung gegen den lokalen Server.
Betrieben wird der Server nicht als klassischer Systemdienst, sondern als systemd-User-Unit mit aktiviertem Linger, weil ich auf dem Spark kein passwortloses sudo habe und root-Dienste deshalb keine praktikable Option sind. Als Vergleich zur SGLang-Route habe ich vLLM ebenfalls getestet: 24 bis 26 Tokens pro Sekunde mit MTP, spürbar langsamer als mein SGLang-Aufbau. Ollama ist auf dem Gerät installiert, aber ohne geladene Modelle, es liegt für den Fall bereit, dass ich mal schnell etwas anderes ausprobieren will.
Gemessene Geschwindigkeit: Tokens pro Sekunde
Die Zahl, die für mich zählt: 50,7 Tokens pro Sekunde beim Decodieren, gemessen über 300 Token, ein Stream, abgerufen vom Mac aus über Tailscale. Beim Prefill, also dem Einlesen des Prompts, liegt der Server bei rund 1.500 Tokens pro Sekunde, das macht auch bei langen Kontexten den ersten Antwort-Token schnell greifbar.
Zum Vergleich: Im Agentic Coding, also bei mehrstufigen Aufgaben mit Tool-Aufrufen, nennt das Upstream-Repo für dieselbe Kombination 32 bis 40 Tokens pro Sekunde, das ist keine eigene Messung von mir, sondern der dort dokumentierte Referenzwert für diesen Anwendungsfall. Der Unterschied zu meinen 50,7 Tokens pro Sekunde erklärt sich durch die Aufgabe: reines Decodieren eines einzelnen Streams läuft schneller als ein Agentenlauf mit Tool-Antworten, Zwischenschritten und neuem Kontext bei jeder Runde.
Stolperfallen beim Einrichten
Die wichtigste Regel zuerst: --mem-fraction-static darf nie über 0,50 liegen, sonst kann der gesamte Host einfrieren, nicht nur der Inferenz-Prozess. Ich fahre seitdem konsequent mit 0,50 und habe damit noch keinen Absturz gehabt. Warum das gerade beim Unified Memory des DGX Spark so heikel ist, steht ausführlich in DGX Spark im Test: lohnt sich der Kauf?.
Zweite Falle: Ich habe auf dem Gerät kein passwortloses sudo, root-Dienste über systemd scheiden also aus. Die Lösung ist ein systemd-User-Unit mit aktiviertem Linger, damit der Dienst auch ohne aktive Login-Session weiterläuft. Drittens die Internetleitung an meinem Standort: rund 2 MB/s, ein 70-GB-Download für Modellgewichte dauert damit mehrere Stunden, das solltest du einplanen, bevor du am Abend noch schnell ein neues Modell ziehen willst. Viertens der erste Start: Wegen des Kompilierens dauert er rund 9 Minuten, jeder weitere Start danach 5 bis 7 Minuten, das ist kein Fehler, sondern normal. Und fünftens: Docker hat auf dem Gerät ein Speicher-Cap von 100 GB, bei mehreren großen Checkpoints erreichst du diese Grenze schneller, als du denkst.
Wofür es reicht, wofür nicht
Mein Ziel mit diesem Aufbau ist eine Claude-Code-Alternative ohne Cloud für Kunden, bei denen lokale Verarbeitung ein hartes Kriterium ist. Dafür fahre ich den Terminal-Coding-Agenten Pi (pi.dev) gegen das lokale Modell und vergleiche laufend mit Claude Code, mit dem meine eigene KI-Belegschaft arbeitet. Ein abschließendes Urteil habe ich noch nicht, das ist bei mir bewusst ein laufender Test und kein fertiges Ergebnis, das ich hier verkaufen will.
Was daneben gut funktioniert: Auf derselben GPU läuft parallel Whisper large-v3 für Spracherkennung, mit 3 bis 4 GB Speicherbedarf ein kleiner Nachbar zum großen Sprachmodell. Das zeigt, dass auf dem Spark neben Qwen3.8 noch Raum für zusätzliche, kleinere Modelle bleibt. Was ich noch nicht guten Gewissens behaupten kann: dass Qwen3.8 unter SGLang bei mir schon in jeder Situation an Claude Code herankommt. Für Aufgaben mit viel Kontext, komplexen Mehrdatei-Änderungen oder unklaren Anforderungen bleibt Claude bei mir vorn, dafür ist die Belegschaft ja auch produktiv im Einsatz.
Vergleich zum Mac: DGX Spark gegen MacBook Pro M3 Max
Neben dem DGX Spark steht bei mir ein MacBook Pro M3 Max mit 64 GB RAM, auf dem ich Qwen3.8 über LM Studio in 8-bit-Quantisierung laufen lasse, dort belegt das Modell 27,5 GiB RAM. Gemessen habe ich dort 11 Tokens pro Sekunde beim Decodieren, deutlich langsamer als auf dem Spark.
| Kriterium |
DGX Spark (SGLang) |
MacBook Pro M3 Max (LM Studio) |
| Speicher |
128 GB Unified Memory nominal, rund 119 GB laut System nutzbar |
64 GB RAM |
| Quantisierung |
NVFP4, Checkpoint 21,9 GB |
8-bit, 27,5 GiB RAM belegt |
| Tokens pro Sekunde, Decode |
50,7 |
11 |
| Erreichbarkeit |
im Tailnet, von jedem Gerät aus |
lokal auf dem Gerät |
Für mich heißt das: Der Spark ist die klare Wahl, wenn mehrere Geräte auf dasselbe Modell zugreifen sollen und Geschwindigkeit zählt. Der Mac bleibt sinnvoll, wenn ich unterwegs bin und kein Tailnet-Zugriff möglich ist, auch wenn ich dann mit gut einem Fünftel der Geschwindigkeit rechnen muss.
Häufige Fragen
Läuft Qwen3.8-27B auch mit weniger als 128 GB Speicher?
Ja. Laut den gelesenen Fachquellen braucht eine 4-Bit-Quantisierung 16 bis 19 GB, eine Q4_K_M-Variante rund 17,1 GB. Mein eigener NVFP4-Checkpoint liegt bei 21,9 GB, das läuft auf deutlich kleineren GPUs als dem Speicher meines DGX Spark.
Wie schnell ist Qwen 3.8 auf dem DGX Spark?
Bei mir gemessen: 50,7 Tokens pro Sekunde beim Decodieren eines einzelnen Streams, rund 1.500 Tokens pro Sekunde beim Prefill. Das Upstream-Repo nennt für Agentic Coding mit Tool-Aufrufen 32 bis 40 Tokens pro Sekunde als Referenzwert, das ist eine andere Aufgabe als reines Decodieren.
Welche Lizenz hat Qwen 3.8?
Apache 2.0, damit auch für kommerzielle Projekte nutzbar. Die Lizenz steht so auf der offiziellen Modellkarte des Modells.
Brauche ich SGLang, oder reicht Ollama für Qwen 3.8?
Ollama ist bei mir installiert, aber ohne geladene Modelle. Für mein Setup mit OpenAI- und Anthropic-kompatibler API und Speculative Decoding war SGLang die passendere Wahl. Als Alternative habe ich vLLM getestet, dort kam ich mit MTP auf 24 bis 26 Tokens pro Sekunde, spürbar unter meinem SGLang-Wert.
Kann Qwen 3.8 Claude Code ersetzen?
Bei mir noch nicht vollständig. Ich fahre den Terminal-Agenten Pi gegen Qwen3.8 und vergleiche laufend mit Claude Code, das meine KI-Belegschaft antreibt. Für einfache, klar umrissene Aufgaben reicht es oft, bei komplexen Mehrdatei-Änderungen bleibt Claude bei mir vorn.
Wie es weitergeht
Der nächste logische Schritt aus diesem Setup ist ein direkter Vergleich derselben Aufgaben in Pi gegen Qwen3.8 und in Claude Code, den ich in Qwen vs Claude: lokal gegen Cloud auswerte. Wenn dich die Hardware selbst mehr interessiert als das Modell, findest du meine Erfahrung mit dem Gerät in DGX Spark im Test: lohnt sich der Kauf?. Einen breiteren Überblick über lokale Modelle jenseits von Qwen gebe ich in Lokale KI: was 2026 wirklich geht, und wer dieselbe Frage aus Kubernetes-Sicht stellt, findet die Antwort in Kubernetes für KI: LLMs auf GPU-Nodes.
Mein Vorschlag, wenn du selbst starten willst: Miss zuerst deinen eigenen Referenzwert mit einem kleinen Prompt, bevor du größere Kontexte oder Agenten-Workflows dagegenlaufen lässt. Das Setup-Rezept, dem ich gefolgt bin, liegt offen im Repository hasso5703/dgx-spark-qwen38, der SGLang-Server selbst im SGLang-Projekt auf GitHub.
