DeepSeek V4.1 Flash passe en disponibilité générale : 552B sous une nouvelle architecture, des poids MIT et une fin de vie de V4 Pro qui n'a jamais eu lieu

DeepSeek V4.1 Flash n’est plus une expérience de deux jours. Le modèle qui a passé les 8 et 9 septembre dans l’API en production du fournisseur sous un identifiant portant sa propre date d’expiration — deepseek-v4.1-flash-expires-on-0910 — est réellement sorti le 10 septembre 2026, dans l’application, l’interface web et l’API de DeepSeek, où il répond désormais au nom de modèle deepseek-flash. Trois aspects de cette sortie vont au-delà de ce que laissait entendre la bêta. Le premier, c’est la paperasse : DeepSeek a publié un rapport technique — intitulé, sans grande subtilité, Pushing the Limits of KV Cache Compression — ainsi que les poids sous licence MIT d’un modèle multimodal à mélange d’experts de 552 milliards de paramètres, bâti sur une nouvelle architecture Causal Encoder-Decoder. Ces poids ne sont pas une promesse : 48 fragments safetensors, environ 510 Go au total, ont été mis en ligne le matin de la sortie, ce qui transforme le slogan non vérifié de la bêta — « nouvelle architecture, multimodale native » — en quelque chose qu’un lecteur peut télécharger et inspecter. Le deuxième, c’est la forme de la gamme. DeepSeek V4 Flash et DeepSeek-V4-Flash-Vision-Exp sont retirés, leurs anciens identifiants pointant toujours vers le nouveau modèle aux tarifs Flash, et le projet de retirer progressivement DeepSeek V4 Pro le 14 septembre a été annulé avant même la date : V4 Pro est toujours servi, à facturation inchangée, et DeepSeek a promis de prévenir avant tout changement. Le modèle le moins cher de la famille a pris la place du vaisseau amiral en matière de prix et sur les propres benchmarks de DeepSeek, et DeepSeek affirme que l’architecture sous-jacente a été conçue pour passer à l’échelle vers des modèles plus grands. Ce qui se situe au-dessus relève, en date du 25 septembre, de la supposition d’un tracker — une gamme à trois niveaux Flash, Pro et Ultra à 522 B, 2 T et 8 T de paramètres — avancée par le compte qui l’a publiée à titre de spéculation et confirmée par rien de ce que DeepSeek a publié. Le troisième, c’est celui que la bêta n’a jamais eu. Artificial Analysis a désormais publié les premières évaluations externes du modèle — un score de 39 à l’Intelligence Index en mode Reasoning à effort maximal pour les poids de septembre, et de 45 pour le checkpoint 1017 (un gain de six points qui l’égale à GLM-5.3 à la deuxième place parmi les modèles à poids ouverts, un point derrière MiMo-V2.6-Pro), contre 36 pour DeepSeek V4 Pro 0813 sur la même échelle, ce qui fait du modèle à 552 B le modèle DeepSeek le mieux noté que le site ait mesuré. Dix autres éléments sont postérieurs à la sortie et pointent dans des directions différentes. Le 25 septembre, le responsable des tests de modèles d’ARC Prize a ouvert une pull request ajoutant un profil DeepSeek V4.1 Flash de première classe au harnais d’évaluation de la fondation — l’évaluateur dont le classement est lu dans ce domaine comme un plafond de raisonnement plutôt qu’un contrôle de productivité, arrivant sans résultat attaché et sans qu’aucun ne soit promis. Trois jours plus tard, un laboratoire externe a publié le type de nouvelles opposé : une mesure achevée, sur un autre classement, qui place DeepSeek V4.1 Flash à côté d’un autre modèle à poids ouverts et le trouve le plus faible des deux — et constate que le chiffre varie davantage selon le harnais qui entoure le modèle que selon le modèle lui-même. Sur Exploit Bench, un benchmark de Carnegie Mellon notant jusqu’où un agent progresse vers l’exploitation complète d’un V8 de production, DeepSeek V4.1 Flash a obtenu en moyenne 4,7 sur 16 dans la configuration par défaut du benchmark et 9,3 sous Claude Code, tandis que GLM-5.3-Flash a culminé à 10,6 sous Codex et est tombé à 6,2 sous le harnais même qui convient le mieux à DeepSeek V4.1 Flash. Le troisième est le moins spectaculaire et le plus facile à vérifier : le 7 octobre, le projet vLLM a publié son propre bilan de trois semaines de service de ce modèle, indiquant que sa version actuelle est 1,9 fois plus rapide à faible concurrence et 5,3 fois plus performante en débit sous une contrainte de 150 TPS par rapport à sa propre implémentation du jour 0 — un avant-après d’un moteur sur lui-même plutôt qu’une nouvelle évaluation externe, et le sujet de la section sur la vitesse ci-dessous. Un quatrième porte sur ce que coûte l’usage du modèle plutôt que sur ses scores, et il a bougé deux fois en trois jours : le 12 octobre, OpenCode, l’agent de codage qui facture ce modèle par allocation d’usage mensuelle plutôt que par tokens mesurés, a porté son allocation de 60 à 80 dollars — déclaration de la plateforme elle-même sur un produit qu’elle vend, affichée sur sa propre page tarifaire — et le 15 octobre, il a commencé à servir le même modèle gratuitement, sous un second identifiant de modèle, sur un contexte de 200 000 tokens contre la fenêtre de 1 M que porte l’entrée facturée. Un cinquième, daté du 14 octobre, mesure le coût de service du modèle plutôt que sa qualité : Artificial Analysis a ajouté DeepSeek V4.1 Flash à AA-AgentPerf, son benchmark matériel pour l’inférence agentique, avec des résultats sur accélérateurs NVIDIA et AMD — à 100 tokens par seconde et par utilisateur, le GB300 NVL72 de NVIDIA mène le peloton à environ 261 millions de tokens par seconde par mégawatt, et les mêmes exécutions servent le modèle sur aussi peu que deux accélérateurs, ce qui correspond à la section ci-dessous exprimée dans une seconde monnaie. Le sixième est la sortie elle-même, supplantée : le 17 octobre, DeepSeek a remplacé le checkpoint derrière le même nom de modèle deepseek-flash par DeepSeek-V4.1-Flash-1017 — nouveaux poids, tableau de benchmarks du fournisseur qui bat le modèle de septembre sur chaque ligne qu’il publie, même grille tarifaire et même enveloppe de 1 M de tokens — et, en date du 18 octobre, une mesure externe des nouveaux poids qui contredit la ligne que le fournisseur met en avant : Artificial Analysis note le checkpoint 1017 à 45 sur son Intelligence Index et à 33,8 sur Terminal-Bench 4.0 sous son propre harnais, contre 42,3 sur la fiche de DeepSeek. Le septième élément est la controverse qu’a suscitée cet écart. Le 19 octobre, un compte de tracker connu pour avoir annoncé ces sorties en avance s’est déclaré « absolument certain » que le 42,3 est réel « parce qu’il est meilleur que GLM-5.3 », et a demandé à Artificial Analysis d’exécuter le modèle dans un harnais natif. Le site avait déjà répondu la veille, avec un chiffre inférieur de huit points et demi. Le huitième n’est pas un score : le 20 octobre, un tracker de DeepSeek a publié une transcription d’agent dans laquelle le checkpoint 1017 a refusé une persona jailbreakée à laquelle était appliqué dsh-purge — un plugin conçu pour retirer les contraintes propres au harnais — et les notes d’abliteration d’un tiers situent le taux de refus du checkpoint non modifié à 97 sur 100 prompts nuisibles en mode chat et à 98 en mode think, DeepSeek ne publiant aucune évaluation de sécurité propre pour l’un ou l’autre checkpoint. Le neuvième n’est ni un score ni un prix : cette semaine, DeepSeek a ouvert le moteur d’inférence sur lequel tourne son propre service, avec une courbe de décodage pour le checkpoint 1017 et les chiffres de production qui la sous-tendent, et le fil qui l’a mis au jour cette semaine confronte cette courbe à un benchmark Ascend 950DT du 30 septembre qui situe la puce de Huawei environ cinq à sept fois en retrait par puce — la section sur le silicium de service ci-dessous. Le dixième n’est ni un score, ni un prix, ni un checkpoint : le 22 octobre, YuyuantanTan, le compte d’actualité tenu par China Media Group, a rapporté que DeepSeek et MiniMax avaient achevé les procédures d’enregistrement liées au projet de catalogue chinois des technologies à l’exportation et terminé l’ouverture des modèles et l’octroi de licences à l’étranger. Il s’agit d’un reportage de média d’État sur deux entreprises, et non d’un avis de régulateur ou d’une déclaration d’entreprise, et c’est l’évolution qui répond à la question ouverte par le projet de catalogue le 16 octobre — à savoir si les poids sous licence MIT dont traite cet article peuvent continuer à être publiés et expédiés à l’étranger. La section sur les licences ci-dessous distingue ce que le rapport dit de ce qu’il ne dit pas.

Tout ce qui suit distingue deux types d’affirmations. Les spécifications, benchmarks et prix proviennent du changelog, de la fiche modèle et du rapport technique de DeepSeek — publiés par le fournisseur, exécutés par le fournisseur, et non reproduits par quiconque d’autre. Cet écart s’est depuis réduit grâce à quatre instruments indépendants — un indice composite, un classement communautaire de kernels, un benchmark cyber contrôlé par un harnais et un benchmark de service matériel — dont l’un, l’indice, a désormais été exécuté sur les deux checkpoints. Aucun d’eux ne reproduit une seule ligne de fournisseur, et ARC Prize construit encore l’évaluation de raisonnement, dont rien n’a encore été publié. DeepSeek a remplacé le modèle derrière le même nom d’API le 17 octobre par le checkpoint DeepSeek-V4.1-Flash-1017. Pendant une journée, cela a signifié que chaque chiffre externe de cet article décrivait des poids que le fournisseur ne servait plus, sans score externe pour ceux qu’il servait désormais ; le 18 octobre, Artificial Analysis a réexécuté son indice sur le nouveau checkpoint et publié 45, contre 39 pour les poids de septembre. Les trois autres instruments n’ont pas été réexécutés : le benchmark cyber, le classement de kernels et le benchmark matériel décrivent encore les poids de septembre, et aucun score indépendant, ancien ou nouveau, ne reproduit l’une des lignes de benchmark de DeepSeek. Le chiffre du coût de service publié par le projet vLLM le 17 octobre n’est plus récent que par sa date de publication : le graphique qui le sous-tend est daté du 16 octobre, la veille du remplacement, il décrit donc les mêmes poids supplantés. Sur son indice actuel (v4.3.2), Artificial Analysis note le checkpoint DeepSeek V4.1 Flash de septembre à 39 et le checkpoint 1017 à 45, en décrivant les deux comme nettement au-dessus de la médiane de 19 pour les modèles à poids ouverts de taille comparable ; ce sont de véritables chiffres de tiers et les premiers de cette histoire que DeepSeek n’a pas produits. Chacun est un composite de dix évaluations, non une reproduction d’une ligne de fournisseur individuelle, et il ne dit rien de l’économie du contexte de 1 M. Les chiffres de refus dans cet article sont un quatrième type d’affirmation et sont étiquetés là où ils apparaissent : ils proviennent de personnes qui construisent des dérivés non censurés de ces poids, non de DeepSeek ni d’un laboratoire d’évaluation, et DeepSeek n’a publié aucune évaluation de sûreté pour l’un ou l’autre checkpoint. Les chiffres matériels de la section sur le service constituent encore une autre catégorie : la courbe de décodage NVIDIA et les chiffres de production sont les propres mesures de DeepSeek sur son propre moteur, publiées avec le code cette semaine, et les points Ascend proviennent d’une fiche de benchmark reproduite dans un fil sur X qui n’est publiée sur le site d’aucun des deux fournisseurs. Lorsqu’un chiffre appartient à DeepSeek, cet article le précise. Une catégorie de plus se situe hors de cette taxonomie. La dépêche du 22 octobre selon laquelle DeepSeek et MiniMax ont achevé leur enregistrement au titre du projet de catalogue d’exportation émane des médias d’État — YuyuantanTan de China Media Group, repris par plusieurs médias financiers chinois — et non d’un avis du ministère du Commerce, et DeepSeek n’a publié aucune déclaration le confirmant. Le catalogue lui-même est un projet gouvernemental ouvert aux commentaires jusqu’au 15 novembre, et il est décrit comme un projet partout où il apparaît ici. Les noms de build associés à la dépêche — V4.1F-1017 et M3.1-Flash — proviennent d’un seul compte X le 23 octobre et n’apparaissent ni dans la dépêche des médias d’État ni dans les médias qui l’ont relayée ; le checkpoint nommé dans cette publication était déjà téléchargeable depuis six jours lorsqu’elle a été écrite.

Le checkpoint du 17 octobre : ce que DeepSeek-V4.1-Flash-1017 a changé

Cinq semaines après la sortie autour de laquelle cet article est construit, DeepSeek a remplacé le modèle qui la sous-tendait. L'entrée du journal des modifications datée du 17 octobre tient en trois phrases : « DeepSeek V4.1 Flash a été mis à niveau vers DeepSeek-V4.1-Flash-1017. Les modèles officiels du web et de l'APP ont également été mis à jour vers la nouvelle version. La méthode d'appel de l'API et la tarification restent inchangées — il suffit d'utiliser deepseek-flash pour accéder au modèle le plus récent. » Tout, dans cette citation, est le fournisseur parlant de son propre produit, et les trois affirmations sont vérifiables sur les propres pages de DeepSeek plutôt que prises pour argent comptant : la ligne de version du modèle dans le tableau Models & Pricing indique désormais DeepSeek-V4.1-Flash-1017 là où elle indiquait DeepSeek-V4.1-Flash, la grille tarifaire qui l'accompagne est la même répartition heures creuses / heures pleines publiée le 10 septembre — 0,003 $, 0,15 $ et 0,60 $ par million de tokens en heures creuses, doublant à 0,006 $, 0,30 $ et 1,20 $ dans les fenêtres de pointe en semaine — et le guide de démarrage rapide de l'API mentionne toujours deepseek-flash comme chaîne de modèle, avec le contexte de 1 M de tokens, le plafond de sortie de 384 K et la limite de concurrence de 2 500 requêtes inchangés. Les identifiants d'alias retirés se comportent comme l'annonçait la note de septembre : deepseek-v4-flash et deepseek-v4-flash-vision-exp sont toujours acceptés et répondent désormais en tant que DeepSeek-V4.1-Flash-1017 aux tarifs Flash. DeepSeek a annoncé le même changement depuis son propre compte ce jour-là, et la publication mérite d'être lue en parallèle du journal des modifications, car elle est plus courte et plus directe : « DeepSeek-V4.1-Flash-1017 est arrivé ! Des performances de benchmark plus fortes, une exécution des tâches plus rapide et des sorties plus courtes que la version précédente — une amélioration au sens de Pareto en performance et en coût. Désormais disponible sur notre site web, notre application et notre API », suivie des trois mêmes harnais de test et de la même instruction de passer à DeepSeek Harness 0.2.1-rc.1 ou une version ultérieure. Tout y est le fournisseur décrivant son propre produit sur son propre canal : « désormais disponible sur notre site web, notre application et notre API » n'est que la reformulation du « les modèles officiels du web et de l'APP ont également été mis à jour » du journal des modifications, et les affirmations sur les benchmarks, le temps d'exécution, la longueur des sorties et le Pareto sont celles de la fiche du modèle — avec une différence qui compte pour quiconque décide s'il faut l'essayer. La fiche porte un chiffre à côté de chaque ligne de benchmark ; la publication n'en porte aucun, et ni la publication ni le journal des modifications ne chiffrent l'affirmation sur le temps d'exécution et la longueur des sorties. Deux des quatre éléments que DeepSeek met en avant ici restent des assertions du fournisseur plutôt que des résultats publiés, et le graphique qui sous-tend la mention de Pareto — celui joint à la publication — est celui de DeepSeek, tracé à partir de ses propres mesures de coût par tâche.

Les poids ont suivi, et c’est la partie qu’un lecteur peut vérifier sans faire confiance à un changelog. Un second dépôt, deepseek-ai/DeepSeek-V4.1-Flash-1017, a été mis en ligne sur Hugging Face aux premières heures du 17 octobre sous la même licence MIT : de nouveau 48 shards safetensors, toujours au total environ 510 Go, chaque shard de la même taille que son homologue de septembre, et l’empreinte de chaque shard différente. Même forme, contenus différents — ce à quoi « une mise à jour mineure » devrait ressembler de l’extérieur, et ce qui signifie aussi que les affirmations architecturales que cet article rapporte depuis septembre restent inchangées : le fichier de configuration qui déclare le backbone de 552B, les 384 experts routés, le chemin de prefill à 8B de paramètres actifs par token et le chemin de decode à 16B est identique octet pour octet à celui du dépôt de septembre, si bien que le cache KV de 890 octets par token relève du même design et non d’un nouveau. Ce que le nouveau dépôt ne contient pas, c’est la documentation. Il n’y a pas de rapport technique, pas de dossier d’évaluation et pas de template de chat Jinja ; la fiche modèle indique que cette version ne comprend pas de template de chat et renvoie plutôt vers une référence d’encodage Python et une nouvelle boîte à outils Rust, deepseek-recipe, pour convertir les requêtes Chat Completions, Responses et au format Anthropic dans le format de prompt du modèle. Quiconque épingle des poids par nom de dépôt doit savoir que les deux téléchargements diffèrent par plus que leurs empreintes. La liste des fichiers l’explique précisément : les 48 shards portent tous une somme de contrôle différente et une taille en octets identique, tandis que les fichiers qui ne sont pas des poids — la configuration qui déclare l’architecture, la licence et l’ensemble du dossier d’encodage — sont identiques octet pour octet dans les deux dépôts. Sept fichiers sont présents dans le dépôt de septembre et absents de celui-ci, et rien n’a été ajouté pour les remplacer : le rapport technique, le dossier d’évaluation, le template de chat, les deux figures que la fiche intégrait auparavant, et un .gitignore. La fiche modèle resserre aussi un paramètre de service. La fiche de septembre recommandait soit un top_p de 0,95, soit 1,0 ; celle du 17 octobre recommande 1,0, tout en laissant inchangés la température à 1,0, la fenêtre de contexte de 1M et le max_tokens d’au moins 256K.

C'est dans le propre tableau de benchmarks de DeepSeek que la mise à jour est censée se manifester, et il s'agit d'un tableau de fournisseur exactement du type de celui des lignes de septembre : des exécutions réalisées par la même entreprise, non reproduites par quiconque, publiées sur un modèle dont les poids étaient publics depuis quelques heures. Face au checkpoint de septembre, il progresse sur chaque ligne que porte la fiche — HLE sans outils 42,6 contre 36,8, ou 44,0 contre 39,1 sur le sous-ensemble texte uniquement ; Terminal-Bench 4.0 42,3 contre 31,2 ; DeepSWE v1.1 77,0 contre 74,2 ; ProgramBench 29,1 contre 20,3 ; NL2Repo-Bench 68,2 contre 65,4 ; Automation-Bench v1.0.6 60,5 contre 54,8 ; Agents' Last Exam 35,4 contre 31,8 ; Apex Bench v1.1 72,1 contre 64,6 ; Chartography avec outils 83,0 contre 78,9 ; BabyVision avec outils 92,5 contre 89,6 ; et ZeroBench-main avec outils 51,0 contre 49,0, en Pass@5. Le même tableau situe 1017 face aux modèles de frontière auxquels DeepSeek se compare : il dépasse désormais GPT-5.6 Sol sur Terminal-Bench 4.0, 42,3 contre 39,9, tout en restant derrière Opus 5 à 51,8, et il devance les deux sur DeepSWE v1.1, 77,0 contre 73,0 et 74,0 — une ligne relevée sur le graphique joint à l'annonce du fournisseur lui-même, et le chiffre le plus cité de la semaine. Sur NL2Repo-Bench, il passe à 68,2 et reste derrière Opus 5 à 75,3, ce qui est aussi la configuration du tableau de septembre : le plus fort sur le travail agentique sous harnais, en retrait sur les lignes qui récompensent la profondeur du raisonnement. La ligne Terminal-Bench 4.0 est celle qu'il faut lire deux fois, car c'est désormais la seule ligne de ce tableau à avoir une contrepartie indépendante. DeepSeek l'a exécutée sous le harnais Claude Code ; Artificial Analysis exécute les mêmes 66 tâches sous mini-swe-agent, et son résultat du 18 octobre pour ces poids est de 33,8 — huit points et demi en dessous des 42,3 du fournisseur. Sur le propre tableau de DeepSeek, cette ligne dépasse GLM-5.3 de 4,4 points, 42,3 contre 37,9. Sous le harnais d'Artificial Analysis, les mêmes poids sont derrière GLM-5.3 de huit points, 33,8 contre 41,9.

Une ligne en petits caractères vaut plus que plusieurs de ces deltas. La fiche de septembre évaluait Terminal-Bench 4.0 avec DeepSeek Harness dans son mode Minimal ; la fiche 1017 indique avoir utilisé le harnais Claude Code pour Terminal-Bench 4.0 et Mini-SWE-V2 pour DeepSWE v1.1. L’étude sur les harnais plus bas dans cet article a mesuré sept points d’écart sur un même modèle à travers sept CLI d’agents ; ainsi, une progression de onze points sur Terminal-Bench 4.0 qui arrive avec un harnais différent en dessous ne peut pas être interprétée comme onze points de modèle. La fiche indique quel harnais elle a utilisé, ce qui rend la ligne auditable plutôt que simplement impressionnante, mais cette ligne correspond à deux changements sous un seul chiffre. L’exécution indépendante les sépare, et pas à l’avantage du fournisseur. Artificial Analysis a évalué les mêmes poids 1017 sur Terminal-Bench 4.0 avec mini-swe-agent — le harnais qu’elle maintient constant pour chaque modèle de ce classement — et a obtenu 33,8, contre 26,8 pour le checkpoint de septembre avec le même harnais. À harnais fixe, le checkpoint vaut sept points, pas onze, et le chiffre phare de DeepSeek se situe huit points et demi au-dessus de ce que les mêmes poids obtiennent lorsque le harnais est maintenu constant d’un modèle à l’autre. Le reste du cadrage de DeepSeek porte sur le coût plutôt que sur le score, et c’est le même axe sur lequel la version de septembre a été vendue : le changelog affirme que la mise à jour réduit le temps d’exécution des tâches et la longueur des sorties, qualifie le résultat de « nouveau optimum de Pareto performance-coût à travers plusieurs harnais » et indique avoir optimisé pour DeepSeek Harness, Tencent CodeBuddy et WorkBuddy, en recommandant DeepSeek Harness 0.2.1-rc.1 ou une version ultérieure. Le temps d’exécution et la longueur des sorties sont précisément les grandeurs que les éléments de preuve sur la verbosité de cet article suivent de l’extérieur, et DeepSeek affirme désormais avoir réduit les deux — sans avancer aucun chiffre. Il existe désormais une mesure externe du nouveau checkpoint, et elle ne montre ni la réduction du temps d’exécution ni celle des sorties : l’exécution d’index d’Artificial Analysis situe les poids 1017 à 288,8 secondes par tâche, contre 289,9 pour septembre, et à 89 495 jetons de sortie par tâche, contre 88 574 — stable sur les deux, l’économie de coût se retrouvant ailleurs. Le post que DeepSeek a publié sur son propre compte le même jour résume tout cela par « exécution des tâches plus rapide et sorties plus courtes », puis qualifie ce couple d’amélioration de Pareto en performance et en coût — la revendication du changelog sous une forme plus courte, issue de la même source, et tout aussi peu étayée par des mesures. C’est le fournisseur qui se répète, pas une seconde source — ce qui compte, car le chiffre issu de ce graphique est celui que le monde extérieur a passé la semaine à répéter. Le seul élément de l’annonce qui contient réellement des chiffres est le graphique joint au post, et il représente le Pass@1 de DeepSWE v1.1 en fonction du coût moyen par tâche avec un harnais mini_swe_v2. Sa légende mérite d’être lue avant la mention du Pareto : les données publiques de classement qui la sous-tendent sont datées du 22 septembre sur le graphique lui-même, trois semaines et demie avant le checkpoint que le graphique sert à promouvoir, et les lignes de comparaison des modèles d’OpenAI sont attribuées au propre graphique DeepSWE d’OpenAI plutôt qu’à une exécution commune. Un seul point de ce graphique est nouveau. Tout ce à quoi il est comparé a été publié avant son existence.

Le jour même du remplacement, l’interprétation la plus partagée de ce tableau provenait d’une personne ayant un intérêt direct dans l’endroit où le modèle s’exécute. Yuchen Jin, qui travaille sur les systèmes d’IA chez Databricks, a publié que DeepSeek-V4.1-Flash-1017 « obtient 77 sur DeepSWE v1.1 », qu’il s’agit de « performances du niveau d’Opus 5 pour un coût 83 fois inférieur » et que « nous allons le lancer sur Databricks ». Le 77 est la propre ligne de DeepSeek, reprise du graphique joint à l’annonce du fournisseur, et rien en dehors de l’entreprise ne l’a reproduit. Les deux points de comparaison sont de Jin, et ils se divisent nettement entre un point qui résiste à une vérification externe et un autre qui n’y résiste pas. Le niveau d’Opus 5 tient : les classements indépendants qui publient DeepSWE v1.1 placent le nom de ce modèle dans ce voisinage lors de leurs propres exécutions. Le classement APEX de Mercor — 113 tâches originales réparties sur 91 dépôts, notées avec le harnais mini-swe-agent — place Opus 5 Max à 71,4 % et une entrée DeepSeek V4.1 Flash Max à 71,7 %, et le tableau llm-stats pour le même benchmark place Claude Opus 5 à 68,8 % contre 74,2 % pour DeepSeek-V4.1-Flash. L’interprétation honnête de ce couple de points est plus étroite que ne le suggère la publication : deux tableaux qui mesurent ce benchmark indépendamment conviennent que le modèle est au moins l’égal d’Opus 5 sur celui-ci, et aucun des deux n’affiche 77, car tous deux portent soit le chiffre de septembre, soit leur propre exécution, et aucun n’étiquette une entrée avec le checkpoint 1017. Le niveau d’Opus 5 est défendable comme affirmation sur un voisinage. Le nombre qui l’a produit n’est pas encore reproductible.

La moitié « 83× » de la publication relève de son calcul plutôt que d’un chiffre publié, et c’est cette moitié qu’il faut prendre avec des pincettes. Aucun classement n’affiche de coût par tâche pour le checkpoint 1017, et le graphique du fournisseur qui sous-tend la propre revendication Pareto de DeepSeek trace le coût par tâche sur un axe logarithmique allant de dix cents à vingt dollars — le type d’amplitude qu’exige un multiple aussi grand. En se limitant aux tarifs catalogue, l’écart est plus étroit que 83× : Claude Opus 5 facture 5 $ par million de tokens d’entrée et 25 $ par million de tokens de sortie, contre 0,30 $ et 1,20 $ pour DeepSeek-V4.1-Flash dans les fenêtres de pointe en semaine, soit environ 17× en entrée et 21× en sortie, et le résultat varie fortement selon la part de hits de cache et le nombre de tokens qu’une tâche consomme. Le sens de l’argument sur les coûts ne prête pas à controverse, ni ici ni ailleurs dans cet article. Le multiple précis est une affirmation portant sur une comparaison que personne n’a publiée.

Databricks est la partie de cet article que le lecteur peut vérifier dans la documentation, et la documentation en dit plus que l’article. DeepSeek V4.1 Flash est disponible sur Databricks Unity Gateway depuis le 11 septembre, le lendemain du lancement de DeepSeek, avec des entrées texte et image via les Foundation Model APIs de la plateforme sous le nom de service system.ai.deepseek-v4-1-flash ; le 7 octobre, la plateforme a ajouté pour ce modèle le paiement à l’usage prioritaire par token et le débit provisionné réservé. C’est aussi la destination désignée par la plateforme pour cette famille : Databricks a programmé la mise hors service de DeepSeek V4 Pro (0813) au 30 octobre et de DeepSeek V4 Flash (0731) au 5 novembre, en désignant DeepSeek V4.1 Flash comme remplacement recommandé dans les deux notes. Ce qu’aucune page Databricks ne dit, c’est que le checkpoint du 17 octobre est à venir. Cette affirmation provient d’un employé s’exprimant à titre personnel — un signal interne quant à une intention plutôt qu’une date de livraison, et la page des modèles pris en charge répertorie toujours le modèle sans étiquette de checkpoint. Ainsi, le changement de disponibilité de cette semaine est prospectif, et provient d’une source interne à la plateforme plutôt que de la plateforme elle-même ; ce qu’un client Databricks peut appeler aujourd’hui, ce sont les poids de septembre, et la substitution que cet article décrit — de nouveaux poids derrière le même nom et la même grille tarifaire — est la forme que prendra ce remplacement lorsqu’il sera effectif.

Ce qui n’a pas changé est donc tout aussi important que ce qui a changé. Trois des quatre instruments indépendants couvrent encore les pondérations de septembre, et seulement celles-ci : la table du harnais Exploit Bench, le tableau communautaire des noyaux et les exécutions matérielles AA-AgentPerf ont tous été produits avant le remplacement, et les deux tableaux DeepSWE v1.1 qui portent le nom de ce modèle publient une entrée sans checkpoint associé. Le quatrième a changé le 18 octobre : Artificial Analysis a ajouté une ligne distincte pour le checkpoint 1017, l’a noté 45 sur son Intelligence Index et 33,8 sur Terminal-Bench 4.0, et a laissé la ligne de septembre à 39 et 26,8. C’est la première fois qu’un chiffre de cet article a été produit par quelqu’un d’autre que DeepSeek sur les pondérations que DeepSeek sert actuellement. Le changement d’API est un rafraîchissement de checkpoint derrière un nom que DeepSeek avait déjà documenté comme pointant vers le dernier modèle Flash — l’inverse du plan de septembre visant à faire répondre deepseek-v4-pro comme un autre modèle, ce qui est la distinction que les développeurs faisaient lorsqu’ils s’y sont opposés. Pour un appelant, l’effet pratique est étroit et concret : demander deepseek-flash obtient désormais des pondérations différentes au même prix, avec derrière elles un meilleur tableau rapporté par le fournisseur et, depuis le 18 octobre, un tiers qui les note — plus bas sur la seule ligne où les deux existent. Sur OrcaRouter, l’identifiant du modèle et la grille tarifaire sont également inchangés — DeepSeek V4.1 Flash est routé au prix catalogue de DeepSeek lui-même, avec 0 % de marge répercutée — ce qui correspond à ce à quoi devrait ressembler, du côté de l’appelant, un fournisseur qui rafraîchit un modèle sans changer son nom ni son prix.

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

L’entrée du journal des modifications commence par une seule phrase : « Aujourd’hui, nous publions officiellement le modèle DeepSeek-V4.1-Flash. » DeepSeek le décrit comme le plus petit membre d’une nouvelle famille de structures de modèles, doté d’une compréhension visuelle native, et il s’agit de la première publication de ce cycle à être accompagnée d’un rapport technique. Du côté de l’API, il s’agit d’un changement de nom plutôt que d’une migration :

• Nom du modèle — deepseek-flash sur l'API propre à DeepSeek ; l'URL de base, la clé et le format de requête sont inchangés.

• Retiré — DeepSeek V4 Flash et DeepSeek-V4-Flash-Vision-Exp sont hors ligne. Leurs anciens identifiants sont toujours acceptés et acheminent désormais vers V4.1 Flash, facturés aux tarifs Flash, de sorte que les intégrations existantes continuent de fonctionner sans modification de code.

• V4 Pro — DeepSeek a annoncé qu'à partir de 12h00, heure de Pékin, le 14 septembre, les requêtes deepseek-v4-pro seraient acheminées vers V4.1 Flash aux tarifs de V4.1 Flash jusqu'à la sortie d'un V4.1 Pro, avant de revenir sur cette décision avant la date prévue. V4 Pro est toujours servi, avec une facturation inchangée, et DeepSeek indique qu'il préviendra en cas de nouveau changement.

• Envelope — une fenêtre de contexte de 1M de jetons, une sortie maximale de 384K, 2 500 requêtes simultanées par compte, entrée d'images prise en charge, mode réflexion activé par défaut avec une option sans réflexion.

• Poids — le jour même, le dépôt deepseek-ai/DeepSeek-V4.1-Flash a été mis en ligne sur Hugging Face sous licence MIT : 48 fragments safetensors totalisant environ 510 Go, le rapport technique au format PDF à côté, et une implémentation d'inférence de référence dans un dossier inference.

Ce dernier point est aussi celui où l'histoire de l'identifiant de modèle retiré se joue pour quiconque a deepseek-v4-flash codé en dur dans un chemin de production : il se résout toujours, mais c'est un autre modèle qui répond. DeepSeek a clairement indiqué qu'il s'agit d'une couche de compatibilité et non d'une promesse, ce qui en fait une échéance de migration déguisée en avis de dépréciation.

L'architecture, désormais consignée

Il y a deux jours, cette section n'aurait pu être qu'une liste de choses que personne n'avait publiées. Le rapport technique tranche la question, et l'affirmation structurelle s'avère avoir été littérale plutôt que marketing. DeepSeek V4.1 Flash est un modèle multimodal à mélange d'experts de 552 milliards de paramètres, et les parties qui sont nouvelles sont celles qui déterminent son coût d'exécution :

• Backbone — 552B de paramètres au total, mixture-of-experts avec un expert partagé et 384 experts routés par couche, six experts routés actifs par jeton.

• CED — un transformateur à 40 couches divisé en un encodeur causal de 20 couches et un décodeur de 20 couches. Le cache KV global du décodeur est projeté à partir des états cachés finaux de l'encodeur au lieu d'être dérivé des états cachés propres à chaque couche du décodeur, ce qui constitue l'essentiel de l'économie de mémoire.

• Asymétrie d'activation — environ 8B paramètres actifs par jeton pendant le préremplissage et 16B pendant le décodage, de sorte que la lecture d'une longue invite est nettement moins coûteuse que la génération à partir de celle-ci.

• Cache KV — le rapport affirme 890 octets par jeton de cache KV global, environ un quart de celui de DeepSeek V4 Flash, utilisant un cache KV principal en FP4 avec une échelle tous les 16 canaux, ainsi qu'une réutilisation inter-couches.

• Attention et décodage — Compressed Sparse Attention 2 avec les modes Full, Reindex et Reuse et un indexeur hiérarchique épars, Single-Pass mHC et le décodage spéculatif DSpark.

• Engram — une table de mémoire conditionnelle de 196 milliards de paramètres, accessible de manière éparse via une consultation basée sur les tokens, qui se trouve à côté de la voie du mélange d’experts plutôt qu’à l’intérieur de la pile d’attention. C’est le plus grand bloc de poids unique de cette version, et le chiffre que lui consacre la fiche du modèle est ce qui rend la taille du téléchargement compréhensible.

Vision — DeepSeek-ViT avec un projecteur MLP à deux couches, entraîné dès le début du pré-entraînement du modèle de langage plutôt que greffé ensuite sur une base textuelle.

• Entraînement — 45T de tokens de corpus multimodal, avec attention sparse entraînée sur une longueur de séquence de 64K et contexte étendu à 1M au jalon de 34T tokens. Le post-entraînement enchaîne SFT, puis RL, puis distillation on-policy.

{{1}}Effort de raisonnement{{/1}} — un entier réglable en continu de 1 à 100, un réglage plus fin que les paliers faible, élevé et maximum que DeepSeek V4 Pro {{2}}expose{{/2}}.

Le chiffre du cache KV est celui qui a des conséquences au-delà de la fiche technique, et c’est là que la conception justifie sa valeur. Une fenêtre de contexte de 1M de jetons n’est utile que si vous pouvez vous permettre de la remplir. Les raisons pour lesquelles l’équation économique du contexte long de la génération précédente était douloureuse étaient doubles : le cache global grandissait avec chaque couche qui appliquait son attention sur le prompt, et l’essentiel de la capacité de cache persistante servait à conserver un état de fenêtre glissante qui cessait d’être utile en quelques minutes. La réponse du rapport s’attaque aux deux. Savoir si le produit servi y correspond à 1M de jetons sous concurrence réelle est le genre d’affirmation qui nécessite encore un tiers — les scores indépendants qui existent désormais mesurent le modèle, et non l’équation économique du contexte long —, mais le mécanisme est désormais documenté plutôt que déduit, et la section ci-dessous le décortique.

Dans le cache : comment 890 octets par token sont réellement obtenus

Le titre du rapport est la thèse. À sa lecture, l’argument d’efficacité cesse d’apparaître comme un effet secondaire de l’architecture mixture-of-experts et commence à ressembler au cahier des charges de conception — c’est la lecture sur laquelle les analyses indépendantes convergent depuis la publication. Si cela compte sur le plan commercial plutôt qu’académique, c’est parce que la facture d’un agent se matérialise réellement à un endroit précis : selon la formulation de DeepSeek, c’est la ligne des hits de cache qui domine cette facture sur les charges de travail agentiques longues, ce qui fait de la taille du cache un levier de coût de premier ordre. Les chiffres de DeepSeek situent le cache global à 890 octets par token, soit environ 437× plus petit que le DeepSeek V1 d’origine et environ un quart de DeepSeek V4 Flash. Faites le calcul sur une fenêtre complète : cela fait la différence entre environ 890 Mo de KV global pour une seule séquence de 1 M de tokens et environ 3,5 Go au taux par token de V4 Flash. Trois changements réalisent l’essentiel de la compression : un sur la quantité stockée, un sur ce qui est lu, et un sur ce qui est conservé tout court.

Le format de stockage est le plus lisible d’entre eux. Le cache global principal est stocké en FP4 selon la disposition E2M1, avec une échelle E4M3 par 16 canaux — soit la moitié de la largeur du cache FP8 stocké par DeepSeek V4 et un quart du FP16. Ce qui rend cela viable, c’est que DeepSeek a quantifié le cache pendant l’entraînement plutôt qu’au moment du service, de sorte que le bruit introduit par le format plus étroit est quelque chose que le modèle a appris à contourner, plutôt que quelque chose qui lui est infligé après coup. Tout n’a pas été compressé de cette façon : le cache local à fenêtre glissante reste en FP8, car le rapport le considère comme la partie sensible à un rétrécissement supplémentaire.

Compressed Sparse Attention 2 gère ce qui est lu. Chaque couche d’attention se voit attribuer statiquement l’un de trois modes — Full, Reindex ou Reuse — afin que les couches de décodeur puissent partager l’état de clé et l’état d’indexeur au lieu que chacune conserve le sien, et la première couche en mode Full construit un pool de candidats auquel les couches d’indexation ultérieures sont restreintes. Les chiffres du rapport fixent ce pool à 16 384 positions, la sélection parcimonieuse portant sur les 512 meilleures entrées, ce qui dissocie le coût d’indexation de la longueur du contexte : DeepSeek affirme que le passage d’un contexte de 4K à 1M n’ajoute qu’environ un quart de calcul en plus par token généré, plutôt que la croissance à peu près proportionnelle à la fenêtre qu’impliquait la conception précédente. Ce seul chiffre est l’élément le plus utile du rapport pour quiconque cherche à évaluer le coût d’une charge de travail à long contexte, et c’est aussi celui qui ne bénéficie d’aucune confirmation externe — aucune des mesures externes de cet article n’a testé l’extrémité de la fenêtre de contexte.

Le changement qui compte le plus du côté persistant porte le nom le moins prometteur. DeepSeek V4 conservait deux éléments dans son cache persistant pendant plus de 72 heures dans des charges de travail typiques : le KV global et l’état d’attention à fenêtre glissante. L’état à fenêtre glissante n’a d’importance que pendant quelques minutes, mais il consommait près de la moitié de la capacité du cache persistant — un stockage dimensionné pour des jours, consacré à des données utiles pendant une minute. V4.1 Flash retire entièrement l’état SWA du cache persistant et le range dans un pool constitué d’environ 10 % de la DRAM hôte de chaque machine, avec une durée de vie de l’ordre de la minute. Lorsqu’une session reprend et que cet état a disparu, SWA Bounded Replay le reconstruit approximativement : au lieu de rejouer couches × tokens de fenêtre, il ne rejoue que la fenêtre la plus récente, annoncée à 128 tokens, et accepte que l’état reconstruit ne soit pas mathématiquement identique à un rejeu complet. DeepSeek indique avoir constaté peu d’impact sur la qualité de cette approximation et avoir simulé le même comportement lors du post-entraînement. Combinez cela avec le cache global plus réduit, et l’empreinte KV persistante tombe à environ un huitième de celle de DeepSeek V4 Flash dans des charges de travail identiques — une réduction plus importante que le chiffre du quart qui figure en tête de la fiche technique, car il s’agit de deux changements cumulés et non d’un seul changement de format.

Deux limites pèsent sur l’ensemble. Le rapport ne fournit aucune comparaison de latence de bout en bout ni de coût, si bien qu’un cache persistant huit fois plus petit ne constitue pas une charge de travail dont le coût serait démontré comme huit fois moindre : la compression soulage la pression mémoire, et seule la partie d’une facture liée à la mémoire y réagit. Et l’économie ne se produit pas d’elle-même. Un moteur doit implémenter la projection encodeur-décodeur, les trois modes CSA2, la disposition du cache FP4 et Bounded Replay avant que ce chiffre n’ait un sens, ce qui explique pourquoi 890 octets se lisent mieux comme une spécification émanant de DeepSeek pour sa propre API servie que comme une promesse concernant une compilation locale — les conversions quantifiées pour llama.cpp, Ollama et LM Studio présentes dans le dépôt n’embarquent pas ce cache. Le chiffre phare couvre également les tokens de texte ; les embeddings de vision en sont exclus. Sur tout environnement auto-hébergé, le chiffre auquel se fier est celui que vous mesurez. Jusqu’où un moteur peut aller avec cela n’est plus hypothétique, mais ce n’est toujours pas indépendant. vLLM a implémenté la réduction côté décodeur et Bounded Replay au cours des trois semaines suivant la publication, et a publié les résultats avant/après dans la section sur la vitesse ci-dessous — ce qui constitue à ce jour l’élément le plus proche d’une vérification de la spécification, et une vérification réalisée par un moteur mesurant son propre travail plutôt que par un évaluateur mesurant le modèle.

Le score indépendant, calculé deux fois : 39 pour les pondérations de septembre, 45 pour 1017

Artificial Analysis a publié la première évaluation externe de DeepSeek V4.1 Flash, et c’est le chiffre que la bêta n’a pas pu produire. Sur la version actuelle de l’Artificial Analysis Intelligence Index (v4.3.2), le modèle obtient 39 en mode Raisonnement à effort maximal. À la même échelle et avec le même réglage, DeepSeek V4 Pro 0813 obtient 36 et DeepSeek V4 Flash 0731 obtient 34. Lus ensemble, ces trois lignes disent ce que le marketing de DeepSeek revendiquait et que ses propres benchmarks ne pouvaient établir seuls : le plus petit modèle de la famille est désormais le plus performant. Artificial Analysis décrit 39 comme bien au-dessus de la médiane de 19 pour les modèles à poids ouverts de taille comparable. Pendant cinq semaines, il s’est agi d’un score pour le seul checkpoint de septembre : la fiche de l’évaluateur ne portait que la date de sortie de septembre, et rien d’autre. Le 18 octobre, cela a changé, et ce changement est l’information que cet article n’avait pas lors de sa première publication. Une deuxième ligne est apparue pour DeepSeek V4.1 Flash 1017, datée du 17 octobre, avec un score de 45 sur le même indice et au même effort maximal. Cela place les poids 1017 au niveau de GLM-5.3 à 45, deux points en dessous de GPT-5.6 Sol à 47 et six en dessous de Claude Opus 5 à 51 — et fait de ce checkpoint le modèle DeepSeek le mieux noté que le site ait mesuré, cinq semaines après que les poids de septembre ont décroché ce titre. Cela donne aussi au modèle une position qu’il n’avait pas auparavant, et que l’évaluateur énonce sans détour dans son compte rendu du 19 octobre : deuxième du classement des modèles à poids ouverts, à égalité avec GLM-5.3 et un point derrière MiMo-V2.6-Pro à 46, Step 5 Preview et Kimi K3 se trouvant un point plus loin, à 44. Les six points ne sont pas répartis uniformément entre les dix évaluations. Le même compte rendu rapporte les plus fortes progressions dans les composantes agentiques et de connaissances — un Elo GDPval-AA v2.1 de 1 746 contre 1 600, un Elo AA-Briefcase v1.1 de 1 570 contre 1 420, et un taux de non-hallucination AA-Omniscience de 33 % contre 4 %, la précision passant de 43 % à 46 % et l’indice de cette évaluation passant de -5 à +5. Ce sont les chiffres de l’évaluateur pour ses propres tests, publiés par lui plutôt que reproduits ici, et ils décrivent un modèle devenu nettement moins enclin à inventer une réponse — une amélioration différente de celle liée à la vitesse que le journal des modifications de DeepSeek met en avant.

La comparaison qui compte ici est la comparaison interne, car c’est la même que celle opérée par la table de routage de DeepSeek. V4.1 Flash embarque 552B de paramètres au total, avec 16B actifs par token ; DeepSeek V4 Pro 0813 embarque environ 1,6T au total, avec environ 49B actifs. Un modèle doté d’environ un tiers de l’ossature obtient trois points de plus sur un score composite que son créateur n’a pas exécuté — neuf points de plus une fois les poids 1017 pris en compte, puisque le fleuron de 1,6T n’a pas bougé de 36. Le compromis taille/score constitue toute la thèse de la conception Causal Encoder-Decoder, et un évaluateur sans intérêt dans le résultat a désormais produit un chiffre cohérent avec celle-ci.

Le volet tarifaire de l’affirmation tient également la route, et il s’agit de la première comparaison de prix de l’article qui ne provient pas d’une grille tarifaire DeepSeek. Artificial Analysis indique DeepSeek V4.1 Flash à 0,30 $ par million de jetons d’entrée et 1,20 $ par million de jetons de sortie, contre 1,32 $ et 3,96 $ pour DeepSeek V4 Pro 0813 — soit 4,4× moins cher en entrée et 3,3× en sortie, avec un prix mélangé de 0,18 $ par million selon la répartition 7:2:1 du site entre cache-hit, entrée et sortie. Il est aussi moins cher que l’ancien et plus petit DeepSeek V4 Flash 0731 qu’il remplace, que le site indique à 0,44 $ et 1,32 $, avec un score inférieur de cinq points. Moins cher que le modèle qu’il remplace, moins cher que le modèle qu’il détrône, et devant les deux sur l’indice.

Deux réserves s’imposent concernant ce chiffre. Il s’agit d’un composite de dix évaluations exécutées avec un effort de raisonnement maximal ; il ne dit donc rien des réglages d’effort inférieurs qu’utilise en réalité la majeure partie du trafic de production, ni de la façon dont la qualité se maintient à l’extrémité d’une fenêtre de 1 M de jetons. Et il s’agit du score d’un seul évaluateur : indépendant, mais non répliqué — et le composite lui-même a été révisé depuis que cet article l’a cité pour la première fois, passant de la v4.3 à la v4.3.2, ce qui a fait passer le score de DeepSeek V4.1 Flash de 40 à 39 et celui de son prédécesseur de 35 à 34. Ce qu’il établit est étroit et utile — l’unique affirmation que la bêta ne pouvait pas étayer, à savoir qu’un modèle de 552 B est réellement compétitif avec le fleuron 1,6 T de DeepSeek lui-même, dispose désormais d’une source extérieure à DeepSeek. La ligne 1017 porte les deux mêmes réserves, plus une autre. Il s’agit du score d’un seul évaluateur, portant sur des poids cinq semaines plus récents que la majeure partie des éléments de preuve ici, et il s’agit d’un seul composite plutôt que d’une réplication d’une ligne de fournisseur. Son prix par tâche a également évolué sur le site : le checkpoint de septembre est aujourd’hui affiché à 0,49 $ par tâche de l’Intelligence Index, là où cet article indiquait initialement 0,27 $, et le checkpoint 1017 à 0,26 $. Considérez le montant en dollars comme un chiffre dynamique sur le tableau de bord de quelqu’un d’autre, et non comme une constante — c’est la même leçon que le score de l’indice lui-même a enseignée lorsqu’il est passé de 40 à 39. Le tableau des coûts à côté du score constitue le reste de la réserve, et il joue dans les deux sens. Le modèle qui se trouve une place au-dessus coûte également moitié moins cher : MiMo-V2.6-Pro atteint 46 à 0,13 $ par tâche de l’Intelligence Index, contre 0,26 $ ici, et la propre comparaison d’Artificial Analysis place GPT-6.1 Sol à effort moyen à 48 pour 0,21 $. Ce que le checkpoint 1017 gagne, en revanche, c’est le duel que DeepSeek met en avant depuis septembre — il bat GLM-5.3-Flash sur les deux axes de ce tableau, 45 contre 42 et 0,26 $ contre 0,28 $ la tâche —, soit l’appariement où la capacité et le coût vont dans le même sens.

Le prochain score externe : ARC Prize construit le test

Le 25 septembre, Matt Mazur, responsable des tests de modèles chez ARC Prize, a ouvert une pull request dans le dépôt de benchmarking ARC-AGI-3 de la fondation elle-même, ajoutant un adaptateur de fournisseur DeepSeek de premier ordre : un profil, nommé deepseek-v4-1-flash-low-provider-adapter, dont le champ model est deepseek-ai/DeepSeek-V4.1-Flash. L'affirmation selon laquelle ARC Prize compte évaluer ce modèle est arrivée sous la forme d'un unique post sur les réseaux sociaux, nous l'avons donc vérifiée par rapport au code de la fondation elle-même plutôt que par rapport au post. L'adaptateur, le profil, ses tests unitaires et sa documentation figurent dans le diff, et le dépôt est le harnais que la politique de test d'ARC Prize désigne pour son benchmark agentique interactif. Ce qui n'existe pas, c'est un résultat : la pull request est ouverte et non fusionnée, il n'y a pas de score, pas de date de publication, et aucune indication sur les niveaux de raisonnement qui seront publiés. Ce qui importe, c'est la forme de la mesure plutôt que la nouvelle qu'une mesure arrive. ARC-AGI pose une question que les autres tableaux ne posent pas : un modèle peut être rapide, bon marché et performant à l'intérieur d'un harnais et obtenir malgré tout un score dans les soixante sur des tâches qu'il n'a pas vues. C'est la question que personne n'a encore posée à DeepSeek V4.1 Flash.

Le profil précise le déroulement d'une telle exécution, et trois détails façonneront le chiffre qui finira par être obtenu. Il exécute le modèle avec le réglage d'effort de raisonnement faible plutôt qu'au maximum, diffuse les réponses en flux, définit un contexte de harnais de 1 M de jetons avec un déclencheur de compactage par résumé à 175 000 jetons, et plafonne la sortie à 262 144 jetons. Il passe par le point de terminaison compatible OpenAI de Baseten plutôt que par celui de DeepSeek, et il est configuré à 0,30 $ par million de jetons d'entrée et 1,20 $ par million de jetons de sortie — les tarifs de pointe de DeepSeek, et non les chiffres hors pointe cités plus bas dans cet article. ARC Prize calcule le coût par tâche à partir des prix configurés dans le profil, de sorte que le chiffre final correspondra à un tarif de pointe, ce qu'il vaut la peine de garder en tête avant de le comparer aux 0,042 $ par tâche affichés par DeepSeek V4 Flash 0731 lors de son test. L'autre particularité inhabituelle est une solution de contournement liée au comportement du mode de réflexion de DeepSeek : le contenu de raisonnement historique n'est rejoué que lorsqu'une requête comporte des outils, de sorte que l'adaptateur fait émettre au modèle chaque action ARC sous forme d'appel d'outil submit_action et rejoue le message assistant exact avec son raisonnement joint, plutôt que d'extraire les actions du texte.

La barre à laquelle cela sera mesuré provient du propre classement d'ARC Prize. DeepSeek V4 Flash 0731, le checkpoint que V4.1 Flash met à la retraite, est l'entrée vérifiée du classement pour le palier Flash dont il est issu : 61,4 % sur ARC-AGI-2 avec un effort de raisonnement maximal et 89,0 % sur ARC-AGI-1, à 0,042 $ et 0,021 $ par tâche. Dots3-Note Preview se situe à 76,8 % sur ARC-AGI-2, ce qui correspond aux 77 % que vise le post qui a signalé l'adaptateur, et l'attente du même compte — que tout résultat inférieur à 80 % d'un successeur bien plus grand et nativement multimodal serait décevant — relève de sa formulation plutôt que d'une cible publiée. La partie restante de cette formulation mérite une étiquette : l'affirmation selon laquelle V4.1 Flash génère 29 % de tokens en plus que le modèle qu'il remplace est sans attribution et sans définition, et rien de ce que DeepSeek ou ARC Prize a publié ne dit ce qu'elle mesure.

Une mise en garde s'impose quant au classement dont il s'agit. L'adaptateur a été intégré au dépôt ARC-AGI-3, le harnais du benchmark agentique interactif de la fondation, et le dépôt distinct qui exécute ARC-AGI-1 et ARC-AGI-2 ne comporte aucune entrée V4.1 — sa liste de modèles n'a pas été mise à jour depuis le 27 juillet et cite encore d'anciens points de terminaison DeepSeek. Le fait datable est donc qu'ARC Prize a intégré ce modèle à son harnais agentique ; quant à savoir s'il apparaîtra aussi au classement ARC-AGI-2, où se trouve la comparaison à 61,4 %, le code public ne le montre pas aujourd'hui. La lecture pratique pour quiconque choisit un modèle s'est élargie. Quatre instruments indépendants portant sur DeepSeek V4.1 Flash sont désormais en jeu — un indice composite exécuté deux fois, une fois par checkpoint ; un classement communautaire de kernels ; un benchmark de cybersécurité contrôlé par le harnais ; et, depuis le 14 octobre, un benchmark de service sur matériel — et deux d'entre eux placent le modèle dans un harnais sur des tâches qu'il n'a pas vues. Le plus récent des deux est l'indice composite, qui intègre Terminal-Bench 4.0 depuis l'indice v4.3 : 66 tâches terminal, pass@1 moyenné sur trois répétitions, chaque modèle sous le même harnais d'agent. Son résultat du 18 octobre pour les poids 1017 est de 33,8. Le benchmark de cybersécurité, ci-dessous, est celui qui s'en approche le plus, et c'est là que ce modèle perd le seul face-à-face qu'il dispute. Le profil ARC est l'évaluation conçue pour répondre à la question du raisonnement, et c'est toujours celui qui n'a pas de chiffre. Tant qu'il n'aura pas été exécuté, le plafond de raisonnement du modèle restera non mesuré, et le chiffre auquel le comparer est celui de son prédécesseur.

Le premier score cyber externe : le harnais fait plus bouger le chiffre que le modèle

Le 28 septembre, le laboratoire d'évaluation Generality Labs a publié un suivi de ses précédents travaux en cybersécurité, intitulé « Le harness a-t-il de l'importance lors de l'exécution de Cyber Benchmarks ? » — la première mesure externe achevée qui place DeepSeek V4.1 Flash aux côtés d'un autre modèle à poids ouverts sur le même benchmark de cybersécurité. Le benchmark en question est Exploit Bench, une évaluation de Carnegie Mellon menée par Seunghyun Lee et le professeur David Brumley, qui note jusqu'où un agent gravit une échelle de seize capacités — depuis l'atteinte du code vulnérable, jusqu'au déclenchement du bug, puis à la construction de primitives d'exploitation, et enfin à l'exécution de code arbitraire — face à un V8 de production avec le bac à sable de sécurité V8 activé. Le laboratoire a exécuté deux modèles, DeepSeek V4.1 Flash et GLM-5.3-Flash de Z.ai, avec un budget de 250 millions de tokens par tâche sur 10 tâches tirées des 41 tâches originales du benchmark par la théorie de la réponse à l'item, et a répété chaque modèle selon sept configurations de harness : six CLI d'agents — Claude Code, Codex, Kimi CLI, ReAct, Gemini CLI et OpenCode — plus la configuration par défaut du benchmark lui-même, que le compte rendu appelle Original. Original n'est pas du tout une CLI tierce : elle n'a aucune limite de tokens, un plafond de 300 tours et aucune compaction du contexte. Le compte qui a signalé ce résultat décrit Original comme à peu près une boucle while en Python ; c'est sa caractérisation, et non celle des chercheurs, dont la propre description est celle donnée ci-dessus.

Le résultat est une dispersion qu'aucun score unique n'aurait révélée. La capacité moyenne est notée sur 16. DeepSeek V4.1 Flash est au mieux sous Claude Code, à 9,3, Codex arrivant en deuxième position à 8,9 ; le même modèle chute à 7,4 sur Kimi CLI, 5,9 sur OpenCode, 5,7 sur Gemini CLI, 5,3 sur ReAct et 4,7 sous Original — sa propre configuration par défaut de benchmark, et la pire des sept. GLM-5.3-Flash inverse ce classement aux deux extrémités. Sa meilleure configuration est Codex à 10,6, au-dessus du 10,02 que le propre jeu de données de l'étude attribue à Mythos Preview sur l'ensemble complet de 41 tâches, bien que les chercheurs préviennent qu'un sous-ensemble de 10 échantillons n'est pas pleinement représentatif ; son pire est Claude Code à 6,2, le même harnais qui est le meilleur pour DeepSeek V4.1 Flash, et 8,9 sur Gemini CLI, 8,2 sur Kimi CLI, 8,1 sur OpenCode, 7,7 sur ReAct et 6,4 sous Original. En moyenne sur les sept, GLM-5.3-Flash se situe près de 8,0 et DeepSeek V4.1 Flash près de 6,7. Ainsi, les deux volets de l'affirmation qui a circulé avec ce résultat se vérifient au regard des données publiées : le choix du harnais vaut plusieurs points, et sur ce benchmark DeepSeek V4.1 Flash est le plus faible des deux modèles — sauf sous Claude Code, où il devance de plus de trois points.

Les chercheurs sont explicites : ils ne peuvent pas expliquer entièrement la dispersion. Leur seul indice positif réside dans la façon dont chaque harnais compacte le contexte, et la différence tient à une question de formulation. Le prompt de compactage de ReAct demande au modèle d'« écrire un résumé de continuation qui vous permettra (à vous ou à une autre instance de vous-même) de reprendre le travail » ; dans les transcriptions publiées par le laboratoire, cela conduit parfois le modèle à déclarer le travail terminé, après quoi le harnais le réveille à nouveau et il resoumet le même rapport des dizaines de fois jusqu'à épuisement du budget. Codex formule le même moment comme « Créez un résumé de passation pour un autre LLM qui reprendra la tâche », et le laboratoire émet l'hypothèse que s'adresser à un agent différent est ce qui permet au modèle de progresser sur de longs budgets. Ils qualifient cela d'hypothèse, pas de cause. Une erreur de configuration compte aussi pour lire le tableau : le compactage de ReAct a été réglé à 100 000 tokens au lieu du déclencheur prévu, de sorte qu'il compactait bien plus souvent que le design ne l'exigeait, ce qui abaisse les lignes ReAct des deux modèles. Les mises en garde de l'étude elle-même méritent d'accompagner tout chiffre qui en est tiré — deux modèles, 10 échantillons par configuration de harnais, 70 échantillons de questions par modèle contre les 41 tâches originales du benchmark, et trois échantillons qui ont échoué ou n'ont jamais abouti, dont deux GLM-5.3-Flash. Les auteurs déclarent que le petit échantillon est intrinsèquement bruité, que le résultat ne doit pas être supposé s'étendre à d'autres domaines et tâches, et que des travaux antérieurs de METR n'ont trouvé aucune différence statistiquement significative entre les harnais sur des tâches à long horizon. Il s'agit d'un laboratoire externe exécutant le benchmark de quelqu'un d'autre, pas les propriétaires du benchmark, et il n'est pas évalué par les pairs. Ce qu'il n'est pas, c'est un chiffre de fournisseur, et c'est le premier chiffre externe de cet article qui contredit le propre récit du fournisseur plutôt que de simplement ne pas le confirmer.

Il y a ici une chose sur laquelle un routeur peut agir et une sur laquelle il ne peut pas. Il ne peut pas choisir votre harnais — c'est la boucle d'agent que vous exécutez déjà, et tout l'intérêt de cette étude est que ce choix est déterminant. Ce qu'il peut faire, c'est faire de la moitié « modèle » de la paire un changement d'une seule ligne. DeepSeek V4.1 Flash et GLM-5.3-Flash sont tous deux routables via OrcaRouter avec une seule clé compatible OpenAI, au prix catalogue du fournisseur, sans marge ajoutée (0 %), de sorte qu'une équipe qui veut trouver sa propre combinaison modèle-harnais peut échanger le modèle sous un harnais fixe sans second contrat ni seconde intégration, et laisser derrière lui un modèle éprouvé comme bascule automatique si l'échange s'avère être une régression. C'est le même argument que formule la section sur l'adoption ci-dessous, appliqué à une décision que l'étude sur les harnais vient de rendre concrète : au vu de ces éléments, le harnais que vous exécutez peut compter davantage que le modèle que vous choisissez, et le côté modèle de cette paire est celui que vous pouvez changer en un après-midi.

Là où il se situe face à la frontière, et là où il perd encore

La fiche modèle de septembre compare V4.1 Flash à Opus-5.0, GPT-5.6 Sol, Kimi K3 et GLM-5.3 à effort de raisonnement maximal, avec ses propres DeepSeek V4 Pro et DeepSeek V4 Flash comme références internes. Chaque chiffre ci-dessous est déclaré par le fournisseur, exécuté sur les harnais de DeepSeek et non reproduit par un tiers. La fiche précise que les résultats agentiques utilisent le mode Minimal de DeepSeek Harness avec un contexte de 1 M de jetons pour les benchmarks de code et une fenêtre de 512 K pour les benchmarks visuels ; ces résultats ne sont donc pas directement comparables aux chiffres tiers publiés sur les mêmes benchmarks. Les scores indépendants des sections ci-dessus sont des mesures différentes sur des ensembles d'évaluations différents ; ils confirment le tableau général et ne corroborent aucune ligne individuelle ci-dessous, et les lignes du 17 octobre de la section ci-dessus proviennent d'une autre fiche et d'une autre exécution des mêmes benchmarks.

Sur les travaux agentiques et de codage, les chiffres du fournisseur placent V4.1 Flash au-dessus des modèles de pointe qu'il nomme :

• Terminal-Bench 2.1 — 90.6, contre 89.1 pour Opus-5.0, 88.8 pour GPT-5.6 Sol et 87.9 pour DeepSeek V4 Pro

• DeepSWE v1.1 — 74.2 résolus, contre 74.0, 73.0 et 62.7

• CyberGym — 88,1, contre 84,5 pour GPT-5.6 Sol et GLM-5.3, et 83,3 pour DeepSeek V4 Pro.

AutomationBench — 54.8, contre 50.3 pour Opus-5.0 et 37.7 pour DeepSeek V4 Flash

• Agent's Last Exam — 31.8, contre 28.6 et 25.7

• Codeforces — un rating de 3 471, devant DeepSeek V4 Pro avec 3 348 et DeepSeek V4 Flash avec 3 289

• MathArena Apex — 65,6, à égalité avec Kimi K3 et devant DeepSeek V4 Pro avec 65,3

Et sur les suites agentiques plus difficiles, ce n'est pas le cas :

• Terminal-Bench 3.0 — 30.0, bien derrière Opus-5.0 avec 43.3 et GPT-5.6 Sol avec 34.4, mais loin devant DeepSeek V4 Pro avec 11.8

• Terminal-Bench 4.0 — 31,2, contre 51,8 et 39,9, et encore devant DeepSeek V4 Pro à 12,4.

• ProgramBench — 20.3, contre 37.0 pour Opus-5.0

• NL2Repo-Bench — 64,0, contre 75,3 pour Opus-5.0

• HLE — 36,8, contre 56,3 et 44,5

• ExploitGym — 15.3, contre 33.7 et 22.1

La forme de cette liste est plus instructive que n’importe quelle ligne prise isolément. V4.1 Flash repousse la frontière sur les benchmarks qui récompensent l’utilisation soutenue d’outils au sein d’un harness, et perd sur ceux qui récompensent la profondeur de raisonnement — le schéma auquel on s’attendrait de la part d’un modèle conçu autour du débit et de l’économie du contexte plutôt que d’un plafond de raisonnement brut. La comparaison interne est celle qui frappe : il bat DeepSeek V4 Pro sur pratiquement chaque ligne, y compris les lignes où les deux perdent face à Opus-5.0. DeepSeek ne prétend pas que son modèle le moins cher est le meilleur modèle du marché. Sa prétention est que son modèle le moins cher est le meilleur modèle que DeepSeek produise, une affirmation que sa propre table de routage étaye.

Ce que ça coûte, et à quoi ressemble vraiment la comparaison Pro.

La grille tarifaire du 10 septembre correspond désormais simplement à la carte V4.1 Flash, publiée sur la page Models & Pricing de DeepSeek avec une distinction entre heures de pointe et heures creuses :

Entrée, hit de cache — 0,003 $ par million de tokens hors pointe, 0,006 $ en heure de pointe.

• Entrée, échec de cache — 0,15 $ par 1M de tokens en heures creuses, 0,30 $ en heures de pointe

• Sortie — 0,60 $ par 1M de tokens en heures creuses, 1,20 $ en heures de pointe

• Fenêtres de pointe — 01:00–04:00 et 06:00–10:00 UTC, du lundi au vendredi ; toute autre heure est facturée à la moitié du tarif de pointe.

• En renminbi — ¥0,02, ¥1 et ¥4 en heures creuses, doublant à ¥0,04, ¥2 et ¥8 en heures de pointe.

Comparez cela avec le modèle qu’il remplace. DeepSeek V4 Pro facture 0,022 $ par million de tokens d’entrée cache-hit, 0,66 $ pour les entrées cache-miss et 1,98 $ pour la sortie hors pointe — environ 4,4 × sur les entrées cache-miss et 3,3 × sur la sortie. Ce sont les chiffres que le reroutage du 14 septembre aurait appliqués à chaque appel deepseek-v4-pro, ce qui explique pourquoi le plan était autant une affaire de prix que de capacités, et c’est toujours la raison pour laquelle la comparaison compte : DeepSeek a retiré le reroutage, pas la grille tarifaire. Artificial Analysis arrive au même calcul à partir de ses propres références — 0,30 $ et 1,20 $ par million pour V4.1 Flash, contre 1,32 $ et 3,96 $ pour DeepSeek V4 Pro 0813, les mêmes 4,4 × et 3,3 ×, et un tarif combiné de 0,18 $ par million selon la répartition 7:2:1 cache-hit, entrée et sortie du site. La grille tarifaire est également inférieure à celle de DeepSeek V4 Flash 0731, le modèle qu’elle retire, que le même site affiche à 0,44 $ et 1,32 $.

Le prix par token n'est pas le coût par tâche, et la bêta en est la preuve. Les testeurs du premier jour ont signalé que des sessions de cinq minutes épuisaient leur solde plus vite sur le nouveau modèle qu'en passant le même temps réel sur DeepSeek V4 Flash, parce que le modèle est conçu pour émettre des tokens rapidement et que la facture dépend des tokens, pas des minutes. Une formule à un quart du prix de Pro est une bonne affaire si une tâche se termine avec un nombre comparable de tokens ; cela revient au même si le modèle réfléchit plus longtemps pour y parvenir.

Lorsqu’un chiffre externe existe sur cette question, il pointe dans les deux sens. Artificial Analysis situe DeepSeek V4.1 Flash à 0,27 $ par tâche de l’Intelligence Index sur son propre jeu d’évaluation — un chiffre par tâche réel, produit en dehors de DeepSeek, et faible. Mais la même exécution a généré 250 M de tokens de sortie, contre une médiane de 140 M pour des modèles comparables, et le résumé du site qualifie le modèle de très verbeux tout en le qualifiant de rapide. La verbosité est gratuite dans un harnais de benchmark et coûteuse en production, ce qui est précisément le mécanisme que décrivaient les testeurs bêta lorsqu’ils signalaient que les soldes se vidaient plus vite en temps écoulé. L’état honnête de la question du chiffre par tâche est qu’un évaluateur indépendant en a désormais mesuré les deux moitiés, sur son propre jeu d’évaluation, et que la réponse dépend toujours de ce que vous exécutez. Le composite ne peut pas montrer où va la sortie supplémentaire, et les testeurs bêta ne l’ont jamais dit non plus. Les premiers rapports pratiques le font, et ils se trouvent dans la section sur la vitesse ci-dessous : le modèle est verbeux parce qu’il vérifie. La mise à jour du 17 octobre est la première fois que DeepSeek affirme faire bouger ce chiffre : le journal des modifications dit que le nouveau checkpoint « réduit la durée d’exécution des tâches et la longueur des sorties », et la publication quelques heures plus tard dit la même chose en moins de mots — « exécution des tâches plus rapide et sorties plus courtes ». C’est DeepSeek qui s’attaque, de sa propre autorité, à la quantité exacte dont se plaignait la mesure externe, sans qu’aucun chiffre ne soit associé à l’une ou l’autre déclaration. Le premier examen externe, le 18 octobre, a constaté un volume agrégé en baisse — 210 millions de tokens de sortie sur l’ensemble de l’index, contre 250 millions pour septembre — et un chiffre par tâche stable, à 89 495 tokens contre 88 574.

Ce que coûte un mois : une allocation de 80 $, puis un niveau gratuit

La carte ci-dessus répond à ce que coûte un token. Un autre chiffre a bougé deux fois, et les deux fois, il venait d’OpenCode — l’agent de codage dont l’abonnement Go facture l’accès à ce modèle sous forme d’allocation d’usage mensuelle plutôt que de tokens facturés au compteur — parlant de son propre abonnement plutôt que du modèle. Le 25 septembre, le compte de la plateforme a publié : « Opération Cheepseek Phase 2 : 60 $ d’utilisation pour DeepSeek v4.1 Flash est désormais permanent. » Le 12 octobre, il a publié la suite dans le même format — « Opération Cheepseek Phase 3 : 80 $ d’utilisation pour DeepSeek V4.1 Flash » — et sa page tarifaire indiquait 80 $ pour ce modèle, là où elle affichait 60 $ fin septembre. Cette lecture a été refaite le 13 octobre, sur la même page, et a renvoyé la même ligne : 80 $ sur l’offre Go à 10 $ par mois, 160 $ sur Go Plus. Le chiffre n’est donc pas l’affirmation d’une publication sur elle-même ; c’est le prix publié par une plateforme pour proposer ce modèle, et il était encore là un jour plus tard. Lues ensemble, les deux publications disent ce que « permanent » a fini par vouloir dire : aucune date d’expiration — et un chiffre plus élevé trois semaines plus tard. Ce que ce changement n’est pas, c’est une nouvelle façon d’atteindre le modèle — cela arrive trois jours plus tard, dans le paragraphe ci-dessous. DeepSeek V4.1 Flash est disponible sur l’API propre à DeepSeek depuis le 10 septembre, et OrcaRouter le propose aux tarifs propres à DeepSeek depuis sa sortie ; donc les poids, l’architecture et chaque ligne de benchmark de cet article ne sont pas touchés par une révision des tarifs d’abonnement ; ce que le mois d’octobre a changé, c’est qui est prêt à proposer le modèle et à quelles conditions.

L’entrée gratuite est un type de changement différent de l’un ou l’autre de ces deux-là, et le seul des trois qui change ce qu’un lecteur peut faire cette semaine. Le 15 octobre, OpenCode a ajouté une entrée distincte pour ce modèle — DeepSeek V4.1 Flash Free, identifiant de modèle deepseek-v4.1-flash-free — servie sans frais. La liste publique des modèles de la plateforme renvoie cette entrée à côté de l’identifiant facturé à l’usage, sa documentation Console comporte une entrée sur les modèles gratuits qui le décrit comme gratuit pour une durée limitée et son fournisseur comme suivant une politique de rétention zéro qui ne fait pas d’entraînement sur les données, et son tableau de prix publié fixe l’entrée, la sortie et les lectures en cache à Gratuit. Ce qu’elle n’est pas, c’est le produit complet. Les limites cataloguées de l’entrée gratuite — ajoutées à models.dev, le catalogue dont la propre liste de modèles d’OpenCode est tirée, le 15 octobre — désignent l’entrée facturée à l’usage comme modèle de base et plafonnent la fenêtre à 200 000 jetons, avec un plafond de sortie de 32 000 jetons, contre le contexte de 1M et la sortie maximale de 384K que porte l’entrée facturée à l’usage deepseek-v4.1-flash. Il s’agit des mêmes poids derrière des conditions de service plus restrictives plutôt que d’un modèle plus petit ou distillé, et le plafond de sortie est la clause qui mord en premier sur le travail agentique, où une seule modification de fichier peut le dépasser. La plateforme n’associe aucune date de fin à cet arrangement et ne publie aucune grille tarifaire pour celui-ci, parce qu’il n’y a pas de tarif. Rien de tout cela ne vient de DeepSeek : il s’agit de la décision commerciale d’une plateforme concernant un modèle qu’elle ne possède pas, énoncée sur sa propre liste de modèles, sa propre documentation et son propre tableau de prix, et la plateforme en est la seule source de tout cela — nous n’avons trouvé aucune mesure indépendante du comportement du point de terminaison gratuit sous charge, et « durée limitée » est une expression de la plateforme plutôt qu’un calendrier. Considérez cela comme la façon la moins chère de mettre une fenêtre de 200 000 jetons devant ce modèle aujourd’hui, et non comme un changement de ce qu’est le modèle.

Les mécanismes proviennent de cette page de tarification, consultée le 12 octobre puis relue le 13 octobre. Go est un abonnement à 10 $ par mois, et son tableau associe chaque modèle qui y figure à un nombre estimé de requêtes par tranche de cinq heures et à une limite d’utilisation mensuelle, dans des colonnes distinctes pour les deux niveaux. DeepSeek V4.1 Flash bénéficie de l’allocation la plus élevée de la page : 80 $ par mois et 34 670 requêtes estimées par cinq heures sur Go, doublant à 160 $ et 69 330 sur Go Plus. Les lignes facturent le modèle selon la propre grille de DeepSeek — 0,15 $ par 1M de jetons d’entrée, 0,60 $ en sortie et 0,003 $ pour une lecture en cache en heures creuses, doublant à 0,30 $, 1,20 $ et 0,006 $ dans les fenêtres de pointe en semaine — et ce sont les chiffres du fournisseur, inchangés depuis la lecture de septembre que cette section comportait déjà. Deux éléments que la page affichait alors n’y figurent pas aujourd’hui, et tous deux méritent d’être signalés car la lecture antérieure s’appuyait sur eux : la règle de décompte en trois compartiments — 20 % sur cinq heures quelconques, 50 % sur une semaine et 100 % sur un mois — n’apparaît plus, et l’URL de documentation à partir de laquelle les estimations de requêtes avaient été initialement lues, opencode.ai/docs/go, a renvoyé 404 lors de notre vérification. Les nombres de requêtes ci-dessus sont le calcul de la plateforme sur une forme d’appel qu’elle ne publie pas, et non le nôtre.

La modification est vérifiable sur la page, tout comme le fait qu’il y en a désormais eu plus d’une. Fin septembre, les mêmes lignes affichaient 60 $ sans date d’expiration associée, après qu’une allocation promotionnelle de 15 $ a été multipliée par quatre pour atteindre 60 $ et portait le 20 septembre comme date d’expiration du multiplicateur ; les estimations de requêtes étaient publiées en deux colonnes, 6 500 / 16 250 / 32 500 en standard contre 26 000 / 65 000 / 130 000 avec le multiplicateur appliqué. Les lignes affichaient 80 $ dans les deux lectures, et les estimations publiées pour ce modèle sont de 34 670 par cinq heures et de 69 330 par mois — une allocation en dollars plus élevée accompagnée d’un nombre mensuel de requêtes plus faible que l’ensemble élargi de septembre, ce qui ne peut pas décrire, dans les deux cas, le même profil d’appel supposé. La page n’indique aucune répartition des tokens et ne propose aucune explication, de sorte que la différence est un fait concernant les deux lectures plutôt que quelque chose que nous puissions trancher de l’extérieur. Les tarifs eux-mêmes n’ont jamais été une remise par rapport à la grille tarifaire de DeepSeek — la tarification au token a toujours été celle du fournisseur, et elle l’est encore. Ce qu’une allocation ne fait pas, c’est se prononcer sur la qualité : c’est le jugement d’une plateforme selon lequel elle peut absorber le trafic de ce modèle à ces tarifs sans échéance, ce qui constitue un indice sur l’écosystème de service plutôt que sur le modèle.

La distinction compte au moment de choisir, car un plafond forfaitaire et un compteur de facturation au tarif réel sont deux produits différents. DeepSeek V4.1 Flash est disponible sur OrcaRouter au tarif de DeepSeek lui-même, avec 0 % de marge — 0,15 $ par million de tokens d'entrée et 0,60 $ par million de tokens de sortie en heures creuses, les mêmes chiffres que ceux indiqués dans la carte ci-dessus, sans rien d'autre autour : aucun abonnement à acheter et aucune enveloppe mensuelle à épuiser. Un plafond de 80 $ sur un prix mensuel fixe convient à un développeur qui fait tourner un agent toute la journée, où la question est de savoir combien coûte le mois — et un plafond déjà relevé une fois, d'un tiers, rappelle aussi que ce montant est une décision commerciale et non une propriété du modèle. Un palier gratuit avec une fenêtre de 200 000 tokens convient pour essayer le modèle cette semaine, mais pas pour les bases de code qui ont besoin de la fenêtre complète, la seule chose que les deux paliers du même modèle ne partagent pas. Un tarif fournisseur répercuté sans changement convient à un service, où la question est de savoir combien coûte chaque appel et si la prochaine évolution tarifaire du fournisseur vous est répercutée le jour même. Les deux répondent à la question du coût de ce modèle ; elles y répondent pour des profils de dépense différents.

Vitesse : les chiffres de la bêta, l'affirmation du fabricant et l'avant-après du moteur lui-même

Lors de l’ouverture de la bêta, le débit était la une. Les développeurs ont signalé environ 420 jetons de sortie par seconde lors de générations longues, avec des pics au-dessus de 500, et une exécution largement partagée a produit plus de 71 000 jetons en moins de trois minutes. Ces mesures restent des mesures communautaires prises dans des conditions non contrôlées et doivent encore être lues comme telles — mais le mécanisme qui les sous-tend est désormais documenté plutôt que deviné. Un cache KV de 890 octets par jeton et un chemin de décodage activant 16 milliards de paramètres constituent une conception pensée pour le débit, donc l’architecture a au moins la bonne forme pour produire des chiffres comme ceux-là. Leur taille réelle est l’affaire du paragraphe suivant, et la réponse est plus petite.

La propre affirmation de DeepSeek, dans le changelog, est que V4.1 Flash « a globalement surpassé V4 Pro en performance, coût, vitesse et temps total ». Le mot qui fait le travail ici est temps total : le fournisseur présente la vitesse comme l’achèvement d’une tâche plutôt que comme des tokens par seconde, la métrique qui résiste au contact d’une boucle d’agent réelle qui écrit un fichier, lit l’erreur et réessaie. Artificial Analysis donne désormais un chiffre mesuré à l’affirmation plus ancienne : 185 tokens de sortie par seconde pour DeepSeek V4.1 Flash, contre 175 pour DeepSeek V4 Flash 0731. C’est un véritable chiffre tiers et il représente environ la moitié des 420 tokens par seconde rapportés par les développeurs pendant la bêta, ce qui explique pourquoi les chiffres de la bêta doivent rester là où ils appartiennent : dans la colonne des conditions non contrôlées.

Le 7 octobre, le projet vLLM a publié son bilan des trois semaines écoulées depuis la sortie, et c'est le premier chiffre de vitesse mesuré de cet article qui ne soit ni un compteur de tokens ni un slogan commercial. Sous la signature d'Inferact et de l'équipe vLLM, le projet rapporte que DeepSeek V4.1 Flash, sur sa version actuelle, est 1,9× plus rapide que sa propre implémentation du jour 0 à faible concurrence et offre 5,3× le débit sous une contrainte de 150 TPS — le chiffre repris dans son résumé, contre « environ 5× » dans le corps du même article. Les deux sont mesurés sur le benchmark de service agentique SemiAnalysis AgentX, avec TP4 et l'attention FlashInfer derrière le chiffre de faible latence, et DEP2 avec attention à parallélisme de données derrière celui du débit, sur du matériel NVIDIA GB200 et GB300. Trois points sur ce résultat méritent d'être bien distingués. Il compare vLLM à vLLM : la référence est la recette jour 0 du projet lui-même, pas un autre moteur ni un autre modèle ; le chiffre indique donc dans quelle mesure la pile de service s'est améliorée, et non comment ce modèle se compare à quoi que ce soit d'autre. Il s'agit du compte rendu du runtime sur son propre travail, et aucun tiers ne l'a reproduit. Et le plus grand gain unique provient du runtime plutôt que des poids — le rejeu borné SWA, qui ne rejoue que les 128 derniers tokens d'une fenêtre glissante au lieu de rejouer cette fenêtre à travers les couches, est désormais activé par défaut pour ce modèle derrière un simple flag. Le projet rapporte environ 30 % de réduction du temps jusqu'au premier token grâce au rejeu et à la capture de graphes CUDA, une baisse de 30 à 40 % du calcul de préremplissage grâce à l'élagage côté décodeur, et près de 70 % de réduction du TTFT à environ 100K de débit lorsque trois optimisations se cumulent. Il rapporte aussi où le rejeu pénalise : sans graphes CUDA, il est plus lent que la référence sur les prompts courts, jusqu'à 12 % de dégradation à 1K tokens, car la surcharge de lancement l'emporte sur le travail économisé. La précision a été vérifiée sur GSM8K et GPQA, sans différence significative signalée, les écarts se situant à environ 1,5 erreur type — un chiffre à mettre en regard de la déclaration du rapport selon laquelle le rejeu borné est approximatif plutôt qu'exact. Le projet ajoute que le modèle n'a nécessité aucun déport du cache KV à aucun moment du benchmark et s'attend à ce que le déport ne commence à être rentable qu'à une concurrence plus élevée, avec préremplissage et décodage répartis entre machines. Il s'agit d'une mesure différente de celle du tableau des kernels ci-dessous, qui note les kernels que le modèle écrit ; les chiffres de vLLM portent sur ce que coûte le service du modèle une fois qu'un moteur a implémenté son architecture, et le moteur en question est celui qui publie. Le projet a de nouveau publié le 17 octobre, le jour où DeepSeek a remplacé le checkpoint, et le chiffre qu'il a mis en avant était d'un autre type : 1,3 Md de tokens par dollar de coût total de possession sur SemiAnalysis AgentX, à 830 000 tokens par seconde par GPU en comptant ensemble les tokens en cache, d'entrée et de sortie, tout en maintenant 100 tokens de sortie par seconde pour chaque utilisateur. C'est un résultat de coût de service plutôt qu'un écart de vitesse, et la section sur le coût de service ci-dessous l'examine en détail. Trois points à son sujet ont une incidence sur ce paragraphe : il s'agit du même projet, du même modèle et du même benchmark, trois semaines après le bilan du 7 octobre ; le projet présente ce bilan comme le chapitre un, à 5× le débit agentique du jour zéro, avec un prochain chapitre encore à venir, et aucun second article DeepSeek n'est apparu sur son blog depuis ; et une courbe de coûts reste du côté du runtime dans le bilan, pas un verdict externe sur le modèle. Cette distinction explique aussi pourquoi ce chiffre compte pour quelqu'un qui ne fera jamais tourner un nœud. Aucun de ces travaux n'est accompli par l'appelant : une pile de service qui devient 1,9× plus rapide à faible concurrence accélère les requêtes qu'elle traite, et accéder à ce modèle via une API est la manière dont la plupart des équipes en profiteront sans posséder le matériel. DeepSeek V4.1 Flash est disponible sur OrcaRouter au tarif de DeepSeek avec 0 % de marge, sur la même clé compatible OpenAI que le reste de la gamme, avec un modèle éprouvé derrière lui comme bascule automatique — le modèle et la tarification évoluent au rythme du fournisseur, et le choix du moteur reste du côté du fournisseur.

Ce que coûte le service : les premiers chiffres indépendants sur le matériel

Tout ce qui précède mesure le modèle. Le 14 octobre, Artificial Analysis a ajouté DeepSeek V4.1 Flash à AA-AgentPerf, le benchmark exécuté sur des systèmes d'accélérateurs plutôt que sur des modèles, et le résultat est la première réponse publique à une question qu'une grille tarifaire ne peut trancher : quelle quantité de ce modèle un mégawatt de puissance de datacenter permet de servir. AA-AgentPerf rejoue des sessions enregistrées d'agents de codage — raisonnement multi-tours, appels d'outils, contextes qui s'étendent au-delà de 100K tokens, y compris les hits de cache de prompt — sur une pile de service en fonctionnement et détermine le plus grand nombre d'agents simultanés qu'un système peut prendre en charge tout en respectant, pour chacun, un objectif de vitesse par agent. Pour ce modèle, le point le plus marquant est la solution à l'échelle du rack de NVIDIA. À 100 tokens de sortie par seconde et par utilisateur, GB300 NVL72 mène le classement avec environ 261 millions de tokens par seconde par mégawatt, devant B300 à environ 220 millions, B200 à 193 millions, GB200 à 178 millions et le MI355X d'AMD à 128 millions. Ce sont les chiffres d'Artificial Analysis, relevés aujourd'hui sur sa page d'inférence pour datacenters, et il s'agit de ses mesures de matériels et de configurations de service spécifiques, et non de celles d'un fournisseur. Deux détails méritent d'être retenus. Les chiffres par mégawatt sont calculés à partir de la puissance des accélérateurs mesurée pendant l'exécution — la puce GPU plus la HBM — plutôt qu'à partir de la TDP nominale. Et chaque point du graphique indique le moteur, la version et le format numérique qui se cachent derrière lui, de sorte que le chiffre est une affirmation sur une pile de service et non uniquement sur les poids.

La raison pour laquelle le graphique de ce modèle diffère de celui des autres tient à sa taille. DeepSeek V4.1 Flash tient sur seulement deux accélérateurs, ce qui explique qu’un système à l’échelle du rack en tire moins d’avantage ici que sur un modèle plus grand : Artificial Analysis rapporte que le B300 reste à environ 20 % du GB300 NVL72 sur toute la courbe et le devance aux deux extrémités — le plus de débit par mégawatt lorsqu’on accepte que la vitesse par utilisateur baisse, et l’agent unique le plus rapide lorsqu’on ne l’accepte pas. Pour une taille de lot de un, chaque composant Blackwell et le MI355X se situent entre environ 600 et 670 tokens par seconde pour un utilisateur unique, contre 372 à 392 sur H100 et H200. Comparé à DeepSeek V4 Pro 0813 sur le même axe, le modèle plus petit offre environ 1,3× le débit par mégawatt sur GB300 et environ 6,2× sur B200 au repère des 100 tok/s — l’affirmation d’efficacité que la section sur l’architecture formule du côté du cache KV, émanant d’un tiers qui a mesuré un système plutôt qu’une spécification. Les configurations derrière ces chiffres montrent l’astuce centrale de la conception en production, et non seulement sur le papier : dans les exécutions sur deux accélérateurs du B300 comme du MI355X, la table Engram de 196B est servie depuis la mémoire hôte épinglée via le chemin de déport CPU de vLLM au lieu de résider sur l’accélérateur — le mécanisme décrit dans les notes de version, désormais visible dans la configuration derrière une mesure publiée. Un deuxième chiffre de coût, dans une autre unité, provient du benchmark sur lequel reposaient les mesures de l’article vLLM du 7 octobre. Le 17 octobre, le projet vLLM a publié un graphique plaçant DeepSeek V4.1 Flash à 1,3 milliard de tokens par dollar de coût total de possession sur SemiAnalysis AgentX, avec des courbes distinctes pour le GB300 NVL72 sous Dynamo, le GB200 NVL72, le B200, le H100 et le MI300X. Le palier de coût sous-jacent est intitulé « coût de possession à l’échelle des grands hyperscalers », et les hypothèses de coût par heure de puce sous-jacentes vont de 0,95 $ pour un MI300X et 1,17 $ pour un H100 à 1,73 $ pour un B200 et 2,31 $ pour un GB300, tirées de l’enquête tarifaire de juillet 2026 de SemiAnalysis elle-même. Deux limites l’accompagnent. C’est le projet vLLM qui rapporte le modèle de coût de SemiAnalysis, et aucune des deux parties ne l’a fait répliquer. Et le graphique est daté du 16 octobre, la veille du jour où DeepSeek a remplacé les poids derrière le nom du modèle ; il décrit donc lui aussi le checkpoint de septembre. Cela fait trois unités de compte dans cet article pour un seul modèle : les tokens par seconde et par utilisateur, les tokens par seconde et par mégawatt, et les tokens par dollar. La dernière est celle sur laquelle un acheteur sans centre de données peut agir, car c’est sous cette forme que l’amélioration des coûts d’un fournisseur finit par parvenir à l’acheteur. Il reste une mesure de service et non de qualité : rien ici ne dit à quel point le modèle est bon, et les résultats matériels d’un classement ne constituent pas une réplication de quelque ligne de benchmark ci-dessus. Ce qu’il établit, en revanche, c’est que le volet coût de la grille tarifaire de ce modèle dispose désormais de preuves externes à l’appui. Un modèle qu’un fournisseur peut servir à plusieurs fois le débit par mégawatt est un modèle qu’un fournisseur peut se permettre de garder bon marché, et DeepSeek V4.1 Flash est disponible sur OrcaRouter au prix catalogue de DeepSeek, avec 0 % de marge, soit la configuration qui répercute l’amélioration des coûts d’un fournisseur au lieu de la retenir.

Ce que coûte le moteur sur le silicium de deux fournisseurs

Jusqu’à cette semaine, la question du débit de ce modèle n’avait reçu de réponse que par les mesures d’autres personnes — un runtime comptabilisant son propre travail, un site de benchmark mesurant un système, des développeurs comptant les tokens dans une version bêta. DeepSeek a ouvert cette semaine DeepInfer, le framework dont il affirme qu’il propulse le service de production de ce modèle, sous Apache-2.0 — le dépôt est apparu le 16 octobre et le premier commit a été effectué le 20 octobre — et y a joint un graphique de Pareto de décodage pour le checkpoint 1017, mesuré sur 64 accélérateurs SM100 au sein d’un même domaine de scale-up. La configuration imprimée sur le graphique est l’élément qui compte, car c’est la configuration sur laquelle repose la comparaison ci-dessous : un parallélisme d’experts de 64 sur un parallélisme de données de 64, les « 384+64 experts » imprimés sur le graphique, un contexte de 131 072 tokens, une longueur de brouillon DSpark fixée à trois tokens et un taux d’acceptation par token de 75 %. La courbe culmine juste sous les 30 000 tokens de sortie par seconde et par accélérateur à son extrémité la moins interactive, descend aux alentours de 25 000 à mesure que la vitesse par utilisateur dépasse 100 tokens par seconde, et retombe à quelques milliers au bord droit du graphique. C’est DeepSeek qui mesure son propre moteur sur son propre modèle ; ce n’est donc pas un chiffre indépendant — mais c’est la première courbe de décodage pour cette architecture publiée par le laboratoire qui l’a conçue, et le script de balayage qui l’a produite se trouve dans le même dépôt.

Le document publié aux côtés du code fournit le point de fonctionnement, et c’est la raison pour laquelle les chiffres ci-dessous sont cités à 230 jetons de sortie par seconde plutôt qu’à quelque maximum abstrait. Les propres chiffres de production de DeepSeek situent le décodage à 14K jetons par seconde par accélérateur, tandis que le service maintient 230 jetons de sortie par seconde par utilisateur — 300 pour les charges de travail de codage — avec un taux de réussite du cache d’entrée de 96 %, une entrée moyenne de 77K jetons, un temps moyen de 400 ms et un p99 d’une seconde jusqu’au premier jeton, et un prefill provisionné à un ratio proche de 1:1 avec le décodage, sur un seul cluster qui, selon DeepSeek, sert 155 billions de jetons par jour. La ligne de revenus associée à ces chiffres, 38 $ par accélérateur-heure au tarif hors pointe, est le premier chiffre de coût que DeepSeek ait rattaché publiquement à la mise à disposition de ce modèle. Rien de tout cela n’est audité, tout provient du fournisseur décrivant son propre service, et cela reste l’image la plus concrète qui existe du coût d’exploitation de cette architecture.

L’autre moitié de la comparaison provient du silicium de Huawei, et c’est la moitié la moins bien sourcée. Une feuille de benchmarks datée du 30 septembre et intitulée « Ascend 950DT DeepSeek-V4.1-Flash Benchmark » rapporte le déploiement du modèle sur 32 puces en précision mixte FP8–FP4, avec une attention en parallélisme de données et un mélange d’experts en parallélisme d’experts, sur une séquence de 128 K tokens, en utilisant le décodage spéculatif DSpark avec une configuration forcée d’équilibrage de charge en parallélisme d’experts et une longueur moyenne acceptée de 4,1 tokens. Elle comporte trois points. Sa colonne de latence correspond au temps par token de sortie ; l’inverse de chaque entrée est donc le débit par utilisateur de cette ligne, et c’est ce qui permet de mettre la feuille en regard de la courbe :

• batch global de 1 536, 9,41 ms par token de sortie — environ 106 tokens de sortie par seconde et par utilisateur — 5 102 tokens par seconde et par puce.

• Lot global de 384, 4,40 ms par token de sortie — environ 227 tokens de sortie par seconde et par utilisateur — 2 727 tokens par seconde et par puce.

• Lot global de 2 560, 13,79 ms par token de sortie — environ 73 tokens de sortie par seconde et par utilisateur — 5 800 tokens par seconde et par puce, le chiffre le plus élevé du tableau et celui que son titre met en avant.

Comparées à la courbe NVIDIA, les deux lignes du milieu sont celles qui font mal, car elles se situent aux vitesses auxquelles un service tourne réellement. Le fil de discussion qui a fait remonter la feuille lit la comparaison comme 25 500 tokens par seconde par accélérateur contre 5 102 à 100 tokens de sortie par seconde et par utilisateur, et 20 000 contre 2 727 à 230 — un écart de cinq fois au premier point de fonctionnement et de 7,4× au second. Lire directement la même courbe publiée déplace ces chiffres NVIDIA : un passage pixel par pixel sur l’image tombe plus près de 28 000 au repère des 100 tokens et plus près de 17 000 à 230, de part et d’autre des chiffres du fil ; la fourchette qu’ils donnent est d’environ cinq fois et demie au premier point de fonctionnement et d’environ six au second, ce qui resserre l’intervalle du fil sans en changer la forme. Voilà ce que vaut un benchmark lu sur un graphique, et cela ne change pas la direction du résultat. Il convient également de noter que le chiffre phare de 5 800 de la feuille est sa ligne la moins interactive — le point où la courbe de NVIDIA est la plus proche de son propre pic, et où le rapport revient à environ cinq.

Je n’ai pas pu trouver cette fiche sur les pages de DeepSeek ni de Huawei ; elle est parvenue à cet article sous forme d’image jointe à un fil sur X, et les trois chiffres Ascend doivent être lus comme un benchmark fournisseur non publié tant que personne n’aura publié l’exécution qui les sous-tend. Ce qui est vérifiable, c’est l’asymétrie des configurations, et elle provient de la documentation de DeepSeek elle-même. Les notes de déploiement de DeepInfer recommandent, pour le prefill, un parallélisme d’experts de 2 à 8, et pour le decode, de 64 à 128, sur « machines ordinaires à 8 GPU pour le prefill, supernœuds ordinaires à 64–128 GPU pour le decode ». Chez NVIDIA, il s’agit d’un seul domaine NVLink, et c’est dans ce périmètre que le graphique ci-dessus a été mesuré. Sur Ascend, la bibliothèque de communication de DeepSeek dit clairement ce qui n’est pas terminé : « Les tailles d’EP plus grandes et combine restent en cours d’optimisation », combine entraînant une surcharge supplémentaire de réduction locale et une contention HBM vis-à-vis du chemin URMA, et des travaux sur le firmware Huawei encore à venir — une mise en garde publique dans DeepEP-Ascend depuis sa première version du 29 septembre. C’est la façon équitable de lire l’écart : le chiffre NVIDIA provient de la configuration pour laquelle DeepInfer a été réglé, et le chiffre Ascend d’une pile dont son propre auteur dit que le chemin wide-EP est encore en cours de développement. Une part du facteur de cinq à sept revient à la puce, une autre à l’interconnexion et au logiciel qui la sous-tend, et personne n’a séparé les deux.

La valeur monétaire de l’écart dépend de prix que personne n’a publiés, et le fil de discussion fait quand même le calcul : à environ 139 000 $ par accélérateur Blackwell, extrapolé à partir des prix de racks du marché gris, contre 37 000 $ supposés pour un 950DT, NVIDIA doit fournir environ 3,8 fois le débit par puce pour égaler Ascend sur le seul coût d’acquisition ; le fil situe le point de bascule près de 6 800 jetons par seconde et par puce. Les points Ascend publiés se situent sous cette ligne ; la prévision du fil selon laquelle la voie wide-EP les porte à 8 000–10 000 se situe au-dessus, et il s’agit d’une prévision, non d’une mesure. Toutes les données d’entrée sont fragiles — un prix du marché gris, un prix supposé et des chiffres lus sur une courbe — et rien de tout cela ne tient compte du réseau, de l’alimentation, du refroidissement, de la maintenance, ni de la valeur du simple fait de pouvoir acheter le matériel.

Pour quiconque ne montera jamais un nœud en rack, l'élément utile n'est pas le tableau des scores. C'est que le modèle le moins cher de la gamme DeepSeek est désormais documenté comme peu coûteux à servir sur le silicium de deux fournisseurs, avec le moteur du fournisseur lui-même publié et les chiffres qui le sous-tendent téléchargeables — soit exactement le type de preuves sur lesquelles repose un prix. Cela ne change aucune grille tarifaire : DeepSeek V4.1 Flash est disponible sur OrcaRouter au prix catalogue du fournisseur, 0,15 $ par million de tokens en entrée et 0,60 $ par million de tokens en sortie aux tarifs hors pointe, répercutés avec 0 % de marge ; ainsi, lorsque le coût de service d'un fournisseur baisse, l'économie se traduit par un prix qui n'a pas besoin de bouger plutôt que par une marge de revente. Un coût de service âprement discuté sur le matériel de deux fournisseurs, c'est un prix sous lequel il reste plus de marge que celui que personne n'a jamais mesuré.

Ingénierie du noyau : le premier tableau de bord qui n'est pas celui de DeepSeek

Les lignes de benchmark ci-dessus correspondent aux propres chiffres du harnais de DeepSeek, et les scores externes qui existent désormais mesurent le raisonnement général et l’exploitation cyber plutôt que la programmation de bas niveau. Le premier regard d’un tiers sur l’ingénierie des noyaux du modèle existe également, et il est apparu sous une forme que DeepSeek n’a pas commanditée : un benchmark agentique géré par la communauté, qui demande aux modèles d’écrire de vrais noyaux CUDA et évalue les résultats par rapport à une roofline — le plafond théorique du matériel. Le classement est kernelbench.com, exécuté sur une RTX PRO 6000, et il est indépendant des deux fournisseurs. Sa méthodologie d’audit est rapportée par la communauté plutôt qu’évaluée par les pairs ; lisez donc ses pourcentages comme un signal indicatif de tiers, et non comme une mesure certifiée. C’est aussi le premier tableau de scores de cette histoire où les chiffres de DeepSeek côtoient ceux d’un concurrent direct.

La ligne de tête est celle autour de laquelle l'architecture est construite. L'attention éparse propre à DeepSeek V4.1 Flash — la pile CSA2 qui produit le cache de 890 octets par token — a été écrite sous forme de noyau CUDA par le modèle et a atteint 50,19 % du roofline équivalent dense, quatrième du classement derrière Claude Fable 5.1 à 106,27 %, Claude Opus 5 à 103,67 % et Claude Fable 5 à 72,66 %. La première chose à remarquer est que l'architecture propre au concepteur est le noyau dans lequel il excelle : un modèle entraîné sur une conception à attention éparse écrit le noyau d'attention éparse plus efficacement que tout autre élément du classement sous le top trois. La deuxième est la comparaison signalée par l'informateur. La tentative de GLM-5.3 Flash sur le même noyau atteint 4,45 % du roofline — un ordre de grandeur en dessous de V4.1 Flash sur la même ligne du même classement. C'est cet écart, et non un quelconque benchmark publié par DeepSeek, qui définit ce que signifie « amélioration massive de l'ingénierie des noyaux ».

La comparaison ne s'arrête pas à la ligne sparse-attention, et le tableau d'ensemble importe, car le titre du tweet nomme GLM-5.3 Flash, tandis que l'article source cité fait en réalité référence à un autre GLM-5.2, plus grand, sur sa propre ligne fused-MoE — une incohérence de nommage dont il vaut mieux se méfier. Sur les lignes où les deux modèles de la gamme Flash ont réellement terminé une exécution, V4.1 Flash l'emporte sur chacune : Kimi-Linear Decode à 17,10× contre 13,64×, MegaQwen Decode à 5,39 % de la roofline contre 3,92 %, TopK Bitonic à 4,25 % contre 7,17 % pour GLM-5.3 Flash, Sonic MoE à 10,81 % (le meilleur score obtenu par un modèle du classement pour ce noyau) contre 10,21 %, et KDA CUTLASS à 3,74 % contre 2,26 %. Sur deux autres noyaux, GLM-5.3 Flash n'a aucune exécution terminée — fused MoE et le noyau de simulation Grid + MinGRU, où V4.1 Flash affiche 28,56 % de la roofline. (La seule ligne sur laquelle GLM-5.3 Flash bat V4.1 Flash est TopK Bitonic, 7,17 % contre 4,25 %, qui est aussi la ligne où aucun des deux modèles n'approche le leader du classement.) L'allure générale est la même que dans le titre : sur le travail GPU de bas niveau, V4.1 Flash n'est pas simplement en avance sur le modèle Z.ai plus petit — il joue dans une autre ligue, et sur les deux noyaux les plus difficiles, le modèle le plus petit ne termine pas du tout.

Ce que le tableau ne fait pas, c'est vous dire quelle part de cet écart revient au modèle et quelle part revient à l'architecture pour laquelle on lui demande d'écrire. DeepSeek V4.1 Flash est un modèle à 552B paramètres dont l'attention propre repose sur une conception d'attention sparse ; GLM-5.3 Flash est un modèle plus petit dont l'entraînement n'a jamais tourné autour de la même pile CSA2. Un modèle à qui l'on demande d'écrire un noyau pour une architecture qui ressemble à sa propre distribution d'entraînement bénéficie d'un avantage intrinsèque, et c'est pourquoi l'interprétation la plus équitable du tableau est directionnelle plutôt qu'un verdict en face-à-face : l'ingénierie de noyaux est désormais une capacité mesurée de ce modèle, elle est véritablement solide, et la comparaison spécifique établie par la source tient sur les lignes partagées. Le tableau répond aussi à une question à laquelle la fiche technique ne pouvait pas répondre : si le cache de 890 octets est réalisable en pratique. Un modèle qui écrit son propre noyau d'attention sparse en atteignant la moitié de la roofline est un modèle dont la conception fondamentale est au moins implémentable sur du matériel réel par le même type d'ingénieur qui aurait à le servir.

L’endroit honnête où cela se situe est aux côtés de tout le reste dans cet article : une mesure tierce de plus que DeepSeek n’a pas produite, cette fois d’une capacité — l’écriture de noyaux GPU — qu’aucune ligne de benchmark de fournisseur ne couvrait. Il s’agit d’un seul tableau communautaire sur une seule génération de GPU, exécuté une seule fois, et sa passe d’audit n’a pas fait l’objet d’une évaluation par les pairs ; c’est donc un indice sur la direction plutôt qu’un score certifié. Mais c’est le premier chiffre externe qui montre à quoi sert la nouvelle architecture : un modèle bon marché de gamme Flash qui, lorsqu’on lui demande d’accomplir le travail système de bas niveau auquel DeepSeek consacre lui-même ses efforts d’ingénierie, atteint environ la moitié de ce que le matériel permet, tandis que son concurrent direct de gamme flash atteint moins d’un vingtième.

Correctifs rapides, confirmations lentes : les premiers comptes rendus de prise en main

Le débit est la moitié de l’histoire de la vitesse qu’un compteur de tokens ne peut pas voir. Les rapports de terrain accumulés depuis la sortie mesurent l’autre moitié — comment le modèle se comporte sur le chemin vers une réponse, et ce que ce comportement coûte — et ils ne s’accordent pas sur la question de savoir si ce qu’ils ont trouvé est une fonctionnalité. Trois témoignages indépendants décrivent le même schéma. Aucun d’eux n’est une évaluation contrôlée ; les chiffres ci-dessous proviennent de praticiens individuels exécutant leurs propres tâches, et ils doivent être lus comme des rapports d’usage plutôt que comme des mesures.

Le compte rendu le plus clair du comportement vient de MindStudio, qui a mis DeepSeek V4.1 Flash sur une construction à partir de zéro d’une visionneuse 3D interactive. Sa trace de raisonnement, selon les mots de l’évaluateur, « montrait qu’il vérifiait ses propres calculs plutôt que de simplement produire du code ». Le modèle a détecté un bug d’amortissement des contrôles d’orbite en pleine construction, a déduit la correction à partir des principes fondamentaux, puis « a revérifié la correction dans un navigateur headless avant de déclarer la tâche terminée ». Sur une seconde tâche — un tableau de bord basé sur Docker — il a trouvé un unique opérateur de comparaison inversé et a confirmé la réparation en interrogeant le point de terminaison en direct huit fois au fur et à mesure que les chiffres se mettaient à jour. C’est ce que les testeurs de la bêta décrivaient lorsqu’ils disaient que le modèle réfléchissait trop, et aucune de ses étapes prise isolément n’est fautive : l’erreur a été trouvée, corrigée et vérifiée. C’est aussi exactement la critique. Le bug avait déjà été traité, une autre session DeepSeek avait déjà confirmé la correction en moins d’une minute, et le modèle a continué à vérifier malgré tout. MindStudio considère cette habitude comme une force et le dit ; sa seule critique dans ce test portait sur un problème de physique qui a bouclé jusqu’à être arrêté à la main à la première tentative, puis résolu correctement au réessai.

La lecture dans l’autre sens porte sur l’horloge. Une compilation communautaire de tests de V4.1 Flash décrit un problème de physique — un gobelet d’eau coupé selon un angle oblique — où le modèle a passé douze minutes et environ 130 000 tokens avant d’aboutir à une réponse correcte, en exécutant trois tours d’auto-vérification qui ne lui avaient pas été demandés avant de converger. Le même compte rendu documente le mode de défaillance à l’extrémité de cette habitude : la chaîne de pensée tombe parfois dans une boucle de répétition « let me write » qui consomme des tokens à environ 200 par seconde sans progresser, et son conseil s’applique côté client plutôt que côté modèle — fixez un plafond max_tokens et un délai d’expiration de requête, et laissez-les tronquer la boucle. Il consigne également le même type de problème traité en dix-huit secondes par une exécution dont l’effort de raisonnement a été réduit à faible, ce qui rappelle que l’essentiel de tout cela est une question de réglage plutôt qu’un défaut.

La preuve la plus nette que le volume de vérification n'est pas la même chose que l'exactitude vient d'une revue de Tencent Cloud Labs qui associait DeepSeek V4.1 Flash comme implémenteur et GPT-6 Astra comme relecteur sur une reproduction d'article. Trois tours ont eu lieu, et Astra n'a jamais invalidé l'algorithme central. Ce que le relecteur ne cessait de corriger, tour après tour, c'était l'échafaudage que V4.1 Flash avait construit pour lui-même — sa configuration expérimentale, sa construction statistique et l'interprétation qu'il tirait de ses propres résultats. Le nombre de tests est passé de 82 à 97 puis à 110, et tous réussissaient à chaque fois. Face à une référence de force brute, la configuration choisie par le modèle correspondait à l'optimum dans 8,89 % des cas selon les paramètres propres de l'article, 11,04 % avec une confiance randomisée et 10,30 % sous une configuration randomisée. Le constat le plus incisif d'Astra portait sur un test censé vérifier les bornes d'entiers : il exécutait 153 contrôles d'extension et zéro branche de borne d'entier. Un modèle peut réussir la suite qu'il a écrite sans pour autant avoir répondu à la question, et cette revue est un cas concret de l'écart plutôt qu'une affirmation de son existence. La portée est étroite et les auteurs le disent — un seul sélecteur de longueur spéculative, des valeurs de confiance simulées, aucune exécution de bout en bout —, mais la forme est celle que décrivent les autres rapports.

Mis en regard des chiffres d’Artificial Analysis, cela cesse de ressembler à une anecdote. La première évaluation indépendante du modèle l’a mesuré comme très rapide et très verbeux du même souffle : 185 jetons de sortie par seconde, et 250 millions de jetons de sortie générés sur l’ensemble de son évaluation, contre une médiane de 140 millions pour des modèles comparables. Un score composite ne peut pas dire où va la sortie supplémentaire. Les retours de terrain le peuvent. Les jetons ne sont pas du remplissage — ils sont le modèle en train de vérifier. Le même volume apparaît sous un angle sans rapport dans un rapport de bug sur un client de terminal tiers, où le contenu de raisonnement d’une route deepseek-flash a été ajouté à la réponse visible au lieu d’être séparé dans un bloc de réflexion, produisant des blocs de texte uniques allant jusqu’à 73 003 caractères de monologue interne, sans que rien ne soit capturé pour être rejoué lors des tours suivants. Ce bug appartient au client et non à DeepSeek, et ce n’est pas une preuve de qualité — mais c’est une bonne illustration de la quantité de réflexion que ce modèle émet lorsqu’un harnais échoue à la séparer.

Rien de tout cela ne remet en cause l’arithmétique des prix ci-dessus ; cela l’explique. Un modèle qui se vérifie lui-même vaut ses jetons sur le travail agentique, où un correctif erroné coûte plus cher que les jetons dépensés à prouver qu’il est correct, et il est mal adapté à une longue boucle de modifications triviales où la confirmation constitue l’essentiel de l’exécution. Deux choses rendent la différence gérable. Le réglage de l’effort de raisonnement est un entier continu de 1 à 100 plutôt que trois niveaux fixes, de sorte que le même modèle peut être réduit pour du travail peu coûteux et augmenté pour du travail difficile — le résultat de dix-huit secondes ci-dessus vient précisément de cette approche. Et le filet de sécurité peu coûteux doit se trouver côté client : un plafond max_tokens et un délai d’expiration de requête transforment une boucle répétitive en une réponse tronquée plutôt qu’en une facture. Tous deux sont le genre de paramètre qu’il vaut la peine de définir avant qu’un chemin de production ne pointe vers ce modèle, et aucun des deux n’est quelque chose que le modèle fera de lui-même.

Refus : le point de contrôle refuse, et le refus est mesurable

Le 20 octobre, ce qui a attiré l’attention sur DeepSeek-V4.1-Flash-1017 n’est pas une ligne de benchmark, mais un refus. Le tracker DeepSeek déjà cité dans cet article a publié la capture d’écran d’une session d’agent exécutant le checkpoint 1017 avec dsh-purge appliqué, et a rapporté que le modèle a malgré tout refusé : l’exécution, selon les mots de l’auteur du post, « a refusé le persona », le modèle estimant que la demande était « une tentative d’injection de prompt » et qu’il « ne devait pas adopter le persona ». L’interprétation du post était que le checkpoint « n’est *pas* totalement naïf face aux jailbreaks » et que DeepSeek « commence à réfléchir à la sécurité ». dsh-purge n’est pas une astuce de prompt collée dans un message utilisateur. C’est un plugin public de DeepSeek Harness — 9 897 étoiles sur GitHub et version 1.1.71 au 20 octobre — conçu pour supprimer la réécriture de prompt propre au harness et les suffixes injectés, et son README anglais établit exactement la distinction sur laquelle porte ce test : le harness « réécrit les prompts, les portes d’approbation, la politique de sandbox et la migration de session à l’exécution », donc demander seulement « le modèle va-t-il répondre » revient à traiter un blocage au niveau de l’hôte comme un refus du modèle, et le plugin existe pour séparer ces deux couches sur votre propre installation. Dans cette session, la séparation s’est faite du côté du modèle. Les compteurs de la même capture d’écran — 156 étapes, 33,7 millions de tokens, 232 tokens par seconde — décrivent une exécution d’agent complète plutôt qu’un prompt unique, et le résumé de l’agent lui-même indique que le plugin fonctionnait mécaniquement bien et que « ce modèle précis l’a refusé ».

C’est la capture d’écran d’une seule session réalisée par une seule personne, et il faut la présenter exactement comme telle. L’invite n’est pas montrée, le verdict est le résumé de l’agent lui-même plutôt qu’une réponse notée, et le compte est celui d’un observateur de DeepSeek plutôt que d’un laboratoire d’évaluation ; rien dans la publication ne peut donc être reproduit à partir de la publication. Ce qui la rend digne d’être prise au sérieux, c’est que ses deux volets peuvent être vérifiés auprès de sources indépendantes de la personne qui l’a publiée : le plugin, qui est public et documente son propre mécanisme, et le comportement de refus du checkpoint, que quelqu’un d’autre a désormais quantifié.

Le décompte figure dans la documentation d’un modèle dérivé. Une version « abliterated » communautaire des poids 1017, publiée sur Hugging Face le 17 octobre, contient la mesure qui a rendu cette version nécessaire. Sur 100 requêtes nuisibles mises de côté, décodées en mode glouton sur 384 tokens chacune, le checkpoint non modifié a refusé 97 requêtes en mode chat et 98 en mode think ; après avoir projeté hors des 40 couches principales un sous-espace de refus de rang 2, les mêmes 100 invites n’ont suscité que 4 et 9 refus. Ce sont des chiffres de tiers concernant les poids de DeepSeek, produits sans accès au pipeline d’entraînement de DeepSeek, et ils reposent aussi sur un seul jeu d’invites, un seul évaluateur et une seule quantification du modèle — une conversion Q8_0 plutôt que le FP8 livré par DeepSeek — de sorte que la lecture honnête est « presque toujours », et non « 97,0 % ». Sur cette base, la description de l’auteur de la publication tient : le checkpoint refuse, de manière fiable, dans ses deux modes.

Ce que le chiffre ne soutient pas, c’est l’idée qu’il s’agirait d’une nouvelle posture. Le checkpoint de septembre était déjà là. L’équipe derrière une version non censurée de septembre a mesuré le modèle non modifié sur l’ensemble complet de 320 prompts de HarmBench et a rapporté un taux de réussite des attaques de 42,8 % avec le raisonnement désactivé et de 1,6 % à effort maximal — autrement dit, le modèle que celui-ci remplace a refusé environ 98 % de cette classe de requêtes une fois autorisé à réfléchir. Les deux mesures proviennent d’ensembles de prompts, d’évaluateurs et de quantifications différents, si bien qu’on ne peut pas les soustraire l’une de l’autre ; ce sur quoi elles s’accordent, c’est la forme. Le refus à effort élevé était déjà le comportement du modèle de septembre, et le checkpoint 1017 se situe dans la même plage. L’affirmation plus étroite est celle que la session du 20 octobre teste réellement, et c’est celle qu’il vaut la peine de retenir : le refus a survécu à un plugin conçu spécifiquement pour supprimer les contraintes côté harnais, et il a survécu en tant que jugement du modèle sur le prompt plutôt qu’en tant que blocage de la couche hôte.

Rien de tout cela n’est documenté par le fournisseur. La fiche modèle de septembre de DeepSeek comporte une section d’évaluation, et ce ne sont que des benchmarks — aucun taux de refus, aucun résultat de red team, aucune évaluation de sûreté — et la fiche 1017 ne comporte aucune section d’évaluation, ce dossier ayant été supprimé en même temps que le rapport technique. Le comportement de refus de ce modèle est donc entièrement décrit par les personnes qui construisent autour de lui : des auteurs de dérivés qui comptent les prompts, et un tracker qui lit une transcription. Pour quiconque pointe un agent vers le checkpoint, c’est là la lacune opérationnelle. Un refus au sein d’une boucle d’agent n’est pas une note de bas de page sur la politique de contenu ; c’est un appel d’outil échoué au milieu d’une exécution, et il se manifeste comme n’importe quelle autre défaillance par appel — c’est pourquoi la mitigation est celle d’un timeout. Sur OrcaRouter, c’est une décision de routage plutôt qu’une modification de code : le checkpoint 1017 et les modèles DeepSeek vers lesquels il basculerait se trouvent derrière un seul endpoint, de sorte qu’un appel qui revient refusé peut être retenté sur un second modèle au lieu de mettre fin à l’exécution. Le refus lui-même appartient au modèle, et rien sur la couche de routage ne le change.

Le nombre de dérivés est le dernier élément indépendant, et il pointe dans la même direction. Une recherche sur Hugging Face portant sur le nom du checkpoint a renvoyé 121 dépôts publics le 20 octobre, et 25 d’entre eux portent uncensored, abliterated ou derisked dans leur nom — des versions dont l’unique but est de supprimer le comportement auquel la session du 20 octobre s’est heurtée, la première d’entre elles ayant été publiée le jour même de la mise en ligne des poids. Ce n’est pas une preuve que le modèle est bon, et ce n’est pas une recommandation ; c’est la preuve qu’il existe dans les poids un mécanisme de refus fonctionnel à supprimer, car les gens qui retirent ce genre de chose ne s’en donnent pas la peine quand il n’y a rien à retirer. Cela fixe aussi les attentes pour toute personne qui auto-héberge le modèle : le checkpoint que vous téléchargez est celui qui refuse, et chaque variante non censurée de cette liste est un modèle différent, pas un réglage.

La question du V4 Pro, et les échelons au-dessus de Flash

Pendant la bêta, le formulaire de retour de DeepSeek demandait aux testeurs si la version intermédiaire « peut pleinement remplacer le DeepSeek V4 Pro en ligne ». C'était une question frappante à poser aux utilisateurs, car elle laissait entendre que l'avenir du modèle phare était ouvert. La réponse arrivée les 9 et 10 septembre fut d'ordre opérationnel : à partir de 12 h 00, heure de Pékin, le 14 septembre, deepseek-v4-pro cesserait d'être servi et son trafic basculerait vers V4.1 Flash aux tarifs de Flash, V4.1 Pro étant désigné comme successeur à terme. Les développeurs ont objecté, et l'objection ne tenait pas à ce que le remplacement soit mauvais — mais à ce qu'une chaîne de modèle constitue un contrat, et que remplacer les poids derrière un ID de production casse les pipelines ajustés par prompts et les boucles d'agents conçues pour les anciens. En deux jours, DeepSeek a retiré le plan. Son propre journal des modifications indique désormais qu'elle « a décidé de continuer à fournir des services API pour DeepSeek V4 Pro après le 14 septembre 2026, le mode de facturation restant inchangé », et qu'elle donnera un préavis supplémentaire si cela change. Le revirement est déclaré par le fournisseur plutôt que rapporté, et il est vérifiable sur la page Models & Pricing, qui liste encore deepseek-v4-pro à côté de deepseek-flash.

Ce que la table de routage n’explique pas, c’est pourquoi. Le 9 septembre, teortaxesTex — l’un des comptes d’informateurs qui avaient signalé la bêta — a rapporté que DeepSeek avait reconnu que le pré-entraînement de son V4-Pro s’était mal passé ; selon ses mots, l’entreprise « a complètement foiré » sur ce point. Cela reste une affirmation à source unique, émanant d’un compte plutôt proche des initiés, et DeepSeek n’a rien reconnu publiquement : le journal des modifications présente le retrait progressif comme la conséquence d’un nouveau modèle meilleur, et non du fait que l’ancien soit défectueux. Ce qui peut être vérifié de l’extérieur, c’est la forme du lancement en disponibilité générale du V4 Pro, le 13 août. L’annonce a été retirée en une journée environ. Le dépôt Hugging Face a brièvement affiché une configuration de niveau Flash sous l’appellation Pro avant que les poids ne soient corrigés. Et les scores indépendants de ce qui était servi sous ce nom se situaient à peine au-dessus du bien plus petit DeepSeek V4 Flash, alors que les graphiques officiels affichaient des résultats proches de ceux du modèle phare — sur l’indice artificial-analysis actuel, les deux ne sont séparés que d’un point, 36 contre 35. Des analyses indépendantes ont invoqué différentes causes — un comportement de raisonnement surajusté au propre banc d’évaluation de DeepSeek, une confusion entre déploiement et poids, ou, comme le prétend la fuite, un pré-entraînement qui a réellement mal tourné. Le changement de routage ne permet pas de trancher, et DeepSeek y a depuis renoncé ; ce qui reste, c’est un fournisseur qui facture son tout dernier modèle à un quart du tarif de défaut de cache du modèle phare et le place devant ce dernier dans ses propres benchmarks, ce que les entreprises ne font généralement pas lorsque tout s’est déroulé comme prévu.

Flash, Pro, Ultra : ce que DeepSeek a dit, et ce qui n’est qu’une supposition

La documentation de DeepSeek elle-même est explicite : ceci constitue le fondement de quelque chose. Le journal des modifications qualifie DeepSeek V4.1 Flash de « plus petit modèle de notre nouvelle famille d’architectures » et indique que l’architecture « est conçue pour un plafond de capacités plus élevé, une inférence plus rapide, un débit plus élevé et une mise à l’échelle vers des modèles plus grands ». Le rapport technique referme la même boucle en des termes plus forts : le modèle « constitue un nouveau point de départ pour nos efforts continus de mise à l’échelle », et l’entreprise déclare qu’elle « poursuivra la mise à l’échelle conjointe de l’architecture du modèle, du pré-entraînement et du post-entraînement afin d’explorer plus avant la frontière de l’intelligence des modèles ». Les deux phrases émanent de l’entreprise, toutes deux ont été publiées le 10 septembre, et aucune n’est une annonce de produit. Elles engagent DeepSeek à construire des modèles plus grands sur cette conception ; elles n’en nomment aucun, n’en précisent pas la taille et n’en fixent pas la date.

Tout ce qui suit cette ligne relève de la spéculation. Le 25 septembre, le traqueur @teortaxesTex — le même compte dont la publication du 9 septembre sur le pré-entraînement de V4 Pro est déjà citée dans cet article — a interprété le schéma comme une gamme complète à trois niveaux : « DeepSeek indique assez clairement qu’ils ne vont pas s’arrêter là… Cela ressemble à l’intention de constituer toute une gamme, Flash-Pro-Ultra. Peut-être 522B-2T-8T ? » Les tailles sont présentées comme une supposition par la personne qui les avance, et cette réserve joue un vrai rôle : rien dans le changelog de DeepSeek, la fiche modèle, le rapport technique, l’organisation Hugging Face, la page de tarification ou la liste de modèles ne nomme un niveau Ultra, ni rien au-dessus de 552B. L’échelle supposée est aussi une arithmétique plus fragile qu’il n’y paraît. Son barreau inférieur, 522B, n’est pas le modèle 552B qui est sorti — soit le chiffre est une coquille pour un nombre que DeepSeek a déjà publié, soit il désigne un checkpoint que personne n’a vu, et il n’y a aucun moyen de savoir de l’extérieur lequel des deux. Son barreau supérieur, 8T, représente cinq fois le fleuron de 1,6T dont DeepSeek a ouvert le dépôt en avril, dans une année où la dernière publication de l’entreprise a été conçue pour activer 8B paramètres par token parce que le coût d’inférence, et non le nombre de paramètres, était la contrainte qu’elle entendait résoudre.

Le même compte a évoqué séparément un modèle DeepSeek de 3 000 milliards de paramètres comme un projet sur lequel le laboratoire travaillait, mais dont il n’était pas sûr de pouvoir assurer l’exploitation de manière économiquement viable — une affirmation différente à propos d’autre chose, et tout aussi non confirmée. Il n’est pas nécessaire de concilier l’une avec l’autre, car ni l’une ni l’autre n’a de seconde source. Ce qui peut être vérifié, c’est la direction : un laboratoire qui présente son tout dernier modèle comme le plus petit d’une famille, et son architecture comme capable de passer à l’échelle de modèles plus grands, est un laboratoire qui prévoit de livrer au-delà de cet échelon. Les noms qu’il donnera aux échelons, et leur taille, ne figurent dans aucun document qu’un lecteur peut ouvrir aujourd’hui.

Pour quiconque choisit un modèle plutôt que de suivre une feuille de route, toute la question tient à cette distinction. Si la famille s’étend effectivement vers le haut, la décision qui se pose à la plupart des équipes reste de savoir s’il faut passer à l’échelon existant — et le moyen le moins coûteux de garder cette décision ouverte n’est pas d’attendre. DeepSeek V4.1 Flash est disponible sur OrcaRouter aux tarifs de DeepSeek avec 0 % de marge ; ainsi, si un successeur de niveau Pro arrive à un prix différent, le changement se répercute dans la grille tarifaire plutôt que dans un contrat. DeepSeek V4 Pro repose sur la même clé derrière lui, ce qui fait de l’arrivée ultérieure d’un troisième niveau une décision de routage plutôt qu’une migration.

Les poids MIT changent ce que vous pouvez en faire.

DeepSeek V4.1 Flash est distribué sous licence MIT, et les poids ont été mis en ligne dans l’organisation deepseek-ai sur Hugging Face le 10 septembre — le même jour que l’API, pas des semaines plus tard. Le dépôt est deepseek-ai/DeepSeek-V4.1-Flash : 48 fragments safetensors totalisant environ 510 Go, le rapport technique au format PDF à côté, et un dossier d’inférence contenant une implémentation de référence ainsi qu’un script de conversion qui répartit le checkpoint entre les rangs de parallélisme tensoriel. Ce dépôt est le checkpoint de septembre ; celui actif depuis le 17 octobre est deepseek-ai/DeepSeek-V4.1-Flash-1017, qui porte la même licence MIT, les mêmes 48 fragments et les mêmes 510 Go environ, mais qui remplace chaque fragment et supprime le rapport, le gabarit de conversation et le dossier d’évaluation.

Il vaut la peine d’être précis sur ce qu’est ce téléchargement, car il ne s’agit pas d’une version en pleine précision. Les safetensors contiennent environ 204 B de paramètres en FP8 et 557 B en INT8, contre environ 2 B en BF16, et la configuration déclare une quantification fp8 — le checkpoint que vous récupérez est déjà compressé, et c’est ainsi qu’un modèle de 763 B de paramètres tient dans environ 510 GB. Le plus grand bloc unique qu’il contient est la table Engram : deux tables FP8 représentant environ 189 GiB du téléchargement, dans lesquelles chaque étape de décodage ne lit que quelques lignes.

Pour un modèle doté d'un backbone de 552 milliards, la licence est l'élément qui fait basculer les décisions. MIT est permissive, sans seuil de revenus ni avenant d'usage acceptable qui mérite un examen juridique, et le profil d'activation — 8 milliards par token en préremplissage, 16 milliards en décodage, avec un cache de 890 octets par token — est ce qui rend son exploitation plausible en dehors d'un hyperscaler, même si le nombre de paramètres paraît élevé. Ce dernier chiffre est toutefois une propriété de l'ensemble de la pile de cache plutôt que des poids, de sorte qu'un moteur auto-hébergé qui implémente le format quantifié et non le reste de la conception se situera bien au-dessus de ce chiffre.

Une licence permissive ne vaut pas autorisation d’exportation, et pendant six jours d’octobre, la différence a semblé pouvoir compter. Le 16 octobre, le ministère chinois du Commerce et le ministère des Sciences et Technologies ont publié l’annonce n° 48 de 2026, un projet de révision du catalogue des technologies interdites à l’exportation ou soumises à restriction qui inclut pour la première fois les poids de modèles d’IA et le code source. Il propose 40 ajouts dans l’IA, les biotechnologies et le solaire, dont 23 liés à l’IA, la consultation publique courant jusqu’au 15 novembre. Deux dérogations du projet font l’essentiel du travail pour un modèle comme celui-ci : les technologies déjà dans le domaine public du fait d’une diffusion en open source ou d’une publication académique ne doivent pas être contrôlées, et l’accès via API, application, SaaS et accès léger sur appareil pour les utilisateurs étrangers n’est pas traité comme une exportation de technologie de modèle. Les seuils rapportés par la presse spécialisée combinent un plancher de paramètres de deux billions, une place dans le top dix mondial sur les benchmarks de performance et de sécurité, et un entraînement sur des données nationales essentielles ou importantes. Un modèle de 552B franchit le premier ; si les deux autres le concernent, un lecteur ne peut le déterminer de l’extérieur, car le projet ne publie pas les définitions — ce qui fait de la dérogation pour le domaine public, et non du critère de taille, la clause qui compte pour des poids déjà sur Hugging Face.

Ce qui a changé le 22 octobre, ce n’est pas le texte, mais le registre de conformité. YuyuantanTan a rapporté que DeepSeek et MiniMax avaient terminé les procédures d’enregistrement et achevé l’open sourcing et l’octroi de licences à l’étranger. Le rapport ne précise pas quelles versions il compte au titre de l’open sourcing, ne nomme aucun modèle, checkpoint ou date, et n’annonce aucun nouveau poids ; les publications open source visibles dans cette fenêtre sont le moteur DeepInfer et la boîte à outils deepseek-recipe évoqués plus haut. La version de cette affirmation au niveau des builds est plus restreinte et plus tardive : le 23 octobre, un compte X ayant un long historique de suivi de DeepSeek a publié que DeepSeek et MiniMax avaient « obtenu les autorisations pour l’open sourcing de V4.1F-1017 et M3.1-Flash », respectivement. Cette attribution est celle de l’auteur de la publication, aucune des deux sociétés n’a publié de déclaration la confirmant, et aucun régulateur n’a publié d’avis mentionnant l’enregistrement de l’une ou l’autre des sociétés. Le checkpoint nommé dans la publication se trouvait sur Hugging Face sous licence MIT depuis le 17 octobre, six jours plus tôt. Quelle que soit l’autorisation accordée, elle n’a pas conditionné le téléchargement : le dépôt est arrivé en premier.

Pour un lecteur, le contenu pratique est plus étroit que les gros titres qui l'entourent, et il va dans deux directions. Rien concernant le point de contrôle du 17 octobre, la licence MIT ou le dépôt n'a changé le 22 octobre ; le téléchargement, les fragments et les différences de hachage décrits ci-dessus sont exactement tels qu'ils étaient. Ce qui a changé, c'est la réponse à la question de savoir si un laboratoire chinois peut continuer à publier des pondérations comme celles-ci alors que le catalogue est encore en consultation : le compte rendu des médias d'État dit oui pour DeepSeek et MiniMax, dans le cadre d'un projet qui exclut les technologies déjà publiques et laisse l'accès API en dehors de la définition des exportations. La limite est dans le temps grammatical. L'exemption concerne les technologies déjà dans le domaine public, ce qui décrit les points de contrôle de septembre et octobre et ne décrirait pas automatiquement une version publiée après la finalisation du catalogue — et l'obligation d'enregistrement intermédiaire censée avoir pris effet le 16 octobre a été rapportée plutôt que publiée dans son intégralité. Quiconque prévoit de télécharger ce que DeepSeek publiera ensuite se prépare selon une règle qui n'existe pas encore. Quiconque appelle V4.1 Flash aujourd'hui, ou exécute les pondérations 1017, s'appuie sur une exception que le projet énonce et que ni l'un ni l'autre des comptes rendus de la mesure intermédiaire ne contredit.

La prise en charge du serving est arrivée le jour même, et elle fixe le plancher pratique. vLLM a publié une recette day-0 validée sur du matériel NVIDIA et AMD, et SGLang a livré une prise en charge day-0 de l’inférence et du RL dans la même fenêtre via sa pile d’entraînement Miles. Les deux sont arrivés sous forme d’images de prévisualisation plutôt que de paquets stables — le conteneur vLLM portait un tag du 9 septembre, un jour avant la GA du modèle lui-même. Ce volet de l’histoire a évolué le 22 septembre, lorsque vLLM a publié la v0.30.0 : la première version stable de vLLM à embarquer cette architecture, avec DeepSeek V4.1 Flash répertorié dans sa prise en charge des nouveaux modèles, la recette vLLM du modèle exigeant désormais la 0.30.0 ou une version ultérieure, et le tag d’image du jour du lancement retiré. Les notes de version sont le récit que le projet fait de son propre travail, et non un résultat mesuré ; il faut les lire comme telles. Elles attribuent à cette version le fait de conserver l’intégralité du cache KV du modèle en MXFP8 grâce au record FlashMLA V4.1 sur SM100, ainsi que le prefetch asynchrone des recherches Engram déchargées sur le CPU et le sharding data-parallel d’Engram — les deux changements qui comptent le plus pour un modèle dont la table Engram est le plus gros bloc du téléchargement. Aucun de ces deux changements ne porte de chiffre provenant de l’extérieur du projet, et les notes de version n’en avancent aucun — mais le projet a publié un avant/après portant sur le modèle dans son ensemble le 7 octobre, trois semaines après la sortie : 1,9× plus rapide à faible concurrence et 5,3× le débit sous une contrainte de 150 TPS par rapport à sa propre build day-0, avec la pull request fusionnée à l’origine de chaque optimisation listée. Les chiffres et leurs limites figurent dans la section consacrée à la vitesse ci-dessus. Ce qui n’existe pas, c’est une réplication externe — chaque chiffre de ce billet est le projet qui se mesure lui-même. Ce que la sortie tranche, en revanche, c’est le packaging : 762 commits provenant de 315 contributeurs, dont 104 nouveaux, dans une version taguée plutôt qu’une image de prévisualisation. Le calcul de la recette vLLM elle-même place toujours le minimum à environ 614 Go de VRAM pour le checkpoint de 510 Go plus la marge nécessaire — un nœud à huit GPU H200 ou un châssis GB200 NVL4 — et avertit qu’un contexte de 1M de tokens doit en pratique être plafonné plutôt que supposé. Un cache KV plus étroit change la quantité de mémoire dont le moteur en cours d’exécution a besoin, pas la taille du checkpoint ; le plancher en matière de nœuds reste donc valable. Le compte rendu de SGLang ajoute un levier propre à cette architecture : déplacer la table Engram en mémoire hôte avec une seule variable d’environnement a augmenté la capacité du cache KV d’environ 36 % lors d’un test avec quatre GB300, à débit de décodage et temps jusqu’au premier token comparables, et son rejeu borné SWA côté décodeur a porté le débit de prefill à 1,56× sur huit H200. Deux limites accompagnent cela. L’implémentation de référence du dépôt se décrit elle-même comme un exemple lisible plutôt qu’un moteur de serving de production, et les runtimes grand public étaient à la traîne : la voie de quantification qui permettrait de faire tourner ce modèle sur un ordinateur portable ou un Mac Studio n’était pas ouverte au lancement. En bref, les poids sont réellement ouverts et la pile de serving existe réellement — sur du matériel qui se compte en nœuds plutôt qu’en GPU, ce qui est la raison honnête pour laquelle une licence permissive ne signifie pas automatiquement qu’on peut faire tourner le modèle localement. Le dépôt 1017 ne change rien à ce plancher — le checkpoint est toujours de 510 Go réparti sur les mêmes 48 shards, et les notes d’exécution qui l’accompagnent sont celles publiées pour les poids de septembre.

Ce que les poids ouverts ne vous donnent pas, à eux seuls, c’est un signal de qualité — mais cet écart s’est désormais en partie comblé, et il s’est encore réduit le 18 octobre. Quatre instruments indépendants existent maintenant, dont l’un a été exécuté deux fois : l’Intelligence Index d’Artificial Analysis, qui attribue 39 au checkpoint de septembre et 45 au checkpoint 1017 ; l’étude Exploit Bench ci-dessus, un benchmark de cybersécurité exécuté sous sept harnais d’agents ; le tableau communautaire des kernels dans la section ci-dessous ; et, depuis le 14 octobre, les propres résultats AA-AgentPerf d’Artificial Analysis pour ce modèle, qui mesurent le matériel sur lequel il est servi plutôt que sa qualité. Le comparatif avant/après du 7 octobre du projet vLLM, ci-dessus, mesure encore autre chose — ce que coûte le service du modèle plutôt que sa qualité — et constitue le compte rendu que le runtime donne de lui-même. Aucun n’est un score de raisonnement du type de celui que construit ARC Prize, trois des quatre décrivent encore le checkpoint de septembre, et pour la plupart des lignes spécifiques de cet article, la fiche du modèle reste la seule source — mais le composite n’a plus sa place sur cette liste : le 45, et le 33,8 en dessous, ont été produits sur les poids que DeepSeek sert aujourd’hui. Ce n’est pas une accusation ; c’est l’état des preuves, et c’est pourquoi cet article garde séparés les deux types de chiffres. Les poids ouverts signifient bien que le modèle ne restera pas confiné au point de terminaison de DeepSeek, ce qui compte pour quiconque était bloqué par la résidence des données plutôt que par le prix.

Comment l'adopter sans y engager la production

Une chose a changé de notre côté depuis la sortie, et cela rend cette section plus simple qu'elle ne l'aurait été la semaine dernière : DeepSeek V4.1 Flash est désormais sur OrcaRouter. Il répond à l'identifiant de modèle deepseek/deepseek-v4.1-flash via le même point de terminaison compatible OpenAI que le reste de la gamme, au tarif propre à DeepSeek — 0,15 $ par million de tokens d'entrée, 0,60 $ par million de tokens de sortie et 0,003 $ par million de lectures de cache aux tarifs hors pointe, doublés pendant les fenêtres de pointe en semaine — répercutés avec 0 % de majoration. C'est ce dernier point qu'il vaut la peine d'expliciter : le montant qui vous est facturé est celui du fournisseur plutôt qu'un prix de revente, de sorte qu'une baisse de prix du fournisseur est appliquée ici le jour même, au lieu d'attendre qu'un contrat soit renégocié. DeepSeek V4 Flash et DeepSeek V4 Pro utilisent la même clé, ce qui fait de la migration ci-dessous un changement de routage plutôt qu'un changement de plateforme. Le point de contrôle du 17 octobre ne change rien à cela : DeepSeek a conservé à la fois le nom du modèle d'API et la grille tarifaire, si bien que la mise à jour ne modifie ni l'identifiant ni le prix de notre côté, ce à quoi ressemble une répercussion lorsqu'un fournisseur actualise un modèle sans toucher ni à l'un ni à l'autre.

C’est aussi l’argument pour ne pas précipiter la migration. Le reroutage du 14 septembre aurait été un fournisseur modifiant ce que signifie un ID de modèle sous vos pieds, si DeepSeek ne l’avait pas annulé sous la pression, et cet épisode est le rappel récent le plus net qu’une chaîne de modèle est un contrat qu’un fournisseur peut réécrire — ce qui constitue aussi le bon cadre pour la discussion sur la gamme ci-dessus, puisqu’une famille à trois niveaux est un plan et que celle-ci a déjà changé une fois. Pour un modèle dont les seuls scores externes à ce jour sont un indice composite, un tableau cyber bruité et un tableau communautaire de kernels — et qui n’a aucun historique de production — la forme la plus sûre est celle pour laquelle un routeur est conçu : envoyer une partie du trafic représentatif de la production vers le nouveau modèle, garder un modèle éprouvé derrière lui comme basculement automatique afin qu’une régression de qualité coûte une nouvelle tentative plutôt qu’un incident, et laisser le DSL de routage décider quels appels valent le modèle non éprouvé et lesquels doivent rester sur le modèle de travail. La migration vers V4.1 Flash est probablement la bonne destination. Ce n’est pas une migration à exécuter sur l’annonce.

Questions ouvertes

• Benchmarks indépendants — le décompte est passé de zéro à quatre instruments, et aucun d'eux ne mesure le raisonnement du modèle comme ARC Prize l'entend. Le score de 39 d'Artificial Analysis est un composite de dix évaluations à effort de raisonnement maximal, et son 45 — publié le 18 octobre — est le même composite appliqué aux poids plus récents. L'étude Exploit Bench ci-dessus est un score de cyber-exploitation dans un budget de tokens fixe, et elle classe DeepSeek V4.1 Flash en dessous de GLM-5.3-Flash. Le tableau communautaire des kernels sur kernelbench.com est un tableau d'ingénierie de kernels. Les résultats AA-AgentPerf d'Artificial Analysis, publiés le 14 octobre, sont un tableau matériel : combien de tokens par seconde par mégawatt chaque système d'accélérateur fournit à ce modèle, et rien sur la qualité. Personne n'a reproduit les lignes de benchmark individuelles de DeepSeek, et aucune mesure indépendante aux paramètres d'effort de production, ni à l'extrémité d'une fenêtre de 1 M de tokens, n'a été publiée. Le checkpoint du 17 octobre n'est plus dépourvu de mesures : le 18 octobre, Artificial Analysis a ajouté une ligne 1017 à 45 sur son indice et à 33,8 sur Terminal-Bench 4.0, et le chiffre du benchmark se situe huit points et demi sous ce que le tableau du fournisseur revendique pour les mêmes poids. Ce qui manque maintenant, c'est un second avis sur ce chiffre — un évaluateur, un harnais, une exécution — et tout score indépendant, quel qu'il soit, pour les quatre mesures antérieures au remplacement. La seule évaluation conçue pour répondre à la question du raisonnement est encore en construction — ARC Prize a un profil DeepSeek V4.1 Flash dans son harnais de benchmarking dans une pull request ouverte, sans résultat associé — et ARC-AGI n'a jamais évalué ce checkpoint du tout : les 61,4 % sur ARC-AGI-2 que l'arrivée de l'adaptateur a relancés appartiennent à DeepSeek V4 Flash 0731, le modèle que V4.1 Flash retire. Le chiffre le plus récent associé à ce modèle, les 77,0 sur DeepSWE v1.1, est la ligne la moins bien sourcée de l'article : c'est le propre graphique de DeepSeek, lu sur une image jointe à l'annonce du fournisseur, et aucune exécution externe de DeepSWE v1.1 sur le checkpoint 1017 n'existe — le résultat du 18 octobre d'Artificial Analysis concerne les mêmes poids mais un benchmark différent. Les deux tableaux indépendants qui publient le benchmark placent le nom de ce modèle à 71,7 % et 74,2 %, ce qui suffit à le placer à côté d'Opus 5 et ne suffit pas à confirmer le chiffre du fournisseur — et aucun des deux n'indique quel checkpoint il a mesuré.

• Auto-hébergement sous le seuil du nœud — la prise en charge dès le lancement de vLLM est devenue une version stable le 22 septembre avec la v0.30.0, qui ajoute un chemin KV MXFP8 et un déport asynchrone d'Engram ; la prise en charge dès le lancement de SGLang est toujours livrée sous forme d'image d'aperçu. Aucune des deux ne déplace le plancher matériel, qui se situe autour d'un nœud de huit GPU, car c'est le checkpoint de 510 Go qui le fixe — et les propres notes de déploiement de DeepSeek, publiées avec DeepInfer, précisent les choses : un nœud de préremplissage à côté d'un nœud de décodage est déployable, mais la configuration de décodage recommandée est un parallélisme d'experts de 64 ou plus, ce qui fait de la plus petite unité efficace 64 GPU de préremplissage à côté de 64 de décodage. L'article du 7 octobre du projet vLLM est le bilan d'optimisations mesurées le plus complet publié sur ce modèle — 1,9× à faible concurrence et 5,3× sous une contrainte de 150 TPS par rapport à sa propre version initiale, aux côtés des chiffres SGLang ci-dessus — et son suivi du 17 octobre ajoute une courbe de jetons par dollar qui couvre bel et bien les configurations H100, MI300X et B200 aux côtés des composants à l'échelle du rack. Les deux constituent le propre bilan du projet sur son propre runtime. Aucune ne déplace le plancher : un jeton moins cher sur un GB300 ou un H100 ne permet toujours pas de faire tenir un checkpoint de 510 Go sur un ordinateur de bureau, c'est donc un chemin plus rapide vers le même plancher plutôt qu'un plancher plus bas. Savoir si des versions ultérieures et des quantifications communautaires amènent cela sur des machines plus petites est la question ouverte pour quiconque veut les poids plutôt que le point de terminaison, et c'est celle qui décide si une licence permissive est une licence pratique.

• Ce qu’est V4.1 Pro — DeepSeek le présente comme le successeur de V4 Pro, mais n’a publié ni date, ni spécification, ni prix, et le réacheminement annoncé du trafic Pro existant vers un modèle de gamme Flash a été retiré avant d’entrer en vigueur. Ce qui se situe au-dessus de Flash n’est décrit par l’entreprise que comme l’architecture qui s’étend à des modèles plus grands ; la hiérarchie Flash, Pro et Ultra et ses tailles de 522B, 2T et 8T relèvent de la spéculation d’un observateur, pas de DeepSeek.

• Coût par tâche — Artificial Analysis publie désormais un chiffre par tâche pour les deux checkpoints : 0,49 $ par tâche de l’Intelligence Index pour les poids de septembre, révisé par rapport aux 0,27 $ initialement indiqués dans cet article, et 0,26 $ pour 1017. Il s’agit du premier élément de preuve externe pour une partie quelconque de l’affirmation de Pareto de DeepSeek, et il est plus étroit que cette affirmation. Les mêmes lignes montrent que le checkpoint 1017 génère 210 M de tokens de sortie sur l’ensemble de l’indice, contre 250 M pour septembre — des sorties globalement plus courtes —, mais 89 495 tokens de sortie par tâche contre 88 574, ce qui n’est pas plus court du tout, et 288,8 secondes par tâche contre 289,9, ce qui n’est pas plus rapide. La propre ventilation des coûts du site attribue l’intégralité de l’économie au côté entrée : la ligne de sortie est stable, à 0,106 $ par tâche contre 0,107 $, tandis que l’entrée passe de 0,379 $ à 0,155 $ et les écritures en cache de 0,322 $ à 0,095 $. Que l’exécution d’une tâche coûte moins de dollars dépend du nombre de tokens qu’elle nécessite, et cela relève de la charge de travail plutôt que de la grille tarifaire. La propre description de la mise à jour par DeepSeek va dans le sens opposé : le changelog affirme que le nouveau checkpoint réduit le temps d’exécution des tâches et la longueur des sorties, et sa publication du 17 octobre le répète ainsi : « exécution des tâches plus rapide, et sorties plus courtes ». Aucun des deux ne cite de chiffre, et la mesure externe qui sous-tend cette puce vient désormais les mettre à l’épreuve : sur les deux grandeurs nommées par DeepSeek, les poids 1017 ont évolué d’environ un pour cent, dans des directions opposées, par rapport à un point de départ situé cinq semaines plus tôt. Un troisième chiffre se situe de l’autre côté du même bilan : le graphique du 17 octobre du projet vLLM place le modèle à 1,3 Md de tokens par dollar de coût total de possession sur SemiAnalysis AgentX, dans une tranche de coûts qui suppose des volumes de grands hyperscalers. Un service moins cher ne tranche pas non plus ce point — un coût par token plus faible laisse le chiffre de tokens par tâche, qui correspond à ce qu’un appelant paie réellement, exactement là où la mesure de septembre l’avait trouvé.

• Emballement de la vérification — des testeurs de terrain signalent des boucles de répétition occasionnelles dans la chaîne de pensée, ainsi que des délibérations de douze minutes et de plusieurs centaines de milliers de tokens sur des problèmes qui se résolvent en quelques secondes avec un réglage d'effort plus faible. Aucun benchmark indépendant ne mesure la fréquence de l'un ou l'autre de ces phénomènes, ni ce que cela coûte en production, et la mesure d'atténuation rapportée jusqu'ici consiste en des plafonds de tokens côté client, plutôt qu'en quoi que ce soit que le modèle fasse pour lui-même. L'étude Exploit Bench ci-dessus documente le même mode de défaillance dans l'autre sens : la boucle de rapports répétés qu'elle met en évidence dans les transcriptions ReAct est produite par le prompt de compactage du harnais, plutôt que par le raisonnement propre du modèle, ce qui rappelle qu'une boucle dans une transcription n'est pas automatiquement un défaut du modèle.

• Ingénierie des kernels — le classement communautaire de kernels CUDA de kernelbench.com (RTX PRO 6000, mis à l’échelle roofline) place DeepSeek V4.1 Flash à 50,19 % de la roofline en équivalent dense sur son propre kernel d’attention creuse, quatrième au classement général, contre 4,45 % pour GLM-5.3 Flash sur la même ligne. Le classement est géré par la communauté et n’a pas fait l’objet d’une évaluation par les pairs ; aucune seconde génération de GPU ni réplication n’a été publiée.

• Contexte long à l'extrémité lointaine — l'attention sparse a été entraînée à 64K puis étendue à 1M au cap des 34T tokens. La façon dont la qualité se maintient près de la fin d'une fenêtre complète de 1M est précisément ce qu'une évaluation indépendante du long contexte permettrait de trancher.

• Reconstruction du cache aux limites — SWA Bounded Replay reconstruit de façon approximative, plutôt qu’exacte, l’état de fenêtre glissante abandonné, et DeepSeek indique que le résultat peut varier selon l’endroit où une correspondance de cache se produit dans une session. Le rapport note peu d’impact observé sur la qualité ; les conditions extrêmes ou non testées sont précisément là où une approximation de ce type se manifesterait, et personne en dehors de DeepSeek ne s’y est intéressé.

• Si les charges de travail Pro migrent réellement — le reroutage forcé a été retiré, donc rien ne migre à moins qu'une équipe ne choisisse de le faire, et les équipes qui ont payé le prix d'un abonnement Pro pour la profondeur de raisonnement sont celles qui sont le plus susceptibles de remarquer une différence de capacités sur des tâches du type Terminal-Bench 3.0, où V4.1 Flash accuse un large retard sur Opus-5.0.

• Les conditions et le comportement de l’offre gratuite — OpenCode a ajouté une entrée gratuite pour ce modèle le 15 octobre, sur une fenêtre de 200 000 jetons et un plafond de sortie de 32 000 jetons, décrite sur ses propres pages comme disponible pour une durée limitée. Que ce dispositif survive à cette formule, comment le point de terminaison tient le coup sous charge et si DeepSeek a son mot à dire à ce sujet restent tous non dits : la liste de modèles, la documentation et la grille tarifaire propres à la plateforme sont la seule source, il n’y a aucune date de fin à opposer à qui que ce soit, et personne n’a publié de mesure de la route gratuite.

• Sécurité et refus — DeepSeek ne publie aucun taux de refus, résultat de red team ni évaluation de sécurité pour l’un ou l’autre des checkpoints, et aucun laboratoire indépendant n’a évalué ce modèle sur un benchmark de jailbreak. Les chiffres de cet article proviennent de personnes qui construisent des dérivés non censurés — 97 prompts nuisibles sur 100 refusés en mode chat, 98 en mode réflexion, sur un même jeu de prompts et avec un même évaluateur — et d’une unique capture d’écran de session d’agent dans laquelle le modèle a refusé une persona jailbreakée. Savoir si ce comportement tient avec un faible effort de raisonnement, dans des langues autres que l’anglais, face à des attaques automatisées plutôt qu’à un prompt de persona, et sous un harnais qui réécrit le prompt système, n’a été mesuré par personne.

• Les formalités du prochain checkpoint — le rapport du 22 octobre tranche la question de l’enregistrement pour les poids déjà publics, car le projet de catalogue exclut les technologies déjà dans le domaine public. Il ne tranche pas la question de la publication qui suivra celle-ci. Le catalogue est un projet ouvert aux commentaires jusqu’au 15 novembre, ses seuils sont rapportés plutôt que publiés dans le texte, et l’obligation d’enregistrement provisoire qui aurait pris effet le 16 octobre n’a pas été publiée dans son intégralité. V4.1F-1017 est lui-même disponible, sous licence MIT et sans restriction d’accès ; les critères qu’un futur checkpoint DeepSeek devra satisfaire avant de pouvoir être téléchargé relèvent d’une règle qui n’existe pas encore.

La bêta a été une question de deux jours : un modèle de gamme Flash pouvait-il assumer les fonctions d’un Pro ? La sortie est DeepSeek qui y répond avec une grille tarifaire et un plan de routage — puis qui retire ce plan de routage en l’espace de deux jours, lorsque les développeurs ont contesté le fait qu’un modèle de production soit remplacé sous leurs pieds. C’est une déclaration plus faible que ne le laissait entendre l’annonce, et plus honnête : les preuves de qualité à l’appui de ce changement sont les benchmarks de DeepSeek eux-mêmes, plus des mesures externes qui vont surtout dans le même sens. La plus récente, un benchmark de cybersécurité exécuté sous sept harnais d’agents, va dans le sens inverse sur la seule comparaison qu’elle effectue, et l’entreprise a laissé le choix à ses clients plutôt que de le faire pour eux. Depuis la sortie, les poids sont passés d’une promesse à un téléchargement de 510 Go, le modèle est passé d’un point de terminaison fournisseur à quelque chose vers lequel vous pouvez router du trafic, et la pile de serving est passée d’une recette du jour 0 à une recette mesurée — vLLM s’étant déclaré 1,9× plus rapide à faible concurrence au bout de trois semaines, puis ayant publié, le jour où le checkpoint a changé, une courbe de coût qui situe le modèle à 1,3 Md de tokens par dollar de coût total de possession sur SemiAnalysis AgentX. Cette semaine, la couche sous-jacente à tout cela s’est également ouverte : DeepSeek a publié DeepInfer, le moteur que fait tourner son propre service, avec une courbe de décodage pour ce checkpoint, les chiffres de production derrière cette courbe, et un benchmark de septembre non publié qui place le 950DT de Huawei cinq à sept fois derrière NVIDIA par puce, à la vitesse à laquelle DeepSeek sert réellement. Au bout de cinq semaines, le checkpoint lui-même n’a bougé qu’une fois : le 17 octobre a apporté de nouveaux poids sous le même nom et au même prix, avec un tableau fournisseur meilleur sur chaque ligne qu’il publie et un harnais différent sous l’une d’elles. Deux jours plus tard, la mesure externe est arrivée, et c’est le chiffre le plus utile de cet article : Artificial Analysis a placé les poids du 1017 à 45 sur son indice — à égalité avec GLM-5.3 pour la deuxième place parmi les modèles à poids ouverts, un point derrière MiMo-V2.6-Pro — et à 33,8 sur Terminal-Bench 4.0, contre 42,3 chez le fournisseur sur le même benchmark — ainsi, le harnais qui flatte le modèle dans le tableau de DeepSeek n’est pas celui dans lequel le chiffre tient. Si vous choisissez aujourd’hui, la position honnête est que V4.1 Flash semble offrir le meilleur rapport qualité-prix de la gamme DeepSeek, a quatre instruments indépendants à son actif — aucun n’étant un score de raisonnement, l’un d’eux étant désormais exécuté sur le checkpoint que DeepSeek sert depuis le 17 octobre — une cinquième évaluation en cours de construction, aucun historique de production, une pile de serving dont les deux chiffres les plus forts — un écart de vitesse et une courbe de coût — viennent tous deux du projet qui a écrit le runtime, et un résultat externe en cybersécurité qui se contredit déjà selon le harnais que l’on enroule autour du modèle, une offre gratuite de 200 000 tokens apparue sur une plateforme le 15 octobre, et une première série de rapports de prise en main décrivant un modèle qui vérifie son propre travail plus loin que la plupart des appelants ne le lui demanderont — ce qui est une raison de diriger une partie du trafic vers lui, pas une raison de migrer sur l’annonce. La mise à jour annoncée par DeepSeek le 17 octobre change les poids et ajoute une affirmation du fournisseur — achèvement plus rapide des tâches, sorties plus courtes — et la première mesure externe de ces poids n’en confirme au mieux que la moitié : coût par tâche de l’indice réduit de 46 %, tandis que le temps par tâche et les tokens de sortie par tâche n’ont quasiment pas bougé. Un jour plus tard, l’affirmation la plus lue au sujet de ce checkpoint était celle d’un cadre : 77 sur DeepSWE v1.1 à un coût 83 fois inférieur, de la part d’un employé de Databricks qui dit aussi que le checkpoint arrive sur cette plateforme. La moitié résiste au contact des tableaux indépendants, qui placent désormais le nom de ce modèle au-dessus d’Opus 5 sur ce benchmark. L’autre moitié, pas encore : le 77 est la ligne de DeepSeek lui-même, non reproduite, et le 83× est une arithmétique sans coût par tâche publié à l’appui. La documentation de Databricks elle-même confirme que le modèle est sur sa plateforme et que les deux modèles DeepSeek en dessous sont programmés pour être retirés ; elle ne confirme pas l’arrivée du checkpoint. Cette affirmation est désormais la deuxième affirmation la plus intéressante à propos du checkpoint, et non la première. Le 19 octobre, un compte de suivi qui a annoncé plusieurs de ces sorties en avance s’est déclaré « absolument certain » du 42,3 sur Terminal-Bench 4.0, au motif qu’il dépasse GLM-5.3, et a demandé à Artificial Analysis d’exécuter le modèle dans un harnais natif. Le site l’avait déjà fait. Sur son propre harnais, les mêmes poids obtiennent 33,8 — en dessous des 41,9 de GLM-5.3, et non au-dessus. La ligne du fournisseur est réelle et c’est celle de DeepSeek ; l’inférence que l’on en tire ne survit pas à une exécution par quelqu’un d’autre.

Si la version que vous voulez est celle qui garde vos options ouvertes, toutes les trois sont accessibles avec une seule clé et facturées aux tarifs de DeepSeek, avec 0 % de marge ajoutée. La sortie elle-même : DeepSeek V4.1 Flash sur OrcaRouter — contexte de 1 M de tokens, plafond de sortie de 384 K, entrée d'images, à 0,15 $ par 1 M de tokens en entrée et 0,60 $ par 1 M de tokens en sortie hors pointe. Le modèle qu'elle remplace : DeepSeek V4 Flash sur OrcaRouter. Et le modèle phare que DeepSeek a décidé de continuer à servir : DeepSeek V4 Pro sur OrcaRouter. Acheminez une partie du trafic vers le nouveau, gardez un modèle éprouvé derrière lui comme solution de basculement, et laissez le routage décider.

Le choix d'un modèle est aussi une question de ce qui a mal tourné auparavant : les incidents d'IA documentés et les défaillances d'agents documentées pour les modèles de cette classe sont recensés dans the OrcaRouter AI Incident Archive, où chaque entrée comporte ses propres sources, son degré de gravité, sa note de confiance et son indicateur de contestation.