Plus de paramètres, mais une étape plus lente
Vous voulez entraîner un modèle de langage sur plusieurs cartes graphiques, les GPU. Une étape d’entraînement consiste à lui faire traiter un lot de texte, à mesurer ses erreurs puis à ajuster ses paramètres, les coefficients qu’il apprend. Vous cherchez à lui donner davantage de paramètres sans augmenter autant le calcul nécessaire à chaque étape. C’est l’intérêt recherché avec un mélange d’experts, ou MoE.
Supposons que vous disposiez déjà d’un modèle sans sélection d’experts, appelé modèle dense. Vous remplacez certains blocs par des experts en gardant une quantité comparable de calcul par token. Le nouveau modèle possède davantage de paramètres, mais n’en utilise qu’une partie à la fois. Pourtant, une étape prend maintenant plus de temps. Que font les GPU pendant cette différence ?
Il faut alors suivre ce que font les machines. Certaines multiplient des matrices, d’autres attendent des données. Les experts reçoivent des quantités de travail différentes, les échanges traversent plusieurs types de liens et les zones de mémoire temporaires occupent de la place. Une économie d’opérations ne garantit pas une économie de temps.
Le Ultimate MoE Training Handbook de Hugging Face, signé Nouamane Tazi, Leandro von Werra et Thomas Wolf, fournit le point de départ de ce dossier. Nous retenons son parcours de diagnostic et le confrontons aux publications et aux implémentations citées ci-dessous. LeCompute n’a pas réalisé de benchmark multi-GPU pour cet article. L’exemple chiffré qui suit est construit pour expliquer le mécanisme.
Un expert transforme des nombres à l’intérieur du modèle
Le modèle découpe le texte en tokens, des morceaux qui peuvent correspondre à un mot ou à une partie de mot. Il associe à chacun une liste de nombres, un vecteur. Au fil des couches du réseau, ce vecteur est transformé pour préparer la prédiction. L’attention fait circuler des informations entre les positions du texte ; un bloc de calcul appelé feed-forward, ou FFN, transforme ensuite le vecteur de chaque position.
Dans les architectures MoE Mixture-of-Experts. Architecture où le réseau est découpé en de nombreux « experts » dont un routeur n'active qu'un petit sous-ensemble par token. Le calcul par token suit le nombre de paramètres actifs ; la mémoire, elle, suit le nombre total, car tous les experts doivent rester résidents en VRAM, prêts à être sollicités. Approfondir dans le glossaire étudiées ici, ce bloc FFN propose plusieurs transformations possibles : les experts. Ce sont des sous-réseaux avec leurs propres coefficients appris, les poids. Deux experts peuvent avoir exactement la même structure et recevoir le même vecteur tout en produisant des sorties différentes, parce que leurs poids diffèrent. Un expert fournit un nouveau vecteur à la suite du réseau ; il ne rédige pas à lui seul une réponse à l’utilisateur.
Le routeur est un petit réseau qui lit le vecteur d’entrée et calcule un score pour chaque expert. Il retient ceux qui ont les meilleurs scores. Sélectionner les deux meilleurs s’appelle un top-2 ; le terme top-k désigne le même choix pour un nombre k d’experts. Les autres experts de cette couche ne calculent pas de sortie pour ce token. Le papier Mixtral décrit cette sélection et la somme pondérée qui suit.
Prenons un exemple de pondération : le routeur choisit les experts A et B avec des coefficients de 0,75 et 0,25. La sortie du bloc vaut alors 0,75 × sortie_A + 0,25 × sortie_B, coordonnée par coordonnée. Ces coefficients indiquent la contribution de chaque sortie dans cet exemple, pas une probabilité que l’expert ait « raison ». La couche suivante reçoit le vecteur obtenu, et une autre couche MoE pourra faire un autre choix.
C’est ce choix limité qui permet d’ajouter des experts sans tous les exécuter pour chaque token. Le nombre total de poids augmente, tandis qu’une partie seulement intervient dans le calcul de cette couche. Les poids des autres experts restent à stocker pour les tokens qui les utiliseront.
Comment le routeur apprend sans connaître le bon expert
Pendant l’entraînement d’un modèle qui prédit la suite d’un texte, les données fournissent le token réellement présent à la position suivante. Le modèle produit une distribution de probabilités sur les tokens possibles. Une fonction d’erreur, appelée perte, pénalise une faible probabilité attribuée au token attendu. Le but partagé du routeur et des experts est de réduire cette erreur finale.
Le programme remonte ensuite les opérations qui ont produit la prédiction. Cette rétropropagation calcule des gradients : ils indiquent comment une petite modification des paramètres ferait varier la perte. L’optimiseur, l’algorithme qui met à jour les poids, utilise ces indications pour effectuer un ajustement. La qualité des prédictions se construit ainsi sur de nombreux lots de texte.
Reprenons les contributions de A et B. Si une légère augmentation de la pondération de A ferait baisser l’erreur finale, le gradient transmet cette indication au routeur. Si une petite modification des poids de A aiderait également, un signal rejoint cet expert. Ces indications sont calculées à travers la chaîne d’opérations ; elles n’exigent pas de refaire une prédiction complète pour chaque modification possible.
Le signal vient ici du mélange pondéré des sorties retenues. Le choix qui garde deux experts et écarte les autres, lui, ne fournit pas directement une dérivée permettant de comparer toutes les sélections possibles. C’est pourquoi la manière de transformer les scores en pondérations fait partie du mécanisme d’apprentissage, pas seulement de l’affichage de pourcentages. Mécanisme de routage et d’apprentissage de Switch Transformers.
Le routeur n’essaie donc pas tous les experts pour comparer leurs réponses au corrigé. Il apprend avec les chemins exécutés par le modèle. À mesure que ses poids changent, les scores peuvent changer et d’autres experts être sélectionnés. Des comportements spécialisés peuvent émerger, sans que l’ingénieur ait à nommer à l’avance un expert « code » ou « français ».
Quand les experts vivent sur des GPU différents
Jusqu’ici, nous avons décrit des opérations mathématiques. Pour les exécuter sur un cluster, un ensemble de machines reliées, il faut décider où résident les poids. Le parallélisme d'experts Mode de découpage d'un MoE où chaque GPU héberge un sous-ensemble des experts, au lieu de recevoir une tranche de chaque matrice comme en parallélisme tensoriel. Le token doit donc voyager jusqu'aux GPU qui détiennent les experts choisis pour lui : la communication devient un all-to-all et non un all-reduce. Souvent abrégé EP. place des experts différents sur les GPU. Si le routeur choisit un expert situé sur une autre carte, le vecteur doit rejoindre cette carte avant que l’expert puisse travailler.
Ces vecteurs intermédiaires s’appellent les activations. Le dispatch les regroupe par destination et les achemine aux experts ; le combine rapporte les sorties et les réunit avec leurs pondérations. Un dispatcher est le composant logiciel qui organise ces échanges. Avec un all-to-all Collective où chaque rang envoie une donnée distincte à chaque autre rang. Dans une couche MoE en parallélisme d'experts, elle survient deux fois : le dispatch expédie l'état caché de chaque token vers les GPU de ses experts, le combine rapatrie les sorties. Son volume est proportionnel au nombre de tokens, donc il ne s'amortit pas avec la taille du lot. , les processus participants peuvent chacun envoyer des données différentes aux autres. En entraînement distribué, un processus pilote typiquement un GPU et porte un identifiant appelé rang. Opérations de communication de DeepEP.
Ce schéma suit le passage avant, celui qui produit les résultats à partir des entrées. La rétropropagation échange ensuite les informations nécessaires pour calculer les gradients. Le coût réseau ne se limite donc pas à envoyer une fois les vecteurs d’entrée. Le routeur choisit des transformations, et leur placement transforme ces choix en trajets et en charges de calcul sur les cartes.
Un exemple : quatre GPU, une seule carte qui retarde les autres
Hypothèse pédagogique. Une couche possède huit experts de même structure et de même coût de calcul, avec leurs propres poids. Ils sont placés par paires sur quatre GPU. Ensemble, les quatre processus traitent 4 096 tokens et choisissent deux experts par token. Chaque token déclenche donc deux traitements : cela donne 8 192 affectations token-expert. Nous ignorons ici les autres parallélismes.
Une distribution uniforme donnerait 1 024 affectations par expert et 2 048 par GPU. Supposons que le routeur produise plutôt cette répartition :
| GPU | Affectations aux deux experts | Total sur la carte |
|---|---|---|
| GPU 0 | 3 072 + 1 024 | 4 096 |
| GPU 1 | 1 024 + 1 024 | 2 048 |
| GPU 2 | 512 + 512 | 1 024 |
| GPU 3 | 512 + 512 | 1 024 |
GPU 0 reçoit deux fois la charge moyenne d’une carte. Même si les autres terminent plus tôt, les opérations dépendantes des résultats de GPU 0 doivent patienter. Le temps ne double pas nécessairement : les multiplications peuvent avoir des rendements différents selon leur taille, et certains travaux se recouvrent. Mais la moyenne du cluster masque déjà la carte à examiner.
Le déséquilibre doit donc être observé à deux niveaux. Les comptes par expert montrent les experts peu sollicités ou saturés. La somme de ces comptes sur chaque GPU révèle la répartition physique du travail. Un placement différent pourrait modifier cette seconde distribution sans changer le total reçu par chaque expert.
Pour rendre l’exemple tangible côté mémoire, supposons que chaque vecteur envoyé à un expert contienne 2 048 valeurs stockées sur deux octets. Les 8 192 affectations représentent 32 Mio de vecteurs d’entrée : 8 192 × 2 048 × 2. Ce calcul suppose une copie du vecteur par expert choisi. Il ne donne pas le trafic d’une carte réseau : une partie des traitements reste locale, certains envois peuvent être regroupés et les métadonnées, les sorties et les gradients s’ajoutent. Il montre déjà qu’un expert supplémentaire par token augmente aussi les données à traiter.
Pourquoi ajouter une contrainte d’équilibrage
Nous avons vu comment l’erreur de prédiction entraîne le routeur. Cet objectif ne lui demande pas directement de répartir le travail entre les GPU. Dans notre scénario, il peut continuer à favoriser l’expert qui reçoit 3 072 affectations, même si la carte qui l’héberge retarde les autres.
Les experts peu sélectionnés reçoivent aussi moins de signal d’apprentissage issu de la tâche. Une perte auxiliaire d’équilibrage ajoute donc un second objectif : encourager une meilleure répartition. Son coefficient règle l’importance de cette contrainte face à l’erreur de prédiction. Switch Transformers décrit ce mécanisme ainsi qu’une précision numérique plus élevée pour stabiliser le routeur. De petites différences entre scores peuvent changer les experts retenus ; conserver davantage de précision à cet endroit protège la décision sans exécuter tout le modèle en FP32, le format flottant sur 32 bits.
L’approche Auxiliary-Loss-Free Load Balancing ajuste plutôt un bonus ou un malus de sélection, appelé biais, selon la charge récente de chaque expert. Favoriser un expert sous-utilisé augmente ses chances d’être retenu. Cette correction intervient dans le choix, séparément des scores qui pondèrent les sorties. « Sans perte auxiliaire » signifie que cette correction de charge ne provient pas d’un second objectif ajouté à l’erreur de prédiction ; le modèle continue à apprendre sa tâche.
Le réglage doit se juger sur les deux effets recherchés : laisser apprendre des transformations utiles et éviter qu’une partie du matériel absorbe tout le travail. Une courbe de perte d’équilibrage isolée ne montre pas ce que reçoit réellement chaque carte.
Équilibrer sur quel ensemble de tokens ?
Une séquence, un micro-lot et un lot global ne contiennent pas le même mélange de données. Le micro-lot est le petit groupe traité à la fois par un processus ; plusieurs micro-lots et processus peuvent contribuer à une mise à jour globale des poids. Répartir uniformément chaque petit groupe impose une contrainte plus forte que répartir l’ensemble.
Supposons qu’un micro-lot contienne surtout du code et qu’un autre contienne surtout du texte en français. Exiger une répartition uniforme dans chacun pousse les deux types de données vers tous les experts. Exiger cette répartition seulement sur leur ensemble laisse la possibilité à des experts différents de recevoir davantage de code ou de français. Mais la carte qui héberge les experts favoris du code peut recevoir une pointe de charge pendant le premier micro-lot.
Le travail de l’équipe Qwen, Demons in the Detail, étudie cette différence. Un équilibrage global laisse davantage de place à la spécialisation par domaine dans ses expériences, tout en autorisant un déséquilibre local. Mesurez donc la charge des micro-lots que les GPU exécutent réellement, même si votre objectif porte sur le lot global.
Pour lire ces mesures, MaxVio exprime l’excès de charge de l’expert le plus sollicité par rapport à la moyenne : (maximum − moyenne) / moyenne. Dans notre exemple, il vaut (3 072 − 1 024) / 1 024 = 2. Cela signifie trois fois la charge moyenne sur cet expert. Ce chiffre n’est ni une erreur de prédiction ni un pourcentage de GPU inutilisés. Définition dans l’étude sur l’équilibrage sans perte auxiliaire.
Des pointes de charge sur des experts différents peuvent se compenser sur une longue période, tout en ralentissant chaque micro-lot. En pratique, conservez les compteurs par couche et par intervalle court avant de calculer des moyennes globales. C’est aussi ce qui permet de repérer une couche problématique derrière une moyenne satisfaisante sur tout le modèle.
Vérifier l’allocation avant de modifier le modèle
Avant d’ajuster le modèle, il faut savoir ce que les machines sont capables de faire. Une allocation désigne les ressources réservées pour l’entraînement ; un nœud est une machine du cluster, qui peut contenir plusieurs GPU. Relevez les nœuds, leurs connexions, appelées la topologie, et les versions logicielles. Deux allocations avec le même nombre de cartes peuvent inclure une machine dégradée ou emprunter des chemins réseau différents. Changer simultanément les machines et le routeur empêcherait de savoir ce qui a corrigé le problème.
Sur du matériel NVIDIA compatible, DCGM, l’outil de diagnostic des GPU, propose des contrôles de préparation. Le niveau 1 sert à vérifier la disponibilité avant un travail ; les diagnostics plus poussés demandent un créneau adapté. Un test passé ne dispense pas de surveiller les erreurs et les changements de comportement pendant l’entraînement.
Il faut ensuite tester les échanges utilisés. Un all-reduce combine les contributions des processus, par exemple pour sommer des gradients ; un all-to-all distribue des messages vers plusieurs destinations. Un bon résultat du premier ne valide pas automatiquement le second. NCCL Tests teste la performance et la correction des échanges de NCCL, la bibliothèque de communication de NVIDIA. Conservez le nombre de processus, la taille des messages, les machines, les versions et la colonne de débit comparée. La mesure de bande passante busbw d’un test synthétique ne donne pas directement le nombre de tokens que votre modèle pourra traiter par seconde.
Cette référence sert à distinguer une allocation défaillante d’un changement de charge applicative. Comparez les réglages réseau sur les mêmes machines. Pour une autre taille de cluster, établissez une référence correspondante au lieu d’appliquer un seuil unique à toutes les allocations.
Construire une référence dense qui permet de raisonner
Le modèle dense, qui applique le même bloc FFN à tous les tokens d’une couche, donne un contrôle utile. Vérifiez que les données arrivent assez vite, que l’attention fonctionne, que la perte diminue et que les sauvegardes des poids sont rechargeables. Ce contrôle évite d’attribuer au MoE un problème déjà présent dans la boucle d’entraînement.
La comparaison demande toutefois de préciser ce qui reste égal. Garder le nombre de paramètres actifs rapproche une partie du calcul, mais le MoE conserve aussi les poids de ses experts non sélectionnés. L’optimiseur peut garder des informations de suivi pour mettre à jour ces poids, ce qui occupe encore de la mémoire. Comparer à nombre total de paramètres égal répond à une autre question : combien de calcul la sélection permet-elle d’éviter dans un modèle de cette taille ? Annoncez la comparaison choisie avant d’interpréter son résultat.
Les expériences d’OLMoE font varier séparément plusieurs choix : la taille et le nombre des experts, la présence d’experts exécutés pour tous les tokens, ou la conversion d’un modèle dense en MoE, appelée upcycling. Cette méthode aide à relier un résultat à un changement précis. Si le point de départ est un modèle dense déjà entraîné, son coût de préentraînement appartient au bilan lorsque vous comparez des budgets complets.
Notre proposition pour un essai d’ingénierie est de figer les données, leur découpage en tokens, la longueur des séquences, les tokens par mise à jour et le protocole d’évaluation. Les réglages d’optimisation peuvent ensuite être ajustés de façon documentée pour chaque architecture. Cela inclut le taux d’apprentissage, qui règle l’ampleur des corrections des poids. Une valeur identique peut convenir à un modèle et mal convenir à l’autre.
Lire une trace : transfert, attente ou petits calculs ?
Une trace d’exécution représente les calculs et les communications par des barres sur une chronologie, pour chaque rang. Elle permet de voir qui travaille pendant qu’un autre attend. Si les processus entrent à des instants différents dans un échange, la durée affichée peut inclure cette attente. La largeur d’une barre all-to-all ne mesure donc pas uniquement le temps passé à transporter des octets.
En revenant à notre scénario, l’enquête consiste à rapprocher la fin des calculs de GPU 0, les compteurs de tokens et les échanges qui suivent. Si le rang chargé arrive tard et que les autres l’attendent, l’équilibrage ou le placement est une piste. Si les charges sont comparables mais que les transferts restent longs, la topologie et le dispatcher deviennent prioritaires.
Pour ce diagnostic, une distribution artificiellement équilibrée peut servir de contrôle. Elle modifie la décision du modèle et ne valide donc pas sa qualité. Une baisse du temps d’étape montre seulement la marge associée à ce changement de répartition, avec ses effets sur la taille des calculs et les échanges.
Les opérations locales comptent également. Il faut regrouper les tokens par expert, exécuter leurs multiplications matricielles puis restaurer l’ordre. L’expression Grouped GEMM désigne l’exécution groupée de plusieurs multiplications de matrices. Regrouper ces calculs aide à occuper le GPU lorsqu’un expert seul reçoit trop peu de tokens. La documentation MoE de Megatron Core décrit ces optimisations et leurs contraintes. Une petite opération peut laisser des unités de calcul inoccupées même lorsque toutes ses données sont déjà sur la carte.
Faire rentrer le travail sans déplacer le problème
Pendant l’entraînement, la mémoire conserve les poids, le suivi de l’optimiseur et les activations nécessaires pour calculer les gradients. Elle contient aussi des buffers, des zones temporaires utilisées pour les échanges et les calculs. Dans notre scénario, les nombreuses entrées de GPU 0 peuvent demander plus de place que celles de ses voisins. Relevez le pic de chaque rang : une moyenne satisfaisante n’empêche pas la carte la plus chargée de manquer de mémoire. Distinguez l’espace utilisé par les tableaux de nombres, les tenseurs, de celui que le gestionnaire de mémoire réserve pour les allocations présentes ou futures.
La recomputation évite de garder certaines activations et les recalcule lorsque la rétropropagation en a besoin. L’offloading les transfère temporairement vers la RAM de la machine, puis les rapporte au GPU. La première méthode ajoute du calcul ; la seconde ajoute des transferts entre CPU et GPU. Le rapport technique de Megatron Core examine ces compromis avec les optimisations de communication et de calcul. Une économie de mémoire doit donc se mesurer avec son effet sur le temps d’étape.
Le recouvrement, ou overlap, essaie de faire avancer un calcul indépendant pendant une communication, pour éviter une période d’attente. Il peut nécessiter de conserver plusieurs lots et leurs buffers en même temps. La configuration de Megatron précise que certains recouvrements du parallélisme d’experts augmentent le pic mémoire. Accélérer une étape par ce moyen peut donc dépasser la mémoire disponible.
Le traitement de la capacité change aussi l’apprentissage. Si un expert ne peut accepter qu’un nombre fixe d’affectations, les suivantes peuvent être supprimées de son calcul. Dans notre exemple, un plafond de 1 024 laisserait 2 048 affectations excédentaires sur le premier expert, alors que d’autres experts disposent encore de place. Cela supprime la contribution de cet expert pour les affectations écartées, sans nécessairement supprimer le token de tout le modèle. MegaBlocks regroupe le travail en blocs adaptés aux charges variables pour éviter cette suppression et le remplissage de tous les experts jusqu’à une taille fixe. Une recette dite dropless conserve les affectations, dont le travail doit toujours tenir en mémoire et être exécuté.
Choisir le parallélisme à partir des trajets
Étendre le groupe d’experts sur davantage de GPU peut réduire le nombre de poids conservés par carte, mais fait circuler les activations entre davantage de destinations. La frontière entre liens rapides internes au nœud et réseau inter-nœuds mérite donc d’apparaître dans le relevé de configuration.
Les autres parallélismes n’organisent pas le même travail. Le parallélisme tensoriel fait calculer différentes parties d’une opération matricielle à plusieurs GPU. Celui de pipeline répartit les groupes de couches entre cartes, et celui de données fait traiter des lots différents à des copies du modèle, qui synchronisent leurs gradients. Une configuration combine ces dimensions sous la contrainte du nombre total de GPU et de la mémoire disponible. MoE Parallel Folding propose de configurer séparément le parallélisme de l’attention et des experts, car ces blocs n’ont pas les mêmes besoins.
Changer la taille et le nombre des experts, leur placement et le groupe de communication en même temps rendrait l’explication du résultat difficile. Notre recommandation est de partir d’une configuration supportée, puis de tester un changement cohérent à la fois en conservant les traces et les évaluations. Un placement efficace sur une machine ne prédit pas son résultat sur huit machines reliées par le réseau.
Le résultat à rechercher : le temps jusqu’à une qualité définie
Un débit élevé montre que le système traite rapidement des tokens. Il faut encore vérifier combien de tokens sont nécessaires pour apprendre ce qui vous intéresse. Dans un exemple hypothétique, une recette qui traite deux fois plus de tokens par seconde mais en demande trois fois plus pour atteindre le même résultat prendrait une fois et demie plus de temps de calcul. Ce rapport ne compte pas les évaluations, sauvegardes et interruptions, qui s’ajoutent au temps total.
Fixez donc l’objectif avant de choisir le gagnant. La perte de validation mesure l’erreur sur des textes qui ne servent pas à ajuster les poids ; des évaluations complémentaires vérifient les tâches qui vous intéressent. Fixez aussi un plafond de ressources, puis rapportez les tokens traités, le temps écoulé, les GPU mobilisés et les reprises après interruption. Les GPU-heures comptabilisent le nombre de GPU multiplié par leur durée d’utilisation ; elles ne rendent pas équivalents deux matériels différents.
L’étude MOSAIC formalise cette relation en associant un modèle prédictif de qualité à un modèle de performances calibré sur le système. Son résultat ne remplace pas une mesure sur votre cluster, mais rappelle pourquoi le meilleur choix sous un budget d’opérations peut changer sous une contrainte de temps et de mémoire.
Notre lecture du guide Hugging Face conduit à une décision pratique : gardez une référence matérielle et une référence d’apprentissage avant d’empiler les optimisations. Examinez la charge des experts quand les rangs attendent ; examinez les transferts quand les charges sont comparables ; examinez les petits kernels et la mémoire quand les liens n’expliquent plus le temps perdu. Une fois le modèle entraîné, le service des MoE pose une autre question de batch et de réseau, avec une charge et des contraintes de latence différentes.
Sources et méthode
Analyse documentaire réalisée le 8 novembre 2026. Le guide Hugging Face a été examiné à la révision ef70726e6f8b99d74298a16a4894340f288a58c2. Son environnement épingle Megatron à d6316eb45bf1bfbb6f1f848c0b56e55166564d80. Les documentations marquées latest ont été consultées à cette date et peuvent évoluer.
Les faits d’architecture et d’apprentissage sont vérifiés dans Mixtral, Switch Transformers, OLMoE, Auxiliary-Loss-Free Load Balancing et Demons in the Detail. Les mécanismes système sont documentés par DeepEP, NCCL Tests, DCGM, MegaBlocks, Megatron Core et Parallel Folding. MOSAIC apporte le cadre de comparaison entre qualité, ressources et temps.
La pondération 0,75/0,25, la répartition sur quatre GPU, le calcul de 32 Mio et la comparaison entre débit et volume de données sont des exemples pédagogiques calculés. Le scénario distribué suppose huit experts de même coût, un top-2 et un stockage sur deux octets par valeur. Ces exemples ne sont ni des mesures réseau ni des prédictions de débit. Le parcours de diagnostic et le protocole de comparaison sont notre recommandation d’ingénierie, fondée sur les mécanismes sourcés.
