Mise en Cache des Prompts LLM : Réduisez les Coûts API de 90 % (Les 3 Fournisseurs)

Mise en Cache des Prompts LLM : Réduisez les Coûts API de 90 % (Les 3 Fournisseurs)

La mise en cache des prompts LLM vous permet de réutiliser des tokens déjà traités entre les appels API -- réduisant les coûts d'entrée jusqu'à 90 % et le temps jusqu'au premier token jusqu'à 85 %. Si vous envoyez le même prompt système, les mêmes définitions d'outils ou les mêmes exemples few-shot à chaque requête, vous payez le plein tarif pour un travail que le GPU a déjà effectué.

Ce guide couvre OpenAI, Anthropic et Gemini avec le même chatbot implémenté dans les trois SDK -- quelque chose qu'aucun autre guide ne fait. Nous couvrons également la mise à jour du cache automatique d'Anthropic de février 2026, des scénarios de coûts en production avec de vrais montants en dollars, et les anti-patterns qui détruisent silencieusement votre taux de succès du cache.

Résumé Rapide -- Les Trois Fournisseurs en un Coup d'Œil

Avant de plonger dans les détails d'implémentation, voici la comparaison complète. Si vous savez déjà quel fournisseur vous utilisez, sautez directement à sa section. Si vous êtes en phase d'évaluation, ce tableau vous dit tout en 10 secondes.

Conclusion clé : OpenAI est le plus simple (zéro config, 50 % de remise). Anthropic offre la remise la plus profonde (90 %) avec le plus de contrôle. Gemini propose un TTL configurable et un cache implicite sur les modèles 2.5+ avec des remises comparables à Anthropic.

Comment Fonctionne la Mise en Cache des Prompts LLM ?

Vous n'avez pas besoin de comprendre les mécanismes internes des transformers pour utiliser la mise en cache des prompts efficacement. Mais vous devez comprendre un concept : la correspondance de préfixe.

Le Cache KV en 60 Secondes

Quand un LLM traite votre prompt, il calcule des états d'attention (paires clé-valeur) pour chaque token. Ces entrées de cache KV sont la partie coûteuse -- elles consomment la mémoire GPU et le temps de calcul. La mise en cache des prompts stocke ces états calculés pour que la prochaine requête avec le même préfixe ignore entièrement le recalcul.

Le mot crucial est préfixe. Le cache correspond depuis le début de votre prompt. Si les 2 000 premiers tokens correspondent à une entrée en cache mais que le token 2 001 diffère, ces 2 000 premiers tokens sont servis depuis le cache. Tout ce qui suit le point de divergence est calculé à nouveau.

C'est pourquoi l'ordre du prompt est important. Structurez vos prompts ainsi :

1. Définitions d'outils (les plus statiques)
2. Prompt système
3. Exemples few-shot statiques
4. Contexte récupéré (semi-dynamique)
5. Historique de conversation (croît à chaque tour)
6. Requête utilisateur (toujours différente)

Contenu statique d'abord, contenu dynamique en dernier. Plus les tokens correspondent au préfixe mis en cache, plus les économies sont importantes.

Mise en Cache des Prompts vs Mise en Cache Sémantique vs Mise en Cache des Réponses

Ces trois termes sont constamment confondus. La mise en cache des prompts (ce que couvre ce guide) réutilise les états KV calculés au niveau GPU pour des préfixes de tokens identiques -- aucune perte de précision, même sortie que sans cache. La mise en cache sémantique utilise la similarité des embeddings pour retourner des réponses précédemment générées pour des requêtes "suffisamment similaires" -- plus rapide mais peut retourner des mauvaises réponses. La mise en cache des réponses stocke des paires entrée-sortie exactes et retourne la réponse mise en cache telle quelle -- ne fonctionne que pour des requêtes vraiment identiques.

La mise en cache des prompts est la seule "optimisation gratuite" -- elle réduit coût et latence sans aucun compromis de précision. Pour les mathématiques approfondies des transformers derrière le cache KV, l'article technique de Hugging Face a mesuré une accélération de ~5,21x sur des GPU T4.

Comment OpenAI Gère-t-il la Mise en Cache des Prompts ?

La mise en cache des prompts d'OpenAI est entièrement automatique. Depuis octobre 2024, chaque appel API avec 1 024+ tokens d'entrée bénéficie automatiquement de la mise en cache. Pas d'opt-in, pas d'en-têtes, pas de changements de code.

Comment Fonctionne le Cache Automatique d'OpenAI

Quand vous envoyez une requête avec au moins 1 024 tokens, OpenAI vérifie si le préfixe correspond à une requête récente de votre organisation. Les succès de cache coûtent 50 % du prix standard des tokens d'entrée. Après le seuil initial de 1 024 tokens, le cache correspond par incréments de 128 tokens.

Le cache dure 5-10 minutes en utilisation normale et peut persister jusqu'à 24 heures lors de périodes creuses. Il est limité par organisation, donc différents projets au sein de la même organisation bénéficient de caches partagés.

Les modèles supportés incluent GPT-4o, GPT-4o-mini, GPT-4.1, o1, o3-mini, et tous les modèles plus récents.

Exemple Python SDK OpenAI

from openai import OpenAI

client = OpenAI()

# Ce prompt système fait ~2 000 tokens -- bien au-dessus du minimum de 1 024
SYSTEM_PROMPT = """You are a senior Python developer specializing in async programming.
You follow PEP 8, use type hints, and write comprehensive docstrings.
When reviewing code, check for: race conditions, resource leaks, error handling,
and performance bottlenecks. Always suggest specific fixes with code examples.
[... imagine 1,800 more tokens of coding guidelines, examples, and rules ...]"""

def chat(user_message: str) -> str:
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[
            {"role": "system", "content": SYSTEM_PROMPT},
            {"role": "user", "content": user_message},
        ],
    )

    # Vérifier si la mise en cache s'est activée
    usage = response.usage
    cached = usage.prompt_tokens_details.cached_tokens
    total_input = usage.prompt_tokens
    print(f"Cached: {cached}/{total_input} tokens ({cached/total_input*100:.0f}%)")

    return response.choices[0].message.content

# Premier appel : cache miss (prix plein)
chat("Review this async function for race conditions...")

# Deuxième appel dans les 5-10 min : cache hit (50 % de remise sur les tokens en cache)
chat("Now optimize the same function for throughput...")

Le premier appel traite tout au prix plein et remplit le cache. Le deuxième appel réutilise les tokens du prompt système mis en cache à moitié prix. Vous verrez quelque chose comme Cached: 1920/2048 tokens (94%) dans la sortie.

Verdict : OpenAI est le plus facile à démarrer -- zéro configuration, la mise en cache se fait automatiquement. La remise de 50 % est la plus faible des trois fournisseurs, mais rien n'égale la simplicité.

Comment Anthropic/Claude Gère-t-il la Mise en Cache des Prompts ?

Anthropic offre deux modes : la mise en cache automatique (activée par défaut depuis février 2026) et la mise en cache explicite avec des points de rupture cache_control. Le chiffre phare est difficile à ignorer -- les lectures en cache coûtent seulement 10 % du prix d'entrée standard, soit une remise de 90 %.

Cache Automatique vs Explicite (Mise à Jour 2026)

À partir du 5 février 2026, Anthropic active la mise en cache automatique par défaut pour tous les prompts éligibles. Vous n'avez plus besoin de l'ancien en-tête bêta. Le système détermine automatiquement les points de rupture de cache optimaux.

La mise en cache explicite est toujours disponible quand vous voulez un contrôle fin. Vous placez cache_control: {"type": "ephemeral"} sur des blocs de contenu spécifiques pour marquer exactement où la frontière du cache doit être. C'est utile quand votre prompt a une structure spécifique et que vous voulez garantir que certaines sections sont mises en cache.

Deux options TTL existent :

• Cache de 5 minutes (par défaut) : les écritures coûtent 1,25x le prix d'entrée de base, les lectures coûtent 0,1x. Rentabilisé après 1 succès de cache.
• Cache d'1 heure : les écritures coûtent 2x le prix d'entrée de base, les lectures coûtent 0,1x. Rentabilisé après 2 succès de cache. Disponible sur les modèles Claude 4.5+.

L'isolation du cache est passée du niveau organisation au niveau espace de travail le 5 février 2026. Cela signifie que différents espaces de travail au sein de la même organisation maintiennent des caches séparés.

Lorsque vous travaillez avec la mise en cache d'Anthropic, il est utile de structurer votre prompt pour une mise en cache optimale -- placer le contenu statique avant le contenu dynamique est encore plus important ici puisque vous payez une prime d'écriture.

Exemple Python SDK Anthropic

import anthropic

client = anthropic.Anthropic()

SYSTEM_PROMPT = """You are a senior Python developer specializing in async programming.
You follow PEP 8, use type hints, and write comprehensive docstrings.
When reviewing code, check for: race conditions, resource leaks, error handling,
and performance bottlenecks. Always suggest specific fixes with code examples.
[... imagine 1,800 more tokens of coding guidelines, examples, and rules ...]"""

def chat(user_message: str) -> str:
    response = client.messages.create(
        model="claude-sonnet-4-5-20250514",
        max_tokens=1024,
        system=[
            {
                "type": "text",
                "text": SYSTEM_PROMPT,
                "cache_control": {"type": "ephemeral"},  # Point de rupture explicite
            }
        ],
        messages=[
            {"role": "user", "content": user_message},
        ],
    )

    # Lire les métriques du cache depuis la réponse
    usage = response.usage
    created = usage.cache_creation_input_tokens
    read = usage.cache_read_input_tokens
    standard = usage.input_tokens
    print(f"Cache write: {created}, Cache read: {read}, Standard: {standard}")

    return response.content[0].text

# Premier appel : cache_creation_input_tokens = ~1920 (écriture à 1,25x)
chat("Review this async function for race conditions...")

# Deuxième appel : cache_read_input_tokens = ~1920 (lecture à 0,1x -- 90 % de remise !)
chat("Now optimize the same function for throughput...")

Comprendre la Tarification Écriture vs Lecture du Cache

Voici où la tarification d'Anthropic devient intéressante. En utilisant Claude Sonnet 4.5 (3 $/MTok entrée de base) comme exemple :

• Entrée standard : 3,00 $ par million de tokens
• Écriture cache (5 min) : 3,75 $ par million de tokens (1,25x) -- vous payez plus la première fois
• Lecture cache : 0,30 $ par million de tokens (0,1x) -- 90 % moins cher à chaque succès suivant

Le cache de 5 minutes est rentabilisé après seulement 1 lecture. Le cache d'1 heure (6,00 $/MTok écriture) est rentabilisé après 2 lectures. Si vous faites plus de quelques requêtes par minute avec le même préfixe, le calcul est largement en votre faveur.

Verdict : Anthropic offre la remise la plus profonde (90 %) et le plus de contrôle. Idéal pour les charges de travail à fort volume et sensibles aux coûts.

Comment Google Gemini Gère-t-il la Mise en Cache des Prompts ?

Gemini adopte une approche différente avec deux mécanismes de mise en cache distincts : la mise en cache de contexte explicite (objets cache nommés que vous créez et référencez) et la mise en cache implicite (automatique, zéro config, ajoutée en 2026 pour les modèles Gemini 2.5+).

Mise en Cache de Contexte Explicite (Caches Nommés)

Contrairement à OpenAI et Anthropic où la mise en cache est transparente, la mise en cache explicite de Gemini nécessite que vous créiez d'abord un objet cache nommé, puis que vous le référenciez dans les requêtes suivantes. Le seuil minimum de tokens est de 1 024 tokens pour les modèles Gemini Flash et de 4 096 tokens pour les modèles Pro. Le TTL est configurable -- la valeur par défaut est 1 heure, mais vous pouvez le régler selon vos besoins.

Les tokens en cache sur Gemini 2.5 Pro sont tarifés à 0,125 $/MTok contre le prix d'entrée standard de 1,25 $/MTok -- une remise de 90 %. Il y a aussi un coût de stockage de 4,50 $ par million de tokens par heure pour Pro, et 1,00 $ pour Flash.

Mise en Cache Implicite dans Gemini 2.5 (2026)

À partir de Gemini 2.5 Pro et Flash, Google a ajouté la mise en cache implicite -- une mise en cache automatique qui fonctionne comme l'approche d'OpenAI. Aucune configuration nécessaire. Placez du contenu large et commun au début de votre prompt et envoyez des requêtes avec des préfixes similaires en succession rapide. Le système détecte automatiquement le contenu éligible au cache et répercute les économies.

Exemple Python SDK Gemini

from google import genai
from google.genai import types

client = genai.Client()

SYSTEM_PROMPT = """You are a senior Python developer specializing in async programming.
You follow PEP 8, use type hints, and write comprehensive docstrings.
When reviewing code, check for: race conditions, resource leaks, error handling,
and performance bottlenecks. Always suggest specific fixes with code examples.
[... imagine 1,800 more tokens of coding guidelines, examples, and rules ...]"""

# Étape 1 : Créer un objet cache nommé
cache = client.caches.create(
    model="gemini-2.5-flash",
    config=types.CreateCachedContentConfig(
        display_name="python-review-guidelines",
        system_instruction=SYSTEM_PROMPT,
        ttl="3600s",  # 1 heure
    ),
)

print(f"Cache created: {cache.name}, expires: {cache.expire_time}")

# Étape 2 : Utiliser le cache dans les requêtes
response = client.models.generate_content(
    model="gemini-2.5-flash",
    contents="Review this async function for race conditions...",
    config=types.GenerateContentConfig(
        cached_content=cache.name,
    ),
)

# Vérifier l'utilisation du cache dans la réponse
metadata = response.usage_metadata
print(f"Cached tokens: {metadata.cached_content_token_count}")
print(f"Total input tokens: {metadata.prompt_token_count}")

L'approche explicite a un grand avantage : vous contrôlez précisément le TTL. Si vous savez que votre traitement par lot dure 4 heures, définissez un TTL de 4 heures et évitez l'expiration du cache en plein milieu du traitement.

Verdict : Le TTL configurable de Gemini et ses deux modes de mise en cache (explicite + implicite) le rendent polyvalent. Le seuil minimum est désormais comparable aux autres fournisseurs, et la remise de 90 % sur les lectures en cache correspond à Anthropic.

Comparaison du Code Côte à Côte -- Même Cas d'Usage, Les 3 Fournisseurs

Voici le même chatbot avec un prompt système mis en cache, implémenté dans les trois SDK. Comparez directement l'expérience développeur.

# --- OpenAI : Zéro config, appelez juste l'API ---
from openai import OpenAI
client = OpenAI()

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {"role": "system", "content": SYSTEM_PROMPT},  # Mis en cache automatiquement
        {"role": "user", "content": user_message},
    ],
)
cached = response.usage.prompt_tokens_details.cached_tokens

# --- Anthropic : Point de rupture cache_control explicite ---
import anthropic
client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-4-5-20250514",
    max_tokens=1024,
    system=[{
        "type": "text",
        "text": SYSTEM_PROMPT,
        "cache_control": {"type": "ephemeral"},  # Marquer la frontière du cache
    }],
    messages=[{"role": "user", "content": user_message}],
)
cached = response.usage.cache_read_input_tokens

# --- Gemini : Objet cache nommé ---
from google import genai
from google.genai import types

client = genai.Client()
cache = client.caches.create(
    model="gemini-2.5-flash",
    config=types.CreateCachedContentConfig(
        system_instruction=SYSTEM_PROMPT,
        ttl="3600s",
    ),
)
response = client.models.generate_content(
    model="gemini-2.5-flash",
    contents=user_message,
    config=types.GenerateContentConfig(cached_content=cache.name),
)
cached = response.usage_metadata.cached_content_token_count

Si vous voulez des économies sans effort, optez pour OpenAI. Si vous voulez la remise la plus profonde et un contrôle fin, choisissez Anthropic. Si vous avez besoin de durées de cache configurables ou si vous êtes déjà sur Google Cloud, prenez Gemini.

Calculateur de Coûts en Production -- Vraies Économies à Grande Échelle

Les pourcentages abstraits ne guident pas les décisions. Les montants en dollars, oui. Voici trois scénarios de production avec de vraies estimations de coûts en utilisant Claude Sonnet 4.5 (3 $/MTok entrée), GPT-4o (2,50 $/MTok entrée) et Gemini 2.5 Pro (1,25 $/MTok entrée).

Tarification vérifiée mars 2026. Consultez Anthropic, OpenAI et Gemini pour les tarifs actuels.

Hypothèses : 80 % de taux de succès du cache (réaliste pour des prompts bien structurés), tokens de sortie exclus puisque la mise en cache n'affecte que les coûts d'entrée.

Au niveau Growth, la mise en cache Anthropic économise 576 $/mois malgré un prix de base plus élevé qu'OpenAI. À l'échelle Enterprise, vous regardez 7 200 $/mois d'économies avec Anthropic -- soit 86 400 $ par an. C'est l'équivalent du salaire d'un ingénieur senior économisé grâce à un simple changement de configuration.

Le schéma est clair : plus votre volume de requêtes est élevé et plus votre préfixe statique est long, plus la mise en cache économise. La remise de 90 % d'Anthropic domine à grande échelle, mais le prix de base plus bas de Gemini le rend compétitif quand on prend en compte le coût total.

Anti-Patterns de Mise en Cache -- Quand NE PAS Mettre en Cache

La mise en cache semble simple jusqu'à ce que votre taux de succès soit mystérieusement à 0 %. Voici les erreurs qui détruisent silencieusement la mise en cache des prompts -- et comment les corriger.

Erreurs qui Brisent le Cache (Avec Solutions)

Horodatages dans les prompts système -- L'erreur la plus fréquente. Si votre prompt système inclut datetime.now(), la clé de cache change chaque seconde.

# MAUVAIS : Échecs de cache à chaque requête
system_prompt = f"""You are a helpful assistant.
Current time: {datetime.now().isoformat()}
Always be helpful and accurate."""

# BON : Déplacer l'horodatage vers le message utilisateur
system_prompt = """You are a helpful assistant.
Always be helpful and accurate."""

user_message = f"[Current time: {datetime.now().isoformat()}]\n{user_query}"

Contenu spécifique à l'utilisateur avant le contenu statique -- Si vous mettez session_id ou les préférences utilisateur au début, chaque utilisateur obtient un préfixe unique.

# MAUVAIS : Préfixe unique par utilisateur = zéro réutilisation du cache
messages = [
    {"role": "system", "content": f"User ID: {user_id}\nPreferences: {prefs}\n{GUIDELINES}"},
    {"role": "user", "content": query},
]

# BON : Contenu statique d'abord, contexte utilisateur à la fin
messages = [
    {"role": "system", "content": GUIDELINES},  # Identique pour tous -> mis en cache
    {"role": "user", "content": f"Context: User {user_id}, prefs: {prefs}\n{query}"},
]

Quand la Mise en Cache des Prompts N'Aide Vraiment Pas

Certains scénarios ne bénéficieront pas de la mise en cache même si vous structurez vos prompts parfaitement :

• Prompts à usage unique : Si chaque requête a un contexte complètement unique sans préfixe partagé, il n'y a rien à mettre en cache.
• Prompts très courts : En dessous de 1 024 tokens (OpenAI/Anthropic) ou 4 096 tokens (Gemini Pro), la mise en cache ne s'active pas.
• Requêtes peu fréquentes : Si les requêtes sont espacées de plusieurs heures, le cache expire avant l'arrivée d'une deuxième requête. La fenêtre de 5-10 minutes d'OpenAI et le TTL par défaut de 5 minutes d'Anthropic signifient que vous avez besoin d'un trafic constant.

La Mise en Cache des Prompts Fonctionne-t-elle avec le Streaming ?

Oui. La mise en cache des prompts et le streaming sont indépendants -- la mise en cache opère sur les tokens d'entrée, le streaming affecte la livraison des sorties. Ils résolvent des problèmes différents à différentes étapes du cycle de vie de la requête.

Le cache gère la phase de prefill (traitement de votre prompt d'entrée). Le streaming gère la phase de décodage (génération et envoi incrémentiel des tokens de sortie). Vous bénéficiez des deux avantages simultanément : prefill plus rapide grâce au succès du cache, plus livraison progressive des sorties grâce au streaming.

Voici un exemple de streaming avec mise en cache activée :

import anthropic

client = anthropic.Anthropic()

with client.messages.stream(
    model="claude-sonnet-4-5-20250514",
    max_tokens=1024,
    system=[{
        "type": "text",
        "text": SYSTEM_PROMPT,
        "cache_control": {"type": "ephemeral"},
    }],
    messages=[{"role": "user", "content": "Explain Python's GIL..."}],
) as stream:
    for text in stream.text_stream:
        print(text, end="", flush=True)

    # Après la fin du streaming, vérifier les métriques du cache
    usage = stream.get_final_message().usage
    print(f"\nCache read: {usage.cache_read_input_tokens} tokens")

L'amélioration du TTFT grâce à la mise en cache est en réalité la plus notable avec le streaming. Sans mise en cache, vous attendez le prefill complet avant que le premier token soit renvoyé en streaming. Avec la mise en cache, le prefill est quasi-instantané, donc les tokens commencent à affluer presque immédiatement.

Comment Surveiller les Taux de Succès du Cache en Production

Configurer la mise en cache est la moitié du travail. Savoir si elle fonctionne réellement est l'autre moitié. Si votre taux de succès du cache tombe en dessous de 50 %, quelque chose a changé dans la structure de votre prompt et vous laissez de l'argent sur la table.

Métriques de Cache Spécifiques au Fournisseur

Un Simple Journal de Taux de Succès du Cache

Voici une fonction utilitaire que vous pouvez intégrer dans n'importe quel projet pour suivre les taux de succès du cache via les champs de réponse API :

import logging

logger = logging.getLogger("cache_monitor")

def log_cache_metrics(provider: str, usage: dict) -> float:
    """Extrait et journalise les métriques de cache depuis la réponse d'un fournisseur. Retourne le taux de succès."""

    if provider == "openai":
        cached = getattr(usage.prompt_tokens_details, "cached_tokens", 0)
        total = usage.prompt_tokens
    elif provider == "anthropic":
        cached = usage.cache_read_input_tokens
        created = usage.cache_creation_input_tokens
        total = cached + created + usage.input_tokens
    elif provider == "gemini":
        cached = getattr(usage, "cached_content_token_count", 0)
        total = usage.prompt_token_count
    else:
        raise ValueError(f"Unknown provider: {provider}")

    hit_rate = (cached / total * 100) if total > 0 else 0
    logger.info(f"[{provider}] Cache hit rate: {hit_rate:.1f}% ({cached}/{total} tokens)")

    if hit_rate < 50:
        logger.warning(f"[{provider}] Low cache hit rate! Check prompt structure.")

    return hit_rate

Un système de production sain devrait maintenir des taux de succès du cache de 70-90 %. Si vous êtes en dessous de 50 %, revenez à la section anti-patterns. Vous pouvez aussi intégrer cela avec des métriques d'évaluation automatisées pour détecter les régressions dans votre pipeline de prompts.

La Mise en Cache des Prompts dans des Cas d'Usage Réels

Les exemples de chatbot ci-dessus illustrent les mécanismes, mais la mise en cache des prompts brille vraiment dans des patterns architecturaux spécifiques.

Pipelines RAG

Dans un setup RAG, votre prompt système et vos exemples few-shot sont statiques pour toutes les requêtes. Les documents récupérés changent à chaque fois. Structurez votre prompt pour maximiser le préfixe mis en cache :

1. Prompt système (mis en cache)
2. Exemples few-shot (mis en cache)
3. Documents récupérés (dynamique -- vient en dernier)
4. Requête utilisateur (toujours unique)

Avec un prompt système de 5 000 tokens et 3 000 tokens d'exemples few-shot, ce sont 8 000 tokens mis en cache à chaque requête. À 1 000 requêtes/jour sur Anthropic, vous économiseriez environ 6,50 $/jour rien que sur le préfixe mis en cache. Quand vous récupérez et mettez en cache des blocs de contexte, assurez-vous que la sortie de récupération vient après le préfixe statique.

Chatbots Multi-Tours

Les conversations multi-tours sont un point fort de la mise en cache des prompts. Chaque tour s'ajoute à l'historique de conversation, mais toute la conversation précédente est déjà mise en cache depuis les tours précédents. L'avantage du cache se compose -- au tour 10, vous pourriez avoir 15 000 tokens d'historique mis en cache avec seulement 200 tokens frais du dernier message utilisateur.

Systèmes Agentiques et Définitions d'Outils MCP

Si vous construisez des agents avec utilisation d'outils, vos définitions d'outils sont des schémas JSON statiques répétés à chaque appel API. Un agent typique pourrait avoir 20+ outils totalisant 3 000-5 000 tokens de définitions. C'est un excellent matériau de mise en cache.

C'est particulièrement pertinent pour les architectures basées sur MCP où les définitions d'outils serveur sont envoyées à chaque appel. Avec le cache_control explicite d'Anthropic, vous pouvez marquer le tableau tools pour la mise en cache et garantir que ces tokens sont réutilisés.

Quel Fournisseur Devriez-Vous Choisir ?

Si vous utilisez déjà un fournisseur, commencez là -- la mise en cache des prompts ne nécessite pas de changement. LiteLLM agit comme une couche proxy qui normalise les paramètres de mise en cache entre les fournisseurs, ce qui est utile si vous routez des requêtes vers plusieurs modèles.

FAQ -- Mise en Cache des Prompts LLM

Qu'est-ce que la mise en cache des prompts dans les LLMs ?

La mise en cache des prompts stocke les états d'attention calculés (cache KV) à partir de préfixes de prompts précédemment traités. Quand une requête suivante commence par la même séquence de tokens, le fournisseur réutilise ces états stockés plutôt que de les recalculer -- réduisant à la fois coût et latence sans impact sur la qualité des sorties.

Combien la mise en cache des prompts économise-t-elle sur les coûts API ?

Les économies vont de 50 % à 90 % selon le fournisseur. OpenAI offre une remise de 50 % sur les tokens d'entrée mis en cache. Anthropic offre jusqu'à 90 % de remise (lectures en cache à 0,1x du prix de base). Gemini offre environ 90 % de remise sur les lectures en cache. Les économies réelles dépendent de votre taux de succès du cache, de la longueur du prompt et de la fréquence des requêtes.

La mise en cache des prompts OpenAI se fait-elle automatiquement ?

Oui, depuis octobre 2024. Tout appel API avec 1 024+ tokens d'entrée bénéficie automatiquement de la mise en cache. Pas d'opt-in, pas d'en-têtes, pas de changements de code nécessaires. Le cache correspond aux préfixes de tokens depuis le début du prompt.

Quelle est la différence entre la mise en cache des prompts et la mise en cache sémantique ?

La mise en cache des prompts fait correspondre des préfixes de tokens exacts au niveau GPU -- il n'y a aucune perte de précision, et les sorties sont identiques aux requêtes non mises en cache. La mise en cache sémantique utilise la similarité des embeddings pour trouver des requêtes précédentes "suffisamment proches" et retourne des réponses mises en cache -- c'est plus rapide mais peut retourner des réponses incorrectes ou périmées. Elles résolvent des problèmes fondamentalement différents.

Combien de temps dure le cache de prompts ?

Cela varie selon le fournisseur. OpenAI : 5-10 minutes (jusqu'à 24 heures avec rétention étendue). Anthropic : 5 minutes (par défaut) ou 1 heure (disponible sur les modèles Claude 4.5+, coûte 2x en écriture). Gemini : configurable, 1 heure par défaut pour les caches explicites. Le TTL de mise en cache implicite est géré automatiquement par Google.

Quelle est la longueur minimale de tokens pour la mise en cache des prompts ?

OpenAI : 1 024 tokens. Anthropic : 1 024 tokens pour la plupart des modèles actuels. Gemini : 1 024 tokens pour les modèles Flash, 4 096 pour les modèles Pro. Les prompts inférieurs à ces seuils n'activeront pas la mise en cache -- c'est le problème le plus courant du type "ça ne fonctionne pas".

La mise en cache des prompts fonctionne-t-elle avec les réponses en streaming ?

Oui. La mise en cache et le streaming opèrent sur différentes phases de la requête. La mise en cache accélère la phase de prefill des entrées ; le streaming livre les tokens de sortie de manière incrémentielle. Les deux fonctionnent simultanément, et vous noterez réellement l'amélioration du TTFT plus avec le streaming activé.

Quand ne devrais-je PAS utiliser la mise en cache des prompts ?

Évitez de compter sur la mise en cache quand vos prompts sont sous le seuil minimal de tokens, quand vous incluez des horodatages ou des IDs de session dans le prompt système, quand vous faites tourner les exemples few-shot entre les appels, ou quand les requêtes sont trop peu fréquentes pour atteindre le cache avant son expiration (fenêtre de 5-10 minutes pour OpenAI/Anthropic).

Puis-je utiliser la mise en cache des prompts avec LangChain ou LiteLLM ?

Oui. LangChain transmet les paramètres de mise en cache spécifiques au fournisseur via ses wrappers API. LiteLLM fournit une syntaxe de mise en cache unifiée qui normalise cache_control pour Anthropic, OpenAI, Gemini, Vertex AI et Bedrock -- particulièrement utile pour les configurations multi-fournisseurs.

Qu'est-ce qu'un succès de cache vs un échec de cache ?

Un succès de cache signifie que le fournisseur a trouvé un préfixe correspondant en mémoire et a réutilisé les états KV stockés -- vous payez le tarif réduit de tokens mis en cache et obtenez un TTFT plus rapide. Un échec de cache signifie qu'aucune correspondance n'a été trouvée, donc le prompt complet est traité depuis le début au prix standard. Vérifiez les champs cached_tokens (OpenAI), cache_read_input_tokens (Anthropic) ou cachedContentTokenCount (Gemini) dans la réponse API pour voir ce qui s'est produit.

Verdict Final

La mise en cache des prompts est l'optimisation à moindre effort et rendement le plus élevé dans la pile API LLM. Vous ne changez pas votre modèle, vous ne sacrifiez pas la qualité, et l'implémentation va de "ne rien faire" (OpenAI) à "ajouter un champ" (Anthropic) à "créer un objet cache" (Gemini).

Commencez avec la mise en cache automatique de votre fournisseur actuel. Mesurez votre taux de succès du cache avec l'utilitaire de journalisation ci-dessus. Si vous êtes en dessous de 70 %, restructurez vos prompts (statique d'abord, dynamique en dernier) et éliminez les anti-patterns. La plupart des équipes voient 50-80 % de réduction des coûts dans la journée suivant la mise en œuvre de ces changements.

Sources

• Anthropic Prompt Caching Documentation
• OpenAI Prompt Caching Guide
• Gemini Context Caching Documentation
• Anthropic Model Pricing
• Gemini API Pricing
• KV Caching Explained -- Hugging Face Blog
• LiteLLM Prompt Caching Documentation