Prompt caching d’OpenAI : comment réduire le coût de vos requêtes API

Les applications qui s’appuient sur un grand modèle de langage ne paient pas seulement les réponses qu’elles affichent. Elles paient aussi la lecture des instructions, des documents et de l’historique envoyés au modèle à chaque appel. Lorsque cette longue partie d’une requête est répétée, la facture comme le temps de réponse peuvent vite augmenter. Avec le prompt caching, ou mise en cache des prompts, OpenAI propose depuis octobre 2024 une optimisation directement intégrée à son API.

Le principe est simple : lorsque plusieurs demandes commencent par le même long contenu, l’API peut réutiliser le traitement déjà effectué pour ce préfixe commun. OpenAI annonce alors deux bénéfices : 50 % de réduction sur le prix des tokens d’entrée mis en cache et une latence pouvant diminuer jusqu’à 80 %. Cette fonctionnalité vise notamment les assistants conversationnels, les outils d’analyse documentaire et les applications qui transmettent à répétition de longues consignes.

Il faut toutefois distinguer la promesse commerciale de son effet réel sur une facture. La remise porte sur une partie précise de l’usage, les tokens d’entrée réutilisés. Elle ne réduit ni le prix des nouveaux éléments ajoutés à chaque requête, ni celui des tokens générés en réponse.

Le prompt caching, qu’est-ce que c’est exactement ?

Un prompt est le contenu envoyé au modèle : une instruction système, des règles de réponse, le contexte d’une conversation, un document à analyser ou encore la question de l’utilisateur. Ce texte est découpé en tokens, les unités de traitement facturées par les modèles de langage.

Dans une application classique, une même base d’instructions peut être envoyée des milliers de fois. Imaginons un assistant métier qui reçoit toujours un long règlement interne, une charte éditoriale ou la description détaillée d’un catalogue avant de répondre. Sans optimisation, le modèle doit retraiter cette partie à chaque requête.

Le prompt caching ne réutilise pas une réponse toute faite. Il permet de réemployer le traitement d’un préfixe de prompt identique. La nuance est importante : chaque nouvelle demande est bien soumise au modèle, qui génère une nouvelle réponse à partir du contexte disponible. OpenAI ne promet donc pas de transformer un assistant en répondeur automatique, mais d’éviter une partie des calculs redondants sur les entrées.

Cette mécanique est automatique. Les développeurs n’ont pas à activer un interrupteur ni à modifier le format de leurs appels API. En revanche, l’architecture des prompts détermine directement la possibilité de profiter du cache : si le début du message change à chaque appel, les économies seront limitées.

À quelles conditions les requêtes sont-elles mises en cache ?

Au 21 octobre 2024, le mécanisme s’applique aux prompts d’au moins 1 024 tokens sur les modèles compatibles. Cela représente un contenu déjà conséquent : plusieurs pages de texte, un historique de conversation étoffé ou de longues instructions structurées. Sous ce seuil, il n’y a pas de réduction liée au cache.

OpenAI indique que la taille du cache augmente ensuite par blocs de 128 tokens. La plateforme cherche les préfixes identiques entre les requêtes. La conséquence pratique est claire : deux messages qui contiennent les mêmes informations, mais dans un ordre différent ou avec des variations dès le départ, ne bénéficieront pas nécessairement du même niveau de mise en cache.

Le bon réflexe consiste à organiser une requête du plus stable au plus variable :

• les règles permanentes de l’application et les longues consignes au début ;
• les documents ou connaissances souvent réutilisés juste après ;
• l’historique nécessaire à la conversation ensuite ;
• la question, les données personnelles ou les paramètres propres à l’utilisateur à la fin.

Cette organisation ne change pas la nature de la requête. Elle facilite simplement l’identification de la portion commune. C’est particulièrement utile lorsqu’une application s’adresse à de nombreux utilisateurs avec une même base documentaire ou un même cadre de réponse.

OpenAI expose aussi dans les données d’usage de l’API le nombre de tokens servis depuis le cache. Cet indicateur permet de vérifier, appel après appel, si la structuration des prompts produit effectivement les gains espérés. Il ne suffit donc pas de supposer que le cache fonctionne : il faut mesurer la part de tokens concernés.

Quels modèles et quels tarifs sont concernés ?

Lors de son lancement, OpenAI rend le prompt caching disponible sur GPT-4o, GPT-4o mini, o1-preview et o1-mini. La facturation distingue les tokens d’entrée standard des tokens d’entrée provenant du cache. Dans tous les cas, le tarif mis en cache correspond à la moitié du tarif d’entrée habituel.

Le tableau montre pourquoi l’expression « réduire les coûts jusqu’à 50 % » mérite d’être lue avec précision. Si une requête est composée presque exclusivement d’un long préfixe réutilisé, l’économie sur ses entrées peut se rapprocher de 50 %. Mais si l’application génère beaucoup de texte en sortie, ou si l’utilisateur ajoute une grande quantité de contenu inédit, la baisse de la dépense globale sera inférieure.

La mise en cache n’ajoute pas de frais d’écriture au cache selon OpenAI. Elle est donc pensée comme un levier tarifaire simple pour les développeurs dont les appels contiennent déjà de grandes portions répétitives.

Pourquoi la latence peut-elle baisser jusqu’à 80 % ?

Avant de produire une réponse, un modèle doit parcourir le contexte qui lui est transmis. Plus le prompt est long, plus cette étape peut peser dans le délai perçu par l’utilisateur. En évitant de retraiter un préfixe déjà rencontré, le prompt caching allège cette phase initiale.

OpenAI évoque une réduction de latence pouvant atteindre 80 %. Il s’agit d’un maximum annoncé, pas d’une garantie uniforme pour chaque application. Le résultat dépend de la longueur de la partie identique, du volume d’éléments nouveaux, du modèle utilisé et de la longueur de la réponse générée. Une requête courte, ou une demande dont la réponse est très longue, ne connaîtra pas forcément une amélioration aussi spectaculaire.

L’intérêt est néanmoins concret dans plusieurs cas : un chatbot doté d’un vaste message système, un outil de support client alimenté par une documentation stable, un assistant juridique qui doit conserver les mêmes règles de rédaction, ou une application qui analyse de nombreux éléments au regard d’une grille identique. Dans ces scénarios, un temps de réponse plus régulier améliore l’expérience sans imposer de compromis direct sur le contenu demandé au modèle.

Comment organiser ses prompts pour obtenir des économies ?

Le prompt caching ne dispense pas d’une gestion attentive des coûts. Il complète les pratiques habituelles, comme choisir un modèle adapté à la tâche, limiter le contexte à ce qui est réellement utile et plafonner, lorsque c’est pertinent, la longueur des réponses.

Pour tirer parti de la fonctionnalité, les équipes peuvent d’abord repérer les parties de prompt strictement identiques d’un appel à l’autre. Une consigne stable peut inclure le rôle de l’assistant, le ton attendu, les règles de sécurité, un format de sortie ou les instructions de traitement d’un document. Ces éléments ont intérêt à rester au début et à ne pas être réécrits inutilement.

À l’inverse, les informations qui changent à chaque interaction doivent venir après ce socle commun. Il peut s’agir de la requête d’un client, d’un identifiant de dossier, d’une date, d’un extrait de conversation récent ou des données d’un formulaire. Cette séparation rend l’application plus lisible pour ses concepteurs et augmente les chances de retrouver un préfixe déjà traité.

Il faut également éviter d’envoyer par défaut l’intégralité d’un historique ou d’une base de connaissances lorsque seuls quelques passages sont nécessaires. Le cache réduit le coût d’un contenu réutilisé, mais il ne rend pas gratuit un contexte inutilement volumineux. Réduire le volume de tokens reste une source d’économies complémentaire.

Quels projets ont le plus à y gagner ?

Les projets les plus concernés sont ceux qui combinent des requêtes fréquentes et un contexte stable. Les assistants internes d’entreprise constituent un exemple naturel : ils s’appuient souvent sur les mêmes politiques, les mêmes règles de confidentialité ou les mêmes procédures. Les outils de rédaction assistée peuvent eux aussi renvoyer constamment une longue charte, un modèle de document ou des consignes de mise en forme.

Les services de traitement de documents y trouvent également un intérêt. Une même instruction détaillée, par exemple extraire des champs ou produire une synthèse selon une structure précise, peut être appliquée à une série de fichiers. Enfin, les interfaces conversationnelles qui conservent un cadre commun pour tous les utilisateurs sont susceptibles de cumuler les gains à mesure que leur volume d’appels augmente.

À l’inverse, une application qui envoie essentiellement des requêtes courtes et totalement nouvelles profitera peu du mécanisme. Dans ce cas, le choix du modèle et la concision du prompt seront généralement des leviers plus déterminants.

Ce qu’il faut surveiller avant d’en faire un levier budgétaire

Le prompt caching marque une évolution importante de la tarification des grands modèles de langage : la valeur facturée ne dépend plus seulement de la quantité de texte envoyée, mais aussi de sa réutilisation. Cette logique est particulièrement adaptée aux produits qui industrialisent un même cadre d’instructions à grande échelle.

Pour les équipes de développement, l’enjeu est de suivre trois indicateurs : le volume total de tokens d’entrée, la part effectivement servie depuis le cache et la proportion représentée par les réponses générées. Ces données permettent de relier une optimisation de prompt à un effet budgétaire concret, plutôt que de se fier à un pourcentage théorique.

La fonctionnalité s’inscrit aussi dans une compétition plus large entre fournisseurs de modèles, où la rapidité et le prix deviennent aussi importants que les capacités de génération. Les développeurs ont donc intérêt à concevoir dès maintenant des prompts modulaires, stables et mesurables. Le cache n’élimine pas le coût de l’IA générative, mais il offre un moyen direct de ne pas payer deux fois le traitement du même contexte.