La mise en cache des prompts réduit les coûts d'inférence IA jusqu'à 90 pour cent, et la plupart des équipes ne l'utilisent pas correctement

La plupart des équipes qui paient pour l'accès à l'API des grands modèles de langage (LLM) laissent filer entre 50 et 90 pour cent d'économies potentielles, alors que le mécanisme pour les capturer existe en production depuis plus d'un an. La mise en cache des prompts permet à un fournisseur d'API de réutiliser le calcul déjà effectué pour les parties invariables d'une requête — instructions système, définitions d'outils (tools), documents de référence longs — au lieu de les retraiter à chaque appel.

Le problème n'est pas que la mise en cache des prompts ne fonctionne pas. C'est que la plupart des équipes d'ingénierie structurent leurs prompts d'une manière qui l'annule avant même qu'elle ait une chance d'aider, puis concluent que la fonctionnalité "n'a rien changé" pour leur cas d'usage.

Comment le cache fonctionne réellement

Lorsqu'un modèle transformer traite un prompt, il calcule des paires clé-valeur (KV) pour chaque token d'entrée — les représentations internes que le modèle utilise pour prédire le token suivant. Ce calcul est la partie coûteuse de l'inférence, dont le coût croît avec la longueur de l'entrée. La mise en cache des prompts stocke ces paires KV sur les serveurs du fournisseur après une première requête, indexées exactement sur le même préfixe de tokens qui les a produites.

Lors d'une requête ultérieure, si le nouveau prompt partage ce même préfixe, le fournisseur évite de recalculer les paires KV pour la partie commune et ne traite que les nouveaux tokens ajoutés à la fin. L'implémentation d'Anthropic, par exemple, facture environ 10 pour cent du tarif de base des tokens d'entrée pour les lectures de cache et environ 25 pour cent de plus que le tarif de base pour l'écriture initiale du cache — un compromis rapidement rentable pour tout préfixe réutilisé plus de deux fois. La mise en cache automatique des prompts d'OpenAI applique une réduction de 50 pour cent sur les tokens d'entrée mis en cache sans coût d'écriture séparé, et la mise en cache de contexte de Google sur les modèles Gemini fonctionne de manière similaire via un objet de cache explicite que l'on crée et référence.

D'où viennent réellement les économies

Les économies ne sont pas théoriques. Un agent de support client qui inclut un prompt système de 3 000 tokens, un extrait de base de connaissances produit de 5 000 tokens et un ensemble de définitions d'outils de 2 000 tokens à chaque appel paie pour 10 000 tokens d'entrée avant même que la vraie question de l'utilisateur — peut-être 50 tokens — n'entre en jeu. Pour une application à fort volume traitant des dizaines de milliers de requêtes par jour, cette surcharge éclipse largement le coût marginal de la requête elle-même.

Avec un cache correctement configuré, ce préfixe de 10 000 tokens est calculé une fois puis lu depuis le cache à chaque appel suivant dans la fenêtre de durée de vie du cache (TTL, généralement 5 minutes sur le niveau standard d'Anthropic, extensible jusqu'à une heure chez certains fournisseurs). L'effet pratique pour un pipeline RAG avec une large fenêtre de contexte récupéré, ou un agent avec un schéma d'appel d'outils étendu, est une réduction de 60 à 80 pour cent du coût d'entrée effectif — sans aucun changement de la qualité du modèle, du comportement de sortie, ou de la latence perceptible par un utilisateur. La latence s'améliore même légèrement, puisque les tokens en cache court-circuitent entièrement le forward pass.

L'erreur qui tue le taux de succès du cache

La mise en cache des prompts ne fonctionne que sur des correspondances exactes de préfixe. Si un seul token change n'importe où avant la limite mise en cache, toute l'entrée de cache échoue (miss) et le fournisseur recalcule depuis zéro. C'est là que la plupart des implémentations se sabotent silencieusement elles-mêmes.

Le schéma d'échec le plus courant : placer du contenu dynamique — un horodatage, un ID de session, une liste de documents récupérés dans un ordre aléatoire — près du début du prompt, avant les instructions système statiques et les définitions d'outils. Chaque requête a alors un préfixe unique, et le cache n'a jamais l'occasion d'accumuler des succès. La solution est mécanique mais exige de la discipline : structurer chaque prompt pour que le contenu statique vienne en premier (instructions système, exemples few-shot, schémas d'outils, documents de référence stables) et le contenu variable en dernier (le message réel de l'utilisateur, la date actuelle si nécessaire, l'état spécifique à la session).

Une deuxième erreur courante est la personnalisation excessive du prompt. Les équipes qui injectent des préférences spécifiques à l'utilisateur ou des détails de compte directement dans le prompt système — plutôt que de les transmettre comme un bloc séparé et clairement délimité après le préfixe cachable — détruisent leur propre taux de succès de cache pour une amélioration marginale de qualité souvent même pas mesurable. Si les données de personnalisation changent par utilisateur ou par session, elles doivent se trouver après la limite du cache, et non tissées dans les instructions partagées.

Le contexte récupéré est le cas le plus difficile

Les applications RAG font face à une tension architecturale réelle : tout l'intérêt de la récupération est de faire apparaître des documents différents pour des requêtes différentes, ce qui brise par définition la correspondance de préfixe sur le contenu récupéré lui-même. La solution la plus efficace ici n'est pas de mettre en cache les fragments récupérés — c'est de mettre en cache tout ce qui les entoure. Gardez le prompt système, les instructions de récupération et la spécification du format de sortie dans un préfixe stable, et traitez les documents récupérés comme le suffixe variable. Les équipes gérant de grandes bibliothèques d'outils peuvent obtenir un gain supplémentaire en mettant en cache le bloc de définitions d'outils séparément du contenu récupéré, car les schémas d'outils changent rarement au sein d'une session même quand la requête change.

Bien mesurer

Les tableaux de bord des fournisseurs rapportent généralement les nombres de tokens de lecture et d'écriture de cache séparément des tokens d'entrée standard, ce qui facilite le calcul du taux de succès réel : lectures de cache divisées par le total des tokens éligibles au préfixe. Les équipes devraient suivre ce chiffre explicitement plutôt que d'inférer les économies à partir de la facture totale, car un faible taux de succès peut se cacher derrière une facture par ailleurs raisonnable si le volume de requêtes fluctue également.

À retenir

Auditez d'abord la structure de votre prompt : le contenu statique (instructions système, schémas d'outils, documents de référence) doit précéder tout contenu variable par requête, sans exception.
Ne personnalisez pas à l'intérieur du préfixe cachable — injectez les données spécifiques à l'utilisateur comme un bloc clairement séparé après les instructions partagées.
Pour les pipelines RAG, mettez en cache l'échafaudage stable autour du contenu récupéré, pas le contenu récupéré lui-même.
Suivez le taux de succès du cache comme une métrique explicite, pas comme quelque chose d'inféré à partir des dépenses totales.
Vérifiez la fenêtre TTL de votre fournisseur et les schémas de trafic — des interruptions de trafic plus longues que la fenêtre TTL forceront une nouvelle écriture de cache quelle que soit la structure du prompt.