La version courte
DeepSeek V4.1 Flash combine un encodeur-décodeur causal, un état d’attention clairsemée partagé, un cache KV principal en FP4 et le rejeu borné pour réduire la charge de calcul et de stockage liée à l’inférence. Notre relevé de rédaction fait de l’effort par défaut une option prometteuse pour des brouillons peu coûteux, avec des limites aux comparaisons de rang et de coût.
- Le cache KV global de V4.1 occupe environ le quart de celui de V4 Flash ; ce n’est pas toute la mémoire du modèle.
- L’effort par défaut prenait en moyenne 43 secondes et coûtait 0,007744 $ par brouillon dans notre relevé du 10 septembre.
- Comparez le texte utilisable et le temps de révision sur vos propres évaluations avant de payer pour plus de raisonnement.
Dans notre benchmark de rédaction, DeepSeek V4.1 Flash a pris en moyenne 43 secondes par brouillon de script, pour moins d’un cent américain. C’est ce résultat qui a changé ma sélection de modèles pour rédiger à grande échelle. Le rapport explique pourquoi ce modèle mérite aussi l’attention des ingénieurs qui construisent des agents fonctionnant longtemps.
Son réseau principal compte 552 milliards de paramètres, soit presque deux fois les 284 milliards de V4 Flash. Pourtant, son cache KV global utilise environ le quart de la mémoire par token. L’équipe a créé un modèle plus gros tout en réduisant un des coûts qui augmentent avec la conversation.
Je suis Louis-François, CTO et cofondateur de Towards AI. Nous aidons les ingénieurs à devenir des ingénieurs en IA qui construisent et livrent des produits d’IA. Notre nouveau livre, AI Engineering For Production, sera lancé le 20 octobre 2026. Ce modèle illustre bien le type de compromis que ces produits exigent.
Pourquoi le cache compte pour les agents
Un agent ajoute des appels d’outils, des résultats et des messages à sa conversation. La requête suivante a besoin de cet historique. Un cache de préfixe réutilisable peut éviter de recalculer l’état d’attention de la partie inchangée, même si les fournisseurs peuvent encore facturer cet input en cache. Le suffixe restant doit toujours être traité.
Le cache KV conserve les clés et les valeurs utilisées par l’attention. Il permet au modèle de réutiliser des calculs antérieurs pendant la génération de nouveaux tokens. Il constitue une partie de la mémoire d’inférence, avec les poids du modèle et les autres états de travail. Il ne contient pas tout ce que le modèle sait et n’explique pas comment celui-ci comprend le langage.
Les longs contextes rendent ce cache coûteux à conserver et à déplacer. DeepSeek V4.1 s’attaque à cette pression par trois changements liés : moins de calcul pour le prompt, davantage de partage de l’état d’attention global et moins d’instantanés locaux persistants. Les détails viennent du rapport technique de DeepSeek, surtout des sections 2.2, 2.3 et 3.2.1–3.2.2. Lire le rapport.
Ce qui a vraiment changé par rapport à V4 Flash
V4 Flash utilisait déjà l’attention clairsemée compressée. Les architectures encodeur-décodeur et la réutilisation du cache entre les couches reposent aussi sur des travaux antérieurs. La contribution de V4.1 est la conception précise et la stratégie de déploiement décrites dans ce rapport.
| Mécanisme | Ce que V4.1 change |
|---|---|
| Traitement du prompt | Une séparation encodeur-décodeur causale permet à la plupart des tokens du prompt de traverser uniquement l’encodeur. |
| État d’attention | CSA2 partage davantage l’état KV global et le travail d’indexation entre les couches. |
| Précision du cache | Le cache KV global principal passe de FP8 à FP4. L’indexeur de V4 utilisait déjà FP4. |
| Stockage persistant | Le rejeu borné reconstruit l’état d’attention local au lieu de conserver tous les instantanés locaux à long terme. |
Traiter la majeure partie du prompt dans 20 couches
Le réseau comporte 20 couches d’encodeur et 20 couches de décodeur. Le décodeur dérive ses clés et valeurs globales de la sortie finale de l’encodeur, plutôt que de faire traverser toutes ses couches à chaque token du prompt pour construire cet état global. Il a encore besoin d’un état d’attention local propre à chaque couche, reconstruit en rejouant une fenêtre de 128 tokens.
C’est pourquoi le modèle active environ 8 milliards de paramètres pendant le préremplissage et 16 milliards pendant la génération. Le calcul de préremplissage presque réduit de moitié correspond au fait d’éviter la majeure partie du traitement du décodeur dans cette architecture. Ce n’est pas une promesse mesurée que chaque requête prendra moitié moins de temps qu’avec V4 Flash.
Le rapport cite des travaux antérieurs, dont YOCO. V4.1 introduit cette organisation par rapport à V4 Flash tout en s’appuyant sur les recherches antérieures sur les encodeurs-décodeurs et le partage du cache.
Le schéma d’architecture du rapport, présenté à 05:35 dans la vidéo source.
Partager le cache et le travail de recherche
Dans la configuration présentée, quatre des 40 couches créent un nouvel état KV global. La plupart des autres couches le réutilisent ; les deux premières utilisent seulement l’attention à fenêtre glissante. CSA2 partage aussi une partie de l’état de l’indexeur et des positions sélectionnées entre les couches.
Les modes de fonctionnement de CSA2, présentés à 06:33 dans la vidéo source.
L’attention clairsemée sélectionne 512 entrées globales, en plus d’une fenêtre locale de 128 tokens. La première couche d’indexation globale du décodeur parcourt le contexte visible et crée un ensemble pouvant contenir 16 384 positions candidates. Les couches d’indexation suivantes cherchent dans cet ensemble, tandis que certaines couches réutilisent une sélection antérieure. Cela réduit le travail de recherche répété. Le premier parcours dépend toujours de la longueur du contexte.
Le cache KV principal passe aussi de FP8 à FP4, avec un surcoût pour les facteurs d’échelle de quantification. Ensemble, ces changements font passer le stockage du cache global de 3 514 à 890 octets par token. Un cache global d’un million de tokens occupe environ 0,89 Go. Ce chiffre exclut les poids du modèle et les autres besoins en mémoire pour le faire fonctionner.
L’indexation clairsemée hiérarchique, présentée à 07:25 dans la vidéo source.
Reconstruire l’état local au besoin
La stratégie de déploiement de V4.1 évite de conserver à long terme tous les instantanés des fenêtres glissantes de chaque couche. Les instantanés de l’encodeur peuvent rester brièvement dans la mémoire de l’hôte pour les sessions actives. Lorsqu’un état nécessaire est absent, le rejeu borné en reconstruit une approximation à partir d’un court suffixe en cache. L’état à fenêtre glissante du décodeur est reconstruit pendant le préremplissage plutôt que conservé dans le cache de préfixe.
Cette approximation compte. Rejouer 128 tokens ne reconstruit pas exactement l’état d’origine de chaque couche. DeepSeek rapporte un effet négligeable sur la qualité dans ses tests et reconnaît que des cas limites sont possibles, sans publier d’étude d’ablation chiffrée consacrée à cette approximation.
En combinaison avec le cache global plus petit, l’analyse de déploiement rapporte une empreinte KV persistante d’environ un huitième de celle de V4 Flash. C’est un résultat sur le stockage du cache. Le coût d’une application dépend encore de la charge de travail, du fournisseur, de la réutilisation du cache et des tokens générés.
Là où les performances ont encore des limites
V4.1 Flash accepte des images et du texte en entrée, produit du texte en sortie et prend en charge des contextes allant jusqu’à un million de tokens. Le rapport indique un réseau principal de 552B paramètres, plus une composante Engram distincte de 196B paramètres. Son architecture à mélange d’experts active une petite partie du réseau principal pour chaque token.
Les résultats agentiques du rapport sont solides sur plusieurs suites de tests. DeepSWE passe de 54,4 pour V4 Flash à 74,2 pour V4.1 Flash, une amélioration de 19,8 points de pourcentage. Opus 5 obtient 74,0 et GPT-5.6 Sol 73,0 dans ce tableau. Mais Terminal-Bench 4.0 montre un écart clair : 31,2 pour V4.1, contre 51,8 pour Opus 5 et 39,9 pour Sol. Ce sont des évaluations rapportées dans les conditions du rapport, pas une garantie pour votre agent.
Le rapport estime aussi comment le calcul de décodage augmente avec la longueur du contexte. Il montre environ 25 % plus de FLOPs pondérés par la précision pour chaque token décodé à un million de tokens de contexte qu’à 4K. C’est un résultat d’ingénierie sur le calcul, pas une mesure de latence ou de prix d’API.
La courbe de calcul de décodage du rapport, présentée à 09:15. Les FLOPs décrivent le calcul, pas les prix d’API ni la latence mesurée.
Ce que notre benchmark de rédaction a mesuré
Notre relevé du 10 septembre couvre 148 configurations de modèles, 10 tâches de rédaction et cinq brouillons par configuration et par tâche. Trois modèles juges évaluent les brouillons anonymisés selon la même grille éditoriale détaillée. Le benchmark cherche à savoir si un modèle peut suivre les instructions et rédiger des scripts éducatifs dans notre voix. Il ne mesure pas tous les types de rédaction.
| Modèle et réglage | Score de la grille / 100 | USD moyens par brouillon | Secondes moyennes |
|---|---|---|---|
| DeepSeek V4.1 Flash, par défaut | 87,13 | 0,0077 $ | 43,1 |
| DeepSeek V4.1 Flash, max | 86,75 | 0,0124 $ | 74,6 |
| Kimi K3 | 88,19 | 0,2598 $ | 234,3 |
| Claude Opus 5, max | 88,76 | 0,2927 $ | 131,7 |
| Claude Fable 5.1, max | 89,71 | 3,1525 $ | 622,5 |
Figure recréée à partir du relevé du benchmark du 10 septembre. Les valeurs exactes figurent dans le tableau ci-dessus.
Les coûts sont les moyennes du dépôt calculées à partir des tokens. DeepSeek et Kimi utilisent l’usage enregistré par OpenRouter ; les exécutions avec Claude Code utilisent l’output mesuré et une tarification équivalente à celle de l’API, plutôt que les frais d’abonnement. Les temps incluent les différences de fournisseurs et d’outils de test. Ces chiffres décrivent ce relevé, pas une offre de prix permanente.
Pour cette comparaison, j’ai regroupé le relevé en conservant la configuration au meilleur Elo pour chaque modèle, y compris les réglages ultra. DeepSeek occupe la septième place dans cette vue. Ses entrées max et par défaut se classent 22e et 24e parmi les 148 configurations. L’Elo est calculé à partir de comparaisons par tâche ; son ordre peut donc différer du score moyen de la grille. Les positions voisines ont des intervalles de confiance qui se chevauchent.
C’est pourquoi je ne transformerais pas un score proche en « équivaut à Fable ». Fable reste en tête de ce classement. DeepSeek offre un compromis de coût utile pour des brouillons qu’une personne va réviser.
Commencez avec high, puis testez max
L’API de DeepSeek propose les efforts de raisonnement low, high et max, avec high par défaut. La documentation du mode de raisonnement décrit cette correspondance.
Dans notre test de rédaction, max a coûté environ 60 % de plus et pris environ 73 % plus de temps que le réglage par défaut. Leurs intervalles de confiance Elo se chevauchent ; le résultat ne démontre donc pas un avantage de qualité pour max et ne prouve pas non plus l’équivalence des réglages. Deux brouillons produits avec max ont aussi atteint le plafond d’output initial de 32K. Le raisonnement supplémentaire consomme du budget d’output qui pourrait être nécessaire au script lui-même.
Moyennes mesurées et intervalles Elo bootstrap à 95 % pour les deux réglages d’effort.
Pour les plans et les premiers brouillons, je commencerais avec high et je mesurerais la révision encore nécessaire. Si max réduit systématiquement ce travail sur vos propres tâches, le temps et les tokens supplémentaires peuvent en valoir la peine. Les courbes d’effort du rapport concernent son propre ensemble d’évaluations ; notre résultat en rédaction ne devrait pas être généralisé aux tâches de raisonnement difficiles.
Avant de l’utiliser dans une application
Nous avons migré le tuteur IA de notre académie vers V4.1 après avoir effectué nos propres évaluations et tests. C’est le processus que je répéterais pour un autre produit : tester la tâche, mesurer les échecs et la révision, puis comparer le coût et la latence.
Pour les utilisateurs actuels de Pro, DeepSeek a annoncé que les requêtes deepseek-v4-pro seraient redirigées vers V4.1 Flash à partir du 14 septembre 2026 à 04:00 UTC, jusqu’au lancement de V4.1 Pro. Un alias ne garantit pas que le modèle restera inchangé. Vérifiez les options de versionnement de votre fournisseur et refaites vos évaluations avant de vous fier à cette migration. Annonce officielle de l’API.
Le meilleur argument de ce modèle dans mon workflow de rédaction est un premier jet à faible coût. Quand les mots constituent le produit final, je tiens encore compte de l’écart de qualité et du temps consacré aux corrections. Le chiffre utile, c’est le travail que le brouillon terminé me fait économiser.
FAQ
Qu’est-ce qui est nouveau dans DeepSeek V4.1 Flash ?
Par rapport à V4 Flash, le rapport présente une architecture encodeur-décodeur causale, la réutilisation du cache et de l’indexation avec CSA2, FP4 pour le cache KV global principal et le rejeu borné de l’état d’attention local. L’attention clairsemée et la recherche sur les encodeurs-décodeurs existaient avant ce modèle.
DeepSeek V4.1 Flash tient-il dans 1 Go de mémoire ?
Non. À 890 octets par token, un cache KV global d’un million de tokens occupe environ 0,89 Go. Ce chiffre exclut les poids du modèle, l’état local et les autres besoins en mémoire pour l’inférence.
Devrais-je utiliser l’effort de raisonnement high ou max ?
High est le réglage par défaut de l’API. Dans notre test de rédaction du 10 septembre, les intervalles de confiance Elo du réglage par défaut et de max se chevauchaient, alors que max coûtait environ 60 % de plus et prenait environ 73 % plus de temps. Testez les réglages sur vos propres tâches avant de choisir.
Combien coûtait DeepSeek V4.1 Flash par script ?
Le réglage par défaut coûtait en moyenne 0,007744 $ par brouillon et max 0,012425 $ dans le relevé du benchmark. Ce sont des coûts calculés à partir des tokens pour le fournisseur et les tarifs testés, pas des prix garantis pour chaque script ni des frais d’abonnement.
Quel rang DeepSeek V4.1 Flash a-t-il obtenu dans le benchmark de rédaction ?
En regroupant tous les réglages d’effort sous chaque modèle et en conservant le meilleur Elo, V4.1 Flash se classe septième dans cette comparaison. Ses configurations max et par défaut se classent 22e et 24e parmi 148 configurations. Les intervalles de confiance Elo voisins se chevauchent.
Le prefill de V4.1 Flash est-il toujours deux fois plus rapide que celui de V4 Flash ?
Non. L’économie de calcul décrite vient du traitement de la majeure partie du prompt dans l’encodeur, sans traverser tout le décodeur. Ce résultat architectural ne garantit pas une latence divisée par deux par rapport à V4 Flash pour chaque requête.