Le Mixture of Experts expliqué : paramètres actifs, mémoire GPU et inférence MoE

DeepSeek-R1 possède 671 milliards de paramètres au total et en active environ 37 milliards pour chaque jeton.

S'agit-il donc d'un modèle de 671B ou de 37B ?

Pour le stockage et une grande partie des enjeux de déploiement, le chiffre de 671B est celui qui compte.

Pour ce qui est de la part du réseau participant au traitement d'un jeton individuel, c'est le chiffre de 37B qui compte.

Ces deux nombres décrivent le même modèle. Ils répondent à des questions différentes. DeepSeek publie ces deux chiffres pour R1 et V3, qui partagent la même architecture sous-jacente de « Mixture-of-Experts ».

Cette distinction est l'idée centrale derrière un mélange d'experts, ou MoE.

Un modèle MoE contient de nombreux sous-réseaux paramétrés appelés experts. Un système de routage appris détermine quels experts doivent traiter chaque jeton. Seul un sous-ensemble est activé, ce qui permet au modèle de posséder un nombre total de paramètres bien supérieur à celui utilisé lors de la passe avant pour un seul jeton.

Cela se résume parfois par « plus de paramètres pour une même puissance de calcul ».

Un raccourci utile, mais incomplet.

Ces poids d'experts inactifs n'ont pas disparu. Ils nécessitent toujours un espace de stockage. Si vous souhaitez une inférence rapide résidant sur GPU, ils doivent généralement être répartis quelque part dans le système GPU.

C'est pourquoi le MoE modifie la relation entre la capacité du modèle, le calcul, la mémoire et la communication plutôt que de simplement vous offrir un modèle géant au coût d'un petit.

Qu'est-ce qu'un mélange d'experts (Mixture of Experts) ?

Un transformeur dense conventionnel envoie chaque jeton à travers le même réseau à propagation avant (feed-forward) au sein de chaque bloc de transformeur.

Conceptuellement :

Jeton
 ↓
Attention
 ↓
Réseau à propagation avant
 ↓
Couche suivante

Un transformeur à mélange d'experts clairsemé remplace certaines de ces opérations denses à propagation avant par une collection de réseaux experts.

Conceptuellement :

                 ┌→ Expert 1 ─┐
                 │            │
Jeton → Routeur ───┼→ Expert 2 ─┼→ combinaison → couche suivante
                 │            │
                 ├→ Expert 3 ─┤
                 │            │
                 └→ Expert 4 ─┘

Le routeur évalue les experts pour le jeton actuel.

Il peut sélectionner :

Expert 2
+
Expert 4

tandis qu'un autre jeton dans la même phrase pourrait être envoyé à :

Expert 1
+
Expert 3

Les experts appartiennent à un seul modèle. Il ne s'agit pas de chatbots indépendants votant pour une réponse.

Ce sont des blocs de paramètres spécialisés au sein du réseau.

Les architectures à experts clairsemés reposent sur ce principe fondamental : différentes entrées activent différents sous-ensembles des paramètres disponibles du modèle. Les travaux sur le Switch Transformer ont démontré comment le routage clairsemé permet d'augmenter considérablement le nombre de paramètres d'un modèle sans accroître proportionnellement le calcul par exemple.

Le routeur décide quels experts sont activés

Le routeur, parfois appelé réseau de routage, est placé devant les experts.

Pour chaque jeton, il calcule des scores déterminant quels experts doivent recevoir ce jeton.

Imaginons huit experts :

E1  E2  E3  E4  E5  E6  E7  E8

Le routeur pourrait produire :

0,02
0,05
0,61
0,03
0,18
0,04
0,05
0,02

Si le modèle utilise un routage « top-2 », le jeton est principalement envoyé à :

E3
+
E5

Le jeton suivant peut générer des scores de routage totalement différents.

C'est un point important.

Les experts ne sont généralement pas assignés de manière permanente à des catégories évidentes telles que :

Expert 1 = Français
Expert 2 = Python
Expert 3 = mathématiques

Une certaine spécialisation peut apparaître, mais le routeur apprend sa propre organisation interne pendant l'entraînement.

Mixtral nous en donne un exemple clair

Le modèle Mixtral 8x7B de Mistral est l'une des architectures MoE les plus simples à comprendre.

Chaque couche MoE contient :

8 experts

et le routeur envoie chaque jeton vers :

2 experts

à ce niveau de la couche.

Le document sur Mixtral indique environ :

47 milliards de paramètres au total
13 milliards de paramètres actifs par jeton

bien que le modèle soit communément décrit comme un « 8x7B ».

Ainsi, un jeton n'utilise pas les huit experts.

Il en utilise deux.

À la couche suivante, le routeur prend une nouvelle décision.

Et un autre jeton peut suivre un chemin d'experts totalement différent.

C'est ce qu'on appelle l'activation creuse.

Les paramètres actifs et les paramètres totaux mesurent des choses différentes

Prenons l'exemple suivant :

Paramètres totaux = 47 Md
Paramètres actifs = 13 Md

Le premier indique le nombre de paramètres existant dans l'ensemble du modèle.

Le second indique approximativement combien d'entre eux participent au calcul pour un jeton.

Cela soulève deux questions d'infrastructure distinctes.

Les paramètres totaux aident à déterminer le stockage

Si le modèle contient 47 milliards de paramètres, ces poids doivent être stockés quelque part.

Une estimation simple du stockage en BF16 commence autour de :

47 Md × 2 octets
≈ 94 Go

avant de prendre en compte les métadonnées de point de contrôle et les autres composants du modèle.

Les paramètres actifs aident à décrire le calcul

Si environ 13 milliards de paramètres participent au traitement d'un jeton, le calcul par jeton est bien plus proche de ce chemin actif que de l'exécution d'un réseau dense de 47 milliards.

C'est là tout l'enjeu des modèles MoE.

une grande capacité de paramètres

sans

activer chaque paramètre
pour chaque jeton

Pourquoi les « paramètres actifs » ne reflètent pas les besoins en VRAM

C'est là que les conseils matériels sur les MoE font souvent fausse route.

Prenons l'exemple de DeepSeek-R1 :

671 milliards de paramètres au total
37 milliards de paramètres actifs

Certains voient 37B et se disent :

37B × 0,5 octet
≈ 18,5 Go en 4 bits

et en concluent :

DeepSeek-R1 devrait tenir sur un GPU de 24 Go.

Cela ne fonctionne pas comme ça.

Les autres experts contiennent toujours des poids.

DeepSeek-R1 utilise l'architecture DeepSeek-V3, et DeepSeek indique explicitement 671 milliards de paramètres au total, dont 37 milliards activés pour chaque jeton.

Un calcul de stockage approximatif pour le modèle complet de 671B donne :

Il ne s'agit là que d'approximations basées uniquement sur les poids.

‍

‍

Mais ils montrent immédiatement pourquoi :

37B actifs

ne signifie pas :

les exigences matérielles d'un modèle dense de 37B

Notre guide sur la taille et la mémoire du modèle DeepSeek-R1 aborde ce problème de déploiement plus en détail.

Alors, que nous indique ce chiffre de 37B ?

Il nous indique quelle part du réseau participe au traitement d'un jeton.

Très grossièrement, un modèle dense de 671B impliquerait des calculs à travers un ensemble de poids beaucoup plus vaste pour chaque jeton.

Un modèle MoE peut conserver une capacité de paramètres énorme tout en choisissant un chemin beaucoup plus restreint pour le jeton actuel.

C'est pourquoi les architectures MoE sont attrayantes lors du passage à l'échelle des modèles.

Les travaux sur le Switch Transformer décrivent l'activation creuse précisément en ces termes : les modèles peuvent atteindre un nombre de paramètres extrêmement élevé tout en gardant un coût de calcul par exemple beaucoup plus maîtrisé.

DeepSeek suit la même idée générale à une échelle moderne beaucoup plus vaste.

Le MoE ne fait pas fonctionner 671B comme un modèle dense générique de 37B

Il y a une autre simplification excessive à éviter.

Si DeepSeek-R1 active 37B paramètres, cela ne signifie pas :

coût d'inférence de DeepSeek-R1
=
n'importe quel modèle dense aléatoire de 37B

L'architecture compte toujours.

Un modèle MoE comprend :

• couches d'attention
• routeurs
• paramètres partagés
• couches expertes
• communication entre les emplacements des experts
• mécanismes spécifiques au modèle tels que le MLA de DeepSeek
• différents modèles d'accès à la mémoire

« 37B actifs » est utile pour comprendre la sparsité.

Ce n'est pas un facteur de conversion de performance universel.

Mesurez le modèle réel.

Modèle dense versus MoE

Une comparaison générale utile est la suivante :

‍

‍

Le MoE permet d'augmenter la capacité en paramètres sans nécessiter l'exécution simultanée de tous les experts.

Le coût est un modèle et un système de service plus complexes.

Où résident habituellement les experts ?

Dans les modèles MoE (mélange d'experts) basés sur des transformeurs, les réseaux d'experts remplacent ou complètent généralement la partie feed-forward/MLP de certains blocs de transformeurs.

Ainsi, un bloc dense simplifié pourrait être :

Attention
  ↓
MLP dense

tandis qu'un bloc MoE pourrait être :

Attention
  ↓
Routeur
  ↓
MLP experts

Le mécanisme d'attention lui-même n'est généralement pas transformé en un vaste ensemble d'experts routés indépendamment de la même manière.

C'est important car tous les paramètres d'un modèle MoE ne sont pas activés de manière parcimonieuse.

Il existe des parties partagées du réseau que chaque jeton utilise systématiquement.

DeepSeek utilise également des experts partagés

DeepSeekMoE ajoute une autre idée utile.

Parallèlement aux experts routés, il isole des experts partagés destinés à capturer les connaissances communes, tandis que les experts routés peuvent se spécialiser davantage. L'architecture MoE publiée par DeepSeek combine une segmentation fine des experts avec des experts partagés pour réduire la redondance entre les spécialistes routés.

Conceptuellement :

Jeton
 │
 ├────────→ Expert partagé ─────────┐
 │                                │
 ↓                                │
Routeur                             │
 │                                │
 ├→ Expert routé A ──────────────┤
 └→ Expert routé F ──────────────┤
                                  ↓
                             combiner la sortie

L'expert partagé est disponible de manière générale.

Le routeur sélectionne toujours un sous-ensemble d'experts routés.

Cela signifie que le nombre de paramètres actifs de DeepSeek ne se limite pas simplement à :

nombre d'experts sélectionnés
×
taille de l'expert

Le modèle dispose également d'un calcul partagé.

La spécialisation des experts est la raison d'être des experts

Supposons que chaque expert apprenne exactement la même chose.

Avoir 64 experts entraînerait principalement une duplication des paramètres.

L'intérêt du routage réside dans le fait que les experts apprennent des fonctions suffisamment distinctes pour que différents jetons bénéficient de chemins d'experts différents.

Les travaux originaux sur DeepSeekMoE se concentrent largement sur ce problème et cherchent explicitement à encourager une spécialisation accrue des experts tout en réduisant la redondance des connaissances entre eux.

Cela crée également un défi en matière d'entraînement.

Vous recherchez la spécialisation.

Ce que vous ne voulez pas :

95 % des jetons → Expert 7

tandis que la plupart des autres experts restent inutilisés.

C'est ce qu'on appelle le problème d'équilibrage de charge.

L'équilibrage de charge des experts est crucial

Les routeurs ne distribuent pas nécessairement les jetons de manière uniforme par eux-mêmes.

Certains experts peuvent devenir beaucoup plus sollicités que d'autres.

Si un GPU contient les experts les plus sollicités tandis qu'un autre contient des experts rarement sélectionnés, le premier devient un goulot d'étranglement.

Vous pourriez vous retrouver avec :

GPU 0 → 95 % d'occupation
GPU 1 → 90 % d'occupation
GPU 2 → 25 % d'occupation
GPU 3 → 10 % d'occupation

alors même que la répartition totale du poids des experts semble parfaitement équilibrée sur le papier.

C'est l'une des raisons pour lesquelles le déploiement des MoE soulève un problème système qui va au-delà du simple stockage des poids.

La question est donc la suivante :

Les experts sont-ils répartis en fonction du trafic réellement généré par le routeur ?

La documentation actuelle de vLLM souligne que les distributions réelles de jetons peuvent être fortement asymétriques, même lorsque les modèles MoE sont entraînés pour favoriser une utilisation équilibrée des experts. Son équilibreur de charge pour le parallélisme d'experts peut redistribuer les affectations d'experts entre les rangs en fonction de la charge observée.

Qu'est-ce que le parallélisme d'experts ?

Le service de modèles denses utilise généralement le parallélisme tensoriel pour diviser les grands tenseurs à l'intérieur des couches du modèle entre plusieurs GPU.

Les modèles MoE nous offrent une autre option :

le parallélisme d'experts.

Au lieu de découper chaque expert sur chaque GPU, le parallélisme d'experts place différents experts sur différents GPU.

Sur le plan conceptuel :

GPU 0
Expert 1
Expert 2

GPU 1
Expert 3
Expert 4

GPU 2
Expert 5
Expert 6

GPU 3
Expert 7
Expert 8

Un jeton routé vers :

Expert 2 + Expert 7

nécessite donc un traitement sur :

GPU 0 + GPU 3

Le déploiement actuel en parallélisme d'experts de vLLM distribue explicitement les experts MoE sur différents GPU, tout en gérant les autres types de couches selon la configuration de parallélisme tensoriel ou de données.

Le parallélisme d'experts économise de la mémoire en distribuant les poids des experts

Imaginez :

64 experts

et :

8 GPU

Un placement simple en parallélisme d'experts pourrait conserver :

8 experts par GPU

plutôt que chaque GPU ne contienne les 64.

Cela rend le stockage de collections d'experts massives beaucoup plus simple.

Le coût survient lorsqu'un jeton a besoin d'un expert situé sur un autre GPU.

Son état caché doit alors être transféré vers le GPU hébergeant cet expert.

Après le calcul par l'expert, le résultat doit être renvoyé ou redistribué.

C'est pourquoi l'inférence MoE devient intensive en termes de communication.

Le parallélisme d'experts utilise une communication de type All-to-All.

Le parallélisme tensoriel repose souvent largement sur des modèles collectifs tels que AllReduce.

Le parallélisme d'experts présente un modèle de communication naturel différent :

All-to-All.

Les jetons existent initialement sur les GPU traitant leur lot actuel.

Le routeur détermine quel expert doit traiter chaque jeton.

Ces experts peuvent se trouver sur des GPU différents.

Les jetons doivent donc être répartis :

Jetons GPU 0 ─┬→ Experts GPU 1
             ├→ Experts GPU 2
             └→ Experts GPU 3

Jetons GPU 1 ─┬→ Experts GPU 0
             ├→ Experts GPU 2
             └→ Experts GPU 3

Ensuite, les sorties des experts doivent retourner vers les séquences appropriées.

Les implémentations actuelles du parallélisme d'experts dans vLLM proposent plusieurs backends All-to-All, incluant des chemins à usage général ainsi que des chemins spécialisés pour un débit élevé ou une faible latence.

Ainsi, une fois de plus, le modèle ne pose pas seulement un problème de mémoire.

La communication entre GPU devient une partie intégrante de l'inférence.

Le parallélisme tensoriel et le parallélisme d'experts résolvent des problèmes différents.

Comparez-les :

‍

‍

Un déploiement MoE à grande échelle peut utiliser les deux.

Les couches d'attention peuvent utiliser le parallélisme tensoriel, tandis que les experts utilisent le parallélisme d'experts.

vLLM prend actuellement en charge exactement ce type de configuration mixte.

Pourquoi le parallélisme d'experts peut surpasser le partitionnement tensoriel de chaque expert

Supposons que chaque expert soit volumineux.

Vous pourriez partitionner chaque expert sur tous les GPU.

Dans ce cas, chaque fois qu'un jeton utilise un expert, de nombreux GPU peuvent participer à l'opération.

Alternativement, le parallélisme d'experts permet de maintenir les experts individuels localement sur des appareils spécifiques.

Cela peut améliorer la localité et réduire l'ampleur de la distribution nécessaire pour chaque calcul d'expert.

vLLM décrit le parallélisme d'experts comme un moyen d'accroître la localité et l'efficacité des déploiements MoE.

Mais cela exerce une pression sur la répartition des jetons.

Une mauvaise disposition des experts peut entraîner une communication « All-to-All » coûteuse ou déséquilibrée.

Rien dans le MoE n'élimine les compromis inhérents aux systèmes distribués.

Cela modifie simplement les compromis qui importent.

DeepSeek-R1 est un MoE, mais ses modèles distillés ne le sont pas.

Cette distinction est particulièrement importante car les noms portent à confusion.

Complet :

DeepSeek-R1

repose sur l'architecture MoE de DeepSeek-V3 :

671 Md au total
37 Md actifs

Mais :

DeepSeek-R1-Distill-Qwen-14B
DeepSeek-R1-Distill-Qwen-32B
DeepSeek-R1-Distill-Llama-70B

sont des modèles denses plus petits affinés à l'aide de données de raisonnement générées par R1.

DeepSeek précise explicitement que ses modèles distillés R1 sont basés sur des points de contrôle denses de Qwen et Llama.

Par conséquent :

R1-Distill-Qwen-32B

ne contient pas une version réduite de l'architecture Mixture-of-Experts de R1.

Il s'agit d'un modèle dense de 32 Md basé sur Qwen, entraîné à partir d'exemples générés par R1.

C'est pourquoi notre guide matériel DeepSeek-R1 traite le modèle complet et les versions distillées comme des problèmes d'infrastructure totalement distincts.

Mixtral illustre pourquoi le nom d'un modèle peut également être trompeur

Mixtral 8x7B ressemble à première vue à :

8 × 7B
=
56B

mais son décompte de paramètres publié est d'environ :

47B au total
13B actifs

car chaque partie de l'architecture n'est pas simplement constituée de huit copies indépendantes d'un modèle 7B.

Les couches d'attention et les autres structures partagées ne sont pas répliquées sous forme de huit réseaux entièrement distincts.

L'article de Mistral explique que chaque couche MoE contient huit experts feed-forward et achemine chaque jeton à travers deux d'entre eux.

C'est pourquoi le nombre de paramètres doit être tiré de la documentation réelle du modèle plutôt que d'une simple multiplication des chiffres présents dans le nom du produit.

Wan 2.2 illustre l'utilisation du MoE au-delà des modèles de langage

Le MoE n'est plus réservé aux architectures LLM.

Wan 2.2 applique une conception MoE à la diffusion vidéo.

Ses modèles A14B utilisent deux experts :

• un expert pour le bruit élevé lors de la première étape de débruitage
• un expert pour le bruit faible lors de l'affinage final

Chaque expert possède environ 14B de paramètres.

Au total, le modèle contient environ :

27 milliards de paramètres au total

tandis que :

~14 milliards

sont actifs lors d'une étape de débruitage.

Ce mécanisme de routage diffère de celui d'un modèle de langage qui sélectionne des experts distincts pour des jetons arbitraires.

Wan effectue le routage en fonction de l'avancement du processus de génération dans le calendrier de bruit.

L'idée sous-jacente reste reconnaissable :

augmenter la capacité totale du modèle sans utiliser chaque expert pour chaque opération.

Notre guide Wan 2.2 pour ComfyUI et GPU couvre cette charge de travail en détail.

Le MoE permet-il d'économiser de la mémoire GPU ?

Cela mérite une réponse précise.

L'activation creuse ne réduit pas automatiquement la mémoire nécessaire pour stocker le modèle complet.

Si vous conservez chaque expert sur un seul GPU, tous leurs poids consomment de la VRAM, même si seul un sous-ensemble est actif pour un jeton donné.

Le MoE peut réduire la pression sur la mémoire par GPU lorsque les experts sont répartis sur plusieurs appareils grâce au parallélisme d'experts.

Vous pouvez également réduire le stockage du modèle via :

• la quantification
• Déchargement CPU
• déchargement d'experts
• placement spécialisé
• service distribué

Mais il s'agit là de techniques de déploiement.

L'architecture de base de routage creux réduit principalement la quantité de calcul d'expert activé par jeton par rapport à l'activation de chaque expert.

Un expert inactif consomme-t-il des ressources de calcul ?

Pour ce jeton, pas de la même manière qu'un expert sélectionné.

C'est tout l'intérêt de l'activation creuse.

Si un routeur sélectionne :

2 experts sur 8

les six autres MLP experts n'ont pas tous besoin d'effectuer leur calcul direct complet pour ce jeton.

Mais leurs paramètres existent toujours.

Et dans une implémentation résidant sur GPU, ces poids peuvent toujours occuper de la VRAM.

Donc :

inactif

signifie :

non sélectionné pour le calcul expert de ce jeton

plutôt que :

n'existe pas en mémoire

Le MoE réduit-il le nombre de FLOPs ?

Par rapport à un réseau dense ayant le même nombre total de paramètres, souvent de manière spectaculaire.

C'est l'un de ses objectifs principaux.

Mixtral expose 47 milliards de paramètres tout en en activant environ 13 milliards par jeton.

DeepSeek expose 671 milliards de paramètres au total tout en en activant 37 milliards par jeton.

L'objectif est de découpler :

la capacité totale en paramètres

de :

la puissance de calcul utilisée par chaque jeton

Le résultat est un calcul creux (sparse).

Cela n'implique pas la même latence qu'un modèle dense correspondant au nombre de paramètres actifs, car le routage, l'accès à la mémoire et la communication diffèrent.

Le MoE rend-il l'inférence plus rapide ?

Par rapport à quoi ?

Cette question nécessite une base de comparaison.

Un modèle dense de 671 milliards de paramètres nécessiterait un calcul énorme pour chaque jeton.

Un MoE de 671 milliards de paramètres au total qui en active 37 milliards est bien moins coûteux que ce modèle dense hypothétique de 671 milliards.

Cependant, un modèle MoE distribué de 671B n'est pas nécessairement plus rapide qu'un modèle dense de 32B bien optimisé.

L'inférence MoE peut entraîner :

• une surcharge de routage
• des charges d'experts irrégulières
• une communication All-to-All
• une synchronisation des experts
• un stockage important du poids total
• un accès mémoire moins prévisible

Le calcul creux est utile.

Le calcul creux distribué reste une question d'ingénierie système.

Pourquoi la qualité d'un modèle ne peut pas être prédite à partir des paramètres actifs

Supposons que nous comparions :

modèle MoE
37B actifs
671B au total

avec :

modèle dense
40B au total
40B actifs

Il serait tentant de dire :

Ils devraient avoir une capacité sensiblement équivalente car ils utilisent approximativement le même nombre de paramètres par jeton.

Ce n'est pas une conclusion logique.

Le modèle MoE peut solliciter différents sous-ensembles de paramètres pour différents jetons.

Sur l'ensemble d'un document ou d'une conversation, une part bien plus importante de ses paramètres totaux peut être mise à contribution à différents moments.

Les données d'entraînement, l'architecture, la qualité du routage, l'optimisation, la conception du contexte et le post-entraînement jouent également un rôle crucial.

Le nombre de paramètres n'a jamais été une mesure complète de la capacité des modèles denses.

Les modèles MoE rendent cette mesure encore moins pertinente.

Des jetons différents peuvent-ils utiliser des experts différents ?

Oui.

C'est un principe fondamental des modèles de langage MoE à routage par jeton, comme Mixtral.

Prenons l'exemple suivant :

"The Python function returns a list."

À une couche donnée, le routeur pourrait produire :

"The"      → Experts 2, 4
"Python"   → Experts 1, 7
"function" → Experts 3, 7
"returns"  → Experts 3, 5
"a"        → Experts 2, 4
"list"     → Experts 1, 6

Il ne s'agit là que d'identifiants illustratifs.

Le point important est que le routage peut varier selon le jeton et la couche.

Mixtral achemine explicitement chaque jeton indépendamment vers deux experts dans chaque couche MoE.

Cela crée d'énormes combinaisons de chemins d'experts possibles sans avoir besoin de faire appel à chaque expert à chaque fois.

Les experts ne sont pas nécessairement des spécialistes interprétables par l'humain

Il serait pratique de pouvoir ouvrir un modèle et découvrir :

Expert 12 = médecine
Expert 17 = JavaScript
Expert 24 = grec

La spécialisation réelle apprise est généralement plus complexe.

Un expert peut réagir à des modèles qui ne correspondent pas précisément à une catégorie humaine.

La spécialisation peut également varier selon les couches.

Les experts des premières couches peuvent réagir à des caractéristiques différentes de ceux des couches ultérieures.

Le modèle n'a pas besoin que les experts possèdent des intitulés de poste compréhensibles.

Il a besoin que le routage et les représentations des experts améliorent la prédiction.

Que se passe-t-il si chaque jeton choisit le même expert ?

Cela crée un problème sérieux.

Un expert devient surchargé.

Les autres reçoivent trop peu de travail d'entraînement ou d'inférence.

Le modèle perd alors une grande partie de l'avantage d'avoir de nombreux experts.

L'entraînement des systèmes MoE utilise donc des mécanismes de routage et d'équilibrage destinés à empêcher un effondrement sévère des experts.

Le Switch Transformer et les travaux ultérieurs sur les MoE identifient la capacité de routage et l'équilibrage des experts comme des défis majeurs, tandis que les systèmes de service actuels doivent également gérer le déséquilibre des experts dans le trafic réel.

C'est pourquoi le routeur n'est pas un simple classificateur ajouté au modèle.

Il est au cœur du succès ou de l'échec de l'architecture.

L'équilibrage de charge devient également un problème de mise en service

L'entraînement peut produire une utilisation globalement équilibrée des experts sur un corpus massif.

Votre trafic en production peut ne pas ressembler à ce corpus.

Imaginez un déploiement utilisé presque exclusivement pour du code.

Ses prompts peuvent solliciter systématiquement un sous-ensemble d'experts plus fréquemment.

Désormais, un rang parallèle d'experts reçoit beaucoup plus de travail qu'un autre.

Le rang surchargé le plus lent peut limiter l'ensemble de la passe avant distribuée.

La version actuelle de vLLM propose un Équilibreur de charge parallèle pour experts qui suit la charge des experts et peut ajuster les mappages d'experts entre les rangs pour atténuer ce déséquilibre.

C'est un bon exemple de problème d'inférence que les modèles denses ne rencontrent tout simplement pas sous cette forme.

La réplication des experts peut aider les experts très sollicités

Une autre stratégie consiste à répliquer les experts fréquemment utilisés.

Au lieu d'une seule copie de :

Expert 17

traitant chaque jeton qui y est acheminé, plusieurs appareils peuvent en détenir des copies.

Cela permet d'échanger de la mémoire supplémentaire contre une plus grande capacité de calcul et une meilleure répartition de la charge.

Le même principe revient sans cesse dans la conception de services :

mémoire
↔
débit

Utilisez de la mémoire supplémentaire pour dupliquer la capacité sollicitée.

Ou économisez de la mémoire en conservant moins de copies, au prix d'une contention accrue.

Le bon choix dépend de la charge de travail.

Le MoE rend la topologie de communication de plus en plus importante

Avec le parallélisme tensoriel, les GPU échangent des fragments d'opérations tensorielles.

Avec le parallélisme d'experts, les jetons peuvent être dirigés vers le périphérique qui héberge les experts sélectionnés.

Dans les deux cas, le chemin de communication d'un serveur multi-GPU est déterminant.

Pour les configurations Hivenet RTX 5090 sur un seul hôte, nous avons mesuré le NCCL AllReduce sur un hôte à 8 GPU et constaté que la bande passante du bus VM se situait dans la variance normale par rapport à la référence bare-metal. Ce résultat ne constitue pas un benchmark direct du trafic All-to-All du MoE, mais il confirme que l'environnement multi-GPU virtualisé peut offrir un chemin de communication GPU haute performance pour la charge de travail collective testée.

La méthodologie et les résultats sont disponibles dans notre benchmark GPU VM vs bare-metal.

Pour un déploiement MoE réel, effectuez un benchmark de la charge de travail All-to-All et du modèle exact plutôt que de considérer un résultat AllReduce comme interchangeable.

Le MoE et le parallélisme tensoriel peuvent être combinés

Supposons qu'un modèle dispose de :

Couches d'attention
+
Couches d'experts MoE

Vous pouvez utiliser :

le parallélisme tensoriel pour l'attention et les autres grands tenseurs denses,

et :

le parallélisme d'experts pour les couches d'experts.

La version actuelle de vLLM prend en charge cette conception hybride. Lorsque le parallélisme d'experts est activé, les couches d'experts sont réparties au sein du groupe EP, tandis que le comportement de l'attention dépend de la configuration TP et DP.

Cela offre au moteur de service des outils différents pour les différentes parties d'un même modèle.

C'est souvent plus judicieux que de supposer que chaque couche doit être parallélisée de manière identique.

Le parallélisme d'experts et le parallélisme de données peuvent également fonctionner ensemble

Le parallélisme de données signifie généralement :

répliquer le modèle
→ traiter des groupes de requêtes indépendants

Pour les déploiements MoE, les choses deviennent plus intéressantes.

vLLM peut combiner le parallélisme de données avec le parallélisme d'experts afin que les poids des experts soient distribués entre les rangs plutôt que répliqués indépendamment au sein de chaque copie parallélisée par les données.

Le résultat peut améliorer la localité des experts et l'efficacité de la mémoire.

Cela signifie également que des rangs supposés « parallélisés par les données » peuvent nécessiter une participation synchronisée à l'exécution des couches d'experts.

Le MoE rend la terminologie familière du parallélisme encore plus nuancée.

La quantification reste importante pour le MoE

L'activation creuse réduit le calcul.

Elle ne réduit pas le poids des experts stockés.

La quantification le peut.

Pour un MoE contenant des centaines de milliards de paramètres au total, le passage de poids appropriés de :

BF16

à :

FP8

ou à des formats de précision inférieure peut supprimer des centaines de gigaoctets des besoins de stockage.

Cela rend le guide d'inférence NVFP4 et Blackwell pertinent également pour le déploiement de MoE.

La combinaison peut être puissante :

MoE
→ activer moins d'experts

Quantification
→ réduire la taille des poids des experts

Parallélisme d'experts
→ distribuer les experts sur les GPU

Chaque technique s'attaque à une partie différente du problème d'infrastructure.

Le cache KV existe toujours dans un LLM MoE

Le MoE ne supprime pas l'attention.

Les MoE basés sur des modèles de langage nécessitent donc toujours un état d'attention lors de l'inférence autorégressive.

Leur cache KV peut toujours augmenter avec :

• le contexte
• la concurrence
• l'architecture
• la précision du cache

Cela crée une concurrence importante pour la VRAM.

Un GPU peut contenir :

des poids d'experts locaux
+
des poids d'attention/partagés
+
le cache KV
+
des allocations d'exécution

Répartir les experts sur davantage de GPU peut donc aider à la fois à faire tenir le modèle et à libérer de l'espace pour le cache.

Encore une fois, le nombre de paramètres actifs ne dit pas grand-chose sur le problème global de la mémoire de service.

PagedAttention optimise le cache, pas les poids des experts

Notre guide sur PagedAttention et le traitement par lots continu explique comment vLLM gère efficacement la mémoire du cache KV actif au fur et à mesure que les requêtes arrivent et se terminent.

Cela ne permet pas de charger et décharger gratuitement des centaines de gigaoctets de poids d'experts.

Il s'agit de couches de mémoire distinctes :

Paramètres du modèle
→ experts + poids partagés du modèle

État de l'inférence
→ cache KV + état temporaire

MoE et PagedAttention résolvent des problèmes différents.

Une pile de service performante doit gérer les deux.

Comment estimer la mémoire nécessaire pour un MoE ?

Partez du poids total du modèle, et non des paramètres actifs.

Si le point de contrôle complet du modèle est disponible, utilisez sa taille réelle.

Si vous ne disposez que du nombre de paramètres, utilisez une estimation approximative pour la planification :

nombre total de paramètres
×
octets par paramètre stocké

Prenez ensuite en compte :

• métadonnées de quantification
• couches à plus haute précision
• embeddings
• poids du modèle partagés/attention
• tampons d'exécution
• cache KV
• placement des experts
• réplication

Si les experts sont répartis sur plusieurs GPU, calculez la quantité d'état d'expert stockée par chaque GPU.

Ajoutez ensuite les parties partagées ou fragmentées du modèle.

Cela demande plus de travail que :

paramètres actifs × 0,5

C'est aussi beaucoup plus proche de la réalité.

Expérience de pensée sur la mémoire de DeepSeek-R1

Commencez par :

671 milliards de paramètres au total
37 milliards de paramètres actifs

Si chaque paramètre était hypothétiquement en 4 bits :

671B × 0,5 octets
≈ 335,5 Go

Huit RTX 5090 offrent :

8 × 32 Go
=
256 Go de VRAM totale

Ainsi, même le stockage théorique brut des poids en 4 bits dépasse la capacité totale du groupe de huit GPU.

C'est pourquoi le modèle R1 complet ne devient pas soudainement une charge de travail standard pour huit 5090, simplement parce que seuls 37 milliards de paramètres sont activés par jeton.

La sparsité des experts réduit le calcul.

Elle n'efface pas l'ensemble complet des paramètres des experts.

La quantification spécialisée, le déchargement et les déploiements distribués peuvent modifier l'implémentation. L'arithmétique de base explique pourquoi le point de départ reste complexe.

Un MoE peut être léger en calcul par rapport à son stockage

C'est sans doute le meilleur modèle mental.

Le MoE crée un ratio inhabituel :

un grand nombre de paramètres stockés
↓
un sous-ensemble plus restreint de calcul actif

Les modèles denses maintiennent ces deux quantités plus étroitement liées.

Cela rend les MoE attractifs lorsque le calcul est le facteur limitant et que vous pouvez gérer le stockage des paramètres et le système de routage.

Cela peut devenir problématique lorsque la capacité mémoire ou la communication entre GPU constitue la contrainte principale.

C'est pourquoi le MoE n'est pas automatiquement une architecture moins coûteuse dans tous les déploiements.

Quand le MoE est-il pertinent ?

Du point de vue de la conception du modèle, le MoE est intéressant lorsque vous recherchez :

• une très grande capacité totale de modèle
• un calcul parcimonieux par jeton
• des experts capables de se spécialiser
• une meilleure mise à l'échelle sans augmentation proportionnelle des FLOPs

Du point de vue de l'infrastructure, il est pertinent lorsque le système de service peut gérer :

• un stockage important du poids total
• le routage
• le placement des experts
• la communication All-to-All
• le déséquilibre de charge
• le parallélisme des experts
• le cache et les couches partagées

L'architecture et l'infrastructure doivent être adaptées l'une à l'autre.

Quand un modèle dense peut-il être plus simple ?

Un modèle dense est opérationnellement plus simple.

Chaque jeton suit essentiellement le même chemin de paramètres.

Il n'y a pas de routage d'experts.

Il n'existe pas d'experts « à la mode ».

Vous n'avez pas besoin de placement d'experts ou de répartition All-to-All des jetons.

Un modèle dense robuste de 27B tenant sur un seul GPU peut donc être plus simple à exploiter qu'un MoE beaucoup plus volumineux, même si le nombre de paramètres actifs du MoE semble similaire.

Notre guide des GPU cloud pour Qwen3.6-27B est une bonne illustration de cette catégorie de déploiement simplifiée.

L'architecture du modèle fait partie intégrante des opérations.

Ne choisissez pas un MoE simplement parce que le nombre total de paramètres est plus élevé.

Un modèle avec :

300B au total
30B actifs

n'est pas automatiquement supérieur à un modèle :

dense de 70B.

modèle.

Et l'inverse n'est pas non plus justifié.

Évaluez le modèle sur la tâche à accomplir.

Évaluez ensuite l'infrastructure nécessaire pour le déployer.

Les questions pertinentes sont :

1. Le modèle produit-il de meilleurs résultats ?
2. Combien de paramètres sont réellement stockés ?
3. Combien sont activés ?
4. De combien de VRAM le point de contrôle réel a-t-il besoin ?
5. Comment est-il quantifié ?
6. Comment les experts sont-ils répartis ?
7. Quelle communication l'inférence nécessite-t-elle ?
8. De quelle concurrence et de quel contexte avons-nous besoin ?
9. Quel est le coût d'un débit utile ?

Le nombre de paramètres doit être pris en compte dans cette décision.

Il ne doit pas la remplacer.

La manière pertinente d'envisager le mélange d'experts

Un modèle de mélange d'experts confère au réseau plus de paramètres potentiels qu'il n'en faut pour activer un jeton.

Le routeur choisit un chemin.

C'est ce qui donne au MoE son avantage principal :

une grande capacité totale
+
un calcul parcimonieux

La même conception crée son principal défi d'infrastructure :

tous ces poids d'experts
vous cherchez toujours un logement

Dès que plusieurs GPU sont impliqués, une autre exigence apparaît :

les jetons doivent atteindre
les experts qu'ils ont sélectionnés

L'inférence MoE devient donc un équilibre entre :

capacité
calcul
mémoire
routage
communication
équilibrage de charge

C'est pourquoi « 671B au total, 37B actifs » n'est pas contradictoire.

Il s'agit d'une description compacte de l'architecture.

Le chiffre 671B indique la capacité totale en paramètres.

Le chiffre 37B indique quelle part de cette capacité participe au calcul d'un jeton.

Vous avez besoin des deux chiffres pour comprendre le modèle.

FAQ sur le mélange d'experts (MoE)

Qu'est-ce qu'un modèle de mélange d'experts ?

Un modèle de mélange d'experts contient plusieurs réseaux experts et un mécanisme de routage qui sélectionne un sous-ensemble de ces experts pour chaque entrée ou jeton. Les modèles MoE parcimonieux n'activent donc qu'une partie de leur ensemble total de paramètres pour chaque passe avant.

Que signifie MoE ?

MoE signifie Mixture of Experts (mélange d'experts).

Qu'est-ce qu'un expert dans un MoE ?

Un expert est un sous-réseau paramétré au sein du modèle, généralement un bloc feed-forward/MLP dans les MoE basés sur des transformers. Le routeur choisit quels experts traitent un jeton.

Qu'est-ce que le routeur dans un MoE ?

Le routeur est un mécanisme de contrôle appris qui évalue les experts disponibles et décide quel sous-ensemble doit traiter chaque jeton.

Que sont les paramètres actifs ?

Les paramètres actifs sont les paramètres participant au calcul pour un jeton ou un chemin de propagation particulier. Dans un MoE creux, ils peuvent être bien moins nombreux que le nombre total de paramètres du modèle.

Que sont les paramètres totaux ?

Les paramètres totaux comptabilisent l'ensemble des paramètres appris contenus dans le modèle, y compris les experts qui ne sont pas sélectionnés pour le jeton actuel.

Un MoE a-t-il besoin de mémoire pour les experts inactifs ?

Oui. Si les poids des experts sont chargés sur les accélérateurs, les experts inactifs occupent de la mémoire même lorsqu'ils ne sont pas sélectionnés pour un jeton spécifique. Ils peuvent être distribués ou déchargés, mais l'activation creuse en elle-même ne supprime pas leurs besoins en stockage.

Pourquoi DeepSeek-R1 possède-t-il 671 milliards de paramètres mais seulement 37 milliards actifs ?

DeepSeek-R1 utilise l'architecture MoE de DeepSeek-V3. Il contient 671 milliards de paramètres au total, tandis que l'architecture de routage active environ 37 milliards de paramètres pour chaque jeton.

DeepSeek-R1 est-il réellement un modèle de 37 milliards de paramètres ?

Non. Le chiffre de 37 milliards décrit les paramètres activés, et non la taille totale du modèle stocké. Le modèle complet contient 671 milliards de paramètres.

De combien de VRAM un MoE de 671 milliards de paramètres a-t-il besoin ?

Cela dépend de la précision, de la quantification, du placement et du déchargement. À titre d'estimation brute, 671 milliards de paramètres correspondent à environ 1,34 To en 16 bits, 671 Go en 8 bits ou 335,5 Go en 4 bits, sans compter les autres frais généraux.

Le MoE réduit-il la charge de calcul ?

Les modèles MoE parcimonieux peuvent réduire considérablement le volume de calcul par rapport à un modèle dense possédant le même nombre total de paramètres, car seuls certains experts sont activés pour chaque entrée. C'est l'une des motivations principales des architectures à experts parcimonieux.

Le MoE réduit-il la mémoire GPU ?

Pas automatiquement. L'activation parcimonieuse réduit le calcul actif. Le poids total des experts doit toujours être stocké, à moins qu'ils ne soient distribués, quantifiés ou déchargés.

Qu'est-ce que le parallélisme d'experts ?

Le parallélisme d'experts répartit les différents experts MoE sur plusieurs GPU. Les jetons sont acheminés entre les appareils en fonction des experts dont ils ont besoin. La version actuelle de vLLM prend en charge le déploiement MoE avec parallélisme d'experts.

En quoi le parallélisme d'experts diffère-t-il du parallélisme tensoriel ?

Le parallélisme tensoriel divise les opérations tensorielles importantes entre les GPU. Le parallélisme d'experts place différents experts sur différents GPU et y achemine les jetons. Le service MoE peut utiliser ces deux techniques.

Quel type de communication le parallélisme d'experts utilise-t-il ?

Le parallélisme d'experts nécessite généralement une communication de type All-to-All afin que les états des jetons puissent être envoyés aux GPU hébergeant les experts sélectionnés et que les résultats puissent être renvoyés. La version actuelle de vLLM propose plusieurs backends All-to-All pour le service avec parallélisme d'experts.

Qu'est-ce que l'équilibrage de charge des experts ?

L'équilibrage de charge des experts vise à éviter qu'un petit nombre d'experts ou de GPU hébergeant des experts ne reçoive une charge de travail disproportionnée. vLLM propose actuellement un équilibreur de charge pour parallélisme d'experts capable d'ajuster les mappages d'experts en fonction de la charge observée.

Mixtral 8x7B est-il un modèle de 56B ?

Le nombre total de paramètres du modèle publié est d'environ 47B, avec environ 13B de paramètres actifs par jeton. Chaque couche MoE contient huit experts et achemine chaque jeton à travers deux d'entre eux.

Les modèles distillés DeepSeek-R1 sont-ils des modèles MoE ?

Non. Les modèles distillés officiels R1 sont des modèles denses basés sur Qwen et Llama, affinés à partir de données générées par DeepSeek-R1.

Le mélange d'experts (MoE) est-il uniquement utilisé pour les LLM ?

Non. Wan 2.2 utilise une architecture MoE dans ses modèles de diffusion vidéo A14B, avec des experts distincts pour le bruit élevé et le bruit faible, activés à différents stades du débruitage.

Chaque jeton utilise-t-il les mêmes experts ?

Pas nécessairement. Dans les modèles de langage MoE à routage par jeton comme Mixtral, le routeur peut choisir des experts différents pour des jetons différents et à des couches différentes.

Les experts sont-ils spécialisés dans des sujets évidents ?

Pas nécessairement. Les experts peuvent développer une spécialisation, mais leurs rôles appris ne correspondent pas forcément aux catégories humaines telles que la programmation, la médecine ou les langues individuelles.

Le modèle MoE est-il plus rapide qu'un modèle dense ?

Le MoE peut utiliser beaucoup moins de ressources de calcul qu'un modèle dense possédant le même nombre total de paramètres, mais la vitesse d'inférence réelle dépend du routage, du placement des experts, de la communication, de l'accès à la mémoire, du matériel et du logiciel de service.

Dois-je choisir un modèle en fonction des paramètres actifs ?

Non. Les paramètres actifs aident à décrire le calcul d'inférence, mais la qualité du modèle et les exigences matérielles dépendent également du nombre total de paramètres, de l'architecture, de l'entraînement, de la précision, du routage, du contexte et de la configuration du service.

‍