DeepSeek V4.1 Flash : un tout nouveau modèle de base arborant un numéro de version mineure

DeepSeek V4.1 Flash a six jours, et les trois questions que son lancement avait laissées ouvertes sont désormais closes — deux d'entre elles en faveur de l'entreprise et une nettement défavorable. Le modèle lui-même est inchangé depuis le 10 septembre : un mélange d'experts de 552 milliards de paramètres avec des poids ouverts sous licence MIT, un contexte d'un million de tokens, et une nouvelle architecture Causal Encoder-Decoder que la fiche modèle du fournisseur lui-même classe dans ce que l'entreprise appelle sa « nouvelle famille d'architectures ». Ce qui a bougé, c'est tout ce qui l'entoure. Un évaluateur indépendant a publié une note là où, le matin du lancement, il n'y en avait aucune. L'entreprise a retiré la mise à la retraite de DeepSeek V4 Pro qu'elle avait annoncée dans son propre journal des modifications. Et le travail de serving au jour zéro qui n'existait pas ce matin-là tourne désormais sur plusieurs runtimes d'inférence répandus — avec ses deux parties les plus difficiles, les tables de mémoire Engram et la séparation préremplissage/décodage dont dépendent les déploiements en production, encore activement retravaillées en public.

Le décalage de nommage reste la raison d'être de ce texte. Lire « V4 Flash to V4.1 Flash » comme une simple étape de correctif est à la fois l'interprétation naturelle et l'erreur à ne pas commettre : le numéro de version n'est qu'à une décimale d'un réajustement, alors que l'architecture sous-jacente fonde toute une famille. Six jours de preuves n'ont pas adouci ce constat. Si tant est qu'elles aient changé quelque chose, les chiffres indépendants n'ont fait que le durcir, car un modèle qui surpasse le vaisseau amiral à 1,6 billion de paramètres de son propre fournisseur n'est pas une simple version mineure — c'est une génération qui a refusé de se nommer.

Ce qui a réellement été expédié le 10 septembre

Ce n'était pas une fuite ni une bêta. Le test API de deux jours qui a débuté le 8 septembre sous l'ID de modèle deepseek-v4.1-flash-expires-on-0910 s'est terminé comme son suffixe l'annonçait, et la version a été déployée sur l'application web, l'application mobile et l'API officielle de DeepSeek, avec les poids et un rapport technique publiés sur Hugging Face sous deepseek-ai/DeepSeek-V4.1-Flash.

Les détails pratiques n'ont pas bougé depuis six jours :

• Nom du modèle — appelez deepseek-flash. Les anciens noms deepseek-v4-flash et deepseek-v4-flash-vision-exp sont toujours acceptés, mais ils ne correspondent plus aux modèles qu'ils désignaient auparavant : les deux sont retirés, et les requêtes qui les nomment sont servies par DeepSeek V4.1 Flash et facturées au tarif Flash.

• Ce qui est inclus — une fenêtre de contexte de 1 M de tokens, une sortie maximale de 384 K, une sortie JSON, l’appel de fonctions, une entrée d’images native, et un mode de réflexion activé par défaut avec des réglages d’effort faible, élevé et maximal.

• Licence — MIT, poids inclus, avec un dossier d’inférence et un module d’encodage séparé dans le dépôt. DeepSeek a explicitement invité la communauté open source à développer la prise en charge de l’inférence dès le premier jour, et la communauté s’en est emparée plus rapidement que l’invitation ne le laissait entendre.

Le .1 qui n'est pas une version mineure

L'affirmation à l'origine de cet article venait de teortaxesTex, un observateur pseudonyme mais très suivi de DeepSeek, dans un post du 10 septembre : selon lui, c'est « la première fois que DeepSeek attribue une version .1 à un tout nouveau modèle de base », que V4.1 est « plus différent de V4 que, disons, LLaMA 3 ne l'est de LLaMA 1 », et que DeepSeek « ne pense pas que cela mérite encore V5 » — sans que l'auteur du post puisse dire pourquoi.

Considérez la partie causale comme une inférence et la partie structurelle comme vérifiable. L'inférence — pourquoi DeepSeek a choisi .1 plutôt que V5 — n'est que la lecture d'un observateur, rien de plus ; personne en dehors de l'entreprise n'a expliqué cette décision, et les documents de DeepSeek eux-mêmes n'en parlent jamais. La partie vérifiable, c'est l'architecture, et elle ne ressemble pas à une version mineure. Le journal des modifications de DeepSeek décrit V4.1 Flash comme « le plus petit modèle de notre nouvelle famille d'architectures », ce qui est une phrase étrange pour une simple mise à niveau de version : une mise à niveau de version étend une famille, elle n'en fonde pas une.

L'ambiguïté a un coût réel, et il retombe sur les acheteurs, pas sur DeepSeek. Les numéros de version sont le signal le moins coûteux dont dispose un développeur pour savoir « s'agit-il d'une nouvelle génération ou d'un simple réglage, et quelle part de mon budget d'évaluation mérite-t-elle ? » DeepSeek a désormais rendu ce signal peu fiable dans une direction : un modèle qui fonde une famille d'architectures se trouve à une décimale d'un modèle qui a modifié sa recette de post-entraînement. L'entreprise garde son marqueur V5 en réserve. Tous ceux qui effectuent une évaluation de migration paient pour cette confusion.

Ce que « nouvelle architecture » signifie dans les poids

La fiche du modèle est d’une précision inhabituelle, ce qui rend l’affirmation générationnelle testable sans le moindre benchmark. Cinq éléments ressortent — le cinquième étant celui que la couverture du lancement a surtout ignoré, et celui qui s’avère le plus important pour quiconque cherche à servir ce modèle.

— Activation asymétrique — la séparation encodeur-décodeur causal est un transformateur de 40 couches organisé en un encodeur causal de 20 couches suivi d'un décodeur de 20 couches, où le cache KV global du décodeur est projeté depuis les états cachés finaux de l'encodeur plutôt que dérivé de chaque couche du décodeur. Le but de cette conception est que le modèle n'active que 8B paramètres par jeton pendant le préremplissage et 16B pendant le décodage. Les charges de travail agentiques à forte entrée — longs documents, longues traces d'outils — obtiennent la moitié bon marché du modèle ; la génération obtient la moitié coûteuse.

• Compression du cache KV, mesurée par token — DeepSeek-V4.1-Flash utilise un cache KV principal en FP4 à 890 octets par token, ce que la fiche situe à environ un quart de celui de DeepSeek V4 Flash. La couverture chinoise est allée plus loin et a présenté la compression par rapport à la première génération du modèle V4 comme une réduction de 437× ; ce chiffre plus important provient d’un calcul fourni par le fabricant sur une base différente, il faut donc le considérer comme une affirmation plutôt qu’une mesure.

• SWA Bounded Replay — l'attention à fenêtre glissante vous oblige normalement à conserver l'état KV sur SSD pour reconstruire le contexte. Cette méthode reconstruit les états KV SWA manquants en rejouant uniquement la fenêtre la plus récente de jetons, réduisant ainsi l'empreinte KV persistante à environ un huitième de celle de DeepSeek V4 Flash.

• Compressed Sparse Attention 2 — chaque couche d'attention fonctionne dans l'un des trois modes statiques (Full, Reindex ou Reuse), partageant l'état KV et l'état de l'indexeur entre les couches, avec un indexeur hiérarchique sparse qui borne le coût des couches plus profondes indépendamment de la longueur du contexte.

• Engram — un module de mémoire conditionnelle qui sépare la mémoire du calcul, implémenté sous forme de recherches de hachage de n-grammes injectées via des portes dans le flux résiduel du modèle plutôt que sous forme d'attention ou d'experts supplémentaires. Les deux tables fp8 contiennent 189 GiB de poids, d'après la propre description de l'architecture par SGLang, et les fournisseurs de runtime qui ont porté le checkpoint situent les tables à environ 196B paramètres en plus des 552B du backbone — c'est pourquoi le nombre de paramètres mis en avant sur la fiche décrit le backbone et non l'ensemble du téléchargement. Engram est entraîné sur deux couches, utilise des ordres de deux, trois et quatre n-grammes sur huit têtes de hachage par ordre, et fusionne les tokens qui se normalisent de la même manière afin que les variantes de casse soient hachées vers le même compartiment. Le détail de conception à retenir est le coût qu'il impose : chaque étape de décodage lit ces tables, donc l'endroit où vous les placez détermine la quantité de cache KV qu'il vous reste.

Si l’on prend ces cinq éléments ensemble, le tableau stratégique devient lisible : il s’agit d’abord d’une architecture de sparsité, d’efficacité de cache et de déport mémoire, dimensionnée pour que la même structure puisse être mise à l’échelle plus tard. La mention d’une « nouvelle famille d’architectures » joue un vrai rôle — c’est l’affirmation que d’autres choses arrivent.

Le score indépendant est enfin tombé — et il soutient le fournisseur.

Il y a quatre jours, cette section aurait été très différente. Au lancement, Artificial Analysis n'avait rien publié sur DeepSeek V4.1 Flash, la page du modèle sur Hugging Face portait encore la mention selon laquelle le modèle « n'est déployé par aucun fournisseur d'inférence », et l'affirmation centrale de toute l'annonce — qu'un modèle de gamme Flash surpasse globalement un modèle phare de 1 600 milliards de paramètres en performance, en coût, en vitesse et en temps total de tâche — n'était qu'une affirmation du fournisseur, sans audit externe. Ces trois lacunes ont depuis été comblées.

Artificial Analysis a désormais mesuré le modèle sur son Intelligence Index, et en bref, l'affirmation de DeepSeek résiste au contact d'un tiers :

• Intelligence Index — DeepSeek V4.1 Flash obtient un score de 40 avec un effort de raisonnement maximal, se classe sixième sur 113 modèles de sa catégorie de comparaison et se situe bien au-dessus de la médiane de 18 pour les modèles à poids ouverts comparables. DeepSeek V4 Pro 0813, le modèle phare qu'il aurait été accusé de supplanter, obtient un score de 36 sur le même indice.

• Coût par tâche — 0,27 $ par tâche de l'Intelligence Index pour V4.1 Flash contre 0,67 $ pour V4 Pro 0813. C'est l'affirmation de capacité par dollar, reproduite de façon indépendante : le modèle le moins cher est le plus capable selon cette mesure, pour environ 40 % du coût par tâche accomplie.

• Vitesse — 212,1 jetons de sortie par seconde contre une médiane de 73,1 t/s pour des modèles comparables, avec un temps jusqu'au premier jeton de 1,31 s contre une médiane de 2,37 s. Sur le même banc d'essai, V4 Pro 0813 mesure 94,4 t/s et un TTFT de 1,72 s.

• Prix — Artificial Analysis relève 0,30 $ par million de tokens en entrée et 1,20 $ par million de tokens en sortie, avec une remise de 98 % sur le cache, ce qui correspond à la grille tarifaire maximale de DeepSeek telle que publiée, et non à une majoration premium appliquée par un tiers.

Étiquetez cela correctement, car l’étiquette a changé. Ce sont des mesures indépendantes, et non des chiffres de fournisseur — mais ce sont des mesures indépendantes sur un seul banc d’essai tiers, et un indice n’est pas un verdict sur un modèle. Ce qu’il permet de trancher est plus étroit et plus utile qu’une position dans un classement : l’affirmation spécifique que DeepSeek a faite pour justifier sa propre gamme de produits, selon laquelle Flash surpasserait Pro sur la capacité et le coût simultanément, dispose désormais d’une corroboration externe plutôt que d’un journal des modifications derrière elle.

Il y a aussi un bémol honnête de l'autre côté, et il provient du même rapport de fournisseur que précédemment. Les propres chiffres de DeepSeek montrent que V4.1 Flash remporte 13 des 16 comparaisons face à Kimi K3 et 11 des 13 face à GLM-5.3, tout en restant derrière GPT-5.6 Sol et Claude Opus 5 sur les nouvelles tâches Terminal-Bench 3.0 et 4.0 ainsi que sur ProgramBench. C'est un profil cohérent — au meilleur niveau sur le travail de codage, de terminal et d'automatisation par agents pour lequel cette architecture est optimisée, plus faible sur les tâches de raisonnement de pointe — et c'est le profil que présenterait un véritable saut générationnel. L'indice indépendant est d'accord avec les grandes lignes sans trancher chaque cellule.

Le retrait de Pro annoncé par DeepSeek — puis annulé

Voici la partie qui a changé par rapport au plan énoncé par DeepSeek lui-même, et c'est celle qui risque le plus d'affecter une intégration en production.

Lors du lancement, DeepSeek a annoncé que DeepSeek V4 Pro serait retiré de son API. À partir de 12 h 00, heure de Pékin, le 14 septembre, les requêtes mentionnant deepseek-v4-proseraient acheminées vers V4.1 Flash et facturées au tarif de Flash — une réduction d'environ 70 % du coût de sortie pour quiconque a le nom du modèle Pro codé en dur — et resteraient acheminées ainsi jusqu'à la sortie d'un futur V4.1 Pro. Sur la grille tarifaire du jour du lancement, cela signifiait que les 3,96 $ par million de tokens de sortie de Pro tombaient à 1,20 $ pour Flash aux heures de pointe, sans modification du code ni autre avis qu'une entrée dans le journal des modifications.

Cela ne s'est pas produit. Le 11 septembre, DeepSeek a publié un avis sur sa propre plateforme ouverte indiquant qu'en réponse à la demande des utilisateurs, elle continuerait à fournir le service API DeepSeek V4 Pro après le 14 septembre, la facturation restant inchangée — l'avis est resté affiché sur la plateforme le 14 septembre même, une fois le moment de basculement passé ; il s'agit donc d'une déclaration directe émanant de l'entreprise concernée plutôt que d'une rumeur à son sujet. La raison rapportée est l'élément le moins surprenant de cette histoire : des développeurs ont désapprouvé qu'un fournisseur remplace silencieusement les poids derrière un nom de modèle dans une intégration de production, et les propres tests multipartites de DeepSeek avaient constaté que V4 Pro conservait un avantage de qualité sur les charges de travail réelles de certaines équipes, même là où V4.1 Flash gagne dans les évaluations publiques.

La lecture pratique est un revirement pur et simple de ce que conseillaient les articles du jour du lancement. Si vous avez inscrit le 14 septembre à votre calendrier pour retester une intégration épinglée à Pro, l’échéance est caduque : DeepSeek V4 Pro est toujours DeepSeek V4 Pro, et toujours au même prix qu’avant, tandis que V4.1 Pro reste non annoncé, sans fiche, sans nombre de paramètres, sans date et sans poids. Ce qui n’a pas changé, c’est la direction suivie — DeepSeek a clairement l’intention de faire converger sa gamme vers la nouvelle architecture, et la seule chose qu’il a confirmée au sujet de l’ancienne, c’est qu’il n’imposera pas la transition à une date fixe.

Le servir : 189 GiB de tables de n-grammes, et le travail encore ouvert

La formulation de la disponibilité au lancement était « fonctionne sur l’API du fournisseur et nulle part ailleurs ». Cela n’est plus vrai, et l’endroit où cela a cessé de l’être est instructif concernant cette architecture.

SGLang et Miles ont livré le support day-zero de DeepSeek V4.1 le 10 septembre, dans la même fenêtre que le modèle lui-même — de sorte que la note « pas de service tiers » qui figurait sur la page Hugging Face au lancement était obsolète en quelques heures. L’aspect intéressant n’est pas qu’il fonctionne ; c’est ce que son exécution coûte. Parce que chaque étape de décodage lit les tables Engram, l’approche de SGLang consiste à vous laisser les placer en mémoire GPU ou en mémoire hôte, le déchargement vers l’hôte libérant environ 46 GiB par GPU pour le cache KV, au prix d’environ 200 GB de RAM hôte sur le nœud. Sur une configuration GB300 à quatre GPU, le déchargement vers l’hôte a augmenté la capacité du cache KV de 36 %, avec un débit de décodage et un temps jusqu’au premier token comparables, et les 28 complétions de sonde greedy correspondaient toutes à la référence tout-GPU. C’est à activer explicitement, via une seule variable d’environnement ; ce n’est pas le défaut. vLLM mène des travaux parallèles dans la direction opposée — le mappage mémoire de fragments des tables depuis le disque plutôt que leur maintien dans la RAM hôte — ce qui dit la même chose sous deux angles : ce sont les tables Engram, et non les poids, qui constituent la contrainte sur le coût de service de ce modèle.

Les changements les plus récents de toute l’histoire se trouvent ici, et ce sont de petits changements qui méritent d’être qualifiés de petits. Le 15 septembre, un contributeur SGLang a ouvert la pull request #39666, ajoutant un module Engram et un adaptateur partagé d’historique des requêtes à la branche DeepSeek V4.1 du projet — 7 fichiers, +1205/−11, l’adaptateur exposant des champs facultatifs d’historique n-gram sur le planificateur et les lots de propagation avant, et reconstruisant cet historique à travers les correspondances de préfixe, les rétractions et la réutilisation d’emplacements. Elle est ouverte et non fusionnée, ses exécutions CI échouaient, et elle attendait une revue de neuf propriétaires de code ; le résumé de l’auteur lui-même est sans détour sur les limites, indiquant que les vérifications de recherche ne prouvent pas la validité du cycle de vie des requêtes. Elle faisait partie d’un lot de pull requests DeepSeek V4.1 ouvertes sur cette branche le 15 septembre, la plupart provenant du même contributeur, couvrant la construction du modèle, la tour de vision, l’encodage de chat et la couche noyau.

Puis, le 16 septembre, le plan pour la moitié la plus ardue du serving est devenu public. Un ticket de feuille de route, #39700, présente la désagrégation prefill/decode pour DeepSeek V4.1 sur la plateforme B200 sous la forme d'une liste par étapes : d'abord le parallélisme de contexte côté prefill, puis ce travail de prefill combiné à MegaMoE, BCG et multi-stream, puis les éléments côté decode, dont l'attention DP et la mémoire CUDA-graph. La première étape a été intégrée sous la forme de la pull request #39748, intitulée « [DSV4.1-PD-1/8] Support prefill node use cp parallel strategy » et ouverte le même jour par le même auteur. Elle permet au nœud prefill d'un déploiement désagrégé d'exécuter une stratégie de parallélisme de contexte, avec une configuration de référence de huit B200 en TP4/EP4 exécutant le runner MoE flashinfer_mxfp4 et le décodage spéculatif DSPARK. Le nœud prefill prend --enable-prefill-cp --cp-strategy interleave aux côtés de --disaggregation-mode prefill via le backend de transfert Mooncake ; le nœud decode s'exécute sans aucun flag CP. La validation repose sur un scoring gsm8k ainsi que des tests unitaires sur les chemins texte et image. Comme la pull request Engram, elle est ouverte, non fusionnée, et actuellement bloquée en CI à cause d'un label run-ci manquant.

Soyez clair sur ce que tout cela est et n'est pas. C'est de la plomberie d'infrastructure à l'intérieur d'un runtime qui sert déjà le modèle — cela ne change rien à ce que fait DeepSeek V4.1 Flash, à ce qu'il coûte, ni à la question de savoir si vous devriez l'utiliser. Cela ne vaut ces lignes que parce que cela marque où se trouvent les aspérités restantes. Du côté d'Engram, l'historique de n-grammes qui survit à la rétractation et à la réutilisation du cache de préfixes est exactement le genre de détail de correction qui sépare une démo d'un point de terminaison de production. Du côté de la désagrégation, la cible est les opérateurs qui séparent le prefill et le decode sur des pools distincts afin que chaque moitié puisse être parallélisée pour son propre goulot d'étranglement — un déploiement dont la configuration de référence démarre à huit B200, ce qui est une décision capitalistique plutôt qu'une ligne dans un fichier de configuration. Et la série est étiquetée 1/8 alors que le ticket de feuille de route énumère ses étapes en six parties, avec toute la moitié decode encore non écrite : même la numérotation est provisoire. Si vous ne prenez pas cette décision capitalistique, rien de tout cela n'est visible depuis là où vous êtes — DeepSeek V4.1 Flash est en ligne sur OrcaRouter au tarif de passage ci-dessous, et la plomberie reste du côté opérateur du point de terminaison.

J'appelle DeepSeek V4.1 Flash aujourd'hui.

La mention de disponibilité a changé de notre côté aussi, et elle a changé dans un sens dont les lecteurs de la version du jour du lancement de cet article s'étaient entendu dire qu'il ne se produirait pas. OrcaRouter ne proposait pas DeepSeek V4.1 Flash le 10 septembre — la page du modèle renvoyait « model not found » et cet article le disait clairement plutôt que de laisser entendre le contraire. Il le propose désormais : deepseek/deepseek-v4.1-flash est en ligne dans le catalogue à 0,15 $ par million de jetons d'entrée et 0,60 $ par million de jetons de sortie, le tarif propre du fournisseur DeepSeek répercuté avec 0 % de marge ajoutée, ce qui est aussi le chiffre à vérifier la prochaine fois que DeepSeek modifie un prix. Depuis son arrivée, il a fait transiter 54 982,2 M de jetons par la plateforme, avec un p50 de temps jusqu'au premier jeton de 811 ms et un p95 de 3,03 secondes.

Ce que cela vous apporte au-delà de la même grille tarifaire, c'est la possibilité de traiter une architecture vieille de six jours comme une expérience plutôt qu'un engagement. Le basculement (failover) signifie qu'un appel V4.1 Flash qui commence à renvoyer des erreurs sous charge peut être redirigé vers un autre modèle sans déploiement ; le DSL de routage signifie que vous pouvez placer le nouveau modèle sur une partie de votre trafic et un modèle éprouvé sur le reste, et les comparer sur vos propres entrées plutôt que sur un classement ; et tous les autres modèles du catalogue se trouvent derrière la même clé, y compris le reste de la gamme DeepSeek — DeepSeek V4 Flash et DeepSeek V4 Pro — si bien qu'un retour en arrière est un simple changement de chaîne, pas un second contrat.

Cela compte plus que d'habitude ici, pour deux raisons que six jours d'actualité ont rendues concrètes. La première est que l'avantage de prix est réel, mais conditionné au fait que le fournisseur maintienne le tarif, et qu'un arrangement de répercussion est le seul type qui reste honnête lorsqu'il ne le fait pas. La seconde est que la seule mise en garde de la semaine de lancement a survécu : l'avantage capacitaire et l'avantage de coût sont désormais mesurés indépendamment, mais ils le sont sur un seul banc d'essai, sur un modèle dont le nom dit « mise à jour mineure » et dont l'architecture dit le contraire. Routez-le comme une nouvelle génération, car c'est ce qu'il est, et gardez-le derrière un palier que vous pouvez déplacer.

Qu'est-ce qui est encore ouvert ?

Trois choses, par ordre croissant de ce qu'elles vous apprendraient.

DeepSeek V4.1 Pro mettrait à l’épreuve l’affirmation relative à la famille. DeepSeek V4.1 Flash se présente comme le plus petit modèle d’une nouvelle famille d’architectures, et le modèle frère qui prouverait que cette famille existe n’a toujours ni fiche, ni nombre de paramètres, ni date, ni poids, ni prix. C’est aussi le modèle autour duquel toute la manœuvre de routage Pro était structurée, maintenant que cette manœuvre a été annulée.

Une seconde évaluation indépendante permettrait de tester le score. Un Intelligence Index de 40, contre 36 pour le modèle qu’il remplace, est un résultat clair sur un seul banc d’essai et un simple point de données sur la question de savoir si cette architecture a une génération d’avance ou constitue un pas de côté bien optimisé. Surveillez l’arrivée d’un second évaluateur, et si le chemin de service avec déport Engram tient le coup face à un trafic réel plutôt que sur des sondes greedy, et si la séparation prefill/décode actuellement préparée dans des pull requests finira un jour par devenir une histoire d’empaquetage qu’une équipe normale peut déployer.

Et la question utile, quoique peu reluisante : savoir si DeepSeek recommencera. Un second label .1 sur un autre nouveau modèle de base transformerait une anomalie en convention, et une convention est un élément autour duquel un développeur peut planifier. Un seul modèle n'est qu'une curiosité. Le nom ne devient trompeur de manière utile qu'une fois qu'un schéma s'établit.

Pour l’instant, la lecture pratique se sépare clairement selon qui vous êtes. Si vous utilisez DeepSeek V4 Pro, le modèle derrière ce nom ne changera pas le 14 septembre ni à aucune date annoncée — DeepSeek est revenu sur cette décision, et vous pouvez laisser votre intégration telle quelle. Si vous utilisez DeepSeek V4 Flash, vous êtes déjà en cours de migration, au même prix, vers une architecture que DeepSeek a conçue pour passer à l’échelle. Et si vous attendiez la V5, la réponse honnête est que DeepSeek semble avoir livré la génération, refusé de la nommer, puis découvert que le numéro sur la boîte est finalement déterminant.