Des chercheurs de ByteDance identifient une faille dans l'économie de mémoire de DeepSeek

Publiée fin septembre 2026, cette étude remet en question l'un des principaux piliers techniques de DeepSeek. Des chercheurs de ByteDance ont dirigé le travail. Parmi les coauteurs figurent des universitaires de Princeton, de Stanford et de l'université de Californie à Berkeley. Selon le SCMP, ils décrivent un défaut potentiel dans la technologie d'économie de mémoire qui sous-tend les modèles du laboratoire chinois. Cette technologie a aidé DeepSeek à réduire son retard sur OpenAI et Anthropic, avec des coûts nettement inférieurs. La conclusion des auteurs : l'économie réalisée peut se payer en imprécision des réponses.

Ce que l'on sait de l'étude

Le compte rendu public est pour l'instant succinct, et il faut en tenir compte. Le fragment de source disponible ne mentionne ni le nom du mécanisme concerné, ni pourcentage de perte de qualité, ni liste de benchmarks. On ne sait pas non plus sur quelles versions des modèles DeepSeek les tests ont été menés. Il indique seulement que l'étude a mis au jour une faiblesse dans l'approche d'économie de mémoire et que cette faiblesse peut entraîner une baisse de précision.

La composition même de l'équipe d'auteurs en dit long. ByteDance développe ses propres grands modèles et paie elle-même l'inférence : elle connaît le prix de chaque gigaoctet de cache. Les coauteurs issus de trois grandes universités américaines apportent à l'étude un poids académique. Il ne s'agit pas d'une note de blog d'un concurrent, mais d'un preprint porté par une large coalition. Il sera très probablement disséqué, et d'autres tenteront de le reproduire.

Pourquoi ça fait mal à DeepSeek

Pour DeepSeek, l'économie de mémoire n'est pas une optimisation parmi d'autres, c'est le socle de son modèle économique. La mémoire qu'un modèle conserve pendant la génération, avant tout le cache des clés et valeurs de l'attention, détermine combien de requêtes un seul accélérateur peut absorber et quelle longueur de contexte il peut gérer. Plus le cache est compact, moins le token coûte cher. Pour un laboratoire qui travaille avec un accès limité aux puces haut de gamme et qui rivalise par les prix, c'est critique.

Pour situer le contexte : dans la publication consacrée à DeepSeek-V2, le laboratoire annonçait une réduction du KV-cache de 93,3% grâce au mécanisme Multi-head Latent Attention. DeepSeek-V3 compte 671 milliards de paramètres, dont 37 milliards actifs par token, et a été entraîné en environ 2,788 millions d'heures GPU sur des H800. Le texte disponible ne confirme pas que la nouvelle étude concerne précisément ce mécanisme : ce contexte vient de nous, ce n'est pas une citation de la recherche. Mais il donne la mesure des enjeux. Si la compression de la mémoire dégrade systématiquement la précision, l'arithmétique avantageuse de DeepSeek devra être corrigée.

Faits clés

• Auteurs : équipe de ByteDance, coauteurs de Princeton, Stanford et UC Berkeley.
• Publication : fin septembre 2026.
• Objet de la critique : la technologie d'économie de mémoire des modèles DeepSeek.
• Risque annoncé : baisse de la précision du modèle.
• Les métriques de dégradation et la liste des modèles testés ne sont pas indiquées dans le fragment de source disponible.
• Contexte : la V2 annonçait une réduction de 93,3% de la taille du KV-cache, la V3 compte 671 milliards de paramètres dont 37 milliards actifs.

Ce qui manque encore

La question centrale est de savoir où se manifeste précisément la dégradation. La compression de la mémoire pénalise généralement les tâches qui exigent de retrouver un détail exact dans un long contexte : rechercher un fait dans un gros document, travailler sur un dépôt de code, mener des raisonnements en plusieurs étapes qui reviennent à des tokens situés très en amont. Les benchmarks moyens peuvent ne pas le révéler. Si les auteurs ont trouvé un scénario de ce type, c'est plus grave qu'une baisse de quelques points dans un classement général.

La seconde question concerne la réponse de DeepSeek. Le laboratoire pourrait montrer que l'effet n'apparaît que dans certaines configurations, qu'il se corrige par un réentraînement complémentaire ou que les versions plus récentes l'ont déjà contourné. Tant qu'aucune réponse n'est publiée, il est prématuré d'évaluer l'ampleur du problème.

Comment travailler avec ça

Les équipes qui utilisent déjà les modèles DeepSeek en production n'ont pas besoin de changer de stack en urgence. Elles gagneraient en revanche à vérifier les modèles sur leurs propres données.

• Lancez vos scénarios longs : extraction de faits dans de gros documents, analyse de code, chaînes de raisonnement. Comparez avec une référence, par exemple un autre modèle, et consignez les écarts.
• Suivez le preprint et les réplications. Une confirmation indépendante compte plus que la première publication, surtout quand l'auteur travaille pour une entreprise concurrente.
• Calculez le coût en tenant compte de la qualité. Si un token bon marché oblige à relancer des requêtes ou à vérifier à la main, le gain de prix fond.
• Pour les tâches critiques, gardez un modèle de secours et une comparaison automatique des réponses.

Pour le marché dans son ensemble, cette affaire illustre un point plus général. Une efficacité obtenue par une astuce d'architecture doit être éprouvée aussi durement que celle obtenue par la montée en échelle. Le premier audit sérieux de l'approche de DeepSeek vient de pairs du secteur, et ce ne sera très probablement pas le dernier.