Comment exécuter Qwen3.8-Flash-Next en local comme agent de code avec OpenCode

Architecture de Qwen3.8-Flash-Next

C’est un modèle MoE principal de 125 milliards de paramètres, mais seulement ~6 milliards sont activés par token. Il inclut également 51 milliards de paramètres additionnels sous forme d’embeddings n-gram.

L’architecture introduit plusieurs idées que Qwen explore pour Qwen4 :

• Gated DeltaNet + Qwen Sparse Attention (QSA) pour un traitement plus efficace des longs contextes
• Connexions résiduelles à portes pour améliorer la circulation de l’information entre les couches
• Embeddings n-gram qui ajoutent de la capacité sans exiger le calcul actif de tous ces paramètres

Source : Qwen 

Le modèle dispose d’une fenêtre de contexte native de 262 144 tokens, extensible théoriquement à 1 million de tokens via YaRN.

Comment Qwen3.8-Flash-Next se débrouille-t-il en code ?

Il est étonnamment performant en programmation. Voici quelques résultats rapportés par Qwen, comparés à Qwen3.8-27B :

Ces évaluations proviennent de Qwen lui-même ; à considérer comme des résultats fournis par l’éditeur. Elles concordent néanmoins assez bien avec mon expérience en usage réel pour le code.

Préparer le serveur GPU pour Qwen3.8-Flash-Next

J’ai utilisé une RTX PRO 6000 avec 96 Go de VRAM, mais vous n’avez pas forcément besoin d’autant de VRAM.

C’est l’un des aspects intéressants de Qwen3.8-Flash-Next : comme llama.cpp peut décharger une partie du modèle vers la RAM système, vous pouvez utiliser un GPU avec moins de VRAM, à condition d’avoir beaucoup de RAM disponible.

La quantification Unsloth UD-Q4_K_XL que nous utilisons pèse environ 111 Go et est répartie sur quatre fichiers GGUF.

Dans ma configuration, je recommande d’avoir au moins 140 Go de RAM + VRAM utilisables pour laisser la place au modèle, au contexte, au KV cache et aux surcoûts d’exécution.

Avec une carte comme la H200, vous pourriez quasiment tout garder sur le GPU. J’ai opté pour un compromis.

Commencez par vérifier votre GPU :

nvidia-smi

Vous devriez voir votre GPU, la version du pilote, la version de CUDA et la VRAM disponible.

Ensuite, installez les paquets requis :

sudo apt update

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

Compiler llama.cpp avec la prise en charge de Qwen3.8-Flash-Next

Qwen3.8-Flash-Next utilise la nouvelle architecture qwen4_exp, très différente d’un simple chargement d’un autre modèle Qwen3.8.

Le support étant encore tout récent, j’ai utilisé la branche Qwen3.8-Flash-Next maintenue par Unsloth plutôt que de m’appuyer sur une ancienne build de llama.cpp qui pourrait ne pas reconnaître l’architecture. Le travail correspondant dans llama.cpp ajoute la nouvelle architecture qwen4exp, QSA, les embeddings n-gram, et d’autres composants spécifiques au modèle.

Allez dans l’espace de travail :

cd /workspace

Clonez la branche Unsloth :

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

Entrez dans le dossier :

cd llama.cpp

Compilez llama.cpp avec CUDA :

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

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

Enfin, vérifiez que llama-server a bien été compilé :

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

Ma build a renvoyé :

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

Télécharger le modèle GGUF Qwen3.8-Flash-Next

Le téléchargement du modèle a été l’une des parties les plus pénibles de cette installation.

J’ai d’abord essayé ModelScope, mais le débit n’était pas bon. Sur Hugging Face, le téléchargement a démarré à une vitesse correcte avant de tomber soudainement à quelques Ko/s.

Hugging Face utilise désormais son backend Xet pour les gros téléchargements de modèles et active normalement la concurrence adaptative automatiquement. Il propose aussi HF_HUB_DISABLE_XET pour désactiver Xet lorsqu’il pose problème.

Dans mon cas, désactiver Xet et télécharger en parallèle les quatre shards GGUF a beaucoup mieux fonctionné.

Installez la CLI Hugging Face :

pip install -U huggingface_hub

Désactivez Xet pour ce téléchargement :

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 est de toute façon déprécié, car Hugging Face a basculé les gros transferts sur Xet.

Créez le répertoire du modèle :

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

Téléchargez maintenant les quatre shards en parallèle :

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 quantification UD-Q4_K_XL complète pèse environ 111 Go.

Exécuter Qwen3.8-Flash-Next avec llama.cpp

Revenez au dossier llama.cpp :

cd /workspace/llama.cpp

Démarrez le serveur :

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

J’ai volontairement utilisé une fenêtre de contexte de 131 072 tokens plutôt que les 262K natifs complets.

Pour des agents de code, 131K est déjà immense et offre à OpenCode largement assez de place pour les fichiers sources, les sorties d’outils, les journaux de terminal et de longues conversations, sans gaspiller encore plus de mémoire pour un contexte que je n’utiliserai probablement pas.

Les paramètres clés ici sont :

1. --fit on permet à llama.cpp de déterminer automatiquement quelle part du modèle conserver sur le GPU.

2. --fit-target 4096 lui indique de laisser environ 4 Go de mémoire GPU libres, afin de donner un peu d’air au runtime au lieu de taper dans la limite de VRAM. llama.cpp prend officiellement en charge l’ajustement automatique et une marge mémoire cible configurable.

3. Les réglages d’échantillonnage ne sont pas choisis au hasard. Qwen recommande temperature=1.0, top_p=0.95, top_k=20 et min_p=0.0 en mode reasoning.

Même après le chargement complet du modèle, il me restait encore une bonne marge, avec environ 13 Go de VRAM disponibles pour la fenêtre de contexte, le KV cache et d’autres applications.

Tester le serveur Qwen3.8-Flash-Next avec CURL

llama-server expose une API compatible OpenAI.

Vérifiez le modèle disponible :

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

Vous devriez voir qwen3.8-flash-next.

Testons maintenant une génération :

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

Si vous obtenez une réponse valide, le serveur local est prêt.

Sur ma configuration, j’ai d’abord observé ~80 tokens/s, ce qui m’a surpris sachant qu’une partie du modèle résidait en RAM système.

Avec l’augmentation du contexte, la vitesse est plutôt descendue vers 64 tokens/s.

Cela reste très exploitable pour un modèle de cette taille, et l’architecture l’explique en partie : malgré 125 Md de paramètres principaux, seuls ~6 Md sont actifs par token.

Tester Qwen3.8-Flash-Next avec la WebUI de llama.cpp

Ce que j’apprécie avec llama.cpp, c’est que llama-server fournit déjà une WebUI simple.

Ouvrez http://localhost:8080. Si tout fonctionne, le modèle doit être disponible.

Pour mon premier vrai test, je lui ai demandé de créer d’un bloc le site d’un service informatique gouvernemental :

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, 

La génération était conséquente. Le modèle a d’abord « réfléchi » un grand nombre de tokens, puis a produit un site complet dans un seul fichier HTML. Environ 13 minutes pour terminer, avec une vitesse qui a diminué au fil de l’extension du contexte.

Le résultat a dépassé mes attentes.

On y trouvait des graphiques, des animations, des onglets, différentes sections, un design responsive, des interactions JavaScript et une mise en page étonnamment soignée.

Ce qui est intéressant, c’est que c’était quasiment une génération one-shot. Je ne lui avais pas explicitement demandé nombre de ces petits détails.

C’est là que j’ai compris que ce modèle pouvait être particulièrement bon pour des tâches de codage où on lui laisse de la latitude, au lieu de spécifier chaque détail d’implémentation.

Connecter Qwen3.8-Flash-Next à OpenCode

Discuter, c’est bien, mais je voulais surtout tester Qwen3.8-Flash-Next comme modèle agentique pour le code.

Pour cela, j’ai utilisé OpenCode. Installez-le d’abord :

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

Redémarrez votre terminal et vérifiez l’installation :

opencode --version

Chez moi, c’était la version 1.18.23.

Créez maintenant la configuration OpenCode :

mkdir -p ~/.config/opencode

Ajoutez le provider local llama.cpp que nous avons construit :

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 partie la plus importante est http://127.0.0.1:8080/v1. 

OpenCode prend en charge les providers personnalisés compatibles OpenAI via @ai-sdk/openai-compatible, ce qui facilite grandement la connexion de llama.cpp.

J’ai fixé le contexte de travail d’OpenCode à 65K même si le serveur llama.cpp offre 131K.

Cela laisse une bonne marge pour de longues sorties et évite que les sessions d’agent ne saturent trop agressivement le contexte du serveur.

Utiliser Qwen3.8-Flash-Next comme agent de code local

Accédez à un dossier de projet et lancez OpenCode :

cd /workspace/my-project
opencode

Vous pouvez désormais confier au modèle des tâches agentiques classiques. Par exemple, je lui ai demandé de créer un tableau de bord d’analytique :

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.

Le modèle a commencé par lister les tâches et planifier l’application avant d’écrire le code.

En quelques minutes, il a produit un premier tableau de bord fonctionnel. Je n’ai pas apprécié la première interface : trop espacée, avec plusieurs problèmes d’ergonomie.

Je lui ai simplement indiqué ce qui n’allait pas et demandé de reconstruire l’interface en un centre de commande plus compact.

La deuxième version était bien meilleure.

J’ai obtenu un tableau de bord compact pour suivre en temps réel CPU, RAM, VRAM, GPU, stockage, activité réseau et processus en cours. Il a aussi ajouté des contrôles pour vider les caches, nettoyer les fichiers temporaires et gérer les processus.

Ce qui m’a frappé, c’est l’approche d’implémentation. Testé sur deux applications différentes, Qwen a souvent privilégié un simple HTML, CSS et JavaScript « vanilla » plutôt que d’installer directement React, des paquets Node ou un autre framework lourd.

J’ai apprécié ce comportement : si je ne spécifiais pas de framework, il cherchait l’architecture la plus simple pour résoudre le problème, sans ajouter de dépendances inutiles.

L’inconvénient, c’est le temps : beaucoup de raisonnement, beaucoup de tokens générés, et parfois pas mal de débogage. On sent le modèle « penser » le problème en consommant des tokens.

Mais les projets finaux paraissaient généralement plus complets que ce que j’obtiens avec de plus petits modèles locaux.

Conclusion

Après avoir testé Qwen3.8-Flash-Next pour la génération de sites web et le codage agentique, je le considère comme un net progrès par rapport à Qwen3.8-27B. La principale différence est son approche des projets : il accorde plus d’attention à la structure, aux détails et à l’implémentation concrète, au-delà de la simple génération de code. Si vous souhaitez exécuter ce modèle en local, consultez notre tutoriel Qwen3.8-27B.

J’ai aussi apprécié qu’il s’appuie souvent sur du HTML, CSS, JavaScript et Python simples, sans ajouter de frameworks et dépendances superflus.

Le principal inconvénient reste la taille. Le GGUF UD-Q4_K_XL pèse ~111 Go, et le modèle peut générer beaucoup de tokens de raisonnement et de sortie, surtout en phase de débogage.

À part cela, la mise en place s’est révélée étonnamment simple. Si vous avez suffisamment de RAM et de VRAM, Qwen3.8-Flash-Next est l’un des meilleurs modèles locaux pour le code que j’ai testés à ce jour.