DeepSeek R1 n'active que 37 de ses 671 milliards de paramètres
Axel Morel · Fondateur & analyste, ProbansL'essentiel
Une architecture à mélange d'experts ne met en jeu, pour chaque token, qu'une fraction de ses paramètres, sélectionnée par un mécanisme de routage. C'est ce qui sépare les 671 milliards de paramètres affichés par DeepSeek R1 des 37 milliards que sa fiche donne pour activés.
- Huit experts sur 256 travaillent à chaque token. Le rapport technique de V3 donne le décompte : un expert partagé et 256 experts routés, dont 8 sont activés pour chaque token. La fiche de modèle de R1, elle, donne les décomptes de paramètres sans expliquer la sélection.
- Les 37 milliards actifs sont moins que Llama-3.1-70B. Rapproché des 70 milliards de Llama-3.1-70B, il est du même ordre de grandeur, inférieur même. Ce que ce rapprochement ne fait pas, en revanche, c'est comparer deux calculs : il compare deux décomptes de paramètres, et aucune de mes sources ne mesure le calcul par token de l'un ou de l'autre.
- DeepSeek publie elle-même ce que son service lui coûte. Ramenés au coût horaire du nœud, ces débits donnent environ 0,06 dollar par million de tokens en entrée et 0,30 dollar en sortie. Facturé au tarif de R1 alors en vigueur, le coût d'infrastructure de 87 072 dollars sur cette fenêtre de 24 heures aurait généré 562 027 dollars de recettes, soit une marge théorique de 545 %.
671 milliards de paramètres, mais 37 milliards seulement mobilisés pour produire chaque mot d’une réponse. Ce chiffre surprend tant qu’on n’a pas vu le mécanisme qui le rend possible : 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 que le mot « dense » désigne
Définition, pas un résultat de mes sources. On appelle dense une architecture de transformeur qui n’est pas découpée en experts. Le mot est celui de Meta, qui écrit avoir retenu pour Llama 3 « a standard dense Transformer model architecture […] rather than for a mixture-of-experts model », et qui donne pour motif la stabilité d’entraînement, pas le coût de calcul.
Cette même source situe elle-même le mélange d’experts comme une architecture alternative : elle nomme Mixtral et Arctic, dit les battre en performance (« Llama 3 outperforms these models »), tout en reconnaissant qu’« there remain numerous trade offs in terms of training and inference efficiency » entre les deux familles. L’arbitrage entre dense et mélange d’experts sur l’efficacité d’inférence n’est donc pas tranché, y compris par le producteur qui sert ici de repère de comparaison.
Ce que la méthode interprète. Je lis cette conception comme celle où la taille du modèle et le calcul par token varient ensemble, faute d’un mécanisme qui mette une partie du réseau au repos. Aucun des documents que j’ai relevés ne chiffre ce calcul, ni pour un modèle dense, ni pour un mélange d’experts : c’est une lecture de l’architecture, pas une mesure.
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 sous-réseaux spécialisés, appelés experts, et un mécanisme de routage sélectionne, pour chaque token, ceux qui le traiteront. Le rapport technique de V3 donne le décompte : un expert partagé et 256 experts routés, dont 8 sont activés pour chaque token. La fiche de modèle de R1, elle, donne les décomptes de paramètres sans expliquer la sélection : le mécanisme de routage lui-même n’est détaillé dans aucune de mes sources.
Le chiffre DeepSeek R1, remis en contexte
Ce que les données établissent. La fiche de modèle de DeepSeek-R1 donne 671 milliards de paramètres au total et 37 milliards activés, et précise que R1 est entraîné à partir de DeepSeek-V3-Base : les deux modèles partagent donc l’architecture à mélange d’experts détaillée dans le rapport technique de V3, où ces mêmes valeurs figurent. Une précision sur le premier chiffre : le papier R1 le donne deux fois, différemment, « # Total Params 671B » en table 8 et « 660B R1-Zero and R1 » en annexe B.4.4. Je retiens 671, qui est la valeur de la table et celle de la fiche de modèle ; l’écart n’est expliqué nulle part. Le rapport entre 671 et 37, un facteur d’environ 18, est un rapport entre le nombre de paramètres affiché et le nombre activé par token.
Ce que la méthode interprète. 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. Rapproché des 70 milliards de Llama-3.1-70B, il est du même ordre de grandeur, inférieur même. Le repère tient : Meta écrit que « Llama 3 uses a standard, dense Transformer architecture » et donne les hyperparamètres des trois tailles, 8, 70 et 405 milliards, sous cette même description, la table 1 précisant que tous les résultats du papier portent sur les modèles 3.1. La variante à 70 milliards est donc un modèle dense au sens de son producteur. Je retiens cette taille plutôt que 8 ou 405 milliards parce qu’elle est la plus proche en ordre de grandeur des 37 milliards actifs de R1 ; les deux autres, très en dessous ou très au-dessus, auraient donné un rapprochement moins lisible. Ce que ce rapprochement ne fait pas, en revanche, c’est comparer deux calculs : il compare deux décomptes de paramètres, et aucune de mes sources ne mesure le calcul par token de l’un ou de l’autre.
Pourquoi ce découplage compte économiquement
Ce que la méthode interprète. Le coût d’inférence tient au calcul effectivement exécuté, et le mélange d’experts découple ce calcul du total affiché. C’est une lecture du mécanisme, pas un résultat de mes sources : aucun des documents relevés ici ne mesure la relation entre paramètres activés et coût de calcul, et le rapport d’inférence de DeepSeek ne dit rien de la mémoire nécessaire au chargement des poids ni de la précision employée.
Un modèle dense de 671 milliards mettrait en jeu, à chaque token, l’intégralité de ces paramètres. Un modèle à mélange d’experts de même taille totale n’en active que 37 milliards par token, à l’échelle du réseau entier : le rapport technique de V3 donne ce chiffre comme un total, sans le décomposer entre l’attention et les couches d’experts, et aucune de mes sources ne fait cette décomposition. Le répertoire de connaissances est là dans les deux cas ; le calcul, non.
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 active, par token, que 37, soit moins que les 70 milliards de Llama-3.1-70B, un rapprochement de deux décomptes de paramètres et non une mesure de calcul, le seul point de comparaison retenu ici.
Ce que ça vaut en dollars, sur les chiffres que DeepSeek publie
Ce que les données établissent. DeepSeek a publié elle-même, fin février 2025, le coût d’infrastructure de son service d’inférence sur une fenêtre de 24 heures allant du 27 février à midi au 28 février à midi (UTC+8) : 226,75 nœuds en moyenne, chaque nœud regroupant 8 GPU H800. Le tarif de location, lui, n’est pas constaté mais posé : DeepSeek écrit « Assuming the leasing cost of one H800 GPU is $2 per hour », soit 16 dollars par heure et par nœud. Tout ce qui suit hérite de cette hypothèse. Sur cette fenêtre, chaque nœud traitait en moyenne environ 73 700 tokens par seconde en entrée, cache compris, et 14 800 en décodage (génération de la réponse) : sur les 608 milliards de tokens d’entrée de la journée, 342 milliards, soit 56,3 %, ont été servis par le cache sur disque, ce qui fait du chiffre d’entrée un débit de service et non un débit de calcul pur. Ramenés au coût horaire du nœud, ces débits donnent environ 0,06 dollar par million de tokens en entrée et 0,30 dollar en sortie. Ces deux chiffres sont une moyenne sur tout le trafic V3 et R1 de la journée, pas un chiffre isolé pour R1 seul, et un plancher d’infrastructure, pas une facture par requête ; celui d’entrée, en plus, n’est pas un coût de calcul pur puisqu’il inclut le cache.
Le calcul de marge repris plus bas figure dans le rapport lui-même : ce chiffrage en dollars le vérifie et le documente, il ne le découvre pas. Mon apport propre tient au coût par token. Le rapport publie des débits et un coût de nœud, il ne les ramène pas au million de tokens, et il ne rapproche nulle part le débit d’entrée du taux de cache qu’il publie pourtant dans le même document. C’est cette composition-là que le chiffre brut ne montre pas.
Ce que la méthode interprète. Ce chiffre traduit en dollars ce que signifie le facteur 18 (37 milliards de paramètres actifs sur 671 milliards). Un modèle dense de 671 milliards activant l’intégralité de ses paramètres à chaque token calculerait, au même tarif horaire supposé de 2 dollars par GPU, environ 18 fois plus en sortie : sur le même matériel, le débit de décodage chuterait d’autant, portant le coût vers environ 5 dollars par million de tokens en sortie. Le volet entrée ne se prête pas au même calcul direct : le débit mesuré de 73 700 tokens par seconde inclut le cache disque à hauteur de 56,3 %, un mécanisme qui n’a aucune raison de disparaître pour un modèle dense, et multiplier ce débit dans son ensemble par 18, comme si tout relevait du calcul, surestime probablement l’écart réel pour l’entrée. Une estimation plus prudente ne porterait le facteur que sur la part effectivement calculée du trafic, autour de 44 %, ce que le rapport de DeepSeek ne permet pas d’isoler avec précision. Ce chiffre “modèle dense équivalent” reste, pour l’entrée comme pour la sortie, une extrapolation par un facteur constant et non une mesure : aucun des modèles denses documentés dans ce dossier n’atteint cette taille.
Ce même rapport publie un autre chiffre, indépendant du précédent : facturé au tarif de R1 alors en vigueur, le coût d’infrastructure de 87 072 dollars sur cette fenêtre de 24 heures aurait généré 562 027 dollars de recettes, soit une marge théorique de 545 %. DeepSeek qualifie elle-même ce chiffre de théorique et écrit que sa recette réelle est « substantially lower » : la tarification de V3, les remises hors heures de pointe et l’usage gratuit du chatbot la réduisent en pratique. Ce chiffre-là ne dit rien de l’architecture ; il tient à un tarif et à un volume.
Mes réserves
- 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épend aussi du matériel utilisé, une donnée déjà intégrée au chiffrage en dollars ci-dessus, pas à ce facteur seul.
- La comparaison avec les 70 milliards de paramètres de Llama-3.1-70B 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.
- Les coûts d’infrastructure calculés ici (0,06 $ / 0,30 $ par million de tokens) sont un plancher calculé par DeepSeek à partir d’un tarif de location qu’elle pose en hypothèse, non un coût constaté. Ce n’est ni le coût qu’obtiendrait un tiers louant du matériel comparable ailleurs, ni le prix facturé aux utilisateurs de l’API, qui inclut marge, R&D et amortissement de l’entraînement.
- Ce texte ne traite pas de la mémoire à réserver pour héberger le modèle. Le savoir demanderait la spécification exacte des cartes employées par DeepSeek : mes sources donnent bien une fiche de H800, mais rien ne me permet d’établir que c’est la variante qu’elle déploie, et la fiche en documente deux dont les capacités diffèrent.
- Le coût par token ne dit rien du coût par réponse complète pour un modèle de raisonnement : le papier R1 range lui-même l’efficacité en tokens parmi ses limites reconnues, et documente un doublement de la longueur de génération en cours d’entraînement (32 768 à 65 536 tokens). Un coût par token bas peut coexister avec un coût par réponse plus élevé si le modèle produit structurellement plus de tokens.
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. Trois questions à poser avant de dimensionner une infrastructure autour d’un modèle MoE annoncé en paramètres totaux : combien de paramètres sont réellement activés par token, puisque le calcul en dépend ; sur combien de nœuds le producteur fait tourner son propre service, chiffre que DeepSeek publie ici ; et si le coût par token annoncé est mesuré en production ou estimé à partir d’une fiche technique.
Retour au dossier Comprendre les modèles post-LLM. Voir aussi Qu’est-ce qu’un LLM de raisonnement ?.
ISP-IA41/100· 31-55 % · Preuves limitées · Toutes les sources de cet article sont de tier P : chaque producteur y documente son propre produit. Le plafond de partie prenante de l'échelle IA s'applique donc, et le barreau 4 est le maximum atteignable, pas un score confortable. Il est retenu parce que la preuve centrale est un faisceau de documents primaires émanant de deux producteurs distincts, DeepSeek et Meta, qui se recoupent sur des faits d'architecture et non sur un effet. Ce faisceau n'est pas homogène et il faut le dire : deux préprints arXiv versionnés et datés d'un côté, deux fiches de modèle Hugging Face de l'autre, sans numéro de version, sans date de mise à jour et sans copie archivée, alors que la fiche de R1 est justement la seule pièce du corpus qui attribue les 671 et 37 milliards à R1 lui-même. La convergence est donnée pour modérée et non forte parce que la section économique ne repose que sur une seule publication de DeepSeek sur son propre service, dont le tarif de location est posé en hypothèse par elle-même et dont la marge de 545 % est explicitement théorique. La réplication est nulle au sens strict : personne n'a rejoué ces chiffres. Elle n'est pas également hors de portée selon le fait considéré, et l'annexe I du papier R1 le montre, qui indique que les poids de R1 et de R1-Zero sont publiés sur HuggingFace : les décomptes de paramètres sont donc vérifiables par un tiers, quand les chiffres du service d'inférence ne le sont pas sans accès à ce service. La puissance d'échantillon n'a pas d'objet, le corpus étant fait de quelques documents techniques et non d'une population d'observations. Relecture du 2026-09-04 : les corrections apportées ce jour touchent la façon dont le texte interprète et compose ses chiffres (répartition supposée entre attention et experts, extrapolation appliquée à un débit partiellement issu du cache), pas la base de sources elle-même, qui reste identique et toujours plafonnée à ce même barreau. L'ISP ne bouge donc pas : ce n'est pas un score maintenu par confort, c'est qu'aucune source nouvelle ni aucun changement de tier ne le justifierait.
L'Indice de solidité des preuves évalue la base empirique de cette analyse sur quatre critères pondérés : type de preuve (40 %), convergence (30 %), réplication (20 %), puissance (10 %). L'axe type de preuve est calibré par champ : 100 y désigne le meilleur dispositif que l'échelle ISP-IA sache produire, et non une preuve absolue.
Toutes les sources de cet article sont de tier P : chaque producteur y documente son propre produit. Le plafond de partie prenante de l'échelle IA s'applique donc, et le barreau 4 est le maximum atteignable, pas un score confortable. Il est retenu parce que la preuve centrale est un faisceau de documents primaires émanant de deux producteurs distincts, DeepSeek et Meta, qui se recoupent sur des faits d'architecture et non sur un effet. Ce faisceau n'est pas homogène et il faut le dire : deux préprints arXiv versionnés et datés d'un côté, deux fiches de modèle Hugging Face de l'autre, sans numéro de version, sans date de mise à jour et sans copie archivée, alors que la fiche de R1 est justement la seule pièce du corpus qui attribue les 671 et 37 milliards à R1 lui-même. La convergence est donnée pour modérée et non forte parce que la section économique ne repose que sur une seule publication de DeepSeek sur son propre service, dont le tarif de location est posé en hypothèse par elle-même et dont la marge de 545 % est explicitement théorique. La réplication est nulle au sens strict : personne n'a rejoué ces chiffres. Elle n'est pas également hors de portée selon le fait considéré, et l'annexe I du papier R1 le montre, qui indique que les poids de R1 et de R1-Zero sont publiés sur HuggingFace : les décomptes de paramètres sont donc vérifiables par un tiers, quand les chiffres du service d'inférence ne le sont pas sans accès à ce service. La puissance d'échantillon n'a pas d'objet, le corpus étant fait de quelques documents techniques et non d'une population d'observations. Relecture du 2026-09-04 : les corrections apportées ce jour touchent la façon dont le texte interprète et compose ses chiffres (répartition supposée entre attention et experts, extrapolation appliquée à un débit partiellement issu du cache), pas la base de sources elle-même, qui reste identique et toujours plafonnée à ce même barreau. L'ISP ne bouge donc pas : ce n'est pas un score maintenu par confort, c'est qu'aucune source nouvelle ni aucun changement de tier ne le justifierait.
- Le décompte des paramètres totaux et activés serait relevé directement dans les poids publiés, par une équipe sans lien avec DeepSeek, de sorte que l'écart entre les deux valeurs que le producteur publie lui-même, 671 et 660 milliards, soit tranché sur l'artefact et non sur sa documentation.Une équipe sans lien avec DeepSeek, à partir des poids déposés sur HuggingFace · un dispositif approchant existe, sans remplir la condition
- Le débit et le coût du service d'inférence seraient mesurés sur une fenêtre comparable par un observateur qui n'exploite pas ce service, de sorte que la marge annoncée cesse de reposer sur un tarif de location que le producteur pose lui-même en hypothèse.Un fournisseur d'infrastructure tiers, ou une équipe académique mesurant le service · personne ne l’a produit
- Une ablation indépendante isolerait la part du gain réellement attribuable au mélange d'experts, en comparant une architecture creuse et une architecture dense entraînées à budget de calcul égal, plutôt qu'en rapprochant deux modèles conçus séparément.Une équipe académique sans lien avec DeepSeek ni Meta · un dispositif approchant existe, sans remplir la condition
Ce dispositif porterait l'indice à 49 sur 100, dans le palier « Preuves limitées ». Les trois autres axes restent à leur valeur actuelle : un dispositif ne fait monter ni la convergence d'une littérature ni sa réplication.
Effectif observé : L'effectif observé n'a pas d'objet ici : les unités sont quelques documents techniques nommés, pas une population d'observations, et aucun travail supplémentaire ne transforme un décompte d'architecture en série de mesures. Cet axe ne monterait que si la question posée cessait d'être ce qu'annonce l'architecture pour devenir ce qu'elle produit.
Score de 41/100 (31-55 %) établi le 4 septembre 2026.
I source primaire indépendante · S secondaire spécialisée · P partie prenante ayant un intérêt commercial sur le sujet traité.
Lexique
- LLM· Grand modèle de langage↗
- Modèle d'intelligence artificielle entraîné sur de vastes corpus de texte pour prédire et générer du langage, capable de tâches d'analyse, de synthèse et de génération de texte en langage naturel sans avoir été explicitement programmé pour la tâche demandée.
Modification apportée · mis à jour le 4 septembre 2026
J'ai refait le relevé du papier Llama 3 sur le document complet, et non plus sur son résumé. Le repère de comparaison en sort renforcé : Meta écrit noir sur blanc que Llama 3 emploie une architecture dense et donne les trois tailles, 8, 70 et 405 milliards, sous cette même description. La réserve que je posais sur la variante à 70 milliards n'a plus lieu d'être et je l'ai retirée. En sens inverse, j'ai supprimé la section consacrée à la mémoire à réserver : elle reposait sur une fiche de carte H800 dont je ne peux pas établir qu'elle correspond au matériel de DeepSeek, et dont la seconde variante, à 94 Go, inversait la conclusion du calcul. J'ai retiré du texte ce que mes sources ne portent pas : la prévalence des architectures denses, la définition du dense par le calcul, la relation entre paramètres activés et coût, la réception médiatique du rapport DeepSeek. J'ai aussi ajouté deux choses que mes sources disent et que je passais sous silence : le papier R1 donne la taille totale deux fois, 671 et 660 milliards, et 56,3 % des tokens d'entrée du rapport d'inférence sortent d'un cache disque, ce qui change ce que veut dire le coût d'entrée de 0,06 dollar. Enfin, le rapport ne se réfère plus au 27 février seul : sa fenêtre de mesure court jusqu'au 28 à midi. J'ai ajouté deux encadrés en langue courante, l'un sur la sélection des experts à chaque fragment de texte produit, l'autre sur ce qui relie le calcul exécuté à la dépense. J'ai relu ce texte en revenant à mes six sources intégrales, sans repartir de ma version précédente. Deux points touchaient le cœur du raisonnement économique. D'abord, j'écrivais que les 37 milliards de paramètres actifs se limitaient aux couches d'experts, l'attention restant une charge à part : le rapport technique de V3 donne pourtant ce chiffre comme un total pour le réseau entier, sans cette décomposition, que je n'ai retrouvée nulle part ailleurs. Ensuite, mon estimation d'un coût d'entrée à 1 dollar pour un modèle dense équivalent multipliait par 18 un débit dont 56,3 % vient du cache disque et non d'un calcul, ce qui surestime l'écart réel : je l'ai retirée et j'explique maintenant pourquoi ce volet ne se prête pas au même calcul direct que la sortie. J'ai aussi resserré deux réserves qui étaient trop loin du chiffre qu'elles qualifient (le débit d'entrée compté cache compris, les limites du coût par million de tokens), ajouté que le coût par token ne dit rien du coût par réponse complète pour un modèle qui raisonne en générant plus de tokens, justifié pourquoi je compare aux 70 milliards de Llama-3.1-70B plutôt qu'aux deux autres tailles de la même série, et repris de ma propre source Llama 3 ce qu'elle dit elle-même des compromis entre architecture dense et mélange d'experts, que je passais sous silence. Retiré une comparaison au reste du secteur qu'aucune de mes sources ne permettait d'établir. Une deuxième relecture, faite dans la foulée, m'a trouvé quatre points que je n'ai pas encore corrigés et que je préfère signaler que masquer : ma phrase d'ouverture dit que le mélange d'experts change le calcul « réellement » exécuté, alors qu'aucune de mes sources ne mesure de calcul réel, seulement un décompte de paramètres. La légende du schéma cite le papier R1 et le rapport V3, mais aucun des deux ne donne à lui seul les deux chiffres 671 et 37 milliards pour R1 lui-même : c'est la fiche de modèle Hugging Face de R1 qui les porte ensemble, elle manque à la légende. Je me contredis sur qui a fait le calcul du coût par million de tokens : je l'attribue à DeepSeek à un endroit et je le revendique comme mon propre calcul un peu plus haut, ce sont mes sources qui donnent le débit et le tarif, c'est moi qui les ramène au million de tokens. Enfin, ma réserve sur la mémoire à réserver invoque une fiche technique du H800 que je n'ai en réalité pas dans mes sources, et le doublement de longueur de génération que je cite (32 768 à 65 536 tokens) concerne DeepSeek-R1-Zero dans le papier, pas R1. Je m'arrête à cette relecture sans en relancer une troisième : ces quatre points restent à traiter.
Développe une méthode d'analyse destinée à distinguer ce que les preuves établissent, ce qu'elles suggèrent et ce qu'elles ne permettent pas de conclure, puis à traduire cette distinction en décisions professionnelles.
Choix du sujet, direction de la rédaction, validation ou modification des sources, validation et retravail du texte et des illustrations : Axel Morel. Rédaction, choix des sources initiales et plan de rédaction initial : assistance IA.
Responsabilité éditoriale : Axel Morel. Recherche et rédaction assistées par IA selon la méthodologie Probans, sources vérifiées avant publication. Charte éditoriale.
En savoir plus