La facture de l'API DeepSeek n'est pas un simple « nombre d'appels multiplié par un prix unitaire » : elle dépend des tokens d'entrée, des tokens de sortie et du comportement du cache. Beaucoup d'équipes établissent leur budget à partir du tarif affiché, puis constatent en production un coût nettement supérieur. La cause n'est généralement pas une hausse du prix unitaire, mais une structure d'entrée, un taux de cache et un nombre de nouvelles tentatives différents de l'estimation initiale.

Cet article décompose la facturation DeepSeek en éléments calculables : quels tokens sont facturés, pourquoi le cache fonctionne parfois et parfois non, comment estimer à partir du champ usage renvoyé, et dans quel ordre réduire les coûts. Les prix unitaires exacts sont régis par les prix des modèles et la documentation officielle de DeepSeek.

Note : DeepSeek est une marque de son titulaire. Cet article s'appuie sur les formes d'interface courantes en octobre 2026 ; prix, noms de modèles et règles de facturation peuvent évoluer. Vérifiez à nouveau la page officielle avant tout achat.

1. Décomposer la facture en quatre postes

Poste de facturation Quand il apparaît Principaux facteurs Axe d'optimisation
Entrée (cache manqué) Un nouveau contenu entre pour la première fois dans le contexte Longueur des documents, historique des messages, définitions d'outils Recherche, résumé, réduction
Entrée (cache touché) La requête réutilise un préfixe déjà mis en cache Stabilité du préfixe, taux de réussite Préfixe fixe, moins de contenu aléatoire
Sortie Le modèle génère le corps de réponse et les résultats structurés Longueur de sortie, contraintes de format max_tokens, contraintes JSON
Contenu de raisonnement Un modèle de raisonnement produit son processus de réflexion Difficulté de la tâche, niveau de raisonnement Éviter le raisonnement sur les tâches simples

Le cache de contexte de DeepSeek se reflète généralement du côté de l'entrée : le préfixe touché est facturé à un tarif d'entrée réduit, la partie non touchée au tarif d'entrée standard. L'existence d'un coût de stockage du cache et sa durée de conservation dépendent de la documentation officielle actuelle ; ne reprenez pas les règles d'anciens articles.

Le coût d'une requête peut s'écrire ainsi :

Coût d'une requête =
  tokens d'entrée en cache × prix du cache touché
+ tokens d'entrée hors cache × prix de l'entrée
+ tokens de sortie × prix de la sortie

Ce n'est qu'en appliquant cette formule aux journaux que l'on peut répondre à la question « combien ce module coûte-t-il par mois ». La seule facture totale de la console ne permet pas de savoir quel projet ou quel type de requête fait exploser les coûts.

2. Pourquoi le cache économise, et pourquoi il échoue souvent

La logique du cache de contexte est simple : si le début de deux requêtes est identique, le serveur peut réutiliser le calcul précédent et ne recalculer que la partie nouvelle. Le cache est donc particulièrement efficace pour :

  1. un prompt système et un rôle fixes ;
  2. des définitions d'outils et des schémas de fonctions stables ;
  3. des extraits de base de connaissances, manuels produits ou modèles de contrats réutilisés ;
  4. la première partie inchangée d'une conversation multi-tours.

À l'inverse, les pratiques suivantes font échouer le cache :

  • insérer l'heure courante, un identifiant aléatoire ou le nom de l'utilisateur au début du prompt système ;
  • réordonner les outils ou les documents à chaque requête ;
  • placer le document entier en tête et la question de l'utilisateur seulement ensuite ;
  • basculer sans cesse la même activité entre plusieurs modèles ou points d'entrée ;
  • utiliser un préfixe trop court pour atteindre la granularité réutilisable.

Placer le contenu variable à la fin de la requête et le contenu stable au début est la méthode la plus simple et la plus efficace. Le cache est généralement fourni au mieux, sans promesse de réussite ; estimez donc le budget sur une hypothèse de « réussite partielle », pas sur un cache systématiquement touché.

3. Estimer avec le champ usage

Ne devinez pas les tokens à partir du nombre de caractères. Enregistrez le champ usage de chaque réponse et observez-le pendant une semaine pour obtenir la structure réelle de votre activité.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url="https://api.deepseek.com",
)

resp = client.chat.completions.create(
    model="deepseek-chat",  # nom à vérifier sur la page des prix
    messages=[
        {"role": "system", "content": "Tu es un assistant support ; réponds en trois phrases maximum."},
        {"role": "user", "content": "Peut-on encore modifier l'adresse après l'expédition ?"},
    ],
    max_tokens=256,
)

usage = resp.usage
hit = getattr(usage, "prompt_cache_hit_tokens", 0) or 0
miss = getattr(usage, "prompt_cache_miss_tokens", 0) or 0

print("entrée", usage.prompt_tokens)
print("cache touché", hit, "manqué", miss)
print("sortie", usage.completion_tokens)

Si la réponse ne fournit pas le détail du cache, enregistrez au moins l'entrée et la sortie totales, puis recoupez avec la facture ou la page d'usage. L'essentiel est de conserver des définitions de champs cohérentes et de ne pas comparer des données de dates ou de points d'entrée différents.

Pour l'estimation, notez au minimum : date, projet, modèle, tokens d'entrée, tokens de sortie, cache touché, nombre de nouvelles tentatives, mode streaming ou non. Le montant se calcule en fin de mois en multipliant par le prix unitaire ; les indicateurs de processus, eux, se consultent chaque jour.

4. Pourquoi la facture varie du simple au multiple à volume égal

Scénario Structure de tokens typique Point de gonflement Priorité d'optimisation
Chatbot support Entrée élevée, sortie courte Historique renvoyé à chaque tour Résumé, cache, limiter aux derniers tours
Extraction documentaire Entrée moyenne, sortie structurée Même document relu plusieurs fois Cache de préfixe, traitement par lots
Assistant de code Entrée et sortie élevées Résultats d'outils et fichiers longs Recherche, découpage, limitation de sortie
Génération de texte long Entrée courte, sortie longue Accumulation des tokens de sortie Génération par segments, max_tokens
Tâches de raisonnement Entrée moyenne, sortie incluant la réflexion Le raisonnement est compté en sortie Modèle non raisonnant pour les tâches simples

Les écarts viennent généralement de cinq facteurs :

  1. Ratio entrée/sortie différent : le support et la rédaction longue ont des structures de coût opposées ; une moyenne unique ne peut pas servir aux deux.
  2. Taux de cache différent : un préfixe fixe est réutilisable, un contenu dynamique casse le cache.
  3. Longueur de contexte différente : envoyer le document entier à chaque tour fait croître le coût d'entrée avec le nombre de tours.
  4. Nombre de nouvelles tentatives différent : les renvois après un 429 ou un délai dépassé augmentent le volume ; la facturation des échecs dépend de la facture.
  5. Gamme de modèle différente : modèles raisonnants et non raisonnants n'ont ni le même prix unitaire ni la même longueur de sortie ; une mauvaise correspondance gonfle le budget.

5. L'ordre de réduction des coûts ne doit pas être inversé

  1. Quantifier d'abord : calculer la structure réelle des tokens de chaque fonction avec usage et les journaux, sans se fier à l'intuition.
  2. Améliorer ensuite le cache : fixer le prompt système, les définitions d'outils et le préfixe de connaissances, réduire le contenu dynamique en tête.
  3. Réduire l'entrée : ne récupérer que les extraits pertinents en RAG, résumer l'historique, ne conserver que les champs utiles des sorties d'outils.
  4. Limiter la sortie : définir un max_tokens raisonnable, exiger du JSON ou des champs fixes, éviter les explications redondantes.
  5. Router par modèle : classification, extraction et réécriture sur des modèles légers ; raisonnement complexe sur des modèles supérieurs.
  6. Asynchroniser et traiter par lots : placer en file les annotations, résumés et analyses hors ligne qui n'exigent pas de réponse immédiate.
  7. Surveiller et alerter : suivre l'usage par projet, modèle et scénario, et fixer des plafonds budgétaires.

Si l'ordre est inversé, le résultat typique est le suivant : on passe à un modèle moins cher, mais l'entrée n'est pas maîtrisée et le cache ne répond pas ; la facture ne baisse pas et la qualité se dégrade.

6. Gérer budget et facturation

  • une clé par projet, avec séparation test/production pour éviter que les quotas se chevauchent ;
  • un plafond de dépense et des alertes par clé, pour limiter automatiquement les dégâts en cas d'appels anormaux ;
  • un rapprochement hebdomadaire par projet, modèle et scénario, pour identifier les appels qui progressent le plus vite ;
  • une trace séparée des économies dues au cache et au routage, sans laquelle l'effet des optimisations ne peut pas être démontré ;
  • pour les équipes ayant besoin de paiement en yuans et de factures, une passerelle IA locale peut unifier la facturation ; les prix, taux de change et règles de facturation sont régis par les prix des modèles.

Questions fréquentes

Faut-il activer manuellement le cache de DeepSeek ?

En général, il n'y a pas de segment de cache à marquer explicitement ; le serveur détermine automatiquement si un préfixe peut être réutilisé. Le mécanisme exact et la durée de conservation dépendent de la documentation officielle. Votre rôle est de rendre le préfixe stable, pas d'ajouter davantage de configuration.

Pourquoi le taux de cache varie-t-il autant ?

Les causes courantes sont l'insertion d'horodatages, d'identifiants aléatoires ou d'informations utilisateur dans le préfixe, ou des allers-retours entre modèles et points d'entrée. Déplacez d'abord le contenu variable à la fin, puis observez pendant une semaine.

Les tokens de réflexion d'un modèle raisonnant sont-ils facturés ?

Les tokens de réflexion produits par un modèle raisonnant sont généralement comptés dans la sortie ; le détail exact dépend de la documentation officielle et de la facture. Pour une simple classification ou extraction, mieux vaut ne pas utiliser par défaut un modèle raisonnant.

Qu'est-ce qui coûte le plus cher, l'entrée ou la sortie ?

Pour la plupart des modèles, le prix de sortie dépasse celui de l'entrée, mais l'entrée en cache touché est généralement moins chère. Ne comparez pas seulement deux prix unitaires : calculez le coût par requête selon votre propre ratio entrée/sortie.

Pourquoi l'estimation ne correspond-elle pas à la facture ?

Les oublis fréquents incluent l'historique des messages, les définitions d'outils, les nouvelles tentatives, les entrées hors cache et les sorties longues. Recoupez l'identifiant de requête avec les journaux d'usage pour localiser l'écart.

Étape suivante

Créez d'abord une clé de test sur ZSQH AI Gateway, exécutez une semaine de tâches réelles en relevant entrées, sorties et cache touché, puis convertissez le budget avec les prix des modèles. La disponibilité des modèles et les prix sont régis par la page des prix.

Lectures associées :