🤖 machine learning

Systematic Exploration of 4-Expert Heterogeneous Mixture-of-Experts via Automated Pipeline Search

Cet article présente un pipeline automatisé pour explorer des architectures hétérogènes de type mélange d'experts à 4 experts au sein du jeu de données LEMUR, révélant un biais critique d'énumération alphabétique qui a limité l'espace de recherche aux combinaisons centrées sur AirNet tout en identifiant ShuffleNet et MobileNetV3 comme les partenaires optimaux pour des ensembles de haute précision.

Auteurs originaux : Yashkumar R Lukhi, Harsh Rameshbhai Moradiya, Radu Timofte, Dmitry Ignatov

Publié 2026-06-24

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Yashkumar R Lukhi, Harsh Rameshbhai Moradiya, Radu Timofte, Dmitry Ignatov

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 êtes un chef essayant de créer la « super-soupe » ultime. Vous avez un garde-manger (le jeu de données LEMUR) rempli de 29 types différents de bouillons pré-faits (comme du poulet, du bœuf, du légume, etc.). Votre objectif est de mélanger exactement quatre de ces bouillons pour voir quelle combinaison a le meilleur goût.

Ce document décrit un robot chef qui a essayé de faire cela automatiquement, mais qui a rencontré une erreur amusante qui a changé les résultats. Voici l'histoire de ce qui s'est passé, décomposée simplement.

1. L'Objectif : Construire une « Super-Soupe »

Dans le monde de l'IA, un Mixture-of-Experts (MoE) est comme une équipe de spécialistes. Au lieu d'un seul cerveau géant essayant de résoudre un problème, vous avez quatre cerveaux plus petits et différents travaillant ensemble.

La Tâche : Le robot devait choisir 4 « cerveaux » d'IA (architectures) différents parmi les 29 options du garde-manger et les mélanger en une seule équipe.
Le Calcul : Il existe 23 751 façons différentes de choisir 4 cerveaux parmi 29. C'est beaucoup de recettes de soupe à tester !

2. La Cuisine du Robot Chef

Les chercheurs ont construit une cuisine automatisée (un pipeline) pour accomplir ce travail sans aide humaine.

Le Générateur : Un script robotique qui écrit le code pour les nouvelles recettes de soupe. Il ne se contente pas de deviner ; il assemble soigneusement le code comme un jeu de Lego.
Le Contrôle de Sécurité : Avant de cuisiner, le robot vérifie la recette trois fois :
1. La grammaire est-elle correcte ? (Vérification de la syntaxe)
2. Est-ce que la marmite rentre sur la cuisinière ? (Test CPU pour voir si la taille convient)
3. Avons-nous déjà fait cette soupe ? (Vérification des doublons)
La Cuisson : Si la recette passe l'étape, elle part sur une cuisinière très puissante (une carte graphique NVIDIA RTX 4090) pour cuire pendant seulement un jour (un époque d'entraînement). Le but n'était pas de faire une soupe parfaite, mais de trouver les combinaisons les plus prometteuses rapidement.

3. La Grande Erreur : Le Piège de l'« Alphabétique »

Le robot chef était censé essayer toutes les 23 751 combinaisons. Cependant, il a commis une erreur critique dans sa façon de choisir les ingrédients.

Le robot a reçu l'ordre de choisir les combinaisons par ordre alphabétique.

Imaginez que votre garde-manger est trié par ordre alphabétique. Le tout premier article est « AirNet ».
Le robot a commencé à choisir des recettes. Il a d'abord choisi toutes les combinaisons possibles incluant « AirNet ».
Comme il existe tellement de façons de mélanger « AirNet » avec trois autres ingrédients, le robot a passé tout son temps à fabriquer des soupes à base d'« AirNet ».
Le Résultat : Après 28 jours de cuisine, il avait testé 1 146 recettes. Mais devinez quoi ? Chacune d'entre elles incluait « AirNet ».
Il n'a même pas essayé une seule soupe qui ne contenait pas AirNet. Il n'a exploré que 4,8 % du total des recettes possibles. C'était comme un chef qui ne ferait que des soupes à base de « Poulet » et ne testerait jamais une soupe à base de « Bœuf », simplement parce que le « Poulet » arrive en premier sur la liste.

4. Ce Qu'ils Ont Découvert (À l'intérieur de la « Zone AirNet »)

Même s'ils n'ont regardé que les soupes à base d'« AirNet », ils ont quand même trouvé des choses intéressantes :

Les Meilleurs Ingrédients : Lorsque « AirNet » était mélangé à ShuffleNet ou MobileNetV3, la soupe avait le meilleur goût (précision la plus élevée). Ces deux-là étaient les « épices secrètes » qui faisaient bien fonctionner l'équipe.
Les Mauvais Ingrédients :
- FractalNet : Cet ingrédient était un désastre. Il était si complexe qu'il cassait sans cesse la cuisinière (épuisement de la mémoire). C'était une « impasse ».
- MNASNet : Cet ingrédient ne cassait pas la cuisinière, mais la soupe avait un goût terrible. C'était un ingrédient à « faible rendement » qui faisait baisser les performances de l'équipe.
Le Champion : La meilleure soupe trouvée était un mélange de AirNet + AlexNet + DPN68 + ResNet. Elle a obtenu un score de 68 % sur un test standard (CIFAR-10) en seulement un jour de cuisson.

5. La Leçon Apprise

Les chercheurs ont réalisé que leur robot était biaisé parce qu'il était trop ordonné.

La Correction : Au lieu de choisir les recettes par ordre alphabétique, ils auraient dû mélanger la liste de manière aléatoire avant de commencer. De cette façon, « AirNet » n'apparaîtrait dans environ 14 % des recettes (ce qui est équitable), et ils auraient eu un véritable goût de toutes les combinaisons possibles.

Résumé

Ce qu'ils ont fait : Construit un robot pour mélanger automatiquement 4 modèles d'IA différents afin de trouver la meilleure équipe.
Ce qui a mal tourné : Le robot s'est retrouvé coincé dans une « boucle alphabétique », ne testant que des combinaisons incluant un modèle spécifique (AirNet), manquant ainsi 95 % des possibilités.
Ce qu'ils ont appris : Malgré cette erreur, ils ont découvert que ShuffleNet et MobileNetV3 sont de bons partenaires pour les équipes d'IA, tandis que FractalNet et MNASNet sont de mauvais partenaires.
L'enseignement à retenir : Lorsque vous cherchez les meilleures combinaisons, ne vous contentez pas de suivre l'ordre ; mélangez les choses de manière aléatoire pour éviter de passer à côté des meilleures options.

Le code et la correction de ce « piège alphabétique » ont été publiés pour que d'autres puissent les utiliser, afin que les futurs robots chefs ne commettent pas la même erreur.

Résumé Technique : Exploration Systématique des MoE Hétérogènes à 4 Experts via une Recherche de Pipeline Automatisée

Énoncé du Problème
L'article traite du défi que représente l'exploration de l'immense espace combinatoire des architectures de Mélange d'Experts (MoE) hétérogènes. Plus précisément, il cible la construction d'ensembles MoE à 4 experts (MoE4) en utilisant le jeu de données de réseaux de neurones LEMUR, qui contient 29 familles d'architectures de base distinctes. L'espace de recherche théorique pour la sélection de 4 familles uniques parmi 29 est de $\binom{29}{4} = 23\,751$ combinaisons possibles. Les travaux antérieurs au sein de l'écosystème LEMUR n'avaient conçu manuellement qu'un petit nombre de configurations, laissant la majeure partie de cet espace inexploré. Les auteurs visent à automatiser la découverte d'ensembles hétérogènes performants sans dépendre des Grands Modèles de Langage (LLM) pour la boucle de génération, ce qui avait montré un succès limité dans les scénarios à 2 experts.

Méthodologie
Les auteurs ont développé un pipeline de recherche entièrement automatisé de 28 jours, construit sur le framework NNGPT, comprenant quatre étapes séquentielles :

Construction du Pool d'Experts : Le système interroge la base de données LEMUR pour récupérer 29 familles d'architectures de base établies et entraînées sur CIFAR-10. Il filtre les mutations générées par LLM, les modèles MoE existants et les modèles générés avec un préfixe en minuscules pour garantir un pool propre de familles architecturales distinctes.
Assemblage de Code Déterministe : Un script de génération (AlterHeteroMoE4.py) assemble programmatiquement des modèles MoE4 candidats. Il récupère le code source de quatre familles sélectionnées, renomme les classes pour éviter les collisions, fusionne les imports et instancie un modèle enveloppe (wrapper). L'architecture utilise une HeterogeneousGate (un réseau de routage de type convolutionnel avec mise à l'échelle de température) pour router les entrées. La sortie est une somme pondérée des logits des experts : $y = \sum_{i=1}^{4} g_i(x) \cdot f_i(x)$ . L'entraînement utilise AdamW, l'augmentation par mixup ( $\alpha=0.2$ ), le lissage des étiquettes (label smoothing) et des taux d'apprentissage avec décroissance cosinus (cosine-annealed).
Validation Multi-étapes : Avant l'évaluation sur GPU, les candidats passent par trois filtres :
- Vérification de Syntaxe : La fonction compile() de Python vérifie la correction du code.
- Sonde de Passage Avant (Forward-Pass) sur CPU : Un lot fictif (2, 3, 256, 256) est passé sur le CPU pour détecter les décalages de dimensions que les vérifications de syntaxe ne détectent pas.
- Déduplication de la Base de Données : Une somme de contrôle MD5 garantit qu'aucun modèle en double n'est évalué.
Automatisation de Campagne : Un orchestrateur tolérant aux pannes (CampaignMoE4.py) gère la boucle génération-évaluation sur 197 lots, persiste l'état dans des fichiers JSON, permettant une reprise sécurisée via SSH après interruption, et vise 1 000 évaluations réussies.

Contributions Clés
L'article présente trois contributions d'ingénierie primaires :

Générateur d'Assemblage de Code Déterministe : Un outil qui combine systématiquement des familles de base en modèles MoE4 syntaxiquement valides et vérifiés par passage avant, sans nécessiter d'appels à des LLM, en réutilisant des configurations de routage et d'entraînement éprouvées.
Pipeline de Validation Multi-étapes : Un système de filtrage pré-GPU qui réduit considérablement le gaspillage des ressources de calcul en interceptant les erreurs de syntaxe, les décalages de dimensions dépendants de la résolution et les doublons.
Automatisation de Campagne Tolérante aux Pannes : Un système d'orchestration robuste permettant une exécution autonome de longue durée (28 jours) avec gestion de l'état persistant.

Résultats
La campagne s'est déroulée pendant 28 jours sur un NVIDIA RTX 4090, générant 4 463 modèles candidats et évaluant avec succès 1 021 modèles.

Biais de Couverture de l'Espace de Recherche : Une analyse post-campagne critique a révélé un biais de couverture sévère. En raison de l'utilisation de itertools.combinations sur une liste triée, le générateur a énuméré les combinaisons par ordre lexicographique. Comme "AirNet" est la première par ordre alphabétique, le générateur a épuisé toutes les $\binom{28}{3} = 3\,276$ combinaisons contenant AirNet avant de passer à la famille suivante. La campagne s'est arrêtée à 1 146 combinaisons, ce qui signifie que 100 % de l'espace exploré était ancré à AirNet, ne couvrant que 4,8 % de l'espace de recherche théorique.
Métriques de Performance : Dans le périmètre ancré à AirNet, le meilleur modèle (AirNet + AlexNet + DPN68 + ResNet) a atteint une précision Top-1 de 68,0 % sur CIFAR-10 en un seul époque d'entraînement. La précision moyenne sur les modèles réussis était de 0,5221.
Analyse par Famille :
- Familles à Haut Rendement : ShuffleNet (précision moyenne : 0,632) et MobileNetV3 (précision moyenne : 0,621) ont produit de manière constante les ensembles les plus précis avec des taux de succès >96 %.
- Familles à Faible Rendement : FractalNet n'avait qu'un taux de succès de 0,7 % en raison de fréquentes erreurs de type Out-of-Memory (OOM) et de décalages de forme. MNASNet a systématiquement dégradé la qualité des ensembles (précision moyenne : 0,218).
Analyse des Échecs : 99,7 % des échecs étaient dus à des erreurs CUDA OOM, principalement causées par les exigences de mémoire de la combinaison de quatre réseaux complets à une résolution de 256×256.

Signification et Revendications
L'article affirme que l'assemblage automatisé d'experts hétérogènes peut produire des candidats compétitifs sans réglage manuel, comme en témoigne la précision de 68,0 % obtenue en une seule époque. Cependant, les auteurs sont modestes quant à la généralisabilité des classements de précision spécifiques, notant qu'ils sont conditionnés par la présence d'AirNet en raison du biais de couverture.

La principale contribution scientifique est l'identification d'un angle mort de couverture inhérent aux recherches combinatoires à grande échelle utilisant une énumération déterministe triée avec des conditions d'arrêt basées sur le débit. Les auteurs proposent une solution simple — le mélange aléatoire stratifié (stratified random shuffling) de la liste des combinaisons — pour éliminer ce biais lors de futures exécutions. Ils identifient également des familles architecturales spécifiques (FractalNet, MNASNet) qui devraient être exclues du pool d'experts pour améliorer l'efficacité et la qualité des futures campagnes. Le pipeline, les artefacts d'analyse et le générateur corrigé sont publiés en open-source.