Dense ou MoE ? Pourquoi Qwen3.6-35B-A3B bat le 27B dense sur Strix Halo

Chez SoberCloud, une partie de nos tests d’inférence tourne sur une machine un peu particulière : un AMD Ryzen AI MAX+ 395 « Strix Halo », 16 cœurs Zen 5, un iGPU Radeon 8060S (RDNA 3.5) et 128 Gio de mémoire unifiée (UMA) partagée entre le CPU et le GPU. Pas de carte graphique discrète, pas de VRAM dédiée : tout le monde tape dans la même RAM.

Cette architecture change complètement les règles du jeu pour choisir un modèle. La conclusion, après deux semaines de tests, tient en une phrase : sur ce matériel, un Mixture-of-Experts bat systématiquement un modèle dense de taille fichier comparable. Voici pourquoi.

Dense vs MoE : le rappel qui change tout

Un modèle dense active tous ses paramètres pour générer chaque token. Un Qwen3.6-27B dense, c’est 27 milliards de multiplications-additions à chaque token produit.

Un modèle MoE (Mixture-of-Experts) comme Qwen3.6-35B-A3B contient 35 milliards de paramètres au total, mais n’en active que 3 milliards par token (le « A3B » = Active 3B). Un routeur sélectionne dynamiquement un petit sous-ensemble d’« experts » à chaque étape.

Autrement dit : le MoE est plus gros sur le disque, mais beaucoup plus léger à calculer par token.

Pourquoi ça compte tant sur mémoire unifiée

Sur un GPU classique avec VRAM dédiée (type RTX 3090), l’inférence est souvent compute-bound : le facteur limitant, c’est la puissance de calcul brute.

Sur Strix Halo, c’est l’inverse. L’iGPU partage la bande passante mémoire avec le CPU, donc l’inférence est bandwidth-bound : le facteur limitant, c’est la vitesse à laquelle on peut faire transiter les poids du modèle depuis la RAM. Conséquence directe :

Plus le modèle est petit en octets effectivement lus par token, plus c’est rapide. Un MoE qui ne lit que 3B de poids actifs par token écrase un dense qui doit en relire 27B à chaque fois.

C’est exactement ce qu’on a mesuré. Le 23 mai, on a testé un Qwopus3.6-27B-v2 (dense 27B + MTP). Verdict sans appel : plus lent que le MoE 35B, alors qu’il est plus petit sur le disque. Tous ses paramètres sont actifs à chaque token → la bande passante UMA sature.

Le modèle qu’on a retenu

Après un balayage complet, notre choix de production est :

unsloth/Qwen3.6-35B-A3B-MTP-GGUF : UD-Q5_K_XL

• ~26 Go sur le disque (quantification 5 bits)
• 35B paramètres dont 3B actifs par token
• Servi par llama.cpp en backend Vulkan
• ~73 tokens/seconde en débit réel mono-utilisateur

Sur notre référence qualité interne (BenchLocal, qui note la qualité du tool-calling, de l’instruction-following et de l’extraction de données), ce modèle obtient un solide 100 / 80 / 91.

Le contre-exemple : quand le MoE ne rentre pas

Le MoE n’est pas magique non plus. Le 16 mai, on a voulu tester un MiniMax-M2.7 en IQ4_XS… qui pèse 110 Go. Sur 128 Gio d’UMA partagée avec le système, le KV cache et les activations, ça ne rentre tout simplement pas : OOM (out of memory) immédiat.

La leçon : un MoE est avantageux tant qu’il tient en mémoire. Le sweet spot sur 128 Gio d’UMA, c’est un MoE dont le fichier quantifié reste autour de 25-35 Go, ce qui laisse de la marge pour un contexte large.

Ce qu’on en retient

Critère	Dense (27B)	MoE (35B-A3B)
Paramètres totaux	27B	35B
Paramètres actifs / token	27B	3B
Taille fichier (Q5)	plus petite	~26 Go
Débit sur Strix Halo	plus lent	~73 t/s
Adapté UMA bandwidth-bound	non	oui

Sur un matériel sobre, à mémoire unifiée et limité par la bande passante, le MoE n’est pas un luxe : c’est le bon outil pour le bon contexte matériel. C’est précisément le genre d’arbitrage qui nous permet de servir des LLM open source performants sans empiler les GPU — et donc sans empiler les watts.

Cet article fait partie de notre carnet Découvertes, où l’on documente les choix techniques de notre infrastructure d’inférence souveraine. La suite : notre comparatif des logiciels d’inférence.