Prompt caching
Définition
Mise en cache des parties stables d'un prompt (instructions système, documentation répétée) pour réduire fortement le coût et la latence des appels suivants. Disponible chez Anthropic et OpenAI.
Comment ça marche
Le prompt caching permet de réutiliser le calcul d'attention d'une partie stable d'un prompt entre plusieurs appels API. Lors du premier appel, le fournisseur calcule l'état interne du modèle après avoir traité votre contexte stable (system prompt, documentation, exemples few-shot), puis stocke cet état chiffré pendant quelques minutes. Aux appels suivants utilisant exactement le même prefix, le modèle reprend cet état sans le recalculer, ce qui économise du compute et du temps. Le résultat : la partie cachée est facturée 5 à 10 fois moins cher que la version non cachée, et la latence du premier token chute de plusieurs centaines de millisecondes.
Anthropic versus OpenAI
Les deux fournisseurs majeurs ont des approches différentes. Chez Anthropic, le caching est explicite : on marque les segments à cacher avec cache_control dans la requête, et on choisit la durée (5 minutes ou 1 heure pour le cache étendu). Chez OpenAI, le caching est automatique sur les modèles compatibles : si plus de 1024 tokens initiaux sont identiques entre deux requêtes, le cache s'active sans configuration. L'avantage Anthropic : contrôle fin et durée plus longue. L'avantage OpenAI : zéro configuration, ça marche tout seul. Google Vertex AI propose un mécanisme similaire à Anthropic, avec déclaration explicite.
Quand l'utiliser
Le caching devient rentable dès qu'un même contexte stable revient au moins quelques fois par minute. Cas typiques : assistants conversationnels avec long system prompt (instructions, persona, exemples), agents qui chargent la même documentation à chaque tour, traitement par lot avec consignes répétées, RAG qui injecte les mêmes blocs de contexte sur des questions différentes. Pour un volume sérieux, l'économie atteint facilement 60 à 80% du coût total des appels. À l'inverse, sur des appels uniques ou très variés, le caching n'apporte rien : le cache ne sera pas hit, et on paie les tokens de marquage en plus.
Comment structurer son prompt
La règle d'or : tout ce qui est stable au début, tout ce qui varie à la fin. Le caching ne fonctionne que sur un prefix exact : si vous changez ne serait-ce qu'un caractère dans la partie cachée, elle se recalcule entièrement et vous perdez tout le bénéfice. On structure donc : system prompt (instructions générales) → documentation cachée (RAG, exemples) → marqueur de cache → question utilisateur (qui varie). Pour les agents, on cache l'historique stable et on ajoute uniquement le nouveau tour à chaque itération. Une mauvaise structure annule complètement le gain : c'est de la conception, pas de la magie.
Les coûts détaillés
L'écriture dans le cache coûte légèrement plus cher qu'un input standard (environ 25% de surcoût). La lecture depuis le cache coûte 10 fois moins cher qu'un input standard chez Anthropic, plus du même ordre chez OpenAI. Donc dès qu'un même contexte est utilisé deux fois et demi, l'opération devient rentable. Pour un chatbot avec 100 conversations en parallèle qui partagent le même system prompt, on économise typiquement 70 à 80% du coût de cette partie. Sur un produit qui consomme des milliers de dollars par mois en LLM, le caching peut diviser la facture par trois sans changer la qualité.
Les limites et les pièges
Le cache expire après 5 minutes (ou 1 heure en option payante chez Anthropic) sans utilisation. Sur un trafic irrégulier, beaucoup d'appels manquent le cache. La taille minimale pour activer le caching est non négligeable : 1024 tokens minimum chez OpenAI, segments suffisamment longs chez Anthropic. En dessous, ça ne s'active pas. Côté monitoring, on suit le taux de cache hit dans les usage reports : si on est sous 50%, c'est qu'on a mal structuré son prompt ou que le trafic est trop dispersé. Et attention aux changements de version de modèle : un cache calculé sur claude-sonnet-4 ne fonctionne pas sur claude-sonnet-4.5.