L'activation de la mise en cache des prompts ne m'a rien fait économiser — en fait, ma facture OpenAI API a bondi d'environ un quart. Le coupable était une seule ligne qui changeait à chaque requête : un horodatage intégré dans le prompt système.

Les fournisseurs de LLM permettent aux développeurs de mettre en cache des fragments de prompts pour réduire les coûts de traitement des tokens. Une lecture de cache (un « hit ») coûte à peine un dixième du tarif habituel, tandis qu'une écriture de cache (un « miss ») coûte environ 1,25 × le prix normal. Si une écriture a lieu mais que le fragment mis en cache n'est jamais lu, les 25 % de frais supplémentaires sont perdus. C'est exactement ce qui s'est produit lorsque l'horodatage a empêché le prompt de correspondre à une entrée de cache existante.

Pourquoi la mise en cache peut se retourner contre vous

La mise en cache des prompts fonctionne en faisant correspondre la séquence d'octets exacte de la partie mise en cache. Le fournisseur hache l'entrée ; si le hachage correspond à une entrée stockée, le système réutilise le calcul précédent et applique le tarif de lecture réduit. Toute variation — même un seul caractère — rompt la correspondance et force un nouveau calcul, facturé au tarif d'écriture plus élevé.

Dans mon cas, le prompt système commençait par :

Current session started: 2026-07-14T09:41:07Z

Comme l'horodatage était mis à jour à chaque appel API, les premiers octets de la requête n'étaient jamais identiques. Le fournisseur traitait chaque appel comme une nouvelle entrée de cache, facturait la prime d'écriture et n'enregistrait jamais de lecture. Le résultat a été une augmentation constante de cache_creation_input_tokens alors que cache_read_input_tokens restait à zéro, un signe clair que le cache n'était jamais sollicité.

Comment repérer un cache défaillant

Les journaux d'utilisation fournis par l'API donnent deux compteurs clés :

  • cache_creation_input_tokens – les tokens qui ont déclenché une écriture.
  • cache_read_input_tokens – les tokens qui ont bénéficié d'une lecture.

Lorsque le premier augmente et que le second reste stable, le cache n'est pas réutilisé. Un test rapide consiste à répéter exactement la même requête deux fois ; le second appel devrait montrer un pic de tokens de lecture si le cache fonctionne.

Résoudre le problème

La solution est simple : assurez-vous que la zone mise en cache est statique d'un appel à l'autre. Suivez ces deux règles :

  1. Placez le contenu immuable en premier. Les prompts système, les définitions d'outils ou toute instruction qui ne change jamais doivent occuper les premiers octets de la requête.
  2. Ajoutez le contenu mutable à la fin. Les horodatages, le texte généré par l'utilisateur, les ID de requête ou toute donnée qui varie par appel doivent se trouver après le segment mis en cache.

Si ne serait-ce qu'un seul caractère change, le hachage change et l'échec de mise en cache persiste. Réorganiser le prompt pour que l'horodatage se trouve à la fin rétablit le taux de réussite du cache et ramène la facture au niveau de coût réduit attendu.

Quand la mise en cache est réellement utile

La mise en cache des prompts excelle dans les scénarios où le même ensemble d'instructions est réutilisé de nombreuses fois :

  • Boucles d'agents où une IA fait appel de manière répétée à un ensemble fixe d'outils.
  • Sessions de chat qui font référence à un document long et statique, alors que seule la dernière requête de l'utilisateur change.
  • Extraction de données en masse où le même prompt d'analyse est appliqué à de nombreux enregistrements.

Pour les appels ponctuels qui incluent un nouveau contexte à chaque fois — comme une question unique avec un préambule spécifique — la mise en cache n'offre aucun avantage et peut même ajouter des coûts si la requête déclenche involontairement une écriture.

Pièges cachés

Même si le prompt lui-même est statique, la requête peut être altérée en aval :

  • Les proxys ou les agrégateurs qui réordonnent ou injectent des espaces blancs peuvent briser la correspondance octet par octet.
  • Les services de passerelle (gateways) qui ajoutent des en-têtes d'authentification ou modifient le formatage JSON peuvent modifier involontairement le fragment mis en cache.

Tester via la passerelle en envoyant deux fois une requête identique et en vérifiant les compteurs de lecture permet de vérifier que le chemin de mise en cache reste intact.

Une vision plus large des coûts

La surcharge de 25 % sur les écritures n'est pas une pénalité pour l'utilisation de la mise en cache ; elle reflète la puissance de calcul supplémentaire nécessaire pour stocker le fragment en vue d'une réutilisation future. Lorsqu'un « hit » de cache se produit, le coût chute de manière spectaculaire — souvent à une fraction du tarif habituel. La clé est de permettre au système de réellement solliciter le cache. Sinon, vous payez la prime sans aucune économie.

Contre-argument : la mise en cache n'est pas morte

Certains développeurs soutiennent que la complexité de la gestion des parties statiques par rapport aux parties dynamiques des prompts l'emporte sur les économies réalisées. Ce point de vue néglige le fait que de nombreux pipelines de production séparent déjà la configuration (statique) des données utilisateur (dynamiques). En structurant les prompts en conséquence, le même mécanisme de mise en cache qui a profité aux développeurs originaux de l'API peut être exploité sans effort supplémentaire. Le compromis réside dans une légère discipline de conception de prompts, et non dans un défaut fondamental de la technologie.

À surveiller ensuite

  • Surveillez les deux compteurs de cache dans votre tableau de bord d'utilisation chaque semaine.
  • Auditez la construction des prompts pour confirmer que tout élément variable se situe après le bloc mis en cache.
  • Effectuez des tests A/B avec et sans mise en cache sur une charge de travail représentative pour quantifier les économies réelles.
  • Validez la passerelle en comparant les charges utiles des requêtes brutes avant et après tout proxy.

À retenir

La mise en cache des prompts peut réduire considérablement les coûts des API LLM, mais seulement si le segment mis en cache est véritablement identique d'un appel à l'autre. Un horodatage égaré ou tout autre jeton dynamique au début d'un prompt force une écriture coûteuse à chaque fois, gonflant ainsi la facture. En plaçant les instructions statiques au début et en reléguant les données changeantes à la fin, vous laissez le cache faire son travail et maintenez vos dépenses sous contrôle.