DeepSeek V4 Pro GA vs Preview : 18 à 62 % de réflexion en moins

Sur des tâches identiques, la version GA de DeepSeek V4 Pro consomme 18 % à 62 % de tokens de raisonnement en moins que la Preview qu’elle remplace. Elle corrige aussi un mode de défaillance capable de saturer toute une fenêtre de sortie de 8 192 tokens. C’est enfin la première version Pro où la désactivation du raisonnement fiabilise l’extraction en JSON strict. En revanche, elle a perdu la capacité de la Preview à répondre qu’elle ne sait pas. Nous avons comparé deepseek-v4-pro-0813 à la version Preview dans un même lot de tests, quatre jours après la GA. Nous ne publions que les volumes de tokens : la veille de nos mesures, DeepSeek avait modifié les tarifs de V4 et instauré une facturation heures pleines/heures creuses. Comparer en dollars deux grilles tarifaires mouvantes serait moins instructif que comparer les tokens. DeepSeek a lancé la version GA sans billet de blog, changelog ni communiqué de presse. Il faut donc la mesurer pour savoir ce qui a changé.

TL;DR

• La GA consomme 18 à 62 % de tokens de raisonnement en moins par tâche : 18 contre 48 pour une recherche simple.
• Le raisonnement fausse les valeurs du JSON strict sur les deux versions (2/8 correctes). La GA sans raisonnement est la seule configuration fiable observée (8/8).
• La GA corrige une défaillance de la Preview : avec thinking_budget: 16, la Preview a saturé sa fenêtre de sortie de 8 192 tokens dans 5 exécutions sur 9, contre 0 sur 9 pour la GA.
• La GA ne refuse plus proprement de répondre : face à des entités inventées, la Preview décline en 100 à 150 tokens ; la GA ne renvoie rien ou invente une réponse.

Combien de raisonnement la version GA économise-t-elle ?

Entre 18 % et 62 %, avec l’écart le plus marqué sur les tâches simples. Voici, pour nos quatre tâches standard exécutées trois fois chacune avec salage, les médianes des tokens de raisonnement et de complétion :

Les deux versions obtiennent 3/3 sur chaque tâche. Il s’agit donc d’un gain d’efficacité net, sans compromis sur la qualité. La tendance à retenir est la suivante : plus la tâche demande de profondeur, plus l’économie diminue. Elle passe de 62 % pour une recherche en une étape à 18 % pour une chaîne de cinq étapes. Quel que soit le coût des deux versions, l’écart suivra cette courbe. L’extraction structurée bénéficie du gain le plus important : sous un json_schema strict, le volume passe de 159 à 40 tokens de raisonnement, soit une division par quatre.

Le cache se comporte de la même manière sur les deux versions : toutes deux ont mis en cache 4 096 tokens d’un préfixe de 5 000 tokens, puis servi le résultat 4 secondes après l’appel d’amorçage. Ce sont les tarifs qui bougent actuellement, pas le mécanisme. DeepSeek a relevé les prix de la famille V4 et instauré une facturation heures pleines/heures creuses, avec un tarif réduit de moitié en heures creuses, à compter du 2026-08-16 à 16:00 UTC. Avant de convertir ces volumes de tokens en dollars, consultez donc la grille tarifaire de chaque version et la tranche horaire d’exécution.

La GA corrige-t-elle un problème mesurable ?

Oui, et il s’agit du mode de défaillance le plus coûteux de cette famille. Avec thinking_budget: 16, la Preview perd le fil : au lieu de raisonner brièvement puis de répondre, elle tombe dans une boucle de répétition (« I’ll output: 168. I’ll output: 168… ») jusqu’à épuiser max_tokens. Sur neuf exécutions de la même tâche en 5 étapes, la Preview a rempli la fenêtre entière de 8 192 tokens à 5 reprises. La GA ne l’a jamais fait : elle a répondu correctement à chaque fois, en 79 à 130 tokens.

Le coût de cette défaillance est précisément le problème. Une requête censée réduire la facture en plafonnant la réflexion finit par facturer 8 193 tokens de complétion, contre environ 130 pour une réponse normale. Demander au modèle de moins réfléchir multiplie alors la facture de sortie par 63. Sur la Preview, un budget de 64 tokens n’était pas plus sûr : 2 exécutions sur 3 ont produit une mauvaise réponse (183, 174). Si vous utilisez encore la Preview et pilotez les coûts avec de petits budgets de raisonnement, cette combinaison doit être abandonnée en priorité.

La désactivation du raisonnement est sans risque ici, contrairement à d’autres modèles de cette famille : Flash 0731 est passé de 6/6 à 0/6 sur des calculs en 2 étapes sans raisonnement, tandis que les deux versions Pro ont conservé un score de 3/3 sur notre chaîne en 5 étapes avec thinking: {"type": "disabled"} ou enable_thinking: false. Sur Pro, désactiver le raisonnement ne dégrade pas la précision des tâches de raisonnement et corrige l’extraction structurée, comme détaillé ci-dessous.

Le sélecteur reste sans effet observable sur les deux versions. reasoning_effort accepte low, medium, high, xhigh et max. none et minimal sont rejetés avec une erreur 400 qui indique les valeurs autorisées. Sur notre tâche en 5 étapes, les niveaux ont produit entre 76 et 122 tokens de raisonnement sur la GA, et entre 116 et 167 sur la Preview, sans tendance monotone. Comme l’a montré notre matrice inter-fournisseurs des réglages de raisonnement, DeepSeek se pilote avec la désactivation et le budget, pas avec l’enum.

Le raisonnement fausse-t-il toujours le JSON strict ?

Oui, sur les deux versions. La GA est toutefois la première version Pro à proposer une solution fiable. Nous avions repéré ce défaut sur DeepSeek V4 Flash 0731 : le JSON respecte le schéma, mais les nombres sont faux. Le problème subsiste sur Pro. Nous avons demandé aux deux versions d’extraire quatre champs d’une facture de trois lignes sous un json_schema strict. Chaque configuration a été exécutée huit fois, et nous avons contrôlé les valeurs plutôt que le schéma :

Toutes les réponses incorrectes sont parsables, respectent le schéma et contiennent des données fausses. Pour un document qui comporte clairement trois lignes, le nombre d’articles renvoyé a été 45, 22, 2026, -4, -35 ou -3864 selon les exécutions. Une réponse de la Preview a indiqué un total de -139 308 173 307 904. Une réponse de la GA a inventé une tout autre société (« MITRE ») et un total de 1000. Un validateur considère pourtant toutes ces réponses comme du JSON valide.

La consigne opérationnelle est simple. Sur la GA, désactivez le raisonnement pour l’extraction structurée : le défaut a disparu dans toutes nos exécutions. Ce seul réglage justifie fortement l’abandon de la Preview, qui restait défaillante dans 6 cas sur 8 même sans raisonnement. Ce résultat correspond au comportement de la famille mesuré sur Flash, où la désactivation du raisonnement corrigeait également toutes les exécutions. Il confirme aussi la zone sûre pour les tâches en une étape observée dans notre matrice des réglages de raisonnement : l’extraction n’a pas besoin de réflexion, et dans cette famille, la réflexion la dégrade directement.

Qu’a perdu la GA ?

La capacité à répondre « je ne sais pas ». Nous avons interrogé les modèles sur cinq entités inventées : le cours de l’action d’une société, l’effectif d’un institut, la charte d’une ville, le point de fusion d’un alliage et le lauréat d’un prix. La Preview décline proprement en 100 à 150 tokens de sortie : « I don’t have any information about a 1987 Pan-Continental Robotics Prize. » La GA adopte l’un des deux comportements suivants, tous deux inutiles :

Nous avons vérifié ce comportement sur un second chemin de requête indépendant avant publication. La Preview y a décliné les trois questions testées en 101 à 148 tokens. La GA a consommé 8 191 tokens avant de renvoyer une réponse vide pour l’une, est restée évasive pour une autre, et a affirmé un point de fusion précis (« 2,314 degrees Celsius ») pour un alliage inexistant dans le troisième cas. Le client change, pas l’asymétrie : ce comportement vient du modèle.

Pour les pipelines de recherche documentaire, la conséquence pratique est double : une question à laquelle l’index ne peut pas répondre consomme une fenêtre complète de raisonnement masqué, puis renvoie soit un message vide, soit une invention que votre validateur acceptera sans difficulté. Si vous envoyez à ce modèle les requêtes sans réponse, fixez max_tokens assez bas pour que l’échec reste visible et peu coûteux. Traitez aussi une complétion vide comme une absence de résultat, pas comme une erreur.

Quoi d’autre change lors de la migration ?

Peu de choses. La migration relève donc davantage du comportement que de l’intégration. Les deux versions ont accepté 279 000 tokens en entrée dans un seul appel et répondu à une question ciblant une information située au milieu. Elles partagent le tokenizer de la famille : un même corpus mêlant anglais, chinois et code produit exactement le même nombre de tokens sur la GA, la Preview et deepseek-v4-flash-0731. Les budgets de tokens peuvent donc être repris tels quels dans toute la famille. Les deux versions acceptent silencieusement temperature, top_p et top_k, ainsi qu’un tour assistant prérempli, la fonctionnalité de complétion par préfixe documentée par DeepSeek.

Le cache est identique jusque dans sa granularité : aucune des deux versions n’a mis en cache un préfixe de 512 tokens. Au-delà, toutes deux utilisent des pages exactes de 1 024 tokens (1 024, 2 048, 4 096) et servent les résultats 4 secondes après l’appel d’amorçage, soit la même taille de page que Flash. Dernier point côté coûts : les deux versions renvoient l’intégralité de la chaîne de raisonnement dans reasoning_content, et sa réinjection au tour suivant est gratuite. Un tour de suivi a facturé les mêmes 134 tokens d’entrée sur la GA, et 56 sur la Preview, que le raisonnement du tour précédent soit inclus ou supprimé. Contrairement aux modèles qui refacturent chaque token de raisonnement conservé, cette famille l’ignore simplement.

Sur la boucle d’outils, le bilan est neutre. Dans une boucle d’agent à deux fonctions — rechercher un incident, puis redémarrer le service associé — la GA a davantage réfléchi au premier tour (48 contre 34 tokens de raisonnement), puis moins au second (18 contre 35). Les deux versions ont choisi le bon outil 3 fois sur 3. DeepSeek positionne cette version sur les charges agentiques, mais la réflexion par étape est plus proche de l’égalité que ne le suggèrent les chiffres globaux d’efficacité. Pour un agent confronté à des impasses, la perte de la capacité à refuser compte davantage.

FAQ

Combien la version GA permet-elle d’économiser ?

En tokens, elle réduit le raisonnement de 18 à 62 % par tâche, et le divise par quatre sous un json_schema strict. Pour le coût en dollars, consultez la grille tarifaire actuelle : DeepSeek a modifié les tarifs de la famille V4 et ajouté une facturation heures pleines/heures creuses, avec un tarif réduit de moitié en heures creuses, le 2026-08-16. Un même volume de tokens n’a donc pas le même prix selon la version et l’heure.

La version GA économise-t-elle davantage sur les tâches simples ou complexes ?

Sur les tâches simples. La baisse du raisonnement atteint 62 % pour une recherche en une étape, environ 48 % pour un problème en 2 étapes et une extraction JSON, mais seulement 18 % pour une chaîne de calcul en cinq étapes. Les deux versions convergent sur les traitements profonds en plusieurs étapes. La migration devient surtout rentable pour le trafic simple et volumineux.

Faut-il encore utiliser de petits budgets de raisonnement sur DeepSeek V4 Pro ?

Pas sur la Preview. Avec thinking_budget: 16, elle est tombée dans une boucle de répétition qui a consommé toute la fenêtre de sortie de 8 192 tokens dans 5 exécutions sur 9. La facture de sortie a été multipliée par environ 63 pour une requête censée coûter moins cher. Un budget de 64 tokens a produit des réponses incorrectes. La GA a géré le même budget correctement dans 9 cas sur 9 : ce levier n’est sûr que sur la version datée.

Peut-on faire confiance au JSON strict de DeepSeek V4 Pro ?

Uniquement sur la GA et avec le raisonnement désactivé. Sur huit exécutions par configuration, les réponses conformes au schéma contenaient des nombres erronés dans 6 cas sur 8 lorsque le raisonnement était activé, sur les deux versions. Pour une facture de trois articles, le nombre de lignes renvoyé a notamment été 45, 2026 ou -3864. Avec thinking: {"type": "disabled"}, la GA a produit des valeurs correctes 8 fois sur 8. La Preview restait incorrecte 6 fois sur 8, même sans raisonnement. Validez les valeurs, pas seulement les schémas.

DeepSeek V4 Pro refuse-t-il les questions auxquelles il ne peut pas répondre ?

La Preview le fait en 100 à 150 tokens. La GA, pour l’essentiel, ne le fait pas : face à des entités inventées, elle consomme toute la fenêtre de sortie à réfléchir puis renvoie un message vide, ou fournit une réponse inventée avec assurance si la fenêtre est plus grande. Vérifiez les réponses dans vos propres sources au lieu de faire confiance à l’absence de refus, et traitez les complétions vides comme des absences de résultat.

Mesures réalisées le 2026-08-17 via la gateway Synthorai, quatre jours après l’apparition de la version GA. La Preview a été réexécutée dans le même lot pour chaque comparaison : matrice du sélecteur et de la désactivation (7 valeurs d’effort, 5 budgets, 2 paramètres de désactivation, n=3), mesure du raisonnement sur quatre tâches, sortie structurée en JSON strict, boucle de function calling en deux tours, test de cinq entités inventées avec deux tailles de fenêtre, contrôle de l’intégrité de quatre valeurs en JSON strict (n=8 par configuration), paire de mesures de facturation avec réinjection du raisonnement, paires de tests du cache implicite à deux délais et encadrement du seuil de cache, acceptation d’un contexte de 279K tokens avec recherche ciblée, comparaison du tokenizer sur un corpus fixe dans toute la famille V4, et tests d’acceptation de l’échantillonnage, du préremplissage et de n>1. Le taux d’emballement provient de neuf exécutions par version avec max_tokens: 8192. Les résultats sont exprimés en tokens plutôt qu’en dollars, car DeepSeek a modifié les tarifs de la famille V4 et instauré une facturation heures pleines/heures creuses le 2026-08-16, la veille de cette série de tests. Le comportement de refus et l’emballement ont été recoupés sur un second chemin de requête indépendant. Les tarifs et les comportements peuvent évoluer ; refaites les mesures avant de vous appuyer sur un chiffre isolé.

← Retour au blog