Fonctionnement du cache de prompt des LLM : cache KV et TTL

TL;DR — Le cache de prompt des LLM n’est pas une optimisation ajoutée après coup. Il découle directement du calcul de l’attention dans l’architecture Transformer. Une fois compris pourquoi les vecteurs Key/Value d’un préfixe stable sont mathématiquement réutilisables, le vrai intérêt apparaît : deux gains simultanés, avec une forte baisse des coûts (50–90%) et du délai avant le premier token (5–20×). Cet article, premier volet d’une série en cinq parties, explique l’origine architecturale du cache, le compromis entre mémoire et calcul qui détermine sa rentabilité, ainsi que le comportement du TTL que tout développeur doit connaître. La partie 2 détaille les implémentations propres à chaque fournisseur.

Série : partie 1 sur 5 — Principes du cache · Suite : partie 2 — Comparaison et évaluation des fournisseurs · Partie 3 — Tutoriel avec du code fonctionnel · Partie 4 — Meilleur LLM selon le cas d’usage · Partie 5 — Intégration avec LangChain · Version condensée : le guide complet du cache de prompt

Pourquoi la facture en tokens de votre application IA augmente plus vite que son nombre d’utilisateurs

Si vous développez un chatbot, une application RAG ou un agent IA, vous avez probablement rencontré le même problème : la facture double alors que l’usage reste stable. Dans les logs de requêtes, on retrouve à chaque appel le même system prompt de plusieurs milliers de tokens, les mêmes descriptions d’outils et les mêmes extraits de la base de connaissances.

C’est le principal problème économique de l’inférence des LLM : le modèle ne conserve aucun état. Chaque requête retraite tout le contexte depuis le début. Un system prompt de 8K tokens appelé 1,000 fois représente 8 millions de tokens de calcul répété. Vous payez chacun de ces tokens, et vos utilisateurs attendent leur traitement.

Le cache de prompt résout ce problème. Contrairement à la plupart des optimisations de performances, il n’a pas été ajouté à l’architecture : il découle naturellement de la définition de l’attention dans les Transformers. Une fois ce principe compris, les tarifs, les TTL et les différences entre fournisseurs deviennent beaucoup plus simples à expliquer.

1. Pourquoi les LLM disposent d’un cache : déroulement de l’inférence d’un Transformer

La plupart des tutoriels sur le cache de prompt passent cette partie sous silence. Pourtant, c’est elle qui explique pourquoi ce cache existe et pourquoi les remises proposées par les fournisseurs ne sont pas de simples arguments commerciaux : elles reflètent les coûts réels du GPU.

1.1 La self-attention en une équation

Un Transformer de type decoder-only, famille à laquelle appartiennent GPT-4, Claude, Gemini, DeepSeek et Qwen, traite les tokens en appliquant la self-attention de façon répétée. Pour une séquence de N tokens, la sortie de l’attention pour chaque token i est :

Attention(Q, K, V) = softmax( Q · Kᵀ / √d ) · V

Q, K et V sont des matrices de forme [N × d], obtenues à partir des embeddings d’entrée par trois projections linéaires apprises, une par couche et par tête. Cette définition vient de l’article original Attention Is All You Need (Vaswani et al., 2017).

Deux propriétés de cette équation sont déterminantes pour le cache :

Propriété 1 — Masque causal. Pendant la génération, le token i ne peut prêter attention qu’aux tokens situés aux positions ≤ i. La matrice d’attention est triangulaire inférieure : les vecteurs K et V des premiers tokens sont utilisés par tous les suivants, mais les tokens suivants ne les modifient jamais.

Propriété 2 — K et V dépendent uniquement du préfixe. Comme ils sont calculés à partir des embeddings d’entrée des positions 1…i au moyen de matrices de poids fixes, les vecteurs K et V à la position i sont une fonction déterministe des tokens situés aux positions 1…i, et d’eux seuls. Rien à la position i+1 ne peut modifier K_i ou V_i.

La conséquence est immédiate : si deux requêtes partagent un préfixe identique de longueur P, les P premières lignes de K et V sont strictement identiques bit à bit.

Voilà toute la base théorique du cache de prompt. Le reste relève de l’ingénierie.

1.2 Les deux phases de l’inférence

L’inférence des LLM modernes se déroule en deux phases distinctes, dont l’utilisation du GPU diffère fortement. Cette séparation est décrite en détail dans Efficiently Scaling Transformer Inference (Pope et al., 2022).

Phase de prefill. Le modèle ingère tout le prompt en une fois. Pour chaque couche, il calcule Q, K et V pour chaque token d’entrée, puis exécute la self-attention. Le prefill est limité par la puissance de calcul : il sature les unités de multiplication matricielle du GPU. Son coût augmente en O(N²) avec la longueur du prompt, à cause de la matrice d’attention.

Phase de decode. Le modèle génère les tokens de sortie un par un, de façon autorégressive. À l’étape t, seul le Q du nouveau token est calculé ; il est comparé aux K/V de tous les tokens précédents. Le decode est limité par la bande passante mémoire : l’essentiel du temps sert à lire K/V depuis la mémoire du GPU, pas à effectuer des multiplications. Son coût augmente en O(N) par token, donc linéairement avec la longueur actuelle du contexte.

Pour une charge classique de chatbot, avec un system prompt de 8K tokens, une requête utilisateur de 100 tokens et une réponse de 300 tokens, le prefill représente environ quatre fois plus de temps réel et de coût que le decode. C’est ce travail que le cache évite.

Per call breakdown (8K prompt, 300 output tokens, Claude-class model):

  ████████████████████████████████░░░░░░░░  Prefill: ~80% of compute
  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░████████  Decode:  ~20% of compute

1.3 Le cache KV : conserver le travail du prefill pour le decode

À l’origine, le « cache KV » désignait une optimisation interne à une requête. Pendant le decode, chaque nouveau token doit prêter attention aux K et V de tous les tokens précédents. Les recalculer à chaque étape ferait passer le decode de O(N) à O(N²). Tous les moteurs d’inférence stockent donc en mémoire GPU les K et V produits pendant le prefill et les réutilisent pendant toute la phase de decode. Cette technique est universelle : tous les LLM commerciaux l’utilisent. Sans elle, la génération serait impraticable.

Ce que les fournisseurs présentent comme le « cache de prompt » est l’étape suivante : conserver le cache KV après la fin de la requête, puis le réutiliser pour la requête suivante si elle partage le même préfixe.

1.4 Le compromis mémoire-calcul, ou pourquoi les TTL existent

Pourquoi les fournisseurs ne mettent-ils pas tout en cache indéfiniment ? Parce que le cache KV est énorme.

Pour un modèle comportant L couches Transformer, H têtes d’attention, une dimension de tête D et B octets par valeur, généralement 2 en fp16, la taille du cache KV pour N tokens est :

KV cache size  =  2 × L × H × D × B × N
                  ↑   ↑   ↑   ↑   ↑   ↑
                  K&V layers heads head bytes tokens

Pour un modèle de la classe 70B avec 80 couches, 8 têtes KV après grouped-query-attention, une dimension de tête de 128 et des poids fp16, cela représente environ 320 KB par token. Un contexte de 32K tokens nécessite ~10 GB de cache KV, pour une seule requête. Un GPU H100 moderne dispose de 80 GB ; il ne peut en conserver que quelques-uns simultanément.

C’est cette contrainte que PagedAttention (Kwon et al., 2023, l’article à l’origine de vLLM) cherche à résoudre au niveau du batch. La même contrainte limite le cache de prompt entre plusieurs requêtes :

Le TTL du cache d’un fournisseur est donc essentiellement une politique d’éviction mémoire. À un moment donné, le GPU doit récupérer cette mémoire pour traiter les charges actives d’autres utilisateurs, et le préfixe en cache est évincé. 5 minutes pour les caches résidant en HBM ; jusqu’à 1 heure pour les caches transférés en DRAM par pagination ; plusieurs heures pour ceux stockés sur disque.

L’approche de DeepSeek. DeepSeek-V2 a introduit Multi-head Latent Attention (MLA), qui réduit le cache KV d’environ 4× par rapport à la grouped-query attention standard (DeepSeek-AI, 2024). Cette compression permet précisément de conserver le cache KV sur disque plutôt qu’en HBM. DeepSeek peut ainsi proposer une unité minimale de cache beaucoup plus petite, 64 tokens contre 1,024 pour les caches résidant en HBM, ainsi que des TTL effectifs nettement plus longs.

C’est aussi pour cette raison que le cache entre requêtes exige des préfixes identiques token par token. Le cache est indexé par un hash des identifiants de tokens. La moindre différence, même un seul caractère entraînant une tokenisation différente, produit des K et V distincts à partir de ce point. Il n’existe aucune correspondance approximative à ce niveau. C’est le rôle du cache sémantique, qui repose sur un autre mécanisme au niveau de la gateway.

1.5 Deux niveaux de cache

┌──────────────────────────────────────────────────────────────┐
│  Layer 1: Per-request KV cache (always on, every provider)    │
│  → keeps decode O(N) instead of O(N²)                        │
│  → you don't pay attention to it; the provider just does it  │
└──────────────────────────────────────────────────────────────┘
                              ↓
┌──────────────────────────────────────────────────────────────┐
│  Layer 2: Cross-request Prompt Cache (the money-and-time      │
│           saver this series is about)                         │
│  → reuses prefill K/V across requests with matching prefixes  │
│  → exposed as: explicit / fully automatic / hybrid           │
│  → bounded by TTL (memory-eviction-driven)                   │
└──────────────────────────────────────────────────────────────┘

La suite de cette série, et l’essentiel des réglages à effectuer côté développement, concerne le niveau 2.

2. Deux gains : le coût ET la latence

La plupart des articles présentent le cache comme une optimisation des coûts. C’est réducteur. En production, les équipes l’adoptent souvent d’abord pour réduire la latence, en particulier dans les interfaces de chat.

2.1 Calcul du coût

Les pages tarifaires affichent les chiffres principaux, mais les appliquent rarement à une charge réaliste. Prenons un bot de support client avec un system prompt de 8,000 tokens, 100K requêtes par jour et des messages utilisateur de 200 tokens. Sur claude-sonnet-4-5, avec les tarifs Anthropic publiés pour 2026, l’entrée en cache coûte 10% du tarif normal et l’écriture en cache entraîne une majoration de 125% :

Sans cache

• Entrée par appel : 8,200 tokens × tarif d’entrée de base
• Coût par appel, mesuré sur un appel unique : ~$0.022
• Coût mensuel : 100K × 30 × $0.022 = ~$66,000

Avec cache de prompt

• Écriture initiale du cache : 8,000 tokens × majoration de 125%, négligeable à l’échelle du volume mensuel
• Appels suivants : 8,000 tokens × 10% du tarif de base + 200 tokens × tarif de base + sortie
• Coût effectif par appel : ~$0.003
• Coût mensuel : ~$9,000

~86% d’économies. Ce chiffre correspond à la remise publiée par Anthropic, appliquée à une charge d’entrée réaliste. L’article suivant, partie 3 — Tutoriel, présente des mesures réelles pour les autres fournisseurs.

2.2 Le gain de latence, souvent le principal avantage

Le prefill n’est pas seulement coûteux : pour tout prompt de plus de quelques centaines de tokens, c’est le principal facteur du délai avant le premier token. En cas de cache hit, il peut être presque entièrement évité.

TTFT mesuré en streaming sur la gateway publique Synthorai, le 2026-05-25, avec un system prompt stable d’environ 7,300 tokens :

Mesures effectuées sur une seule exécution et un tenant unique. Le gain de TTFT est surtout visible avec les prompts longs, au-delà de 5K tokens. Pour les prompts courts, le prefill ne représente pas une part suffisante de la latence. Pour Claude, le principal gain mesuré porte sur le coût, avec une réduction d’environ 88–89% du prix de l’entrée lors d’une lecture du cache. D’après les chiffres publiés par Anthropic, le gain de TTFT augmente fortement pour les prompts de 100K tokens et plus.

Dans une interface de chat, les utilisateurs commencent à percevoir consciemment un délai au-delà d’environ 1 s de TTFT et de ~2 s avant le premier texte utile. Sans cache, un prompt RAG de 10K tokens dépasse largement ce seuil. Avec le cache, la même charge semble instantanée.

Pour les boucles d’agents de 15 étapes ou plus, l’économie de coût est intéressante, avec 50% de réduction, mais c’est surtout le gain de latence qui rend le produit exploitable : 15 étapes × 5s de prefill = 75 s d’attente sans activité par tâche → avec le cache, 15 × 0.5s = 7.5 s.

2.3 Conséquences sur la stratégie produit

Une erreur fréquente consiste à considérer le cache comme une simple optimisation de coûts réservée aux ops, à ajouter après le lancement. Comme il réduit aussi la latence, il fait partie de l’expérience utilisateur :

• Un chatbot dont le TTFT reste inférieur à 1 s paraît réactif ; à 3 s, il semble défaillant.
• Un produit RAG dont la récupération et le prefill prennent 4 s perd face au même produit qui répond en 1 s.
• Un agent qui termine une tâche en 20 s l’emporte sur un autre qui en demande 90 s.

La stratégie de cache doit être définie en même temps que le choix du modèle et la structure des prompts, pas trois sprints après le lancement.

3. Fraîcheur du cache, TTL et modèle opérationnel

Le TTL fait partie des sujets les plus souvent abordés et les moins bien expliqués à propos du cache de prompt. Il faut distinguer deux points :

3.1 La fraîcheur a deux sens à ne pas confondre

Fraîcheur du cache ≠ fraîcheur de la réponse. Deux concepts distincts sont souvent mélangés :

Les réponses utilisant le cache ne sont donc pas « périmées » du point de vue de la qualité du modèle. Elles sont mathématiquement identiques à celles produites sans cache. En revanche, si votre system prompt contient « l’heure actuelle est 14:32:05 » et que les appels suivants utilisent le cache, cette heure restera 14:32:05 jusqu’à l’expiration du TTL. Le modèle donnera alors aux utilisateurs une heure erronée avec assurance.

3.2 Comportement du TTL selon les fournisseurs

La valeur par défaut de 5 minutes n’est pas arbitraire. Elle correspond approximativement à la durée pendant laquelle la pression sur la mémoire GPU reste acceptable pour les modèles populaires en période de forte charge. Comme indiqué au §1.4, le cache KV d’un seul contexte long peut occuper plusieurs dizaines de GB ; les fournisseurs ne peuvent pas le conserver indéfiniment.

3.3 Concevoir en fonction du TTL

Trois approches fonctionnent bien en production :

Approche A — Maintenir les sessions actives. Dans un chat, la cadence naturelle des requêtes, avec quelques secondes ou minutes entre deux tours, suffit à maintenir le cache. Le TTL ne pose généralement pas de problème ; il faut surtout éviter de placer des données dynamiques dans le préfixe.

Approche B — Envoyer un heartbeat pour les traitements batch. Pour les traitements batch qui durent plusieurs heures, envoyez une requête minimale tous les TTL/2 afin de maintenir le cache. Son coût est quasiment nul, quelques tokens d’entrée, et cela évite les évictions massives du cache.

Approche C — Utiliser les fournisseurs à TTL long pour le stockage à froid. Si un document de 50K tokens n’est interrogé qu’occasionnellement, par exemple une fois par heure pendant une semaine, les caches explicites de Gemini avec un TTL de 24 heures ou les caches sur disque de DeepSeek seront plus performants que les solutions à TTL court, malgré les frais de stockage.

4. Principes universels à connaître

Les fournisseurs proposent cinq formes de cache très différentes : marqueurs explicites, fonctionnement entièrement automatique, modèle hybride, stockage architectural sur disque ou absence totale de cache. L’article suivant compare ces approches en détail : partie 2 — Comparaison et évaluation des fournisseurs. Quatre principes s’appliquent toutefois à tous les fournisseurs et découlent directement de l’architecture décrite plus haut :

4.1 Le cache fonctionne par préfixe : l’ordre compte

Comme K/V à la position i dépend des tokens situés aux positions 1…i, les fournisseurs ne peuvent faire correspondre qu’un préfixe contigu commençant au token 0. Modifier un seul caractère à la position 0 invalide tout le préfixe. Le contenu stable doit être placé en premier et le contenu variable en dernier. Ce n’est pas une heuristique, mais une conséquence directe de la structure causale de la self-attention (§1.1).

4.2 Le cache stocke K/V, pas les réponses

Un cache hit ne renvoie pas une réponse générée précédemment. Il récupère les vecteurs K et V déjà calculés, puis le modèle les utilise pour produire une nouvelle réponse à la question actuelle. Par conséquent :

• La qualité de sortie est identique à celle d’un appel sans cache (§1.1).
• La sortie reste non déterministe de la même manière : temperature, top-p et les autres paramètres continuent de s’appliquer.
• Les réponses mises en cache ne sont jamais « périmées » du point de vue de la qualité du modèle. Seul le contenu du prompt, comme les horodatages ou les prix, peut devenir obsolète. Voir de nouveau le §3.1.

4.3 Les écritures dans le cache sont un investissement, pas une opération gratuite

Chez les fournisseurs qui appliquent une majoration à l’écriture, Anthropic à 125% et Gemini explicit à 125%, le premier appel avec un nouveau préfixe coûte plus cher qu’un appel sans cache. Le seuil de rentabilité est rapidement atteint, généralement dès le premier hit. Mais si votre préfixe « stable » change à chaque requête, vous paierez sans cesse les coûts d’écriture sans jamais les amortir. Ce problème apparaît souvent lorsque les documents récupérés sont triés par pertinence : c’est l’anti-pattern classique.

4.4 Les API de cache ne sont pas portables entre fournisseurs

cache_control (Anthropic) ≠ cached_content (Gemini) ≠ cache_id (Qwen). Si votre application doit fonctionner avec plusieurs fournisseurs, vous devez soit maintenir trois intégrations, soit placer une Token Gateway devant eux pour uniformiser les interfaces. La partie 2 aborde ce point en détail.

5. Le cache de prompt est-il toujours rentable ?

Presque. Il est rentable lorsque :

• Vos prompts contiennent un préfixe stable : system prompt, base de connaissances ou schémas d’outils
• Vos appels sont fréquents ou liés : même session, traitements batch ou exécutions d’agents en cours
• Vous pouvez structurer les prompts pour placer le contenu stable au début

Lorsque ces trois conditions sont réunies, les dépenses baissent généralement de 50–90% et le TTFT est 3–20× plus rapide, sans changer de modèle.

À suivre : partie 2 — Comparaison des caches fournisseurs et cadre d’évaluation transforme les principes architecturaux présentés ici en une comparaison détaillée de Claude, OpenAI, Gemini, DeepSeek et Qwen, avec une grille d’évaluation permettant de choisir le fournisseur adapté à votre charge.

Démarrage rapide : utiliser le SDK OpenAI avec tous les fournisseurs

Synthorai expose un endpoint compatible avec OpenAI. Il suffit d’y connecter le SDK officiel openai pour passer d’un modèle à l’autre, Claude, GPT, Gemini, DeepSeek ou Qwen, en modifiant une seule ligne. La gateway traduit cache_control vers la syntaxe de cache native de chaque fournisseur.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["SYNTHORAI_KEY"],
    base_url="https://synthorai.io/v1",
)

resp = client.chat.completions.create(
    model="claude-sonnet-4-5",                       # swap freely
    max_tokens=256,
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user",   "content": "Hello"},
    ],
)

print(resp.choices[0].message.content)
print(resp.usage.prompt_tokens_details)  # cached_tokens when upstream reports it
print(resp.usage.cost)                   # USD per call (gateway-computed)

Le même appel fonctionne avec gpt-5.4-mini, gemini-2.5-pro, deepseek-v4-flash et qwen3-max : seul le champ model change. La gateway renvoie les métadonnées de cache hit dans le champ OpenAI standard prompt_tokens_details.cached_tokens, ainsi qu’un champ cost en USD. Vous n’avez donc pas besoin de maintenir localement une matrice tarifaire pour chaque fournisseur.

FAQ

Le cache de prompt des LLM est-il identique au cache sémantique ? Non. Le cache de prompt fonctionne par préfixe : il réutilise les valeurs K/V lorsqu’il trouve une correspondance exacte au niveau des tokens au début du prompt. Le cache sémantique établit une correspondance au niveau du sens, au moyen d’embeddings, puis renvoie une réponse précédente. Les deux sont utiles, et une bonne Token Gateway les combine en plusieurs niveaux.

Le cache de prompt modifie-t-il la sortie du modèle ? Non. K et V sont des fonctions déterministes des tokens d’entrée (§1.1). Les logits produits à partir de K/V en cache sont mathématiquement identiques à ceux obtenus en recalculant K/V. Le cache est une pure optimisation d’efficacité, sans effet sur la qualité.

Pourquoi le TTL du cache est-il si court ? Ne pourrait-on pas le conserver indéfiniment ? Le cache KV est énorme (§1.4 : ~10 GB pour un contexte de 32K sur un modèle 70B). La mémoire GPU constitue le goulot d’étranglement ; les caches sont évincés dès que le serveur a besoin de cette mémoire pour les charges actives. Les caches sur disque, comme ceux de DeepSeek, peuvent subsister plusieurs heures, contrairement aux caches en mémoire.

Quelle est la différence entre cache KV et cache de prompt ? Le cache KV est la structure de données en mémoire utilisée pendant l’inférence. Le « cache de prompt » correspond à la réutilisation de ce cache KV entre plusieurs requêtes. Ce sont les niveaux 1 et 2 décrits au §1.5.

Les prompts en cache peuvent-ils devenir obsolètes au point de dégrader la qualité ? Non du point de vue du modèle. Oui du point de vue du contenu si le prompt contient des informations sensibles au temps. Le cache stocke des vecteurs K/V, pas des faits sur le monde. Voir le §3.1.

Comment mesurer le taux de cache hit ? Tous les fournisseurs le renvoient dans l’objet d’usage de la réponse : cache_read_input_tokens (Anthropic), cached_tokens (OpenAI), cached_content_token_count (Gemini), prompt_cache_hit_tokens (DeepSeek). Enregistrez ces valeurs dans votre pipeline de logs.

Références et sources : Vaswani et al., « Attention Is All You Need » (NeurIPS 2017) · Pope et al., « Efficiently Scaling Transformer Inference » (2022) · Kwon et al., « Efficient Memory Management for LLM Serving with PagedAttention » (SOSP 2023, vLLM) · DeepSeek-AI, « DeepSeek-V2: A Strong, Economical, and Efficient MoE Language Model » (2024) — architecture MLA · Documentation Anthropic sur le cache de prompt · Documentation OpenAI sur le cache de prompt · Documentation Google Gemini sur le cache de contexte · Guide DeepSeek du cache KV · Cache de contexte Alibaba Bailian

← Retour au blog