DeepSeek V4.1 Flash 1017 : 30/30 en code sans raisonnement

Sans raisonnement, DeepSeek V4.1 Flash 1017 a résolu nos 30 petites tâches de modification de code avec tests, pour $0.0042 par tâche résolue. C’est 36% de moins qu’avec le niveau de raisonnement par défaut ($0.0066). Même privé de l’outil d’exécution des tests, il en a résolu 28 sur 30. En revanche, désactiver le raisonnement ne convient pas aux questions dont il faut calculer la réponse en un seul appel, comme les problèmes de dénombrement sous contraintes : le modèle n’a donné que 11 bonnes réponses sur 39. Le raisonnement est le travail interne du modèle avant sa réponse, facturé en tokens de sortie. Le paramètre reasoning_effort en règle l’intensité (low, high par défaut, ou max), et thinking: {"type": "disabled"} le désactive. Nous avons mesuré tous les réglages deux jours après la sortie du 17 octobre, au tarif public de pointe de DeepSeek : $0.30 par million de tokens d’entrée et $1.20 par million de tokens de sortie.

TL;DR

• DeepSeek V4.1 Flash 1017 coûte $0.30/$1.20 par million de tokens en heures de pointe, et moitié moins en heures creuses ; les heures de pointe représentent 35 des 168 heures de la semaine.
• Sur de petites tâches de code exécutées en mode agent, DeepSeek V4.1 Flash 1017 a obtenu 30 sur 30 avec tous les réglages : $0.0042 par tâche sans raisonnement, $0.0066 avec high par défaut, $0.0099 avec max.
• Sur 13 tâches de raisonnement en un seul appel, le modèle a obtenu 11 sur 39 sans raisonnement, contre 39 sur 39 à chacun des niveaux de raisonnement.
• DeepSeek V4.1 Flash 1017 a retrouvé une information cachée à trois positions dans un prompt de 1,001,531 tokens.

Qu’est-ce qui a changé le 17 octobre, et combien coûte 1017 ?

DeepSeek V4.1 Flash 1017 a remplacé le V4.1 Flash de septembre sur l’API de DeepSeek, au même prix. Dans sa note de version, DeepSeek annonce « une exécution plus rapide des tâches et des sorties plus courtes qu’avec la version précédente ». Un graphique compare le taux de réussite sur DeepSWE v1.1, qui consiste à corriger des problèmes dans de vrais dépôts de code, au coût par tâche. DeepSeek attribue les progrès sur les projets de bout en bout à « l’apprentissage par renforcement avec auto-évaluation ». Les poids sont ouverts : vous pouvez les télécharger sur Hugging Face et héberger le modèle vous-même. Pour le déploiement, voici ce qu’il faut savoir sur le nom, le prix, les heures de pointe et le tokenizer :

• Sur l’API de DeepSeek, le modèle derrière votre identifiant a changé. L’identifiant de DeepSeek est deepseek-flash, et sa page de tarifs indique que les anciens noms deepseek-v4-flash et deepseek-v4-flash-vision-exp utilisent désormais 1017. Un code qui appelle directement DeepSeek utilise donc un nouveau modèle, même sans aucune modification : relancez vos évaluations. Synthorai a conservé les anciennes versions derrière les anciens identifiants, comme l’explique la dernière section.
• Le prix n’a pas changé. Les prix sont en dollars par million de tokens. Un accès au cache correspond à une entrée déjà reçue par le serveur lors d’une requête précédente, par exemple un prompt système répété :

• La majeure partie de la semaine est en heures creuses. Les heures de pointe vont de 01:00 à 04:00 et de 06:00 à 10:00 UTC en semaine (de 09:00 à 12:00 et de 14:00 à 18:00, heure de Pékin). Les week-ends et jours fériés chinois sont entièrement en heures creuses.
• Le tokenizer n’a pas changé. Les mêmes échantillons en anglais, en chinois, en Python et en JSON ont donné exactement les mêmes nombres de tokens sur 1017, le V4.1 Flash de septembre et V4 Pro. Les budgets de tokens restent donc valables.

Dans le classement Artificial Analysis, consulté le 19 octobre, 1017 obtient 45.1 avec son réglage maximal, contre 39.5 pour la version de septembre. Cet indice regroupe des benchmarks d’agents, de code, de connaissances et de sciences qu’Artificial Analysis exécute lui-même. DeepSeek a aussi ouvert des API Search et Fetch sur sa propre plateforme. Elles renvoient respectivement les résultats web d’une recherche et le contenu d’une URL, chacune à $0.75 pour 1,000 appels. Les appels depuis Claude Code, Codex et DeepSeek Harness avec une clé API DeepSeek sont gratuits jusqu’au 31 octobre 2026 à 16:00 UTC. Ces conditions ne concernent que l’API de DeepSeek. Nous n’avons testé ni ces API, ni les performances annoncées sur les grands projets. La suite de cet article porte uniquement sur les mesures de 1017, selon le niveau de raisonnement.

Quel niveau choisir pour raisonner en un seul appel ?

low suffit sur nos tâches ; désactiver le raisonnement ne suffit pas. Nous avons soumis à 1017 notre jeu habituel de 13 tâches : dénombrement sous contraintes, application d’une règle 200 fois, problème du sac à dos, arithmétique modulaire et problèmes similaires ayant une réponse vérifiable. Chaque tâche a été exécutée trois fois par réglage, avec une seule requête par exécution. Le coût par bonne réponse correspond à la dépense totale divisée par le nombre de bonnes réponses, au tarif public de pointe :

Sans raisonnement, le modèle s’est trompé 28 fois sur 39. Parmi ces erreurs, 17 réponses ne contenaient qu’un nombre en cinq tokens ou moins, sans aucun calcul. Tous les niveaux de raisonnement ont donné toutes les bonnes réponses : seule la quantité de texte produite a changé.

max a produit plus de texte que low sur 12 des 13 tâches, avec 1.96x plus de tokens de sortie au total. Nous l’avons vérifié par un test des signes, qui compte les tâches où un réglage produit plus de texte que l’autre, puis par une correction de Holm pour tenir compte des cinq comparaisons simultanées. L’écart reste significatif (p = 0.002). high a produit 1.51x plus de tokens que low et des sorties plus longues sur 11 des 13 tâches. Après correction, ce n’est toutefois qu’une tendance, pas un écart démontré (p = 0.09). Sans aucun paramètre reasoning_effort, ce qui équivaut à high selon la documentation de DeepSeek, la sortie était 14% plus courte qu’avec high explicite. Cela donne une idée de la variabilité entre deux exécutions au même réglage.

Voici les deux paramètres de contrôle et l’emplacement des mesures dans la réponse :

import os
from openai import OpenAI

client = OpenAI(base_url="https://synthorai.io/v1", api_key=os.environ["SYNTHORAI_API_KEY"])
prompt = "How many positive integers below 1000 are divisible by 3 or 5 but not by 15?"
resp = client.chat.completions.create(
    model="deepseek-v4.1-flash-1017",
    messages=[{"role": "user", "content": prompt}],
    reasoning_effort="low",                          # "low" | "high" (default) | "max"
    # extra_body={"thinking": {"type": "disabled"}}, # thinking off instead
)
u = resp.usage
reasoning = u.completion_tokens_details.reasoning_tokens  # billed as output
cache_hits = u.prompt_tokens_details.cached_tokens         # billed at 2% of the input price
thinking_text = resp.choices[0].message.reasoning_content

Les boucles d’agents de code ont-elles besoin du raisonnement ?

Nos tâches de code n’en avaient pas besoin, mais elles étaient simples : tous les réglages ont résolu 30 tâches sur 30, et les moins chers étaient le raisonnement désactivé et low. Ici, une boucle d’agent signifie que le modèle procède par tours, appelle des outils et lit leurs résultats jusqu’à ce qu’il estime la tâche terminée. Nous avons fourni à 1017 un petit package Python et trois tâches fondées sur des bugs introduits volontairement : corriger l’analyse d’un montant, ajouter deux formats d’entrée, puis corriger un contrôle de découvert et un rapport mensuel. Il disposait de quatre outils : lister les fichiers, lire un fichier, écrire un fichier et exécuter les tests visibles. Une exécution ne comptait comme réussie que si les fichiers finaux passaient des tests cachés, jamais montrés au modèle. Chaque tâche a été exécutée 10 fois par réglage, avec un maximum de 30 tours, et le code du modèle tournait dans une sandbox isolée. Les nombres de tours, de tokens de sortie et de secondes sont les médianes par exécution. Le coût par tâche résolue correspond à la dépense totale divisée par le nombre de tâches résolues, au tarif public de pointe :

Le nombre de tours a peu varié selon le niveau. C’est le raisonnement par tour qui a augmenté : absent lorsqu’il était désactivé, il représentait 72% de la sortie avec max. Nous avons comparé les 10 exécutions de chaque tâche avec un test de Mann-Whitney, qui vérifie si les coûts d’un réglage sont systématiquement supérieurs à ceux d’un autre, puis appliqué une correction de Holm aux 12 comparaisons. high coûtait plus cher que low sur les trois tâches, de 1.24x à 1.70x, et max coûtait plus cher que high sur deux tâches sur trois. Aucune différence n’a pu être établie entre le raisonnement désactivé et low.

Les deux dernières lignes servent de contrôle : ce sont les mêmes tâches, sans l’outil d’exécution des tests. Le modèle ne disposait donc d’aucun retour avant l’évaluation. Sans raisonnement, il a encore résolu 28 tâches sur 30. La baisse n’est pas significative (test exact de Fisher, qui compare deux nombres de réussites, p = 0.49) : le retour des tests n’était donc pas nécessaire pour réussir sans raisonnement dans ce cas. Les tâches qui échouaient sans raisonnement dans le jeu en un seul appel exigeaient de nombreuses étapes de calcul ou de recherche dans une seule réponse. Ces tâches de code demandaient de lire et de modifier quelques fichiers, ce que 1017 a su faire sans raisonnement.

Les tâches sont volontairement petites : quelques fichiers, des bugs repérables à la lecture du code et moins de 30 tours. Des travaux d’agent plus difficiles, comme des fonctionnalités touchant de nombreux fichiers, de longues séances de débogage ou une base de code inconnue, peuvent nécessiter un niveau plus élevé. C’est précisément ce type de projet que DeepSeek met en avant pour 1017. Nous ne l’avons pas testé. Pour des tâches simples avec outils, un point de départ raisonnable est de désactiver le raisonnement ou de choisir low, puis de passer à high si la tâche est complexe ou si des exécutions échouent.

Lorsque le raisonnement est activé et que la requête contient tools, le guide du mode raisonnement de DeepSeek impose de renvoyer le reasoning_content de chaque tour précédent de l’assistant. La documentation indique qu’à défaut, l’API renvoie une erreur 400 :

msg = resp.choices[0].message
messages.append({
    "role": "assistant",
    "content": msg.content or "",
    "tool_calls": msg.tool_calls,
    "reasoning_content": msg.reasoning_content,  # required with tools in thinking mode
})

Combien économise-t-on avec le cache et les heures creuses ?

Dans nos exécutions d’agents, le cache a réduit la facture de plus de moitié, et les heures creuses divisent encore le reste par deux. À chaque tour, une boucle d’agent renvoie toute la conversation. Sur les 120 exécutions avec l’outil de test, l’entrée représentait donc 90% des tokens, et 82% de cette entrée a été facturée au tarif du cache, soit 2% du prix d’entrée. Au tarif public de pointe, ces 120 exécutions ont coûté $0.75 ; sans réduction liée au cache, les mêmes tokens auraient coûté $1.66. Après application du cache, la sortie représentait 71% de la facture et l’entrée hors cache 27%. Le niveau de raisonnement est donc le principal levier restant pour réduire le coût d’un agent 1017. En heures creuses, les mêmes tokens auraient coûté $0.38.

Le cache est automatique sur l’API de DeepSeek : aucun frais d’écriture et rien à marquer. Lors de notre vérification, nous avons envoyé deux fois un prompt de 6,069 tokens ; au second appel, 6,016 tokens ont été facturés comme des accès au cache. Gardez donc le début du prompt stable : d’abord le prompt système et les définitions d’outils, puis les éléments qui changent à chaque requête.

La fenêtre de contexte de 1M est-elle réellement exploitable ?

Toute la fenêtre est exploitable pour retrouver une information. Nous avons caché une phrase contenant un code à sept chiffres dans un texte de remplissage composé de phrases variées. Nous avons ensuite demandé ce code, sans raisonnement, en plaçant la phrase à trois positions dans le prompt :

Une requête de 1.15 million de tokens a échoué avec HTTP 400 et un message indiquant une limite de 1,048,568 tokens. Une requête trop longue est donc rejetée avant de commencer, sans troncature silencieuse. Ce test porte sur la récupération d’un seul fait explicite. Raisonner sur de nombreux faits dispersés dans un long prompt est plus difficile, et nous ne l’avons pas testé.

Quel réglage pour quel usage ?

Aucun niveau de raisonnement ne remplace une suite de tests ou un validateur que l’agent peut exécuter. Sans outil de test, le modèle a encore résolu 28 tâches sur 30 sans raisonnement, mais rien n’a détecté les deux échecs avant l’évaluation. Prévoyez aussi des tests de régression après le 17 octobre si vous appelez deepseek-v4-flash ou deepseek-flash sur l’API de DeepSeek : le modèle derrière ces noms a changé.

Comment Synthorai gère cette version

Sur Synthorai, 1017 possède son propre identifiant, deepseek-v4.1-flash-1017. Pour préserver le comportement des intégrations existantes, nous n’avons pas réaffecté les anciens identifiants comme DeepSeek l’a fait sur son API : deepseek-v4.1-flash reste le V4.1 Flash de septembre. Pour passer à 1017, vous changez l’identifiant du modèle. Sur /v1/chat/completions, les tarifs affichés sont de $0.30 en entrée, $1.20 en sortie et $0.006 en lecture du cache par million de tokens, soit les tarifs publics de DeepSeek. reasoning_effort et thinking: {"type": "disabled"} sont transmis tels quels. Les appels avec raisonnement renvoient reasoning_content, et les accès au cache sont indiqués dans usage.prompt_tokens_details.cached_tokens. Tous les coûts de cet article utilisent le tarif public de pointe de DeepSeek ; vous pouvez ainsi les adapter à vos propres horaires.

FAQ

DeepSeek V4.1 Flash 1017 est-il un autre modèle que deepseek-v4-flash ?

Sur l’API de DeepSeek, c’est désormais le modèle derrière ce nom. La page de tarifs de DeepSeek indique que les anciens identifiants deepseek-v4-flash et deepseek-v4-flash-vision-exp utilisent DeepSeek V4.1 Flash 1017, au tarif Flash. deepseek-flash pointe lui aussi vers cette version. Le V4.1 Flash de septembre n’est plus disponible sur l’API de DeepSeek, mais des hébergeurs tiers continuent de servir ses poids ouverts. Sur Synthorai, les anciens identifiants conservent les anciennes versions, et 1017 porte l’identifiant deepseek-v4.1-flash-1017.

Faut-il désactiver le raisonnement sur DeepSeek V4.1 Flash 1017 ?

Désactivez-le pour les tâches simples de code et d’utilisation d’outils : dans notre boucle d’agent, 1017 a résolu 30 petites tâches de code sur 30 sans raisonnement à $0.0042 chacune, et 28 sur 30 même sans outil de test. Gardez-le activé, à low, pour les questions en un seul appel qui nécessitent plusieurs étapes de calcul ou de planification : sans raisonnement, le score était de 11 sur 39, contre 39 sur 39 avec low. Pour les travaux d’agent complexes, que nous n’avons pas testés, envisagez high.

DeepSeek V4.1 Flash 1017 dispose-t-il vraiment d’une fenêtre de contexte de 1M tokens ?

Oui : 1017 a retrouvé une information cachée aux positions 10%, 50% et 90% d’un prompt de 1,001,531 tokens, en environ 25 secondes, pour $0.30 par requête au tarif public de pointe. Une requête dépassant 1,048,568 tokens a renvoyé HTTP 400.

À lire aussi : Coût de DeepSeek V4.1 Flash, DeepSeek V4 Pro : version stable contre préversion, Réglages du raisonnement des LLM, Coût d’écriture du cache de prompts, Paliers tarifaires des longs contextes.

Mesures effectuées le 19 octobre 2026 via la passerelle Synthorai, avec l’identifiant deepseek-v4.1-flash-1017 : 195 appels en réponse unique (13 tâches, cinq réglages, trois exécutions), 180 exécutions d’agents (trois tâches, six réglages dont deux sans outil de test, 10 exécutions) et 11 requêtes à long contexte. Coûts calculés au tarif public de pointe de DeepSeek ; chiffres d’Artificial Analysis consultés le 19 octobre 2026.

← Retour au blog