Cache de prompts : comment réduire jusqu’à 90 % vos coûts de tokens

Le cache de prompts stocke le calcul déjà effectué sur la partie stable d’un prompt (system prompt, documents, instructions) pour éviter de le retraiter à chaque appel.
Les gains observés vont de 50 % (OpenAI, remise automatique) à 90 % sur les tokens en cache (Anthropic), avec une baisse de latence pouvant atteindre 80 %.
Le mécanisme repose sur une correspondance exacte de préfixe : la moindre différence en début de prompt (espace, ordre des clés JSON, définition d’outil) invalide le cache.
OpenAI l’active automatiquement dès 1024 tokens, Anthropic exige un paramètre cache_control explicite, Google Gemini facture le stockage du cache en plus de sa lecture.
La règle de structuration universelle : contenu statique en tête de prompt, contenu variable (requête utilisateur) en fin de prompt.

Le cache de prompts est une fonctionnalité proposée par les fournisseurs de modèles (OpenAI, Anthropic, Google) qui permet de réutiliser le calcul interne déjà effectué sur la partie inchangée d’un prompt, au lieu de le retraiter à chaque requête. Concrètement, si votre application envoie le même system prompt, les mêmes instructions ou le même document de référence à chaque appel API, le modèle peut « se souvenir » de cette portion et sauter directement au traitement de la partie variable. Le résultat : une facture d’API divisée jusqu’à deux, une latence réduite de moitié à 80 %, et aucune perte de qualité sur les réponses générées. Pour une startup qui envoie des milliers d’appels par jour avec un system prompt de 2000 tokens, cette seule optimisation peut représenter plusieurs centaines d’euros économisés chaque mois, sans toucher au comportement du produit.

Le mécanisme technique derrière le cache de prompts

Pour comprendre pourquoi le cache de prompts fonctionne, il faut revenir à la façon dont un LLM traite une requête. Avant de générer le moindre token de réponse, le modèle doit d’abord « lire » l’intégralité du prompt d’entrée et construire, pour chaque token, une représentation interne appelée paire clé-valeur (KV cache), utilisée par les couches d’attention du transformer. Cette étape, appelée prefill, est coûteuse en calcul et proportionnelle à la longueur du prompt.

Le cache de prompts exploite une observation simple : dans la grande majorité des applications réelles, une large portion du prompt ne change jamais d’un appel à l’autre. Le system prompt d’un chatbot, les instructions d’un agent de codage, les schémas de tool-calling ou un document de référence injecté en RAG restent identiques pendant des heures, parfois des jours. Le fournisseur peut donc calculer une seule fois la représentation KV de cette portion stable, la stocker temporairement, puis la réutiliser directement pour tous les appels suivants qui commencent par le même préfixe exact.

Techniquement, le fournisseur hache généralement les premiers tokens du prompt entrant (environ les 256 premiers chez OpenAI) et compare ce hash à son cache récent. En cas de correspondance, seule la partie nouvelle du prompt (typiquement le message utilisateur) est traitée en pleine puissance de calcul ; le reste est lu directement depuis le cache. C’est cette économie de calcul qui se traduit en économie de tokens facturés et en gain de latence, puisque sauter le prefill signifie aussi sauter le temps de traitement associé.

Le point critique à retenir : cette correspondance doit être exacte au niveau du préfixe. Un espace en trop, un ordre de clés JSON différent, une définition d’outil modifiée entre deux appels, et le cache ne s’applique plus du tout — le modèle retraite l’intégralité du prompt au tarif standard.

OpenAI, Anthropic, Google — trois approches différentes

Les trois grands fournisseurs implémentent le cache de prompts avec des logiques et des économies distinctes, ce qui a un impact direct sur la façon dont vous devez concevoir votre intégration.

OpenAI applique le cache automatiquement, sans aucune modification de code. Dès qu’un prompt dépasse 1024 tokens, l’API vérifie si son préfixe correspond à un appel récent traité sur le même serveur, avec des paliers de correspondance par incréments de 128 tokens. En cas de cache hit, la remise appliquée sur les tokens mis en cache est de 50 % par rapport au tarif standard, et la latence peut chuter jusqu’à 80 %. Pour les applications qui envoient plus d’une quinzaine de requêtes par minute sur le même préfixe, OpenAI recommande d’ajouter un paramètre prompt_cache_key afin de router systématiquement les appels liés vers le même serveur et maximiser le taux de cache hit.

Anthropic adopte une logique opposée : le cache est explicite et contrôlé par le développeur via le paramètre cache_control inséré à l’endroit précis du prompt où l’on souhaite créer un point de rupture (breakpoint). Jusqu’à quatre breakpoints sont autorisés dans un même prompt, permettant de mettre en cache indépendamment les outils, le system prompt et certains messages. En contrepartie de ce contrôle plus fin, Anthropic offre l’une des remises les plus agressives du marché sur les tokens lus depuis le cache, tout en facturant l’écriture initiale du cache à un tarif légèrement supérieur au tarif standard. Par défaut, un cache Anthropic est conservé cinq minutes, avec une option d’extension à une heure moyennant un surcoût.

Google Gemini se distingue par un modèle économique différent : au-delà du coût de lecture réduit, Gemini facture également le stockage du cache pendant sa durée de vie (par défaut une heure, personnalisable). Ce détail change le calcul de rentabilité — un cache Gemini n’est intéressant que s’il est réellement réutilisé suffisamment de fois avant expiration pour compenser son coût de stockage.

Cas d’usage où le cache de prompts change vraiment la donne

Trois familles d’applications tirent un bénéfice disproportionné du cache de prompts, et il vaut la peine de les identifier précisément avant d’investir du temps dans l’implémentation.

Les chatbots et assistants conversationnels avec un system prompt volumineux et statique constituent le cas d’usage le plus simple et le plus rentable. Un system prompt de 2000 tokens décrivant la personnalité, les règles métier et les contraintes de sortie d’un assistant, envoyé à chaque tour de conversation, est un candidat idéal : il ne change jamais entre deux messages d’un même utilisateur, et souvent pas non plus d’un utilisateur à l’autre. C’est généralement le premier levier activé par les équipes, car il offre le meilleur ratio effort d’implémentation / gain financier.

Les assistants de codage exploitent le cache différemment : le contexte du dépôt (structure de fichiers, conventions de code, instructions du projet) reste stable pendant toute une session de travail, tandis que seule la requête ponctuelle de l’utilisateur varie. Placer ce contexte en tête de prompt permet de conserver le cache actif sur plusieurs dizaines d’échanges consécutifs.

Les pipelines RAG et le document caching représentent le troisième cas d’usage majeur. Lorsqu’une application interroge répétitivement le même corpus de référence (documentation produit, base de connaissances, contrat juridique) avec des questions différentes à chaque fois, mettre en cache le document plutôt que la question permet de ne payer le coût plein qu’une seule fois pour l’ensemble du corpus, puis de bénéficier du tarif réduit pour chaque nouvelle question posée dessus.

À l’inverse, une application qui génère des prompts entièrement différents à chaque appel, sans aucune portion stable en tête, ne tirera aucun bénéfice du cache de prompts — il n’y a tout simplement aucun préfixe à réutiliser.

Structurer ses prompts pour maximiser le taux de cache hit

Le gain financier du cache de prompts dépend entièrement de la structure du prompt envoyé. Une règle unique gouverne tous les fournisseurs : placer le contenu statique en premier, le contenu variable en dernier. Concrètement, cela signifie ordonner systématiquement un appel API de la façon suivante : définitions d’outils, system prompt et instructions générales, documents de référence stables, puis en toute fin seulement le message ou la requête spécifique de l’utilisateur.

Cette contrainte a des implications concrètes qui piègent souvent les équipes en début d’implémentation. Injecter la date du jour, l’identifiant de session ou toute autre variable dynamique au milieu ou en tête du system prompt casse le cache pour l’intégralité du prompt qui suit, même si 95 % du contenu reste identique. La solution consiste à déplacer systématiquement ces éléments variables en toute fin de prompt, après la partie statique.

De la même manière, la sérialisation des données doit rester strictement identique d’un appel à l’autre : un objet JSON dont l’ordre des clés change, un tableau d’outils réordonné aléatoirement, ou même un simple changement d’indentation suffisent à générer un hash de préfixe différent et donc un cache miss complet. Les équipes qui obtiennent les meilleurs taux de cache hit figent la génération de leurs prompts avec des templates déterministes plutôt que de laisser un ORM ou un sérialiseur JSON réordonner les champs librement.

Enfin, le volume minimum de tokens compte : en dessous d’environ 1024 tokens côté OpenAI, le cache ne s’active pas du tout, ce qui rend cette optimisation particulièrement pertinente pour les system prompts riches en contexte métier, en exemples few-shot ou en documentation, et beaucoup moins pour les micro-prompts courts.

Calculer le retour sur investissement du cache de prompts

Le cache de prompts n’est pas gratuit à mettre en place, même s’il ne nécessite souvent que quelques lignes de code. Il est donc utile de chiffrer précisément le gain attendu avant de le prioriser dans une roadmap technique.

Prenons un exemple représentatif : une application envoie un system prompt statique de 2000 tokens, accompagné d’une requête utilisateur variable de 100 tokens, à raison de 500 000 appels sur un mois. Sans cache, chaque appel facture l’intégralité des 2100 tokens au tarif d’entrée standard. Avec le cache activé, seuls les 100 tokens variables restent facturés au tarif plein ; les 2000 tokens du system prompt basculent au tarif réduit du cache, de l’ordre de dix fois moins cher que le tarif standard selon le fournisseur. Sur ce scénario, le coût mensuel total peut chuter d’environ 89 %, ce qui représente plusieurs centaines d’euros économisés chaque mois sur une seule fonctionnalité, sans aucun changement dans la qualité ou le comportement des réponses générées.

Ce calcul dépend cependant de trois variables à vérifier avant d’estimer un gain pour votre propre cas : la proportion de contenu réellement statique dans vos prompts, le taux de cache hit effectif (qui dépend de la fréquence des appels et de la durée de vie du cache), et le tarif d’écriture initiale du cache, qui chez certains fournisseurs est légèrement supérieur au tarif standard. Une application à faible volume d’appels ou dont le préfixe change fréquemment atteindra rarement les gains maximaux théoriques annoncés par les fournisseurs.

Les limites et pièges à connaître avant d’activer le cache

Le cache de prompts n’est pas une optimisation à activer aveuglément sur toute une application. Plusieurs limites méritent d’être anticipées.

La première concerne la durée de vie du cache, qui varie fortement selon le fournisseur : cinq minutes par défaut chez Anthropic, une heure chez Gemini avec possibilité d’extension payante. Une application dont les appels sur un même préfixe sont trop espacés dans le temps ne bénéficiera jamais du cache, quel que soit le soin apporté à la structuration du prompt.

La deuxième porte sur le suivi et l’observabilité : les métriques d’usage classiques (tokens d’entrée, tokens de sortie) ne suffisent plus à comprendre le coût réel d’une application qui utilise le cache. Il devient nécessaire de suivre distinctement les tokens lus depuis le cache, les tokens écrits dans le cache et les tokens traités au tarif standard, faute de quoi le calcul de coût par requête devient faux.

La troisième limite est propre à Anthropic : le tarif d’écriture initiale du cache est plus élevé que le tarif d’entrée standard. Sur une application à très faible taux de réutilisation (prompts rarement identiques d’un appel à l’autre), le cache peut en réalité augmenter la facture plutôt que la réduire, puisque chaque écriture coûte plus cher qu’un traitement normal sans jamais être compensée par une lecture ultérieure.

Enfin, le cache de prompts réutilise le calcul, jamais le résultat final : il ne remplace pas une stratégie de cache applicatif classique qui stockerait directement la réponse du modèle pour des requêtes strictement identiques. Les deux approches sont complémentaires et répondent à des besoins différents.

Le cache de prompts réduit-il aussi la qualité des réponses générées ?

Non. Le cache de prompts réutilise uniquement la représentation interne déjà calculée du préfixe, sans modifier le comportement du modèle ni la façon dont il génère la suite de la réponse. La qualité de sortie reste identique, seuls le coût et la latence changent.

Faut-il activer le cache de prompts manuellement ?

Cela dépend du fournisseur. OpenAI l’active automatiquement dès qu’un prompt dépasse 1024 tokens, sans modification de code. Anthropic exige d’insérer explicitement un paramètre cache_control dans le prompt pour définir les points de rupture à mettre en cache.

Pourquoi mon cache de prompts ne fonctionne-t-il pas malgré un system prompt identique ?

La cause la plus fréquente est une différence invisible dans le préfixe : un ordre de clés JSON qui change, une variable dynamique injectée en tête de prompt, ou un espace en trop. La correspondance de cache exige un préfixe strictement identique, caractère pour caractère.

Combien de temps un cache de prompts reste-t-il actif ?

Cela varie selon le fournisseur : cinq minutes par défaut chez Anthropic (extensible à une heure), une heure par défaut chez Google Gemini avec durée personnalisable. Chez OpenAI, la durée dépend de la charge du serveur ayant traité le prompt.

Le cache de prompts fonctionne-t-il pour les images et les définitions d’outils ?

Oui, à condition qu’elles soient strictement identiques entre deux appels. Les définitions d’outils (tool calling) et les images intégrées au prompt participent au calcul du préfixe au même titre que le texte, et toute modification les concernant invalide également le cache.

Le cache de prompts peut-il augmenter mes coûts au lieu de les réduire ?

Oui, dans un cas précis : chez Anthropic, le tarif d’écriture initiale du cache est plus élevé que le tarif standard. Si votre application génère rarement des préfixes identiques d’un appel à l’autre, chaque écriture de cache peut coûter plus cher sans jamais être compensée par une lecture ultérieure.

Quelle taille minimale de prompt est nécessaire pour bénéficier du cache ?

Chez OpenAI, le cache ne s’active qu’à partir de 1024 tokens, avec des paliers supplémentaires par incréments de 128 tokens. En dessous de ce seuil, l’optimisation n’a aucun effet, ce qui la rend surtout pertinente pour les system prompts riches en contexte.

Sources

Auteur

Jacques

Expert en workflows IA et automatisation, spécialisé dans la création de processus intelligents, d’outils connectés et de systèmes numériques performants.

En savoir plus sur Jacques →

✨ Articles recommandés

Réduire coût API IA : Guide complet sans perdre en qualité

Automatisation IA

Cache de prompts : économiser jusqu’à 90% des tokens | Guide complet