Élagage d’experts MoE : préserver leurs coopérations
Découvrez HOPE, une méthode d’élagage des modèles MoE qui tient compte des coopérations entre experts pour réduire la mémoire sans sacrifier les performances.
Réduire un modèle MoE sans casser les coopérations entre experts
Les modèles à mélange d'experts (MoE) n'activent qu'une partie de leurs paramètres pour traiter chaque token. Ça diminue le calcul nécessaire par requête, mais pas forcément l'empreinte mémoire côté déploiement : les experts que le routeur peut choisir doivent rester disponibles, même quand ils ne sont pas sollicités à chaque étape. Le sujet devient vite concret quand on veut héberger un modèle plus gros, rallonger la fenêtre de contexte, ou absorber plus de requêtes sans changer le budget matériel.
Une première idée consiste à supprimer définitivement les experts jugés les moins utiles. Le hic, c'est que les méthodes classiques évaluent souvent les experts un par un. Or, dans un MoE, certains experts contribuent vraiment « en équipe » : retirer un expert peut affaiblir le fonctionnement de ceux qui coopéraient avec lui. HOPE, une méthode proposée par Amazon, vise justement à intégrer cette dépendance dans la décision d'élagage. Dans cet article, on va passer par le problème mémoire, le principe de HOPE, ses résultats expérimentaux, puis la manière de le tester et de l'implémenter - sans oublier les limites et les vérifications à faire avant un déploiement en production.
Pourquoi l'élagage des experts est devenu un enjeu
Le coût mémoire ne suit pas toujours le coût de calcul
Dans un MoE, une couche regroupe plusieurs réseaux experts et un mécanisme de routage. Pour chaque token, le routeur sélectionne les experts qui contribueront à la sortie. Le modèle n'utilise donc pas forcément tous ses paramètres à chaque token, mais, dans une configuration « classique », les poids de tous les experts doivent être chargés et accessibles pendant l'inférence.
Du coup, réduire les paramètres actifs ne suffit pas toujours à faire rentrer le modèle dans la mémoire disponible sur les accélérateurs. Dans certains cas, les poids des experts pèsent lourd : l'exemple donné pour Qwen3.5-122B utilise 256 experts par couche, sur 48 couches MoE, et environ 95 % des quelque 250 Go de paramètres sont attribués aux réseaux experts. Pour un token, le modèle n'en sélectionne pourtant que huit par couche.
On peut quantifier pour réduire la taille des poids, mais ça ne règle pas forcément tout. Le chargement dynamique des experts est une autre piste, mais les transferts entre mémoire et accélérateur peuvent ajouter de la latence et rendre le comportement plus dur à stabiliser. L'élagage, lui, supprime des experts du checkpoint : on réduit la mémoire d'inférence sans exiger un mécanisme de chargement à la volée.
Supprimer un expert, c'est aussi modifier le routage
Élaguer un expert ne revient pas juste à « effacer un bloc de poids ». Si un expert censé être sélectionné pour un token n'est plus là, le routeur doit faire appel à un expert de remplacement, parmi ceux qui auraient eu les scores suivants. La sortie de la couche change donc pour deux raisons : l'expert disparaît, et la liste des experts effectivement activés peut aussi changer.
Les méthodes dites de premier ordre attribuent en général un score individuel à chaque expert (calculé à partir d'un jeu de calibration), puis suppriment les experts les moins bien classés, couche par couche. Ça marche souvent quand on élague à faible dose - et l'approche est simple à expliquer. Mais elle repose sur une hypothèse implicite : l'importance d'un expert serait à peu près indépendante de celle des autres.
Cette hypothèse se fissure quand plusieurs experts sont activés ensemble de manière récurrente. Dans ce cas, retirer un expert « isolé » peut sembler raisonnable, tout en cassant un groupe qui fonctionne bien. Et quand on augmente le taux d'élagage, le risque de retirer plusieurs membres d'une même coopération augmente aussi : c'est précisément là que le classement indépendant peut sous-estimer le coût réel.
À retenir : diminuer les paramètres actifs ne garantit pas de réduire autant la mémoire. Et réduire la mémoire en supprimant des experts oblige à regarder l'impact sur le routage, pas seulement la valeur individuelle de chaque expert.
Comment HOPE tient compte des coopérations
Passer du score individuel à une matrice d'interactions
HOPE signifie Higher-Order Pruning of Experts. L'idée est de choisir l'ensemble des experts à retirer en tenant compte des interactions entre paires d'experts. Le point de départ, c'est la variation de sortie causée par l'élagage : sur chaque token du jeu de calibration, les experts supprimés qui auraient été sélectionnés sont remplacés par d'autres experts disponibles. L'objectif idéal serait de minimiser directement l'erreur générée par ces remplacements.
Sauf qu'il devient difficile de calculer l'optimum directement : la meilleure sélection dépend de l'ensemble supprimé, donc de quels experts de remplacement seront activés. HOPE contourne ce problème avec une fonction de substitution qui vise à majorer la partie dominante de l'erreur. En développant cette fonction, on obtient des termes qui décrivent les contributions individuelles, mais aussi des termes croisés entre paires d'experts.
Ces informations sont regroupées dans une matrice F construite à partir des données de calibration. Chaque case reflète, en moyenne, le produit des sorties pondérées par les poids de routage lorsque deux experts sont activés ensemble. La diagonale correspond à la contribution individuelle estimée. Les valeurs hors diagonale capturent les interactions entre experts.
En pratique, ça change la lecture d'un score. Un expert peut avoir un score individuel élevé, mais être surtout utile parce qu'il « s'entend » avec des experts qu'on garde. À l'inverse, un expert très bien classé pris seul peut être moins intéressant si sa contribution devient redondante quand ses partenaires sont retirés. HOPE ne cherche donc pas uniquement à conserver les experts « les plus forts » au sens individuel : il cherche un ensemble dont les contributions restent utiles ensemble.
Résoudre une sélection sous contrainte
Avec un budget donné, HOPE reformule la sélection comme un problème quadratique : choisir quels experts supprimer pour minimiser un coût estimé à partir de la matrice F. La formulation n'est pas convexe. L'implémentation décrite fait une relaxation continue, puis arrondit le résultat pour obtenir une sélection binaire (une liste concrète d'experts à supprimer).
Le déroulé se résume à trois actions :
- Mesurer les activations, les poids du routeur, les normes de sortie et les co-activations sur des données représentatives.
- Construire et résoudre le problème quadratique pour le taux d'élagage choisi.
- Supprimer les experts sélectionnés et enregistrer un nouveau checkpoint.
La calibration fait toute la différence. Des traces de code, des conversations ou des trajectoires d'agents ne sollicitent pas les mêmes chemins dans le modèle. Il faut donc choisir des exemples proches des tâches réellement servies. Et il faut surtout distinguer calibration et réentraînement : HOPE ne met pas à jour les poids conservés.
Le surcoût mentionné par rapport à une méthode de premier ordre vient surtout de la résolution du problème quadratique. L'article parle d'un ordre d'une à deux secondes par couche pour cette étape, mais le passage de calibration reste généralement le poste dominant. Et ce chiffre ne remplace pas une mesure sur votre configuration : architecture, matériel et implémentation changent la donne.
Quels résultats HOPE obtient-il
Un gain plus visible quand le taux d'élagage augmente
L'évaluation porte sur trois modèles : Qwen3.5-122B, Qwen3.5-35B et GLM-4.5-Air. Les auteurs utilisent deux jeux de calibration : l'un orienté code, l'autre basé sur des trajectoires SWE-Bench Verified. Ils comparent HOPE à quatre méthodes de premier ordre : REAP, MAN, EAN et Frequency. Les taux d'élagage testés vont de 10 % à 50 %.
Sur l'ensemble des conditions, HOPE obtient le meilleur rang moyen, à 2,07 sur cinq méthodes, et arrive en tête dans 39 % des cas. L'avantage augmente quand on élague plus : à 50 % d'élagage, son rang moyen atteint 1,58, contre 2,42 pour la méthode suivante, REAP. Le résultat suit assez bien la logique attendue : plus on retire d'experts, plus préserver des groupes coopératifs devient décisif.
L'écart se voit particulièrement sur SWE-Bench Pro, un benchmark de résolution autonome de problèmes logiciels. Sur Qwen3.5-35B-A3B élagué à 50 %, HOPE obtient 42,3, contre 41,8 pour le modèle non élagué. REAP affiche 36,2. C'est un signal intéressant pour les usages agentiques, où les tâches s'enchaînent avec du raisonnement, des appels d'outils et plusieurs étapes successives.
Cela dit, il ne faut pas lire « égal ou mieux que la référence » comme une règle générale. L'article signale que des modèles élagués peuvent parfois égaler ou dépasser le modèle d'origine sur des tâches précises - par exemple quand la suppression d'experts peu pertinents réduit du bruit pour cette tâche. Ce n'est pas exclusif à HOPE, et ça ne prouve pas que le modèle sera meilleur partout.
Le gain vient du choix des partenaires, pas seulement du classement
Comparer HOPE à REAP aide à comprendre d'où vient l'amélioration. Les valeurs de la diagonale de la matrice F retrouvent presque exactement les classements d'experts de REAP, à cause de la variance des contributions. Autrement dit : si on ne regardait que la diagonale, on tomberait sur une logique proche d'un classement individuel.
La différence se joue surtout sur les valeurs hors diagonale. Quand HOPE et REAP ne conservent pas les mêmes experts, ceux retenus par HOPE uniquement ont, dans l'analyse rapportée, des scores de coopération plus élevés avec les experts déjà conservés. En clair : HOPE accepte parfois de « sacrifier » un expert bien noté individuellement pour préserver un groupe plus cohérent.
Pour une équipe produit, le point n'est pas de copier aveuglément le meilleur score moyen d'un benchmark. Il faut regarder les tâches prioritaires, les écarts de qualité, la mémoire consommée et la stabilité des résultats. Un gain sur le code agentique ne suffit pas à décider si le modèle convient à un assistant généraliste, à un service client, ou à un outil interne soumis à des exigences de conformité.
Comment tester HOPE sur un modèle
Une procédure en trois étapes
Le paquet HOPE décrit dans l'article a été testé sur Qwen3, Qwen3-Next, Qwen3.5 et GLM-4.5. Le flux de travail inclut la calibration, la résolution de la sélection, puis la création du checkpoint élagué. Les commandes ci-dessous montrent la procédure avec un modèle Qwen3.5 ; elles ne remplacent pas la vérification des dépendances et des options spécifiques à votre version.
1. Calibrer le modèle
hope calibrate \
--model-path Qwen/Qwen3.5-35B-A3B \
--prompts calibration_prompts.txt \
--out-path observations.h5
Cette étape lance un passage sur les prompts de calibration. Des hooks observent les couches MoE et enregistrent notamment les experts sélectionnés, leurs poids de routage, les normes de sortie et les co-activations. Les observations sont stockées en HDF5 pour la suite du traitement.
2. Résoudre le problème d'élagage
hope solve \
--obs-path observations.h5 \
--prune-frac 0.50 \
--out-path pruneset.json
Le paramètre --prune-frac 0.50 demande de supprimer 50 % des experts concernés. Commencer par là n'a rien d'obligatoire : produire plusieurs sélections à des taux différents aide à tracer la courbe entre mémoire économisée et qualité sur vos tâches.
3. Créer le checkpoint réduit
hope prune \
--model-path Qwen/Qwen3.5-35B-A3B \
--pruneset-path pruneset.json \
--out-path ./Qwen3.5-35B-A3B-pruned-50
Le résultat est présenté comme un checkpoint standard compatible avec l'écosystème Hugging Face, sans changement nécessaire des définitions de modèle côté vLLM ou SGLang. C'est pratique, mais ça ne dispense pas de vérifier le chargement, le format, le temps de démarrage, et le comportement avec la version de serveur retenue.
Construire un protocole d'évaluation utile
Une validation sérieuse doit comparer le modèle original à plusieurs variantes élaguées, avec le même matériel et les mêmes paramètres d'inférence. Au minimum, mesurez :
- la mémoire réellement utilisée, au chargement et pendant l'inférence ;
- la latence, le débit et les erreurs de chargement ;
- les performances sur des tâches représentatives de la production ;
- la robustesse sur des entrées difficiles ou inhabituelles ;
- l'effet du taux d'élagage sur la qualité et le coût d'exploitation.
Séparez le mieux possible jeu de calibration et jeu d'évaluation. Sinon, vous risquez de surestimer la qualité : les données qui servent à mesurer les activations peuvent aussi « aider » la sélection. Et si vous opérez en Europe, il faut aussi choisir et traiter les données de calibration en respectant les obligations applicables, notamment sur la confidentialité et le RGPD si des données personnelles sont impliquées.
Enfin, un déploiement progressif reste la voie la plus sûre : d'abord hors ligne, puis test sur un trafic limité, puis montée en charge si la qualité et les métriques opérationnelles restent acceptables. L'élagage réduit la taille du modèle, mais ne transforme pas à lui seul une expérimentation en service fiable.
Quelles sont les limites et les décisions à prendre
HOPE traite un problème précis : choisir les experts à supprimer dans chaque couche à partir d'interactions observées pendant la calibration. Ça reste utile, mais ça ne « résout » pas tout le reste de la complexité d'un modèle de langage.
Première limite : l'avantage est plus net autour de 40-50 % d'élagage. À 10-20 %, des méthodes de premier ordre comme REAP ou MAN peuvent rester compétitives. Si votre objectif est d'enlever peu d'experts, la complexité supplémentaire de HOPE peut ne pas se justifier - surtout si le temps d'ingénierie et la validation sont limités.
Deuxième limite : chaque couche est optimisée indépendamment. Or, ce que vous décidez dans une couche peut changer les activations et les besoins plus loin. Les auteurs évoquent une approche croisée entre couches, mais indiquent que les résultats restent préliminaires. Présenter HOPE comme une optimisation globale de toute l'architecture serait donc exagéré.
Troisième limite : HOPE capture les relations par paires, pas les interactions impliquant trois experts (ou plus). Les effets d'ordre supérieur peuvent compter, mais les estimer devient vite coûteux et combinatoire. La matrice F est donc un compromis : plus riche qu'un score individuel, mais moins exhaustive qu'une modélisation complète des groupes.
Enfin, un benchmark ne prédit pas automatiquement le comportement produit. Le niveau de quantification, le serveur d'inférence, les longueurs de contexte, la répartition réelle des requêtes et les outils utilisés peuvent changer les compromis. La méthode à choisir dépend donc d'une décision opérationnelle :
- Élagage faible et priorité à la simplicité : commencez par une méthode de premier ordre, puis mesurez le gain réel.
- Élagage important et tâches complexes en jeu : testez HOPE en comparaison, car les coopérations peuvent devenir déterminantes.
- Qualité critique ou données très variées : élargissez la validation avant de supprimer des experts de façon définitive.
- Mémoire déjà contrainte surtout par quantification : comparez le bénéfice marginal de l'élagage à son risque sur la qualité.
La bonne question n'est donc pas « quelle méthode gagne en général ? », mais « quelle sélection respecte notre budget mémoire sans abîmer les usages qui comptent ? ». HOPE propose une manière plus structurée d'aborder cette question quand les interactions entre experts ont un vrai impact opérationnel.
Conclusion
L'élagage des experts peut réduire directement l'empreinte mémoire d'un modèle MoE, mais les méthodes qui évaluent chaque expert isolément ratent une partie du fonctionnement réel du routage. HOPE apporte une matrice d'interactions pour choisir les suppressions en tenant compte des coopérations par paires. D'après les résultats rapportés, la méthode devient surtout intéressante quand le taux d'élagage est élevé et que les tâches mobilisent des combinaisons variées d'experts.
Pour autant, HOPE n'est pas une solution universelle. Le choix de la calibration, les benchmarks, le taux de suppression et les contraintes du serveur déterminent ce que vous verrez réellement. La démarche raisonnable est de comparer plusieurs méthodes et plusieurs taux sur vos usages de production, puis d'arbitrer entre mémoire économisée, qualité et complexité d'exploitation. C'est cette mesure - pas seulement le score d'un benchmark - qui permet de décider si l'élagage vaut le coup pour votre modèle.