Mixture of Experts (MoE)

Mixture of Experts (MoE) désigne une architecture de réseau de neurones dans laquelle une couche dense classique est remplacée par un ensemble de sous-réseaux spécialisés, appelés experts, dont seul un petit sous-ensemble est activé pour chaque token traité. Le modèle possède donc un très grand nombre de paramètres totaux, mais n'en mobilise qu'une fraction — les paramètres actifs — à chaque passe d'inférence. Cette dissociation entre capacité et coût de calcul est ce qui permet aujourd'hui d'entraîner et de servir des LLM de plusieurs centaines de milliards de paramètres à un coût compatible avec un usage en production, y compris pour des cas d'usage cyber (analyse de logs, triage d'alertes, rétro-ingénierie assistée).

Fonctionnement technique

Dans un Transformer classique, chaque bloc alterne une couche d'attention et un réseau feed-forward (FFN) dense. Dans un Transformer MoE, ce FFN est dupliqué en N experts (8, 64, 256 selon les modèles) et précédé d'un routeur (ou gating network) : une petite couche linéaire qui, pour chaque token, produit un score par expert, puis sélectionne les top-k meilleurs (typiquement k=1 ou k=2). Seuls ces experts calculent, et leurs sorties sont combinées par une somme pondérée par les scores du routeur.

• Routage par token, pas par requête : deux tokens d'une même phrase peuvent emprunter des experts différents. La « spécialisation » émerge de l'entraînement et reste largement non interprétable.
• Capacité d'expert : pour paralléliser, chaque expert dispose d'un buffer de taille fixe par batch. Au-delà, les tokens excédentaires sont droppés (ignorés ou passés en résiduel). Ce détail d'implémentation a des conséquences de sécurité majeures (voir plus bas).
• Perte d'équilibrage (load balancing loss) : un terme de régularisation ajouté pendant l'entraînement pour éviter que le routeur ne concentre tout le trafic sur quelques experts (expert collapse).
• Contrainte mémoire : tous les experts doivent résider en VRAM même s'ils sont peu utilisés. Un MoE économise du calcul, pas de la mémoire.

Exemples concrets

• Mixtral 8x7B (Mistral AI) : 8 experts, top-2, ~47 Md de paramètres totaux pour ~13 Md actifs — coût d'inférence d'un modèle 13B, qualité proche d'un 70B.
• DeepSeek-V3 / R1 : routage fin-grained avec experts partagés, ~671 Md totaux pour ~37 Md actifs.
• Switch Transformer (Google) : le travail fondateur qui a popularisé le top-1 routing à grande échelle.
• La plupart des modèles frontier propriétaires actuels sont, selon les indices publics disponibles, des architectures MoE.

Implications de sécurité

Le MoE introduit des surfaces d'attaque absentes des modèles denses, précisément parce que le chemin de calcul dépend des données.

• Fuite inter-utilisateurs par canal auxiliaire : c'est le risque le plus spécifique. Comme la capacité d'expert s'évalue au niveau du batch, la sortie produite pour un utilisateur peut dépendre des tokens soumis par les autres utilisateurs du même batch. Des travaux académiques (notamment sur l'Expert-Choice Routing et la gestion des égalités de score) ont montré qu'un attaquant capable de remplir un batch peut, en observant les tokens droppés de sa propre requête, reconstruire progressivement le prompt d'une victime. C'est une violation directe de l'isolation entre tenants — un modèle de menace familier à quiconque a traité les vulnérabilités de type side-channel sur CPU partagé (Spectre, Meltdown, hyperthreading).
• Déni de service par saturation d'expert : des entrées adverses conçues pour router massivement vers un même expert créent un point chaud, dégradent la latence et peuvent amplifier le coût de calcul — une variante applicative de l'algorithmic complexity attack.
• Empoisonnement ciblé : lors d'un fine-tuning ou d'un entraînement distribué, un adversaire peut chercher à corrompre un expert particulier ou à manipuler le routeur pour installer une porte dérobée conditionnelle, difficile à détecter car dormante tant qu'un déclencheur ne route pas vers l'expert compromis.
• Fingerprinting et exfiltration de propriété intellectuelle : les motifs de latence liés au routage permettent d'inférer des caractéristiques architecturales du modèle servi.

Bonnes pratiques

• Isoler les batches par tenant ou, à défaut, garantir un routage indépendant du batch. C'est la contre-mesure principale contre les fuites inter-utilisateurs.
• Préférer les implémentations à routage déterministe et sans drop (dropless MoE) pour les déploiements multi-tenants sensibles.
• Randomiser l'ordre des tokens dans le batch pour casser les dépendances exploitables au tri et aux égalités.
• Instrumenter la distribution de charge par expert et alerter sur les déséquilibres anormaux : c'est un signal de détection exploitable, à intégrer aux tableaux de bord SIEM au même titre que n'importe quelle métrique applicative.
• Appliquer les contrôles habituels de rate limiting et de quotas, qui limitent la capacité d'un attaquant à remplir un batch.
• Traiter les poids des experts comme un actif : contrôle d'intégrité par signature, chaîne d'approvisionnement vérifiée, et validation systématique des modèles téléchargés depuis des dépôts publics.

En résumé, le MoE est un levier d'efficacité désormais standard dans les LLM de grande taille, mais son principe même — un chemin de calcul conditionné par les données et partagé entre requêtes concurrentes — en fait un objet à évaluer avec les réflexes de l'analyse de canaux auxiliaires et de l'isolation multi-tenant, et non uniquement sous l'angle de la qualité des réponses.