> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tokios.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Tokios exposes private local models through https://api.tokios.com using an outbound-only connector tunnel.
> Use 'connector' for the local tokios-connector process.
> Use 'deployment' for the public model name in the API model field.
> Use 'upstream model id' for the model served by Ollama, llama.cpp, vLLM, LM Studio, or another local backend.
> API keys use the prefix sk-tok-. Connector tokens use the prefix ct-tok-.

# Mixture of Experts (MoE) : routage, parallélisme d'experts et mémoire

> Comprenez le Mixture of Experts (MoE) : fonctionnement du routage, pourquoi la mémoire évolue avec le nombre total de paramètres, et quels modèles open-weight utilisent le MoE. Inclut des formules de dimensionnement et un guide matériel.

Un modèle **Mixture of Experts (MoE)** fonctionne comme un grand modèle mais n'utilise qu'une petite fraction de ses poids à chaque jeton généré. Cette séparation — capacité totale énorme, calcul par jeton réduit — est la raison pour laquelle la dernière génération de modèles frontier open-weight est passée au MoE. C'est aussi la raison pour laquelle un modèle comme DeepSeek-V3 avec 671B de paramètres totaux n'en active que 37B par jeton, tout en nécessitant suffisamment de mémoire pour contenir l'ensemble des 671B. Cette page explique le fonctionnement du routage, ce que le parallélisme d'experts implique pour le serving, et comment dimensionner le matériel pour les modèles MoE.

> [!NOTE]
>
> Last verified: 2026-10-14

## Qu'est-ce que le Mixture of Experts

Dans un transformer **dense** standard, chaque jeton traverse chaque couche et active tous les paramètres à chaque passe avant. Un modèle dense de 70B utilise l'intégralité des 70B paramètres pour chaque jeton.

Un modèle MoE remplace la sous-couche feed-forward de certaines couches transformer par plusieurs **experts** sous-réseaux en parallèle et un **routeur** (aussi appelé **réseau de portes**) qui décide quels experts traitent chaque jeton. La plupart des experts restent inactifs pour un jeton donné. Un modèle avec 256 experts peut n'en activer que 8 par jeton — environ 3% de sa capacité totale par étape.

Le résultat :

* **Paramètres totaux** : déterminent la mémoire nécessaire au modèle (tous les experts doivent rester chargés).
* **Paramètres actifs** : déterminent le coût de calcul par jeton (seuls les experts sélectionnés s'exécutent).

C'est l'arbitrage fondamental. Le MoE vous offre la capacité de connaissance d'un très grand modèle pour le coût de calcul par jeton d'un modèle beaucoup plus petit — mais vous devez quand même payer la facture mémoire pour chaque expert, qu'il s'active ou non.

## Comment fonctionne le routage MoE

Chaque couche MoE contient un routeur qui sélectionne quels experts traitent chaque jeton. L'approche la plus courante dans les modèles en production est le **gating top-k** :

1. Le routeur calcule un score pour chaque expert en multipliant l'état caché du jeton par une matrice de poids apprise, puis applique un softmax pour produire une distribution de probabilité sur tous les experts.
2. Les k experts avec les scores les plus élevés sont sélectionnés. Leurs sorties sont combinées en utilisant les poids normalisés par softmax comme coefficients.
3. Tous les autres experts ne produisent aucune sortie pour ce jeton — ils sont entièrement ignorés.

La valeur de k varie selon le modèle. DeepSeek-V3 et Qwen3 utilisent k=8. gpt-oss utilise k=4. Kimi K3 utilise 16 experts routés plus 2 experts partagés par jeton.

### Experts partagés

Certaines architectures réservent un sous-ensemble d'**experts partagés** qui s'activent pour chaque jeton, indépendamment des scores de routage. Les experts partagés gèrent les patterns communs (bases de la modélisation du langage, formatage) afin que les experts routés puissent se spécialiser. Qwen3-Next utilise 1 expert partagé plus 10 experts routés. Kimi K3 utilise 2 experts partagés plus 16 experts routés. DeepSeek-V3 et le MoE Qwen3 original n'utilisent pas d'experts partagés — tous les experts actifs sont sélectionnés par le routeur.

### Équilibrage de charge

Un routeur qui envoie toujours les jetons aux mêmes quelques experts annule l'intérêt du MoE : ces experts deviennent des goulots d'étranglement tandis que les autres restent inactifs. Les modèles en production utilisent plusieurs stratégies pour maintenir une utilisation équilibrée des experts :

* **Perte auxiliaire** — une pénalité à l'entraînement qui pousse le routeur vers une utilisation uniforme des experts. La plupart des premiers modèles MoE (Switch Transformer, ST-MoE) utilisent cette approche. Le coût est une légère réduction de la spécialisation : le routeur optimise l'équilibre en même temps que la qualité.
* **Équilibrage de charge sans perte auxiliaire** — DeepSeek-V3 a introduit une approche basée sur des biais qui ajuste les biais de routage par expert à l'inférence. Si un expert reçoit plus de jetons que sa part cible, son biais diminue, ce qui réduit sa probabilité d'être sélectionné. Cela élimine entièrement le compromis qualité des pertes auxiliaires.
* **Stable LatentMoE** — Kimi K3 utilise un mécanisme de routage latent appris qui produit des affectations d'experts plus stables entre les jetons, réduisant la variance qui cause le déséquilibre de charge dans le gating top-k standard.

Ce qu'il faut retenir : l'équilibrage de charge se résout à l'entraînement, pas au serving. En tant qu'utilisateur exécutant un modèle MoE localement, vous ne configurez pas le routage — vous configurez la mémoire et le parallélisme.

## Pourquoi la mémoire MoE évolue avec les paramètres totaux, pas les actifs

C'est le point le plus important à comprendre avant d'exécuter un modèle MoE localement.

**Tous les experts doivent résider en mémoire en permanence.** Le routeur décide dynamiquement — par jeton, par couche — quels experts activer. Il n'y a aucun moyen de savoir à l'avance quels experts une invite donnée nécessitera, donc chaque expert doit être chargé et prêt. Swapper des experts depuis le disque à la demande est bien trop lent pour une inférence interactive.

Cela signifie que la formule de mémoire de [Mémoire et délestage](/fr/concepts/memory-and-offloading.md) s'applique aux **paramètres totaux**, pas aux actifs :

```text theme={"theme":{"light":"github-light","dark":"css-variables"}}
VRAM(GB) ≈ total_params(B) × bytes-per-param × 1.2
```

Les paramètres actifs n'affectent que le calcul par jeton (et donc la vitesse de génération), pas la mémoire.

### Exemples détaillés

| Model | Total params | Active params | Experts (active/total) | Memory at 4-bit (\~0.5 B/param) | Memory at 8-bit (\~1 B/param) |
| - | - | - | - | - | - |
| DeepSeek-V3 / R1 | 671B | 37B | 8 of 256 | \~403 GB | \~805 GB |
| Kimi K2 | 1T | 32B | 8 of 384 | \~600 GB | \~1,200 GB |
| Kimi K3 | 2.8T | 104B | 16+2 of 896 | \~1,680 GB | \~3,360 GB |
| Qwen3-30B-A3B | 30.5B | 3.3B | 8 of 128 | \~18 GB | \~37 GB |
| Qwen3-235B-A22B | 235B | 22B | 8 of 128 | \~141 GB | \~282 GB |
| Qwen3.8-2.4T-A95B | 2.4T | 95B | 10+1 of 512 | \~1,440 GB | \~2,880 GB |
| GLM-5.3 | 753B | \~40B | Not publicly specified | \~452 GB | \~904 GB |
| gpt-oss-20b | 21B | 3.6B | 4 of 32 | \~13 GB | \~25 GB |
| gpt-oss-120b | 117B | 5.1B | 4 of 128 | \~70 GB | \~140 GB |

Le facteur 1.2x couvre le cache KV, les activations et la surcharge du framework pour une longueur de contexte modeste — la même formule que pour les modèles denses. Consultez [Mémoire et délestage](/fr/concepts/memory-and-offloading.md) pour la dérivation complète du dimensionnement.

### Ce que cela signifie en pratique

Un Qwen3-30B-A3B a 30.5B de paramètres totaux mais seulement 3.3B actifs. Il génère des jetons à peu près à la vitesse d'un modèle dense de 3.3B — mais il a besoin de mémoire pour l'ensemble des 30.5B. En 4 bits, cela fait environ 18 Go, ce qui tient dans un GPU de 24 Go. Un modèle dense de 30B en 4 bits aurait besoin d'environ la même mémoire mais générerait les jetons plus lentement, car il traite tous les 30B paramètres par jeton au lieu de 3.3B.

À l'inverse, Kimi K3 a 2.8T de paramètres totaux et 104B actifs. Il génère des jetons à peu près à la vitesse d'un modèle dense de 104B — mais il a besoin d'environ 1.4 To de mémoire rien que pour les poids en 4 bits. Aucun matériel grand public ou prosumer ne peut contenir cela.

## MoE vs modèles denses

| | Dense | MoE |
| - | - | - |
| **Parameters per token** | All parameters | Only active parameters (a fraction of total) |
| **Memory** | Scales with total parameters | Scales with total parameters (same formula) |
| **Compute per token** | Scales with total parameters | Scales with active parameters only |
| **Generation speed** | Limited by total parameter count | Limited by active parameter count — often much faster than a dense model of the same total size |
| **Knowledge capacity** | Limited by total parameters | Total parameters can be much larger for the same per-token compute |
| **Hardware requirement** | Must fit total parameters | Must fit total parameters (not active) |
| **Multi-GPU serving** | Tensor parallelism splits layers | Expert parallelism splits experts across GPUs |

L'essentiel : le MoE dissocie la capacité de connaissance du calcul par jeton. Un MoE de 671B paramètres avec 37B actifs peut égaler ou dépasser un modèle dense de 70B en qualité tout en générant des jetons à peu près à la vitesse d'un 70B — mais il a besoin de 671B de mémoire.

## Parallélisme d'experts : servir du MoE sur plusieurs GPUs

Quand un modèle MoE ne tient pas sur un seul GPU, vous devez le distribuer. Le **parallélisme d'experts** est la stratégie spécifique au MoE pour y parvenir :

* Chaque GPU détient un sous-ensemble des experts totaux. Dans un modèle de 256 experts réparti sur 8 GPUs, chaque GPU détient 32 experts.
* Pendant la passe avant, les décisions du routeur déterminent quels jetons doivent être envoyés à quel GPU. Les jetons routés vers des experts sur le GPU 3 sont communiqués au GPU 3 pour traitement, puis les résultats reviennent.
* Les couches non-experts (attention, embeddings) sont généralement réparties avec le **parallélisme de tenseurs** standard, où chaque GPU détient une tranche des matrices de poids de chaque couche.

Les runtimes de serving en production comme vLLM et TensorRT-LLM combinent le parallélisme de tenseurs pour les couches d'attention avec le parallélisme d'experts pour les couches MoE. Le résultat s'appelle le **parallélisme mixte**. La documentation vLLM couvre la configuration en détail ; le paramètre clé est que le parallélisme d'experts est un axe de parallélisme distinct du parallélisme de tenseurs.

L'implication pratique : les modèles MoE bénéficient d'interconnexions à haut débit entre les GPUs (NVLink, InfiniBand) car les jetons doivent se déplacer entre les GPUs lors de l'étape de routage. Un cluster connecté uniquement par PCIe subira des pénalités de vitesse significatives dues à la communication inter-GPU.

## Quels modèles open-weight utilisent le MoE

La génération actuelle de modèles frontier open-weight s'est massivement orientée vers le MoE. Voici le paysage en octobre 2026 :

### Moins de 50B total (exécutables sur 1-2 GPUs grand public en 4 bits)

| Model | Total | Active | Experts | Active per token | License |
| - | - | - | - | - | - |
| gpt-oss-20b | 21B | 3.6B | 32 | 4 | Apache 2.0 |
| Qwen3-30B-A3B | 30.5B | 3.3B | 128 | 8 | Apache 2.0 |

### 50B-250B total (multi-GPU ou systèmes unifiés à haute mémoire)

| Model | Total | Active | Experts | Active per token | License |
| - | - | - | - | - | - |
| gpt-oss-120b | 117B | 5.1B | 128 | 4 | Apache 2.0 |
| Qwen3-235B-A22B | 235B | 22B | 128 | 8 | Apache 2.0 |

### Plus de 250B total (matériel serveur requis)

| Model | Total | Active | Experts | Active per token | License |
| - | - | - | - | - | - |
| DeepSeek-V3 / R1 | 671B | 37B | 256 | 8 | MIT (V3), custom (R1) |
| GLM-5.3 | 753B | \~40B | MoE | MoE | Custom (see [GLM-5.3](/fr/models/glm-5.3.md)) |
| Kimi K2 | 1T | 32B | 384 | 8 | Custom |
| Qwen3.8-2.4T-A95B | 2.4T | 95B | 512 | 10+1 shared | Apache 2.0 |
| Kimi K3 | 2.8T | 104B | 896 | 16+2 shared | Custom |
| DeepSeek V4.1-Flash | 552B | 8B in / 16B out | MoE | Asymmetric | MIT |

Sources : fiches modèles sur HuggingFace et rapports techniques officiels liés ci-dessous.

## Ce qu'il faut retenir pour l'inférence locale

Le MoE change la signification des chiffres sur une fiche modèle :

* **Paramètres actifs** : indiquent la vitesse de génération du modèle. Un MoE de 671B avec 37B actifs génère à peu près à la vitesse de 37B.
* **Paramètres totaux** : indiquent la mémoire nécessaire au modèle. Ce même MoE de 671B a besoin de 671B de VRAM, pas 37B.
* **Nombre d'experts et routage** : sont des détails d'architecture qui affectent la qualité et l'efficacité de l'entraînement, mais en tant qu'utilisateur d'inférence locale, vous ne les configurez pas — vous configurez la mémoire et le parallélisme.

Quand vous voyez un modèle MoE annoncé comme "2.4T paramètres, 95B actifs", lisez : "génère à la vitesse de 95B, a besoin de 2.4T de mémoire." Dimensionnez votre matériel pour le total, profitez de la vitesse du nombre actif.

Utilisez le [guide d'adéquation modèle-GPU](/fr/guides/model-fit.md) pour vérifier si un modèle MoE spécifique et une quantification donnée tiennent sur votre matériel avant de télécharger.

## Approfondir

> **[Memory and offloading](/fr/concepts/memory-and-offloading.md)**
>
> La formule complète de dimensionnement, y compris les octets par paramètre par précision et les mécanismes de délestage.

> **[Quantization](/fr/concepts/quantization.md)**
>
> Réduisez les octets par paramètre pour modifier l'équation mémoire des modèles MoE et denses.

> **[How inference works](/fr/concepts/how-inference-works.md)**
>
> Pourquoi le décodage est limité par la bande passante mémoire et comment les paramètres actifs affectent la vitesse de génération.

> **[Model serving and scaling](/fr/concepts/model-serving-and-scaling.md)**
>
> Stratégies de parallélisme, serving multi-GPU, et comment les runtimes distribuent les modèles.

## Modèles utilisant le MoE

> **[Kimi K3](/fr/models/kimi-k3.md)**
>
> 2.8T total, 104B actifs, 896 experts avec routage Stable LatentMoE.

> **[DeepSeek](/fr/models/deepseek.md)**
>
> V3/R1 à 671B/37B, V4.1-Flash à 552B avec activation asymétrique 8B/16B.

> **[Qwen3](/models/qwen3)**
>
> Niveaux MoE 30B-A3B et 235B-A22B, 128 experts avec routage top-8.

> **[Qwen3.8](/fr/models/qwen3.8.md)**
>
> Flagship 2.4T avec 95B actifs, 512 experts, 10 routés + 1 partagé.

> **[GLM-5.3](/fr/models/glm-5.3.md)**
>
> 753B total, \~40B actifs, MoE avec contexte 1M.

> **[gpt-oss](/models/gpt-oss)**
>
> 20b (32 experts) et 120b (128 experts), routage top-4, Apache 2.0.

## Une fois que ça tient et que ça tourne

Charger un modèle MoE sur votre matériel est la première étape. Une fois qu'il répond aux requêtes sur `localhost`, l'étape suivante est d'y accéder depuis n'importe où.

> **[Give it a stable endpoint](/fr/quickstart.md)**
>
> Tokios ne choisit, n'héberge ni n'affine le modèle — une fois qu'il tourne localement, Tokios le transforme en un endpoint stable et authentifié que vous pouvez appeler de n'importe où.

## Questions fréquentes

> **Why does an MoE model need memory for all experts if only a few are active?**
>
> Le routeur sélectionne des experts différents pour chaque jeton, donc chaque expert doit être accessible. À tout moment, seuls k experts s'activent, mais le jeton suivant pourrait nécessiter un ensemble complètement différent. Cela signifie que tous les poids des experts doivent rester en mémoire (VRAM ou RAM) en permanence — vous dimensionnez par les paramètres totaux, pas les paramètres actifs.

> **How do I know if my hardware can run an MoE model?**
>
> Calculez : paramètres totaux × octets par poids. En 4 bits (le plancher de quantification native pour la plupart des modèles MoE), c'est `total_params × 0.5 GB`. Ajoutez 20% pour le cache KV et la surcharge. Si ce nombre tient dans votre VRAM + RAM combinées, le modèle se charge. S'il ne tient pas, aucune optimisation ne change cela — il vous faut plus de mémoire ou un modèle plus petit.

> **What is the difference between shared experts and routed experts?**
>
> Les experts partagés sont actifs sur chaque jeton — ils gèrent les tâches communes comme la modélisation du langage. Les experts routés sont sélectionnés par jeton par le réseau de portes. DeepSeek-V3 utilise 256 experts routés avec 8 actifs et pas d'experts partagés. Kimi K3 utilise 896 experts avec 16 routés + 2 partagés. Qwen3.8 utilise 512 experts avec 10 routés + 1 partagé.

> **Can I run an MoE model on a single GPU?**
>
> Seulement les petits. Qwen3-30B-A3B (30.5B total, \~18 Go en 4 bits) tient dans un GPU de 24 Go. gpt-oss-20b (21B total, \~13 Go en 4 bits) tient aussi. Tout ce qui dépasse \~50B de paramètres totaux nécessite soit du serving multi-GPU (vLLM, SGLang avec parallélisme d'experts), soit un système à mémoire unifiée élevée (Mac Studio, DGX Spark) avec délestage CPU.

> **What is expert parallelism and when do I need it?**
>
> Le parallélisme d'experts répartit les couches d'experts sur plusieurs GPUs — le GPU 0 détient les experts 0-63, le GPU 1 détient les experts 64-127, etc. Chaque GPU calcule les sorties de ses experts et elles sont combinées via une communication all-to-all. Vous en avez besoin quand les poids totaux des experts ne tiennent pas sur un seul GPU. vLLM et SGLang le supportent tous les deux ; consultez le [guide d'optimisation vLLM](/fr/guides/vllm-optimization.md) pour la configuration.

## Sources

* [DeepSeek-V3 Technical Report](https://arxiv.org/abs/2412.19437) — 671B total, 37B active, 256 experts, auxiliary-loss-free load balancing.
* [Kimi K2: Open Agentic Intelligence](https://arxiv.org/abs/2507.20534) — 1T total, 32B active, 384 experts, 8 active per token.
* [Kimi K3 model card](https://huggingface.co/moonshotai/Kimi-K3) — 2.8T total, 104B active, 896 experts, Stable LatentMoE.
* [Qwen3 Technical Report](https://arxiv.org/abs/2505.09388) — 128 experts, 8 active, no shared experts in Qwen3 MoE.
* [Qwen3-Next-80B-A3B](https://qwen.ai/blog?id=4074cca80393150c248e508aa62983f9cb7d27cd) — 512 experts, 10 routed + 1 shared.
* [Qwen3.8-Max announcement](https://qwen.ai/blog?id=qwen3.8) — 2.4T total, 95B active, 512 experts.
* [gpt-oss model card](https://arxiv.org/abs/2508.10925) — 32 experts (20b) and 128 experts (120b), 4 active per token.
* [GLM-5.3 model card](https://huggingface.co/zai-org/GLM-5.3) — 753B total, \~40B active.
* [Mixture of Experts Explained (localaimaster.com)](https://localaimaster.com/blog/mixture-of-experts-explained) — Routing mechanics and memory implications.
* [Mixture-of-Experts LLMs (Cameron R. Wolfe)](https://cameronrwolfe.substack.com/p/moe-llms) — Top-k gating formulation and training dynamics.
* [MoE training in Qwen3-235B and Kimi-K2](https://medium.com/clickbait-programming/moe-training-in-qwen3-235b-a22b-and-kimi-k2-c51f582d2ef5) — Learned routing comparison.
* [vLLM MoE Playbook](https://rocm.blogs.amd.com/software-tools-optimization/vllm-moe-guide/README.html) — Expert parallelism and mixed parallelism configuration.
* [Expert Parallelism in TensorRT-LLM](https://nvidia.github.io/TensorRT-LLM/advanced/expert-parallelism.html) — Multi-GPU expert distribution strategies.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.