DeepSeek V4.1 Flash : la nouvelle révolution puissance-prix de l’IA chinoise
Rédigé par Gab
Sommaire
DeepSeek V4.1 Flash est présenté par @kimmonismus comme une évolution particulièrement rapide, six semaines après la mise à jour V4-Flash de juillet. Son message reprend les chiffres structurants: une architecture Causal Encoder Decoder, 552 milliards de paramètres MoE, dont 8 milliards actifs à l’entrée et 16 milliards lors de la génération, ainsi qu’un KV cache réduit à un quart de la HBM et à un huitième du stockage SSD de la génération précédente. Il ajoute que DeepSeek ferait désormais mieux que DeepSeek V4 Pro en capacité, en coût et en vitesse, et que le trafic V4 Pro doit être temporairement routé vers V4.1 Flash à partir du 14 septembre.
Cette lecture est globalement fidèle à l’annonce, mais elle insiste surtout sur le rythme des sorties et le saut produit. Le thread officiel apporte une image plus complète: les gains ne sont pas attribués à la seule architecture, mais aussi à de nouvelles méthodes de pré-entraînement et à un post-entraînement RL mené à plus grande échelle. Surtout, derrière le discours sur un modèle Flash « plus intelligent, plus rapide, plus efficient », le changement le plus opérationnel concerne la mémoire nécessaire à l’inférence longue, un sujet décisif pour les agents IA.
Le graphique partagé par @kimmonismus montre d’ailleurs une réalité moins uniforme que le récit marketing: DeepSeek V4.1 Flash est compétitif sur plusieurs évaluations, mais ne domine pas systématiquement les modèles de pointe sur Terminal-Bench.
Le post de @kimmonismus, publié le 10 septembre, s’appuie explicitement sur le thread du compte officiel de DeepSeek. Ce point est important: les chiffres, la migration des endpoints et les promesses de performances proviennent d’abord de l’éditeur du modèle, et non de l’analyste qui les a synthétisés.
Voici le post source, publié par DeepSeek quelques heures plus tôt:
Le thread officiel: une nouvelle famille, pas une simple mise à jour Flash
Dans son premier message, @deepseek_ai présente V4.1 Flash comme « the smallest model in our new architecture family », avec une compréhension visuelle native. Le positionnement est clair: Flash n’est plus seulement une déclinaison légère, mais le premier modèle d’une famille pensée pour la vitesse, le débit et le passage à l’échelle.
Le deuxième volet du thread détaille l’architecture. DeepSeek V4.1 Flash repose sur un MoE de 552 milliards de paramètres, mais ne mobilise pas l’intégralité du réseau à chaque étape. Selon DeepSeek, seulement 8 milliards de paramètres sont actifs pendant le traitement de l’entrée, puis 16 milliards pendant la génération.
Cette asymétrie constitue le cœur de l’architecture Causal Encoder Decoder. Le traitement du contexte et la production de nouveaux tokens n’ont plus le même coût et ne sollicitent pas exactement les mêmes ressources. Pour les usages qui exigent la lecture d’un contexte volumineux avant de générer une réponse relativement courte, cette séparation peut améliorer le ratio coût-performance.
Le tableau officiel compare V4.1 Flash à V4 Pro 0813, V4 Flash 0731 et plusieurs concurrents. Il indique notamment 30,0 sur Terminal-Bench 3.0, 31,2 sur Terminal-Bench 4.0 et 74,2 sur DeepSWE v1.1 pour V4.1 Flash.
Benchmarks clés de DeepSeek V4.1 Flash
| Benchmark | Score annoncé pour V4.1 Flash | Lecture |
|---|---|---|
| Terminal-Bench 3.0 | 30,0 | V4.1 Flash devance GLM 5.3 dans le tableau officiel. |
| Terminal-Bench 4.0 | 31,2 | Le modèle reste derrière GLM 5.3, affiché à 37,9. |
| DeepSWE v1.1 | 74,2 | Résultat mis en avant par DeepSeek pour les tâches d’ingénierie logicielle. |
DeepSeek affirme que ses nouvelles méthodes de pré-entraînement, combinées à un post-entraînement RL plus ambitieux, placent le modèle devant des systèmes phares, dont DeepSeek V4 Pro. Cette précision est importante par rapport au résumé de @kimmonismus: l’architecture est centrale, mais elle n’explique pas à elle seule les scores revendiqués.
La formule officielle est volontairement simple:
"Smaller KV cache. Bigger savings." @deepseek_ai
La promesse la plus concrète de V4.1 Flash n’est donc pas forcément un score brut supérieur, mais un coût mémoire sensiblement plus faible pour les charges longues et répétitives.
Le KV cache DeepSeek, le vrai levier pour les agents
Le KV cache stocke les représentations nécessaires afin d’éviter de recalculer l’intégralité du contexte à chaque token généré. Cette mémoire est essentielle aux conversations longues, aux agents qui appellent des outils, aux workflows de code, aux recherches itératives et aux systèmes qui conservent un historique étendu.
DeepSeek annonce que le cache de V4.1 Flash ne demande plus que:
- Un quart de la HBM requise par la génération précédente.
- Un huitième du stockage SSD nécessaire auparavant.
- Environ 890 octets par token de cache global, contre 3 514 octets pour V4 Flash selon le graphique publié par l’entreprise.
Le visuel officiel retrace une baisse spectaculaire depuis DeepSeek-V1: 389 120 octets par token pour V1, 48 068 pour V3.2, 3 514 pour V4 Flash, puis 890 pour V4.1 Flash.
Pour un opérateur d’agents, ce gain peut être plus structurant qu’un écart marginal sur un benchmark. Les cache hits représentent souvent une part importante de la facture lorsqu’un agent réutilise fréquemment un contexte volumineux. Compresser ce cache réduit à la fois la pression sur la mémoire GPU et la capacité de stockage nécessaire à grande échelle.
C’est précisément ce que relève @datachad dans les réponses au post de @kimmonismus:
"the kv-cache cut to a quarter of hbm is the one that matters for local inference" @datachad
L’observation est juste, mais elle doit être nuancée. Un KV cache DeepSeek plus compact rend l’auto hébergement IA plus accessible pour des infrastructures déjà équipées. Il ne transforme pas pour autant un modèle MoE de 552 milliards de paramètres en logiciel facile à exécuter sur un ordinateur personnel.
DeepSeek le reconnaît indirectement lorsqu’il évoque lui-même des déploiements d’une tout autre ampleur:
"Planning a large-scale deployment with 2,000 GPUs + a storage cluster? Let’s talk." @deepseek_ai
Le gain de cache améliore fortement l’économie de service, mais il ne fait pas disparaître la barrière matérielle liée à la taille du modèle.
Le modèle et son rapport technique sont disponibles via la page Hugging Face de DeepSeek-V4.1-Flash et le rapport technique DeepSeek V4.1. Le matériel disponible dans le thread ne permet toutefois pas de confirmer les détails avancés dans une réponse par @UnslothAI sur « 196B engram ». Cette donnée ne doit donc pas être traitée comme une spécification vérifiée sans lecture directe du rapport technique.
Une transition API qui fait de Flash le produit par défaut
L’annonce ne se limite pas à promouvoir un nouveau modèle. Elle réorganise aussi la gamme DeepSeek.
Le thread officiel indique que:
- V4 Flash et V4 Flash Vision Exp sont retirés.
- Les anciens identifiants
deepseek-v4-flashetdeepseek-v4-flash-vision-expsont temporairement redirigés vers V4.1 Flash afin de préserver la compatibilité. - À partir du 14 septembre 2026 à 04:00 UTC, les requêtes destinées à DeepSeek V4 Pro seront elles aussi routées vers V4.1 Flash.
- Cette situation doit durer jusqu’au lancement de V4.1 Pro.
- Les requêtes migrées depuis V4 Pro seront facturées aux tarifs V4.1 Flash.
Cette décision va bien au-delà d’une comparaison publicitaire. DeepSeek fait de V4.1 Flash son produit API de référence avant même l’arrivée de V4.1 Pro. Pour les équipes qui utilisent déjà l’API, la migration réduit le risque de rupture immédiate. Elle n’élimine toutefois pas le besoin de revalider les sorties, la latence, les appels d’outils, la vision native et le comportement du modèle en production.
@bygregorr résume le problème du point de vue des constructeurs d’applications:
"Six weeks between architecture families is a short runway for API builders." @bygregorr
DeepSeek répond par une compatibilité transitoire et par le routage des anciens identifiants. Il s’agit d’une réponse pragmatique en matière de continuité de service, mais pas d’une garantie d’équivalence fonctionnelle parfaite. Une application agentique sensible aux formats de sortie, aux appels d’outils ou aux politiques de raisonnement devra malgré tout être retestée.
Le tableau tarifaire de DeepSeek affiche des prix distincts selon les heures, par million de tokens. Hors pointe, il indique 0,003 dollar pour l’entrée avec cache, 0,15 dollar pour l’entrée sans cache et 0,6 dollar pour la sortie. Aux heures de pointe, ces montants passent respectivement à 0,006, 0,3 et 1,2 dollar.
DeepSeek précise que les tarifs hors pointe représentent 50 % des tarifs de pointe. Cette grille renforce l’intérêt économique des charges flexibles, notamment les traitements batch, les évaluations automatisées ou les tâches agentiques non synchrones.
Un post tiers de @ns123abc, mentionné dans la discussion élargie, évoque une exécution environ 86 fois moins chère par million de tokens et un débit de 420 à 507 tokens par seconde. Ces chiffres peuvent nourrir le débat, mais ils ne figurent pas dans le thread officiel fourni. Ils doivent donc être considérés comme des affirmations tierces, dépendantes du matériel, de la longueur de contexte, du niveau de quantification et de la charge testée, et non comme des données DeepSeek confirmées.
Terminal-Bench: une domination annoncée, mais pas un verdict universel
DeepSeek affirme que des « tests by multiple parties » placent V4.1 Flash devant V4 Pro sur la performance, le coût, la vitesse et le temps d’exécution total. Cette affirmation peut étayer son positionnement comparatif, mais le thread ne documente pas suffisamment les protocoles, les fournisseurs, les réglages d’inférence ou la composition exacte de ces tests.
Le principal point de friction concerne Terminal-Bench, un benchmark particulièrement suivi pour évaluer les capacités agentiques sur ordinateur et en programmation.
@Greg_GL_87 relève une incohérence apparente entre deux versions de l’évaluation:
"the table has it losing Terminal-Bench 4.0 to GLM 5.3, 31.2 vs 37.9, but winning 3.0. weird split for two versions of the same eval" @Greg_GL_87
Cette critique n’a pas reçu de réponse dans le fil. Elle est précise et importante. Le tableau officiel affiche bien 31,2 pour V4.1 Flash sur Terminal-Bench 4.0, tandis que @Greg_GL_87 compare ce score aux 37,9 de GLM 5.3. Dans le même temps, V4.1 Flash obtient 30,0 sur Terminal-Bench 3.0 et y devance GLM 5.3.
Un modèle peut battre V4 Pro sur plusieurs indicateurs sans être le meilleur choix pour toutes les tâches de code agentique. Sans protocole détaillé, il reste impossible de déterminer si l’écart entre Terminal-Bench 3.0 et 4.0 provient des tâches, des environnements, des paramètres de test ou d’un autre facteur méthodologique.
@kryptosopus formule une objection plus large en comparant V4.1 Flash à Claude Opus 5:
"Native vision baked into the smallest model but it still loses Terminal-Bench to Opus5 by 13 points. Flash is clearly the "cheap and fast" play, not the frontier one. The scaling line at the bottom is the real tell here" @kryptosopus
Cette lecture ne contredit pas entièrement celle de DeepSeek. V4.1 Flash peut être meilleur que DeepSeek V4 Pro selon plusieurs mesures retenues par l’entreprise, tout en restant derrière Opus 5 sur un benchmark agentique donné. Le problème apparaît lorsqu’une amélioration relative au sein d’une gamme est transformée en affirmation de suprématie globale.
Réactions: enthousiasme open source, prudence produit et questions sur la future version Pro
Les réponses au thread officiel sont largement enthousiastes quant à l’ouverture du modèle et à son intégration rapide. @MrAhmadAwais indique par exemple que V4.1 Flash est déjà disponible dans son offre CommandCodeAI. @Presidentlin salue surtout la contribution de DeepSeek à l’écosystème open source:
"Thank you again for moving Open Source forward" "As always oblig" "How high will your ceiling go?!!" @Presidentlin
La réponse était accompagnée d’une planche de manga qui matérialise ce mélange de fascination et de défi face à la cadence de DeepSeek.
@ParthM1001, de son côté, résume l’ambiance avec une métaphore culinaire:
"The whale has cooked something beautiful again." @ParthM1001
Les réponses au post de @kimmonismus sont davantage orientées vers le positionnement de la gamme. @elshayib_ estime que l’ancienne version Pro perd son sens:
"V4 pro kinda irrelevant now" @elshayib_
@kimmonismus lui répond:
"yeah, just waiting for another release of the pro version" @kimmonismus
Cette réponse est cohérente avec l’annonce officielle: V4 Pro est effectivement en phase de retrait temporaire, mais DeepSeek annonce explicitement une future V4.1 Pro. Conclure que toute la gamme Pro est définitivement inutile va donc au-delà des faits établis.
La même interrogation apparaît chez @RimasXYZ:
"if flash now beats v4-pro on capability, cost and speed, what is left for v4.1-pro to win on?" @RimasXYZ
Le thread ne répond pas à cette question. Il laisse entière la définition du futur produit Pro: meilleure qualité sur les tâches difficiles, capacités de raisonnement renforcées, contexte plus long, fiabilité agentique, ou autre compromis de performance.
Architecture Causal Encoder Decoder: ce qui change techniquement
La réaction de @austinyuhao, « welcome back encoder-decoder », est courte mais pertinente. DeepSeek ne propose pas seulement une compression de cache, il réintroduit une séparation architecturale entre le chemin d’encodage causal et le décodeur.
"welcome back encoder-decoder" @austinyuhao
Le schéma partagé dans la réponse montre un Causal Encoder et un Decoder de vingt couches chacun, pour un réseau total de quarante couches. Il fait aussi apparaître les composants MoE, CSA2, SWA, Vision Encoder, Text Embedding, Engram, DSpark et Candidate Pool.
Cette organisation explique pourquoi les sujets de l’inférence multimodale et du KV cache sont liés. DeepSeek cherche à prendre en charge nativement la vision tout en maintenant un coût raisonnable sur les longues séquences. La promesse est particulièrement attractive pour les agents qui doivent lire des documents, analyser des interfaces, manipuler du code et conserver une mémoire de travail persistante.
FAQ sur DeepSeek V4.1 Flash
Combien de paramètres sont actifs dans DeepSeek V4.1 Flash?
DeepSeek annonce un modèle MoE de 552 milliards de paramètres. Seuls 8 milliards de paramètres seraient actifs pendant le traitement de l’entrée, puis 16 milliards pendant la génération.
Pourquoi le KV cache DeepSeek est-il important pour les agents IA?
Le KV cache permet de conserver les représentations du contexte déjà traité. Un cache plus compact réduit les besoins en mémoire GPU et en stockage, ce qui peut diminuer le coût des conversations longues, des agents avec appels d’outils et des workflows réutilisant fréquemment le même contexte.
Que se passe-t-il pour les utilisateurs de DeepSeek V4 Pro?
À partir du 14 septembre 2026 à 04:00 UTC, les requêtes destinées à DeepSeek V4 Pro doivent être temporairement routées vers V4.1 Flash, jusqu’au lancement de V4.1 Pro. Les équipes concernées doivent revalider leurs usages en production, même si la compatibilité d’API est maintenue durant la transition.
Ce qu’il faut retenir
DeepSeek V4.1 Flash n’est pas seulement une mise à jour rapide supplémentaire. L’annonce combine une nouvelle architecture asymétrique, une activation MoE différenciée entre entrée et génération, une compression forte du KV cache, des tarifs API agressifs et une migration concrète du trafic depuis V4 Pro.
Pour les professionnels, les implications sont claires:
- Le KV cache réduit peut améliorer sensiblement le coût des agents à contexte long.
- L’auto hébergement IA devient plus réaliste pour des opérateurs disposant déjà d’une infrastructure conséquente.
- La redirection de V4 Pro vers Flash impose une phase de validation applicative.
- Les performances revendiquées face à V4 Pro ne suffisent pas à établir une domination sur tous les benchmarks agentiques.
- Terminal-Bench reste un point de vigilance, en particulier face à la divergence entre les versions 3.0 et 4.0 relevée par @Greg_GL_87.
Le thread laisse donc plusieurs questions ouvertes: quels protocoles justifient les « tests by multiple parties », pourquoi les résultats divergent-ils selon la version de Terminal-Bench, quel sera le rôle distinctif de V4.1 Pro, et quelle configuration matérielle rend réellement l’auto hébergement pratique?
La conclusion la plus raisonnable est aussi la plus utile: V4.1 Flash semble constituer une avancée majeure en matière d’efficience et de déploiement, mais il ne prouve pas encore qu’un modèle Flash a éliminé les compromis propres aux modèles frontière.