Mixture of experts : pourquoi DeepSeek R1 n'active que 37 des 671 milliards de paramètres

671 milliards de paramètres, mais 37 milliards seulement mobilisés pour produire chaque mot d’une réponse. Ce chiffre, déjà cité dans notre analyse sur les modèles post-LLM, surprend tant qu’on n’a pas vu le mécanisme qui le rend possible. Il ne s’agit pas d’un modèle bridé ou d’une astuce marketing : c’est une architecture, la mixture of experts (mélange d’experts, MoE), qui change la relation entre la taille affichée d’un modèle et le calcul qu’il exécute réellement.

Ce qu’un LLM dense calcule à chaque token

Ce que les données établissent. Un LLM “dense” — la conception la plus répandue jusqu’ici — active la totalité de ses paramètres pour générer chaque token de sa réponse. Que la question posée relève de mathématiques, de traduction ou de cuisine, le même réseau, dans son intégralité, effectue le calcul. La taille du modèle et le coût de calcul par token sont donc, dans cette conception, directement liés : doubler le nombre de paramètres double, à peu de choses près, le calcul nécessaire pour produire un seul mot.

Le routage : n’activer qu’une poignée d’experts

Ce que les données établissent. Une architecture à mélange d’experts rompt ce lien. Le réseau est découpé en plusieurs sous-réseaux spécialisés, appelés experts. Un mécanisme de routage, entraîné en même temps que le reste du modèle, décide, token par token, lequel — ou lesquels — de ces experts traiter la requête en cours. Le modèle dans son ensemble peut contenir des centaines d’experts et un total de paramètres considérable ; à un instant donné, pour un token donné, seule une petite fraction de ce total est effectivement mobilisée. Le modèle est donc, au sens propre, beaucoup plus grand “sur le papier” que ce qu’il calcule à chaque instant.

Le chiffre DeepSeek R1, remis en contexte

Ce que les données établissent. DeepSeek-R1, décrit par DeepSeek-AI (2025) et construit sur l’architecture MoE détaillée dans le rapport technique DeepSeek-V3, affiche 671 milliards de paramètres au total mais n’en active que 37 milliards par token traité. L’écart entre les deux, un facteur d’environ 18, mesure la distance entre la taille affichée du modèle et le calcul réellement mobilisé pour répondre à une requête donnée.

Mon interprétation. Ce chiffre de 37 milliards de paramètres actifs mérite d’être comparé à autre chose qu’au total de 671 milliards du même modèle, sans quoi il ne dit pas grand-chose au lecteur non spécialiste. Rapproché des 70 milliards de Llama 3.1, un LLM dense de référence, il est du même ordre de grandeur — inférieur, même. Le calcul mobilisé par DeepSeek R1 pour produire un token n’a donc rien d’un modèle “gigantesque” au sens où l’entend la couverture médiatique qui s’arrête au chiffre de 671 milliards. C’est un modèle dont le répertoire de connaissances est vaste, mais dont le calcul par requête reste comparable à celui d’un modèle dense de taille moyenne.

Pourquoi ce découplage compte économiquement

Ce que les données établissent. Le coût d’inférence d’un LLM — le calcul mobilisé pour répondre à une requête — est fonction du nombre de paramètres activés pour cette requête, pas du nombre total de paramètres que contient le modèle. C’est une conséquence directe et non contestée du fonctionnement même de ces réseaux : chaque paramètre activé requiert une opération de calcul, chaque paramètre laissé au repos par le routage n’en requiert aucune.

Mon interprétation. C’est cette mécanique qui rend l’architecture MoE économiquement intéressante. Un modèle dense de 671 milliards de paramètres calculerait, à chaque token, avec l’intégralité de ces 671 milliards — un coût d’inférence considérable. Un modèle MoE de même taille totale, lui, ne paie que le coût des 37 milliards effectivement activés. L’architecture permet ainsi de disposer d’un vaste répertoire de connaissances spécialisées, réparties entre de nombreux experts, sans supporter à chaque requête le coût de calcul d’un modèle dense de taille équivalente.

DeepSeek R1 n’est pas un modèle de 671 milliards de paramètres qui calcule avec 671 milliards de paramètres : c’est un modèle qui en contient 671 milliards et n’en mobilise, par token, qu’une fraction proche de la taille d’un LLM dense courant.

Mes réserves

• Le nombre de paramètres actifs par token est un indicateur partiel du coût réel d’exploitation d’un modèle MoE. Faire tourner DeepSeek R1 suppose de garder en mémoire l’ensemble des 671 milliards de paramètres, y compris les experts non activés pour le token en cours — puisque le routage peut solliciter un expert différent au token suivant. Le besoin en mémoire ne suit donc pas la même courbe que le besoin en calcul : il reste proche de celui d’un modèle dense de taille totale équivalente, même si le calcul, lui, est bien plus restreint.
• Le facteur 18 entre paramètres totaux et paramètres actifs mesure un rapport de taille, pas une mesure directe de coût d’inférence en euros ou en énergie : ce chiffre-là dépendrait aussi du matériel utilisé, une donnée que je n’ai pas ici.
• La comparaison avec les 70 milliards de paramètres de Llama 3.1 rapproche deux ordres de grandeur ; elle ne signifie pas que les deux modèles délivrent une qualité de réponse équivalente sur toutes les tâches, une question distincte de celle traitée ici.

Concrètement, un chiffre de paramètres totaux affiché seul, sans préciser s’il s’agit d’une architecture dense ou d’un mélange d’experts, ne renseigne pas sur le coût de calcul réel d’une requête. Pour DeepSeek R1, c’est le chiffre de 37 milliards de paramètres actifs, pas celui de 671 milliards, qui se rapproche le plus de ce que le modèle mobilise pour répondre.

Retour au dossier Comprendre les modèles post-LLM. Voir aussi Qu’est-ce qu’un LLM de raisonnement ?.