DeepSeek a lancé DeepSeek V4.1 Flash le 10 septembre 2026. Ce modèle multimodal à poids ouverts accepte le texte et les images, produit du texte et peut traiter jusqu’à 1 000 000 de tokens dans son contexte. Son originalité ne tient pas à une victoire générale sur tous les concurrents, mais à un compromis technique précis : un très grand modèle Mixture-of-Experts (MoE), une activation différente selon l’étape de calcul et une empreinte de cache KV annoncée à environ 890 octets par token.
Pour les équipes qui construisent des agents ou manipulent de longs documents, cette architecture peut réduire la pression exercée sur la mémoire de service. Pour l’utilisateur qui veut faire tourner le modèle chez lui, en revanche, les 552 milliards de paramètres restent un morceau particulièrement imposant.
Ce qu’est DeepSeek V4.1 Flash
DeepSeek V4.1 Flash est un modèle de langage multimodal de type Mixture-of-Experts. Le modèle accepte des entrées textuelles et visuelles et renvoie du texte. Ses poids sont disponibles sur Hugging Face sous licence MIT, ce qui autorise leur téléchargement et leur auto-hébergement dans le cadre de cette licence.
L’API utilise l’identifiant deepseek-flash. DeepSeek a par ailleurs annoncé que les requêtes adressées à deepseek-v4-pro seraient orientées vers V4.1 Flash à partir du 14 septembre 2026, jusqu’à l’arrivée de V4.1 Pro. Cette annonce concerne le routage des requêtes : elle ne constitue pas une mesure indépendante des performances du modèle.
Pour la France, la tarification de l’API est exprimée en dollars américains et non dans un tarif spécifique en euros. Elle varie selon le type de tokens facturés et les périodes de pointe ou de faible demande.
Pourquoi 552 milliards ne signifie pas 552 milliards actifs à chaque étape
Le chiffre de 552 milliards correspond à la taille totale du backbone du modèle. Dans un système MoE, tous les experts ne sont pas sollicités pour chaque token. DeepSeek indique qu’environ 8 milliards de paramètres sont actifs pendant le traitement de l’entrée, appelé prefill, puis environ 16 milliards pendant la génération, ou decoding.
Cette activation asymétrique distingue trois notions souvent mélangées :
- les paramètres totaux, qui décrivent la capacité et le stockage global du modèle ;
- les paramètres actifs, mobilisés pour un token à une étape donnée ;
- la mémoire réellement nécessaire, qui dépend aussi de la quantification, du cache, du runtime, de l’offloading et de la bande passante.
Les 8 et 16 milliards actifs ne permettent donc pas, à eux seuls, de déduire la mémoire requise pour une installation locale. C’est le piège classique : confondre le nombre de spécialistes appelés avec la taille de toute la bibliothèque.
L’architecture annoncée est un Causal Encoder-Decoder de 40 couches, réparti entre un encodeur causal et un décodeur. Elle s’appuie notamment sur Compressed Sparse Attention 2, Engram et DSpark pour gérer le traitement, la mémoire et la génération spéculative.
Cache KV et contexte d’un million de tokens
Le cache KV conserve des représentations intermédiaires afin d’éviter de recalculer toute l’historique à chaque nouveau token. Plus une conversation ou un document est long, plus cette mémoire devient importante pour le coût et la capacité de service.
DeepSeek V4.1 Flash annonce une empreinte mondiale de cache KV d’environ 890 octets par token, contre 3 514 octets pour DeepSeek V4 Flash. DeepSeek présente aussi cette conception comme consommant un quart de la mémoire HBM et un huitième du stockage SSD de la génération précédente. Ces valeurs décrivent l’architecture et les conditions techniques annoncées par DeepSeek ; elles ne constituent pas une garantie de débit identique chez tous les fournisseurs.
Le contexte maximal atteint 1 000 000 de tokens. C’est utile pour les documents volumineux, les bases de code et les agents qui conservent beaucoup d’étapes intermédiaires. Mais une grande fenêtre de contexte ne garantit ni la pertinence de chaque réponse ni la qualité du raisonnement sur tout le contenu fourni.
Ce que les benchmarks montrent réellement
Les résultats de DeepSeek sont particulièrement élevés sur certaines évaluations de code, de cybersécurité et d’agents. À effort de raisonnement maximal, le modèle obtient notamment 74,2 sur DeepSWE v1.1, 88,1 sur CyberGym et 90,6 sur Terminal-Bench 2.1. Ces scores restent attachés à leurs suites de tests, à leurs bancs d’évaluation et à leurs réglages précis.
Artificial Analysis mesure séparément un score Intelligence Index de 39,5, une vitesse médiane de sortie de 206,3 tokens par seconde et un délai de 1,13 seconde avant le premier bloc. Ces chiffres relèvent d’une méthodologie et de conditions de fournisseur différentes de celles des tableaux de DeepSeek.
| Modèle | Paramètres totaux | Paramètres actifs | Fenêtre de contexte | Terminal-Bench 2.1 | CyberGym | DeepSWE v1.1 | Terminal-Bench 4.0 | Vitesse de sortie selon Artificial Analysis |
| DeepSeek V4.1 Flash | 552B | 8B en entrée / 16B en sortie | Jusqu’à 1 000 000 de tokens | 90,6 | 88,1 | 74,2 | 31,2 | 206,3 tokens/s |
| DeepSeek V4 Pro 0813 | 1,6T | 49B | — | 87,9 | — | 62,7 | 12,4 | 72,3 tokens/s |
| GPT-5.6 Sol | Non communiqué | Non communiqué | — | 88,8 | 84,5 | 73,0 | 39,9 | 111,9 tokens/s |
| Claude Opus 5 | Non communiqué | Non communiqué | — | 89,1 | — | 74,0 | 51,8 | 65,8 tokens/s |
Le tableau juxtapose donc des métriques précises, pas un classement universel. Le modèle est devant certains concurrents sur des tests donnés et derrière eux sur d’autres, notamment Terminal-Bench 4.0. La bonne question n’est pas « quel modèle gagne partout ? », mais « quel modèle répond le mieux à mon usage, dans quelles conditions et à quel coût ? »
Un benchmark vidéo consacré à 24 prompts de programmation répète les essais pour tenir compte de la variabilité entre deux générations. Cette approche rappelle un point important pour les agents de code : le résultat peut dépendre du prompt, de la température, de top_p, du nombre d’essais et du réglage de raisonnement. Les chiffres d’un classement particulier ne deviennent pas automatiquement une mesure de toute l’API.
Tarifs API et routage de V4 Pro
DeepSeek facture l’API selon plusieurs variables : tokens d’entrée mis en cache, tokens d’entrée non mis en cache, tokens de sortie et période de pointe ou de faible demande. Les montants sont libellés en USD par million de tokens. Le coût réel dépend donc autant du profil de requêtes que du modèle choisi.
Cette distinction compte particulièrement pour les agents, qui peuvent relire de longs historiques et générer beaucoup de sorties. Un tarif d’entrée très bas ne suffit pas à prédire la facture finale si les réponses sont longues ou si les entrées ne bénéficient pas du cache.
Le changement annoncé pour le 14 septembre concerne aussi les utilisateurs qui appellent encore deepseek-v4-pro : DeepSeek a annoncé que ces requêtes seraient dirigées vers V4.1 Flash jusqu’au lancement de V4.1 Pro. Pour les intégrateurs, le nom du point d’accès et le modèle effectivement servi ne sont donc pas nécessairement la même chose pendant cette période.
Poids ouverts, déploiement local et contrainte matérielle
La licence MIT et la disponibilité des poids rendent l’auto-hébergement possible sur le plan logiciel. Cela ne transforme pas V4.1 Flash en modèle facile à installer sur une machine personnelle.
Une démonstration locale s’est déroulée sur quatre NVIDIA DGX Spark, avec offloading vers des SSD. Dans cette configuration particulière, le débit observé était d’environ 70 tokens par seconde pour le code et 54 tokens par seconde pour les agents. Ces mesures décrivent cette installation, son logiciel et ses réglages ; elles ne définissent pas un minimum matériel universel.
La démonstration affichait aussi 296 Go pour les paramètres experts et 203 Go sur disque pour les tables d’Engram. Ces chiffres rendent visible la différence entre l’activation sélective et l’empreinte totale du déploiement. Un modèle peut n’activer qu’une fraction de ses paramètres par token tout en nécessitant une infrastructure importante pour conserver ses poids, ses tables et son cache.
Aucune configuration française spécifique ni aucun tarif en euros pour une installation locale n’est associé au modèle. Pour un projet local, il faut donc raisonner à partir de la quantification, de la mémoire disponible, de l’offloading et du runtime visé plutôt que du seul nombre de paramètres actifs.
À qui s’adresse V4.1 Flash ?
V4.1 Flash mérite l’attention de quatre catégories d’utilisateurs :
- les équipes qui construisent des agents capables de conserver un long contexte ;
- les développeurs qui veulent comparer plusieurs modèles sur leurs propres tâches de code ;
- les utilisateurs d’API sensibles au rapport entre cache, volume de sortie et période de facturation ;
- les passionnés de modèles ouverts disposant d’une infrastructure adaptée à l’inférence distribuée.
Il est moins pertinent de choisir ce modèle sur la seule promesse d’un score spectaculaire. Les résultats disponibles dessinent un profil plus intéressant : une architecture ambitieuse, une mémoire KV fortement compressée, de bonnes performances sur certains tests et une vraie difficulté pratique dès qu’on quitte l’API pour le déploiement local.
Le point essentiel est là : DeepSeek V4.1 Flash cherche à rendre plus efficace le service d’un modèle gigantesque, pas à abolir le coût matériel de sa taille totale.
