Tarification DeepSeek V4 : 20 à 50 fois moins cher qu'OpenAI (Analyse des coûts)

Récemment, j’ai cherché un modèle plus économique, quelque chose que je pourrais solliciter fréquemment sans surveiller le compteur à chaque heure. DeepSeek V4 revenait constamment dans les discussions avec d’autres développeurs, généralement accompagné d’un sourcil levé : « C’est… vraiment bon marché. »

Dora est là. J’ai passé la deuxième moitié de janvier 2026 à l’intégrer dans quelques petits flux de travail : un résumeur de recherche, un rédacteur de notes de produit et un organisateur de backlog hebdomadaire. Rien de complexe. Je me souciais de la façon dont les jetons se traduisaient en vrais dollars sur une semaine normale. Voici ce que j’ai appris sur le coût de l’API DeepSeek V4, les remises qui comptent vraiment, et un moyen très simple de la budgétiser avant de la mettre en production.

Tarification actuelle de DeepSeek

Je ne prétendrai pas que les chiffres sont stables. Les prix bougent, et ils diffèrent selon où vous accédez (directement ou via un intermédiaire comme OpenRouter). Donc, deux repères :

Vérifiez la source : la documentation officielle de l’API DeepSeek et la page de tarification. Ce sont les tarifs canoniques quand vous vous connectez directement.
Si vous passez par une place de marché, ouvrez leur fiche produit. Par exemple, les modèles DeepSeek sur OpenRouter listent les tarifs par million de jetons et les remises basées sur le temps. Ce que j’ai vu fin janvier 2026 chez les fournisseurs était cohérent dans l’ensemble : DeepSeek V4 se situe bien en dessous des modèles de pointe pour les jetons d’entrée et de sortie. Les centimes exacts varient. Je partage comment je travaille avec la tarification plutôt que de la figer en place.

Tarifs standards

Si vous découvrez la facturation basée sur l’utilisation pour les modèles, deux lignes sont importantes :

Jetons d’entrée (ce que vous envoyez) : facturés par 1M jetons.
Jetons de sortie (ce que vous récupérez) : également facturés par 1M jetons, généralement plus cher que l’entrée.

Dans mes exécutions, les tarifs bruts de V4 étaient assez bas pour que les petites pointes quotidiennes ne fassent pas mal. Cela se voit surtout dans les travaux par lots. Par exemple, mon organiseur de backlog hebdomadaire envoie environ 20 invites de 3 à 5K jetons d’entrée chacun et reçoit 1 à 2K jetons de sortie. Même avec des tarifs conservateurs, le total pour toute l’exécution restait dans la zone de « l’argent du café ».

Deux notes pratiques :

L’inflation des jetons de sortie vous rattrape. Si vos invites encouragent de longues réflexions, la ligne de sortie peut doubler votre facture. J’ai plafonné max_tokens et affiné le style davantage. J’ai économisé de l’argent, meilleurs résultats.
La taille des chunks importe. Si vous résumez de longs documents, vous paierez chaque jeton qui se chevauche. Je suis passé d’un chevauchement de 1 600 jetons à 400 et je n’ai pas perdu en qualité.

Remises sur les succès en cache (90% de réduction)

Celle-ci a changé mon calcul mental. Certaines plateformes et fournisseurs de modèles prennent en charge la mise en cache des invites pour les préfixes répétés. Si vos premiers N jetons de l’invite ne changent pas (message système, instructions partagées, schéma), les succès en cache peuvent être facturés à une remise importante. 90% de réduction est le chiffre que j’ai vu documenté chez plusieurs fournisseurs pour les implémentations de mise en cache (la disponibilité varie : confirmez sur la page de tarification de votre fournisseur).

Voici à quoi cela ressemblait dans la pratique :

Mon résumeur de recherche partage un long message système fixe et un schéma d’outils stable. Seul le texte source change.
Après le premier appel, les appels suivants font un succès en cache pour ce préfixe partagé.
Sur les plateformes qui honorent la facturation du cache, ces jetons réutilisés ont été réduits au tarif réduit.

Deux avertissements de mes tests :

« Proche » n’est pas mis en cache. Changez une ligne dans le préfixe partagé et vous allez rater le succès.
Les grands schémas fixes se remboursent d’eux-mêmes. Si vous pouvez consolider les instructions et les outils dans un préfixe stable, faites-le une fois et profitez du cache.

Si votre fournisseur n’expose pas la mise en cache, vous pouvez toujours simuler une partie des économies en déplaçant les instructions répétées dans un message système plus court et cohérent, et en éliminant la redondance des messages utilisateur.

Remises hors pic (75% de réduction)

Quelques places de marché ont commencé à proposer des remises basées sur le temps pour lisser la demande. J’ai vu des fenêtres hors pic avec des réductions importantes (des chiffres comme 50-75% de réduction apparaissent, mais cela dépend du revendeur et du modèle). Les modèles DeepSeek ont tendance à participer car leurs économies penchent déjà vers l’efficacité.

Deux façons dont cela m’a aidé :

J’ai programmé mon travail de backlog hebdomadaire pour la fenêtre hors pic. Même charge de travail, article moins cher.
J’ai groupé les résumés de recherche la nuit. La latence n’avait pas d’importance, et la remise oui.

Ce n’est pas universel. Si vous vous connectez directement à DeepSeek, vérifiez s’ils publient une tarification basée sur l’heure de la journée. Si vous passez par un intermédiaire, lisez les petits caractères de la fiche produit. L’écart peut être assez important pour modifier le moment où vous exécutez les choses.

Pourquoi DeepSeek est si bon marché

Je voulais comprendre si le bas prix était une chose promotionnelle, ou si l’architecture le soutient réellement. D’après ce qui est public, deux éléments se sont distingués.

Architecture MoE

Les modèles plus grands de DeepSeek s’appuient sur Mixture-of-Experts (MoE). En termes simples : au lieu de réveiller le cerveau entier pour chaque jeton, le routeur choisit quelques sous-réseaux d’experts pour le gérer. Vous obtenez toujours un modèle capable, mais seulement une fraction des paramètres fonctionnent par étape, ce qui réduit le calcul et le coût.

Pourquoi cela importe dans la pratique :

Le débit s’adapte mieux. De mon côté, la latence p95 est restée raisonnable même quand j’ai augmenté les travaux parallèles.
Les coûts ne montent pas linéairement avec la complexité. Les invites longues ne pénalisaient pas autant que sur les modèles denses et toujours actifs.

J’ai utilisé d’autres modèles MoE qui semblaient fragiles sur les tâches de niche : V4 a géré les invites lourdes en structure (sorties JSON, utilisation d’outils) sans vaciller. Cette stabilité fait partie de l’histoire des coûts aussi : moins de tentatives, moins de recommencements.

Efficacité Engram

La documentation de DeepSeek mentionne des travaux sur la gestion du contexte et l’efficacité de la mémoire (ils soulignent des choses comme l’amélioration du routage de l’attention et la gestion du cache KV dans certaines versions). Je ne peux pas vérifier les détails internes, mais je peux partager ce que j’ai observé :

Les invites longues contextes n’ont pas échoué au débit de mes tests en janvier 2026. J’ai exécuté des contextes de 32K jetons sans la sensation « tout devient lent ».
Le formatage déterministe s’est bien déroulé à une température plus élevée que prévu, ce qui signifiait que je pouvais garder les sorties plus courtes sans effondrer la qualité.

Mon interprétation : le prix n’est pas un coup marketing. C’est le résultat d’une architecture construite pour garder le calcul par jeton bas, plus une volonté de transmettre cela au prix affiché. Si vous êtes curieux des notes techniques, commencez par la documentation officielle de DeepSeek et tous les papiers liés de leurs fiches produit.

Modèle de calculatrice des coûts

Je n’évalue plus les budgets au centime exact. Je planifie des plages, puis j’ajuste une fois que l’utilisation réelle s’installe. Voici le modèle que j’ai utilisé pour DeepSeek V4. C’est assez simple pour le recréer dans une feuille de calcul.

Les entrées que vous remplirez par charge de travail :

Appels par jour (ou par lot)
Jetons d’entrée moyens par appel
Jetons de sortie moyens par appel
Tarif d’entrée par 1M jetons (de votre fournisseur)
Tarif de sortie par 1M jetons (de votre fournisseur)
Jetons de préfixe cacheable par appel (0 si aucun)
Remise sur les succès en cache (par exemple, 0,90 pour 90% de réduction)
Multiplicateur hors pic (par exemple, 0,25 si 75% de réduction, sinon 1)

Étapes :

Séparez les jetons d’entrée cacheable et non-cacheable.
- cacheable_input = cacheable_prefix_tokens
- variable_input = max(avg_input_tokens - cacheable_prefix_tokens, 0)
Évaluez la partie cacheable au tarif réduit.
- cacheable_cost = (cacheable_input / 1,000,000) × input_rate × (1 − cache_hit_discount)
Évaluez l’entrée variable au tarif d’entrée complet.
- variable_input_cost = (variable_input / 1,000,000) × input_rate
Évaluez la sortie au tarif de sortie.
- output_cost = (avg_output_tokens / 1,000,000) × output_rate
Additionnez-les par appel, puis appliquez tout multiplicateur hors pic.
- raw_cost_per_call = cacheable_cost + variable_input_cost + output_cost
- cost_per_call = raw_cost_per_call × off_peak_multiplier
Adaptez au volume.
- daily_cost = cost_per_call × calls_per_day
- monthly_cost ≈ daily_cost × 30

Un petit exemple réel de ma semaine de tests (23-30 janvier 2026) :

120 appels/jour
3 200 jetons d’entrée/appel, dont 1 800 sont un préfixe fixe et cacheable
1 100 jetons de sortie/appel
Tarifs d’exemple : $0,40 par 1M d’entrée, $1,60 par 1M de sortie (remplacez par vos chiffres réels)
Remise sur les succès en cache : 90%
Multiplicateur hors pic : 0,5 (fenêtre 50% de réduction utilisée via un revendeur)

Maths (arrondies) :

Coût cacheable par appel = (1 800/1 000 000) × $0,40 × (1 − 0,90) ≈ $0,0000072
Coût d’entrée variable par appel = (1 400/1 000 000) × $0,40 ≈ $0,00056
Coût de sortie par appel = (1 100/1 000 000) × $1,60 ≈ $0,00176
Coût brut par appel ≈ $0,0023272
Ajusté hors pic ≈ $0,0011636
Quotidien ≈ $0,14
Mensuel ≈ $4,20

Ce n’est pas une coquille. Les tarifs bas par million plus la mise en cache et hors pic ont transformé un service « surveiller le compteur » en quelque chose que je peux oublier. Cela n’a pas gagné de temps au début, j’ai passé une heure à faire en sorte que le préfixe cacheable soit vraiment fixe, mais chaque appel après est devenu moins cher.

Quelques garde-fous que je garde dans la feuille :

Établissez des limites strictes sur max_tokens. L’inflation des sorties est le tueur budgétaire silencieux.
Suivez les tentatives séparément. Les tentatives sont une dépense réelle.
Enregistrez les jetons moyens hebdomadairement. La dérive des jetons se produit à mesure que les invites évoluent.

À qui cela convient :

Les équipes exécutant beaucoup d’appels petits et similaires (ETL, résumé, QA).
Les créateurs avec des travaux par lots qui peuvent se déplacer hors pic.

À qui cela pourrait ne pas plaire :

Les applications qui ont besoin de longues sorties en streaming toute la journée, hors pic. Les économies se réduisent.
Les configurations sans support de mise en cache. Vous paierez toujours des tarifs bas, mais pas les ridicules.

Si vous voulez un point de départ, reconstruisez le modèle ci-dessus dans l’outil de votre choix. C’est 10 minutes de configuration et cela sauve des heures de deviner plus tard.

Une dernière note : si vous mélangez les fournisseurs, normalisez tout en « coût par 1K jetons » dans votre feuille aussi. Cela rend les comparaisons côte à côte rapides quand vous décidez de garder V4 dans la boucle ou de basculer une tâche vers un modèle de pointe pour des raisons de qualité.

Je continue à regarder comment les fenêtres hors pic se déplacent. Récemment, elles se sont déplacées plus tôt le soir. Pas un problème pour les travaux par lots, juste quelque chose que je garde à l’œil.