Accueil › Glossaire › Context Caching

Context Caching

Le context caching est une technique d’optimisation des LLM qui consiste à stocker et réutiliser les états intermédiaires (KV-cache) calculés lors du traitement d’un contexte volumineux (documents, system prompts, historiques de conversation), évitant le recalcul à chaque nouvelle requête et réduisant les coûts de tokens d’input jusqu’à 90 % et la latence jusqu’à 85 %.

Le concept : pourquoi cacher le contexte

Quand un LLM traite un prompt, il passe chaque token à travers des dizaines de couches de transformers. À chaque couche, le mécanisme d’auto-attention calcule des vecteurs Key (K) et Value (V) pour chaque token. L’ensemble de ces vecteurs forme le KV-cache, la « mémoire de travail » du modèle pour cette requête.

Ce calcul, appelé phase de « prefill », est la partie la plus coûteuse du traitement. Pour un prompt de 100 000 tokens, le prefill peut prendre 5 à 10 secondes et consommer une quantité massive de compute GPU. Si 95 000 de ces tokens sont un document qui ne change pas entre les requêtes, recalculer le KV-cache à chaque fois est un gaspillage pur.

Le context caching élimine ce gaspillage. Le KV-cache du contexte stable est calculé une fois, stocké, et réutilisé pour chaque requête ultérieure qui partage le même contexte. Le modèle ne recalcule que les tokens nouveaux (la question de l’utilisateur), puis reprend la génération normalement.

Ce qui n’est PAS caché : la réponse du modèle. Chaque requête produit une réponse nouvelle et unique. Seuls les calculs intermédiaires (les vecteurs KV) sont réutilisés. Le context caching accélère le traitement de l’input, pas la génération de l’output.

Implicite vs explicite : deux approches fondamentales

L’industrie a convergé vers deux modes de context caching, parfois offerts simultanément par le même fournisseur.

Caching implicite (automatique)

Le fournisseur détecte automatiquement les préfixes répétés dans vos requêtes et réutilise le KV-cache sans intervention de votre part. Aucune modification de code n’est nécessaire.

Fonctionnement : quand le fournisseur reçoit une requête, il compare le préfixe de tokens avec les caches existants. Si un match est trouvé, les tokens cachés sont servis à prix réduit et avec une latence réduite. Si aucun match n’est trouvé, le prefill complet est effectué et le résultat est potentiellement mis en cache pour les requêtes suivantes.

Avantage : zéro effort d’implémentation. Vous bénéficiez de la réduction sans changer une ligne de code.

Inconvénient : le hit rate n’est pas garanti. Le routage vers un serveur qui détient le cache dépend de l’infrastructure du fournisseur. Chez OpenAI, le hit rate observé est d’environ 50 %. Le comportement est non déterministe.

Disponible chez : OpenAI (tous les modèles, seuil 1 024 tokens), Google Gemini 2.5+ (activé par défaut depuis mai 2025), DeepSeek (automatique).

Caching explicite (contrôlé)

Vous indiquez explicitement au fournisseur quel contenu doit être caché, pour combien de temps, et vous référencez ensuite ce cache dans vos requêtes ultérieures.

Fonctionnement : vous créez un objet cache (via un marqueur cache_control chez Anthropic, ou via l’API CachedContent.create chez Google Gemini), avec un TTL (Time-To-Live) défini. Les requêtes suivantes référencent ce cache et bénéficient d’une réduction garantie.

Avantage : hit rate proche de 100 % (le cache est explicitement créé et référencé), réduction garantie, comportement prévisible.

Inconvénient : nécessite des modifications de code. Chez Anthropic, l’écriture du cache coûte 1,25× le prix input (TTL 5 min) ou 2× (TTL 1 h). Chez Google, il y a des frais de stockage par heure. L’investissement est rentabilisé dès la 2e ou 3e requête.

Disponible chez : Anthropic (prompt caching avec cache_control), Google Gemini 1.5 et 2.5+ (context caching API), Google Vertex AI (CachedContent API avec CMEK supporté).

Google Gemini : context caching en détail

Google est le fournisseur qui a le plus formalisé le concept de « context caching » (par opposition au « prompt caching » d’Anthropic et OpenAI). L’implémentation offre des capacités uniques.

Cache explicite Gemini

Vous créez un objet cache via l’API, en spécifiant le contenu (texte, audio, vidéo, PDF), le modèle, et le TTL. Le cache est ensuite référencé par son identifiant dans les requêtes.

# Context caching explicite avec Gemini (Python)
from google import genai
from google.genai import types

client = genai.Client()

# 1. Créer le cache avec un TTL de 1 heure
cache = client.caches.create(
    model="models/gemini-2.5-flash",
    config=types.CreateCachedContentConfig(
        display_name="rapport-annuel-2025",
        system_instruction="Vous êtes un analyste financier expert...",
        contents=[
            types.Content(
                role="user",
                parts=[types.Part.from_text(long_annual_report)]  # 100K+ tokens
            )
        ],
        ttl="3600s",  # 1 heure
    )
)

print(f"Cache créé : {cache.name}")
print(f"Tokens cachés : {cache.usage_metadata.total_token_count}")

# 2. Utiliser le cache dans les requêtes
response = client.models.generate_content(
    model="models/gemini-2.5-flash",
    contents="Quels sont les principaux risques identifiés dans ce rapport ?",
    config=types.GenerateContentConfig(
        cached_content=cache.name,  # Référencer le cache
    )
)

print(response.text)
print(f"Tokens cachés utilisés : {response.usage_metadata.cached_content_token_count}")

Tarification. Sur Gemini 2.5+, les tokens lus depuis le cache coûtent 10 % du prix input standard (90 % de réduction). Le stockage du cache coûte entre $1 et $4,50 par million de tokens par heure selon le modèle. Ce coût de stockage est la principale différence avec le caching Anthropic/OpenAI, où le stockage est inclus dans le prix d’écriture et ne dure que 5 minutes à 1 heure.

Multimodal. L’avantage distinctif de Gemini : le context caching fonctionne avec tous les types de contenu supportés par Gemini, pas seulement le texte. Vous pouvez cacher une vidéo de 10 minutes, un fichier audio, un PDF scanné, ou un ensemble d’images. Le KV-cache de ce contenu multimodal est stocké et réutilisé pour chaque requête ultérieure. C’est un cas d’usage que ni Anthropic ni OpenAI ne couvrent aussi largement.

Cache implicite Gemini

Activé par défaut depuis mai 2025 sur la plupart des modèles Gemini. Aucune configuration requise. Google détecte automatiquement les préfixes répétés et applique une réduction quand un cache hit se produit. Le champ cachedContentTokenCount dans les métadonnées de réponse indique le nombre de tokens servis depuis le cache.

Le cache implicite n’a pas de frais de stockage. Vous ne payez que la réduction sur les tokens cachés quand un hit se produit. Si aucun hit ne se produit, vous payez le prix standard. C’est un bonus opportuniste sans risque.

Comparatif complet des fournisseurs

Verdict : Google Gemini offre l’implémentation la plus complète du context caching, avec le support multimodal unique (vidéo, audio, PDF), les deux modes simultanés, et une réduction de 90 % sur Gemini 2.5+. Anthropic offre la meilleure prévisibilité (hit rate ~100 % en explicite) et la réduction la plus agressive (90 %). OpenAI offre la simplicité maximale (zéro configuration) mais avec un hit rate incertain et une réduction moindre (50 %). DeepSeek offre un excellent rapport qualité-prix avec 90 % de réduction automatique.

Context caching en self-hosting

Si vous self-hostez vos modèles (via vLLM, TGI, ou un autre framework d’inférence), le context caching n’est pas géré par un fournisseur cloud. Vous devez l’implémenter vous-même au niveau du serveur d’inférence.

vLLM et prefix caching

vLLM, le framework d’inférence LLM le plus populaire en self-hosting, implémente le prefix caching nativement. Quand une requête partage un préfixe avec une requête précédente, vLLM réutilise le KV-cache stocké en mémoire GPU plutôt que de le recalculer.

# Activer le prefix caching dans vLLM
# Au lancement du serveur :
python -m vllm.entrypoints.openai.api_server 
    --model meta-llama/Llama-3-70B-Instruct 
    --enable-prefix-caching 
    --gpu-memory-utilization 0.9

Le prefix caching de vLLM utilise la technique PagedAttention pour gérer le KV-cache en blocs de mémoire de taille fixe, similaire à la pagination de la mémoire virtuelle dans les systèmes d’exploitation. Cela permet de partager efficacement les blocs de KV-cache communs entre plusieurs requêtes sans duplication.

La différence avec le context caching des fournisseurs cloud : le cache vLLM est en mémoire GPU (VRAM), pas sur un stockage persistant. Il survit tant que les blocs ne sont pas évincés par le cache eviction policy (quand la VRAM est pleine). Il ne persiste pas après un redémarrage du serveur. C’est un cache opportuniste, pas un cache managé avec TTL garanti.

SGLang et RadixAttention

SGLang, un framework d’inférence émergent, implémente RadixAttention, une technique qui organise les préfixes de prompts dans un arbre radix (trie). Cela permet un matching de préfixes très efficace et un partage du KV-cache entre des requêtes qui partagent des préfixes partiels. La structure en arbre est particulièrement efficace pour les workflows agentiques où de nombreuses requêtes partagent un même system prompt mais divergent ensuite.

Cas d’usage et patterns

RAG avec document volumineux

Le cas le plus rentable. Un pipeline RAG injecte un document de 50 000 tokens dans le contexte pour chaque question utilisateur. Sans caching, 10 questions coûtent 500 000 tokens d’input. Avec le caching Gemini (90 % de réduction), le coût tombe à 50 000 tokens plein tarif (première requête) + 450 000 tokens à 10 % du prix, soit une économie d’environ 81 %.

Chatbot avec system prompt complexe

Un chatbot enterprise avec un system prompt de 8 000 tokens (persona, règles métier, exemples, format de réponse). Ce prompt est identique pour chaque requête de chaque utilisateur. Le context caching évite le recalcul de ces 8 000 tokens à chaque message, réduisant la latence perçue et les coûts.

Analyse vidéo et audio (Gemini uniquement)

Un cas d’usage distinctif de Gemini : cacher une vidéo de 10 minutes ou un enregistrement audio d’une heure, puis poser des questions multiples sur ce contenu. Le traitement multimodal initial (extraction de features vidéo/audio) est coûteux en compute. Le context caching évite de le répéter. C’est un pattern impossible avec Anthropic ou OpenAI qui ne supportent pas le caching multimodal natif de ce type.

Conversations multi-tours

L’historique de conversation s’allonge à chaque tour. Avec le caching automatique d’Anthropic ou le caching implicite de Gemini, le cache avance automatiquement : les messages précédents sont lus depuis le cache, et seul le nouveau message est calculé. Plus la conversation est longue, plus le ratio de tokens cachés augmente.

Calculer le break-even du caching explicite

Le caching explicite a un coût de stockage (Google) ou d’écriture (Anthropic). Il faut calculer à partir de combien de requêtes le caching est rentable.

Formule de break-even

# Break-even pour Google Gemini 2.5 Pro (explicite)
# Paramètres
tokens_cached = 100_000  # tokens dans le cache
price_per_M_input = 1.25  # $/M tokens (Gemini 2.5 Pro, prompts ≤200K)
cache_read_discount = 0.10  # 10% du prix standard
storage_cost_per_M_per_hour = 4.50  # $/M tokens/heure (Gemini 2.5 Pro)
ttl_hours = 1  # durée du cache

# Coûts
cost_per_query_without_cache = tokens_cached / 1_000_000 * price_per_M_input  # $0.125
cost_per_query_with_cache = tokens_cached / 1_000_000 * price_per_M_input * cache_read_discount  # $0.0125
storage_cost = tokens_cached / 1_000_000 * storage_cost_per_M_per_hour * ttl_hours  # $0.45

saving_per_query = cost_per_query_without_cache - cost_per_query_with_cache  # $0.1125
break_even_queries = storage_cost / saving_per_query  # ~4 requêtes

# Avec 4+ requêtes dans l'heure, le caching est rentable
# Avec 20 requêtes : économie de 20 × $0.1125 - $0.45 = $1.80

Le break-even est typiquement entre 2 et 5 requêtes pour un cache de 100K tokens, selon le fournisseur et le modèle. Plus le contexte est grand et plus les requêtes sont fréquentes, plus le ROI est élevé.

Sécurité et isolation

Le context caching soulève des questions de sécurité similaires à celles du prompt caching côté fournisseur. Les garanties d’isolation :

Google Vertex AI : les caches explicites sont isolés par projet Google Cloud. Ils supportent le chiffrement via Customer-Managed Encryption Keys (CMEK), un avantage pour les workloads soumis à des exigences de résidence des données ou de compliance. Le caching implicite n’a pas de persistance, donc pas de risque de fuite entre sessions.

Anthropic : isolation par workspace. Le match doit être exact à 100 % (texte + images). Pas de partage cross-workspace.

Self-hosting (vLLM) : le KV-cache est en mémoire GPU du serveur. Si le serveur est partagé entre tenants (multi-tenant), les préfixes communs (system prompts identiques) sont naturellement partagés en mémoire. Les données spécifiques à chaque tenant (documents, questions) ne sont pas partagées car les préfixes divergent. Pour une isolation maximale, déployez des instances vLLM séparées par tenant.

Bonnes pratiques

Structurez vos prompts pour maximiser les préfixes communs. L’ordre canonique est : tools → system prompt → documents de référence → historique de conversation → message utilisateur. Le contenu stable doit être au début. Le contenu dynamique à la fin. Si le premier token diffère entre deux requêtes, le cache ne matche pas.

Choisissez le bon mode selon votre pattern d’usage. Requêtes fréquentes sur le même contexte (RAG, chatbot) : caching explicite pour la prévisibilité. Requêtes variées avec des préfixes qui se chevauchent parfois : caching implicite (bonus opportuniste). Les deux combinés offrent le meilleur des deux mondes.

Monitorez le hit rate et le coût réel. Chaque réponse API inclut les métriques de cache (tokens cachés lus, tokens écrits, tokens cache hit). Tracez le hit rate, le coût évité, et le coût de stockage. Un hit rate inférieur à 30 % avec du caching explicite indique un problème de structure de prompt ou un TTL trop court.

Ajustez le TTL au pattern de trafic. Si vos requêtes arrivent en burst (20 requêtes en 10 minutes, puis rien pendant 2 heures), un TTL de 15 minutes est suffisant. Si elles sont étalées sur la journée, un TTL plus long est nécessaire mais augmente les coûts de stockage. Mesurez le pattern réel avant de configurer.

Exploitez le caching multimodal de Gemini. Si votre application analyse des vidéos, des fichiers audio, ou des PDFs scannés, Gemini est le seul fournisseur qui offre du context caching sur ces formats. Le coût de traitement multimodal initial est élevé (audio coûte 2 à 7× le prix du texte). Le cacher et le réutiliser est souvent le seul moyen de rendre ces workloads économiquement viables en production.