#Pourquoi Qwen3.6 35B-A3B en local

Trois raisons concrètes poussent à essayer ce modèle plutôt qu'un dense 32B classique. D'abord, la vitesse : seuls les 3B actifs sont impliqués dans le calcul de chaque token, donc l'inférence va beaucoup plus vite qu'un Qwen 32B dense à VRAM équivalente. Ensuite, la qualité : sur les benchmarks publics, le 35B-A3B se tient face à un dense 14B–24B en raisonnement, code et français.

Enfin, c'est l'un des rares modèles à offrir cet équilibre sous licence permissive utilisable en production. Si vous cherchez un assistant généraliste précis, qui réponde vite, et qui rentre sur une carte 24 Go, Qwen3.6 35B-A3B est aujourd'hui un des meilleurs candidats.

Le nom décodé

35B = 35 milliards de paramètres au total. A3B = 3 milliards "Actifs" par token. Le routeur MoE sélectionne dynamiquement quelques experts (sur ~64) à chaque passage, ce qui réduit le coût compute mais pas le coût mémoire.

#L'architecture MoE en une minute

Dans un modèle dense, chaque token traverse toutes les couches et tous les neurones. Dans un MoE, certaines couches feed-forward sont remplacées par un banc d'experts indépendants, et un petit réseau "routeur" décide pour chaque token quels experts activer (typiquement 2 à 8). Le reste dort.

Compute par token: Proportionnel aux paramètres actifs (3B). C'est pour ça que ça génère vite.
Mémoire (VRAM): Proportionnelle au total (35B). Tous les experts doivent être chargés, on ne sait jamais à l'avance lequel sera appelé.
Qualité: Entre un 3B dense et un 35B dense. Sur les tâches généralistes, en pratique, ça se rapproche d'un 14B–24B dense.
Sensibilité au batch: Sur un seul prompt à la fois, le MoE brille. En batch très large, l'avantage compute s'érode car on finit par activer tous les experts.

→

Pourquoi c'est intéressant pour le self-host

Sur une RTX 4090 24 Go, un Qwen 32B dense en Q4 plafonne souvent à 25–35 tok/s. Qwen3.6 35B-A3B dans la même VRAM tourne autour de 70–90 tok/s, avec un niveau de réponse comparable sur la plupart des tâches non-spécialisées.

#Prérequis matériel

VRAM minimale: 16 Go pour le tester (Q3, offload partiel CPU accepté). 20–24 Go pour un usage fluide Q4.
VRAM confortable: 32 Go (RTX 5090) ou 48 Go (mémoire unifiée Apple) pour Q5/Q6 et grand contexte.
RAM système: 32 Go minimum si vous tolérez de l'offload CPU. 64 Go si vous chargez en RAM seule.
Disque: Prévoir 22 Go pour Q4_K_M, 70 Go pour FP16. SSD NVMe fortement conseillé.
OS / runtime: Linux, macOS (Apple Silicon), Windows 11. Ollama ≥ 0.5.x ou llama.cpp récent (build post-mars 2026).

MoE ≠ petit modèle

Ne vous laissez pas tromper par le "3B actifs" : il faut quand même charger tout le modèle en VRAM. Une RTX 4060 8 Go ne suffit pas, même si l'inférence "ne calcule que 3B". Tous les experts doivent rester accessibles instantanément.

#VRAM réelle par quantification

Voici les empreintes mesurées sur llama.cpp avec un contexte de 8 k tokens (modèle + KV-cache + overhead). Les valeurs incluent le runtime, pas seulement le poids du GGUF sur disque.

Q2_K (≈ 13 Go): Possible sur RTX 4070 / 4060 Ti 16 Go. Perte de qualité notable surtout en code et raisonnement multi-étapes. À réserver au dépannage.
Q3_K_M (≈ 17 Go): Tient sur RX 7900 GRE / 4080 / 5070 Ti 16 Go avec un contexte modeste. Qualité encore raisonnable pour du chat généraliste FR.
Q4_K_M (≈ 22 Go): Le sweet spot. Confortable sur RTX 3090 / 4090 / 7900 XTX (24 Go) et RTX 5090 (32 Go). Recommandé par défaut.
Q5_K_M (≈ 26 Go): Demande 32 Go (RTX 5090) ou Mac M-series 36 Go+. Gain de qualité modeste sur Q4 sauf en code.
Q6_K (≈ 30 Go): Réservé aux RTX 5090, Mac Studio, ou config multi-GPU. Très peu de différence avec Q8 en sortie utilisateur.
Q8_0 (≈ 37 Go): Mac Studio M2/M3/M4 Ultra, ou bi-GPU (2× 3090). Qualité quasi-FP16.
FP16 (≈ 70 Go): Recherche, fine-tuning, vLLM en production. Hors-jeu pour la majorité des setups locaux.

→

Quelle quantification choisir

Pour 95 % des usages, Q4_K_M est le bon défaut : il préserve l'essentiel de la qualité, économise la VRAM, et accélère le débit. Ne montez à Q5/Q6 que si vous avez explicitement constaté des régressions sur vos prompts.

#Installation avec Ollama

Ollama reste la voie la plus courte. Si vous ne l'avez pas encore, installez-le (voir le guide d'installation correspondant à votre OS). Une fois le daemon en route sur le port 11434, une seule commande suffit.

Télécharger et lancer

ollama run qwen3.6:35b-a3b-q4_K_M

Le téléchargement pèse environ 21 Go. Au premier prompt, le modèle est chargé en VRAM ; les démarrages suivants sont quasi-instantanés tant que le modèle reste actif en mémoire.

Vérifier le placement GPU

ollama ps

La colonne PROCESSOR doit afficher 100% GPU. Si vous voyez un mix CPU/GPU, c'est que la VRAM est insuffisante : passez à une quantization plus agressive (Q3_K_M), réduisez num_ctx, ou acceptez la perte de débit.

Étendre le contexte

Par défaut, Ollama limite le contexte à 2048 tokens. Pour de la synthèse de docs ou des conversations longues, créez un Modelfile qui force num_ctx à 8192 ou 16384 — chaque doublement coûte quelques centaines de Mo de VRAM supplémentaires.

Modelfile minimal

# fichier : Modelfile.qwen36-long
FROM qwen3.6:35b-a3b-q4_K_M
PARAMETER num_ctx 16384
PARAMETER temperature 0.7

# build
# ollama create qwen36-long -f Modelfile.qwen36-long

#Installation avec llama.cpp

Pour qui veut contrôler finement le placement des experts, le batch ou le KV-cache, llama.cpp est plus souple. On télécharge un GGUF Q4_K_M depuis Hugging Face (modèles publiés par l'équipe Qwen ou par bartowski/unsloth), puis on lance le serveur OpenAI-compatible.

Serveur llama.cpp

./llama-server \
  -m ./models/Qwen3.6-35B-A3B-Q4_K_M.gguf \
  --host 0.0.0.0 --port 8080 \
  -c 16384 \
  -ngl 99 \
  --flash-attn \
  --threads 8

-ngl 99: Offload toutes les couches sur GPU. Mettre 0 pour CPU-only, ou une valeur partielle pour spliter.
-c 16384: Taille de contexte. Compte ~0.5 Go de KV-cache supplémentaire par tranche de 4 k au-delà du défaut.
--flash-attn: Active Flash Attention si votre build le supporte (CUDA, Metal). Gain mémoire net sur les contextes longs.
--threads 8: Sert surtout en CPU partiel. Sur GPU pur, peu d'impact.

→

MoE et expert offload

Les builds récents de llama.cpp acceptent --override-tensor pour placer certains experts en RAM. Sur une 4070 12 Go, ça permet de faire entrer Q4_K_M (au prix d'une partie du débit). Cherchez la doc "expert offload" si vous voulez creuser.

#Vitesse d'inférence mesurée

Mesures faites en Q4_K_M, contexte 4096, prompt court (~200 tokens), génération 512 tokens, batch 1. Les chiffres incluent la phase prompt eval et la génération.

RTX 5090 32 Go: ≈ 110–125 tok/s en génération. La phase prompt eval dépasse 4000 tok/s. Confortable jusqu'à 32 k de contexte.
RTX 4090 24 Go: ≈ 80–95 tok/s. Le modèle Q4 rentre avec 16 k de contexte sans déborder.
RTX 3090 24 Go: ≈ 55–70 tok/s. Excellent rapport perf/€ d'occasion, mais bande passante mémoire plus basse que la 4090.
Mac Studio M4 Ultra 64 Go: ≈ 60–75 tok/s en Q4_K_M, ≈ 45–55 tok/s en Q8_0. Idéal pour du serveur 24/7 silencieux.
Radeon RX 7900 XTX 24 Go (ROCm): ≈ 45–60 tok/s. Ollama supporté, llama.cpp avec ROCm/Vulkan.
RTX 4070 Ti Super 16 Go (Q3_K_M): ≈ 50–65 tok/s, contexte limité à 4 k. À ce niveau, un Qwen 14B dense reste souvent plus pertinent.

MoE et long contexte

Le débit reste élevé en génération, mais la phase prompt eval grimpe vite quand on injecte 16 k de contexte. C'est normal : tous les experts sont sollicités à un moment ou un autre pendant le passage du prompt. Pour du RAG, batchez vos requêtes.

#Optimisations utiles

01
Activer Flash Attention
Sur Ollama, c'est automatique sur GPU récent. Sur llama.cpp, ajouter --flash-attn. Gain notable en VRAM dès 8 k de contexte.
02
Quantifier le KV-cache
llama.cpp accepte --cache-type-k q8_0 --cache-type-v q8_0. Économise ~30 % de VRAM sur le cache, perte de qualité quasi-nulle.
03
Réduire le nombre d'experts actifs
Certaines variantes acceptent --override-kv qwen3moe.expert_used_count=2 (au lieu de 4 ou 8 par défaut). Plus rapide, légère perte de qualité.
04
Limiter num_ctx à ce dont vous avez besoin
16 k est largement assez pour la majorité des chats. 32 k+ ne se justifie que pour de la synthèse de longs documents.
05
Préférer un batch=1 pour le chat interactif
Le MoE perd de son avantage en batch large : si vous servez plusieurs utilisateurs simultanés, considérez vLLM plutôt qu'Ollama.

#Dépannage

OOM au chargement sur RTX 4090: Réduisez num_ctx à 4096 et vérifiez qu'aucun autre process GPU ne tourne (navigateur, jeu). Q4_K_M doit rentrer avec 2 à 3 Go de marge.
Génération à 5 tok/s sur RTX 4090: Le modèle déborde sur CPU. ollama ps affichera un mix CPU/GPU. Ferme tout, redémarre Ollama, ou descend à Q3_K_M.
Réponses incohérentes en français: Vérifiez que vous utilisez la variante Instruct et non Base. Le routage MoE est sensible à la formulation du system prompt — restez direct.
Premier token très lent (>10s): Phase prompt eval longue : c'est attendu pour un contexte large sur MoE. Réutilisez le cache de prompt entre requêtes (option --prompt-cache de llama.cpp).
Modèle introuvable sur Ollama: Le tag exact peut différer (qwen3.6 vs qwen3_6 vs qwen36). Cherchez sur ollama.com/library avant de taper la commande.

#Pour aller plus loin

Maintenant que Qwen3.6 35B-A3B tourne chez vous, quelques pistes pour pousser le setup :

Choisir sa quantification (Q4, Q5, Q8, FP16): Pour comprendre précisément ce qui se passe entre Q3, Q4 et Q5 sur un modèle MoE.
Open WebUI avec Ollama: Une interface ChatGPT-like avec historique et RAG, au-dessus de votre Qwen3.6 local.
Choisir son GPU pour l'IA locale: Si vous hésitez entre 3090 d'occasion, 4090, ou 5090 pour ce type de modèle MoE 30B+.

Ce guide vous a aidé ?

Un retour, une erreur, une précision ? Faites-nous signe, ça améliore le guide pour tout le monde.

Suite logique

Premiers pas · 9 min

Qwen3.6 35B-A3B en local : test et besoins VRAM