Aller au contenu principal

Mise en cache des prompts entre fournisseurs

Avancé

La mise en cache des prompts est le plus grand levier de réduction de coûts d'une application LLM en production — typiquement une réduction de plus de 90 % côté entrée. Tous les fournisseurs majeurs l'ont désormais. Cela donne facilement l'impression que c'est la même fonctionnalité partout, et ce n'est pas le cas.

Le mécanisme est identique : le fournisseur réutilise le préfixe déjà traité de votre prompt au lieu de le relire. Ce qui diffère, c'est qui décide, combien de temps le cache reste vivant, quelle longueur un préfixe doit atteindre pour être éligible, et — celui qui mord — si vous payez ou non une prime pour l'écrire. Une charge de travail réglée sur un fournisseur peut silencieusement cesser de mettre en cache, ou coûter plus cher que sans cache du tout, chez le fournisseur suivant.

What you'll learn
  • Distinguer les deux modèles de contrôle — points d'arrêt explicites vs détection automatique du préfixe — et ce que chacun vous coûte
  • Lire le tableau comparatif entre fournisseurs : préfixe minimum, TTL, remise en lecture, prime d'écriture, et le champ d'usage qui prouve un hit
  • Appliquer la règle de rentabilité portable : combien de réutilisations dans le TTL avant que la mise en cache soit rentable
  • Éviter les cinq pièges qui tuent silencieusement un cache quand vous migrez une charge de travail entre fournisseurs
  • Vérifier un taux de hit réel sur n'importe quel fournisseur à partir de l'usage renvoyé dans la réponse, pas de la documentation

Si vous ne travaillez qu'avec Claude, lisez d'abord Mise en cache des prompts et optimisation des coûts — elle explique en profondeur le mécanisme cache_control. Cette page est la couche de portabilité au-dessus.

Les deux modèles de contrôle​

Tout dans ce domaine relève de l'un de ces deux designs, et le design détermine votre mode de défaillance.

Explicite (Anthropic) : vous attachez un marqueur au dernier bloc stable. Rien n'est mis en cache tant que vous ne le demandez pas. Vous obtenez un contrôle exact sur la frontière et pouvez en placer plusieurs. Vous héritez aussi du bug : un prompt sans point d'arrêt paie plein tarif pour toujours, et rien ne vous avertit.

Automatique (OpenAI, la mise en cache implicite de Google, DeepSeek) : le fournisseur hache votre préfixe et réutilise ce qu'il peut. Rien à configurer, et rien à corriger en cas d'échec. Votre seul levier est la disposition du prompt — placer le contenu stable en premier — plus, chez OpenAI, un indice de routage.

Le levier que vous gardez dans les deux modèles

L'ordre du préfixe est le seul contrôle qui fonctionne partout. Le contenu stable en premier, le contenu volatil en dernier. Sur les systèmes explicites, il détermine où votre point d'arrêt peut se placer ; sur les systèmes automatiques, c'est la seule chose que vous contrôlez.

Le tableau comparatif entre fournisseurs​

Anthropic (Claude)OpenAIGoogle (Gemini)DeepSeek
Contrôlecache_control explicite, jusqu'à 4 points d'arrêtAutomatique, correspondance de préfixeImplicite par défaut ; objets de cache explicites également disponiblesAutomatique, sur disque
Préfixe minimum512 tokens sur Fable 5.1 / Mythos 5.1 / Opus 5.5 / Opus 5 / Fable 5 / Mythos 5 ; 1 024 sur Sonnet 5 et Opus 4.8 ; 2 048–4 096 sur les modèles plus anciens1 024 tokens sur GPT-5.6 et versions ultérieures ; varie selon les paramètres de requête avant cela4 096 tokens sur Gemini 3.5–3.8 Flash et 3.1 Pro Preview ; 2 048 sur Gemini 2.5 Flash / ProNon publié comme un nombre de tokens — les unités de cache se situent aux frontières de requête, aux préfixes communs détectés, et à des intervalles de tokens fixes
TTL5 minutes par défaut ; 1 heure en option30 minutes par défaut sur GPT-5.6+ via prompt_cache_options.ttl ; les modèles antérieurs utilisent prompt_cache_retention — en mémoire (typiquement 5–10 min) ou 24hPas de valeur par défaut fixe publiée pour la mise en cache impliciteÉviction automatique « en quelques heures à quelques jours » une fois inutilisé
Lecture du cache0,1× le prix d'entrée de base ; 0,05× sur Opus 5.5 ; 0,025× sur Fable 5.1 / Mythos 5.10,1× le prix d'entrée de basePublié comme un tarif d'entrée mise en cache séparé (0,1× le tarif standard sur Gemini 3.8 Flash jusqu'au 2026-12-31)Tarif d'entrée en cas de hit séparé, environ 1/30e du tarif en cas de miss sur deepseek-v4-pro
Prime d'écriture du cache1,25× le prix d'entrée de base pour le palier de 5 minutes ; 2× pour le palier d'1 heure1,25× le prix d'entrée de base sur GPT-5.6+Aucune pour la mise en cache implicite ; la mise en cache explicite facture le stockage à 0,50 $ par million de tokens par heure sur Gemini 3.8 Flash jusqu'au 2026-12-31Aucune publiée
Preuve d'un hitcache_read_input_tokens et cache_creation_input_tokens dans usageNombre de tokens mis en cache dans usageusage.total_cached_tokensprompt_cache_hit_tokens et prompt_cache_miss_tokens
Comptabilité / indice de routagePlacement du point d'arrêtprompt_cache_key — comptabilité de cache séparée sur GPT-5.6+, routage de cache avant cela——

Pour les modèles open source auto-hébergés, la même idée existe un niveau plus bas sous forme de mise en cache de préfixe dans le moteur de service : vLLM et SGLang réutilisent des blocs de KV-cache pour un préfixe partagé. Il n'y a pas de prix par token, donc pas de seuil de rentabilité à calculer — le coût est la VRAM, et le gain est la latence de prefill, pas la facture. vLLM l'expose via enable_prefix_caching ; sur le moteur V1, c'est activé par défaut, donc sur une version actuelle vous êtes plus susceptible de devoir le désactiver que l'inverse. Voir Exécuter des modèles localement avec Ollama et Une pile IA locale privée.

La règle de rentabilité​

Voici la partie que la documentation des fournisseurs laisse en exercice. La mise en cache n'est pas gratuite sur les systèmes explicites, et depuis GPT-5.6 elle ne l'est plus non plus chez OpenAI. Une prime d'écriture signifie qu'un préfixe que vous ne réutilisez qu'une seule fois peut vous coûter plus cher que de ne pas le mettre en cache.

Soit P ce que le préfixe coûterait au tarif d'entrée de base, w le multiplicateur d'écriture, r le multiplicateur de lecture, et N le nombre d'appels qui partagent le préfixe à l'intérieur d'une même fenêtre de TTL.

Without caching:  N · P
With caching:     w · P  +  (N − 1) · r · P

Caching wins when:   w + (N − 1) · r  <  N
Which solves to:     N  >  (w − r) / (1 − r)

Insérez les multiplicateurs publiés :

PalierwrN de rentabilitéRéutilisations nécessaires
Anthropic 5 minutes, Opus 5.51,250,051,262 appels
Anthropic 5 minutes, palier de lecture standard1,250,11,282 appels
Anthropic 1 heure20,12,113 appels
OpenAI GPT-5.6+1,250,11,282 appels
Automatique, sans prime d'écriture10,101 appel — jamais de perte

La règle empirique tient donc en une phrase : deux hits à l'intérieur du TTL et vous êtes gagnant ; visez trois avant d'acheter le palier d'1 heure. En dessous, mettre un préfixe en cache est une petite perte silencieuse.

Pro tip
  • N compte les appels à l'intérieur d'une même fenêtre de TTL, pas les appels par jour. Un préfixe réutilisé 1 000 fois par jour en rafales espacées de 20 minutes repaie l'écriture à chaque rafale.
  • Le palier d'1 heure n'est pas une amélioration automatique. Il double la prime d'écriture pour obtenir une fenêtre 12 fois plus longue — cela n'en vaut la peine que si votre trafic est réellement épars.

Exemple concret : un préfixe de 50k tokens, 1 000 appels par jour​

Sur Claude Opus 5.5 — entrée de base 4 $/MTok, écriture 5 minutes 5 $/MTok, lecture 0,20 $/MTok, tous tirés du tableau de tarification d'Anthropic :

Guided walkthrough1 of 4
  1. 50 000 tokens x 1 000 appels = 50M tokens d'entrée. À 4 $/MTok, cela fait 200 $/jour, chaque jour, pour un contenu qui n'a jamais changé.

Le point pédagogique est l'étape 3 face à l'étape 2 : le même volume d'appels, le même préfixe, et une différence de facture de 3,3 fois, décidée entièrement par le motif d'arrivée face au TTL. Le motif d'arrivée est la variable que personne ne met dans le tableur.

Cinq pièges lors de la migration d'une charge de travail​

Watch out
  • Écart de TTL : un job qui tourne toutes les 10 minutes obtient un hit sur le TTL par défaut de 30 minutes d'OpenAI et un miss sur le TTL par défaut de 5 minutes d'Anthropic. Même code, même prompt, taux de hit nul.
  • Écart de seuil : un prompt système de 2 500 tokens se met en cache sur Claude Opus 5.5 (minimum de 512 tokens) et sur GPT-5.6 (1 024) mais pas sur Gemini 3.8 Flash (4 096). L'échec est silencieux — aucune erreur, juste une facture plein tarif.
  • Écart d'invalidateurs : chaque fournisseur invalide sur un préfixe modifié, mais les déclencheurs non évidents diffèrent. Chez Anthropic, modifier les définitions d'outils, tool_choice, ou (selon le modèle) les paramètres de thinking et d'effort invalide le cache. Chez OpenAI, modifier le modèle, les définitions d'outils, les schémas, l'effort de raisonnement, la verbosité, ou la compaction de contexte le fait.
  • Écart de prime d'écriture : migrer un préfixe à faible réutilisation d'un fournisseur automatique vers un fournisseur explicite peut le rendre plus coûteux que l'absence de cache. Appliquez la règle de rentabilité ci-dessus avant de marquer un point d'arrêt.
  • Écart d'observabilité : les noms des champs d'usage ne suivent aucune convention commune. Tout tableau de bord qui analyse les champs de cache d'un fournisseur a besoin d'un adaptateur par fournisseur, sinon votre taux de hit apparaît comme nul après une migration.

Le seul mécanisme spécifique à Anthropic sans équivalent ailleurs : le cache est recherché sur une fenêtre de rétrospection de 20 blocs par point d'arrêt. Une conversation qui grandit régulièrement peut dépasser cette fenêtre et cesser d'obtenir des hits même si le préfixe est inchangé — voir Économie de la mise en cache des prompts pour les règles d'invalidation en détail.

Vérifiez-le, ne le supposez pas​

La documentation décrit une intention ; usage décrit ce qui vous a été facturé. Vérifiez le taux de hit réel sur chaque fournisseur que vous utilisez.

Auditer le taux de hit de cache d'une charge de travail

Audit prompt caching for this codebase.

1. List every place we call an LLM API, with the provider and model.
2. For each call site, identify the prefix that is stable across calls
 and anything volatile that appears BEFORE it (timestamps, user IDs,
 reordered tool lists, freshly serialized JSON with unstable key order).
3. Report the token length of each stable prefix and compare it to that
 provider's minimum cacheable length. Flag any prefix below it.
4. Estimate the typical gap between consecutive calls sharing each prefix
 and compare it to that provider's cache TTL. Flag any gap that exceeds it.
5. Show me where we read the cache fields back from the response usage.
 If we never read them, say so plainly — that is the finding.

Do not change any code. Give me a table of call site, provider, prefix
tokens, minimum, typical gap, TTL, and the fields we read.

Deux signatures d'échec à connaître, car elles se ressemblent sur un tableau de bord mais ont des correctifs opposés :

  • Tokens mis en cache toujours à zéro sur des requêtes répétées qui devraient partager un préfixe → une valeur volatile se trouve avant votre contenu stable, ou le préfixe est sous le minimum. Comparez les octets du prompt rendu entre deux appels.
  • Tokens mis en cache non nuls mais la facture a à peine bougé → le préfixe est mis en cache mais il est court par rapport à votre suffixe volatil. La mise en cache fonctionne ; ce n'est simplement pas là que va votre argent. Regardez les tokens de sortie et pourquoi les agents consomment des tokens à la place.
Retenez les termes
Appuyez sur Entrée ou Espace pour retourner la carte. Utilisez les flèches gauche et droite pour naviguer entre les cartes.Terme affiché.
1 / 6

Vérifiez-vous

0/4
  1. Un préfixe sera réutilisé exactement deux fois à l'intérieur de la fenêtre. Quel palier est le mauvais choix ?
  2. Un prompt système de 2 500 tokens se mettait bien en cache sur Claude et a cessé de le faire après une migration vers Gemini 3.8 Flash. Cause la plus probable ?
  3. Même prompt, mêmes 1 000 appels par jour. Pourquoi la facture triplerait-elle ?
  4. Les tokens mis en cache lus sont non nuls, mais la facture a à peine bougé. Que cela vous indique-t-il ?
Key takeaways
  • Deux designs, deux modes de défaillance : la mise en cache explicite échoue en n'étant jamais marquée ; la mise en cache automatique échoue silencieusement et vous ne pouvez pas forcer un hit.
  • La mise en cache n'est pas automatiquement gratuite. Avec une prime d'écriture, il faut N > (w - r) / (1 - r) réutilisations à l'intérieur d'un TTL — deux appels pour les paliers de 5 minutes, trois pour le palier d'1 heure d'Anthropic.
  • Le motif d'arrivée face au TTL, pas le volume d'appels, décide de la facture : les mêmes 1 000 appels quotidiens coûtent environ 10 $ répartis uniformément et environ 34 $ en rafales sur Opus 5.5.
  • La longueur minimale de préfixe s'étend de 512 à 4 096 tokens selon les fournisseurs — un prompt qui se met en cache sur Claude peut silencieusement cesser de le faire sur Gemini Flash.
  • Prouvez le taux de hit à partir de l'usage renvoyé dans la réponse sur chaque fournisseur ; les noms de champs ne suivent aucune convention commune, donc un tableau de bord a besoin d'un adaptateur par fournisseur.
  • Le contenu stable en premier, le contenu volatil en dernier. C'est le seul levier qui fonctionne sur tous les fournisseurs, y compris la mise en cache de préfixe auto-hébergée.

Sources et lectures complémentaires​

Suite​