Come eseguire Qwen3.8-Flash-Next in locale come agente di coding con OpenCode

Architettura di Qwen3.8-Flash-Next

È un modello MoE principale da 125B parametri, ma solo circa 6B parametri vengono attivati per token. Include inoltre ulteriori 51B parametri in embedding n-gram.

L’architettura introduce diverse idee che Qwen sta esplorando per Qwen4:

• Gated DeltaNet + Qwen Sparse Attention (QSA) per un’elaborazione più efficiente dei contesti lunghi
• Connessioni Residuali con gating per migliorare il flusso di informazioni tra i layer
• Embedding n-gram che aggiungono capacità al modello senza richiedere il computo attivo di tutti quei parametri

Fonte: Qwen 

Il modello ha una lunghezza nativa della finestra di contesto di 262.144 token e può teoricamente essere estesa a 1 milione di token usando YaRN.

Come si comporta Qwen3.8-Flash-Next nel coding?

È sorprendentemente forte anche nel coding. Questi sono alcuni dei risultati riportati da Qwen confrontati con Qwen3.8-27B:

Si tratta di valutazioni fornite da Qwen, quindi le considererei comunque risultati riportati dal vendor, ma sono in linea con la mia esperienza nell’uso del modello per il coding.

Preparare il server GPU per Qwen3.8-Flash-Next

Ho usato una RTX PRO 6000 con 96GB di VRAM, ma non è strettamente necessario averne così tanta.

Questo è in realtà uno degli aspetti interessanti di Qwen3.8-Flash-Next. Poiché llama.cpp può offloadare parti del modello sulla RAM di sistema, puoi usare una GPU con meno VRAM purché tu abbia molta RAM disponibile.

La quantizzazione Unsloth UD-Q4_K_XL che stiamo usando è di circa 111GB ed è suddivisa in quattro file GGUF.

Per il mio setup, consiglierei di avere almeno 140GB di RAM e VRAM utilizzabili complessive per garantire spazio sufficiente a modello, contesto, KV cache e overhead di runtime.

Se hai, ad esempio, una H200, potresti tenere praticamente tutto sulla GPU. Io ho scelto invece una via di mezzo. 

Inizia controllando la tua GPU:

nvidia-smi

Dovresti vedere la tua GPU, la versione del driver, la versione di CUDA e la VRAM disponibile.

Poi, installa i pacchetti richiesti:

sudo apt update

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

Compilare llama.cpp con supporto a Qwen3.8-Flash-Next

Qwen3.8-Flash-Next usa la nuova architettura qwen4_exp, molto diversa dal semplice caricamento di un altro modello Qwen3.8.

Il supporto è ancora nuovissimo, quindi ho usato il branch Qwen3.8-Flash-Next mantenuto da Unsloth invece di affidarmi a una build più vecchia di llama.cpp che potrebbe non riconoscere l’architettura. Il lavoro corrispondente su llama.cpp aggiunge la nuova architettura qwen4exp, QSA, embedding n-gram e altri componenti specifici del modello.

Spostati nella workspace:

cd /workspace

Clona il branch di Unsloth:

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

Entra nella directory:

cd llama.cpp

Compila llama.cpp con CUDA:

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

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

Infine, conferma che llama-server sia stato compilato correttamente:

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

La mia build ha restituito:

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

Scaricare il modello GGUF di Qwen3.8-Flash-Next

Scaricare il modello è stata in realtà una delle parti più fastidiose di questo setup.

Ho provato prima ModelScope, ma la velocità non era granché. Su Hugging Face, il download inizialmente ha raggiunto buone velocità per poi crollare improvvisamente a pochi KB/s.

Hugging Face ora usa il backend Xet per i download di modelli di grandi dimensioni e normalmente abilita automaticamente la concorrenza adattiva. Fornisce anche HF_HUB_DISABLE_XET per disabilitare Xet quando crea problemi.

Nel mio caso, disabilitare Xet e scaricare in parallelo i quattro shard GGUF ha funzionato molto meglio.

Installa la CLI di Hugging Face:

pip install -U huggingface_hub

Disabilita Xet per questo 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 è comunque deprecato, dato che Hugging Face ha spostato i trasferimenti grandi su Xet.

Crea la directory del modello:

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

Ora scarica tutti e quattro gli shard in parallelo:

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

La quantizzazione UD-Q4_K_XL completa è di circa 111GB.

Eseguire Qwen3.8-Flash-Next con llama.cpp

Torna alla directory di llama.cpp:

cd /workspace/llama.cpp

Avvia il 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

Ho deliberatamente usato una finestra di contesto da 131.072 token invece dell’intero contesto nativo da 262K.

Per gli agenti di coding, 131K è già enorme e dà a OpenCode ampio spazio per file sorgente, output degli strumenti, log del terminale e conversazioni lunghe, senza sprecare ancora più memoria per un contesto che probabilmente non userò.

Le impostazioni importanti qui sono:

1. --fit on consente a llama.cpp di determinare automaticamente quanta parte del modello tenere sulla GPU.

2. --fit-target 4096 gli dice di lasciare circa 4GB di memoria GPU liberi, dando un po’ di margine al runtime invece di lavorare al limite della VRAM. llama.cpp supporta ufficialmente sia l’adattamento automatico sia un margine di memoria configurabile.

3. Le impostazioni di campionamento non sono casuali. Qwen consiglia temperature=1.0, top_p=0.95, top_k=20 e min_p=0.0 quando si usa il modello in thinking mode.

Anche dopo aver caricato l’intero modello, mi è rimasta molta memoria, con circa 13GB di VRAM disponibili per finestra di contesto, KV cache e altre applicazioni.

Testare il server Qwen3.8-Flash-Next con CURL

llama-server espone un’API compatibile con OpenAI.

Controlla il modello disponibile:

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

Dovresti vedere qwen3.8-flash-next.

Ora testiamo la generazione di una risposta:

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

Se ottieni una risposta valida, il server locale è pronto.

Nel mio setup, inizialmente ho visto circa 80 token al secondo, il che mi ha sorpreso, dato che parte del modello era in RAM di sistema.

Con l’aumentare del contesto, la velocità è scesa a circa 64 token al secondo.

È comunque estremamente usabile per un modello di queste dimensioni, e l’architettura aiuta a capirne il motivo. Anche se il modello ha 125B parametri principali, solo circa 6B sono attivi per token.

Testare Qwen3.8-Flash-Next con la WebUI di llama.cpp

Una cosa che apprezzo molto di llama.cpp è che llama-server ti offre già una semplice WebUI.

Apri http://localhost:8080. Se tutto funziona correttamente, il modello dovrebbe essere già disponibile.

Per il mio primo test vero e proprio, gli ho chiesto di creare in un colpo solo un sito web completo per il dipartimento IT di un governo:

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, 

È stata una generazione piuttosto grande. Il modello ha passato molti token a ragionare, poi ha generato un intero sito in un singolo file HTML. Ci sono voluti circa 13 minuti per terminare e la velocità di generazione è calata gradualmente man mano che cresceva il contesto.

Ma il risultato è stato molto migliore del previsto.

Ha incluso grafici, animazioni, tab, sezioni diverse, styling responsive, interazioni JavaScript e un layout complessivamente sorprendentemente rifinito.

La parte interessante è che è stata praticamente una generazione one-shot. Non gli ho chiesto esplicitamente di aggiungere molti di quei dettagli minori.

È stato il primo momento in cui ho capito che questo modello potrebbe essere particolarmente valido per i compiti di coding in cui gli dai un po’ di libertà anziché specificare ogni singolo dettaglio di implementazione.

Collegare Qwen3.8-Flash-Next a OpenCode

Chattare è carino, ma volevo soprattutto testare Qwen3.8-Flash-Next come modello agentico per il coding.

Per questo ho usato OpenCode. Installalo per prima cosa:

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

Riavvia il terminale e verifica l’installazione:

opencode --version

Nel mio caso, la versione era 1.18.23.

Ora crea la configurazione di OpenCode:

mkdir -p ~/.config/opencode

Aggiungi il provider locale llama.cpp che abbiamo costruito prima:

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

La parte più importante è http://127.0.0.1:8080/v1. 

OpenCode supporta provider personalizzati compatibili con OpenAI tramite @ai-sdk/openai-compatible, il che rende molto semplice collegare llama.cpp.

Ho impostato in OpenCode un contesto di lavoro da 65K anche se il server llama.cpp ha 131K disponibili.

Questo lascia ampio margine per output lunghi e impedisce alle sessioni dell’agente di riempire troppo aggressivamente l’intero contesto del server.

Usare Qwen3.8-Flash-Next come agente di coding locale

Spostati in una directory di progetto e avvia OpenCode:

cd /workspace/my-project
opencode

Ora puoi assegnare al modello normali task agentici di coding. Ad esempio, ho chiesto a Qwen di creare una dashboard di analytics:

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.

Il modello ha iniziato creando una to-do list e pianificando l’applicazione prima di scrivere tutto.

Nel giro di pochi minuti ha prodotto la prima dashboard funzionante. La prima UI non mi è piaciuta molto: sembrava troppo dispersiva e c’erano diversi problemi di usabilità.

Quindi ho semplicemente detto all’agente cosa non mi piaceva e gli ho chiesto di ricostruire l’interfaccia in un command center di sistema più compatto.

La seconda versione era molto migliore.

Alla fine ho ottenuto una dashboard compatta dove potevo monitorare in tempo reale CPU, RAM, VRAM, uso della GPU, storage, attività di rete e processi in esecuzione. Ha aggiunto anche controlli per svuotare le cache, pulire i file temporanei e gestire i processi.

La cosa interessante è come Qwen ha affrontato l’implementazione. L’ho testato su due applicazioni diverse e spesso ha preferito semplice HTML, CSS e JavaScript vanilla invece di installare subito React, pacchetti Node o un altro framework pesante.

Questo comportamento in realtà mi è piaciuto. Se non specificavo un framework, cercava l’architettura più semplice per risolvere il problema invece di aggiungere dipendenze non necessarie.

Lo svantaggio è che si prende il suo tempo. C’è molto ragionamento, tanti token generati e a volte parecchio debugging. Si avverte chiaramente il modello che spende token per ragionare sul problema.

Ma i progetti finali in generale sono sembrati molto più completi rispetto a quanto ottengo di solito con modelli locali più piccoli.

Considerazioni finali

Dopo aver testato Qwen3.8-Flash-Next per la generazione di siti web e il coding agentico, penso che sia un chiaro passo avanti rispetto a Qwen3.8-27B. La differenza più grande è come affronta i progetti. Presta più attenzione a struttura, dettagli e implementazione pratica invece di limitarsi a generare codice. Se ti interessa eseguire questo modello in locale, leggi il nostro tutorial su Qwen3.8-27B.

Mi è piaciuto anche che spesso si affidasse a semplice HTML, CSS, JavaScript e Python invece di aggiungere framework e dipendenze inutili.

Lo svantaggio principale è la dimensione. L’UD-Q4_K_XL GGUF è intorno ai 111GB e il modello può usare molti token di ragionamento e di output, soprattutto durante il debugging.

A parte questo, il setup è stato sorprendentemente lineare. Se hai abbastanza RAM e VRAM, Qwen3.8-Flash-Next è uno dei modelli di coding locali più forti che abbia testato finora.