La plupart des équipes qui mettent un LLM en production découvrent trop tard que leur facture mensuelle est dominée à 70 % par la retransmission du même contexte à chaque requête. Un prompt système de 4 000 tokens renvoyé 50 000 fois par jour, c’est 200 millions de tokens d’entrée facturés — alors que ce contexte ne change jamais. Le prompt caching, généralisé depuis fin 2024 chez les principaux fournisseurs d’API (Anthropic, OpenAI, Google), permet de ramener ce coût à moins de 10 % du prix standard sur la portion mise en cache. Combiné à une optimisation du throughput en tokens par seconde (TPS), il transforme littéralement l’économie d’une application LLM à grande échelle. Comment construire un système de reranking pour améliorer la pertinence d'un RAG en production
À retenir en 30 secondes : le prompt caching conserve en mémoire côté fournisseur les représentations internes (KV cache) des portions stables du prompt, pour ne refacturer que les tokens réellement nouveaux. Résultat typique : -75 à -90 % sur le coût d’entrée, -40 à -60 % sur la latence de première réponse (TTFT), et un throughput global multiplié par 2 à 3 sur les workloads à contexte long et récurrent. Caching sémantique pour LLMs : réduire latence et coûts d'inférence sans sacrifier la pertinence
Comment fonctionne techniquement le prompt caching
Un LLM transformer, lors de l’inférence, calcule pour chaque token du prompt un vecteur de clés (K) et de valeurs (V) qu’il stocke dans un cache mémoire — le fameux KV cache — pour éviter de recalculer ces projections à chaque nouveau token généré. Lorsqu’une requête réutilise exactement le même préfixe qu’une requête précédente, le fournisseur peut réutiliser les KV déjà calculés plutôt que les refaire. C’est ce qu’exploite le prompt caching exposé via API : marquer explicitement les segments stables du prompt pour qu’ils soient réutilisés sur les requêtes suivantes dans une fenêtre de validité (généralement 5 minutes chez Anthropic, prolongeable à 1 heure côté OpenAI selon le modèle). LLMOps : guide complet pour déployer et opérer un LLM en production
Le principe est à rapprocher directement de ce que nous avons détaillé dans notre article sur le sparse attention et son impact sur l’efficacité des LLMs : à chaque fois qu’une optimisation permet d’éviter des calculs redondants sur la fenêtre d’attention, l’économie en latence et en coût est proportionnelle à la taille du contexte stable.
Structurer un prompt pour maximiser le hit ratio
Le hit ratio du cache dépend entièrement de la stabilité des premiers tokens du prompt. La règle fondamentale : du plus stable au plus variable. Le prompt système, les instructions globales, les exemples few-shot et les documents de référence volumineux doivent être placés en tête ; les éléments dynamiques (requête utilisateur, variables de session) en queue. Un seul token qui diffère au milieu d’un préfixe théoriquement caché invalide tout ce qui suit.
Pour une application RAG, cela implique une discipline particulière : les documents injectés dans le contexte sont souvent dynamiques, donc non cachables. Deux stratégies pragmatiques existent. La première consiste à placer les documents RAG après un préfixe système stable (instructions + exemples), qui lui reste caché. La seconde, plus avancée, est de regrouper les requêtes qui partagent les mêmes documents (batch par cluster sémantique) pour maximiser la réutilisation du cache sur les documents eux-mêmes. Cette optimisation combine naturellement avec les techniques décrites dans notre guide sur l’optimisation des coûts d’inférence LLM en production.
Optimiser le throughput en tokens par seconde (TPS)
Le TPS mesure deux choses distinctes qu’il faut absolument séparer : le TPS d’entrée (vitesse à laquelle le modèle ingère le prompt, dominée par la phase de prefill) et le TPS de sortie (vitesse à laquelle il génère les tokens de réponse, dominée par la phase de decoding). Le prompt caching améliore spectaculairement le TPS d’entrée en court-circuitant le prefill sur la portion cachée. Pour le TPS de sortie, les leviers sont différents : speculative decoding, batching dynamique côté serveur, quantization du modèle et attention optimisée (FlashAttention, PagedAttention). Speculative decoding : accélérer l'inférence LLM par un facteur 2 à 3 sans compromis sur la qualité
Dans une architecture self-hosted sur vLLM ou TGI, la combinaison prompt caching + continuous batching + PagedAttention peut multiplier le throughput global par 5 à 10 sur un même parc GPU par rapport à une implémentation naïve. En API managée, le gain reste significatif mais plafonné par la politique du fournisseur.
Les patterns d’application qui en bénéficient le plus
Quatre familles d’applications voient leur ROI transformé par le prompt caching. Les chatbots conversationnels à prompt système lourd (instructions complètes, personae, règles métier) économisent dès la deuxième requête d’une session. Les agents d’analyse de documents qui posent plusieurs questions sur un même document long cachent le document une fois et paient seulement les questions. Les pipelines batch qui exécutent le même prompt sur des milliers d’inputs légèrement différents voient leur coût d’entrée divisé par 10. Enfin, les applications multi-turn à mémoire longue (type assistant personnel qui conserve l’historique) deviennent économiquement viables à grande échelle. KV cache management : la clé pour maîtriser la mémoire GPU dans les déploiements LLM à grande échelle
Pièges opérationnels à anticiper
Le prompt caching n’est pas gratuit : la mise en cache initiale est généralement facturée plus cher que l’inférence standard (environ 1,25× chez Anthropic). Le gain se matérialise seulement si le préfixe est réutilisé plusieurs fois. Les équipes qui activent le caching sur des requêtes jamais répétées augmentent paradoxalement leur facture. Un deuxième piège concerne l’invalidation : certains fournisseurs refacturent la totalité du préfixe si la session dépasse la fenêtre de validité. Monitorer précisément le hit ratio devient donc indispensable, idéalement via des traces OpenTelemetry qui mesurent la part de tokens d’entrée réellement facturée en mode cache vs. standard. Les équipes qui déploient à grande échelle gagnent à mettre en place une alerte dès que le hit ratio tombe sous un seuil critique (typiquement 70 %). Long-context LLMs : techniques et limites pour exploiter réellement 1 million de tokens en production
Pour aller plus loin sur les mécaniques de contexte qui rendent cette optimisation possible, consultez notre analyse de la gestion du context window d’un LLM en production, ainsi que la documentation officielle d’Anthropic sur le prompt caching.
Mon point de vue d’expert
Je vois trop d’équipes françaises arbitrer entre « LLM puissant mais cher » et « LLM moyen mais abordable » sans jamais activer le prompt caching. Pourtant, c’est l’optimisation à meilleur ROI de toute la stack IA : quelques heures d’implémentation, zéro impact sur la qualité, et une facture divisée par 5 à 10 sur les workloads adaptés. Mon conseil pour les équipes qui démarrent : auditez d’abord la structure de vos prompts (prompt système, few-shot, historique conversationnel) et identifiez la portion stable. Si elle représente plus de 1 000 tokens et que vos appels sont récurrents, activez le caching dès le prototype. Vous bâtirez une architecture économiquement saine dès le jour un, au lieu de devoir rétro-ingénierer vos prompts dans la panique quand la facture AWS arrive.
FAQ : prompt caching et optimisation TPS
- Quelle économie réelle peut-on attendre du prompt caching ?
- Sur un workload où le préfixe stable représente 80 % du prompt total et où ce préfixe est réutilisé au moins 5 fois dans la fenêtre de cache, la réduction du coût d’entrée atteint typiquement 75 à 90 %. Pour un chatbot avec prompt système de 3 000 tokens et 10 tours de conversation moyens, le gain net sur la facture mensuelle est généralement compris entre 60 et 75 %.
- Le prompt caching dégrade-t-il la qualité des réponses ?
- Non, le caching ne modifie pas le calcul du modèle : il réutilise les mêmes représentations internes que celles qui auraient été calculées sans cache. Les sorties sont strictement identiques à celles d’une inférence non cachée sur le même prompt. L’économie porte uniquement sur le temps et le coût de recalcul.
- Comment mesurer le hit ratio en production ?
- Les API renvoient dans leur réponse les compteurs de tokens d’entrée distincts : tokens standard, tokens créés en cache (cache write) et tokens lus depuis le cache (cache read). Un hit ratio sain se calcule comme cache_read / (cache_read + cache_write + standard). Un ratio supérieur à 70 % est le seuil au-dessus duquel l’optimisation devient économiquement intéressante.
- Prompt caching et RGPD : y a-t-il un enjeu ?
- Le cache étant stocké côté fournisseur dans sa propre infrastructure, l’enjeu RGPD rejoint celui du traitement général par l’API. Si le préfixe caché contient des données personnelles, elles sont conservées temporairement dans le cache du fournisseur. Les contrats de traitement (DPA) des principaux fournisseurs couvrent ce stockage transitoire. En pratique, concevez vos préfixes stables pour qu’ils ne contiennent que des instructions et des exemples non-nominatifs ; placez les données personnelles dans la portion dynamique du prompt.