Guide complet du Prompt Caching : principes, modèle de coûts et mise en œuvre

Quel problème résout le prompt caching

Dans l'entrée de la plupart des appels LLM, une part considérable est identique à chaque fois : prompt système, exemples few-shot, documents fixes issus de la recherche, définitions d'outils (tool schema). Avec la facturation normale, ce contenu répété est refacturé en tokens d'entrée à chaque appel, et l'attention est recalculée à chaque fois.

L'idée du prompt caching est directe : le serveur conserve le résultat de calcul de ce préfixe et, si le préfixe d'une requête suivante est identique, le réutilise directement en ne recalculant que la partie nouvelle. Anthropic le présente dans sa [documentation prompt caching](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) comme un moyen de réduire la latence et les coûts ; côté OpenAI, les mécanismes correspondants sont le prompt caching automatique et les remises batch.

Les scénarios où l'on économise réellement

Le prompt caching n'est pas un interrupteur qui fait économiser dès qu'on l'active. Il a une frontière de rentabilité claire : nombre de réutilisations d'un même préfixe × longueur du préfixe > surcoût d'écriture du cache.

• Long prompt système + conversation multi-tours : un prompt système de plusieurs milliers de tokens avec de nombreux tours de conversation est presque toujours rentable.
• RAG + ensemble de documents fixes : placez les documents de politique/base de connaissances invariants en préfixe et ne faites varier que la question de l'utilisateur.
• Agent de code / appels d'outils : le schéma des outils et la description de la structure du dépôt sont généralement répétés à chaque appel.
• Appels uniques avec préfixe court : le coût d'écriture du cache peut dépasser l'économie ; ne forcez pas la mise en cache.

Cinq erreurs courantes qui invalident le cache

• Insérer un horodatage ou un ID aléatoire dans le préfixe : même si Date.now() n'apparaît qu'à un endroit fixe, tout le préfixe change.
• Concaténer dynamiquement le prompt système : chaque utilisateur obtient un préfixe différent et le taux de succès du cache tombe près de 0.
• Résumer/compresser les messages historiques : réécrit à chaque tour, le préfixe devient instable.
• Placer l'entrée utilisateur au tout début : c'est l'erreur de structure la plus fréquente ; les variables doivent être le plus possible à la fin.
• Ne regarder que la facture sans le taux de succès : sans indicateur de taux de succès, le gain du cache est impossible à attribuer.

Réutiliser une même stratégie de cache entre plusieurs modèles

Si votre produit utilise à la fois Claude et GPT, la sémantique du cache n'est pas parfaitement identique entre fournisseurs (qui déclare les points de rupture du cache, durée du TTL, mode de facturation). Regrouper cette adaptation derrière une passerelle unifiée permet au code métier de ne maintenir qu'une seule structure de prompt, sans réécriture lors du changement de modèle.

La passerelle Admesh conserve en aval un protocole compatible OpenAI : une même structure de prompt peut donc passer d'un fournisseur à l'autre en changeant uniquement le champ model ; la facturation des succès de cache est unifiée dans le détail usage de la facture, sans intégration de facturation séparée par fournisseur.

Voir les unités de facturation et les tokens de cache →

Liste de mise en œuvre

1. Découpez le prompt en trois parties : « préfixe stable / partie semi-stable / entrée utilisateur », la partie stable en premier.
2. Assurez-vous qu'aucun horodatage, nombre aléatoire ou ID utilisateur n'apparaît dans le préfixe stable.
3. Comptez séparément dans la facture les tokens de lecture et d'écriture du cache, et convertissez-les en taux de succès réel.
4. Faites une régression régulière avec un ensemble fixe de requêtes d'évaluation pour vérifier que les modifications de prompt n'ont pas cassé le taux de succès.
5. Fixez un seuil minimal de gain du cache (par exemple revenir en arrière sur la structure du prompt en dessous de 5 %) pour éviter l'optimisation pour l'optimisation.