This article is currently available in French only.
Regardez le classement d'Artificial Analysis, qui agrège dix évaluations. V4.1 Flash y est au niveau de Gemini 3.8 Flash et de Qwen 3.8, devant GPT-5.6 Luna, à quatorze points des meilleurs modèles fermés. Un modèle de 552 milliards de paramètres, open weightsLes poids du modèle sont publiés : on peut les télécharger et déployer le modèle sur ses propres serveurs, sans passer par l'API de l'éditeur. Pour 552 milliards de paramètres, il faut quand même un serveur à plusieurs GPU., licence MITUne licence très permissive : usage commercial libre, sans redevance. : les poids se téléchargent et se déploient sur ses propres serveurs, sans passer par l'API de qui que ce soit. Pas sur un portable : il faut un serveur à huit GPULa carte de calcul spécialisée qui fait tourner le modèle. pour tenir les 550 Go de poids.
Et DeepSeek n'a rien de ce qu'ont les laboratoires américains. Une équipe de 120 à 200 personnes, quand OpenAI en compte 7 800 : quarante fois moins. Pas d'accès aux dernières puces Nvidia, interdites à l'export vers la Chine. Pas de datacenter géant. Ils sont sévèrement sous contrainte.
De la contrainte naît la créativité.
Alors, comment ont-ils fait ? La réponse tient dans un chiffre : le cache de contexte de V4.1 Flash pèse 890 octets par tokenLe morceau de texte que le modèle lit ou écrit d'un coup : un mot, un bout de mot ou un signe de ponctuation. Mille pages, c'est environ 500 000 tokens.. Quatre fois moins que V4 Flash sorti quelques mois plus tôt. Quatre cents fois moins que la première génération. Un contexte d'un million de tokens tient dans environ 0,9 Go de mémoire. Sur un GPU, ça change tout. Sur un serveur on-premiseInstallé sur les serveurs de l'entreprise elle-même, pas dans un cloud public. dans le périmètre d'une banque, ça change encore plus.
Cet article décortique comment ils ont fait. Le papier technique est dense, l'architecture est contre-intuitive, et certaines décisions ont l'air fausses tant qu'on n'a pas compris le raisonnement. Une fois compris, c'est brillant.
Deux phases, un goulot
Quand vous envoyez un promptCe qu'on envoie au modèle : la question, les consignes, les documents joints. à un LLMGrand modèle de langage : le programme qui lit et écrit du texte, comme celui derrière ChatGPT., deux choses se passent, et elles ne se ressemblent pas.
La première est le prefillLa phase de lecture : le modèle parcourt tout ce qu'on lui a donné avant d'écrire le premier mot.. Le modèle lit votre prompt, vos documents, votre codebase. Chaque token traverse toutes les couchesUn étage du réseau de neurones. Le texte traverse les couches l'une après l'autre, chacune affine la compréhension. du réseau, et chaque couche calcule pour chaque token deux vecteurs : une clé (K) et une valeur (V). Tout ça est stocké dans le KV cacheLes notes que le modèle prend en lisant. Pour chaque token, il garde une clé (K) et une valeur (V), pour ne pas tout relire à chaque mot qu'il écrit.. Ce sont les notes que le modèle prend en lisant.
La seconde est le decodeLa phase d'écriture : le modèle produit sa réponse, un token à la fois.. Le modèle écrit sa réponse, un token à la fois. Pour choisir chaque token, il relit ses notes plutôt que de tout recalculer. C'est ce qui rend la génération possible à vitesse raisonnable.
Sur un prompt court, tout tient dans la mémoire rapide du GPU, la HBMLa mémoire ultra-rapide soudée au processeur du GPU. Très chère, donc petite : quelques dizaines de Go.. Le problème commence quand on veut des agentsUn modèle qui enchaîne des actions (lire un fichier, lancer un outil, relire le résultat) pour accomplir une tâche, au lieu de répondre en une fois. qui tournent des heures sur des centaines de documents. Le KV cache explose, déborde de la HBM, et finit sur SSDLe disque de stockage du serveur : immense, mais des centaines de fois plus lent que la HBM.. À ce moment-là, chaque token généré exige d'aller chercher des données de l'autre côté de la carte mèreLe circuit principal du serveur, qui relie le GPU, la mémoire et les disques.. Le GPU attend. La latenceLe temps d'attente avant la réponse. explose, le coût aussi.
C'est exactement le scénario d'un agent qui analyse des liasses fiscales toute la journée. Le goulot n'est pas le calcul. C'est le déplacement de données.
Couper le modèle en deux
Un transformeurL'architecture de réseau de neurones derrière tous les grands modèles de langage : une pile de couches qui lisent le texte en pesant l'importance de chaque mot pour les autres. classique est une pile de couches identiques. Chaque couche lit le contexte, calcule ses propres K et V, et les stocke.
DeepSeek casse ce schéma. V4.1 Flash est un transformeur de 40 couches organisé en 20 couches d'encodeur causalIci, la première moitié des couches : celles qui lisent le contexte et prennent les notes. suivies de 20 couches de décodeurIci, la seconde moitié des couches : celles qui écrivent la réponse.. Le nom est trompeur : ce n'est pas un encodeur-décodeurL'architecture classique de traduction (T5, par exemple) : un premier réseau lit la phrase d'entrée, un second, séparé, écrit la sortie. à la T5, tout reste autorégressifQui écrit un token à la fois, chaque token dépendant des précédents.. La différence est dans ce que chaque moitié calcule.
Pendant le prefill, seul l'encodeur travaille. Les 20 premières couches lisent l'intégralité du contexte et produisent un KV cache global. Les 20 dernières ne lisent rien : elles ne voient que les 128 derniers tokens, juste pour construire leur contexte local.
Pendant le decode, le décodeur prend le relais. Mais au lieu de calculer son propre cache global couche par couche, il projette ses clés et valeurs globales directement depuis les états cachésLes nombres internes qu'une couche produit pour représenter chaque token : sa compréhension du texte à cet étage. de la dernière couche de l'encodeur. Vingt couches partagent un seul cache global, dérivé d'une seule représentation.
C'est ce qui explique un chiffre qui semble impossible : 8 milliards de paramètres actifsLes paramètres réellement mobilisés pour traiter un token, sur le total que le modèle contient. par token en prefill, 16 milliards en decode, sur un backboneLe réseau principal du modèle, hors modules annexes comme Engram. de 552 milliards. Le mélange d'expertsLe modèle est découpé en spécialistes, les experts. Pour chaque token, seuls quelques-uns travaillent : ici 1 partagé + 6 choisis sur 384. (1 expert partagé + 6 experts routés sur 384) fait le reste.
Le risque est évident. Si la moitié du modèle ne lit pas le contexte, ne devient-il pas plus bête ? La réponse tient dans la distinction entre contexte global et contexte local.
Global vs local : le résumé exécutif et la page ouverte
Le contexte global, c'est tout ce qu'on a donné au modèle. Les mille pages de rapports, l'historique de la conversation, le prompt système. Le contexte local, c'est la phrase en cours d'écriture. Les quelques dizaines de tokens immédiatement pertinents pour choisir le suivant.
Le décodeur de V4.1 Flash ne recalcule jamais le global. Il le reçoit de l'encodeur. Mais il calcule bien son propre contexte local, via une sliding window attentionChaque token ne regarde que ses voisins les plus récents, ici les 128 derniers, au lieu de tout le texte. : une fenêtre glissante qui ne regarde que les tokens les plus récents.
L'analogie qui marche : une équipe d'analystes juniors lit les mille pages et rédige une synthèse dense. Les associés seniors ne lisent jamais les mille pages. Ils travaillent sur la synthèse. Mais au moment de signer un document, ils mettent leurs lunettes et scrutent chaque mot de la page devant eux. La synthèse pour la direction, la page pour l'exécution.
Résultat : la moitié du modèle n'a plus à générer de cache global. Le coût de lecture est divisé par deux.
CSA2 : trois modes pour arrêter de prendre les mêmes notes
Réduire le calcul, c'est bien. Mais le cache existe toujours. Comment le compresser de 3 500 octets par token (V4 Flash) à 890 sans perdre de compréhension ?
Le mécanisme s'appelle Compressed Sparse Attention 2Le mécanisme d'attention de V4.1 Flash : il compresse les notes, ne lit qu'une sélection de tokens et partage les notes entre couches.. Le point de départ est une observation simple : dans un transformeur classique, chaque couche calcule son propre KV et son propre indexUne table qui dit, pour chaque token, quels tokens du cache valent la peine d'être lus. Une table des matières. d'attention sparseL'opération par laquelle un token va chercher, dans les autres tokens, ce qui l'aide à être compris. Sparse : on ne regarde qu'une sélection de tokens, pas tous.. C'est massivement redondant.
CSA2 assigne à chaque couche d'attention un mode statique parmi trois.
En mode Full, la couche fait tout le travail. Elle calcule son KV de zéro et construit un index : une structure qui permet aux couches suivantes de retrouver rapidement les bons tokens sans parcourir tout le cache. Une table des matières.
En mode Reindex, la couche réutilise le KV d'une couche Full. Elle ne stocke rien de nouveau. Mais elle construit son propre index, une table des matières différente sur les mêmes notes. Si la couche Full indexe par chronologie, la couche Reindex peut indexer par thème ou par entité. Deux chemins de lecture sur un seul stockage.
En mode Reuse, la couche ne construit rien. Elle emprunte le KV d'une couche Full et les indices Top-KLes K meilleurs : ici, les tokens les mieux notés par l'index. K = 512 dans V4.1 Flash. d'une couche Full ou Reindex. Coût mémoire quasi nul.
Concrètement, sur les 40 couches de V4.1 Flash, seules 4 écrivent vraiment leurs notes (mode Full) : une par groupe de six dans l'encodeur, une seule pour tout le décodeur. Toutes les autres relisent les notes d'une voisine. Quarante couches, quatre caches au lieu de quarante.
Par-dessus ça, les notes elles-mêmes sont écrites plus petit : chaque nombre du cache tient sur 4 bitsL'unité de base de l'information. Sur 4 bits on peut écrire 16 valeurs différentes, sur 8 bits 256. au lieu de 8. C'est comme noter un montant à l'euro près plutôt qu'au centime : un peu moins précis, deux fois moins de place. Et comme le modèle est entraîné dès le départ avec cette précision, il ne perd rien en pratique. Pour les curieux : format E2M1, avec une échelle E4M3 partagée par bloc de 16 canaux.
Des notes partagées entre couches, écrites deux fois plus petit : c'est la combinaison qui donne les 890 octets.
Le portier : 16 000 tokens sur un million
DeepSeek ajoute un étage : un indexeur sparse hiérarchiqueLe petit module qui note chaque token du cache pour repérer lesquels valent la peine d'être lus..
La première couche du décodeur agit comme un portier. Elle parcourt le KV cache global hérité de l'encodeur et produit un pool de candidats : sur un contexte d'un million de tokens, elle en retient environ 16 000. Les couches suivantes n'ont pas le droit de chercher ailleurs. Dans ce pool, chacune choisit ensuite les 512 tokens qui l'intéressent vraiment.
Là encore, l'intuition dit que ça doit dégrader la qualité. Si le modèle ne regarde que 1,6 % du contexte, il va rater des choses. Sauf que le portier est entraîné pour que sa sélection soit assez bonne pour que les couches suivantes ne remarquent pas l'absence du reste. La restriction est brutale en principe et invisible en pratique.
Il faut mesurer ce que ça veut dire pour un labo sans accès aux meilleurs GPU Nvidia et sans mega-datacenter. Plutôt que d'attendre du hardwareLe matériel : GPU, serveurs, mémoire., ils ont réécrit le logiciel pour que le hardware ait moins à faire.
SWA Bounded Replay : supprimer la mémoire à court terme
C'est la partie la plus contre-intuitive du papier.
La fenêtre glissante produit elle aussi un cache local. Dans une conversation multi-toursUne conversation en plusieurs échanges : chaque nouvelle question s'ajoute à l'historique., ce cache local doit être persistéConserver sur disque entre deux échanges, au lieu de recalculer. entre les tours pour que le modèle garde le fil. Et cette persistance saturait les SSD. Le stockage de l'agent se remplissait de notes de court terme.
La solution de DeepSeek : ne plus l'archiver. Le cache SWA ne va plus sur SSD, il vit quelques minutes dans la RAM du serveurLa mémoire vive de l'ordinateur qui héberge le GPU : bien plus grande que la HBM, mais plus lente d'accès pour le GPU., le temps de la session. Et s'il manque au tour suivant, le modèle rejoue les 128 derniers tokens (la taille de la fenêtre) pour reconstruire l'état local à la volée.
Ça a l'air absurde après avoir passé tout l'article à réduire le calcul. Mais regardez l'arbitrage. Persister, c'est pousser des données du GPU vers le SSD à travers la carte mère, puis les rapatrier au tour suivant. Rejouer 128 tokens sur un GPU moderne, c'est quelques millisecondes de calcul. Le calcul est moins cher que le transfert.
Le KV cache persistant tombe à environ un huitième de celui de V4 Flash. Pour un agent qui enchaîne des centaines de tours sur une journée, c'est la différence entre un stockage qui sature et un stockage qui tient.
Les trois briques de support
Trois composants secondaires complètent l'architecture.
Single-Pass mHC. Faire tourner un LLM, ce n'est pas que du calcul, c'est aussi du trafic mémoire à l'intérieur du GPU. Chaque opération produit des valeurs intermédiaires que l'opération suivante recharge. Multipliez par des milliards de fois. mHC réorganise le mélange du flux résiduelLe chemin principal par lequel l'information circule de couche en couche, chaque couche y ajoutant sa contribution. pour fusionner plusieurs opérations en une passe, avec un kernelUn petit programme qui exécute une opération sur le GPU. dédié. Moins d'allers-retours mémoire, plus de vitesse.
Engram. Un module de mémoire conditionnelle de 196 milliards de paramètres qui ne vit pas dans la HBM du GPU mais dans la RAM du serveur. Il stocke les faits statiques, accessibles par lookupUne simple recherche dans une table, sans calcul. basé sur les tokens. L'idée : le GPU doit être réservé au raisonnement, pas à la mémorisation de dates et de capitales. C'est l'assistant à côté de l'avocat senior. L'avocat raisonne, l'assistant sort la clause exacte à la demande.
DSpark. Du décodage spéculatifUn petit modèle rapide devine plusieurs mots d'avance, le grand modèle les vérifie d'un coup : plus de mots par seconde. semi-autorégressif : le modèle produit un brouillon de plusieurs tokens, puis les vérifie avec une planification basée sur la confiance. Au lieu d'un mot à la fois, plusieurs. C'est ce qui donne les débits de sortie annoncés.
Ce que ça change concrètement
La figure la plus parlante du papier trace les FLOPsLe nombre d'opérations de calcul. Plus il y en a, plus c'est long et cher. de decode en fonction de la taille du contexte, de 4 000 tokens à un million. Sur les générations précédentes, la courbe monte. Sur V4.1 Flash, elle est presque plate. Répondre à une question sur une page ou sur mille pages coûte à peu près la même chose par token généré.
Côté performance, le modèle est au niveau ou devant des modèles frontièreLes meilleurs modèles du moment, généralement fermés : GPT, Claude, Gemini. sur les benchmarksDes tests standardisés pour comparer les modèles. agentiques (Terminal-Bench 2.1Tâches à accomplir dans un terminal de commandes, comme un développeur., DeepSWE v1.1Correction de bugs dans de vrais projets logiciels., CyberGymRecherche de vulnérabilités dans de vrais logiciels.), tout en restant en retrait sur certains benchmarks de connaissance pure et de long contexte. C'est cohérent avec les choix : le modèle a été conçu pour des charges de travail où l'entrée est massive et la sortie courte, typiquement un agent qui lit des résultats d'outils et des documents. Pas pour un quiz de culture générale.
Et le paramètre d'effort de raisonnement est continu, de 1 à 100, réglable par requête. Pas de mode « rapide » ou « lent » à choisir, un curseur de coût.
Pourquoi ça nous parle
Chez Pixelia, on déploie des systèmes agentiques dans le périmètre de banques marocaines. Nos contraintes ressemblent à celles de DeepSeek : hardware limité, pas de cloud public, des documents longs et des agents qui tournent longtemps.
Un modèle ouvert de niveau frontière dont le cache tient dans moins d'un giga par million de tokens, ça veut dire qu'un serveur on-premise, une machine à huit GPU, pas un datacenter, peut faire tourner un agent qui garde en tête une liasse fiscale complète, l'historique du dossier et le référentiel de règles, sans dégrader la latence. C'est le genre de détail d'architecture qui décide si un projet reste en démo ou passe en production.
DeepSeek n'a pas battu le hardware. Ils ont arrêté de lui demander de travailler pour rien.