Mélange d'Experts (MoE)

L'Essentiel

Ce qu’il faut retenir :

1. Quoi : MoE est une architecture où un modèle contient plusieurs “experts” spécialisés, mais seuls 2-4 sont activés par token.
2. Pourquoi : Un modèle de 100B paramètres peut avoir un coût d’inférence de 20B, divisant les coûts par 5.
3. Comment : Un “router” apprend à sélectionner les experts les plus pertinents pour chaque entrée.

Ce que vous saurez dans 3 minutes

• Décideurs : Comprendre pourquoi MoE permet des modèles massifs à coût d’inférence réduit.
• Experts Techniques : Maîtriser le fonctionnement du router, du load balancing et des trade-offs mémoire/compute.
• Opérationnels : Identifier quand MoE est avantageux vs modèles denses pour vos déploiements.

---

1. Comprendre

L’architecture Mixture of Experts n’est pas nouvelle – elle date des années 1990. Mais son application aux LLM modernes, popularisée par Mixtral (Mistral AI) et GPT-4 (rumeur), a révolutionné l’équation économique des grands modèles.

Définition

Définition

Le Mixture of Experts (MoE) est une architecture de réseau de neurones composée de plusieurs “experts” (sous-réseaux spécialisés) et d’un “router” (gating network) qui sélectionne dynamiquement un sous-ensemble d’experts pour traiter chaque entrée, réduisant ainsi le coût de calcul par rapport à un modèle dense équivalent.

Contexte & Enjeux

Le déclencheur : Le coût exponentiel de l’inférence pour les modèles toujours plus grands. GPT-4 coûterait des millions par jour en compute si tous ses paramètres étaient utilisés pour chaque token.

Le risque : Sans MoE, le scaling des LLM atteint une limite économique. Seuls les hyperscalers pourraient se permettre l’inférence.

L’Analogie de l’Hôpital

Imaginez un hôpital avec 8 médecins spécialistes. Un patient n’a pas besoin de consulter les 8 à chaque visite :

• Modèle Dense : Tous les 8 médecins examinent chaque patient → coûteux, lent
• Modèle MoE : Un triage (router) oriente vers 2 spécialistes pertinents → efficace, rapide

---

2. Appliquer

Architecture MoE

flowchart TD
    subgraph "Couche MoE"
        INPUT[Token Input] --> ROUTER{Router<br/>Gating Network}
        
        ROUTER -->|Score 0.6| E1[Expert 1<br/>FFN]
        ROUTER -->|Score 0.4| E3[Expert 3<br/>FFN]
        
        E2[Expert 2] -.->|Score 0.1| ROUTER
        E4[Expert 4] -.->|Score 0.05| ROUTER
        E5[Expert 5-8] -.->|Scores faibles| ROUTER
        
        E1 --> COMBINE[Weighted<br/>Combination]
        E3 --> COMBINE
        
        COMBINE --> OUTPUT[Token Output]
    end
    
    style E1 fill:#51cf66,stroke:#2b8a3e
    style E3 fill:#51cf66,stroke:#2b8a3e
    style E2 fill:#dee2e6,stroke:#868e96
    style E4 fill:#dee2e6,stroke:#868e96
    style E5 fill:#dee2e6,stroke:#868e96
    style ROUTER fill:#339af0,stroke:#1864ab

Comparaison Dense vs MoE

Modèle Dense

Caractéristiques :

• Tous les paramètres activés pour chaque token
• Compute = Paramètres
• Simple à entraîner et déployer

Métrique	Valeur
Paramètres	70B
Compute/token	70B params
Mémoire GPU	~140 GB (FP16)

Exemples : Llama 3 70B, Claude 3

Modèle MoE

Caractéristiques :

• Seuls 2-4 experts activés par token
• Compute bien inférieur aux Paramètres totaux
• Plus complexe (load balancing, memory)

Métrique	Valeur
Paramètres totaux	176B
Paramètres actifs	39B (~22%)
Mémoire GPU	~352 GB (tous les experts)

Exemples : Mixtral 8x22B, GPT-4 (rumeur), DeepSeek-V2

Le Fonctionnement Détaillé

1. Le Router Calcule les Scores Pour chaque token, un petit réseau “gating” calcule un score de pertinence pour chaque expert.

   G(x) = Softmax(Wg · x)

2. Sélection Top-K Experts Seuls les K experts avec les scores les plus élevés (généralement K=2) sont activés.

3. Calcul Parallèle Les experts sélectionnés traitent l’input en parallèle sur différents GPU/cores.

4. Combinaison Pondérée Les sorties des experts sont combinées selon leurs scores de routing.

   y = Σ (pour i dans TopK) Gi(x) · Ei(x)

Implémentation Simplifiée

import torch
import torch.nn as nn
import torch.nn.functional as F

class SimpleMoELayer(nn.Module):
    def __init__(self, input_dim, hidden_dim, num_experts=8, top_k=2):
        super().__init__()
        self.num_experts = num_experts
        self.top_k = top_k

        # Router (gating network)
        self.router = nn.Linear(input_dim, num_experts)

        # Experts (chacun est un FFN)
        self.experts = nn.ModuleList([
            nn.Sequential(
                nn.Linear(input_dim, hidden_dim),
                nn.GELU(),
                nn.Linear(hidden_dim, input_dim)
            )
            for _ in range(num_experts)
        ])

    def forward(self, x):
        # Calcul des scores de routing
        router_logits = self.router(x)  # (batch, seq, num_experts)
        router_probs = F.softmax(router_logits, dim=-1)

        # Sélection Top-K
        top_k_probs, top_k_indices = torch.topk(router_probs, self.top_k, dim=-1)
        top_k_probs = top_k_probs / top_k_probs.sum(dim=-1, keepdim=True)  # Renormalisation

        # Calcul des experts sélectionnés (simplifié)
        output = torch.zeros_like(x)
        for k in range(self.top_k):
            expert_idx = top_k_indices[..., k]
            weight = top_k_probs[..., k:k+1]
            # En pratique, batch par expert pour efficacité
            for i in range(self.num_experts):
                mask = (expert_idx == i)
                if mask.any():
                    output[mask] += weight[mask] * self.experts[i](x[mask])

        return output

Trade-offs MoE

Avantage	Limite
✅ Inférence économique	❌ Mémoire totale élevée (tous les experts en RAM)
✅ Capacité massive	❌ Entraînement plus complexe (load balancing)
✅ Spécialisation naturelle	❌ Communication inter-GPU
✅ Scaling efficace	❌ Latence batch faible

---

3. Aller plus loin

Load Balancing : Le Défi Clé

Sans régulation, certains experts deviennent “populaires” et se voient attribuer la majorité des tokens, tandis que d’autres restent inutilisés. Solutions :

• Auxiliary Loss : Pénalité encourageant une distribution équilibrée
• Noise dans le routing : Exploration forcée pendant l’entraînement
• Expert Parallelism : Répartition des experts sur plusieurs GPU

Points de vigilance

Pièges fréquents

• Mémoire ≠ Compute : MoE économise du compute mais pas de la mémoire GPU (tous les experts chargés).
• Batch Size Minimum : Les MoE sont moins efficaces sur les petits batches (routing overhead).
• Inférence compliquée : Le déploiement distribué est plus complexe qu’un modèle dense.

Modèles MoE Majeurs

Modèle	Config	Params Totaux	Params Actifs
Mixtral 8x7B	8 experts, top-2	46.7B	12.9B
Mixtral 8x22B	8 experts, top-2	176B	39B
DeepSeek-V2	160 experts, top-6	236B	21B
GPT-4 (rumeur)	8 experts	~1.8T	~200B
Grok-1	8 experts	314B	~80B

---

Questions Fréquentes

Pourquoi GPT-4 serait-il un MoE ?

Des analyses de latence et de comportement suggèrent que GPT-4 n’utilise pas tous ses paramètres à chaque requête. OpenAI n’a jamais confirmé, mais le consensus de la communauté pointe vers un MoE de ~8 experts, chacun de ~200B paramètres.

MoE rend-il les modèles plus interprétables ?

Potentiellement. Les experts se spécialisent naturellement (langue, domaine, type de raisonnement). Analyser quel expert est activé peut donner des insights sur le traitement. Mais ce n’est pas une garantie d’interprétabilité.

Puis-je fine-tuner un modèle MoE ?

Oui, mais c’est plus complexe. Il faut gérer le routing pendant le fine-tuning. Des techniques comme LoRA sur les experts fonctionnent. Mixtral est fine-tunable via les outils standards (HuggingFace, Axolotl).

---

Notions Liées (Spider Web)

• Implémentations : Mistral AI, DeepSeek
• Concepts Liés : Transformer, LLM
• Optimisations : Quantification, Distillation

Ressources Externes

• Paper : Outrageously Large Neural Networks (Google, 2017)
• Tutorial : HuggingFace MoE Guide