Tirer parti du prompt caching

Ce tutorial vous fait mettre en œuvre le prompt caching : réutiliser la partie stable d'un prompt d'un appel à l'autre pour payer moins cher et répondre plus vite. Vous partez d'un appel « naïf » qui recalcule tout à chaque fois, et vous arrivez à un appel structuré dont le préfixe est mis en cache et mesuré.

Aucune connaissance préalable du caching n'est requise. Il suffit de savoir appeler un LLM par API (envoyer un prompt, recevoir une réponse).

À la fin, vous saurez :

reconnaître quand le caching apporte un gain ;
structurer un prompt pour qu'il soit cachable ;
mesurer le gain réel.

Étape 0 — Le problème que l'on résout

À chaque appel, un LLM « relit » l'intégralité du prompt qu'on lui envoie. On paie ces tokens d'entrée à chaque appel, et le temps de traitement croît avec leur nombre.

Or, dans beaucoup d'usages, une grande partie du prompt ne change pas d'un appel à l'autre :

les consignes système (rôle, ton, règles de réponse) ;
un contexte documentaire réinjecté (passages d'un RAG, spécifications, corpus de référence) ;
des exemples de démonstration (few-shot).

Seule la question de l'utilisateur varie vraiment. Recalculer le reste à chaque fois, c'est repayer pour un texte identique. Le prompt caching supprime ce gaspillage.

Étape 1 — Comprendre le principe

Le principe tient en une phrase : mettre en cache un préfixe stable pour le relire beaucoup moins cher aux appels suivants.

Un point de vocabulaire :

préfixe — le début du prompt, envoyé à l'identique à chaque appel ;
cache — une mémoire côté fournisseur qui conserve le calcul déjà fait pour ce préfixe ;
écriture vs lecture — le premier appel écrit le préfixe en cache (léger surcoût), les appels suivants le lisent (très bon marché).

Le calcul économique est simple : tant que vous réutilisez le préfixe, la lecture à bas prix rembourse vite le surcoût d'écriture. Le caching devient donc gagnant dès que le même préfixe sert plusieurs fois dans un court laps de temps.

Note sur les ordres de grandeur : la lecture en cache coûte typiquement une fraction du prix d'un token d'entrée normal, et l'écriture un peu plus. Les ratios exacts dépendent du fournisseur et du modèle et évoluent : ne codez jamais une décision sur un chiffre mémorisé, vérifiez la documentation à jour.

Étape 2 — Reconnaître quand ça aide (et quand non)

Avant de câbler quoi que ce soit, vérifiez que votre cas s'y prête. Le caching paie quand deux conditions sont réunies.

Condition 1 — un préfixe volumineux et stable. Plus la partie réutilisée est grosse, plus l'économie est forte. Un long system prompt ou un contexte documentaire de plusieurs milliers de tokens est un candidat idéal. À l'inverse, un prompt court et entièrement variable ne gagnera rien.

Condition 2 — une réutilisation rapprochée. Le cache a une durée de vie limitée (de l'ordre de quelques minutes selon les fournisseurs), rafraîchie à chaque réutilisation. Si vos appels sont espacés de plusieurs heures, le préfixe aura expiré entre deux et sera recalculé : pas de gain.

Cas typiques où le caching brille :

un assistant conversationnel qui enchaîne plusieurs questions dans une même session, sur un même contexte système ;
un traitement par lot : la même consigne appliquée à une série d'entrées variables, à la suite ;
une boucle d'agent qui rappelle le LLM plusieurs fois avec les mêmes instructions de fond.

Cas où il n'apporte rien : un appel unique et isolé, ou un prompt dont tout change à chaque fois.

Il existe généralement aussi un seuil minimal de tokens en dessous duquel un préfixe n'est pas cachable — logique, puisque cacher un tout petit texte ne vaut pas la peine. Ce seuil dépend du modèle.

Étape 3 — Structurer le prompt : du stable vers le variable

C'est l'étape clé, et elle ne dépend d'aucune API particulière : ordonnez votre prompt du plus stable au plus variable.

Un cache fonctionne sur un préfixe : il ne peut réutiliser que le début commun à deux appels. Dès que survient le premier caractère qui change, le cache s'arrête. Donc tout ce qui bouge doit être à la fin.

┌─────────────────────────────┐
│  Consignes système          │  ← stable        ┐
│  (rôle, règles, format)     │                  │
├─────────────────────────────┤                  ├─ mis en cache
│  Contexte / documents       │  ← semi-stable   │  (réutilisé tel quel)
│  (passages, référence)      │                  │
├─────────────────────────────┤                  ┘
│  Question de l'utilisateur  │  ← variable      ← hors cache
└─────────────────────────────┘

Erreur classique à éviter : glisser un élément variable tôt dans le prompt — un horodatage, un identifiant de session, un compteur — juste après les consignes. Il « casse » le préfixe et rend tout ce qui suit non cachable. Repoussez ces éléments vers la fin, avec la question.

Exercice mental : relisez un de vos prompts existants et surlignez ce qui change réellement d'un appel à l'autre. Tout le reste devrait pouvoir remonter en tête, en bloc.

Étape 4 — Marquer le point de cache

Une fois le prompt ordonné, il faut indiquer au fournisseur jusqu'où cacher. Le mécanisme est le même partout, même si le nom du paramètre change d'une API à l'autre : on pose un point de césure à la fin du dernier bloc stable. Tout ce qui précède ce point est mis en cache ; tout ce qui suit reste recalculé à chaque appel.

En pratique :

Placez la césure après les consignes système si seules elles sont stables.
Placez-la plutôt après le bloc de contexte si ce contexte est lui aussi réutilisé d'un appel à l'autre — vous cachez alors davantage.
Laissez la question variable après la césure.

Le nom exact du paramètre de marquage et le nombre de points de césure autorisés dépendent du fournisseur — consultez sa documentation officielle. Mais retenez surtout la règle, pas le nom : ne mémorisez pas le paramètre, mémorisez — « je cache le plus grand préfixe stable possible, la césure se pose juste avant le premier élément qui varie ».

Étape 5 — Exploiter le cache pendant qu'il est chaud

Le cache est éphémère et se rafraîchit à chaque réutilisation. Pour en tirer le maximum :

regroupez les appels qui partagent un préfixe pendant que le cache est chaud, plutôt que de les disperser dans le temps ;
dans un assistant, enchaînez les questions d'une même session sans réinitialiser le contexte stable entre elles ;
pour un lot, traitez les entrées à la suite tant que le préfixe commun reste en cache.

L'idée directrice : plus le rythme de réutilisation est serré, plus le préfixe reste chaud, plus vous lisez au tarif réduit.

Étape 6 — Mesurer le gain

Ne vous fiez pas à l'intuition : mesurez. Les réponses d'un LLM exposent généralement, dans leurs métadonnées d'usage, le détail des tokens d'entrée — notamment ceux écrits en cache et ceux lus depuis le cache.

Suivez deux indicateurs :

Taux de lecture en cache = tokens lus depuis le cache / tokens d'entrée totaux. Plus il est haut, mieux le préfixe est réutilisé.
Latence de bout en bout, avant et après. Le caching réduit aussi le temps de réponse, pas seulement le coût.

Méthode simple pour valider votre mise en œuvre :

Faites deux appels identiques à la suite (même préfixe).
Sur le premier, attendez-vous à voir surtout de l'écriture en cache.
Sur le second, la même portion doit apparaître en lecture en cache.

Si le second appel ne montre pas de lecture, c'est le signal d'un problème : préfixe non identique au byte près (un espace, un horodatage qui a changé), césure mal placée, ou préfixe sous le seuil minimal. Reprenez l'étape 3.

Récapitulatif

Vous avez appris à :

repérer un préfixe stable et volumineux, réutilisé de façon rapprochée ;
ordonner le prompt du stable vers le variable, sans casser le préfixe ;
marquer le point de cache juste avant la partie variable ;
regrouper les appels pour garder le cache chaud ;
mesurer le taux de lecture en cache et la latence pour prouver le gain.

La règle à retenir tient en une ligne : le plus grand préfixe stable possible en tête, la partie variable en queue, et on mesure.

Pour aller plus loin

Comprendre pourquoi le caching change l'économie d'un RAG : voir la pièce sœur explanation/ à créer sur les arbitrages coût / latence / fraîcheur.
S'informer sur les paramètres précis d'un fournisseur : voir une pièce reference/ dédiée, à dériver de la documentation officielle à jour.