Prompt Caching : coût de la première et des requêtes répétées

Ce que mesure l'expérience

Prompt Cache réduit le retraitement de la partie inchangée de l'entrée. Cela peut être un system prompt, des instructions, un grand document ou un récit stable. La question modifiée se place après le prefix général.

L'expérience nécessite trois états :

A. première requête : prefix stable + question 1
B. cache hit :        prefix stable + question 2
C. cache miss :       prefix modifié + question 3

A et B utilisent même modèle, mêmes réglages et même cache policy. C modifie un caractère dans la zone cachée ou est exécutée après expiration confirmée du TTL. Si vous modifiez à la fois modèle, output et longueur de prompt, le résultat ne peut plus être expliqué par le cache seul.

Vous voulez vérifier la formule sur votre propre usage ? Créez un compte BetterToken et API Key, prenez les tarifs actuels sur la page pricing et effectuez première et requête répétée avec le même prefix. Faites correspondre input, output, cache Token applicable et consommation dans le Dashboard; vérifiez d'abord les règles cache et TTL dans la référence API et la documentation du provider.

OpenAI et Anthropic comptent le cache différemment

Le même mot cache ne désigne pas le même mécanisme.

Prompt caching OpenAI

Dans les API et modèles OpenAI pris en charge, le caching s'applique automatiquement au prefix approprié. Usage affiche les tokens cachés dans les détails d'input. Le code ne crée généralement pas d'objet cache séparé, mais doit garder le prefix commun intact. Seuils, rétention et remises exacts se vérifient sur la page officielle Prompt Caching.

Prompt caching Anthropic

Anthropic Messages permet de marquer la frontière cache avec cache_control. Usage peut afficher séparément création et lecture de cache. Taille minimale, TTL, ordre des blocs et coût dépendent du contrat et modèle actuels; vérifiez-les dans la documentation Anthropic.

Ne transférez ni noms de champs Usage ni coefficients entre les deux protocoles. Dans le tableau d'expérience, notez exactement les catégories renvoyées par l'endpoint actuel.

Préparer un prefix stable

Collectez l'entrée en deux parties :

STABLE_PREFIX
  instructions système
  définitions de tools, si nécessaires
  document de référence inchangé

DYNAMIC_SUFFIX
  question utilisateur actuelle

Pour la première expérience, retirez plutôt tools et streaming. Ils n'empêchent pas automatiquement le cache, mais ajoutent des variables dans usage et output.

Le prefix doit être assez long selon les règles du modèle choisi. Sous le seuil minimal, l'absence de cache hit est le résultat attendu. Ne l'allongez pas avec du texte vide en production; pour l'essai utilisez un vrai document déjà répété dans le problème.

Avant l'appel, sauvegardez le hash de la partie cachée :

import hashlib

prefix_hash = hashlib.sha256(STABLE_PREFIX.encode("utf-8")).hexdigest()
print(prefix_hash)

Le hash confirme que A et B ont reçu le même prefix sans publier son contenu.

Champs à noter

Pour chaque requête, stockez :

• timestamp et request ID;
• Model ID et protocole;
• prefix_hash;
• regular input tokens;
• tokens de cache creation/write si le contrat les sépare;
• tokens de cache read/cached si le contrat les sépare;
• output tokens;
• consommation réelle;
• statut et latence uniquement pour diagnostic.

La latence ne prouve pas le prix. Une réponse rapide peut être un miss, un hit peut attendre en file. La conclusion de coût vient de usage et tarif.

Formule de la première requête

Notons :

I  — regular input tokens
W  — cache write / creation tokens
R  — cache read / cached tokens
O  — output tokens
Pi — prix input régulier par 1 000 000 tokens
Pw — prix cache write par 1 000 000 tokens
Pr — prix cache read par 1 000 000 tokens
Po — prix output par 1 000 000 tokens

Pour un endpoint qui sépare ces catégories :

cost = I / 1_000_000 × Pi
     + W / 1_000_000 × Pw
     + R / 1_000_000 × Pr
     + O / 1_000_000 × Po

Dans la première requête, W et R peuvent être supérieurs à zéro. Avec caching automatique, les champs peuvent différer : utilisez input non caché et caché de l'usage réel, sans inventer de catégorie.

La première requête peut coûter plus cher qu'une requête sans cache si la création est facturée séparément. Ce n'est pas une erreur en soi. La rentabilité commence après assez de lectures.

Formule de répétition et point de rentabilité

Soit :

C0 — coût de la première requête qui crée le cache
Ch — coût d'une requête avec cache hit
Cu — coût d'une requête comparable sans cache
n  — nombre total de requêtes

Série avec une création et n - 1 hits :

C_cached(n) = C0 + (n - 1) × Ch
C_uncached(n) = n × Cu

Le plus petit n où le cache devient rentable est le premier entier qui vérifie :

C_cached(n) < C_uncached(n)

N'utilisez pas les prix d'un autre modèle dans cette formule. Si Ch >= Cu, la configuration actuelle n'apporte pas d'économie; contrôlez cache hit, taille du prefix et catégories tarifaires.

Cache miss de contrôle

Après A et B, exécutez C. Modifiez seulement le prefix caché, en gardant modèle et longueur de réponse attendue. La catégorie cache read doit diminuer ou disparaître conformément au contrat, et traitement normal ou création cache doit changer.

Causes d'un miss inattendu :

• symbole ou espace modifié dans le prefix;
• définitions de tools dans un ordre différent;
• bloc système déplacé;
• modèle ou endpoint modifié;
• requête hors TTL;
• prefix plus court que le seuil minimum;
• client sérialise les mêmes données dans un autre ordre.

Changer la question après un prefix stable est attendu. Changer l'intérieur du prefix crée une autre identité de cache.

Pourquoi nous ne publions pas de « résultat en dollars »

Cet article n'a pas accès à API Key ni à l'usage d'un compte donné; il ne fournit donc pas d'exemple calculé pour le test effectué. Prix, modèles et règles de cache changent. Un nombre arbitraire transformerait vite une expérience reproductible en publicité périmée.

Pour votre résultat :

1. Choisissez un modèle et un protocole.
2. Ouvrez la page BetterToken pricing actuelle.
3. Exécutez A, B et C.
4. Relevez usage et consommation dans Dashboard.
5. Calculez C0, Ch, Cu et le point de rentabilité.
6. Conservez la date de contrôle et prefix_hash.

FAQ

Pourquoi la première requête avec cache peut-elle coûter plus ?

Certains protocoles facturent séparément cache creation/write. Le supplément initial n'est compensé que par des cache reads répétés. Consultez le prix actuel du modèle précis.

Pourquoi la requête répétée n'a-t-elle pas reçu de cache hit ?

Contrôlez longueur et immutabilité du prefix, ordre des blocs, modèle, endpoint, TTL et seuil minimum. Comparez prefix_hash.

Peut-on comparer OpenAI et Anthropic avec un champ Usage ?

Non. Mécanismes, configurations et catégories diffèrent. Normalisez les valeurs dans vos champs I, W, R et O, tout en conservant les champs originaux.

Cache réduit-il toujours le coût ?

Non. Prefix court, répétitions rares, changements fréquents et faible taux de hit peuvent ne pas compenser la création du cache.

Où vérifier le débit réel BetterToken ?

Dans Dashboard par heure, modèle et statut de requête. Prenez le tarif sur la page pricing et les règles de cache dans la documentation du protocole concerné.