La fiche technique officielle de DeepSeek pour V4.1 Flash sur Hugging Face est un document différent du fil de lancement que ce blog a couvert le 10 septembre : là où le fil menait avec un graphique de benchmark face à des rivaux nommés, la fiche technique mène avec l'architecture, puis l'étaye avec un tableau du modèle de base, un tableau de comparaison face à la concurrence, et — fait rare pour un document de lancement — un tableau montrant à quel point les scores du modèle varient selon le harnais d'agent qui l'exécute. Ce dernier tableau est la chose la plus intéressante de cette sortie, et il mérite d'être lu attentivement plutôt que survolé.
Un décodeur qui ne calcule pas son propre cache d'attention
L'affirmation architecturale phare est une conception Causal Encoder-Decoder (CED) : un transformeur à 40 couches scindé en un encodeur causal de 20 couches et un décodeur de 20 couches, où le cache clé-valeur global du décodeur est projeté à partir des états cachés finaux de l'encodeur plutôt que dérivé fraîchement de chaque couche du décodeur. C'est le mécanisme derrière le chiffre d'efficacité le plus frappant du modèle : seuls 8 Md de paramètres sur le socle de 552 Md s'activent par token pendant le préremplissage (prefill), contre 16 Md pendant le décodage.
Cette asymétrie est un pari délibéré sur ce à quoi ressemblent réellement les charges de travail agentiques. Le préremplissage est la phase qui traite le prompt — les sorties d'outils, le contenu de fichiers, l'historique de conversation qu'un agent lit avant d'écrire quoi que ce soit — et dans une boucle d'agent qui s'exécute longtemps, la lecture écrase largement l'écriture. En faisant du préremplissage la phase bon marché (8 Md actifs) et en réservant davantage de capacité au décodage (16 Md actifs, là où la qualité de sortie compte le plus), l'architecture cible exactement la répartition de charge que la propre couverture de ce blog sur les benchmarks agentiques de DeepSeek a suivie toute l'année : les agents dépensent l'essentiel de leurs tokens à lire, pas à générer.
Le reste de l'histoire sur l'efficacité du cache tient à Compressed Sparse Attention 2 (CSA2), qui attribue à chaque couche d'attention l'un de trois rôles fixes — Full, Reindex ou Reuse — de sorte que la plupart des couches partagent l'état clé-valeur et les indices d'attention parcimonieuse calculés par un petit nombre de couches Full plutôt que de les recalculer elles-mêmes. Un Hierarchical Sparse Indexer restreint les couches ultérieures à un pool de candidats construit par la première couche Full, ce qui empêche le coût d'indexation de croître avec la longueur du contexte, même jusqu'à la fenêtre de 1 million de tokens du modèle. Associé à une mise en cache clé-valeur en FP4 (un format E2M1 avec une échelle E4M3 pour 16 canaux), cela ramène l'empreinte globale du cache KV à 890 octets par token — une réduction de 4 fois par rapport à DeepSeek-V4-Flash et de 437 fois par rapport à DeepSeek-V1 original, selon les propres chiffres de la fiche. Une technique distincte, SWA Bounded Replay, s'attaque à un coût de cache différent : elle reconstruit l'état d'attention à fenêtre glissante en rejouant seulement les tokens les plus récents plutôt qu'en le persistant sur disque, ramenant l'empreinte KV persistante à environ un huitième de celle de V4-Flash. Ce sont deux chiffres distincts sur deux caches distincts — les chiffres de 4x/437x décrivent le cache KV global, le chiffre d'environ 8x décrit ce qui doit être conservé en stockage persistant — et la fiche prend soin de les garder séparés, même si les deux se combinent dans la même histoire : une empreinte mémoire par token nettement plus petite que toute génération DeepSeek antérieure.
Deux autres composants complètent l'architecture, tous deux énoncés simplement et aucun vérifié indépendamment ailleurs : une banque mémoire conditionnelle « Engram » de 196 Md de paramètres, accédée de façon parcimonieuse par recherche à base de tokens plutôt que par calcul dense, et DSpark, un schéma de décodage spéculatif utilisant une génération de brouillon semi-autorégressive avec vérification programmée par niveau de confiance. La fiche ne dit pas combien des 196 Md de paramètres d'Engram sont touchés par token, seulement que l'accès est parcimonieux — à noter comme une question ouverte plutôt qu'à combler par un chiffre qui n'existe pas. Pris au pied de la lettre, Engram se situe entièrement en dehors du chiffre de 552 Md du socle, ce qui signifie que le nombre total de paramètres adressables du modèle se rapproche de 748 Md, même si le chiffre le plus cité restera celui, plus petit, du socle.
Un composant de plus se rattache à une histoire que ce blog a déjà racontée. La révélation de GLM-5.3-Flash par Z.ai le mois dernier incluait une analyse indépendante de l'éducateur en apprentissage automatique Sebastian Raschka, qui attribuait le mécanisme de flux résiduel de GLM à des « Manifold-Constrained Hyper-Connections » (mHC) dans « une conception à quatre flux de style DeepSeek V4 » — sa propre reconstruction, pas une spécification confirmée à l'époque. La propre fiche de DeepSeek pour V4.1 Flash nomme désormais directement la même abréviation : « Single-Pass mHC », décrit comme un mélange de flux résiduel révisé exécuté via ce que la fiche appelle un « noyau Mega-mHC efficace ». C'est DeepSeek qui confirme, dans son propre document, que mHC est bien une technique originaire de DeepSeek — l'attribution de Raschka se vérifie, et V4.1 Flash en est la propre itération suivante de DeepSeek, pas une réponse à quelqu'un qui l'aurait empruntée.
Le modèle de base montre déjà le schéma que l'instruct répéterait
Avant tout post-entraînement, DeepSeek-V4.1-Flash-Base affiche déjà l'arbitrage qui se retrouverait dans le modèle final. Face à DeepSeek-V4-Pro-Base — un socle bien plus grand de 1,6 billion de paramètres activant 49 Md de paramètres par token, plus de six fois l'activation de V4.1-Flash-Base — le modèle plus petit gagne ou fait jeu égal en code et en maths (HumanEval 79,4 contre 76,8, BigCodeBench 60,6 contre 59,2, GSM8K 93,0 contre 92,6) tout en accusant un net retard sur le rappel de connaissances et le contexte long (SimpleQA-Verified 42,3 contre 55,2, MultiLoKo 45,5 contre 50,9, LongBench-V2 45,2 contre 51,5). C'est le même clivage qui apparaît dans la comparaison du modèle instruct ci-dessous, ce qui signifie que ce n'est pas un artefact des choix de post-entraînement — il est déjà présent dans le socle préentraîné, avant que le moindre apprentissage par renforcement ou la moindre distillation n'y touche.
Ce que montre réellement le tableau de comparaison face à la concurrence
La comparaison de DeepSeek face à Opus 5, GPT-5.6 Sol, Kimi K3, GLM-5.3, et ses propres V4-Pro et V4-Flash confirme les chiffres déjà rapportés depuis le fil de lancement du 10 septembre : DeepSWE v1.1 à 74,2 contre les 74,0 d'Opus 5, CyberGym à 88,1 devant tous les rivaux nommés, Terminal-Bench 3.0 clairement en retrait face à Opus 5 (30,0 contre 43,3), et GPQA Diamond comme HLE menés tous deux par le propre V4-Pro de DeepSeek (92,4 et 42,7, contre 90,9 et 36,8 pour V4.1 Flash). Un résultat que le fil de lancement n'avait pas mis en avant : sur AutomationBench, le 54,8 de V4.1 Flash dépasse le 50,3 d'Opus 5 lui-même, pas seulement ses rivaux ouverts moins chers — une réelle avance sur le modèle de pointe auquel DeepSeek se comparait, pas une quasi-égalité.
Les trois benchmarks à teinte visuelle — Chartography, BabyVision et ZeroBench-main, tous exécutés « avec outils » — confirment le chiffre que ce blog avait cité depuis le lancement de Fugu par Sakana trois jours plus tard : le 84,0 d'Opus 5 sur Chartography est exactement le chiffre que rapporte cette fiche, dans la même ligne « Chartography w/ tools ». Il vaut la peine d'être précis sur ce que ce tableau inclut et n'inclut pas : il ne comporte aucune ligne pour Claude Fable 5.1 — seul Opus 5 apparaît comme représentant d'Anthropic — donc tout chiffre de Fable 5.1 circulant ailleurs pour ce benchmark ne provient pas du propre graphique de DeepSeek.
Le tableau qui complique le titre
La plupart des fiches techniques s'arrêtent au tableau ci-dessus. Celle-ci en ajoute un second, évaluant le même modèle sur les deux mêmes benchmarks — DeepSWE v1.1 et Terminal-Bench 2.1 — à travers huit harnais d'agents différents : Claude Code, Codex, OpenCode, Pi, mini-SWE, et trois modes du propre harnais de DeepSeek (Minimal, Standard, PTC).
Sur DeepSWE v1.1, l'écart va de 65,5 (OpenCode) à 74,2 (mini-SWE) — 8,7 points de variance sur un modèle identique et un benchmark identique, produits entièrement par le harnais qui exécute la boucle d'agent. Sur Terminal-Bench 2.1, l'écart est plus resserré mais bien réel : 84,1 (Codex) à 90,6 (DeepSeek Harness Minimal).
Voici le détail qui mérite qu'on s'y arrête : 74,2, le score DeepSWE v1.1 utilisé dans le tableau de comparaison face à la concurrence pour dire que V4.1 Flash « devance » les 74,0 d'Opus 5, est le résultat de mini-SWE — et mini-SWE est aussi, à lui seul, le harnais qui note le plus haut parmi les huit testés. La note méthodologique explique ce choix par l'alignement avec les exigences de configuration officielles de DeepSWE v1.1, ce qui est une raison légitime de choisir un harnais précis plutôt qu'arbitraire. Mais cela signifie que la marge rapportée sur Opus 5 — deux dixièmes de point — est plus de sept fois plus petite que l'écart entre le meilleur et le pire harnais de V4.1 Flash lui-même sur la même tâche. Faites passer le modèle par le propre harnais Minimal de DeepSeek plutôt que par mini-SWE, et le score tombe à 72,6 — une nette défaite face aux 74,0 d'Opus 5, pas une victoire. Sur Terminal-Bench 2.1, le même schéma se répète en plus modeste : 90,6, le chiffre du tableau face à la concurrence, est le résultat de DSH Minimal, et DSH Minimal est (de justesse, devant le 90,3 de mini-SWE) le meilleur des huit harnais testés là aussi.
Rien de tout cela ne signifie que le chiffre phare est fabriqué ni que la note méthodologique est malhonnête — DeepSWE v1.1 a peut-être réellement un harnais officiellement recommandé, et DeepSeek a divulgué la comparaison complète à huit harnais dans le même document plutôt que de la cacher, ce qui est plus de transparence que n'en offrent la plupart des benchmarks de lancement, et exactement le genre de tableau qui permet à un lecteur de vérifier l'affirmation plutôt que de la prendre pour argent comptant. Mais la lecture directe est celle-ci : le chiffre unique choisi pour étayer « devance Opus 5 » est aussi, que ce soit par méthodologie ou par coïncidence, le plafond de ce que ce modèle obtient sur tous les harnais que DeepSeek lui-même a testés. Une marge plus petite que le bruit de fond propre d'un modèle d'un harnais à l'autre n'est pas une avance significative, et c'est la rare fiche technique qui vous donne les données pour le constater par vous-même.
Notes pratiques pour quiconque l'exécute réellement
La sortie ne comporte pas de modèle de discussion au format Jinja ; elle fournit à la place une référence Python autonome (encoding.py) couvrant les conversations à plusieurs tours, l'appel d'outils, le mode réflexion, l'effort de raisonnement numérique, les messages système en cours de conversation, et le contenu image entrelacé. Pour un usage en production, DeepSeek a séparément publié deepseek-recipe, des bibliothèques Rust avec liaisons Python qui convertissent les requêtes Messages, Chat Completions et Responses API en prompts ou en identifiants de tokens et qui décodent la sortie du modèle en retour — laissant l'inférence, l'exécution d'outils et le transport HTTP à la charge de l'appelant. Le modèle expose un réglage d'effort de raisonnement continûment ajustable de 1 à 100 plutôt qu'un petit nombre de modes discrets, échangeant coût d'inférence contre précision sur un seul curseur ; tous les chiffres de benchmark du tableau face à la concurrence utilisent le réglage maximal, 100.
À surveiller
- Des reproductions indépendantes de l'écart sur DeepSWE v1.1. Le propre tableau à huit harnais de DeepSeek montre déjà que la marge sur Opus 5 dépend du harnais ; un évaluateur extérieur faisant tourner les deux modèles sous un seul harnais neutre et partagé trancherait la question de savoir si « devance Opus 5 » survit hors de la configuration préférée de DeepSeek.
- Si d'autres laboratoires commencent à publier leurs propres tableaux de sensibilité au harnais. Celui-ci est inhabituellement franc sur une source de variance que la plupart des benchmarks de lancement ne divulguent jamais ; si cela devient une norme plutôt qu'une exception, c'est une réelle amélioration de la façon dont les benchmarks agentiques sont rapportés à l'échelle de l'industrie.
- Une confirmation tierce du composant de mémoire Engram. Une structure de recherche parcimonieuse de 196 Md de paramètres à côté d'un socle de 552 Md est une affirmation large et inhabituelle, sans chiffre d'activation par token énoncé ; une analyse indépendante d'interprétabilité ou d'efficacité serait la prochaine vraie vérification.
- Si « Single-Pass mHC » reçoit sa propre analyse indépendante, comme ce fut le cas pour l'architecture de GLM-5.3-Flash de la part de Sebastian Raschka. La fiche de DeepSeek confirme l'origine de la technique mais ne précise pas entièrement le « noyau Mega-mHC » au-delà de le nommer, laissant place au même genre de reconstruction indépendante qui avait clarifié la version de GLM.