La facture de l'API Mistral n'est pas « un appel, un paiement » : elle se calcule en tokens d'entrée, tokens de sortie, cache, et unités propres aux modèles spécialisés comme l'OCR ou la voix. Beaucoup d'équipes budgétisent à partir d'un chiffre de la page tarifs et découvrent en production une facture plus élevée ; la cause est rarement le prix unitaire, mais la structure des entrées, la longueur du contexte et le nombre de retries, différents de l'estimation.

Cet article décompose la facturation Mistral en parties calculables : quelles unités sont facturées, comment entrée et sortie s'additionnent, pourquoi le contexte fait croître le coût avec le nombre de tours, comment cache et retries influencent la facture, et comment budgéter à partir de logs réels puis rapprocher la facture. Les prix unitaires exacts sont ceux de la page officielle Mistral et de la page tarifs des modèles ; cet article n'en fixe aucun.

Note : Mistral et Mistral AI sont des marques de leurs titulaires. Cet article s'appuie sur la documentation publique d'octobre 2026 ; noms de modèles, unités et prix peuvent évoluer. Avant achat, vérifiez à nouveau la documentation officielle Mistral et la page tarifs des modèles.

1. Distinguer les unités : tous les modèles ne facturent pas au token

Les modèles de langage Mistral facturent au token, mais l'OCR, la voix et l'Embedding ont leurs propres unités. Additionner directement des coûts d'unités différentes est la première source de budget faussé.

Objet facturé Unité Cas courant Point d'attention budgétaire
Modèle de langage Tokens d'entrée et de sortie Dialogue, extraction, code, agent La sortie coûte généralement plus que l'entrée ; le cache d'entrée est remisé
OCR Page, pages en cache incluses Documents scannés, PDF vers texte À suivre séparément de la facture tokens
Transcription vocale Minute, durée en cache incluse Réunions, enregistrements du service client Facturé à la durée, pas au nombre de caractères
Synthèse vocale Caractère Annonces, doublage Entrée et sortie à distinguer
Embedding Token d'entrée Recherche, clustering, déduplication Généralement facturé côté entrée uniquement
Modération de contenu Token Sécurité des contenus, gestion des risques Tarification selon la page prix en vigueur

La page tarifs distingue aussi souvent les paliers Standard, Batch et Priority. Ils répondent à des exigences de délai différentes ; l'usage de Batch dépend de la tolérance d'attente de la tâche.

2. Entrée et sortie : les deux côtés d'une même conversation sont facturés

Dans une requête, tout ce qui entre dans le contexte du modèle compte en entrée : prompt système, historique, question utilisateur, définitions d'outils, documents récupérés et conversion des entrées multimodales. Ce que le modèle génère compte en sortie : texte, champs structurés et raisonnement, si le modèle renvoie son raisonnement.

Deux erreurs fréquentes en découlent :

  • Ne compter que la question utilisateur, pas le contexte. L'utilisateur écrit vingt mots, mais le prompt système, le schéma d'outils et les cinq derniers tours représentent souvent l'essentiel.
  • Comparer les prix d'entrée sans regarder la proportion de sortie. Un service client a beaucoup d'entrée et peu de sortie ; une génération de texte long a peu d'entrée et beaucoup de sortie. Le coût par appel ne peut pas être estimé avec la même moyenne.

La conversion des entrées multimodales et la prise en compte du raisonnement dans la sortie suivent la documentation et la facturation officielles ; n'appliquez pas directement l'expérience d'un autre fournisseur.

3. Longueur du contexte : chaque tour paie « ce qui précède »

Un modèle de langage ne conserve pas en lui la mémoire d'une conversation. Si un dialogue multi-tours reste cohérent, c'est parce que le client renvoie l'historique à chaque tour. Plus le contexte est long, plus l'entrée en tokens augmente à chaque requête ; le coût s'accumule avec le nombre de tours, et pas seulement avec la phrase ajoutée.

Un exemple concret : le premier tour n'envoie que le prompt système et la question ; le cinquième tour envoie les quatre échanges précédents ; le vingtième tour envoie tout l'historique. Même si chaque tour ajoute peu, l'entrée du vingtième tour peut être plusieurs fois celle du premier.

Les méthodes de maîtrise sont simples :

  • ne garder que les derniers tours bruts et résumer les plus anciens ;
  • ne récupérer que les passages pertinents, sans insérer un manuel entier dans le contexte ;
  • placer le contenu stable au début et le contenu variable à la fin, pour favoriser le cache ;
  • traiter les documents longs par segments puis synthétiser, au lieu de répéter le texte intégral à chaque tour.

4. Cache, traitement par lots et retries : trois variables sous-estimées

Entrée en cache. Mistral propose un prix d'entrée en cache pour les modèles texte, généralement nettement inférieur à l'entrée normale. Le cache dépend de la stabilité du préfixe de requête. Mettre un horodatage, un ID aléatoire ou un nom d'utilisateur au début du prompt système, ou réordonner les définitions d'outils à chaque appel, invalide le cache. Le cache est généralement au mieux ; budgétez sur une « hit partiel », pas sur un taux de hit intégral.

Palier par lots. Les tâches sans besoin de réponse immédiate, comme l'étiquetage, le résumé, la classification hors ligne ou la traduction en volume, peuvent évaluer le palier Batch. Il sacrifie le délai au profit d'un autre palier tarifaire ; remises et limites exactes sont sur la page tarifs.

Retries. Les renvois après 429, timeout ou coupure de connexion augmentent le volume réel de requêtes. La facturation des échecs et la double facturation éventuelle des retries dépendent de la facture et de la documentation officielle. Côté ingénierie, utilisez un backoff exponentiel, un nombre maximal de tentatives et l'idempotence des opérations de création, pour éviter de « payer deux fois pour un seul succès ».

5. Estimer avec l'usage et les logs réels

Ne devinez pas les tokens à partir du nombre de caractères. Lisez l'usage renvoyé après chaque appel et enregistrez-le une semaine : vous obtiendrez la structure réelle de votre activité. Le code ci-dessous passe par l'interface compatible OpenAI, avec un nom de modèle lu dans l'environnement pour ne pas figer un nom qui change.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["ZSQH_API_KEY"],
    base_url="https://ai.zhongshangqihang.com/v1",
)

resp = client.chat.completions.create(
    model=os.environ["MISTRAL_MODEL"],  # nom de modèle selon la page tarifs du site
    messages=[
        {"role": "system", "content": "Tu es un assistant service client, réponds en trois phrases maximum."},
        {"role": "user", "content": "Peut-on encore changer l'adresse après expédition de la commande ?"},
    ],
    max_tokens=256,
)

u = resp.usage
print("entrée", u.prompt_tokens)
print("sortie", u.completion_tokens)
print("total", u.total_tokens)

Enregistrez au minimum : horodatage, projet, modèle, tokens d'entrée, tokens de sortie, hit de cache, nombre de retries, streaming ou non. Le montant se calcule en fin de mois avec le prix de la page tarifs ; les indicateurs de processus se regardent chaque jour.

6. De l'estimation à la facture : quelles marges prévoir

Pour budgéter, estimez séparément quatre blocs — usage de base, usage de pointe, retries et échecs, cache non touché — puis additionnez.

Lors du rapprochement, attention à trois différences de base :

  • le solde prépayé est généralement déduit en montant TTC, alors que le plafond de consommation est souvent calculé hors taxes ; les deux peuvent ne pas être synchrones ;
  • le plafond mensuel de l'organisation s'applique à tous les Workspaces, et un plafond de Workspace ne peut pas dépasser celui de l'organisation ;
  • en cas de solde insuffisant, les requêtes dépassant le forfait peuvent renvoyer HTTP 402 : ce n'est pas une panne de modèle, mais un état de facturation.

Le back-office de facturation Mistral propose une liste de factures et le téléchargement PDF ; recharge prépayée, frais de forfait et frais à l'usage y apparaissent séparément. Pour une note de frais d'entreprise, archivez ensemble facture, numéro de commande, preuve de paiement et détail d'usage ; la procédure de facturation est décrite dans le tutoriel de recharge de l'API Mistral du même site.

7. Ne pas inverser l'ordre des optimisations

  1. Quantifier d'abord : calculer la structure d'entrée et de sortie de chaque fonction avec l'usage et les logs, sans intuition.
  2. Améliorer ensuite le cache : figer prompt système, définitions d'outils et préfixe de connaissances, déplacer le contenu dynamique à la fin.
  3. Réduire l'entrée : résumer l'historique, ne récupérer que les passages utiles, ne garder que les champs nécessaires des sorties d'outils.
  4. Limiter la sortie : fixer un max_tokens raisonnable, demander des champs fixes ou du JSON, réduire les explications répétées.
  5. Router par modèle : classification, extraction et réécriture sur un modèle léger, raisonnement complexe sur un modèle supérieur.
  6. Évaluer le traitement par lots : mettre en file les tâches non temps réel pour un autre palier tarifaire.
  7. Surveiller et alerter : suivre l'usage par projet, modèle et scénario, avec plafonds budgétaires et alertes de solde.

Dans l'ordre inverse, le résultat courant est : un modèle au tarif inférieur, mais des entrées non maîtrisées et un cache inefficace, une facture qui baisse peu et une qualité qui baisse d'abord.

Questions fréquentes

L'API Mistral facture-t-elle à l'appel ou au token ?

Les modèles de langage facturent les tokens d'entrée et de sortie, pas le nombre d'appels. L'OCR, la transcription et la synthèse vocale utilisent des unités propres (page, minute, caractère), selon la page tarifs officielle.

Pourquoi la facture grimpe-t-elle plus vite avec un contexte long ?

Parce que chaque tour renvoie l'historique : les tokens d'entrée s'accumulent avec le nombre de tours. Même une nouvelle question très courte fait monter le coût si l'historique n'est pas tronqué.

Pourquoi le cache d'entrée ne fonctionne-t-il pas ?

Souvent à cause d'un préfixe instable : horodatage, ID aléatoire ou informations utilisateur au début, ou réordonnancement des outils et documents à chaque appel. Déplacez d'abord le contenu variable à la fin de la requête, puis observez.

Les requêtes réessayées sont-elles facturées ?

Cela dépend du moment de l'échec par rapport à la facturation et de la base actuelle de l'officiel. Côté ingénierie, limitez les retries, utilisez un backoff et rendez les écritures idempotentes pour éviter une double consommation.

Que faire si l'estimation ne correspond pas à la facture ?

Vérifiez d'abord l'oubli éventuel de l'historique, des définitions d'outils, des retries, des cache miss et des différences de palier Batch, puis comparez les logs d'usage avec les ID de requête. Si l'écart persiste, examinez ensemble le détail de facture et les enregistrements d'usage.

Prochaines étapes

Créez d'abord une clé de test sur ZSQH AI Gateway, exécutez des tâches réelles pendant une semaine, notez entrées, sorties et hits de cache, puis convertissez le budget avec la page tarifs des modèles. Disponibilité des modèles et prix sont ceux de la page tarifs.

Lectures associées :