DeepSeek V4 économise-t-il vraiment 98 % de mémoire ?

Le point clé est simple : le KV cache — le cache des clés et valeurs conservées pendant la génération — peut devenir un énorme poste mémoire dans les grands modèles de langage. Mais il ne représente pas, à lui seul, toute la mémoire vidéo GPU nécessaire pour servir un modèle.

La formulation la plus prudente

La version défendable aujourd’hui serait plutôt :

DeepSeek V4 s’appuie sur Hybrid Attention, Compressed Sparse Attention (CSA) et Heavily Compressed Attention (HCA) pour réduire fortement la pression du KV cache dans l’inférence à très long contexte ; les informations disponibles ne permettent pas d’affirmer que la VRAM totale baisse de 98 % .

C’est moins spectaculaire qu’un « -98 % », mais beaucoup plus juste pour une équipe qui doit dimensionner des GPU, un budget cloud ou un service d’inférence.

Ce que confirment les sources disponibles

La page d’actualité de l’API DeepSeek indique que DeepSeek-V4 Preview a été publié le 24 avril 2026 . La fiche modèle de DeepSeek V4 précise que la famille comprend DeepSeek-V4-Pro et DeepSeek-V4-Flash, et décrit V4 comme une série de modèles MoE — Mixture-of-Experts, ou « mélange d’experts » — qui conserve le framework DeepSeekMoE et la stratégie Multi-Token Prediction (MTP), tout en ajoutant notamment une architecture Hybrid Attention .

Le lien avec la mémoire se trouve surtout dans le traitement de l’attention en contexte long. NVIDIA décrit la Compressed Sparse Attention (CSA) comme une méthode qui compresse dynamiquement les entrées KV afin de réduire l’empreinte mémoire du KV cache, puis applique DeepSeek Sparse Attention (DSA) pour rendre les matrices d’attention plus creuses. La Heavily Compressed Attention (HCA) va plus loin en fusionnant les entrées KV de plusieurs ensembles de tokens en une entrée compressée unique, ce qui réduit encore la taille du KV cache .

Autrement dit, les preuves directes portent sur la taille du KV cache et le coût de calcul de l’attention. Elles ne prouvent pas que toute la pile de déploiement consomme 98 % de VRAM en moins.

98 %, 90 %, 9,5× : trois chiffres à ne pas confondre

Le chiffre de 98 % apparaît notamment dans le titre d’un article LinkedIn généré par un utilisateur : « DeepSeek Sparse Attention Shrinks KV Memory by 98 Percent in Real World Serving » . Ce type de contenu peut servir de point de départ pour remonter une rumeur, mais il ne doit pas être traité comme une fiche technique officielle.

Un chiffre tiers plus facile à interpréter est celui de 10 % de KV cache. Wccftech rapporte que, par rapport à DeepSeek V3.2, DeepSeek V4 ne nécessiterait que 27 % des FLOPs d’inférence single-token et 10 % du cache key-value (KV) . Si l’on ne parle que du KV cache, cela correspond à environ 90 % de réduction. Mais la comparaison porte sur DeepSeek V3.2, et non sur tous les contextes, tous les batch sizes, toutes les configurations matérielles ou toute la VRAM d’un déploiement .

Un autre titre évoque des besoins mémoire 9,5× plus faibles . Même en prenant ce chiffre au pied de la lettre, 1/9,5 correspond à environ 10,5 % de besoin restant, soit près de 89,5 % de réduction. Ce n’est toujours pas 98 %, et il faut encore vérifier si le chiffre concerne le KV cache, un scénario de très long contexte ou la mémoire complète du service .

Pourquoi le KV cache ne suffit pas à résumer la VRAM

Le KV cache est crucial dans les charges de travail longues. Hugging Face explique que, dans les usages agentiques prolongés, chaque résultat d’outil est ajouté au contexte ; les tokens suivants doivent donc traiter un historique de plus en plus long. Deux indicateurs deviennent alors centraux : les FLOPs d’inférence pour générer un token et la taille du KV cache, qui augmentent avec la longueur de séquence . La version GitHub de ce billet décrit aussi des échecs typiques : trace qui dépasse le budget de contexte, KV cache qui remplit le GPU, ou appels d’outils qui ralentissent au fil d’une tâche longue .

Mais un déploiement complet ne stocke pas seulement le KV cache. Même l’article LinkedIn qui porte le chiffre de 98 % distingue les poids partagés, les poids des experts MoE, les activations, le KV cache et les surcoûts du framework . C’est précisément pour cela qu’il faut séparer les postes : une baisse massive du KV cache dans un scénario donné ne se transforme pas automatiquement en baisse équivalente de toute la VRAM.

Une vraie optimisation, pas un chiffre magique

La direction technique de DeepSeek V4 mérite l’attention. Elle cible l’un des coûts majeurs de l’inférence à très long contexte : l’attention et le stockage des clés/valeurs. Les descriptions de CSA et HCA montrent un travail d’ingénierie destiné à compresser les entrées KV, rendre les matrices d’attention plus creuses et réduire le coût de calcul .

Le rapport technique de DeepSeek V4 mentionne également des optimisations d’infrastructure pour l’entraînement et l’inférence, par exemple un kernel fusionné unique pour les modules MoE afin de mieux superposer calcul, communication et accès mémoire . Ce sont des gains potentiellement importants. Mais ce ne sont pas, en soi, des preuves d’une réduction de 98 % de la VRAM totale.

Comment évaluer DeepSeek V4 sans se faire piéger par le slogan

Si vous envisagez DeepSeek V4 pour des documents très longs, des conversations prolongées ou des agents qui enchaînent les appels d’outils, la bonne question n’est pas : « Le modèle économise-t-il 98 % de mémoire ? » La bonne question est : votre goulot d’étranglement est-il vraiment le KV cache ?

Les sources disponibles permettent de dire que V4 apporte une optimisation notable du KV cache en contexte long. Elles ne suffisent pas à inscrire « 98 % less memory » dans un plan de capacité, un budget GPU ou un argumentaire commercial .

La méthode la plus solide reste de benchmarker avec vos propres paramètres : longueur de contexte, batch size, concurrence, moteur de serving et matériel. Si votre charge est principalement limitée par le KV cache, les mécanismes de compression de V4 peuvent avoir beaucoup de valeur. Si le blocage vient plutôt des poids du modèle, des activations, des surcoûts du framework ou de la stratégie de concurrence, la réduction du KV cache ne produira pas mécaniquement la même baisse sur la VRAM totale .