DeepSeek V4.1 Flash 1017 : prix API, Search et mon test

👁 119 lectures

Le modèle DeepSeek V4.1 Flash 1017 associe un checkpoint open-weight actualisé à une nouvelle offre de recherche web en ce mois d’octobre 2026. J’ai testé ce modèle DeepSeek V4 via l’API le 19 octobre, et il a validé l’intégralité des 12 tâches de mon banc d’essai en polonais. Ce résultat d’évaluation directe se distingue des benchmarks de programmation publiés par l’éditeur et de la nouvelle Search API, que ce protocole n’a pas sollicitée.

Ce qui change dans DeepSeek V4.1 Flash 1017

DeepSeek présente V4.1 Flash 1017 comme une mise à jour mineure, mais son tableau comparatif officiel fait état de gains sensibles en raisonnement, en programmation et sur les flux agentiques. Ce suffixe désigne la révision du 17 octobre 2026. Conserver cette précision reste indispensable dans vos comptes rendus, car un alias d’API peut conserver son libellé commercial alors que les poids sous-jacents changent. L’architecture de la première mouture figure dans mes analyses précédentes, tandis que les autres lancements open-weight de la semaine sont détaillés dans mon dossier sur les modèles IA open-weight d’octobre 2026.

Dans les données publiées par DeepSeek, le benchmark DeepSWE v1.1 grimpe de 74,2 à 77,0, Terminal-Bench 4.0 passe de 31,2 à 42,3, et Automation-Bench v1.0.6 progresse de 54,8 à 60,5. Il s’agit d’affirmations et de scores déclarés par l’éditeur. Je n’ai pas reproduit ces évaluations spécifiques, et il ne faut pas les amalgamer avec mon test court en polonais au sein d’un classement unique.

DeepSeek revendique également une réduction de la longueur des sorties textuelles et du temps d’exécution par tâche. Ce point s’avère particulièrement pertinent pour les agents autonomes, où l’accomplissement d’un objectif enchaîne de multiples appels au modèle. Cela ne suffit pas à promettre une économie forfaitaire garantie sur d’autres contextes d’intégration. Une réponse plus concise n’est utile que si elle conserve toutes les informations ou l’appel d’outil dont votre chaîne logicielle a besoin.

Poids ouverts, licence et déploiement local

Le dépôt officiel héberge les poids sous licence MIT et annonce une fenêtre de contexte de 1 million de tokens. Les métadonnées sur Hugging Face indiquent 763 milliards de paramètres. Ce chiffre correspond à la taille globale déclarée du dépôt et non à un comptage vérifié de paramètres actifs par passage. Il ne dispense pas non plus d’évaluer la mémoire VRAM requise par chaque format de quantification envisagé.

La licence MIT accorde des droits d’exploitation étendus, y compris pour un usage commercial et pour la modification du code ou des poids, tout en exigeant la mention des droits d’auteur originaux. Dire qu’il s’agit d’une licence « sans conditions » serait rigoureusement inexact. Son principal atout opérationnel réside dans l’absence de clauses de revenus restrictives, contrairement aux licences personnalisées d’autres modèles récents du secteur.

Héberger localement l’intégralité du checkpoint nécessite une infrastructure adaptée. Mon banc d’essai s’étant appuyé sur une inférence distante via l’API, je n’ai pas de mesures matérielles locales à vous soumettre ici. Les instructions techniques du dépôt officiel constituent la source de référence pour les formats de quantification et la configuration du runtime. Fonder un achat de serveurs uniquement sur une estimation de calcul actif par token ou sur la mention « Flash » serait une erreur de dimensionnement.

La grille officielle : prix DeepSeek API en USD

La documentation de facturation officielle de DeepSeek, consultée le 20 octobre 2026, associe l’alias deepseek-flash au checkpoint V4.1 Flash 1017. Les montants ci-dessous s’entendent pour 1 million de tokens. L’état du cache de contexte s’applique aux tokens d’entrée, tandis que la génération obéit à un tarif propre.

Les fenêtres d’heures pleines définies par l’éditeur se situent entre 01:00-04:00 et 06:00-10:00 UTC du lundi au vendredi, hors jours fériés chinois. Les autres périodes relèvent du tarif heures creuses. Estimer votre facture DeepSeek API demande donc d’anticiper le taux d’utilisation du cache, vos plages horaires d’appels et le volume de texte généré. Les tarifs d’entrée et de sortie maximaux ne représentent pas le coût de chaque requête.

Cette grille officielle en catalogue ne doit pas être confondue avec les dépenses brutes relevées lors de mes essais. Un historique d’exécution via l’API dépend de conditions de service et de facturation propres au fournisseur retenu. Son coût mesuré doit rester rattaché à cette série d’expérimentations plutôt que servir de devis contractuel pour vos déploiements directs futurs.

Les services Search et Fetch de DeepSeek

L’API de recherche Search renvoie des résultats web indexés et classés, tandis que le point de terminaison Fetch extrait le contenu brut d’une page au format Markdown. DeepSeek documente un plafond de 50 résultats web par requête et facture chacun de ces deux services à 0,75 $ pour 1 000 requêtes réussies. L’unité facturable est la requête aboutie, non le nombre de liens ou d’extraits extraits.

Le guide d’intégration précise que les requêtes échouées, les recherches sans résultat et les dépassements de délai (timeouts) ne font l’objet d’aucune facturation. Ses mentions sur la phase de gratuité initiale diffèrent de la page tarifaire, qui fixe formellement le début de la facturation des appels d’outils intégrés côté serveur au 1er novembre 2026 à 00:00, heure de Pékin (soit le 31 octobre à 16:00 UTC). Cette date butoir ne doit pas être interprétée comme l’assurance que chaque requête Search autonome restera gratuite jusque-là.

Dans une architecture applicative, la recherche web et la génération linguistique répondent à deux impératifs distincts. Le composant Search récupère des données d’actualité ; le modèle de langage doit encore filtrer, comprendre et citer correctement ces données. Récupérer une page ne garantit nullement la véracité de ses allégations, et une réponse bien rédigée ne démontre pas que les sources fournies la corroborent.

• Stockez les URL et le texte source récupérés pour permettre un contrôle qualité ultérieur.
• Suivez la consommation des requêtes Search et Fetch séparément de votre volume de tokens.
• Vérifiez systématiquement si la synthèse formulée découle logiquement des éléments extraits.
• Évaluez le comportement de vos prompts face à des retours de recherche vides.

Ces étapes relèvent de l’ingénierie applicative. Je n’ai pas mené de banc d’essai comparatif sur la pertinence documentaire ou la latence de récupération de ce moteur de recherche au cours de mon protocole, ce qui exclut toute comparaison directe avec d’autres index web dans cet article.

Ce que mon test en polonais a démontré

Mon test du 19 octobre 2026 comprenait 12 requêtes courtes formulées en polonais, soumises chacune une seule fois avec une température de 0 et une limite maximale de 6 000 tokens de complétion incluant le raisonnement. DeepSeek a formulé une réponse valide sur l’ensemble des tâches (consultez le comparatif des quatre modèles ouverts évalués en polonais). Le protocole explorait le calcul arithmétique, la flexion grammaticale, le comptage de lettres, l’extraction de données de factures, le calcul de clé de contrôle, la logique formelle, la déduction d’un jour de la semaine historique, le respect de contraintes de mise en forme, la géographie locale, les conversions d’unités, l’orthographe et la poursuite de suites logiques.

Le temps de traitement médian s’est élevé à 0,95 seconde par requête, avec un délai maximal mesuré à 2,4 secondes. Le volume de complétion cumulé sur les 12 requêtes a atteint 1 283 tokens. La dépense globale enregistrée pour mon exécution a été de 0,00062014 $, soit environ 0,0006 $. Ce sont des mesures effectives issues de mes journaux de requêtes, et non des extrapolations calculées sur la base de la grille de prix DeepSeek API actuelle.

Le résultat de 12/12 prend en compte une correction apportée à la grille d’évaluation sur l’exercice orthographique. Le modèle a produit la formule impérative correcte « Weź parasol » (« Prends un parapluie »), là où la consigne initiale attendait un infinitif (« wziąć »). Valider cette alternative linguistique a permis de corriger une règle de notation initiale trop rigide. Aucune réponse n’a été régénérée pour parvenir à ce score.

Ces chiffres sont très encourageants pour des micro-tâches de ce format, mais ils n’indiquent rien sur la rédaction longue en polonais, la qualité stylistique en français, la compréhension visuelle ou le raisonnement complexe à l’échelle d’un projet de programmation complet. Les requêtes réseau peuvent par ailleurs solliciter des grappes de serveurs aux performances disparates. La latence constatée correspond à l’expérience mesurée lors de mon test API et ne saurait constituer une mesure brute de la vitesse d’inférence matérielle pure.

Foire aux questions

Faut-il modifier l’identifiant de modèle pour les utilisateurs actuels de l’API ?

La page tarifaire officielle fait correspondre le nom de modèle deepseek-flash au checkpoint mis à jour. Pensez à documenter la date exacte du checkpoint dans vos benchmarks internes, même si votre configuration logicielle continue d’appeler le même alias d’API.

La Search API explique-t-elle ce sans-faute sur le test ?

Non. Les invites soumises étaient purement textuelles, sans aucun branchement vers des outils de recherche web. Ce test ne permet donc pas de juger des gains que l’intégration de Search ou Fetch pourrait apporter sur d’autres scénarios.

Ce résultat prouve-t-il que DeepSeek surpasse tous les modèles open-weight ?

Le modèle a réussi l’ensemble de ces épreuves concrètes en polonais tout en affichant la latence médiane la plus basse de mon comparatif. Établir une hiérarchie générale exigerait un échantillon bien plus vaste, incluant le traitement d’images, le maniement d’outils externes et les conversations interactives longues.