Så kör du Qwen3.8-Flash-Next lokalt som kodningsagent med OpenCode

Qwen3.8-Flash-Next-arkitektur

Det är en huvudmodell med 125 miljarder parametrar i MoE, men bara cirka 6 miljarder parametrar aktiveras per token. Den inkluderar även ytterligare 51 miljarder parametrar i n-gram-inbäddningar.

Arkitekturen introducerar flera idéer som Qwen utforskar för Qwen4:

• Gated DeltaNet + Qwen Sparse Attention (QSA) för effektivare hantering av långa kontexter
• Gated residualkopplingar för att förbättra informationsflödet mellan lager
• N-gram-inbäddningar som ökar modellkapaciteten utan att alla dessa parametrar behöver beräknas aktivt

Källa: Qwen 

Modellen har ett inbyggt kontextfönster på 262 144 token och kan teoretiskt förlängas till 1 miljon token med YaRN.

Hur presterar Qwen3.8-Flash-Next vid kodning?

Den är också förvånansvärt stark på kodning. Här är några av Qwens egna rapporterade resultat jämfört med Qwen3.8-27B:

Detta är Qwens egna utvärderingar, så jag skulle fortfarande se dem som leverantörrapporterade resultat, men de stämmer ganska väl med min erfarenhet av att använda modellen för kodning.

Förbereda GPU-servern för Qwen3.8-Flash-Next

Jag använde ett RTX PRO 6000 med 96 GB VRAM, men du behöver inte nödvändigtvis så mycket VRAM.

Detta är faktiskt en av de intressanta delarna med Qwen3.8-Flash-Next. Eftersom llama.cpp kan lasta av delar av modellen till systemets RAM kan du använda ett grafikkort med mindre VRAM så länge du har gott om RAM tillgängligt.

Unsloths UD-Q4_K_XL-kvantisering som vi använder är runt 111 GB och är uppdelad i fyra GGUF-filer.

För min uppsättning rekommenderar jag att ha minst 140 GB kombinerat användbart RAM och VRAM för att säkerställa att det finns tillräckligt med utrymme för modellen, kontext, KV-cache och körningens overhead.

Om du har något som en H200 kan du lägga praktiskt taget allt på GPU:n. Jag valde istället en medelväg. 

Börja med att kontrollera din GPU:

nvidia-smi

Du bör se din GPU, drivrutinsversion, CUDA-version och tillgängligt VRAM.

Installera sedan de nödvändiga paketen:

sudo apt update

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

Bygga llama.cpp med stöd för Qwen3.8-Flash-Next

Qwen3.8-Flash-Next använder den nya qwen4_exp-arkitekturen, vilket är något helt annat än att bara ladda en annan Qwen3.8-modell.

Stödet är fortfarande väldigt nytt, så jag använde Unsloths Qwen3.8-Flash-Next-gren i stället för att förlita mig på en äldre build av llama.cpp som kanske inte känner igen arkitekturen. Det motsvarande arbetet i llama.cpp lägger till den nya qwen4exp-arkitekturen, QSA, n-gram-inbäddningar och andra modellspecifika komponenter.

Gå till arbetskatalogen:

cd /workspace

Klona Unsloth-grenen:

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

Gå in i katalogen:

cd llama.cpp

Bygg llama.cpp med CUDA:

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

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

Bekräfta till sist att llama-server byggdes korrekt:

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

Min build returnerade:

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

Ladda ner Qwen3.8-Flash-Next GGUF-modellen

Nedladdningen av modellen var faktiskt en av de mest irriterande delarna av denna setup.

Jag testade först ModelScope, men hastigheten var inte bra. På Hugging Face nådde nedladdningen först hyggliga hastigheter och föll sedan plötsligt ner till KB/s.

Hugging Face använder nu sin Xet-backend för nedladdning av stora modeller och aktiverar normalt adaptiv samtidighet automatiskt. Den tillhandahåller också HF_HUB_DISABLE_XET för att inaktivera Xet när det ställer till problem.

I mitt fall stängde jag av Xet och laddade ner de fyra GGUF-shardarna parallellt, vilket fungerade mycket bättre.

Installera Hugging Face CLI:

pip install -U huggingface_hub

Inaktivera Xet för denna nedladdning:

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 är numera föråldrat ändå, eftersom Hugging Face har flyttat stora överföringar till Xet.

Skapa modellkatalogen:

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

Ladda nu ner alla fyra shardar parallellt:

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

Den kompletta UD-Q4_K_XL-kvantiseringen är cirka 111 GB.

Köra Qwen3.8-Flash-Next med llama.cpp

Gå tillbaka till katalogen llama.cpp:

cd /workspace/llama.cpp

Starta servern:

./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

Jag använde medvetet ett kontextfönster på 131 072 token i stället för det fulla inbyggda 262K.

För kodningsagenter är 131K redan enormt och ger OpenCode gott om utrymme för källfiler, verktygsutdata, terminal-loggar och långa konversationer utan att slösa ännu mer minne på kontext som jag sannolikt inte kommer använda.

De viktiga inställningarna här är:

1. --fit on låter llama.cpp automatiskt avgöra hur mycket av modellen som ska hållas på GPU:n.

2. --fit-target 4096 talar om att lämna omkring 4 GB GPU-minne fritt, vilket ger körningen lite svängrum i stället för att ligga direkt på VRAM-gränsen. llama.cpp stöder officiellt både automatisk anpassning och en konfigurerbar minnesmarginal.

3. Urvalsparametrarna är inte heller slumpmässiga. Qwen rekommenderar temperature=1.0, top_p=0.95, top_k=20 och min_p=0.0 när modellen används i "thinking mode".

Även efter att hela modellen laddats hade jag gott om minne kvar, med ungefär 13 GB VRAM tillgängligt för kontextfönster, KV-cache och andra applikationer.

Testa Qwen3.8-Flash-Next-servern med CURL

llama-server exponerar ett OpenAI-kompatibelt API.

Kontrollera tillgänglig modell:

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

Du bör se qwen3.8-flash-next.

Låt oss nu testa att generera ett svar:

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

Om du får ett giltigt svar är den lokala servern redo.

I min uppsättning såg jag initialt runt 80 token per sekund, vilket förvånade mig med tanke på att en del av modellen låg i systemets RAM.

När kontexten blev större såg jag hastigheter närmare 64 token per sekund.

Det är fortfarande mycket användbart för en modell i den här storleken, och arkitekturen hjälper till att förklara varför. Även om modellen har 125 miljarder huvudparametrar är bara cirka 6 miljarder aktiva per token.

Testa Qwen3.8-Flash-Next med llama.cpp WebUI

En sak jag verkligen gillar med llama.cpp är att llama-server redan ger dig ett enkelt WebUI.

Öppna http://localhost:8080. Om allt körs korrekt ska modellen redan vara tillgänglig.

För mitt första ordentliga test bad jag den bygga en komplett webbplats för en statlig IT-avdelning i ett svep:

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, 

Detta var en ganska stor generering. Modellen "tänkte" många token och genererade sedan en hel webbplats i en enda HTML-fil. Det tog ungefär 13 minuter att bli klar, och genereringshastigheten sjönk gradvis i takt med att kontexten växte.

Men resultatet var mycket bättre än jag väntat mig.

Den inkluderade diagram, animationer, flikar, olika sektioner, responsiv styling, JavaScript-interaktioner och en förvånansvärt polerad helhetslayout.

Det intressanta var att detta i princip var en one-shot-generering. Jag bad inte uttryckligen att den skulle lägga till många av de där mindre detaljerna.

Det var första gången jag insåg att den här modellen kan vara särskilt bra för kodningsuppgifter där du ger den lite frihet i stället för att specificera varje liten implementeringsdetalj.

Koppla Qwen3.8-Flash-Next till OpenCode

Att chatta är trevligt, men jag ville främst testa Qwen3.8-Flash-Next som en agentisk kodningsmodell.

För det använde jag OpenCode. Installera det först:

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

Starta om din terminal och kontrollera installationen:

opencode --version

I mitt fall var det version 1.18.23.

Skapa nu OpenCode-konfigurationen:

mkdir -p ~/.config/opencode

Lägg till den lokala leverantören för llama.cpp som vi byggde tidigare:

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

Den viktigaste delen är http://127.0.0.1:8080/v1. 

OpenCode stöder anpassade OpenAI-kompatibla leverantörer via @ai-sdk/openai-compatible, vilket gör llama.cpp mycket lätt att koppla upp.

Jag satte OpenCode till 65K arbetskontext även om själva llama.cpp-servern har 131K tillgängligt.

Det lämnar gott om utrymme för långa utdata och hindrar agentsessioner från att fylla hela serverkontexten alltför aggressivt.

Använda Qwen3.8-Flash-Next som lokal kodningsagent

Navigera till en projektkatalog och starta OpenCode:

cd /workspace/my-project
opencode

Nu kan du ge modellen vanliga agentiska kodningsuppgifter. Jag bad till exempel Qwen att bygga en analysdashboard:

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.

Modellen började med att skapa en att-göra-lista och planera applikationen innan den skrev allting.

Inom några minuter hade den producerat den första fungerande dashboarden. Jag gillade inte riktigt det första UI:t. Det kändes för utspritt och det fanns flera användbarhetsproblem.

Så jag talade helt enkelt om för agenten vad jag inte gillade och bad den bygga om gränssnittet till ett mer kompakt systemkommandocenter.

Den andra versionen var mycket bättre.

Jag slutade med en kompakt dashboard där jag kunde övervaka CPU, RAM, VRAM, GPU-användning, lagring, nätverksaktivitet och körande processer i realtid. Den lade också till kontroller för att rensa cache, städa temporära filer och hantera processer.

Det intressanta var hur Qwen angrep implementationen. Jag testade den på två olika applikationer, och den föredrog ofta enkel vanilla HTML, CSS och JavaScript i stället för att omedelbart installera React, Node-paket eller något annat stort ramverk.

Jag gillade faktiskt detta beteende. Om jag inte specificerade ett ramverk försökte den hitta den enklaste arkitekturen som löste problemet i stället för att lägga till onödiga beroenden.

Nackdelen är att den tar sin tid. Det är mycket resonemang, många genererade token och ibland en hel del felsökning. Du känner definitivt att modellen spenderar token på att tänka igenom problemet.

Men slutprojekten kändes generellt mycket mer kompletta än vad jag brukar få från mindre lokala modeller.

Avslutande tankar

Efter att ha testat Qwen3.8-Flash-Next för webbplatsskapande och agentisk kodning tycker jag att den är ett tydligt steg upp från Qwen3.8-27B. Den största skillnaden är hur den närmar sig projekt. Den lägger mer vikt vid struktur, detaljer och praktisk implementering i stället för att bara generera kod. Om du är intresserad av att köra denna modell lokalt, läs vår Qwen3.8-27B-handledning.

Jag gillade också att den ofta förlitade sig på enkel HTML, CSS, JavaScript och Python i stället för att lägga till onödiga ramverk och beroenden.

Den största nackdelen är storleken. UD-Q4_K_XL GGUF är runt 111 GB, och modellen kan använda många resonemangs- och utdata-token, särskilt under felsökning.

I övrigt var uppsättningen förvånansvärt okomplicerad. Om du har tillräckligt med RAM och VRAM är Qwen3.8-Flash-Next en av de starkaste lokala kodningsmodeller jag har testat hittills.