DeepSeek V4.1-Flash réduit fortement la mémoire nécessaire aux agents IA

DeepSeek a lancé V4.1-Flash, un nouveau modèle multimodal conçu notamment pour diminuer l’un des coûts les plus difficiles à maîtriser avec les agents IA : la mémoire nécessaire pour conserver leurs longs contextes.

Selon le rapport technique de DeepSeek, le modèle ramène son cache KV global à 890 octets par token, soit environ un quart de celui de DeepSeek-V4-Flash. Le stockage persistant du cache peut, de son côté, être réduit à environ un huitième de celui de la génération précédente.

Ces chiffres sont significatifs pour les infrastructures qui exécutent des agents pendant de longues sessions. Mais une précision s’impose : un cache KV quatre fois plus petit ne signifie pas automatiquement que chaque GPU peut exécuter exactement quatre fois plus de sessions simultanées.

La mémoire occupée par les poids du modèle, les buffers, le runtime et d’autres éléments continue également de compter.

À retenir:

• DeepSeek-V4.1-Flash réduit son cache KV global à 890 octets par token.
• DeepSeek annonce environ 4× moins de mémoire HBM pour ce cache que sur V4-Flash.
• Le cache persistant peut nécessiter environ 8× moins de stockage SSD ou mémoire hôte.
• Le modèle compte 552 milliards de paramètres, mais n’en active que 8 milliards pendant le traitement des entrées et 16 milliards pendant la génération.
• Les gains concernent principalement l’efficacité d’inférence et ne garantissent pas à eux seuls un coût total ou une capacité de sessions exactement multipliés par quatre.

Pourquoi les agents IA consomment autant de mémoire

Lorsqu’un grand modèle de langage traite une conversation, il ne recommence pas tous ses calculs depuis zéro à chaque nouveau mot.

Il conserve une partie des calculs précédents dans ce qu’on appelle un cache KV, pour Key-Value cache. Celui-ci permet au modèle de retrouver rapidement les informations déjà traitées lorsqu’il génère les tokens suivants.

Le problème apparaît lorsque le contexte devient énorme.

Un agent IA peut accumuler des centaines de milliers de tokens provenant de conversations, de fichiers, de pages web, d’appels d’outils ou de résultats générés pendant plusieurs étapes.

Plus ce contexte grandit, plus le cache KV peut occuper de mémoire GPU.

Avec des contextes pouvant atteindre un million de tokens, comme celui annoncé pour V4.1-Flash, cette consommation devient un enjeu important pour les serveurs chargés d’exécuter de nombreuses sessions simultanément.

Comment DeepSeek arrive à 890 octets par token

La réduction ne provient pas d’une seule technique.

DeepSeek utilise notamment une nouvelle architecture baptisée Causal Encoder-Decoder, ou CED. Le modèle comprend 40 couches Transformer réparties entre un encodeur causal de 20 couches et un décodeur de 20 couches.

Au lieu de recréer un cache KV totalement indépendant dans chaque couche du décodeur, certaines informations peuvent être projetées ou réutilisées depuis l’encodeur.

Le modèle combine cette approche avec Compressed Sparse Attention 2, ou CSA2. Cette architecture définit plusieurs modes de fonctionnement permettant à certaines couches de réutiliser des informations KV ou des index d’attention déjà calculés.

DeepSeek ajoute également une compression FP4, utilisant une représentation sur quatre bits pour une partie du cache.

D’après le rapport technique, l’ensemble de ces techniques fait passer le cache KV global à 890 octets par token, contre environ quatre fois plus pour V4-Flash.

8 milliards de paramètres actifs pour lire les entrées

DeepSeek-V4.1-Flash est un modèle Mixture-of-Experts, ou MoE, de 552 milliards de paramètres.

Ce chiffre pourrait laisser penser qu’il faut mobiliser les 552 milliards de paramètres à chaque token. Ce n’est pas le cas.

La nouvelle architecture n’active que 8 milliards de paramètres par token pendant la phase de prefill, lorsque le modèle ingère le contexte existant. Lorsqu’il génère sa réponse, ce chiffre passe à 16 milliards de paramètres actifs par token.

Cette asymétrie est particulièrement intéressante pour les agents.

Un agent peut lire un contexte immense avant de produire une réponse relativement courte. Réduire le coût de cette première étape peut donc avoir davantage d’impact que d’optimiser uniquement la génération.

DeepSeek présente justement V4.1-Flash comme un modèle destiné aux charges de travail très riches en entrées.

Pourquoi « 4× plus de sessions par GPU » est trop simpliste

C’est ici que certains titres autour de V4.1-Flash peuvent devenir trompeurs.

Si une application était entièrement limitée par la mémoire utilisée par son cache KV, réduire ce cache à un quart pourrait théoriquement permettre d’augmenter fortement le nombre de contextes stockés dans la même quantité de mémoire.

Mais un GPU ne stocke pas uniquement le cache KV.

Il faut également tenir compte des poids du modèle, des activations temporaires, des buffers d’inférence, du moteur utilisé et de la façon dont les requêtes sont regroupées.

Il est donc plus exact de dire que V4.1-Flash augmente potentiellement la densité de sessions et réduit la pression sur la mémoire, plutôt que d’affirmer qu’un GPU exécutera systématiquement quatre fois plus d’agents.

DeepSeek lui-même formule son annonce en termes de réduction de HBM et de stockage SSD, sans garantir une multiplication universelle par quatre du nombre de sessions.

Le stockage persistant pourrait être encore plus intéressant

DeepSeek ne s’est pas limité à la mémoire GPU.

La société introduit également une technique appelée SWA Bounded Replay.

Son objectif est d’éviter de stocker en permanence l’intégralité de certaines données liées à la sliding-window attention lorsqu’une session est suspendue.

Une partie du contexte peut être reconstruite lors de la reprise en rejouant une fenêtre récente de tokens.

Selon DeepSeek, cette méthode permet de réduire le cache KV persistant à environ un huitième de celui de V4-Flash.

Pour les services hébergeant des milliers de conversations ou d’agents capables de rester inactifs avant de reprendre leur travail, ce gain sur le SSD ou la mémoire hôte peut être particulièrement important.

Une avancée importante, mais encore largement documentée par DeepSeek

DeepSeek affirme également que V4.1-Flash offre de meilleures performances que plusieurs modèles précédents de la marque sur des benchmarks destinés aux agents et au code.

Il faut toutefois séparer ces résultats de l’amélioration architecturale.

Les chiffres de benchmarks actuellement mis en avant proviennent principalement de DeepSeek et de sa documentation de lancement. Ils ne constituent donc pas encore une validation indépendante complète de toutes les performances revendiquées en production.

En revanche, les caractéristiques architecturales publiées sont suffisamment détaillées pour rendre le sujet intéressant au-delà d’un simple classement de benchmarks.

Le véritable enjeu est économique.

À mesure que les agents IA utilisent davantage d’outils et conservent des historiques plus longs, la quantité de mémoire nécessaire à chaque session devient une composante majeure du coût d’inférence.

V4.1-Flash montre que les prochaines avancées pourraient donc venir autant de la compression de la mémoire que de l’augmentation brute de la puissance des modèles.

Pour suivre les nouvelles architectures, modèles et tendances liées à l’intelligence artificielle sur Tech Explorateur, cette évolution de DeepSeek constitue un bon exemple du déplacement actuel de la compétition : il ne s’agit plus seulement de produire le modèle le plus performant, mais aussi celui que l’on peut réellement faire tourner à grande échelle.

FAQ:

Qu’est-ce que DeepSeek V4.1-Flash ?

DeepSeek V4.1-Flash est un modèle multimodal Mixture-of-Experts de 552 milliards de paramètres, optimisé notamment pour les agents IA et les contextes très longs.

DeepSeek a-t-il vraiment réduit la mémoire par quatre ?

DeepSeek annonce que le cache KV global de V4.1-Flash utilise environ quatre fois moins de HBM que celui de V4-Flash. Cela ne signifie pas que toute la consommation mémoire du modèle est divisée par quatre.

DeepSeek V4.1-Flash peut-il exécuter quatre fois plus d’agents ?

Pas nécessairement. La réduction du cache KV peut permettre davantage de sessions concurrentes, mais la capacité réelle dépend aussi des poids du modèle, du runtime, des buffers et du matériel utilisé.

Sources officielles et fiables:

• DeepSeek — annonce officielle de V4.1-Flash et réduction du cache KV : Consulter l’annonce officielle DeepSeek
• Rapport de recherche DeepSeek-V4.1-Flash — Pushing the Limits of KV Cache Compression : Consulter la publication scientifique sur arXiv
• DeepSeek — fiche officielle du modèle et détails de l’architecture sur Hugging Face : Consulter DeepSeek-V4.1-Flash sur Hugging Face
• DeepSeek API — journal officiel des changements du 10 septembre 2026 : Consulter le changelog DeepSeek API