Accueil → Aide

La facture est plus élevée que ne le justifie le nombre de tokens

Ce que vous voyez

• Cost per request varies wildly for similar prompts
• Median and mean cost per call differ by several times
• A short conversation costs more than a long one
• Agent frameworks cost far more than the same prompts by hand
• The math using the headline per-token price does not reproduce the invoice

Pourquoi cela arrive

Les prix affichés sont donnés par million de tokens d'entrée et de sortie, ce qui invite à raisonner sur une seule moyenne. Les vraies factures sont la somme de quatre tarifs différents : entrée, sortie, lecture de cache et écriture en cache. Quand la répartition change, la facture change sans que le total de tokens bouge beaucoup.

C'est le sens du cache qui surprend. Lire depuis le cache est bon marché : c'est la raison d'être du cache. Y écrire coûte plus cher que de renvoyer les tokens. Une boucle qui modifie le début de son contexte à chaque tour invalide donc le cache et paie le supplément à chaque fois, tandis qu'une boucle qui ajoute à un préfixe stable bénéficie de la remise.

Les chiffres de notre propre facturation donnent l'échelle : sur un échantillon de requêtes avec cache, l'entrée et la sortie ordinaires représentaient ensemble environ 3 % de tous les tokens traités, le reste étant des écritures et lectures de cache. Dans une session de trente requêtes, les seules écritures en cache représentaient 63 % du montant : des tokens qui n'ont produit aucune sortie.

Vérifiez si c'est bien la cause

Prenez une vraie requête dans le journal d'utilisation de votre fournisseur et séparez les quatre compteurs :

# Any provider that reports usage will expose these four fields.
# What to compare:
#   input_tokens           charged at the input rate
#   output_tokens          usually ~5x the input rate
#   cache_read_tokens      a fraction of the input rate
#   cache_creation_tokens  charged ABOVE the input rate
#
# If cache_creation dominates, the cost is context churn, not generation.

Calculez la part du montant que représente chaque compteur. Si les écritures en cache dominent, le levier est la stabilité du prompt, pas un modèle moins cher.

Comment le corriger

1. Stabilisez le début du promptTout ce qui change à chaque tour (un horodatage, une liste d'outils mélangée, un compteur) invalide le cache à partir de ce point. Déplacez le contenu variable à la fin et le préfixe restera cacheable.
2. Regardez la longueur de la sortie avant de changer de modèleLa sortie coûte plusieurs fois l'entrée. Une modification du prompt qui raccourcit les réponses d'un tiers économise souvent plus qu'un passage à une gamme moins chère, et ne demande aucune revalidation.
3. Envoyez les étapes simples à un modèle bon marchéClassification, extraction et routage nécessitent rarement un modèle phare. N'envoyer au modèle cher que l'étape finale de raisonnement réduit généralement le coût global de plus de moitié.
4. Comparez par million de sortie, pas par million de tokensUn chiffre moyen par token cache ce qui fait vraiment la facture. Deux modèles aux moyennes similaires peuvent nettement différer une fois appliqué le ratio entrée/sortie de votre charge.

Voir aussi

Dernière vérification le 2026-10-01. Rédigé à partir de problèmes diagnostiqués sur une passerelle compatible OpenAI en production, pas compilé à partir d'autres sites.