Accueil › Glossaire › Prompt Caching

Prompt Caching

Le prompt caching est une optimisation proposée par les fournisseurs de LLM qui stocke le KV-cache (paires clé-valeur) généré lors du traitement d’un prompt, pour le réutiliser lors de requêtes ultérieures partageant le même préfixe, réduisant les coûts de tokens d’input jusqu’à 90 % et la latence (TTFT) jusqu’à 85 %.

Comment fonctionne le prompt caching

Pour comprendre le prompt caching, il faut d’abord comprendre ce que fait un LLM quand il traite un prompt. Le modèle ne « lit » pas le texte comme un humain. Il le transforme en tokens, puis chaque token passe à travers des dizaines de couches de transformers. À chaque couche, le mécanisme d’attention calcule des paires clé-valeur (KV pairs) pour chaque token. Ces paires représentent la « compréhension » que le modèle a du contexte à ce stade du traitement.

Ce calcul du KV-cache est la partie la plus coûteuse du traitement d’un prompt (la phase de « prefill »). Pour un prompt de 30 000 tokens, cette phase peut prendre plusieurs secondes et consommer une quantité significative de compute GPU.

Le prompt caching stocke ce KV-cache. Quand une requête ultérieure commence par le même préfixe de tokens, le fournisseur récupère le KV-cache stocké au lieu de le recalculer. Le modèle reprend directement là où le cache s’arrête, ne calculant que les tokens non cachés (la partie dynamique du prompt) et la réponse.

Point crucial : le prompt caching ne cache pas la réponse du modèle. Chaque requête produit une réponse unique, même si le préfixe est identique. C’est le calcul intermédiaire (le KV-cache) qui est réutilisé, pas le résultat final. Deux requêtes avec le même préfixe mais des questions différentes à la fin produiront des réponses différentes.

Comparatif des fournisseurs

Chaque fournisseur implémente le prompt caching différemment. Les deux approches fondamentales sont le caching automatique (OpenAI, DeepSeek, Gemini 2.5) et le caching explicite (Anthropic, Google Gemini 1.5).

Anthropic (Claude) : contrôle et prévisibilité

Anthropic offre deux modes de caching. Le mode explicite (historique) utilise des marqueurs cache_control dans les blocs de contenu pour indiquer précisément ce qui doit être caché. Le mode automatique (plus récent) cache tout le contenu jusqu’au dernier bloc cacheable sans configuration manuelle.

Les tokens lus depuis le cache coûtent 10 % du prix normal, soit une réduction de 90 %. C’est la réduction la plus agressive du marché. En contrepartie, l’écriture du cache coûte 1,25× le prix input (TTL 5 minutes) ou 2× (TTL 1 heure). L’investissement est rentable dès la deuxième requête avec le même préfixe.

Un avantage majeur chez Anthropic : les tokens cachés ne comptent pas vers la limite ITPM (Input Tokens Per Minute) du rate limiting. Cela signifie que le caching augmente effectivement votre capacité de débit, parfois d’un facteur 5 à 10×.

Depuis février 2026, le cache est isolé au niveau du workspace (pas de l’organisation), garantissant la séparation des données entre workspaces dans un contexte multi-tenant.

# Prompt caching explicite avec Anthropic (Python)
import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-4-20250514",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "Vous êtes un assistant juridique expert...",
        },
        {
            "type": "text",
            "text": long_legal_document,  # 20K+ tokens
            "cache_control": {"type": "ephemeral"},  # Marquer pour le cache
        },
    ],
    messages=[
        {"role": "user", "content": "Quelles sont les clauses de résiliation ?"}
    ],
)

# Vérifier l'usage du cache
print(f"Tokens input : {response.usage.input_tokens}")
print(f"Tokens cachés lus : {response.usage.cache_read_input_tokens}")
print(f"Tokens écrits en cache : {response.usage.cache_creation_input_tokens}")

OpenAI : zéro configuration, résultats variables

OpenAI active le prompt caching automatiquement sur tous les modèles supportés, sans aucune modification de code. Le système détecte si le préfixe de votre prompt correspond à un cache existant et sert les tokens cachés à 50 % du prix normal.

Le seuil est de 1 024 tokens minimum, avec des incréments de 128 tokens. Le TTL est de 5 à 10 minutes d’inactivité (non publié officiellement). L’écriture du cache est gratuite (pas de surcoût à la première requête).

Le compromis : le hit rate est d’environ 50 % dans les tests indépendants. OpenAI tente de router les requêtes vers les serveurs qui détiennent le cache, mais ce routage n’est pas garanti. Pour les applications où la latence doit être prévisible, ce comportement non déterministe peut poser problème.

Google Gemini : deux approches selon le modèle

Gemini 1.5 utilise un « context caching » explicite : vous créez un objet CachedContent via l’API, avec un TTL configurable (1 heure par défaut). Le cache est ensuite référencé dans les requêtes. Le seuil minimum est élevé : 32 768 tokens.

Gemini 2.5 Pro et Flash supportent le caching implicite (automatique), similaire à OpenAI, sans configuration requise.

Cas d’usage optimaux

Le prompt caching est rentable quand un préfixe long est réutilisé dans plusieurs requêtes. Les cas les plus courants :

System prompts longs. Un system prompt de 5 000+ tokens (instructions complexes, persona, format de réponse) est identique pour chaque requête d’un même produit. Sans cache, ces tokens sont recalculés à chaque appel. Avec le cache, ils ne sont calculés qu’une fois.

RAG avec documents volumineux. Un pipeline RAG qui injecte un document de 20 000 tokens dans le contexte pour chaque question. Si l’utilisateur pose 10 questions sur le même document, le cache évite de retraiter 20 000 tokens × 10 requêtes.

Conversations multi-tours. L’historique de conversation (messages précédents) s’allonge à chaque tour. Le cache stocke l’historique déjà traité et ne recalcule que le nouveau message. Plus la conversation est longue, plus le gain est important.

Few-shot learning avec beaucoup d’exemples. Un prompt contenant 50 exemples annotés (10 000+ tokens) est identique pour chaque nouvelle requête. Le cache élimine le recalcul des exemples.

Analyse de code. Un prompt qui inclut une codebase entière (50K+ tokens) pour du code review ou du debugging. Le cache stocke le traitement de la codebase et ne recalcule que la question spécifique de l’utilisateur.

Calculer le ROI du prompt caching

Le prompt caching est-il rentable dans votre cas ? Voici le calcul :

Exemple avec Anthropic Claude Sonnet 4

Scénario : un chatbot RAG qui injecte un document de 20 000 tokens dans chaque requête. 100 requêtes par heure, même document.

Le cache est rentable dès la 2e requête avec le même préfixe. Sur 100 requêtes, l’économie est massive : 87 % sur les coûts et un TTFT réduit de 85 %. Plus le préfixe est long et plus les requêtes sont fréquentes, plus le ROI est élevé.

Quand le caching n’est PAS rentable

Le prompt caching n’a aucun intérêt si le préfixe change à chaque requête (chaque question a un document différent), si le prompt est court ( 5-10 minutes entre chaque, le cache expire). Dans ces cas, vous payez le surcoût du cache write sans jamais bénéficier du cache read.

Implémentation : bonnes pratiques

Structurer le prompt pour le cache

# Structure optimale pour le prompt caching
# 1. Tools (si function calling) ← cachés
# 2. System prompt ← caché
# 3. Documents / Few-shot examples ← cachés
# 4. Historique de conversation ← caché (avance à chaque tour)
# 5. Message utilisateur ← NON caché (dynamique)

messages = [
    {
        "role": "system",
        "content": [
            {"type": "text", "text": system_instructions},     # Stable
            {"type": "text", "text": reference_document,        # Stable
             "cache_control": {"type": "ephemeral"}},
        ]
    },
    # Historique (les tours précédents sont cachés automatiquement)
    {"role": "user", "content": "Question précédente..."},
    {"role": "assistant", "content": "Réponse précédente..."},
    # Nouveau message (dynamique, pas caché)
    {"role": "user", "content": "Nouvelle question de l'utilisateur"}
]

Monitorer les performances du cache

Chaque réponse API inclut des métriques de cache dans l’objet usage :

# Anthropic : métriques de cache dans la réponse
{
  "usage": {
    "input_tokens": 523,                    # Tokens input non cachés
    "cache_read_input_tokens": 20480,       # Tokens lus depuis le cache
    "cache_creation_input_tokens": 0,       # Tokens écrits en cache (0 = cache hit)
    "output_tokens": 256
  }
}

# OpenAI : métriques dans prompt_tokens_details
{
  "usage": {
    "prompt_tokens": 21003,
    "prompt_tokens_details": {
      "cached_tokens": 20480              # Tokens servis depuis le cache
    },
    "completion_tokens": 256
  }
}

Trackez le hit rate (ratio cache reads / total input tokens) et le coût évité (tokens cachés × prix normal – tokens cachés × prix cache read). Si le hit rate est faible (< 30 %), vérifiez la structure de vos prompts : le contenu dynamique est probablement mal positionné.

Lien avec le KV-cache et l’optimisation mémoire

Le prompt caching côté fournisseur est une application du concept plus large de KV-cache. Dans un transformer, chaque couche d’attention génère des vecteurs Key et Value pour chaque token. Ces vecteurs sont stockés en mémoire GPU pour être réutilisés lors de la génération des tokens suivants (c’est pourquoi la génération token par token est possible sans recalculer tout le contexte à chaque étape).

Le KV-cache consomme une quantité significative de mémoire VRAM. Pour un modèle de 70B paramètres avec un contexte de 128K tokens, le KV-cache peut occuper plusieurs dizaines de Go. Les techniques d’optimisation du KV-cache (PagedAttention dans vLLM, prefix caching local, KV-cache quantization) sont complémentaires au prompt caching du fournisseur.

La différence : le prompt caching côté fournisseur (Anthropic, OpenAI) est un service managé transparent pour le développeur. Le KV-cache optimization est une technique d’ingénierie système appliquée par ceux qui self-hostent leurs propres modèles (via vLLM, TGI, ou un framework d’inférence custom).

Sécurité et isolation du cache

Le cache est un vecteur potentiel de fuite de données si les prompts d’un client sont servis depuis le cache d’un autre client. Les fournisseurs implémentent une isolation stricte :

Anthropic : le cache est isolé par workspace (depuis février 2026). Deux workspaces dans la même organisation ne partagent jamais de cache, même avec des prompts identiques. Deux organisations ne partagent jamais de cache. Le cache nécessite un match exact à 100 % du contenu (texte et images).

OpenAI : le cache est isolé par organisation. Aucun partage cross-organisation.

Implication multi-tenant : si votre application SaaS utilise un seul workspace Anthropic pour tous vos clients, les prompts de tous les clients partagent le même espace de cache. C’est un avantage (meilleur hit rate si les system prompts sont identiques) mais aussi un point d’attention : un prompt contenant des données du client A pourrait théoriquement être servi depuis le cache créé avec les mêmes données. En pratique, le match exact à 100 % rend ce scénario improbable (la question de l’utilisateur diffère), mais pour les workloads les plus sensibles, des workspaces séparés par client offrent une isolation garantie.

Bonnes pratiques

Mettez le contenu statique au début du prompt. Le cache ne fonctionne que sur les préfixes. Si le premier token diffère entre deux requêtes, le cache ne matche pas. L’ordre canonique est : tools → system prompt → documents → historique → question utilisateur.

Utilisez Anthropic pour les longs contextes prévisibles. Le contrôle explicite d’Anthropic (hit rate ~100 %) et la réduction de 90 % en font le choix optimal pour les cas où le préfixe est long et stable (RAG, analyse de documents, few-shot). OpenAI convient mieux pour les cas où le caching est un bonus opportuniste plutôt qu’une stratégie centrale.

Maintenez le cache chaud. Avec un TTL de 5 minutes, le cache expire si aucune requête n’est envoyée pendant 5 minutes. Pour les applications à trafic intermittent, envoyez des « heartbeat requests » périodiques pour maintenir le cache. Ou utilisez le TTL 1 heure d’Anthropic (2× le prix d’écriture) pour les sessions longues.

Trackez le coût de cache write vs cache read. Chez Anthropic, le cache write coûte 1,25× le prix input. Si votre préfixe n’est utilisé qu’une seule fois (hit rate 0 %), vous payez 25 % de plus qu’un appel normal. Monitorez le hit rate et désactivez le caching pour les prompts qui ne bénéficient pas de réutilisation.

Combinez avec le metering par tenant. Le prompt caching réduit le coût par requête mais peut complexifier le metering. Les tokens cachés sont facturés à un tarif différent. Votre pipeline de metering doit distinguer les tokens normaux, les tokens cache write, et les tokens cache read pour une facturation correcte de vos clients.