Coût de DeepSeek V4 Flash : le mode thinking corrompt le JSON

DeepSeek V4 Flash coûte $0.14 par million de tokens en entrée et $0.28 par million en sortie. Les accès au cache reviennent à $0.0028. La version 0731 réentraînée, désormais distribuée sous ce nom, présente un défaut qu’il faut contourner au niveau du routage : avec thinking activé par défaut et un json_schema strict, les champs entiers ont été corrompus dans 8 exécutions sur 13, via deux chemins de requête indépendants. La désactivation de thinking a corrigé toutes les exécutions et divisé par sept le nombre de tokens nécessaires à l’extraction. Nous avons mesuré deepseek-v4-flash-0731 dès sa sortie : corruption, dégradation plus brutale après désactivation de thinking introduite par le réentraînement, budget minimal permettant de rétablir les performances, pages de cache de 1 024 tokens et différences persistantes avec la version preview et V4 Pro.

TL;DR

• Avec thinking par défaut et un json_schema strict, deepseek-v4-flash-0731 a corrompu des champs entiers dans 8 exécutions sur 13, via deux chemins de requête. V4 Pro en a corrompu 2 sur 4 ; seule la preview n’a produit aucune erreur.
• Le réentraînement 0731 a accentué la dégradation lorsque thinking est désactivé : le score en calcul à deux étapes est passé de 6/6 à 0/6.
• Le cache sert des pages de 1 024 tokens à partir d’un seuil d’environ 1,1K tokens. Les entrées sont disponibles 0,3 seconde après l’amorçage et restent valides plus de 45 minutes.
• enable_thinking: false a corrigé toutes les sorties structurées en consommant sept fois moins de tokens. Pour les calculs à deux étapes, le budget thinking fiable est de 256.

Comment les trois versions de V4 se comparent-elles en théorie et en pratique ?

Même tokenizer, même cache, même mécanisme thinking ; prix et modes de défaillance différents. Toutes les mesures ci-dessous proviennent de tests identiques exécutés sur les trois versions. Un tiret indique que cette configuration n’a pas été testée. Les analyses publiées le jour de la sortie portent surtout sur les benchmarks ; nous nous concentrons ici sur les aspects opérationnels :

Le mode thinking corrompt-il les sorties structurées sur V4 Flash ?

Oui sur la version 0731, et l’erreur est assez discrète pour atteindre la production. Une extraction de facture à quatre champs sous json_schema strict — fournisseur, date, total et nombre d’articles — a renvoyé du JSON conforme au schéma, mais avec des nombres erronés. Le champ line_items valait successivement -1, 1, -1 et -19 alors que le document contenait clairement trois articles. Sur notre gateway, aucune des 5 exécutions avec thinking par défaut n’était correcte. Limiter le budget ne suffit pas : avec un budget de 64 tokens, la même corruption s’est produite ; même avec 256 tokens, 1 exécution sur 3 a renvoyé 670 articles. La corruption dépend de la présence de thinking, pas de sa taille. Sur un second chemin de requête indépendant, le même test a produit 3 sorties corrompues sur 8, réparties sur deux lots. Une sortie indiquait un total de 519.95 au lieu des $520.00 du document ; une autre annonçait 22 articles. Ce chemin a conservé reasoning malgré la demande de désactivation. La correction décrite ci-dessous n’a donc été validée que sur le chemin principal. Le JSON est toujours analysable et toujours conforme au schéma ; seules les valeurs sont fausses. Pour un pipeline qui fait confiance à la validation, c’est le pire mode de défaillance possible.

La correction tient sur une ligne : enable_thinking: false a produit un JSON valide et correct à chaque exécution, avec environ 44 tokens de complétion contre 328 par défaut. Les écarts au sein de la famille sont révélateurs. Testée à l’identique avec thinking activé, la preview a obtenu 4/4 sorties correctes, tandis que V4 Pro en a corrompu 2 sur 4. Le défaut touche donc plusieurs modèles V4 en mode thinking, mais surtout la version Flash réentraînée. Il ne s’agit pas non plus du bug thinking-plus-schema déjà documenté. En avril dernier, vLLM a corrigé un problème de tuyauterie où le JSON de DeepSeek arrivait dans le champ reasoning et laissait content vide. Ici, la tuyauterie fonctionne, mais les valeurs sont fausses : le problème est nettement plus grave. Tant que DeepSeek ne l’a pas corrigé, considérez thinking et les sorties structurées strictes comme incompatibles sur ces modèles. Cela n’entraîne aucun surcoût : l’extraction en une étape est précisément le type de charge où thinking peut être désactivé sans risque, pour un coût divisé par sept.

Quels contrôles thinking l’API accepte-t-elle ?

Deux mécanismes de désactivation, un budget exact et un réglage d’effort qui ne permet pas de désactiver thinking. L’interface testée accepte les valeurs low, medium, high, xhigh et max pour reasoning_effort. Contrairement à Qwen 3.8 Max, les valeurs none et minimal sont rejetées ; ce paramètre ne peut donc pas rendre le modèle silencieux à lui seul. Pour désactiver thinking, il faut utiliser enable_thinking: false ou thinking: {"type": "disabled"}. Les deux formes ont un comportement identique, avec des réponses de 9 tokens à une question triviale. thinking_budget est respecté au token près, exactement comme dans nos mesures sur Qwen 3.8 : avec une valeur de 16, le compteur indique 16. La chaîne de pensée complète est renvoyée dans reasoning_content, et le surcoût fixe du prompt reste limité à 5 tokens par appel.

Le réglage d’effort n’a produit aucun effet mesurable. Sur une tâche complexe de comptage de nombres premiers, low et high ont consommé respectivement 31 374 et 31 370 tokens de reasoning, contre 26 897 par défaut. Les trois réponses étaient correctes : il s’agit de variations ordinaires, sans plafond apparent. Les niveaux de Qwen 3.8 correspondent à des plafonds de budget cachés qui s’appliquent aux tâches longues. Sur V4 Flash, les niveaux n’ont rien changé, quelle que soit la profondeur testée. Les deux paramètres utiles sur ce modèle sont la désactivation et thinking_budget ; le réglage d’effort est purement décoratif. Ironie de la situation, la fiche du modèle publiée par DeepSeek fixe ses benchmarks d’agent à « max reasoning effort », alors que ce réglage ne se distingue pas du comportement par défaut sur l’interface que nous avons mesurée.

Quel budget thinking faut-il réellement pour un calcul à deux étapes ?

Il en faut davantage qu’avant le réentraînement, ce qui inverse nos recommandations pour le mode économique sur d’autres modèles. Sur notre lot reproductible de calculs arithmétiques à deux étapes — 1 850 caisses de 24 pièces, 75 % expédiées, soit 3 120 pièces reçues — les trois versions de V4 se comportent comme trois modèles différents :

Deux conclusions. D’abord, le réentraînement orienté agent a déplacé le calcul arithmétique vers le canal thinking : la preview s’en sort difficilement sans thinking, la version 0731 s’effondre complètement et Pro n’est pas affecté. Ensuite, le budget minimal dépend du modèle. Sur ce même lot, 16 tokens thinking suffisent à rétablir totalement Qwen 3.8 Max, tandis que 0731 en exige 256. À ce niveau, les réponses sont toutes correctes et moins coûteuses qu’avec la configuration par défaut : les complétions totalisent entre 53 et 188 tokens, contre 100 à 200 par défaut. Si vous réutilisez une configuration de budget thinking sur un autre modèle, relancez vos tests de précision. Le mécanisme est universel, mais pas le seuil.

Que fournit le cache implicite ?

Des pages de 1 024 tokens, accessibles à partir d’un seuil bas, servies rapidement et conservées longtemps. Des paires de préfixes salés ont produit des accès au cache de 1 024, 2 048, 4 096 et 7 168 tokens exactement à mesure que le prompt s’allongeait. La quantification suit donc des pages de 1 024 tokens. Le seuil se situe juste au-dessus d’une page : un prompt de 704 tokens n’a jamais été mis en cache, tandis qu’un prompt de 1 166 tokens a produit un accès de 1 024 tokens. L’entrée était disponible 0,3 seconde après l’amorçage ; aucun délai de construction particulier n’est à gérer. Elle était encore servie après 45 minutes, ce qui en fait le cache implicite le plus durable que nous ayons testé dans cette gamme de prix. L’entrée de Qwen 3.8 Max expire entre 15 et 45 minutes, avec un seuil proche de 4,3K tokens. DeepSeek facture les entrées lues depuis le cache $0.0028 par million, soit 2 % du prix hors cache, sans supplément d’écriture. La discipline habituelle d’organisation des couches reste valable : préfixe stable d’abord, contenu variable ensuite.

Les limites de contexte de 1M et de sortie de 384K sont-elles réelles ?

La fenêtre a tenu sur tous nos tests. Des codes de substitution insérés dans les prompts ont été restitués à l’identique avec 137 638, 465 238 et 838 198 tokens de prompt, en 7 à 20 secondes. C’est le rappel en contexte long le plus rapide que nous ayons mesuré dans cette gamme de prix. La limite de sortie est moins stricte que la documentation ne l’indique. DeepSeek annonce un maximum de 384K tokens en sortie, mais des requêtes avec un max_tokens de 393 217, et même de 524 288, ont été acceptées avec et sans thinking. La limite n’est donc pas contrôlée à la réception de la requête, et un budget trop élevé ne provoquera pas d’échec explicite. Définissez votre propre plafond si votre système en dépend.

Preview, 0731 et Pro : quelle version répond réellement à vos appels ?

La page tarifaire de DeepSeek n’affiche plus qu’un seul SKU : deepseek-v4-flash, avec DeepSeek-V4-Flash-0731 comme version actuelle et des tarifs inchangés. En pratique, la preview est encore servie sous son propre nom sur certaines routes. Les deux versions sont faciles à distinguer de l’extérieur, même si elles utilisent le même tokenizer. Les comptages sont identiques sur nos corpus anglais, chinois et de code ; les budgets sont donc transférables. Le test le plus fiable consiste à désactiver thinking : sur les calculs à deux étapes de nos lots, la preview obtient environ 2/6, contre 0/6 pour 0731. La preview est aussi la seule version à avoir réussi sans erreur le test de sortie structurée, avec 4/4 sorties correctes, contre 5/5 corrompues pour 0731 et 2/4 pour Pro. Si votre trafic dépend de l’un ou l’autre de ces comportements, testez l’endpoint réellement appelé plutôt que de vous fier à son nom. V4 Pro ($0.435/$0.87) résiste à la dégradation en calcul, mais pas au défaut des sorties structurées.

Dernier point pour la planification : le tokenizer commun aux trois modèles produit environ 6 à 9 % de tokens supplémentaires par rapport à Qwen 3.8 sur des corpus identiques. Pour comparer les budgets entre fournisseurs, utilisez les mesures de densité par langue, pas seulement les tarifs affichés.

FAQ

Les sorties structurées sont-elles fiables sur DeepSeek V4 Flash ?

Oui, avec thinking désactivé : le json_schema strict a été appliqué et toutes les extractions de notre lot étaient correctes. Avec thinking activé par défaut sur la version 0731, les champs entiers ont été corrompus dans 8 exécutions sur 13, via deux chemins de requête, tout en restant conformes au schéma. V4 Pro a corrompu 2 sorties sur 4 avec le même test ; seule la preview n’a produit aucune erreur. Fixez enable_thinking: false sur les routes de sortie structurée jusqu’à la correction du défaut.

Peut-on désactiver thinking sur DeepSeek V4 Flash ?

Oui, avec deux syntaxes : enable_thinking: false ou thinking: {"type": "disabled"}. Le réentraînement 0731 a cependant fragilisé ce mode sur les tâches à plusieurs étapes, avec un score de 0/6 en calcul à deux étapes. Pour toute tâche allant au-delà d’une recherche en une seule étape, utilisez un thinking_budget minimal de 256. Cette configuration a été à la fois parfaitement fiable et moins coûteuse que celle par défaut.

Quelle est la taille minimale du prompt pour le cache de V4 Flash ?

Un peu plus de 1 024 tokens : un prompt de 704 tokens n’a jamais été mis en cache, tandis qu’un prompt de 1 166 tokens a produit un accès de 1 024 tokens exactement. Les accès sont quantifiés par pages de 1 024 tokens, deviennent disponibles 0,3 seconde après l’amorçage et restent valides plus de 45 minutes. Les entrées lues depuis le cache sont facturées $0.0028 par million, soit 2 % du tarif hors cache.

Les tarifs ont-ils changé avec la version 0731 ?

Non. DeepSeek a conservé $0.14 par million de tokens en entrée hors cache, $0.0028 depuis le cache et $0.28 en sortie. La version 0731 a été intégrée au nom existant deepseek-v4-flash comme version actuelle du modèle. Le changement porte sur le comportement, pas sur le prix : dépendance plus marquée à thinking et défaut des sorties structurées décrit ci-dessus.

Mesures effectuées le 2026-08-04 via la gateway Synthorai sur deepseek-v4-flash-0731, avec des groupes de comparaison sur la preview deepseek-v4-flash et deepseek-v4-pro : lots d’extractions sous schéma strict avec journalisation de chaque payload, vérifiés sur un second chemin de requête indépendant ; tests des valeurs acceptées par les réglages et des valeurs invalides ; lot de calculs à deux étapes (n=4-6 par configuration, avec salage) et augmentation progressive du budget thinking jusqu’au rétablissement ; paires de cache salées espacées de 2,5 s avec tests du seuil, des pages, du délai de construction et de l’expiration ; tests des limites de max_tokens dans les deux modes ; comptages identiques du tokenizer sur trois corpus pour les trois modèles et Qwen 3.8 Max. Les montants en dollars correspondent aux tarifs publics de DeepSeek à la date de publication ; vérifiez-les avec le compteur de votre fournisseur. Le comportement peut évoluer à mesure que DeepSeek modifie la version 0731.

← Retour au blog