Qwen3.8-Flash-Next lokaal draaien als coding agent met OpenCode

Qwen3.8-Flash-Next-architectuur

Het is een hoofd-MoE-model met 125B parameters, maar slechts ongeveer 6B parameters worden per token geactiveerd. Daarnaast bevat het nog eens 51B parameters in n-gram-embeddings.

De architectuur introduceert verschillende ideeën die Qwen voor Qwen4 verkent:

• Gated DeltaNet + Qwen Sparse Attention (QSA) voor efficiëntere verwerking van lange context
• Gated Residual-verbindingen om de informatiestroom tussen lagen te verbeteren
• N-gram-embeddings die modelcapaciteit toevoegen zonder dat al die parameters actief hoeven te worden berekend

Bron: Qwen 

Het model heeft een native context window-lengte van 262.144 tokens en kan theoretisch worden uitgebreid tot 1 miljoen tokens met YaRN.

Hoe presteert Qwen3.8-Flash-Next bij coderen?

Het is ook verrassend sterk in coderen. Dit zijn enkele van Qwens eigen gerapporteerde resultaten vergeleken met Qwen3.8-27B:

Dit zijn Qwens eigen evaluaties, dus ik zou ze nog steeds behandelen als vendor-gerapporteerde resultaten, maar ze komen goed overeen met mijn ervaring met het model voor coderen.

De GPU-server voorbereiden voor Qwen3.8-Flash-Next

Ik gebruikte een RTX PRO 6000 met 96GB VRAM, maar je hebt niet per se zoveel VRAM nodig.

Dit is eigenlijk een van de interessante aspecten van Qwen3.8-Flash-Next. Omdat llama.cpp delen van het model kan offloaden naar systeeme RAM, kun je een GPU met minder VRAM gebruiken zolang je maar veel RAM beschikbaar hebt.

De Unsloth UD-Q4_K_XL-kwantisatie die we gebruiken is ongeveer 111GB en is verdeeld over vier GGUF-bestanden.

Voor mijn setup raad ik aan om minstens 140GB aan gecombineerde bruikbare RAM en VRAM te hebben, zodat er genoeg ruimte is voor het model, de context, de KV-cache en runtime-overhead.

Als je iets als een H200 hebt, kun je praktisch alles op de GPU houden. Ik koos in plaats daarvan voor de middenweg. 

Begin met het controleren van je GPU:

nvidia-smi

Je zou je GPU, driverversie, CUDA-versie en beschikbare VRAM moeten zien.

Installeer daarna de vereiste pakketten:

sudo apt update

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

llama.cpp bouwen met ondersteuning voor Qwen3.8-Flash-Next

Qwen3.8-Flash-Next gebruikt de nieuwe qwen4_exp-architectuur, wat heel anders is dan simpelweg nog een Qwen3.8-model laden.

Ondersteuning is nog erg nieuw, dus ik gebruikte de Qwen3.8-Flash-Next-branch van Unsloth in plaats van te vertrouwen op een oudere build van llama.cpp die de architectuur mogelijk niet herkent. Het bijbehorende werk aan llama.cpp voegt de nieuwe qwen4exp-architectuur, QSA, n-gram-embeddings en andere modelspecifieke componenten toe.

Ga naar de workspace:

cd /workspace

Kloon de Unsloth-branch:

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

Ga de map in:

cd llama.cpp

Bouw llama.cpp met CUDA:

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

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

Controleer tot slot of llama-server correct is gebouwd:

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

Mijn build gaf terug:

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

De Qwen3.8-Flash-Next GGUF-modelbestanden downloaden

Het downloaden van het model was eigenlijk een van de meest irritante onderdelen van deze setup.

Ik probeerde eerst ModelScope, maar de snelheid was niet geweldig. Op Hugging Face haalde de download aanvankelijk redelijke snelheden en zakte daarna ineens naar KB/s.

Hugging Face gebruikt nu zijn Xet-backend voor grote modeldownloads en schakelt normaal gesproken automatisch adaptieve concurrency in. Het biedt ook HF_HUB_DISABLE_XET om Xet uit te schakelen als dat problemen veroorzaakt.

In mijn geval werkte Xet uitschakelen en de vier GGUF-shards parallel downloaden veel beter.

Installeer de Hugging Face CLI:

pip install -U huggingface_hub

Schakel Xet uit voor deze 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 is sowieso inmiddels verouderd, aangezien Hugging Face grote transfers naar Xet heeft verplaatst.

Maak de modelmap aan:

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

Download nu alle vier de shards parallel:

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

De complete UD-Q4_K_XL-kwant is ongeveer 111GB.

Qwen3.8-Flash-Next draaien met llama.cpp

Ga terug naar de llama.cpp-map:

cd /workspace/llama.cpp

Start de 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

Ik heb bewust een contextvenster van 131.072 tokens gebruikt in plaats van de volledige native 262K-context.

Voor coding agents is 131K al enorm en geeft het OpenCode ruim voldoende plek voor bronbestanden, tooluitvoer, terminal-logs en lange gesprekken, zonder nóg meer geheugen te verspillen aan context die ik waarschijnlijk niet gebruik.

De belangrijke instellingen hier zijn:

1. --fit on laat llama.cpp automatisch bepalen hoeveel van het model op de GPU moet blijven.

2. --fit-target 4096 vertelt ’m om ongeveer 4GB GPU-geheugen vrij te laten, wat de runtime wat ademruimte geeft in plaats van direct tegen de VRAM-limiet aan te lopen. llama.cpp ondersteunt officieel zowel automatisch fitten als een configureerbare geheugenmarge.

3. De sampling-instellingen zijn ook niet willekeurig. Qwen raadt temperature=1.0, top_p=0.95, top_k=20 en min_p=0.0 aan wanneer je het model in thinking-modus gebruikt.

Zelfs na het volledig laden van het model had ik nog ruimschoots geheugen over, met grofweg 13GB VRAM beschikbaar voor het contextvenster, de KV-cache en andere applicaties.

Qwen3.8-Flash-Next-server testen met CURL

llama-server biedt een OpenAI-compatibele API.

Controleer het beschikbare model:

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

Je zou qwen3.8-flash-next moeten zien.

Laten we nu een antwoord genereren testen:

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."
      }
    ]
  }'

Als je een geldige respons krijgt, is de lokale server klaar.

Op mijn setup zag ik aanvankelijk zo’n 80 tokens per seconde, wat me verbaasde, aangezien een deel van het model in systeeme RAM stond.

Naarmate de context groter werd, zag ik snelheden dichter bij 64 tokens per seconde.

Dat is nog steeds uitstekend bruikbaar voor een model van deze grootte, en de architectuur helpt verklaren waarom. Hoewel het model 125B hoofdparameters heeft, is slechts zo’n 6B actief per token.

Qwen3.8-Flash-Next testen met de llama.cpp WebUI

Wat ik erg fijn vind aan llama.cpp is dat llama-server je al een eenvoudige WebUI geeft.

Open http://localhost:8080. Als alles goed draait, zou het model al beschikbaar moeten zijn.

Voor mijn eerste echte test vroeg ik het om in één keer een complete website voor een IT-afdeling van de overheid te bouwen:

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, 

Dit was een behoorlijk grote generatie. Het model besteedde veel tokens aan nadenken en genereerde daarna een complete website in één HTML-bestand. Het duurde ongeveer 13 minuten om te voltooien en de generatiesnelheid daalde geleidelijk naarmate de context groeide.

Maar het resultaat was veel beter dan ik had verwacht.

Het bevatte grafieken, animaties, tabs, verschillende secties, responsive styling, JavaScript-interacties en een verrassend gepolijste algehele lay-out.

Het interessante was dat dit in feite een one-shot-generatie was. Ik had niet expliciet gevraagd om veel van die kleinere details toe te voegen.

Dat was het eerste moment waarop ik me realiseerde dat dit model bijzonder goed kan zijn voor coding-taken waarbij je het wat vrijheid geeft in plaats van elk implementatiedetail te specificeren.

Qwen3.8-Flash-Next koppelen aan OpenCode

Chatten is leuk, maar ik wilde Qwen3.8-Flash-Next vooral testen als agentic coding-model.

Daarvoor gebruikte ik OpenCode. Installeer het eerst:

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

Herstart je terminal en controleer de installatie:

opencode --version

Bij mij was dat versie 1.18.23.

Maak nu de OpenCode-configuratie aan:

mkdir -p ~/.config/opencode

Voeg de lokale llama.cpp-provider toe die we eerder bouwden:

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

Het belangrijkste is http://127.0.0.1:8080/v1. 

OpenCode ondersteunt aangepaste OpenAI-compatibele providers via @ai-sdk/openai-compatible, waardoor llama.cpp heel eenvoudig te koppelen is.

Ik heb OpenCode ingesteld op een werkcontext van 65K, ook al heeft de llama.cpp-server zelf 131K beschikbaar.

Dit laat ruim voldoende marge voor lange outputs en voorkomt dat agentsessies de volledige servercontext te agressief vullen.

Qwen3.8-Flash-Next gebruiken als lokale coding agent

Navigeer naar een projectmap en start OpenCode:

cd /workspace/my-project
opencode

Nu kun je het model normale agentic coding-taken geven. Ik vroeg Qwen bijvoorbeeld om een analytics-dashboard te bouwen:

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.

Het model begon met een to-dolijst en het plannen van de applicatie voordat het alles schreef.

Binnen enkele minuten had het het eerste werkende dashboard opgeleverd. Ik vond de eerste UI niet echt mooi. Het voelde te verspreid, en er waren verschillende usability-issues.

Dus ik vertelde de agent simpelweg wat ik niet mooi vond en vroeg om de interface opnieuw op te bouwen tot een compacter systeemcommandocentrum.

De tweede versie was veel beter.

Uiteindelijk had ik een compact dashboard waarmee ik CPU, RAM, VRAM, GPU-gebruik, opslag, netwerkactiviteit en draaiende processen in realtime kon monitoren. Het voegde ook knoppen toe voor het legen van caches, het opschonen van tijdelijke bestanden en het beheren van processen.

Het interessante was hoe Qwen de implementatie benaderde. Ik testte het op twee verschillende applicaties, en het gaf vaak de voorkeur aan eenvoudige vanilla HTML, CSS en JavaScript in plaats van meteen React, Node-packages of een ander groot framework te installeren.

Ik vond dit gedrag eigenlijk prettig. Als ik geen framework specificeerde, probeerde het het eenvoudigste architectuurpad te vinden dat het probleem oploste in plaats van onnodige dependencies toe te voegen.

Het nadeel is dat het de tijd neemt. Er is veel redenering, veel gegenereerde tokens en soms flink wat debugging. Je voelt duidelijk dat het model tokens uitgeeft om het probleem door te denken.

Maar de uiteindelijke projecten voelden over het algemeen veel completer dan wat ik meestal van kleinere lokale modellen krijg.

Tot slot

Na Qwen3.8-Flash-Next te hebben getest voor websitegeneratie en agentic coding, vind ik het duidelijk een stap vooruit ten opzichte van Qwen3.8-27B. Het grootste verschil is hoe het projecten benadert. Het let meer op structuur, details en praktische implementatie in plaats van alleen code te genereren. Als je dit model lokaal wilt draaien, lees dan onze Qwen3.8-27B-tutorial.

Ik vond het ook prettig dat het vaak vertrouwde op simpele HTML, CSS, JavaScript en Python in plaats van onnodige frameworks en dependencies toe te voegen.

Het grootste nadeel is de omvang. De UD-Q4_K_XL GGUF is ongeveer 111GB, en het model kan veel denk- en outputtokens gebruiken, vooral tijdens debuggen.

Verder was de setup verrassend eenvoudig. Als je genoeg RAM en VRAM hebt, is Qwen3.8-Flash-Next een van de sterkste lokale coding-modellen die ik tot nu toe heb getest.