Infrastructure de mise en cache des prompts : Réduire les coûts et la latence des LLM

Mis à jour le 11 décembre 2025

Mise à jour de décembre 2025 : La mise en cache des préfixes d'Anthropic offre une réduction des coûts de 90 % et une réduction de la latence de 85 % pour les prompts longs. La mise en cache automatique d'OpenAI est activée par défaut (économies de 50 %). 31 % des requêtes LLM présentent une similarité sémantique avec des requêtes précédentes — une inefficacité massive sans mise en cache. Les lectures de cache à 0,30 $/M tokens contre 3,00 $/M pour le traitement standard (Anthropic). Une architecture de mise en cache multi-niveaux (sémantique → préfixe → inférence) maximise les économies.

La mise en cache des prompts d'Anthropic réduit les coûts jusqu'à 90 % et la latence jusqu'à 85 % pour les prompts longs.¹ OpenAI atteint une réduction des coûts de 50 % avec la mise en cache automatique activée par défaut. Les recherches montrent que 31 % des requêtes LLM présentent une similarité sémantique avec des requêtes précédentes, représentant une inefficacité massive dans les déploiements sans infrastructure de mise en cache.² Les organisations exécutant des applications d'IA en production perdent des sommes considérables sans stratégies de mise en cache appropriées.

La mise en cache des prompts opère à plusieurs niveaux — de la mise en cache des préfixes côté fournisseur qui réutilise les calculs du cache KV, à la mise en cache sémantique au niveau applicatif qui renvoie les réponses précédentes pour des requêtes similaires. Comprendre chaque couche et quand la déployer aide les organisations à optimiser à la fois les coûts et la latence pour leurs patterns de charge de travail spécifiques.

Fondamentaux de la mise en cache

Les coûts d'inférence LLM proviennent de deux sources : le traitement des tokens d'entrée et la génération des tokens de sortie. Les stratégies de mise en cache ciblent les deux :

Mise en cache des tokens d'entrée (mise en cache des préfixes)

Chaque requête LLM traite les tokens d'entrée via le mécanisme d'attention du modèle, générant des paires clé-valeur stockées dans le cache KV. Lorsque plusieurs requêtes partagent des préfixes identiques — prompts système, exemples few-shot ou contexte documentaire — le calcul du cache KV se répète inutilement.

Solution de mise en cache des préfixes : Stocker les valeurs KV calculées pour les préfixes courants. Les requêtes suivantes avec des préfixes correspondants sautent le recalcul, démarrant à partir de l'état mis en cache.

Impact sur les coûts : - Anthropic : Les lectures de cache coûtent 0,30 $/M tokens contre 3,00 $/M pour le traitement standard (économies de 90 %) - OpenAI : Réduction de 50 % pour les tokens mis en cache - Google : Tarification variable selon la fenêtre de contexte

Impact sur la latence : Sauter le calcul du préfixe réduit le délai avant le premier token de 50 à 85 % selon la longueur du préfixe.

Mise en cache des sorties (mise en cache sémantique)

Certaines requêtes méritent des réponses identiques — questions répétées, requêtes déterministes ou recherches ne nécessitant pas de régénération.

Solution de mise en cache sémantique : Stocker les réponses en sortie indexées par des entrées sémantiquement similaires. Renvoyer les réponses mises en cache sans invocation LLM pour les requêtes correspondantes.

Impact sur les coûts : Les réponses mises en cache éliminent entièrement les appels API — 100 % d'économies sur les hits de cache.

Impact sur la latence : La réponse revient en millisecondes contre des secondes pour l'inférence LLM.

Hiérarchie de mise en cache

Les systèmes de production implémentent généralement plusieurs couches de mise en cache :

Requête → Cache sémantique (100 % éco.) → Cache préfixe (50-90 % éco.) → Inférence complète
              ↓                                  ↓                              ↓
         Réponse en cache              État KV en cache              Calcul complet

Chaque couche capture différentes opportunités d'optimisation basées sur les patterns de similarité des requêtes.

Mise en cache des prompts au niveau fournisseur

Anthropic Claude

Anthropic offre la mise en cache des prompts la plus configurable :³

Tarification : - Écritures en cache : Surcoût de 25 % par rapport au prix d'entrée de base - Lectures en cache : Réduction de 90 % (10 % du prix de base) - Seuil de rentabilité : 2+ hits de cache par préfixe mis en cache

Exigences : - Minimum 1 024 tokens par point de contrôle de cache - Jusqu'à 4 points de contrôle de cache par requête - Durée de vie du cache : 5 minutes depuis le dernier accès (étendue à 1 heure avec des hits réguliers) - Jusqu'à 5 tours de conversation pouvant être mis en cache

Implémentation :

import anthropic

client = anthropic.Anthropic()

# Marquer le contenu pour la mise en cache avec cache_control
response = client.messages.create(
    model="claude-3-5-sonnet-20241022",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "Vous êtes un assistant expert pour notre logiciel d'entreprise...",
            "cache_control": {"type": "ephemeral"}  # Marquer pour la mise en cache
        }
    ],
    messages=[{"role": "user", "content": "Comment configurer les permissions utilisateur ?"}]
)

Bonnes pratiques : - Placer le contenu statique (prompts système, documentation) au début du prompt - Placer le contenu dynamique (entrée utilisateur, conversation) à la fin - Utiliser les points de contrôle de cache aux frontières naturelles - Surveiller les taux de hit de cache pour vérifier l'optimisation

OpenAI

OpenAI implémente une mise en cache automatique sans modification de code :⁴

Tarification : - Tokens mis en cache : 50 % du prix d'entrée de base - Pas de surcoût d'écriture en cache

Exigences : - Minimum 1 024 tokens pour l'éligibilité à la mise en cache - Les hits de cache se produisent par incréments de 128 tokens - Durée de vie du cache : 5-10 minutes d'inactivité

Comportement automatique : - Les prompts dépassant 1 024 tokens sont automatiquement mis en cache - Le système détecte les préfixes correspondants entre les requêtes - Aucune modification d'API requise

Surveillance :

response = client.chat.completions.create(
    model="gpt-4-turbo",
    messages=[...],
)

# Vérifier l'utilisation pour les hits de cache
print(f"Tokens mis en cache : {response.usage.prompt_tokens_details.cached_tokens}")
print(f"Total tokens d'entrée : {response.usage.prompt_tokens}")

Google Gemini

Google fournit la mise en cache de contexte pour les modèles Gemini :⁵

Tarification : - Variable selon la taille du contexte mis en cache et la durée - Frais de stockage pour le contenu mis en cache

Fonctionnalités : - Création et gestion explicites du cache - Durée de vie configurable - Partage du cache entre requêtes

Implémentation :

from google.generativeai import caching

# Créer du contenu mis en cache
cache = caching.CachedContent.create(
    model='models/gemini-1.5-pro-001',
    display_name='documentation-produit',
    system_instruction="Vous êtes un expert produit...",
    contents=[product_docs],
    ttl=datetime.timedelta(hours=1)
)

# Utiliser le contenu mis en cache dans les requêtes
model = genai.GenerativeModel.from_cached_content(cached_content=cache)
response = model.generate_content("Comment configurer la fonctionnalité X ?")

Amazon Bedrock

AWS offre la mise en cache des prompts en préversion pour les modèles supportés :⁶

Exigences : - Claude 3.5 Sonnet nécessite un minimum de 1 024 tokens par point de contrôle - Le second point de contrôle nécessite 2 048 tokens

Le pattern d'implémentation correspond à l'approche cache_control d'Anthropic au sein de la structure API de Bedrock.

Mise en cache des préfixes vLLM

L'inférence auto-hébergée avec vLLM inclut la mise en cache automatique des préfixes :⁷

Architecture

L'Automatic Prefix Caching (APC) de vLLM stocke les blocs KV dans une table de hachage, permettant la réutilisation du cache sans structures arborescentes :

Conception clé : - Tous les blocs KV stockés dans le pool de blocs à l'initialisation - Recherche basée sur le hachage pour la correspondance des préfixes - Opérations O(1) pour la gestion des blocs - Efficacité mémoire PagedAttention maintenue

Configuration

from vllm import LLM

llm = LLM(
    model="meta-llama/Llama-3.1-8B-Instruct",
    enable_prefix_caching=True,  # Activer APC
    gpu_memory_utilization=0.90,
)

Impact sur les performances

vLLM avec PagedAttention démontre un débit 14-24x supérieur aux implémentations naïves.⁸ La mise en cache des préfixes ajoute :

• Différence de coût de 10x entre les tokens mis en cache et non mis en cache
• Réduction de la latence d'un ordre de grandeur pour les préfixes correspondants
• Efficacité mémoire grâce aux blocs KV partagés

Considérations de sécurité

vLLM supporte l'isolation du cache pour les environnements partagés :

# Le sel de cache par requête empêche l'accès au cache entre locataires
response = llm.generate(
    prompt="...",
    sampling_params=SamplingParams(...),
    cache_salt="locataire-123"  # Isoler le cache par locataire
)

L'injection de sel de cache dans les hachages de blocs prévient les attaques temporelles où des adversaires infèrent le contenu mis en cache par l'observation de la latence.

Extension LMCache

LMCache étend vLLM avec des capacités de mise en cache avancées :⁹

Fonctionnalités : - Réutilisation du cache KV entre instances de moteur - Stockage multi-niveaux (GPU → RAM CPU → disque) - Mise en cache du contenu non-préfixe - Réduction de latence de 3-10x dans les benchmarks

Architecture :

Moteur vLLM → LMCache → VRAM GPU (chaud)
                     → RAM CPU (tiède)
                     → Disque local (froid)

Mise en cache sémantique

La mise en cache sémantique renvoie les réponses précédentes pour des requêtes sémantiquement similaires (pas seulement identiques) :

GPTCache

GPTCache fournit une mise en cache sémantique open-source pour les applications LLM :¹⁰

Architecture :

Requête → Embedding → Recherche vectorielle → Vérif. similarité → Réponse/Appel API
              ↓           ↓                        ↓
         BERT/OpenAI   Milvus/FAISS          Seuil (0.8)

Composants : - Adaptateur LLM : Intégration avec divers fournisseurs LLM - Générateur d'embeddings : Vectorisation des requêtes - Base vectorielle : Recherche de similarité (Milvus, FAISS, Zilliz) - Gestionnaire de cache : Stockage et récupération - Évaluateur de similarité : Correspondance basée sur un seuil

Implémentation :

from gptcache import cache
from gptcache.adapter import openai

# Initialiser le cache sémantique
cache.init(
    pre_embedding_func=get_text_embedding,
    data_manager=manager,
)

# Utiliser les appels OpenAI mis en cache
response = openai.ChatCompletion.create(
    model='gpt-4',
    messages=[{"role": "user", "content": "Qu'est-ce que le machine learning ?"}]
)
# Les requêtes sémantiquement similaires ("Expliquez le ML", "Définissez l'apprentissage automatique")
# renvoient la réponse mise en cache

Performance

GPTCache atteint des gains d'efficacité significatifs :¹¹

• Réduction des appels API : Jusqu'à 68,8 % selon les catégories de requêtes
• Taux de hit de cache : 61,6 % à 68,8 %
• Précision : 97 %+ de taux de hit positif
• Réduction de latence : 40-50 % sur les hits de cache, jusqu'à 100x pour les hits complets

Techniques avancées

Seuils adaptatifs VectorQ :¹²

Les seuils de similarité statiques (par ex. 0,8) fonctionnent mal sur des requêtes diverses. VectorQ apprend des régions de seuils spécifiques aux embeddings qui s'adaptent à la complexité des requêtes :

• Requêtes factuelles simples : Seuils plus élevés (correspondance plus stricte)
• Requêtes ouvertes : Seuils plus bas (plus de réutilisation)
• Requêtes ambiguës : Ajustement dynamique

Détection de patterns SCALM :

SCALM améliore GPTCache grâce à la détection de patterns et l'analyse de fréquence : - Amélioration de 63 % du ratio de hit de cache - Réduction de 77 % de l'utilisation de tokens - Identifie les patterns d'entrées de cache à haute fréquence

Quand utiliser la mise en cache sémantique

Bons candidats : - Requêtes de type FAQ avec espace de réponses limité - Requêtes de recherche (info produit, documentation) - Réponses déterministes (calculs, formatage) - Applications à fort trafic avec répétition de requêtes

Mauvais candidats : - Génération créative nécessitant l'unicité - Réponses personnalisées (contexte spécifique à l'utilisateur) - Informations sensibles au temps - Patterns de requêtes à faible répétition

Patterns d'implémentation

Applications de chat

Les systèmes de chat bénéficient à la fois de la mise en cache des préfixes et sémantique :

Mise en cache du prompt système :

# Prompt système statique mis en cache au début de la requête
system_prompt = """
Vous êtes un agent de support client pour Acme Corp...
[2000+ tokens de directives et connaissances]
"""

# Conversation dynamique ajoutée après le préfixe mis en cache
messages = [
    {"role": "system", "content": system_prompt, "cache_control": {...}},
    {"role": "user", "content": user_message}
]

Mise en cache de l'historique de conversation : Anthropic supporte la mise en cache jusqu'à 5 tours de conversation, réduisant les coûts pour les conversations multi-tours.

Applications RAG

La génération augmentée par récupération met en cache le contexte récupéré :

# Structure de cache pour RAG
cached_context = {
    "system": system_prompt,           # Toujours mis en cache
    "documents": retrieved_chunks,      # Cache par cluster de requêtes
    "examples": few_shot_examples       # Stable entre les requêtes
}

# Seule la requête utilisateur varie
dynamic_content = {
    "query": user_question
}

Mise en cache des chunks de documents : Lorsque plusieurs requêtes récupèrent les mêmes documents, la mise en cache des préfixes élimine le traitement redondant du contexte partagé.

Workflows agentiques

Les systèmes d'agents avec appel d'outils bénéficient de la mise en cache des préfixes :

Prompt système → Définitions d'outils → Historique conversation → Requête actuelle
    (caché)           (caché)              (partiellement caché)       (dynamique)

Les définitions d'outils (JSON schema, descriptions) restent constantes entre les requêtes, ce qui en fait des candidats idéaux pour la mise en cache des préfixes.

Stratégies d'optimisation

Structurer les prompts pour la mise en cache

Ordonnez le contenu du prompt par stabilité :

1. Le plus stable (début) : Prompt système, définitions d'outils, directives
2. Semi-stable (milieu) : Contexte documentaire, exemples
3. Dynamique (fin) : Entrée utilisateur, historique de conversation récent

Cette structure maximise la réutilisation du préfixe entre les requêtes.

Surveiller les métriques de cache

Suivez ces métriques pour évaluer l'efficacité de la mise en cache :

• Taux de hit : Pourcentage de requêtes servies depuis le cache
• Économies de coûts : Réduction des coûts API grâce à la mise en cache
• Amélioration de latence : Temps de réponse moyen avec vs sans cache
• Efficacité d'utilisation du cache : Entrées de cache utilisées vs expirées

Gestion de l'invalidation du cache

Implémentez des stratégies d'invalidation appropriées :

• Basée sur le temps (TTL) : Les entrées de cache expirent après une durée définie
• Basée sur les événements : Invalidez lors des mises à jour de données
• Basée sur la version : Hachez le contenu dans les clés de cache
• Manuelle : API d'invalidation explicite pour les cas critiques

Équilibrer fraîcheur et économies

Ajustez les politiques de cache selon les exigences du contenu :

Résumé

La mise en cache des prompts offre des économies de coûts substantielles (50-90 %) et des réductions de latence (jusqu'à 85 %) pour les applications LLM. Une implémentation efficace nécessite :

1. Comprendre les couches de cache : Préfixe (KV) vs sémantique (réponse)
2. Exploiter les fonctionnalités fournisseur : Anthropic, OpenAI, Google offrent chacun des capacités de mise en cache différentes
3. Structurer les prompts stratégiquement : Contenu statique d'abord, dynamique ensuite
4. Implémenter un caching multi-niveaux : Combiner sémantique et préfixe pour un bénéfice maximal
5. Surveiller et optimiser : Suivre les taux de hit, ajuster les politiques selon les patterns de charge