DeepSeek V4.1-Flash : comment une architecture coupe en 8 la memoire des agents

DeepSeek a sorti V4.1-Flash le 10 septembre 2026. C'est un modèle MoE de 552 milliards de paramètres avec une nouvelle architecture appelée Causal Encoder-Decoder (CED). Le résultat principal : le KV cache, cette mémoire qui garde l'état d'une session entre les tours, est réduit d'un facteur 8 par rapport à la génération précédente. Les poids sont ouverts sous licence MIT, le contexte monte à un million de tokens, et le modèle traite nativement le texte et les images.

Le numéro de version, 4.1, suggère un point release. C'est pas ça. CED n'est pas un fine-tune ni un patch d'efficacité. C'est une nouvelle façon de structurer un transformer pour les workloads agentiques, où l'input est massif et l'output est court.

Le probleme que CED resout

Un agent de code qui lit un repo de 400 000 tokens pour produire un patch de 1 500 tokens. Un agent de recherche qui avale des centaines de pages pour synthétiser trois paragraphes. Ces deux workloads ont la meme forme : l'input est énorme, l'output est minuscule. Le ratio input/output peut dépasser 250 pour 1.

Un transformer classique (decoder-only, l'architecture derrière la plupart des LLMs) traite tous les tokens de la meme façon. Que ce soit du prompt ou de la génération, chaque token passe par toutes les couches et construit son KV state. Pendant la phase de prefill, le modèle ingère les 400 000 tokens du prompt et construit le KV cache pour chacun. Pendant la phase de decode, chaque token généré lit ce cache à chaque couche pour calculer l'attention.

Cette symétrie est élégante, mais elle est gourmande pour les workloads agentiques. Le modèle paie le coût complet de construction et de stockage du KV cache pour 400 000 tokens d'input, avec la meme mécanique qu'il utilise pour générer 1 500 tokens de sortie. Le KV cache, c'est de la mémoire vive coûteuse (HBM) ou du stockage SSD si ça déborde. Plus le contexte est long, plus le cache grossit, plus l'infrastructure coute cher.

Comment CED fonctionne

DeepSeek a coupé le transformer de 40 couches en deux. Les 20 premières couches forment un encodeur causal. Les 20 suivantes forment un decodeur.

L'encodeur traite le prompt en une seule passe. Il construit une representation compacte de l'input. Le mot "causal" est important : contrairement à un encodeur classique (comme BERT) où chaque token peut voir tous les autres tokens dans les deux sens, l'encodeur de CED est unidirectionnel. Chaque position ne voit que les tokens précédents. C'est la meme contrainte qu'un decoder-only model, mais appliquée à la partie encodeur.

Ce choix a un avantage d'ingénierie : la structure du cache reste compatible avec un decoder-only, ce qui simplifie le réusage du cache entre les sessions. Un encodeur bidirectionnel casserait cette compatibilité.

Le decodeur, lui, génère la réponse. Au lieu de reconstruire le KV cache à partir du prompt à chaque couche, il lit la representation que l'encodeur a déjà construite. C'est cette séparation qui produit la réduction du KV cache : l'encodeur stocke une representation compressée, pas le cache complet de toutes les couches.

Le résultat chiffré par DeepSeek : environ un quart de la mémoire HBM et un huitième du stockage SSD par rapport à V4-Flash, le modèle précédent. C'est une réduction structurelle, pas un réglage d'hyperparamètres.

Les benchmarks et ce qu'ils valent

DeepSeek a publié trois chiffres : GPQA Diamond à 90,9, Codeforces rating à 3471, et Terminal-Bench 2.1 à 90,6. L'entreprise décrit ces résultats comme supérieurs à ses propres modèles flagship, V4-Pro inclus, en performance, coût, vitesse et runtime total.

Ces chiffres sont produits par DeepSeek elle-meme. C'est la règle dans l'industrie : chaque lab publie ses propres benchmarks. La prudence habituelle s'applique. Lance tes propres evals sur ton workload avant de choisir. Un score GPQA de 90,9 ne te dit pas si le modèle gère bien tes contrats fournisseurs ou ton code de production.

Ce qui est vérifiable, c'est la migration silencieuse. Depuis le 14 septembre 2026, les requetes vers deepseek-v4-pro sont redirigées vers V4.1-Flash et facturées au tarif de V4.1-Flash. DeepSeek dit que ça restera comme ça jusqu'à la sortie d'un V4.1-Pro. Si ton code appelait deepseek-v4-pro, il parle déjà à V4.1-Flash depuis deux jours.

Le prix, et pourquoi il est agressif

Le pricing de V4.1-Flash a deux niveaux : heures creuses et heures de pointe. Les heures de pointe sont 01:00-04:00 UTC et 06:00-10:00 UTC, du lundi au vendredi. Tout le reste, y compris les weekends, est en heures creuses.

Composant	Heures creuses	Heures de pointe
Tokens cachés en entrée	0,003 $/M	0,006 $/M
Tokens en entrée (hors cache)	0,15 $/M	0,30 $/M
Tokens en sortie	0,60 $/M	1,20 $/M

Les heures creuses sont exactement la moitié du prix des heures de pointe, sur tous les tiers. Pour un workload qui peut tourner la nuit ou le weekend, c'est une réduction de 50% sans changer le modèle.

Le cache en entrée à 0,003 $/M en heures creuses, c'est 333 fois moins cher que le tarif hors cache. Pour les workloads agentiques qui répétent beaucoup de contexte (system prompt, documentation, instructions d'outils), le cache est la variable qui détermine le coût total. Si ton agent envoie 400 000 tokens de contexte répétable à chaque appel, le cache à 0,003 $/M contre 0,15 $/M hors cache fait passer la facture d'environ 60 dollars à 1,20 dollar pour 100 appels. C'est pas marginal.

Un exemple chez Maisons&Mobilia

Pierre, DSI chez Maisons&Mobilia (M&M, enseigne de meubles fictive), fait tourner des agents de revue de contrats sur l'API de DeepSeek. Son workload type : 300 000 tokens de contexte (documentation juridique, historique de contrats, instructions de format) envoyés à chaque session, et 2 000 tokens de sortie par contrat analysé.

Avant V4.1-Flash, avec V4-Flash, le KV cache de 300 000 tokens occupait beaucoup de mémoire HBM. Son fournisseur d'infrastructure lui facturait la capacité cache au prorata. Sur 50 sessions par jour, le coût de cache représentait environ 40% de sa facture IA mensuelle.

Avec V4.1-Flash, le cache est réduit d'un facteur 8. La meme session de 300 000 tokens occupe 8 fois moins de mémoire. Si Pierre utilise l'API de DeepSeek directement, il paie le cache à 0,003 $/M en heures creuses. S'il autohéberge le modèle (les poids sont en MIT), la réduction du cache lui permet de faire tourner plus de sessions simultanées sur la meme quantité de HBM.

Pierre remarque aussi que ses requetes vers deepseek-v4-pro sont maintenant redirigées vers V4.1-Flash et facturées moins cher. C'est une bonne nouvelle pour son budget, mais ça le pousse à vérifier que la qualité de ses agents ne baisse pas. Il lance une eval sur 100 contrats avec V4.1-Flash et compare le taux d'erreurs avec ses résultats précédents. Si les scores tiennent, il garde le routing automatique. Si ça baisse, il revient en arrière en attendant V4.1-Pro.

La limite : Pierre autohéberge une partie de ses modèles sur un serveur en France pour les données sensibles. V4.1-Flash en MIT, il peut le déployer. Mais la taille du modèle (552B params) demande une infrastructure GPU conséquente. Pour l'instant, il teste via l'API de DeepSeek sur des contrats anonymisés et garde le déploiement local pour plus tard.

Ce que ca change si tu apprends l'IA

1. L'architecture d'un modèle n'est pas fixe. Le decoder-only transformer a dominé depuis 2020. CED montre que les labs commencent à structurer leurs modèles pour les workloads réels : input massif, output court. Comprendre cette évolution, c'est savoir que l'architecture suit l'usage. Les agents ont une forme d'input/output très différente d'un chat, et les modèles s'adaptent.

2. Le KV cache est la variable qui rend les agents viables ou pas. Un agent qui garde 300 000 tokens de contexte entre les tours stocke du KV cache. Plus le cache est gros, plus ça coute en mémoire. La réduction d'un facteur 8 par CED, c'est ce qui permet à un agent de travailler plus longtemps sur un contexte plus large sans exploser l'infrastructure. La compétence pratique : savoir ce qu'est le KV cache et pourquoi il détermine le coût d'un agent.

3. L'open-weight suit le frontier de près, et innove sur l'architecture. DeepSeek est un lab chinois qui publie ses poids en MIT. V4.1-Flash n'est pas une copie d'un modèle fermé : c'est une architecture originale, optimisée pour les agents, avec un paper et des poids ouverts. Comprendre ça, c'est savoir pourquoi l'open-weight n'est pas juste "le frontier en retard". Sur l'architecture pour agents, DeepSeek est en train de montrer une direction que les labs fermés n'ont pas encore prise.

Aller plus loin

Pour comprendre comment un agent IA utilise des outils et enchaene des étapes, notre article sur comment fonctionne un agent IA pose les bases du tool use et de l'orchestration. Pour voir les garde-fous à mettre en place quand un agent accède à tes données, le guide sur les garde-fous des agents IA détaille le moindre privilège et le human in the loop. Pour comprendre le contexte de la bataille des frontier, notre article sur GPT-6 Astra et l'ere AGI couvre le modèle concurrent qui fixe le rythme actuel. Et pour t'entrainer à ces notions en 5 minutes par jour, l'app saisir.ai propose des modules interactifs sur les modèles, les agents et le déploiement, en français, sans coder.

Sources

• DeepSeek, "DeepSeek-V4.1-Flash: Pushing the Limits of KV Cache Compression", 10 septembre 2026
• DeepSeek API Docs, "DeepSeek-V4.1-Flash: Smarter, Faster, More Efficient", 10 septembre 2026
• DeepSeek API Docs, "Pricing", septembre 2026
• Hugging Face, "deepseek-ai/DeepSeek-V4.1-Flash", 10 septembre 2026
• Miraflow, "DeepSeek-V4.1-Flash Explained: The Causal Encoder-Decoder Architecture That Cuts KV Cache by 8x", 16 septembre 2026