🚀 DeepSeek V4 : prix, perfs & limites (open source)

Pro et Flash : des usages différents

Les caractéristiques publiées indiquent environ 1 600 milliards de paramètres au total pour V4-Pro, dont 49 milliards activés par token. Pour V4-Flash, il est question d'environ 284 milliards de paramètres au total, avec 13 milliards activés par token. Les deux variantes reposeraient sur une architecture de type Mixture of Experts (MoE) : pour générer chaque token, seule une partie du réseau est sollicitée.

Du coup, les paramètres totaux ne donnent pas une estimation directe de la facture d'inférence. Le coût dépend aussi du fournisseur, du matériel, du débit, de la longueur des requêtes et de la façon dont les « experts » sont activés. Les chiffres de paramètres servent surtout à situer l'échelle du modèle, pas à calculer un devis.

Une répartition initiale des rôles pourrait ressembler à ceci :

• V4-Flash : classer des demandes, résumer des contenus, extraire des champs ou produire un premier brouillon à grande échelle ;
• V4-Pro : programmation, raisonnements en plusieurs étapes, ou documents où le contexte doit être mieux compris ;
• un modèle différent : si vous avez besoin de qualité maximale, d'une intégration très spécifique, ou de garanties contractuelles particulières.

Souvent, ce routage par niveau de difficulté est plus utile que de chercher « un seul modèle pour tout ». Une requête simple ne devrait pas coûter autant qu'une analyse juridique, ni autant qu'un agent qui intervient sur un dépôt de code.

Une fenêtre d'un million de tokens : capacité et coût réel

Les deux variantes annoncent une fenêtre de contexte d'un million de tokens. C'est énorme : ça peut permettre de traiter de très gros corpus, une partie substantielle d'un dépôt logiciel ou des historiques de conversation longs. Mais une fenêtre maximale n'implique pas que vous pouvez (ou devez) tout envoyer au modèle.

Un contexte long peut réduire le travail de découpage et simplifier certains parcours. En échange, il augmente la quantité de données transmises, la latence potentielle et, le plus souvent, le coût. Il faut aussi vérifier que la qualité reste correcte quand les éléments utiles sont dispersés dans le prompt. Un modèle qui accepte un million de tokens ne garantit pas qu'il exploite efficacement chaque passage.

DeepSeek attribue ses gains d'efficacité à une attention hybride (attention clairsemée + compression). D'après les chiffres publiés, V4-Pro utiliserait, à un million de tokens, 27 % du calcul d'inférence et 10 % du cache KV nécessaires à V3.2. Ce sont des affirmations du fournisseur : à valider sur la configuration réelle que vous utiliserez.

Des poids ouverts, avec une nuance importante

Les poids sont annoncés sous licence MIT et disponibles sur Hugging Face. Concrètement, ça permet d'envisager un hébergement indépendant, à condition d'avoir les ressources matérielles et les compétences pour le faire. Mais la licence « ouverte » ne veut pas dire, automatiquement, que tout sera transparent, sûr ou conforme pour vos usages.

Il faut distinguer trois niveaux :

• les poids du modèle ;
• le service d'API hébergé ;
• l'application que vous construisez.

Chacun a ses propres risques, coûts et obligations. Un modèle auto-hébergé peut limiter le transfert des données vers un prestataire tiers, mais il ne supprime pas les enjeux de sécurité, ni les obligations liées aux données personnelles, ni les risques liés à la chaîne d'approvisionnement logicielle.

Comparer le coût complet, pas seulement le prix affiché

Avant d'arbitrer, vérifiez sur la documentation officielle de l'API DeepSeek :

• le tarif des tokens en entrée et en sortie ;
• les éventuelles réductions pour les requêtes mises en cache ;
• le coût des modes de raisonnement et des limites de contexte ;
• les seuils de débit, les quotas et les conditions de facturation ;
• la disponibilité régionale et les modalités de traitement des données.

Le coût « utile » correspond à une tâche qui aboutit, pas à un million de tokens pris isolément. Si un modèle moins cher produit davantage d'erreurs, demande plusieurs tentatives ou mobilise plus de supervision humaine, l'économie théorique peut s'évaporer. À l'inverse, un modèle Flash bien routé dans un pipeline peut réduire nettement la dépense sur des gros volumes.

Pour estimer l'écart, partez de vos journaux : nombre de requêtes, tokens moyens en entrée et en sortie, taux d'échec, tentatives supplémentaires et coût de supervision. Puis comparez les modèles sur un jeu de cas représentatif. Un benchmark public aide à situer, mais ne remplace pas un test dans votre contexte.

Benchmarks : des signaux encourageants, pas une garantie

DeepSeek rapporte des résultats en programmation, mathématiques, raisonnement et connaissance générale. Les annonces citent notamment un bon classement sur Codeforces, des résultats sur SWE-bench et des performances en mathématiques formelles. L'entreprise indique aussi que V4-Pro se trouverait « à plusieurs mois » des meilleurs modèles de pointe.

Sur le papier, ça donne des pistes. En pratique, ce sont quand même des résultats du fournisseur, donc à confirmer indépendamment et à reproduire dans des conditions comparables. Les performances peuvent dépendre de la version utilisée, des outils disponibles, des consignes, du budget de raisonnement et des tâches retenues. Pour un usage professionnel, le bon réflexe est de mesurer ce qui compte vraiment : taux de résolution, exactitude, sécurité, temps de réponse et coût par résultat exploitable.

Même prudence avec le contexte long : une démo avec un gros document ne suffit pas. Testez la recherche d'informations précises, la gestion des contradictions entre sources, la capacité à citer correctement, et la résistance aux consignes cachées dans les documents importés. Sur un produit documentaire, une réponse « convaincante » mais mal sourcée peut coûter plus cher qu'une réponse plus lente mais fiable.

Tester l'API sans casser la production

Commencez par mettre l'appel au modèle derrière une interface interne. Ce découplage évite de disséminer le nom du fournisseur dans tout le code et facilite les comparaisons entre modèles sans réécrire vos parcours métier. Ensuite, faites tourner V4 en mode miroir ou sur un échantillon contrôlé : les utilisateurs reçoivent toujours la réponse « habituelle », pendant que vous comparez les sorties en arrière-plan.

Au minimum, mesurez :

1. la qualité sur vos cas de référence (avec une grille d'évaluation stable) ;
2. le coût par tâche terminée (y compris les reprises) ;
3. la latence médiane et les délais aux percentiles élevés ;
4. les refus, hallucinations et réponses qui ne respectent pas le format attendu ;
5. la robustesse des appels d'outils et des sorties structurées.

Prévoyez aussi un mécanisme de retour arrière. En production, un déploiement progressif est généralement plus sûr qu'un basculement global. Et surtout : une baisse de coût ne compense pas une régression silencieuse dans un parcours de paiement, un outil interne ou un système de support.

L'annonce mentionne trois modes : réponse directe, raisonnement standard et budget de raisonnement maximal. Plus de raisonnement peut améliorer certaines tâches, mais ça augmente généralement le temps de traitement et la quantité générée. Le bon réflexe : ne pas l'activer par défaut pour toutes les requêtes. Réservez-le aux cas qui en ont réellement besoin.

Exécution locale : possible ne veut pas dire économique

Les tailles annoncées sont d'environ 160 Go pour V4-Flash et 865 Go pour V4-Pro. Rien qu'avec ces ordres de grandeur, l'auto-hébergement de Flash peut déjà devenir une contrainte, même avec quantification. Pour Pro, il faut plutôt envisager un environnement multi-GPU ou une infrastructure cloud adaptée. Le coût du matériel, de l'énergie, de l'exploitation et des mises à jour doit être comparé à celui d'une API hébergée.

L'auto-hébergement peut se justifier si vous avez un besoin réel de contrôle, un volume suffisant, ou des contraintes de localisation. Mais le choisir uniquement pour gratter quelques centimes par requête est rarement une bonne affaire. Une infrastructure sous-dimensionnée augmente la latence et le risque d'incidents ; une infrastructure surdimensionnée transforme une économie variable en dépense fixe.

RGPD, localisation et risques liés au fournisseur

Les informations publiées évoquent une exécution de V4 sur des puces Huawei Ascend et soulignent l'importance de l'écosystème matériel chinois. Elles indiquent aussi que certains territoires ont restreint l'usage des services DeepSeek pour des motifs de sécurité ou de confidentialité. Le cadre applicable dépend du pays, du secteur et du type de données ; une annonce de lancement ne remplace pas une analyse juridique et sécurité.

Pour une entreprise française ou européenne, vérifiez en particulier : le lieu de traitement, les transferts hors Espace économique européen, les durées de conservation, les conditions contractuelles et les sous-traitants. Si des données personnelles sont en jeu, impliquez le délégué à la protection des données et documentez le traitement conformément au RGPD. Dans la santé, la finance, le secteur public ou la défense, des exigences supplémentaires peuvent s'ajouter.

Héberger les poids dans votre environnement réduit certains aspects du transfert vers l'API du fournisseur, mais ne supprime pas les obligations. Il faut continuer à contrôler les accès, les journaux, les données incluses dans les prompts, les vulnérabilités de l'infrastructure et les conditions de licence. Dire « les poids sont locaux » ne suffit pas à dire « le système est conforme ».

Choisir le modèle selon la tâche

V4-Flash mérite un test pour les volumes élevés et les tâches bien délimitées : classification, extraction, résumé simple, première réponse, ou enrichissement de données. Il peut aussi servir de premier niveau dans un système de routage, avec escalade vers un modèle plus fort si le score de confiance ou la complexité le justifie.

V4-Pro mérite un test quand le raisonnement, le code, ou un grand contexte font vraiment la différence, et quand les coûts des modèles actuels pèsent sur la marge. Comparez-le à vos modèles actuels sur des tâches réelles, pas seulement via un classement général.

Gardez aussi une solution alternative si votre activité dépend d'une intégration propriétaire, exige une performance maximale sur une tâche particulière, ou requiert des garanties de conformité que le fournisseur ne peut pas prouver. Un modèle fermé peut rester préférable si ses outils, son support ou son cadre contractuel réduisent le coût opérationnel global.

Décider avec un pilote borné

Un pilote utile a une durée, un périmètre et un seuil de réussite définis avant de commencer. Par exemple : comparer 500 à 1 000 requêtes représentatives, mesurer le taux de résolution et le coût complet, puis faire analyser les échecs par une personne métier. Le « bon » nombre dépend du produit, mais l'objectif reste d'éviter un test basé uniquement sur des démonstrations faciles.

Avant de démarrer, fixez trois seuils : qualité minimale acceptable, économie requise et conditions de sécurité. Si l'un des trois n'est pas atteint, on ne migre pas. Si les trois sont atteints, déployez progressivement, puis gardez un suivi après mise en production : prompts, usages et versions de modèles évoluent.

Les anciens points d'accès deepseek-chat et deepseek-reasoner étaient annoncés comme retirés le 24 juillet 2026 à 15 h 59 UTC. L'échéance étant passée, ne partez pas du principe qu'ils fonctionnent encore. Consultez la documentation officielle, identifiez les appels concernés dans votre code et testez les identifiants de modèles en cours avant toute mise à jour.