Accueil › Glossaire › Capacity Factor

Capacity Factor (MoE)

Le capacity factor est un hyperparamètre des modèles Mixture-of-Experts (MoE) qui définit le nombre maximum de tokens qu’un expert individuel peut traiter par batch, en multipliant la répartition théorique uniforme par un facteur de marge. Les tokens excédentaires sont soit redirigés, soit ignorés (token dropping).

Pourquoi le capacity factor existe

Dans un modèle sparse MoE, un réseau de routage (router) décide pour chaque token quel expert le traite. Si les N experts se répartissaient les T tokens de façon parfaitement uniforme, chaque expert recevrait exactement T/N tokens. En pratique, c’est rarement le cas : certains tokens sont plus « difficiles » ou plus « courants » et attirent systématiquement les mêmes experts.

Le problème est concret et technique. Sur les architectures modernes (TPU, GPU), les formes des tenseurs sont déterminées statiquement à la compilation. Le framework doit réserver un buffer mémoire fixe pour chaque expert avant de savoir combien de tokens il recevra. Si un expert reçoit plus de tokens que prévu, les excédents ne peuvent tout simplement pas être traités : ils « overflow ».

C’est là qu’intervient le capacity factor. Il définit la taille de ce buffer par expert, en multipliant la répartition uniforme théorique par un facteur de marge. Un capacity factor de 1,25 signifie que chaque expert peut traiter 25 % de tokens en plus que ce que la distribution parfaitement équilibrée prévoirait.

La formule

Prenons un exemple concret. Avec un batch de 2 048 tokens et 8 experts, la répartition uniforme donne 256 tokens par expert. Avec un capacity factor de 1,25 : chaque expert peut traiter jusqu’à 320 tokens (256 × 1,25). Le buffer est donc dimensionné à 320 emplacements par expert.

Pour un routage top-k (où chaque token est envoyé à k experts), la formule s’ajuste en conséquence. Le nombre total de « assignations » passe de T à T × k, et la capacité par expert devient :

Expert Capacity = (T × k / N) × CF

Par exemple, avec un routage top-2 sur le même batch : (2 048 × 2 / 8) × 1,25 = 640 tokens par expert.

Le token overflow et le token dropping

Quand un expert reçoit plus de tokens que sa capacité ne le permet, il se passe l’une de ces deux choses :

Token dropping. Les tokens excédentaires sont « droppés » : ils ne sont pas traités par la couche MoE et passent directement à la couche suivante via la connexion résiduelle. En d’autres termes, le vecteur de représentation du token traverse la couche feed-forward sans modification. Ce n’est pas catastrophique grâce à l’architecture résiduelle des Transformers (le token ne « disparaît » pas), mais c’est une perte d’information : ce token n’a pas bénéficié de la computation de l’expert pour cette couche.

Redirection vers un autre expert. Dans certaines implémentations, notamment avec le routage top-2 de GShard, si le premier expert est à capacité, le token peut être redirigé vers le second expert. Si les deux sont saturés, le token est droppé.

Illustration des trois scénarios

Le compromis fondamental

Le capacity factor incarne un compromis direct entre trois dimensions :

Qualité du modèle. Un CF plus élevé réduit le nombre de tokens droppés, ce qui améliore la qualité. Les expériences du Switch Transformer montrent une amélioration nette de la loss quand le CF passe de 1,0 à 1,25. Le ST-MoE confirme que des CF plus élevés (1,5, 2,0) continuent d’améliorer la qualité, mais avec des rendements décroissants.

Coût mémoire et compute. Chaque point de CF augmente la taille des buffers d’activation par expert, ce qui consomme plus de mémoire GPU. Un CF de 2,0 signifie que chaque expert réserve le double de la mémoire nécessaire pour une distribution uniforme. En pratique, cela augmente aussi le compute (les experts traitent plus de tokens) et les coûts de communication dans les architectures distribuées.

Latence en entraînement distribué. Quand les experts sont répartis sur différents devices (expert parallelism), un CF élevé augmente le volume de données échangées entre les nœuds. Si les interconnexions sont lentes, un CF plus faible est préférable malgré le risque de token dropping.

Valeurs recommandées par les papiers de référence

Les travaux fondateurs convergent sur un ensemble de recommandations pratiques :

Switch Transformer (Fedus et al., 2022). Avec un routage top-1, le Switch Transformer fonctionne bien à CF = 1,0 et 1,25. Le papier note que le Switch Transformer surpasse les MoE classiques (top-2) à des capacity factors plus faibles, grâce à un meilleur équilibrage de charge. La recommandation initiale est un CF de 1,25 avec un expert par core de calcul.

ST-MoE (Zoph et al., 2022). Pour un routage top-2, la recommandation est un CF de 1,25 en entraînement. En évaluation, le CF peut être augmenté (typiquement à 2,0) pour réduire le dropping et améliorer la qualité sans contrainte de vitesse d’entraînement. Le ST-MoE a aussi systématisé les bonnes pratiques : top-2 routing, CF 1,25, un expert par core, et la possibilité de modifier le CF en évaluation.

Expert Choice Routing (Google, 2022). L’approche Expert Choice utilise un CF de 2 par défaut (EC-CF2), ce qui correspond au même budget compute qu’un routage top-2 classique (GShard). Les expériences montrent que même un CF réduit à 0,5 surpasse le routage top-1 standard, démontrant la robustesse de cette méthode.

GShard (Lepikhin et al., 2020). GShard, l’un des premiers à formaliser le concept, utilisait un CF entre 2 et 8 pour le routage top-2 avec 600 milliards de paramètres. Ces valeurs élevées reflétaient un provisionnement conservateur pour éviter le dropping sur des modèles massifs distribués.

Relation avec l’auxiliary loss

Le capacity factor et l’auxiliary loss sont deux mécanismes complémentaires qui attaquent le même problème (le déséquilibre de charge) sous des angles différents :

L’auxiliary loss est un signal « soft ». Elle modifie les gradients du routeur pour l’inciter à répartir les tokens de façon plus équilibrée au fil du temps. C’est un processus graduel qui s’améliore au cours de l’entraînement. Elle n’offre aucune garantie instantanée.

Le capacity factor est une contrainte « hard ». Il impose une limite physique immédiate sur le nombre de tokens par expert. Peu importe ce que le routeur décide, un expert ne peut pas dépasser sa capacité allouée. C’est un filet de sécurité mécanique.

En pratique, les deux s’utilisent conjointement : l’auxiliary loss réduit la fréquence du dépassement de capacité, et le CF gère les cas où la loss n’a pas (encore) suffi. Le Switch Transformer utilise typiquement α = 0,01 pour l’auxiliary loss et CF = 1,25 ensemble.

L’approche dropless : se passer du token dropping

Le token dropping est un compromis acceptable, mais pas idéal. Plusieurs approches récentes cherchent à l’éliminer complètement.

MegaBlocks (2022)

MegaBlocks est un système d’entraînement MoE sur GPU qui attaque directement le problème qualité vs. efficacité matérielle du routage dynamique. Au lieu de dropper les tokens ou de gaspiller du compute en padding, MegaBlocks utilise des opérations de multiplication matricielle par blocs (block-sparse matrix multiplication) qui gèrent nativement des tailles d’experts variables. Résultat : aucun token n’est droppé, la charge est naturellement variable, et le hardware est mieux utilisé.

Le constat de MegaBlocks est clair : la loss la plus basse est obtenue avec la capacité maximale (aucun token droppé). Le token dropping est un compromis d’ingénierie, pas un choix optimal pour la qualité du modèle.

DeepSeek-V3 : No Token-Dropping

DeepSeek-V3 adopte explicitement une politique de « No Token-Dropping ». Combinée avec sa stratégie de load balancing auxiliary-loss-free (biais dynamiques), cette approche garantit que chaque token est traité par ses experts désignés. Au lieu de fixer un buffer statique via le capacity factor, DeepSeek utilise un routage limité par nœud (node-limited routing) : chaque token est envoyé à au maximum M nœuds de calcul, sélectionnés selon les scores d’affinité. L’infrastructure d’entraînement gère dynamiquement les tailles de batch variables par expert.

Cette approche est rendue possible par l’optimisation conjointe de l’algorithme (biais dynamiques, routage limité), du framework d’entraînement (overlap computation-communication), et du hardware (H800 GPU). C’est un bon exemple de co-design matériel-logiciel qui élimine un compromis historique de l’architecture MoE.

Dropless en inférence

En inférence, la tendance actuelle est clairement au dropless. Le framework NVIDIA NeMo, par exemple, propose un paramètre capacity_factor=None qui désactive entièrement le dropping. AWS Neuron, pour le déploiement sur Trainium/Inferentia, recommande aussi le mode « dropless » par défaut pour l’inférence, en utilisant des algorithmes de multiplication matricielle par blocs (blockwise matrix multiplication) qui organisent les tokens en blocs de taille fixe tout en minimisant le padding.

Le mode « dropping » (avec capacity factor fixe) reste disponible pour les cas où un coût de calcul prédictible est prioritaire, par exemple pour garantir des SLA stricts sur la latence.

Impact du capacity factor en inférence

Un point souvent négligé : le capacity factor peut être modifié entre l’entraînement et l’inférence. C’est un levier d’optimisation puissant.

En entraînement : un CF de 1,25 offre un bon compromis vitesse/qualité. Le coût mémoire est raisonnable, et les tokens droppés restent minoritaires grâce à l’auxiliary loss.

En évaluation/inférence : un CF plus élevé (2,0 voire plus) réduit le dropping à quasi zéro, ce qui améliore la qualité des prédictions. Le surcoût mémoire et compute est acceptable en inférence car les contraintes sont différentes (pas de gradient, pas de backward pass, souvent un seul batch à traiter).

Des travaux récents (Capacity-Aware Inference, février 2026) montrent qu’il est possible d’utiliser le capacity factor comme levier d’accélération en inférence. En imposant un CF légèrement restrictif (par ex. 1,5 au lieu de l’infini), on peut accélérer l’inférence de manière significative en droppant les tokens qui surchargent les experts les plus sollicités. Les résultats montrent qu’en éliminant environ 12 % des tokens en overflow, on peut obtenir une accélération de 85 % sur une couche MoE, avec un impact limité sur la qualité. C’est particulièrement intéressant quand l’expert parallelism crée des situations de « straggler effect » où un GPU surchargé ralentit tous les autres.

Implémentation pratique

Configuration dans NVIDIA NeMo

# Configuration MoE dans NeMo
num_moe_experts: 8
moe_router_topk: 2
moe_router_load_balancing_type: aux_loss

# Capacity factor
moe_expert_capacity_factor: 1.25   # ou None pour dropless
moe_token_dropping: false           # désactive le dropping
moe_pad_expert_input_to_capacity: true  # padding pour tenseurs statiques

Configuration dans HuggingFace Transformers

from transformers import SwitchTransformersConfig

config = SwitchTransformersConfig(
    num_experts=8,
    expert_capacity=320,          # calculé : (T/N) * CF
    router_aux_loss_coef=0.01,    # auxiliary loss
)

# Le capacity factor n'est pas toujours exposé directement
# dans Transformers. Il est parfois calculé implicitement
# à partir de expert_capacity, batch_size et num_experts.

Configuration dans vLLM (inférence)

# Dropless MoE (recommandé pour inférence)
config = RoutedExpertsMLPOpsConfig(
    num_experts=128,
    top_k=8,
    capacity_factor=None,  # Dropless : aucun token droppé
)

# Dropping MoE (latence prédictible)
config = RoutedExpertsMLPOpsConfig(
    num_experts=128,
    top_k=8,
    capacity_factor=1.25,  # 25% de marge
)

Comment les grands modèles gèrent le capacity factor

La tendance est claire : les modèles les plus récents (DeepSeek-V3, Qwen 3, GPT-oss) convergent vers des approches dropless, rendant le capacity factor classique moins central. Mais pour quiconque entraîne un modèle MoE avec des frameworks standard (Megatron, NeMo, HuggingFace), le CF reste un paramètre incontournable à configurer correctement.

Cas particulier : Vision-MoE

Le capacity factor joue un rôle encore plus crucial dans les modèles de vision. Dans un Vision Transformer (ViT), les images sont découpées en patches qui sont traités comme des tokens. Les images contiennent souvent beaucoup de patches (un ViT classique découpe une image 224×224 en 196 patches de 16×16), ce qui génère un volume de « tokens » important.

Vision-MoE (V-MoE), l’une des premières applications de MoE à la vision, utilisait un capacity factor intentionnellement bas pour réduire les contraintes matérielles. Pour compenser le dropping accru, V-MoE introduit le Batch Priority Routing : le réseau assigne des scores d’importance aux patches et les traite en priorité, de sorte que les patches en overflow sont généralement les moins importants. Ce mécanisme spécifique à la vision montre que le CF n’est pas qu’un simple seuil : son impact dépend fortement de la stratégie de routage associée.

Verdict

Le capacity factor est un concept fondamental pour comprendre les modèles MoE, même si sa centralité diminue avec les approches dropless modernes. Il traduit un compromis d’ingénierie entre la qualité du modèle (ne pas perdre de tokens) et l’efficacité matérielle (ne pas réserver trop de mémoire).

Pour un praticien qui démarre avec les MoE : utilisez CF = 1,25 en entraînement avec un routage top-2 et un expert par device. Augmentez le CF à 2,0 en évaluation. Monitorez le taux de tokens droppés ; s’il dépasse 10 %, augmentez d’abord le coefficient de l’auxiliary loss avant de toucher au CF.

Pour un projet en production : les architectures dropless (type DeepSeek-V3 ou MegaBlocks) sont désormais la référence. Elles éliminent le compromis et simplifient le réglage. Si votre infrastructure le permet, c’est la voie à suivre.