Je constate régulièrement cette erreur chez mes étudiants en ingénierie de prompt. Ils envoient un document de référence de cent pages à chaque question de l’utilisateur. Les factures API s’envolent. Les temps de réponse s’allongent.
Le prompt caching résout ce problème de manière élégante. Au lieu de recalculer les relations entre tous les mots à chaque appel, les fournisseurs d’intelligence artificielle sauvegardent l’état mathématique de vos textes fixes.
- Économies massives : Cette technique réduit vos coûts de jetons d’entrée jusqu’à 90 %.
- Vitesse accrue : Le temps d’attente avant le premier jeton diminue de près de 80 %.
- Mécanique interne : Le système sauvegarde l’état des vecteurs Clé-Valeur (KV Cache) pour éviter les calculs répétitifs sur la carte graphique.
- Règle d’or : L’alignement doit s’effectuer à partir du premier caractère. Le moindre changement au début du texte invalide toute la mémoire cache.
Fonctionnement technique : Dans les rouages du KV Cache
Pour comprendre cette technologie, il faut analyser l’architecture Transformer.
Lors de la phase initiale de lecture, le modèle de langage effectue des multiplications de matrices pour chaque jeton. Il génère trois vecteurs : la Requête (Query), la Clé (Key) et la Valeur (Value). Ces données définissent l’attention que les mots se portent entre eux.
Sans cache, envoyer un document de 30 000 jetons deux fois de suite force le processeur graphique à recalculer ces vecteurs Clé-Valeur à chaque fois. Cela consomme de l’énergie et du temps.
Flux sans cache : [Document de 30 000 jetons] -> Recalcul complet des vecteurs K et V -> Facture élevée et latence forte.
Le prompt caching change la donne. Le système enregistre les matrices K et V dans la mémoire vive ultra-rapide du processeur graphique. Lors de la requête suivante, le modèle lit ces données sans effectuer de calculs.
Flux avec cache : [Document de 30 000 jetons] -> Lecture des vecteurs K et V en mémoire -> Coût minime et réponse instantanée.
Le goulot d’étranglement passe ainsi d’un problème de calcul pur à un simple transfert de mémoire.
Prompt Caching vs Caching Traditionnel
Une confusion fréquente existe entre le cache d’application classique et le cache de prompt. Ce tableau présente leurs différences fondamentales :
| Critère | Cache de Réponse Traditionnel | Prompt Caching |
|---|---|---|
| Données stockées | Le texte final généré par l’IA. | Les états de calcul internes du texte d’entrée. |
| Type de réponse | Renvoie exactement la même réponse à chaque fois. | Génère une réponse unique tout en évitant l’analyse de l’entrée. |
| Règle de correspondance | Exige une question identique au caractère près. | Exige un début de texte (préfixe) identique. |
Les cas d’usage incontournables
- Agents de conversation persistants : Les échanges longs accumulent un historique lourd. Le cache conserve le fil de la discussion pour ne facturer que le dernier message envoyé.
- Consignes système volumineuses : Les règles de comportement de votre entreprise restent identiques pour des milliers de requêtes clients.
- Génération augmentée par récupération (RAG) : Une base de connaissances fixe ou une documentation technique peut être lue une fois, puis interrogée en boucle par différents utilisateurs.
La règle stricte du préfixe
Le cache analyse votre texte à partir du tout premier mot. Si une modification survient au début du prompt, le mécanisme échoue.
Vous devez structurer vos données avec méthode. Placez les éléments statiques au sommet de votre requête et repoussez les variables dynamiques tout en bas.
Voici l’organisation recommandée pour vos requêtes :
- CONSIGNES SYSTÈME (Statique – En cache) : Définissez le rôle de l’assistant.
- BASE DE CONNAISSANCES (Statique – En cache) : Intégrez vos manuels ou vos contrats de plusieurs milliers de mots.
- CONVERSATION (Dynamique – Traitée normalement) : Ajoutez l’historique récent.
- QUESTION DE L’UTILISATEUR (Dynamique – Traitée normalement) : Insérez la demande actuelle et l’heure précise.
Note de l’instructeur : Si vous placez l’heure ou le nom de l’utilisateur au début du prompt, le système détruit instantanément l’opportunité d’utiliser le cache pour le reste du document.
Impact financier sur votre budget
Prenons un exemple concret. Imaginons un service client automatisé qui gère 1 000 requêtes par heure. Chaque appel intègre un manuel technique de 50 000 jetons.
Le tarif standard est de 10,00 $ par million de jetons d’entrée. Le tarif avec cache tombe à 1,00 $ par million de jetons.
- Coût horaire sans cache : 1 000 requêtes x 50 000 jetons x 0,00001 $ = 500,00 $
- Coût horaire avec cache : 1 000 requêtes x 50 000 jetons x 0,000001 $ = 50,00 $
La réduction budgétaire atteint 90 %. Les utilisateurs profitent en plus d’une fluidité de réponse incomparable.
Mise en œuvre avec Anthropic Claude
Anthropic demande une déclaration explicite des points de sauvegarde dans votre code. Vous utilisez pour cela un marqueur spécifique.
import anthropic
client = anthropic.Anthropic()
with open("contrat_legal_volumineux.txt", "r") as f:
texte_contrat = f.read()
response = client.messages.create(
model="claude-3-5-sonnet-20241022",
max_tokens=1000,
temperature=0,
system=[
{
"type": "text",
"text": "Vous êtes un analyste juridique. Répondez aux questions en vous basant sur le document."
}
],
messages=[
{
"role": "user",
"content": [
{
"type": "text",
"text": texte_contrat,
"cache_control": {"type": "ephemeral"}
},
{
"type": "text",
"text": "Quelles sont les clauses de résiliation ?"
}
]
}
]
)
print(response.content[0].text)
print(f"Jetons mis en cache : {response.usage.cache_creation_input_tokens}")
print(f"Jetons lus depuis le cache : {response.usage.cache_read_input_tokens}")
Mise en œuvre avec OpenAI
Le moteur d’OpenAI fonctionne de manière autonome. Il détecte les blocs de texte identiques supérieurs à 1 024 jetons sans intervention de votre part.
from openai import OpenAI
client = OpenAI()
with open("guide_interne.txt", "r") as f:
guide_entreprise = f.read()
messages = [
{
"role": "system",
"content": "Vous êtes un assistant RH. Utilisez le guide fourni."
},
{
"role": "user",
"content": f"Voici le guide :\n\n{guide_entreprise}"
},
{
"role": "user",
"content": "Quelle est la politique pour le télétravail ?"
}
]
# Le premier appel génère le cache
reponse_1 = client.chat.completions.create(
model="gpt-4o",
messages=messages,
)
# Nous ajoutons la suite de la discussion
messages.append({"role": "assistant", "content": reponse_1.choices[0].message.content})
messages.append({"role": "user", "content": "Cette règle s'applique-t-elle aux stagiaires ?"})
# Ce second appel utilise le cache existant
reponse_2 = client.chat.completions.create(
model="gpt-4o",
messages=messages,
)
print(f"Jetons en cache exploités : {reponse_2.usage.prompt_tokens_details.cached_tokens}")
Intégration dans LangChain
Le framework LangChain simplifie l’usage du cache grâce à des intergiciels dédiés.
Il ne faut pas confondre ce dispositif avec les modules de stockage locaux comme InMemoryCache. Ces derniers sauvegardent la réponse textuelle finale sur votre serveur ou votre base de données.
Le prompt caching de LangChain s’appuie sur des classes comme AnthropicPromptCachingMiddleware ou des configurations propres à AWS Bedrock. Il gère l’envoi des en-têtes de manière transparente lors des échanges.
Pour les modèles OpenAI sous LangChain, la structure de votre liste de messages suffit à déclencher l’optimisation. Veillez simplement à conserver l’ordre logique des messages pour préserver l’historique.
Cycle de vie et expiration des données
La mémoire cache n’est pas éternelle. Les infrastructures des fournisseurs d’accès appliquent des règles précises pour libérer l’espace sur leurs cartes graphiques.
- Durée de vie (TTL) : Les données restent actives en général entre 5 et 10 minutes.
- Réinitialisation de la durée : Chaque appel réussi qui utilise le cache remet le compteur de temps à zéro.
- Éviction automatique : En cas de forte affluence sur les serveurs, le fournisseur supprime les caches les moins sollicités selon l’algorithme LRU (les moins récemment utilisés).