Déployer des modèles MoE : guide pratique pour le self-hosting
Qwen3.5-9B tient dans 5,3 Go de VRAM. Son homologue MoE, Qwen3.5-35B-A3B, en nécessite 18,5 Go — et pourtant, il n’active que 3 milliards de paramètres par token. Comment est-ce possible ?
Les modèles Mixture-of-Experts déroutent les déployeurs parce que le nombre de « paramètres actifs » est trompeur pour la planification matérielle. Vous voyez « 3B actifs » et vous pensez qu’un GPU de 8 Go suffira. Puis le modèle refuse de se charger.
Ce guide explique le calcul de VRAM, passe en revue chaque modèle MoE auto-hébergeable aujourd’hui et montre comment les faire tourner sur du matériel réaliste. Nous utiliserons la famille Qwen 3.5 comme exemple fil rouge car c’est la comparaison la plus parlante : même génération, mêmes données d’entraînement, mêmes capacités — seule l’architecture diffère.
En bref : Les modèles Mixture-of-Experts comme DeepSeek V3.1 (685B total, 37B actifs) et Qwen3.5-35B-A3B (36B total, 3B actifs) acheminent chaque token à travers une fraction de leurs experts — mais les poids de chaque expert doivent rester en mémoire. Qwen3.5-9B (dense) tient dans 5,29 Go en Q4_K_M ; son homologue MoE nécessite 18,49 Go à la même quantification malgré moins de paramètres actifs (Unsloth GGUF, 2026). En dessous de Q4_K_M, la qualité du routage se dégrade — n’allez pas plus bas.
Que signifie « Mixture of Experts » pour le déploiement ?
Depuis début 2025, la quasi-totalité des grands modèles d’IA de pointe utilisent des architectures MoE (NVIDIA Blog, 2025). Dans un modèle dense, chaque paramètre participe au traitement de chaque token. Dans un modèle MoE, un réseau routeur sélectionne un sous-ensemble d’« experts » par token — mais tous les experts doivent être chargés en mémoire. Ce seul fait explique presque toutes les surprises que vous rencontrerez au déploiement.
Imaginez ceci. Un modèle dense est un chef unique qui utilise chaque ingrédient de la cuisine pour chaque plat. Un modèle MoE est un restaurant avec 256 chefs, chacun spécialiste, mais vous devez quand même louer tout le bâtiment alors que seuls 8 chefs cuisinent à un instant donné.
Qwen 3.5 : la comparaison idéale
La famille Qwen 3.5 nous offre la comparaison la plus nette possible. Les deux variantes partagent les mêmes données d’entraînement, les mêmes capacités (code, multilingue, raisonnement, appels d’outils, vision) et la même fenêtre de contexte de 262K. La seule différence est l’architecture :
- Qwen3.5-9B — dense, 9,65 milliards de paramètres. Chaque paramètre s’active pour chaque token.
- Qwen3.5-35B-A3B — MoE, 35,95 milliards de paramètres au total, 256 experts, 8 actifs + 1 partagé par token. Environ 3 milliards de paramètres s’activent par token.
Même famille. Même génération. Des profils de déploiement radicalement différents. Voilà ce que MoE fait à votre infrastructure.
Remarquez la tendance. À mesure que les modèles MoE grossissent, l’écart entre paramètres totaux et actifs se creuse de façon spectaculaire. Kimi K2.5 dépasse le billion de paramètres mais n’en active que 32 milliards par token — 3,1 % du total. Votre GPU se moque de ce ratio. Il doit tous les contenir.
Besoins en VRAM — Pourquoi les modèles MoE exigent plus que prévu
Qwen3.5-35B-A3B nécessite 3,5× plus de VRAM que Qwen3.5-9B en Q4_K_M malgré moins de paramètres actifs par token (Unsloth GGUF, Unsloth GGUF, 2026). La raison est simple : la VRAM pour les poids du modèle est proportionnelle aux paramètres totaux, pas aux paramètres actifs. Seul le KV cache est proportionnel aux paramètres actifs.
La formule
Pour tout modèle GGUF quantifié, la VRAM se décompose en deux parties :
- Poids du modèle = total_params × bits_par_poids / 8. Tous les experts inclus.
- KV cache = proportionnel aux paramètres actifs × longueur de contexte × taille du batch.
Dans un modèle dense, paramètres totaux = paramètres actifs, donc la distinction n’a pas d’importance. En MoE, elle est considérable. Voici ce que cela donne avec les chiffres réels de nos données de modèles :
| Modèle | Architecture | Paramètres totaux | Paramètres actifs | Taille Q4_K_M |
|---|---|---|---|---|
| Qwen3.5-9B | Dense | 9,65B | 9,65B | 5,29 Go |
| Qwen3.5-35B-A3B | MoE (256 experts) | 35,95B | ~3B | 18,49 Go |
| DeepSeek V3.1 | MoE (256 experts) | 684,53B | ~37B | 377,56 Go |
Notre constat : Lorsque nous avons créé les pages de déploiement de Prositronic, les modèles MoE nécessitaient des calculs de VRAM et des avertissements entièrement différents. Un modèle avec 3B de paramètres actifs pourrait laisser croire qu’il tourne sur un Raspberry Pi — jusqu’à ce que vous réalisiez que les 36 milliards de poids doivent tous tenir en mémoire. Nous avons dû ajouter un avis dédié
MOE_EXPERT_CPU_OFFLOADsur chaque page de déploiement MoE.
La fine bande verte dans la barre MoE est révélatrice. Si vous pouviez ne charger que les 3B de paramètres actifs, il vous faudrait environ 1,6 Go. Au lieu de cela, il faut 18,49 Go parce que les 256 experts — 35,95 milliards de paramètres — doivent tous résider en mémoire pour que le routeur puisse y piocher.
Pour les modèles MoE plus grands, les configurations multi-GPU deviennent incontournables. DeepSeek V3.1 en Q4_K_M pèse 377,56 Go. Kimi K2.5 dépasse 500 Go. Aucun GPU grand public ne s’en approche. Est-ce que cela signifie qu’il est impossible de les faire tourner ? Pas tout à fait — c’est là que le déchargement d’experts entre en jeu (nous y reviendrons dans une section ultérieure).
Vos modèles MoE — Comparatif de déploiement
Les configurations à un seul expert actif offrent un débit 50 à 80 % supérieur à celles à 8 experts actifs (Chitty-Venkata et al., 2025). Six familles de modèles MoE sont disponibles pour le déploiement auto-hébergé aujourd’hui, de 36B à plus d’un billion de paramètres totaux. Voici leur comparatif :
| Modèle | Total | Actifs | Experts (utilisés/total) | Taille Q4 | VRAM min. |
|---|---|---|---|---|---|
| Qwen3.5-35B-A3B | 35,95B | ~3B | 8+1 / 256 | 18,49 Go | 24 Go |
| Qwen3-235B-A22B | 235B | ~22B | 8 / 64 | ~130 Go | Multi-GPU |
| DeepSeek V3.1 | 684,53B | ~37B | 8+1 / 256 | 377,56 Go | Multi-GPU |
| Kimi K2.5 | 1 016B | ~32B | 8 / 384 | ~550 Go | Multi-GPU |
| Llama 4 Scout | ~109B | ~17B | 1 / 16 | ~60 Go | 2× 48 Go |
| Llama 4 Maverick | ~400B | ~17B | 1 / 128 | ~220 Go | Multi-GPU |
Routage fin vs routage grossier
Notez la différence architecturale. DeepSeek V3.1 et Qwen3.5-35B-A3B utilisent 256 petits experts (routage fin) — chaque expert est un spécialiste étroit. Llama 4 Scout n’utilise que 16 gros experts (routage grossier) — chaque expert est un généraliste qui traite un éventail plus large de tokens. Qu’est-ce que cela implique pour vous ?
Les modèles à routage fin peuvent allouer le calcul avec plus de précision. Mais ils nécessitent davantage de gestion mémoire et leur routage est plus sensible à la quantification. Les modèles à routage grossier sont plus simples à déployer mais moins flexibles. Llama 4 Scout n’active qu’un seul expert par token (pas 8), ce qui rend ses accès mémoire plus prévisibles mais limite la spécialisation.
Impact de la quantification sur les modèles MoE
FP8 atteint un débit 25 à 30 % supérieur à FP16 aux tailles de batch les plus élevées sur GPU H100 (Chitty-Venkata et al., 2025). Mais ne vous laissez pas tenter par une quantification extrême. Les modèles MoE sont plus sensibles à la quantification agressive que les modèles denses car les poids du routeur doivent rester en haute précision pour sélectionner correctement les experts.
Le routeur est le cerveau d’un modèle MoE. Il examine chaque token et décide quels experts doivent le traiter. Lorsque vous quantifiez un modèle dense en Q2, chaque paramètre se dégrade uniformément. Lorsque vous quantifiez un modèle MoE en Q2, le routeur commence à sélectionner les mauvais experts. Le résultat n’est pas une dégradation progressive de la qualité — c’est une chute brutale.
Les modèles MoE de pointe subissent une perte de précision non négligeable avec une quantification extrême sous 4 bits ; des chercheurs ont développé des méthodes comme MiLo (Mixture of Low-rank compensators) pour récupérer la précision, mais cela ajoute de la complexité (Huang et al., 2025). Pour un déploiement pratique, notre recommandation est simple : ne descendez pas en dessous de Q4_K_M.
MXFP4 : l’exception
Il existe une exception. Qwen3.5-35B-A3B propose un quant MXFP4_MOE à 20,11 Go qui applique une quantification MX 4 bits spécifiquement aux couches d’experts tout en conservant les couches d’attention et de routage en précision supérieure. Cette approche sélective préserve la qualité du routage tout en compressant le gros du modèle. Si votre matériel prend en charge MXFP4 (NVIDIA Blackwell et ultérieur), c’est une alternative solide à Q4_K_M.
Quantification dynamique : une approche plus intelligente
La stratégie de quantification dynamique d’Unsloth compresse sélectivement les couches d’experts MoE à des précisions inférieures tout en conservant les couches d’attention et de routage en précision supérieure. C’est pourquoi vous voyez le préfixe « UD » sur de nombreux noms de fichiers de quant — il signifie « Unsloth Dynamic ». L’approche exploite le fait que les experts contribuent inégalement à la qualité du modèle : les experts partagés et les couches de routage sont des cibles prioritaires à préserver, tandis que les experts rarement activés tolèrent davantage de compression.
Stratégies de déchargement d’experts
DeepSeek V3.1 dans son quant TQ1_0 tourne sur un seul GPU de 24 Go avec le déchargement MoE et 96 à 128 Go de RAM système, atteignant environ 1 à 2 tokens par seconde (benchmarks communautaires, 2025). Le déchargement d’experts est la technique clé pour faire tourner de grands modèles MoE sur du matériel limité. Il stocke les poids des experts inactifs dans la RAM système ou sur NVMe et les charge sur le GPU à la demande.
Déchargement CPU avec llama.cpp
L’approche la plus pratique pour les configurations à un seul GPU. Dans llama.cpp, vous pouvez décharger toutes les couches d’experts MoE sur le CPU tout en gardant les couches d’attention et de routage sur le GPU :
llama-server \
--model Qwen3.5-35B-A3B-UD-Q4_K_M.gguf \
-ot ".ffn_.*_exps.=CPU" \
--n-gpu-layers 999 \
--ctx-size 8192 \
--jinjaL’option -ot ".ffn_.*_exps.=CPU" indique à llama.cpp de placer toutes
les couches feed-forward d’experts sur le CPU tout en gardant le reste sur le GPU.
C’est plus efficace que d’utiliser --n-gpu-layers seul, qui décharge des blocs
transformer entiers au lieu de séparer spécifiquement les couches d’experts.
Multi-GPU : le tensor parallelism l’emporte
Le tensor parallelism atteint des gains de performance de 2× et plus de 1 à 4 GPU sur H100, surpassant à la fois le pipeline parallelism et l’expert parallelism (Chitty-Venkata et al., 2025). Si vous disposez de plusieurs GPU connectés via NVLink, le tensor parallelism (TP) répartit chaque couche entre les GPU. L’expert parallelism (EP) assigne différents experts à différents GPU. Le TP l’emporte car la bande passante NVLink est suffisamment élevée pour rendre le découpage de couches efficace, tandis que l’EP souffre d’un surcoût d’équilibrage de charge — certains experts reçoivent plus de trafic que d’autres.
Le décodage spéculatif masque la latence du déchargement
Une technique récente appelée SpecMoEOff combine le décodage spéculatif avec le déchargement d’experts, atteignant jusqu’à 2,5× d’amélioration du débit de décodage en générant des tokens brouillons pendant que les poids des experts sont transférés de la RAM au GPU. C’est encore expérimental mais cela laisse entrevoir un avenir où même des modèles MoE à un billion de paramètres tourneront sur du matériel de station de travail.
Caractéristiques de performance — À quoi s’attendre
La latence inter-token varie de près de 100 % entre les meilleurs et les pires modèles MoE (Chitty-Venkata et al., 2025). Les modèles denses ont une latence par token prévisible car chaque token suit le même chemin de calcul. Ce n’est pas le cas des modèles MoE — les décisions de routage créent de la variance. Si votre application nécessite des temps de réponse constants, c’est un facteur important.
Pics de latence liés aux experts « froids »
Lorsqu’un token est acheminé vers un expert rarement utilisé et que les poids de cet expert ont été évincés du cache GPU (ou n’ont jamais été chargés dans une configuration avec déchargement), vous obtenez un pic de latence. Le GPU est bloqué en attendant l’arrivée des poids de l’expert depuis la RAM. Ces pics sont imprévisibles — ils dépendent du contenu du prompt et des experts qu’il active.
Le débit varie selon le prompt
Certains prompts sollicitent le même petit ensemble d’experts de façon répétée. D’autres répartissent la charge sur de nombreux experts. Cela rend le débit des modèles MoE fondamentalement moins prévisible que celui des modèles denses. Les séquences courtes (128 tokens) atteignent un débit jusqu’à 30 % supérieur aux séquences de 2048 tokens dans les modèles MoE (Chitty-Venkata et al., 2025).
Le batching est aussi moins efficace. Dans un modèle dense, chaque token d’un batch suit le même chemin de calcul. Dans un modèle MoE, différents tokens du même batch sont acheminés vers différents experts, créant des schémas d’accès mémoire que les GPU gèrent moins efficacement.
Quand le dense l’emporte
Comparez tout cela avec Qwen3.5-9B. C’est un modèle dense. Chaque token suit le même chemin de calcul. La latence est prévisible. Le débit est constant. Pas de pics liés aux experts froids. Pas de surcoût de routage. Il n’égalera pas Qwen3.5-35B-A3B sur les benchmarks, mais pour les applications sensibles à la latence — chat en temps réel, assistants de code interactifs, interfaces vocales — cette prévisibilité peut compter plus que la capacité brute. Vous pouvez déployer et comparer les deux sur Prositronic grâce à notre vérificateur de compatibilité matérielle.
Questions fréquentes
Pourquoi mon modèle MoE a-t-il besoin d’autant de VRAM si seuls quelques experts sont actifs ?
Tous les poids des experts doivent résider en mémoire pour un routage instantané. Qwen3.5-35B-A3B charge 35,95 milliards de paramètres mais n’en active qu’environ 3 milliards par token. Le routeur doit pouvoir sélectionner n’importe quel expert à tout moment, donc chaque expert reste chargé même si la plupart restent inactifs lors d’une passe avant donnée.
Peut-on faire tourner DeepSeek V3 sur un seul GPU ?
Oui, avec le déchargement d’experts. Le quant TQ1_0 tient sur un seul GPU de 24 Go avec 96 à 128 Go de RAM système, mais comptez environ 1 à 2 tokens par seconde (benchmarks communautaires, 2025). Pour des vitesses utilisables, il vous faudra au minimum deux GPU de 48 Go ou quatre GPU de 24 Go avec le quant Q4_K_M et le tensor parallelism.
Quelle est la quantification minimale à utiliser pour les modèles MoE ?
Q4_K_M. En dessous de ce seuil, la dégradation des poids du routeur provoque une sélection incorrecte des experts, réduisant la qualité de sortie bien plus nettement qu’une quantification équivalente sur des modèles denses. Les modèles MoE subissent une perte de précision non négligeable avec une quantification extrême sous 4 bits (Huang et al., 2025).
Un modèle MoE est-il toujours meilleur qu’un modèle dense de taille active similaire ?
Pas pour les applications sensibles à la latence. Qwen3.5-9B (dense) offre une latence par token prévisible sans surcoût de routage. Qwen3.5-35B-A3B (MoE) obtient de meilleurs scores aux benchmarks mais présente une latence variable due au routage des experts. Choisissez le dense quand vous avez besoin de temps de réponse constants ; choisissez le MoE quand vous voulez un maximum de capacité par euro de calcul investi.
Quelle est la différence entre MoE à routage fin et à routage grossier ?
DeepSeek V3 et Qwen3.5-35B-A3B utilisent 256 petits experts (routage fin). Llama 4 Scout utilise 16 experts plus gros (routage grossier). Le routage fin permet une spécialisation plus précise mais nécessite davantage de gestion mémoire. Les modèles à routage grossier sont plus simples à déployer mais moins flexibles dans leur allocation du calcul.
Prochaines étapes
Voici ce qu’il faut retenir :
- MoE ≠ moins de VRAM. Tous les poids des experts doivent être chargés, quel que soit le nombre d’experts actifs par token.
- Ne descendez pas en dessous de Q4_K_M pour les modèles MoE. La qualité du routeur se dégrade nettement sous une quantification de 4 bits.
- Le déchargement d’experts est indispensable pour les configurations à un seul GPU. Utilisez
-ot ".ffn_.*_exps.=CPU"dans llama.cpp. - Les modèles denses l’emportent en prévisibilité de latence. Choisissez en fonction de la tolérance de votre application à la variance.
- Le tensor parallelism surpasse l’expert parallelism pour les déploiements multi-GPU, surtout avec NVLink.
Déployez Qwen3.5-9B et Qwen3.5-35B-A3B sur Prositronic pour constater les différences par vous-même. Commencez par la page de déploiement de Qwen3.5-9B et la page de déploiement de Qwen3.5-35B-A3B, puis consultez la page de compatibilité matérielle pour trouver le GPU adapté à votre charge de travail.