💬 NLP

GEM: GPU-Variability-Aware Expert to GPU Mapping for MoE Systems

GEM est un cadre qui optimise la latence d'inférence des modèles à mélange d'experts (MoE) en mappant les experts sur des GPU en fonction de la variabilité matérielle et des motifs de charge de tokens, atténuant ainsi les effets des ralentisseurs et améliorant les performances de bout en bout jusqu'à 16,5 %.

Auteurs originaux : Sourish Wawdhane, Avinash Kumar, Poulami Das

Publié 2026-05-20

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Sourish Wawdhane, Avinash Kumar, Poulami Das

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous gérez la cuisine d'un restaurant haut de gamme (le cluster GPU) où vous avez une équipe de chefs spécialisés (les Experts) préparant une commande massive de plats pour de nombreux clients à la fois.

Dans un modèle d'IA moderne de type « Mélange d'Experts » (MoE), la cuisine ne dispose pas d'un seul chef géant faisant tout. Au lieu de cela, elle compte de nombreux chefs plus petits et spécialisés. Pour chaque mot généré par l'IA (un « token »), un manager (le Routeur) décide quels deux chefs sont nécessaires pour préparer ce mot spécifique.

Le Problème : La Règle du « Chef le Plus Lent »

Dans cette cuisine, il existe une règle stricte : Toute l'équipe doit attendre que la personne la plus lente termine avant de pouvoir passer à l'étape suivante.

Si vous avez 8 chefs, et que 7 d'entre eux terminent leurs tâches en 10 secondes, mais qu'un chef prend 12 secondes parce qu'il est plus lent ou a trop de travail, toute la cuisine reste bloquée en attendant ces 2 secondes supplémentaires. Dans le monde de l'IA, ce temps d'attente est appelé un « traînard », et il tue la vitesse de l'ensemble du système.

L'article identifie deux raisons principales pour lesquelles un chef devient un traînard :

Mauvaise Attribution : Le manager a accidentellement donné les recettes les plus chargées et les plus populaires à un seul chef, tandis que les autres restaient inactifs.
Variabilité Matérielle : Même si le travail est parfaitement réparti, certains chefs sont naturellement plus lents que d'autres en raison de leur matériel spécifique (comme un four plus ancien ou un bras fatigué). L'article a révélé que, dans un groupe de GPU d'apparence identique, le plus rapide peut être près de 28 % plus rapide que le plus lent.

L'Ancienne Méthode : « Travail Égal, Temps Égal »

Les solutions précédentes tentaient de résoudre ce problème en donnant à chaque chef exactement le même nombre de plats à préparer. Elles pensaient : « Si tout le monde a la même quantité de travail, tout le monde finira en même temps. »

Mais cela échoue car :

Vitesses Différentes : Un chef rapide peut préparer 14 % de plats de plus dans le même laps de temps qu'un chef lent. Si vous leur donnez exactement la même pile de travail, le chef rapide termine en avance et attend, tandis que le chef lent lutte toujours.
Motifs Cachés : Certains chefs sont occupés presque tout le temps (Experts Cohérents), tandis que d'autres ne sont occupés ensemble que lors de courtes et intenses poussées (Experts Temporels). Les anciennes méthodes manquaient ces motifs « par à-coups ». Si deux chefs qui deviennent toujours occupés exactement au même moment sont assignés à la même machine lente, toute la cuisine s'arrête net.

La Nouvelle Solution : GEM (Cartographie des Experts Sensible à la Variabilité des GPU)

Les auteurs proposent GEM, un système intelligent qui agit comme un manager de cuisine génial qui connaît exactement la vitesse de chaque chef et la manière dont les commandes arrivent.

GEM utilise deux astuces ingénieuses :

1. La Stratégie de « Charge Proportionnelle »
Au lieu de donner à tout le monde le même nombre de plats, GEM donne plus de plats aux chefs rapides et moins de plats aux chefs lents.

Analogie : Imaginez une course. Si un coureur est 14 % plus rapide, vous ne lui donnez pas la même distance que le coureur plus lent. Vous lui donnez une piste plus longue afin qu'ils franchissent tous les deux la ligne d'arrivée exactement au même moment.
GEM calcule exactement combien de travail supplémentaire les GPU rapides peuvent gérer afin que tout le monde termine la couche en même temps.

2. La Stratégie du « Détective de Motifs »
GEM observe la cuisine pendant un court moment (juste 16 étapes) pour apprendre deux choses :

Qui est toujours occupé ? (Les Experts Cohérents).
Qui devient occupé ensemble ? (Les Experts Temporels).
Analogie : Si le Chef A et le Chef B reçoivent toujours une énorme vague de commandes en même temps, GEM s'assure qu'ils ne sont pas assignés au même four lent. Il les répartit sur différents postes afin qu'ils ne se bloquent pas mutuellement.

Comment GEM Fonctionne (Le Processus en 4 Étapes)

Observer et Apprendre : GEM observe l'IA pendant un tout petit instant pour voir quels experts sont utilisés et quand.
Tester le Matériel : Il exécute un test rapide pour voir exactement la vitesse de chaque GPU spécifique sous différentes charges. Il le fait intelligemment en testant uniquement à des « jalons » spécifiques (comme vérifier la vitesse d'une voiture tous les 32 miles au lieu de tous les miles) pour gagner du temps.
La Recherche : Il exécute une simulation pour trouver l'arrangement parfait des chefs vers les fours. Il essaie d'échanger les chefs jusqu'à ce qu'il trouve une configuration où le chef « le plus lent » termine aussi vite que possible.
Déploiement : Il verrouille cette nouvelle disposition. L'IA commence à fonctionner, et comme le travail est équilibré pour la vitesse réelle des machines, l'ensemble du système fonctionne plus fluidement.

Les Résultats

Lorsque les auteurs ont testé cela sur cinq modèles d'IA puissants différents :

Boost de Vitesse : L'IA a terminé les tâches 7,9 % plus vite en moyenne.
Meilleur Cas : Dans certaines situations, elle était 16,5 % plus rapide.
Expérience Plus Fluide : La « latence de queue » (les pires retards qui donnent l'impression que l'IA bégaye) s'est améliorée encore davantage, jusqu'à 16,9 %.

En bref, GEM empêche l'IA d'attendre la partie la plus lente du système en donnant plus de travail aux parties rapides et moins aux parties lentes, tout en s'assurant que deux experts « occupés » ne sont pas coincés sur la même machine lente. Il transforme les différences matérielles d'une faiblesse en un outil pour de meilleures performances.

Résumé Technique : GEM – Mappage Expert-GPU Sensible à la Variabilité des GPU pour les Modèles à Mélange d'Experts

1. Énoncé du Problème

Les modèles à Mélange d'Experts (MoE) améliorent l'efficacité de l'inférence en activant uniquement un sous-ensemble de sous-réseaux « experts » par token. Cependant, leurs performances dans les environnements de service réels sont sévèrement limitées par les GPU traîneurs. Dans une exécution synchrone, un lot doit attendre que le GPU le plus lent termine le traitement d'une couche avant de pouvoir continuer.

L'article identifie deux causes principales de traîneurs que les solutions existantes ne parviennent pas à résoudre simultanément :

Déséquilibre des Experts : Certains experts sont utilisés de manière disproportionnée par rapport aux autres. Si ces experts « très utilisés » sont co-localisés sur un seul GPU, ce dernier devient un goulot d'étranglement.
Variabilité Matérielle : Les GPU modernes présentent une variabilité de performance inhérente due aux variations de processus, aux facteurs environnementaux et à la gestion de l'alimentation. Même avec des charges de tokens parfaitement équilibrées, un GPU physiquement plus lent agira comme un traînard.

Les travaux antérieurs tentent de résoudre ce problème soit en introduisant une uniformité artificielle dans l'utilisation des experts (dégradant la précision du modèle), soit en redistribuant dynamiquement les experts (entraînant des surcoûts mémoire). Crucialement, ces approches sont agnostiques de la variabilité matérielle, plaçant souvent les experts très utilisés sur les GPU les plus lents disponibles, perpétuant ainsi le problème des traîneurs.

2. Méthodologie : Cadre GEM

Les auteurs proposent GEM (Mappage d'Experts Sensible à la Variabilité des GPU), un cadre conçu pour mapper les experts vers les GPU en tenant explicitement compte à la fois des charges de tokens spécifiques à la tâche et des caractéristiques de performance matérielle. GEM fonctionne via un pipeline en quatre étapes :

Étape 1 : Trace d'Utilisation des Experts

GEM capture les motifs d'acheminement des tokens d'une tâche spécifique lors de l'inférence en ligne. Il compte le nombre de tokens acheminés vers chaque expert pour construire une trace d'utilisation.

Insight : L'article distingue les experts cohérents (utilisés fréquemment à la plupart des pas de temps) des experts temporels (utilisés rarement mais intensément lors d'éruptions spécifiques et corrélées).
Optimisation : Les expériences montrent qu'une longueur de trace de 16 pas de temps suffit à capturer à la fois les motifs cohérents et temporels sans retarder le déploiement.

Étape 2 : Profilage de la Variabilité de Performance

GEM profile la latence des couches MoE sur différents GPU en fonction de la charge de tokens.

Défi : Un profilage fin (pour chaque nombre de tokens) est trop lent (heures), tandis qu'un échantillonnage grossier manque la nature « en escalier » de la latence MoE (où la latence saute à des tailles de lots spécifiques).
Solution : GEM échantillonne les nombres de tokens uniquement aux limites de tuiles (multiples de 32 ou 64 tokens, là où les sauts de latence se produisent). Cela réduit le temps de profilage de plusieurs heures à quelques minutes (par exemple, 3 minutes pour Llama-4-Scout) tout en maintenant la précision.

Étape 3 : Mappage d'Experts Sensible à la Variabilité

GEM utilise une recherche heuristique itérative pour trouver le mappage optimal expert-GPU.

Fonction de Score : Au lieu d'équilibrer les nombres de tokens, GEM minimise la somme des latences des traîneurs sur tous les pas de temps. Le score $S(M)$ est calculé comme suit :
$S(M) = \sum_{t \in T} \max_{g} (C_g(n_g(M, t)))$
Où $C_g$ est le coût de latence pour le GPU $g$ étant donné le nombre de tokens $n_g$ , dérivé des profils de variabilité.
Insights Clés Appliqués :
1. Équilibrage de Charge Non Uniforme : Les GPU plus rapides se voient attribuer proportionnellement plus de tokens que les GPU plus lents afin que tous les GPU terminent le traitement d'une couche à peu près au même moment.
2. Gestion des Corrélations : GEM détecte les experts temporels corrélés (experts utilisés simultanément lors d'éruptions) et s'assure qu'ils sont placés sur des GPU différents. De plus, il évite de placer ces experts à forte charge sur les GPU les plus lents.
Algorithme de Recherche : Le système commence avec plusieurs mappages initiaux (en ajoutant du bruit aux métriques d'utilisation pour assurer la diversité) et échange itérativement des paires d'experts pour réduire le score total de latence des traîneurs jusqu'à convergence.

Étape 4 : Déploiement

Une fois le mappage optimal déterminé, GEM charge les poids des experts sur leurs GPU assignés au moment du chargement du modèle. Le routeur MoE continue d'acheminer les tokens comme d'habitude, mais l'emplacement physique des experts est désormais optimisé pour le cluster matériel spécifique.

3. Contributions Clés

Identification des Goulots d'Étranglement Doubles : L'article met en évidence que les traîneurs résultent de la combinaison d'une utilisation non uniforme des experts et d'une variabilité matérielle inhérente des GPU, un problème négligé par les méthodes d'équilibrage statiques ou dynamiques antérieures.
Cadre GEM : Le premier cadre à effectuer un mappage d'experts sensible à la variabilité matérielle pour les modèles MoE.
Stratégie de Mappage Nouvelle :
- Équilibrage Basé sur la Latence : Passage d'une distribution égale des tokens à une distribution proportionnelle basée sur la vitesse du GPU.
- Détection d'Experts Temporels : Identification et séparation des experts temporels corrélés pour éviter les pics de charge simultanés sur des GPU uniques.
Profilage Efficace : Une stratégie d'échantillonnage aux limites de tuiles qui capture les profils de variabilité matérielle en quelques minutes plutôt qu'en heures.

4. Résultats Expérimentaux

Les auteurs ont évalué GEM sur cinq modèles MoE de pointe (Mixtral-8x7B, Mixtral-8x22B, Llama-4-Scout, Hunyuan-A13B, Qwen3-30B-A3B) en utilisant les jeux de données ShareGPT et CodeContests. Ils ont émulé trois niveaux de variabilité GPU (Faible, Modéré, Élevé) sur un nœud à 4 GPU.

Latence de Bout en Bout : GEM a amélioré la latence d'une moyenne de 7,9 % et jusqu'à 16,5 % par rapport à la ligne de base (mappage linéaire par défaut de vLLM).
- Les configurations à variabilité élevée ont enregistré les gains les plus significatifs (jusqu'à 16,5 %).
- Même dans les configurations à faible variabilité, GEM a apporté des améliorations (jusqu'à 4,5 %) en optimisant pour les experts temporels corrélés.
Latence de Queue (p90 TPOT) : GEM a réduit le temps par token de sortie au 90e percentile d'une moyenne de 9,1 % (jusqu'à 16,9 %), améliorant considérablement la réactivité perçue.
Surcharge de Profilage : Le processus de profilage de variabilité et de mappage prend moins de 4 minutes au total, ce qui est négligeable par rapport aux heures ou jours d'inférence servis en production.

5. Signification et Revendications

L'article revendique que GEM est le premier cadre de mappage d'experts sensible à la variabilité matérielle pour l'inférence MoE. Sa signification réside dans la transformation de la variabilité matérielle d'un inconvénient en une contrainte de mappage qui peut être exploitée pour améliorer les performances.

Les auteurs soulignent que :

Équilibrer simplement les nombres de tokens est insuffisant car cela ignore l'hétérogénéité matérielle.
Ignorer les experts temporels (qui sont souvent corrélés) conduit à des mappages sous-optimaux même si les charges moyennes sont équilibrées.
À mesure que les échelles du système augmentent (par exemple, de 4 à 64 GPU), l'écart entre les GPU les plus rapides et les plus lents s'élargit de manière monotone, rendant le mappage sensible à la variabilité de plus en plus critique pour les déploiements à grande échelle.

Ce travail démontre qu'en alignant le placement des experts à la fois sur la nature statistique de l'acheminement des tokens et sur la réalité physique des performances des GPU, des réductions significatives de latence peuvent être obtenues sans réentraîner les modèles ni engendrer de surcoûts mémoire substantiels.