Qwen3.8-Flash-Next lokal als Coding-Agent mit OpenCode ausführen

Qwen3.8-Flash-Next-Architektur

Es ist ein MoE-Hauptmodell mit 125B Parametern, von denen pro Token nur etwa 6B aktiviert sind. Zusätzlich kommen 51B Parameter in N-Gramm-Embeddings hinzu.

Die Architektur führt mehrere Ideen ein, die Qwen für Qwen4 erprobt:

• Gated DeltaNet + Qwen Sparse Attention (QSA) für effizientere Verarbeitung langer Kontexte
• Gated Residual-Verbindungen für besseren Informationsfluss zwischen den Schichten
• N-Gramm-Embeddings, die die Modellkapazität erhöhen, ohne dass alle Parameter aktiv berechnet werden müssen

Quelle: Qwen 

Das Modell besitzt ein natives Kontextfenster von 262.144 Tokens und lässt sich mit YaRN theoretisch auf 1 Million Tokens erweitern.

Wie gut ist Qwen3.8-Flash-Next beim Coden?

Auch beim Programmieren ist es überraschend stark. Das sind einige von Qwens eigenen Ergebnissen im Vergleich zu Qwen3.8-27B:

Diese Werte stammen aus Qwens eigenen Evaluierungen und sind daher herstellerseitig gemeldet. Sie decken sich aber gut mit meiner Erfahrung beim Coden mit dem Modell.

Den GPU-Server für Qwen3.8-Flash-Next vorbereiten

Ich habe eine RTX PRO 6000 mit 96 GB VRAM verwendet, aber so viel VRAM brauchst du nicht unbedingt.

Das ist tatsächlich einer der interessanten Punkte bei Qwen3.8-Flash-Next. Da llama.cpp Teile des Modells in den Systemspeicher auslagern kann, reicht auch eine GPU mit weniger VRAM – vorausgesetzt, du hast reichlich RAM.

Die von uns verwendete Unsloth-Quantisierung UD-Q4_K_XL ist etwa 111 GB groß und auf vier GGUF-Dateien verteilt.

Für mein Setup empfehle ich mindestens 140 GB kombinierbaren nutzbaren RAM und VRAM, damit genug Platz für Modell, Kontext, KV-Cache und Runtime-Overhead bleibt.

Mit einer H200 könntest du praktisch alles auf der GPU halten. Ich habe mich für den Mittelweg entschieden. 

Starte mit einer GPU-Prüfung:

nvidia-smi

Du solltest GPU, Treiberversion, CUDA-Version und verfügbaren VRAM sehen.

Als Nächstes installierst du die benötigten Pakete:

sudo apt update

sudo apt install -y \
  git \
  cmake \
  build-essential \
  curl \
  libcurl4-openssl-dev \
  python3-pip

llama.cpp mit Qwen3.8-Flash-Next-Support bauen

Qwen3.8-Flash-Next nutzt die neue qwen4_exp-Architektur, die sich deutlich davon unterscheidet, einfach ein weiteres Qwen3.8-Modell zu laden.

Die Unterstützung ist noch sehr frisch, daher habe ich den von Unsloth gepflegten Qwen3.8-Flash-Next-Branch verwendet, statt mich auf einen älteren llama.cpp-Build zu verlassen, der die Architektur eventuell nicht erkennt. Die zugehörige Arbeit an llama.cpp fügt die neue qwen4exp-Architektur, QSA, N-Gramm-Embeddings und weitere modellspezifische Komponenten hinzu.

Wechsle ins Arbeitsverzeichnis:

cd /workspace

Klonen des Unsloth-Branches:

git clone \
  --branch qwen4exp/qwen3.8-flash-next \
  https://github.com/unslothai/llama.cpp.git

Wechsle ins Verzeichnis:

cd llama.cpp

Baue llama.cpp mit CUDA:

cmake -B build \
  -DGGML_CUDA=ON \
  -DCMAKE_BUILD_TYPE=Release

cmake --build build \
  --config Release \
  -j"$(nproc)"

Prüfe abschließend, ob llama-server korrekt gebaut wurde:

./build/bin/llama-server --version

Mein Build gab Folgendes zurück:

version: 0.3.0-dev (build 10656, commit 035e22731)
built with GNU 13.3.0 for Linux x86_64

Das Qwen3.8-Flash-Next-GGUF-Modell herunterladen

Der Download des Modells war tatsächlich einer der nervigeren Teile dieses Setups.

Ich habe zuerst ModelScope ausprobiert, aber die Geschwindigkeit war mau. Bei Hugging Face startete der Download ordentlich und fiel dann plötzlich in den KB/s-Bereich.

Hugging Face nutzt für große Modelldownloads inzwischen sein Xet-Backend und aktiviert normalerweise automatisch adaptive Concurrency. Mit HF_HUB_DISABLE_XET lässt sich Xet bei Problemen deaktivieren.

In meinem Fall war Xet zu deaktivieren und die vier GGUF-Shards parallel herunterzuladen deutlich besser.

Installiere die Hugging Face CLI:

pip install -U huggingface_hub

Deaktiviere Xet für diesen Download:

export HF_HUB_DISABLE_XET=1
unset HF_XET_HIGH_PERFORMANCE
unset HF_XET_NUM_CONCURRENT_RANGE_GETS
unset HF_HUB_ENABLE_HF_TRANSFER

HF_HUB_ENABLE_HF_TRANSFER ist ohnehin veraltet, da Hugging Face große Übertragungen auf Xet umgestellt hat.

Lege das Modellverzeichnis an:

cd /workspace
mkdir -p Qwen3.8-Flash-Next-GGUF

Lade nun alle vier Shards parallel herunter:

for i in 1 2 3 4; do
  shard=$(printf "%05d" "$i")

  hf download unsloth/Qwen3.8-Flash-Next-GGUF \
    "UD-Q4_K_XL/Qwen3.8-Flash-Next-UD-Q4_K_XL-${shard}-of-00004.gguf" \
    --local-dir Qwen3.8-Flash-Next-GGUF &
done

wait

Das komplette UD-Q4_K_XL-Quant liegt bei ungefähr 111 GB.

Qwen3.8-Flash-Next mit llama.cpp ausführen

Zurück ins llama.cpp-Verzeichnis:

cd /workspace/llama.cpp

Starte den Server:

./build/bin/llama-server \
  -m /workspace/Qwen3.8-Flash-Next-GGUF/UD-Q4_K_XL/Qwen3.8-Flash-Next-UD-Q4_K_XL-00001-of-00004.gguf \
  --alias qwen3.8-flash-next \
  --host 0.0.0.0 \
  --port 8080 \
  --ctx-size 131072 \
  --parallel 1 \
  --flash-attn on \
  --fit on \
  --fit-target 4096 \
  --jinja \
  --batch-size 1024 \
  --ubatch-size 512 \
  --temp 1.0 \
  --top-p 0.95 \
  --top-k 20 \
  --min-p 0.0

Ich habe bewusst ein Kontextfenster von 131.072 Tokens statt der vollen 262K gewählt.

Für Coding-Agenten ist 131K bereits riesig und bietet OpenCode reichlich Platz für Quelltexte, Tool-Ausgaben, Terminal-Logs und lange Gespräche – ohne noch mehr Speicher für einen Kontext zu verschwenden, den ich vermutlich nicht nutze.

Wichtige Einstellungen hier sind:

1. --fit on lässt llama.cpp automatisch bestimmen, wie viel des Modells auf der GPU bleiben sollte.

2. --fit-target 4096 weist an, rund 4 GB GPU-Speicher frei zu lassen – das gibt der Laufzeit Luft, anstatt direkt am VRAM-Limit zu operieren. llama.cpp unterstützt sowohl automatisches Fitting als auch eine konfigurierbare Zielmarge.

3. Auch die Sampling-Settings sind nicht zufällig. Qwen empfiehlt temperature=1.0, top_p=0.95, top_k=20 und min_p=0.0 im Thinking-Modus.

Selbst nach dem Laden des gesamten Modells blieb noch reichlich Speicher: Rund 13 GB VRAM waren für Kontextfenster, KV-Cache und andere Anwendungen frei.

Qwen3.8-Flash-Next-Server mit CURL testen

llama-server stellt eine OpenAI-kompatible API bereit.

Prüfe die verfügbaren Modelle:

curl http://127.0.0.1:8080/v1/models

Du solltest qwen3.8-flash-next sehen.

Testen wir nun eine Antwortgenerierung:

curl http://127.0.0.1:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3.8-flash-next",
    "messages": [
      {
        "role": "user",
        "content": "Write a Python function that checks whether a number is prime."
      }
    ]
  }'

Wenn du eine gültige Antwort erhältst, ist der lokale Server bereit.

Auf meinem Setup lag die Anfangsgeschwindigkeit bei rund 80 Tokens pro Sekunde – erstaunlich, da Teile des Modells im RAM lagen.

Mit wachsendem Kontext sank die Geschwindigkeit auf etwa 64 Tokens pro Sekunde.

Für ein Modell dieser Größe ist das immer noch sehr gut, und die Architektur erklärt warum: Obwohl das Modell 125B Hauptparameter hat, sind pro Token nur etwa 6B aktiv.

Qwen3.8-Flash-Next mit der llama.cpp-WebUI testen

Was ich an llama.cpp sehr mag: llama-server bringt bereits eine einfache WebUI mit.

Öffne http://localhost:8080. Wenn alles korrekt läuft, sollte das Modell bereits verfügbar sein.

Für meinen ersten richtigen Test bat ich es, in einem Rutsch eine vollständige Website einer Regierungs-IT-Abteilung zu bauen:

Create a modern, professional government IT department portfolio website in a single index.html file.
Use HTML, CSS, and JavaScript featuring a clean official design and responsive layout with smooth animations, interactive elements, and accessible government-style navigation.
It should display department overview, key services, digital transformation projects, achievements, technology initiatives, statistics, leadership/team section, latest updates, contact information, 

Das war eine ziemlich große Generierung. Das Modell „dachte“ viele Tokens lang und erzeugte dann eine komplette Website in einer einzigen HTML-Datei. Das dauerte rund 13 Minuten; mit wachsendem Kontext fiel die Generierungsgeschwindigkeit schrittweise.

Das Ergebnis war deutlich besser als erwartet.

Es enthielt Diagramme, Animationen, Tabs, verschiedene Sektionen, responsives Styling, JavaScript-Interaktionen und ein überraschend poliertes Gesamtlayout.

Spannend war, dass es praktisch eine One-Shot-Generierung war. Viele der kleineren Details hatte ich nicht explizit gefordert.

Da wurde mir klar, dass dieses Modell besonders für Coding-Aufgaben geeignet sein könnte, bei denen du ihm etwas Freiheit lässt, statt jedes Detail vorzugeben.

Qwen3.8-Flash-Next mit OpenCode verbinden

Chatten ist nett, aber ich wollte Qwen3.8-Flash-Next vor allem als agentisches Coding-Modell testen.

Dafür nutzte ich OpenCode. Installiere es zuerst:

curl -fsSL https://opencode.ai/install | bash

Starte dein Terminal neu und prüfe die Installation:

opencode --version

Bei mir war es Version 1.18.23.

Erstelle nun die OpenCode-Konfiguration:

mkdir -p ~/.config/opencode

Füge den lokalen, zuvor gebauten llama.cpp-Provider hinzu:

printf '%s\n' '{"$schema":"https://opencode.ai/config.json","model":"llama.cpp/qwen3.8-flash-next","provider":{"llama.cpp":{"npm":"@ai-sdk/openai-compatible","name":"Qwen3.8 Flash Next Local","options":{"baseURL":"http://127.0.0.1:8080/v1"},"models":{"qwen3.8-flash-next":{"name":"Qwen3.8 Flash Next","limit":{"context":65536,"output":32768}}}}}}' > ~/.config/opencode/opencode.json

Der wichtigste Teil ist http://127.0.0.1:8080/v1. 

OpenCode unterstützt benutzerdefinierte OpenAI-kompatible Provider über @ai-sdk/openai-compatible – so lässt sich llama.cpp sehr einfach anbinden.

Ich habe OpenCode auf einen 65K Arbeitskontext gesetzt, obwohl der llama.cpp-Server 131K bereitstellt.

So bleibt genug Puffer für lange Ausgaben, und Agent-Sessions füllen den gesamten Serverkontext nicht zu aggressiv.

Qwen3.8-Flash-Next als lokalen Coding-Agenten nutzen

Navigiere in ein Projektverzeichnis und starte OpenCode:

cd /workspace/my-project
opencode

Jetzt kannst du dem Modell normale agentische Coding-Aufgaben geben. Ich ließ Qwen zum Beispiel ein Analytics-Dashboard bauen:

Build a modern system analytics and task-management dashboard. 
It should monitor CPU, RAM, VRAM, GPU usage, temperatures, disk usage, running processes, and temporary files. 
Users should be able to safely terminate tasks, free unused RAM/VRAM, clear caches, and clean temporary files from one interface.

Das Modell startete mit einer To-do-Liste und der Planung der Anwendung, bevor es den Code schrieb.

Nach wenigen Minuten stand das erste funktionierende Dashboard. Die erste UI mochte ich nicht – zu luftig, mit einigen Usability-Problemen.

Also sagte ich dem Agenten einfach, was mich stört, und bat um einen kompakteren System-Kontrollraum.

Die zweite Version war deutlich besser.

Am Ende hatte ich ein kompaktes Dashboard, in dem ich CPU, RAM, VRAM, GPU-Auslastung, Speicher, Netzwerkaktivität und laufende Prozesse in Echtzeit überwachen konnte. Es gab zudem Aktionen zum Leeren von Caches, Reinigen temporärer Dateien und Verwalten von Prozessen.

Interessant war der Implementierungsansatz. In zwei verschiedenen Anwendungen bevorzugte Qwen oft pures HTML, CSS und JavaScript statt sofort React, Node-Pakete oder ein anderes großes Framework einzusetzen.

Das gefiel mir. Wenn ich kein Framework vorgebe, sucht es die einfachste Architektur, die das Problem löst – ohne unnötige Abhängigkeiten.

Der Nachteil: Es nimmt sich Zeit. Viel Reasoning, viele generierte Tokens und teils einiges an Debugging. Man merkt, wie das Modell das Problem gedanklich durchdringt.

Dafür fühlten sich die fertigen Projekte meist deutlich vollständiger an als das, was ich sonst von kleineren lokalen Modellen bekomme.

Fazit

Nach meinen Tests mit Website-Generierung und agentischem Coden ist Qwen3.8-Flash-Next für mich ein klarer Schritt vor Qwen3.8-27B. Der größte Unterschied liegt im Projektansatz: mehr Fokus auf Struktur, Details und praktische Umsetzung statt bloßem Code-Spucken. Wenn du dieses Modell lokal laufen lassen willst, lies unser Qwen3.8-27B-Tutorial.

Mir gefiel auch, dass es oft auf einfaches HTML, CSS, JavaScript und Python setzt, statt unnötige Frameworks und Abhängigkeiten einzubauen.

Der Hauptnachteil ist die Größe. Das UD-Q4_K_XL-GGUF liegt bei rund 111 GB, und das Modell verbraucht beim Debuggen gerne viele Reasoning- und Output-Tokens.

Abgesehen davon war das Setup überraschend unkompliziert. Wenn du genug RAM und VRAM hast, ist Qwen3.8-Flash-Next eines der stärksten lokalen Coding-Modelle, die ich bisher getestet habe.