DeepSeek V4 : pourquoi ce modèle open weights peut vraiment bousculer les modèles fermés

DeepSeek vient de publier V4, et pour une fois je trouve qu'on peut difficilement le réduire à "encore un modèle de plus".

Pas parce que les scores annoncés frôlent ceux des meilleurs modèles fermés. Ça, on l'a déjà vu. Le vrai sujet, c'est la combinaison : open weights sous licence MIT, 1M de contexte par défaut, architecture MoE pensée pour rendre ce contexte réellement exploitable, optimisations explicites pour les agents et le code, et une API compatible OpenAI et Anthropic.

Autrement dit, une brique qui ressemble à du frontier, qui s'intègre comme du fermé, et qui s'opère comme de l'open source. Ce mélange est nouveau, et il met une vraie pression sur le marché. Pas une pression marketing — une pression d'architecture et de prix.

Voilà pourquoi, à mon sens, V4 mérite qu'on s'y arrête sérieusement.

1. DeepSeek V4 : ce qui vient vraiment d'être annoncé

D'abord, les faits, sans habillage.

DeepSeek a publié deux modèles dans la famille V4, tous deux MoE :

DeepSeek-V4-Pro : 1,6 trillion de paramètres au total, 49 milliards actifs par token.
DeepSeek-V4-Flash : 284 milliards de paramètres au total, 13 milliards actifs par token.

Les deux supportent nativement un contexte de 1M tokens, avec un max output de 384K, des modes Thinking / Non-Thinking, du JSON output, des tool calls, du chat prefix completion et du FIM completion en non-thinking. Les poids sont disponibles sur Hugging Face sous licence MIT, et l'API DeepSeek expose les nouveaux noms deepseek-v4-pro et deepseek-v4-flash à la même base URL qu'avant. Côté intégration, le service reste compatible avec les ChatCompletions OpenAI et les APIs Anthropic, ce qui veut dire qu'on peut le brancher dans la plupart des SDK existants sans toucher à grand chose.

DeepSeek annonce aussi explicitement le support d'agents comme Claude Code, OpenClaw et OpenCode, et le remplacement progressif des anciens endpoints deepseek-chat et deepseek-reasoner.

Sur le papier, c'est cohérent : un modèle "haut de gamme" pour le raisonnement long et les tâches agents, et un modèle "rapide / pas cher" pour le reste. Avec, dans les deux cas, le même argument central — le 1M de contexte n'est pas une promesse marketing, mais un terrain de jeu pour les agents.

C'est précisément là que le travail technique devient intéressant.

2. Le point technique important : rendre le contexte 1M exploitable

Un million de tokens de contexte n'a aucun intérêt si la latence explose et si la facture KV cache devient ingérable. Comme l'écrit le blog Hugging Face de DeepSeek, "a 1M context window is just capacity, not performance". La vraie question n'est pas "jusqu'où peut-on faire grimper la fenêtre", mais "à quel coût peut-on l'utiliser".

V4 attaque ce problème par l'architecture, pas par l'astuce d'inférence.

CSA + HCA : compresser l'attention au lieu de juste agrandir la fenêtre

DeepSeek décrit V4 comme une Hybrid Attention Architecture qui combine deux mécanismes :

Compressed Sparse Attention (CSA), qui compresse les KV entries d'environ 4x.
Heavily Compressed Attention (HCA), beaucoup plus agressive, qui compresse d'environ 128x.
Les couches CSA et HCA sont alternées dans la pile, ce qui permet de garder de la précision là où il en faut et d'économiser massivement ailleurs.
Une sliding window locale (de l'ordre de 128 tokens dans l'implémentation vLLM) préserve la localité du contexte récent.
Le tout s'inscrit dans la lignée du travail de DeepSeek sur la DeepSeek Sparse Attention (DSA) présenté dans V3.2.

L'idée centrale est moins de "voir tout le contexte tout le temps" que de faire varier la résolution d'attention selon les couches et de payer le prix d'une attention dense uniquement là où c'est utile.

Pourquoi ça compte pour les agents

C'est là que les chiffres deviennent parlants.

DeepSeek annonce que, à 1M tokens, V4-Pro requiert environ 27 % des FLOPs single-token et 10 % du KV cache par rapport à V3.2. Pour V4-Flash, on tombe à 10 % des FLOPs et 7 % du KV cache. NVIDIA, de son côté, parle d'environ 73 % de réduction des FLOPs d'inférence par token et 90 % de réduction de la pression KV cache vs V3.2.

Ces ordres de grandeur sont confirmés côté servings : selon le blog vLLM, le KV cache bf16 pour une séquence à 1M tokens descend autour de 9,62 GiB, contre environ 83,9 GiB pour une stack type V3.2 à 61 couches. En fp8 ou fp4, on baisse encore. Pour les agents qui tiennent un contexte vraiment long — historique de tool calls, gros codebase indexé, traces de raisonnement préservées — c'est la différence entre "théoriquement possible" et "rentable en production".

Et il faut le dire clairement : ce travail-là est plus important que les benchmarks. Il rend exploitable une capacité que beaucoup de modèles annoncent sans pouvoir vraiment la servir à un coût décent.

3. Benchmarks : très fort, mais pas magique

Passons aux scores, en gardant la tête froide. Tout ce qui suit vient des tableaux DeepSeek / Hugging Face — utiles, mais pas une vérité indépendante absolue.

Là où DeepSeek V4-Pro-Max impressionne

Quelques chiffres marquants annoncés par DeepSeek :

LiveCodeBench : 93,5
Codeforces : 3 206
SWE Verified : 80,6 %
SWE Pro : 55,4
Terminal Bench 2.0 : 67,9
MCPAtlas Public : 73,6
Toolathlon : 51,8
MRCR 1M : 83,5
CorpusQA 1M : 62,0
MMLU-Pro : 87,5
GPQA Diamond : 90,1
SimpleQA Verified : 57,9

Le profil est assez net. V4-Pro brille particulièrement sur le code agentique, le long contexte exploité réellement (MRCR 1M, CorpusQA 1M) et les workflows à outils (MCPAtlas, Toolathlon). Le blog Hugging Face mentionne aussi que sur MRCR 8-needle, le modèle reste au-dessus de 0,82 jusqu'à 256K tokens et descend à 0,59 à 1M — donc un peu de dégradation, mais sans effondrement.

Côté évaluations externes, des plateformes comme Vals AI le placent — selon ce qui est relayé par Xinhua et VentureBeat — en #1 open weights sur Vibe Code Bench, sur SWE-bench et sur IOI, et #2 open weights sur Terminal-Bench 2.0. À prendre comme indication de tendance, pas comme certitude absolue.

Ce qu'il faut nuancer

Maintenant, là où je trouve qu'il faut éviter la facilité.

V4 n'est pas "le meilleur partout". Sur plusieurs axes — qualité moyenne globale, raisonnement encyclopédique très large, intégration produit, sécurité perçue — Gemini, Claude et GPT gardent des avances mesurables. Sur certains usages grand public ou enterprise, ces avances sont même décisives.

Le titre tentant — "DeepSeek bat tout le monde" — serait à la fois faux et contre-productif. La formulation crédible, c'est plutôt : DeepSeek V4 met une pression sérieuse sur les modèles fermés, en particulier sur le triptyque agents + code + long contexte. Et c'est déjà beaucoup.

C'est sur ce triptyque que la suite devient vraiment intéressante : une fois la performance "suffisamment bonne", le facteur déterminant devient l'économie d'inférence.

4. Le vrai choc : l'économie d'inférence

DeepSeek a publié une grille tarifaire qui explique, à elle seule, pourquoi tout le monde regarde V4 de très près.

Pour 1M tokens :

DeepSeek-V4-Pro : input cache miss à 1,74 $, input cache hit à 0,145 $, output à 3,48 $.
DeepSeek-V4-Flash : input cache miss à 0,14 $, input cache hit à 0,028 $, output à 0,28 $.

Pour un usage typique d'agent — 1M tokens d'input cache miss + 1M tokens d'output sur V4-Pro — on tombe autour de 5,22 $ par run. VentureBeat compare ce chiffre aux modèles premium fermés qui tournent plusieurs fois plus cher sur le même format. Cette comparaison reste à manier avec prudence — les conditions de cache, de tokenisation et de remises entreprise varient — mais l'ordre de grandeur est clair.

Le vrai point n'est pas "DeepSeek est le moins cher". C'est plus subtil :

DeepSeek n'a pas besoin de gagner tous les benchmarks pour modifier le calcul économique.
Sur des workloads agents qui consomment des dizaines ou des centaines de millions de tokens par mois, un facteur 2 à 5 sur le coût change ce qu'il devient rationnel de construire.
Le cache hit input à 0,028 $ sur Flash est particulièrement intéressant pour des architectures où le même contexte (codebase, doc, historique) est rejoué à chaque tour.

Autrement dit, V4 ne se contente pas d'arriver "moins cher". Il arrive avec un profil qui rend économiquement viables des architectures qui restaient marginales jusqu'ici : agents qui boucle longtemps, ré-exécutions massives, multi-agents, background processing à grande échelle.

C'est précisément là où les modèles fermés vont devoir répondre — par la baisse de prix, par des paliers de cache plus généreux, ou par une différenciation produit plus forte.

5. Pourquoi c'est important pour les devs, agents et workflows IA

Concrètement, qu'est-ce que ça change si vous construisez de l'IA appliquée aujourd'hui ?

Pour les agents longue durée. Un agent qui lit un repo, planifie, appelle des outils, corrige et recommence sur plusieurs centaines d'actions a besoin d'un contexte stable, d'un coût par tour acceptable et d'une attention qui ne s'effondre pas au-delà de quelques dizaines de milliers de tokens. V4 vise précisément ce profil, avec en plus un mécanisme d'interleaved thinking across tool calls qui préserve le raisonnement à travers les appels d'outils — décrit dans le blog Hugging Face. Le tout repose sur un schéma de tool calls avec un token spécial DSML et un format XML conçu pour réduire les erreurs d'échappement, qui sont une plaie classique sur les modèles à JSON brut.

Pour les codebases volumineuses. Pouvoir charger plusieurs fichiers, leur historique, des tests et des specs dans le même contexte — sans payer une fortune en KV cache — change ce qu'on peut faire en assistance code, refactoring guidé ou revue automatisée. Ce n'est plus "résume cette fonction", c'est "comprends ce module dans son contexte".

Pour les workflows OpenAI-compatible et Anthropic-compatible. L'API expose les deux interfaces. Donc un produit déjà construit autour de l'écosystème OpenAI ou Anthropic peut tester DeepSeek sans réécriture lourde. Pour les équipes qui veulent garder une couche d'abstraction et faire jouer la concurrence, c'est très important.

Pour la souveraineté technique. Pouvoir, à terme, ne pas dépendre uniquement d'une poignée de fournisseurs fermés est un avantage stratégique réel — pour des questions de prix, de gouvernance, de continuité de service et de contraintes réglementaires.

Pour le self-host. V4 est servable via vLLM et SGLang, et NVIDIA fournit des recipes officielles avec NIM, du multinode et de la disaggregation prefill/decode. Les exemples vLLM mentionnent, par exemple, Pro sur 8xB200/B300 et Flash sur 4xB200/B300. NVIDIA évoque aussi plus de 150 tokens/sec/user sur GB200 NVL72 en out-of-the-box. C'est faisable, mais ce n'est clairement pas du laptop.

D'où une distinction importante à garder en tête : open weights ≠ facile à faire tourner sur une machine perso. C'est une nuance que beaucoup d'articles évitent, et qui mérite d'être posée explicitement. Avoir les poids et la licence, c'est avoir l'option de self-host, de fine-tuner, de quantizer, d'auditer. Ce n'est pas un raccourci magique vers une infra légère.

6. Conclusion : l'open source ne rattrape pas seulement en performance, il attaque par l'efficacité

Les modèles fermés ne sont pas morts. Ils gardent des avantages réels, et ils continueront à dominer plusieurs cas d'usage.

Mais l'angle a changé.

Pendant longtemps, le choix entre fermé et "ouvert" se résumait à un arbitrage performance contre liberté. Avec V4, l'arbitrage devient plus complexe. Le marché va se jouer de plus en plus sur quatre axes simultanés : performance × coût × contrôle × intégration. Et sur ces quatre axes, les modèles ouverts deviennent crédibles dans plus de cellules du tableau qu'avant.

DeepSeek V4 est, au fond, un signal. L'écart entre fermé et ouvert n'est plus une évidence sur les usages agents et code. Il devient une décision produit, qui dépend de ce qu'on optimise : la qualité moyenne brute, ou le rapport qualité / coût / liberté de déploiement.

La vraie question n'est plus "est-ce que les modèles ouverts vont rattraper les fermés ?". C'est : faut-il continuer à tout construire sur des modèles fermés par défaut, alors que les options ouvertes deviennent assez bonnes pour être l'épine dorsale d'un produit ?

Sur les 12 prochains mois, c'est ce reflexe par défaut qui va probablement bouger. Pas pour tout le monde, pas partout. Mais suffisamment pour que les modèles fermés sentent qu'ils ne sont plus seuls à pouvoir tenir un agent sérieux.