Mélange d’experts : calcul parcimonieux, routage et coût de déploiement
Un mélange d’experts, ou MoE, stocke plusieurs groupes de paramètres mais n’en active qu’une partie pour chaque entrée. Dans les Transformers parcimonieux courants, il remplace certaines couches FFN : un routeur choisit quelques experts par token, puis combine leurs sorties. La capacité totale peut ainsi croître sans augmenter proportionnellement le calcul FFN par token.
Les experts sont des sous-réseaux entraînés au sein d’un modèle, pas des agents conversationnels réunis en discussion. Leur nom ne garantit pas des spécialités distinctes en mathématiques, droit ou code. Voir d’abord les activations et FFN à portes.
Voir l’image en grandLe bloc bleu suit deux tokens : chaque routeur choisit un FFN, puis pondère sa sortie. Il s’agit du routage top-1 de Switch. La formulation top-k ci-dessous peut activer plusieurs experts pour un même token.
Suivre un token
L’article fondateur sur le MoE à portes parcimonieuses utilise un mécanisme appris pour sélectionner certains experts. Une formulation simplifiée de top-k choisi par token est :
L’état a une largeur ; la matrice de routage a la forme [d,E] pour E experts. désigne un sous-réseau et son poids. Scores, normalisation, experts partagés et biais varient selon l’implémentation. La formule montre sélection, calcul et combinaison.
Avec quatre experts et top-2, supposons [0.50,0.30,0.15,0.05]. En renormalisant les experts retenus, les deux poids deviennent 0,625 et 0,375. Si leurs sorties sont [2,0] et [0,4], le mélange vaut [1.25,1.50]. Ces valeurs sont pédagogiques, pas des mesures d’un modèle réel.
Les tokens peuvent choisir des experts différents ; un même token peut changer de route entre couches. Attention, normalisation et résidus partagés restent généralement présents. Le routeur choisit un calcul interne, pas une réponse lisible.
Paramètres stockés et paramètres actifs
Switch Transformer présente un expert par token ; Mixtral en sélectionne deux sur huit par couche. Ces proportions sont des choix d’architecture, pas la définition du MoE.
Considérons seulement les FFN d’une couche : huit experts de 10M paramètres et top-2 donnent 80M paramètres stockés, mais deux groupes, environ 20M, utilisés par un token. Les paramètres partagés s’ajoutent séparément. Dans un lot, les routes peuvent collectivement utiliser les huit experts.
Les experts inactifs doivent quand même être stockés. Les garder tous sur GPU mobilise la mémoire de tous les poids ; les déporter vers CPU ou disque ajoute des transferts. Le cache KV dépend surtout de l’attention, de la longueur et du lot. Le nombre d’experts ne multiplie ni ne divise directement sa formule.
Gérer la charge du routage
Si presque tous les tokens choisissent un expert, les autres restent inactifs et le premier devient un goulot d’étranglement. L’apprentissage peut renforcer cette préférence. L’équilibrage évite une concentration excessive du calcul et des occasions d’apprentissage ; il n’exige pas des tâches identiques partout.
Une implémentation de Switch attribue une capacité à chaque expert. Pour 100 tokens, quatre experts, top-1 et facteur 1,2, cela donne environ places par expert. La répartition [55,20,15,10] surcharge le premier de 25 tokens. Les 120 places totales ne déplacent pas automatiquement les places libres vers lui. Dans Switch, les tokens excédentaires passent par le résidu sans calcul d’expert à cette couche ; voir la discussion sur capacité et équilibrage. D’autres implémentations utilisent une autre planification ou ne suppriment pas de calcul : ce comportement n’est pas universel.
Une perte auxiliaire favorise une distribution plus équilibrée ; trop pondérée, elle peut perturber l’objectif de tâche. Stabilité, précision numérique et changement de distribution comptent aussi. Un trafic équilibré à l’entraînement ne garantit pas l’équilibre avec de longs documents ou une langue particulière en production.
La communication peut absorber le gain arithmétique
Le parallélisme d’experts distribue les experts sur plusieurs appareils. Il faut leur envoyer les tokens choisis puis récupérer les sorties, souvent par communication all-to-all. Le coût dépend des interconnexions, du nombre de tokens, de la forme des lots et de la planification. Réduire les opérations FFN ne supprime pas les transferts.
Une requête avec peu de tokens peut créer de petites multiplications peu efficaces. Des lots plus grands augmentent le travail par expert, mais aussi routage, tampons et communications. Des modèles aux paramètres actifs similaires peuvent avoir des latences très différentes selon poids totaux, attention et implémentation. Relier ce choix à la quantification et aux performances d’inférence.
Lire les résultats de performance
Relever paramètres totaux et actifs, nombre d’experts, top-k et experts partagés. Préciser ensuite matériel, précision, parallélisme, longueurs et concurrence. Séparer latence du premier token, vitesse de génération suivante et débit global. Comparer la qualité sur les mêmes tâches.
Si les statistiques existent, examiner charge par couche, dépassements ou reroutages, temps de communication et variation selon les entrées. Recevoir souvent des tokens de code montre une préférence de routage. Qualifier l’expert de spécialiste du code demande des interventions contrôlées ou des ablations, pas seulement quelques exemples.
Le MoE ouvre un compromis entre capacité et calcul. Un déploiement local doit encore disposer du stockage de tous les poids, de noyaux compatibles, d’un budget de cache et d’une latence acceptable. Un faible nombre de paramètres actifs ne suffit pas à conclure qu’une machine exécutera le modèle confortablement.