DeepSeek V4.1 Flash : API bon marché, poids ouverts massifs

DeepSeek V4.1 Flash associe des prix d’API bas à un très grand modèle à poids ouverts. Sorti le 10 septembre 2026, il active 8 milliards de paramètres pour traiter l’entrée et 16 milliards pour générer la sortie, mais son réseau principal en contient à lui seul 552 milliards. Le progrès concerne le calcul de chaque phase, pas un petit téléchargement pour votre portable. [1] [2]

Que signifie réellement « 8B actifs » ?

Le nombre de paramètres actifs décrit la partie du modèle utilisée pour un token, pas l’ensemble qu’il faut stocker. V4.1 Flash est un modèle à mélange d’experts, qui sélectionne certaines parties de son réseau pour le calcul. La nouvelle architecture de DeepSeek sépare aussi le traitement de l’entrée de la génération de sortie, avec des nombres de paramètres actifs différents. [2]

Le traitement de l’entrée s’appelle généralement prefill : le modèle lit le prompt avant de répondre. La génération est le decode : il produit les tokens successivement. Le rapport technique de DeepSeek décrit une architecture encodeur-décodeur causale, avec 20 couches pour chaque partie. Les valeurs annoncées sont 8B paramètres actifs en prefill et 16B en decode ; B désigne ici des milliards. [2]

C’est pourquoi faire la moyenne et parler d’un « modèle de 12B » serait trompeur. Un long prompt suivi d’une réponse courte répartit le travail différemment d’une entrée brève suivie d’un gros correctif. L’architecture attribue des calculs différents à ces phases, mais aucune ne transforme le modèle complet en petit téléchargement pour une machine grand public.

Le détail du stockage le montre. DeepSeek annonce un réseau principal de 552B paramètres, plus environ 196B de mémoire conditionnelle Engram, un composant de consultation. La recette de déploiement du projet vLLM compte aussi le modèle de génération de brouillons DSpark et d’autres tenseurs. L’artefact complet Hugging Face affiche actuellement 763 milliards de paramètres. Ces chiffres comptent différentes parties de la même version. [2] [3]

La discussion du lancement sur r/LocalLLaMA, le 10 septembre, associait l’enthousiasme aux questions d’architecture et de déploiement. C’est la tension utile : le modèle peut calculer sélectivement tout en restant très volumineux à héberger. [5]

Pourquoi un cache de contexte plus petit compte-t-il ?

Réduire le cache diminue l’un des besoins de mémoire des longues conversations. Le cache KV conserve les informations d’attention des tokens déjà traités pour les réutiliser pendant la génération. Cette mémoire est distincte de celle qui stocke les poids du modèle.

Le rapport de DeepSeek donne 890 octets par token pour le cache KV global, soit environ un quart de celui de V4 Flash. L’annonce revendique séparément un quart des besoins en mémoire à haute bande passante et un huitième des besoins en SSD pour le cache KV, par rapport à la génération précédente. Ces mesures sont liées, mais ne décrivent pas de façon interchangeable toute la mémoire du modèle. [1] [2]

Cela compte pour les agents de programmation, car une tâche peut accumuler le contenu du dépôt, les sorties d’outils et les modifications successives. Un cache plus petit réduit le coût de maintien de ce contexte. Il ne prouve pas que le modèle se souviendra correctement de chaque dépendance ou choisira un bon correctif. La capacité publiée est d’environ un million de tokens ; la recette de service précise 1 048 576. [2] [3]

Je lirais donc ce changement comme un progrès d’infrastructure. Il facilite l’exploitation du contexte long, tandis que la qualité d’une longue tâche de programmation reste une autre question.

Les progrès en programmation sont-ils vérifiés indépendamment ?

Cette comparaison vient de l’évaluation de DeepSeek, pas d’un test indépendant de cette publication. Sa table du modèle ajusté aux instructions montre des progrès nets face à V4 Flash sur plusieurs benchmarks d’agents. Le rapprochement utile porte sur ce prédécesseur dans les conditions déclarées, pas sur des scores d’un autre fournisseur obtenus autrement.

DeepSeek annonce un passage de 54,4 % à 74,2 % sur DeepSWE v1.1, soit 19,8 points de pourcentage. Sa fiche de modèle indique reasoning_effort=100, temperature=1.0 et top_p=0.95. Les évaluations d’agents de code utilisent DeepSeek Harness Minimal avec un contexte d’un million de tokens ; DeepSWE utilise mini-SWE. Ces conditions sont nécessaires pour interpréter ces chiffres. [2]

À mon sens, cette sortie mérite une nouvelle évaluation de programmation. Ma comparaison précédente de V4 Flash concerne l’ancien modèle et ne permet pas de conclure sur V4.1. Je relancerais des tâches représentatives avec les mêmes tests et critères de revue avant d’appliquer au quotidien un ancien avis négatif ou un nouveau score de lancement.

Combien coûte DeepSeek V4.1 Flash par API ?

La table actuelle utilise l’identifiant deepseek-flash et distingue heures pleines et creuses. Au 14 septembre 2026, l’entrée non mise en cache coûte 0,15 dollar par million de tokens en heures creuses et 0,30 dollar en heures pleines. La sortie coûte respectivement 0,60 et 1,20 dollar. L’entrée en cache bénéficie d’un tarif propre plus bas. [4]

Les tarifs des heures pleines sont deux fois plus élevés. Une comparaison de prix doit préciser la plage horaire et la catégorie de cache, pas seulement le chiffre le plus bas. Le coût total dépend aussi du raisonnement, des sorties d’outils et des nouvelles tentatives. Le faible prix par token de sortie est séduisant, mais je mesurerais le coût d’un résultat que l’on peut examiner.

Peut-on exécuter les poids ouverts localement ?

Les poids sont disponibles sous licence MIT, mais le déploiement documenté demande du matériel serveur conséquent. La recette vLLM décrit un checkpoint d’environ 511 Go et un budget minimal de mémoire GPU de 614 Go. Elle cite notamment un plateau GB200 NVL4 et un nœud de huit GPU H200. Ce sont les exigences de cette recette, pas un minimum universel pour toute implémentation future. [2] [3]

C’est pourquoi je séparerais le choix de l’API de celui de l’hébergement. Un ensemble fixe de tâches par API permet de tester l’utilité du modèle. Héberger les poids exige en plus un plan d’exploitation pour le modèle, la mémoire, l’environnement et la capacité. Les poids ouverts donnent cette option aux opérateurs, sans supprimer le travail d’exploitation.

Pour un développeur individuel, je commencerais par une comparaison limitée via l’API avec le modèle déjà utilisé. Pour une équipe d’infrastructure, je partirais de la recette et mesurerais les longueurs réelles des prompts et sorties. Le chiffre de 8B devient utile une fois que vous savez quelle phase de votre travail il décrit.