DeepSeek réduit le cache mémoire de son modèle à 890 octets par token, contre 3514 auparavant

DeepSeek a publié sur Hugging Face le modèle DeepSeek-V4.1-Flash, accompagné d'un article. Ce dernier consacre moins de place à la qualité des réponses qu'au coût de stockage de la mémoire. Quand un modèle de langage lit un long texte, il mémorise pour chaque token des données intermédiaires du mécanisme d'attention. C'est le cache KV. Il évite de tout recalculer à chaque nouveau mot généré, et il s'alourdit à mesure que le contexte s'allonge. Dans V4.1-Flash, le cache global en HBM (la mémoire la plus rapide de la carte graphique) occupe 890 octets par token. La précédente V4-Flash en demandait 3514. Pour une session d'un million de tokens, cela représente environ 0,9 Go au lieu de 3,5 Go.

Le modèle est multimodal et repose sur une architecture MoE (mixture of experts) : pour chaque token, seule une partie des experts travaille. Son tronc principal compte 552 milliards de paramètres. 196 milliards d'autres résident dans les tables de mémoire Engram. Le contexte est dimensionné pour 1M tokens. L'article compte environ 500 auteurs. Le code d'entraînement n'est pas publié, mais les poids le sont.

Trois techniques pour alléger le coût de service

La principale nouveauté architecturale est un schéma encodeur-décodeur causal, abrégé en CED. Presque tous les meilleurs modèles ouverts sont en decoder-only : une même pile de couches lit la requête et écrit la réponse. Ici, la pile est scindée. Pendant le prefill, lorsque le modèle lit le prompt, 8 milliards de paramètres sont actifs. Au décodage, c'est-à-dire pendant la génération de la réponse, ils sont 16 milliards. Cette approche s'apparente à l'idée de YOCO, où le cache est calculé une seule fois puis réutilisé.

Deuxième technique : le mécanisme d'attention CSA2. Il prend le cache au format FP4, qui stocke les nombres sur seulement quatre bits, et le réutilise entre les couches. Auparavant, chaque couche gardait sa propre copie.

Troisième technique : SWA Bounded Replay. L'attention à fenêtre glissante ne regarde que les derniers tokens. Son cache local devait jusqu'ici être écrit sur disque pour pouvoir reprendre une session plus tard. Ce n'est plus le cas : à la reprise, un fragment borné est recalculé. Cela consomme du calcul, mais décharge le disque.

Bilan côté mémoire :

• cache en HBM : 890 octets par token au lieu de 3514, soit presque 4 fois moins ;
• cache durable sur SSD : environ 1/8 du volume de V4-Flash ;
• paramètres actifs : 8 milliards au prefill et 16 milliards au décodage.

Ce que montrent les benchmarks

Une économie ne suffit pas si le modèle perd en intelligence. Les auteurs ont donc comparé leur modèle à son prédécesseur et au Opus-5 fermé sur des tâches agentiques, où le modèle manipule lui-même du code et un terminal.

• DeepSWE v1.1 est un ensemble de tâches d'ingénierie logicielle : l'agent modifie du code pour corriger un problème précis. V4.1-Flash en résout 74,2%. V4-Flash en résolvait 54,4%, et Opus-5 74,0%.
• Terminal-Bench 2.1 regroupe des tâches en ligne de commande. Le Pass@1, c'est-à-dire la part de tâches résolues dès la première tentative, atteint 90,6% pour V4.1-Flash. Il est de 82,7% pour V4-Flash et de 89,1% pour Opus-5.

Le gain de presque 20 points de pourcentage sur DeepSWE est notable. Sur les deux tests, le modèle ouvert devance le modèle fermé, même si, sur DeepSWE, l'écart de 0,2 point reste dans la marge de bruit habituelle.

Où subsistent des questions

L'intérêt pratique de ce travail est que les sessions agentiques d'un million de tokens se heurtent désormais aux capacités de calcul, et non plus au volume de HBM ou de SSD réservé au cache. Une longue session d'agent, qui accumule pendant des semaines l'historique des modifications et des logs de terminal, coûte moins cher. Une seule carte peut héberger davantage de ces sessions en parallèle. Pour les entreprises qui hébergent elles-mêmes leurs modèles, c'est une économie directe sur le matériel.

Ce résultat appelle toutefois des réserves. Les auteurs n'ont pas présenté d'ablations par composant, c'est-à-dire qu'ils n'ont pas désactivé les techniques une à une, et l'on ne sait pas laquelle des trois génère l'essentiel de l'économie. Il n'y a pas non plus de courbes de qualité de récupération d'information dans le contexte sur le million de tokens complet. La « fenêtre de 1M » annoncée est moins bien étayée qu'on le souhaiterait. Sur les tâches scientifiques complexes de Terminal-Bench 4.0, le modèle est nettement distancé : 31,2% contre 51,8% pour Opus-5.

Par ailleurs, V4.1-Flash semble être le seul grand modèle ouvert à s'écarter du decoder-only pur. Jusqu'ici, on n'avait guère vu une telle démarche que dans T5Gemma, avec son architecture encodeur-décodeur. Si des mesures indépendantes confirment le gain, d'autres laboratoires pourraient adopter cette séparation de la pile entre lecture et génération.