Qwen3.8 Flash Next: Erst zwei Sparks. Jetzt reicht einer.

Am Anfang brauchte ich beide DGX Sparks, um Qwen3.8 Flash Next in meinem Setup zu servieren. Heute läuft das Modell auf einem einzigen Gerät. Für mich ist das der entscheidende Fortschritt: Der zweite Spark wird für dieses Modell nicht mehr gebraucht. Ich kann ihn für andere Aufgaben nutzen oder auf jedem Spark eine eigene Instanz betreiben.

Das ist mehr als ein erfolgreicher Modellstart. Aus einem Verbund für eine Aufgabe werden zwei unabhängig nutzbare Rechner. Und auf dem ersten läuft ein Modell, das ich für ganz konkrete Arbeit einsetze: Mails, Texte, Code und die Pflege meiner Systeme.

Warum mich der Spark als Maschine begeistert

Der GB10 verbindet eine Arm-CPU mit einer Blackwell-GPU und 128 GB gemeinsamem Arbeitsspeicher. Dieser große Speicherpool eröffnet mir eine Modellklasse, die auf einer einzelnen Grafikkarte mit 24 GB schnell an der Speicherkapazität scheitert. Die Blackwell-Architektur bringt dazu die Rechenfunktionen für aktuelle quantisierte Inferenz mit. NVIDIA beschreibt die Hardware hier.

Dabei ist „gemeinsam“ wörtlich zu nehmen: CPU, GPU, Betriebssystem und Dateicache konkurrieren um denselben physischen Speicher. CPU-Offloading schafft auf dieser Maschine keinen zweiten, unabhängigen RAM-Vorrat. Genau diese Eigenschaft erklärt einen wichtigen Teil meiner Serving-Geschichte.

Warum ausgerechnet Qwen3.8 Flash Next?

Ich suche einen lokalen Allrounder, der schreiben, strukturieren, programmieren und mit Werkzeugen arbeiten kann. Qwen3.8 Flash Next ist dafür spannend: Die Architektur kombiniert ein großes Mixture-of-Experts-Modell mit vergleichsweise wenigen pro Token aktiven Parametern und einer zusätzlichen N-Gramm-Tabelle. Qwen nennt 125 Milliarden Kernparameter bei sechs Milliarden aktiven Parametern; die PLE-Tabelle umfasst weitere 51 Milliarden. Das native Kontextfenster beträgt 262.144 Tokens. Diese Angaben beschreiben das Modell, keine von mir gemessene Geschwindigkeit. Quelle: Qwen-Modellkarte.

Die Tabelle macht den Betrieb besonders interessant. Sie ist groß, wird aber als Nachschlagewerk verwendet. Man muss daher nicht jede ihrer Zeilen dauerhaft im schnellen Arbeitsspeicher halten. Hier setzt das Serving-Rezept an, das ich inzwischen nutze.

Die erste Etappe: zwei Sparks für einen Dienst

Mein altes Startskript ist noch vorhanden. Es startet SGLang mit einem NVFP4-Checkpoint, zwei Knoten und Tensor Parallelism mit Größe zwei. Die Geräte bekommen unterschiedliche Ränge und kommunizieren über die schnelle Verbindung zwischen den Sparks. Beide arbeiten damit an demselben Modell.

Das war ein funktionierender Weg, hat aber beide Maschinen gebunden. Dazu kamen die Voraussetzungen des Verbunds: passende Images, Netzwerk, Kommunikation zwischen den Rängen und ein gemeinsamer Start. Für meinen Alltag wollte ich das Modell auf einem einzelnen Gerät verfügbar haben.

Die Lösung: Gewichte und Nachschlagetabelle unterschiedlich behandeln

Heute verwende ich auf dem Spark mit der internen Endung .170 ein angepasstes vLLM-Image und einen AutoRound-Hybrid-Checkpoint. Der Aufbau basiert auf der Arbeit von blazux und dem AutoRound-Fork von Saren-Arterius. Die grundlegenden Patches stammen aus diesen Projekten; meine Dokumentation beschreibt deren konkrete Einbindung und Einstellungen in meinem Betrieb.

Die Expertengewichte liegen im INT4-Pfad, der Ausgabekopf in INT8 und weitere Schichten in FP8 vor. Die FP8-PLE-Tabelle wird separat eingebunden und über Memory Mapping von der NVMe angesprochen. Benötigte Zeilen werden nachgeladen, statt die vollständige Tabelle als dauerhaft residente GPU-Gewichte vorzuhalten.

Das spart Speicher, macht die SSD aber zu einem Teil des Inferenzpfads. Dateicache und Seitenzugriffe verschwinden nicht. Deshalb lasse ich die Tabelle in meiner Konfiguration nicht komplett vorwärmen.

Die Probleme sitzen zwischen Modell, Speicher und Runtime

Der aktuelle Dienst wurde am 17. September 2026 geprüft: Health und Modellliste antworten erfolgreich. Zwei kleine Funktionsproben lieferten außerdem eine korrekte Textantwort und einen strukturierten Tool-Aufruf. Das belegt den grundlegenden API-Pfad, ist aber kein Lasttest. Konfiguriert sind 262.144 Tokens maximale Kontextlänge, acht gleichzeitige Sequenzen, Prefix Caching, Chunked Prefill und MTP mit zwei spekulativen Tokens.

Acht Sequenzen bedeuten nicht acht voll belegte Kontextfenster gleichzeitig. Und ein gestarteter Server belegt noch keine zuverlässige Bearbeitung jeder Aufgabe. Gerade lange Eingaben, parallele Nutzer und Werkzeugschleifen müssen getrennt betrachtet werden.

OpenCode macht daraus einen Arbeitsablauf

Das Modell stellt eine OpenAI-kompatible API bereit. OpenCode übernimmt darüber die Sitzung und den Ablauf aus Anfrage, Werkzeugaufruf und weiterer Antwort. In meinem NEX-Aufbau kommen die Werkzeuge über MCP hinzu.

Wichtig ist die explizite Auswahl: Der Provider auf .170 trägt aus der vorherigen Konfiguration noch den Namen deepseek, bietet aber inzwischen qwen3.8-flash-next an. Die passende Kombination lautet dort deepseek/qwen3.8-flash-next. Der alte globale Default verweist noch auf das frühere DeepSeek-Modell; ihn sollte man nicht ungeprüft in eine Anleitung übernehmen.

Ein sprechender Providername ist hilfreich. Entscheidend für den Aufruf sind jedoch die tatsächlich konfigurierte Adresse und die vom Server angebotene Modell-ID. Das GitHub-Begleitmaterial trennt deshalb mein Bestandssetup von einem bereinigten Beispiel.

Wofür ich das Modell einsetze

Bei Mails geht es um das Verarbeiten von Inhalten, das Herausarbeiten der nächsten Schritte und vorbereitete Antworten. Für den Blog entstehen Gliederungen und Entwürfe; für Kommentare Antwortvorschläge, die zur jeweiligen Unterhaltung passen müssen.

Dazu kommen kleinere Programmierungen am System, Website-Pflege und die Arbeit an n8n-Workflows. Hier zählt, ob ein Modell vorhandenen Code versteht, ein passendes Werkzeug findet und eine Änderung nachvollziehbar vorbereitet. Ein hübscher Codeblock allein erledigt die Aufgabe noch nicht.

Auch Dokumente und Vertragsentwürfe gehören dazu. Das Modell hilft bei Struktur, Formulierungen und dem Übernehmen bereitgestellter Angaben. Ein Vertragsentwurf bleibt ein Entwurf; inhaltliche Entscheidungen und Freigabe gehören zum Arbeitsablauf.

Diese Aufgaben machen den Nutzen für mich greifbar. Ich muss keinen fremden Benchmark zur eigenen Erfolgsmeldung erklären. Die Frage ist, wie gut der lokale Dienst in meine tatsächlichen Prozesse passt.

Was durch den freien Spark gewonnen ist

Der zweite Spark ist jetzt nicht automatisch ausgeschaltet oder untätig. Er ist frei von der Pflicht, die zweite Hälfte dieses Modells zu tragen. Ich kann dort ein anderes Modell ausprobieren oder eine zweite Qwen-Instanz unabhängig betreiben.

Genau darin liegt für mich die Stärke dieses Setups: gute Hardware, ein brauchbares Modell und ein Serving, das beide sinnvoll zusammenbringt. Der Schritt von zwei notwendigen Geräten zu einem verändert, was ich mit meiner vorhandenen Hardware machen kann.