Mise en cache des prompts LLM #1 : comment fonctionnent le cache KV et le TTL

En bref — La mise en cache des prompts LLM n’est pas une optimisation rapportée ; elle découle de la manière dont l’architecture Transformer calcule réellement l’attention. Une fois que vous comprenez pourquoi les vecteurs Clé/Valeur d’un préfixe stable sont mathématiquement réutilisables, la vraie surprise devient le double bénéfice : une réduction de coût spectaculaire (50–90 %) et une réduction spectaculaire du temps jusqu’au premier token (5–20×). Cet article — la première partie d’une série en quatre volets — couvre la raison architecturale de l’existence de la mise en cache, le compromis mémoire-versus-calcul qui détermine si un cache est rentable, et le comportement du TTL que tout développeur doit comprendre. La Partie 2 creuse les implémentations propres à chaque fournisseur.

Série : Partie 1 sur 4 — Principes de la mise en cache · Suivant : Partie 2 — Comparaison et évaluation des fournisseurs · Partie 3 — Tutoriel avec code fonctionnel · Partie 4 — Le meilleur LLM selon le cas d’usage

Pourquoi la facture de tokens de votre application IA croît plus vite que vos utilisateurs

Si vous déployez un chatbot, une application RAG ou un agent IA, vous avez probablement heurté le même mur : votre facture double alors que votre usage, non. Ouvrez le journal des requêtes et vous y trouverez le même prompt système de plusieurs milliers de tokens, les mêmes descriptions d’outils, les mêmes fragments de base de connaissances — réenvoyés à chaque appel.

C’est là le problème économique central de l’inférence LLM : le modèle est sans état. Chaque requête retraite l’intégralité du contexte depuis zéro. Un prompt système de 8 K tokens appelé 1 000 fois équivaut à 8 millions de tokens de travail répété. Vous payez pour chacun d’eux — et vos utilisateurs attendent pour chacun d’eux.

La mise en cache des prompts corrige cela. Mais contrairement à la plupart des astuces de performance, elle n’est pas ajoutée à l’architecture — elle est une conséquence naturelle de la définition même de l’attention Transformer. Une fois que vous le voyez, le reste de l’article (tarification, TTL, différences entre fournisseurs) s’aligne proprement.

1. Pourquoi les LLM ont-ils même un cache : une visite guidée de l’inférence Transformer

Cette section est celle que presque tous les tutoriels de « mise en cache de prompts » sautent. C’est celle qui explique pourquoi le cache existe en premier lieu — et pourquoi les remises offertes par les fournisseurs ne sont pas des chiffres marketing arbitraires mais reflètent une véritable économie GPU.

1.1 L’auto-attention en une seule équation

Un Transformer décodeur seul (la famille à laquelle appartiennent tous GPT-4, Claude, Gemini, DeepSeek, Qwen) traite les tokens en appliquant à répétition l’auto-attention. Pour une séquence de N tokens, la sortie d’attention pour chaque token i est :

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

où Q, K, V sont des matrices de forme [N × d] dérivées des embeddings d’entrée par trois projections linéaires apprises (une par couche par tête). La définition originale provient de Attention Is All You Need (Vaswani et al., 2017).

Deux propriétés de cette équation comptent énormément pour la mise en cache :

Propriété 1 — Masquage 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 tokens précoces sont utilisés par tous les tokens ultérieurs, mais les tokens ultérieurs ne les modifient jamais.

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

L’implication 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 identiques au bit près.

C’est là toute la base théorique de la mise en cache des prompts. Tout le reste relève de l’ingénierie.

1.2 Les deux phases de l’inférence

L’inférence LLM moderne se déroule en deux phases distinctes qui consomment le temps GPU de manières très différentes. Cette séparation est documentée en détail dans Efficiently Scaling Transformer Inference (Pope et al., 2022).

Phase de préremplissage (prefill). Le modèle ingère le prompt complet d’un seul coup. Pour chaque couche, il calcule Q, K, V pour chaque token d’entrée et exécute l’auto-attention. Le prefill est limité par le calcul : il sature les unités de multiplication matricielle du GPU. Le coût croît en O(N²) par rapport à la longueur du prompt, à cause de la matrice d’attention.

Phase de décodage (decode). Le modèle produit un token de sortie à la fois, de manière autorégressive. À l’étape t, seul le Q du nouveau token est calculé ; il prête attention aux K/V de tous les tokens précédents. Le decode est limité par la bande passante mémoire — la majeure partie du temps est consacrée à lire les K/V depuis la mémoire GPU, et non à multiplier. Le coût croît en O(N) par token (linéaire par rapport à la longueur de contexte actuelle).

Pour une charge de travail typique de chatbot (prompt système de 8 K tokens + requête utilisateur de 100 tokens + réponse de 300 tokens), le prefill domine le temps d’horloge et le coût en dollars dans un rapport d’environ 4:1. C’est précisément ce que la mise en cache économise.

Décomposition par appel (prompt 8K, 300 tokens de sortie, modèle de classe Claude) :

  ████████████████████████████████░░░░░░░░  Prefill : ~80 % du calcul
  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░████████  Decode :  ~20 % du calcul

1.3 Le cache KV : sauvegarder le travail de prefill pour le decode

Le « cache KV » désignait à l’origine une optimisation intra-requête. Pendant le décodage, chaque token nouvellement généré doit prêter attention aux K et V de chaque token précédent. Les recalculer à chaque étape transformerait un decode en O(N) en un decode en O(N²). Aussi chaque moteur d’inférence stocke-t-il les K et V issus du prefill en mémoire GPU et les réutilise-t-il pour toute la phase de decode. C’est universel — chaque LLM commercial le fait. C’est ce qui rend la génération réalisable tout court.

Ce que les fournisseurs exposent sous le nom de « mise en cache des prompts » est la généralisation suivante : conserver le cache KV après la fin de la requête, et le réutiliser pour la prochaine requête qui partage le même préfixe.

1.4 Le compromis mémoire–calcul (pourquoi les TTL existent)

Alors pourquoi chaque fournisseur ne met-il pas simplement tout en cache pour toujours ? Parce que le cache KV est énorme.

Pour un modèle avec L couches Transformer, H têtes d’attention, D dimension de tête, et B octets par valeur (typiquement 2 pour le fp16), la taille du cache KV pour N tokens est :

Taille du cache KV  =  2 × L × H × D × B × N
                       ↑   ↑   ↑   ↑   ↑   ↑
                      K&V couches têtes tête octets tokens

Pour un modèle de classe 70B avec 80 couches, 8 têtes KV (après attention par requêtes groupées), une dimension de tête de 128 et des poids fp16, cela représente environ 320 Ko par token. Un contexte de 32 K tokens = ~10 Go de cache KV, juste pour une seule requête. Un GPU H100 moderne dispose de 80 Go ; vous ne pouvez en loger qu’une poignée simultanément.

C’est la contrainte fondamentale que PagedAttention (Kwon et al., 2023, l’article derrière vLLM) a été conçu pour résoudre au niveau du lot (batch) — et la même contrainte est ce qui borne la mise en cache des prompts au niveau inter-requêtes :

Ainsi, le TTL du cache d’un fournisseur est essentiellement une politique d’éviction mémoire : à un moment donné, le GPU a besoin de cette mémoire pour les charges actives d’autres utilisateurs, et le préfixe mis en cache est évincé. 5 minutes pour les caches résidant en HBM ; jusqu’à 1 heure pour les caches paginés vers la DRAM ; des heures pour les caches sauvegardés sur disque.

L’astuce de DeepSeek. DeepSeek-V2 a introduit la Multi-head Latent Attention (MLA), qui compresse le cache KV d’environ 4× par rapport à l’attention par requêtes groupées standard (DeepSeek-AI, 2024). Cette compression est exactement ce qui leur permet de persister le cache KV sur disque plutôt qu’en HBM — ce qui à son tour permet une unité de cache minimale beaucoup plus petite (64 tokens contre 1 024 pour les caches résidant en HBM) et des TTL effectifs bien plus longs.

C’est aussi pourquoi la mise en cache inter-requêtes exige des préfixes identiques token par token. Le cache est indexé par un hachage des identifiants de tokens, et toute divergence — ne serait-ce qu’un seul caractère qui se retokenise différemment — produit un K et un V différents à partir de ce point. Il n’y a pas de « correspondance approximative » à cette couche (c’est ce que fait la mise en cache sémantique, mais c’est un mécanisme différent au sein de la passerelle).

1.5 Deux couches de mise en cache

┌──────────────────────────────────────────────────────────────┐
│  Couche 1 : cache KV par requête (toujours actif, chez tous)  │
│  → maintient le decode en O(N) au lieu de O(N²)              │
│  → vous n'y prêtez pas attention ; le fournisseur le fait    │
└──────────────────────────────────────────────────────────────┘
                              ↓
┌──────────────────────────────────────────────────────────────┐
│  Couche 2 : cache de prompts inter-requêtes (l'économie      │
│           d'argent et de temps dont parle cette série)        │
│  → réutilise les K/V de prefill entre requêtes aux préfixes correspondants  │
│  → exposé sous forme : explicite / entièrement automatique / hybride │
│  → borné par le TTL (piloté par l'éviction mémoire)         │
└──────────────────────────────────────────────────────────────┘

Le reste de la série — et l’essentiel de ce que vous réglerez en tant que développeur — se situe dans la Couche 2.

2. Les deux gains : coût ET latence

La plupart des articles présentent la mise en cache comme une optimisation de coût. Cela la sous-estime. Le gain en latence est souvent la plus grande raison pour laquelle les équipes de production adoptent la mise en cache, surtout pour le chat orienté utilisateur.

2.1 Les maths du coût

Les pages tarifaires donnent les chiffres phares mais les montrent rarement appliqués à une charge de travail réaliste. Prenez un bot de support client avec un prompt système de 8 000 tokens, 100 K requêtes/jour, des messages utilisateur de 200 tokens. En le tarifant sur claude-sonnet-4-5 avec les tarifs publiés 2026 d’Anthropic (10 % pour l’entrée mise en cache, prime de 125 % à l’écriture du cache) :

Sans mise en 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 : 100 K × 30 × 0,022 $ = ~66 000 $

Avec mise en cache des prompts

• Écriture de cache unique : 8 000 tokens × prime de 125 % (négligeable face au volume mensuel)
• Par appel ensuite : 8 000 tokens × 10 % de base + 200 tokens × base + sortie
• Coût effectif par appel : ~0,003 $
• Coût mensuel : ~9 000 $

~86 % d’économie. Ce chiffre correspond à la remise publiée par Anthropic appliquée à une forme d’entrée réaliste. L’article qui suit (Partie 3 — Tutoriel) montre des chiffres réels mesurés pour le reste des fournisseurs.

2.2 Le gain en latence (souvent l’histoire la plus importante)

Le prefill n’est pas seulement coûteux — c’est le plus grand contributeur isolé au temps jusqu’au premier token pour tout prompt dépassant quelques centaines de tokens. Les correspondances de cache vous permettent d’en sauter la quasi-totalité.

TTFT en streaming mesuré sur la passerelle publique Synthorai, le 2026-05-25, prompt système stable d’environ 7 300 tokens :

Exécution unique, mono-locataire. Le gain en TTFT est le plus visible sur les prompts longs (>5 K tokens) ; pour les prompts courts, la portion de prefill est trop petite pour dominer la latence. Le plus grand gain mesuré de Claude est le coût (~88–89 % de réduction sur l’entrée en lecture de cache) — pour des tailles de prompt de l’ordre de 100 K+, le gain en TTFT se cumule substantiellement selon les chiffres publiés par Anthropic.

Pour les interfaces de chat, le seuil au-delà duquel les utilisateurs perçoivent consciemment un délai se situe autour de 1 s pour le TTFT et de ~2 s pour le premier texte utile. Un prompt RAG de 10 K tokens sans mise en cache est nettement au-dessus de cette ligne. Avec la mise en cache, la même charge de travail semble instantanée.

Pour les boucles d’agent à 15 étapes ou plus, l’histoire du coût est bonne (50 % d’économie), mais l’histoire de la latence est ce qui rend le produit réellement livrable : 15 étapes × 5 s de prefill = 75 s de temps mort par tâche → avec la mise en cache, 15 × 0,5 s = 7,5 s.

2.3 Pourquoi cela compte pour la stratégie produit

Une erreur courante consiste à traiter la mise en cache comme « les ops qui font de l’optimisation de coût » — quelque chose que vous greffez après le lancement. Mais le gain en latence signifie que la mise en cache fait aussi partie de la surface UX :

• Un chatbot avec un TTFT inférieur à 1 s semble vivant ; le même bot à 3 s semble cassé.
• Un produit RAG où la récupération+prefill prend 4 s perd face au même produit où cela prend 1 s.
• Un agent qui accomplit une tâche en 20 s l’emporte sur un autre qui prend 90 s.

Vous devriez décider de votre stratégie de cache en même temps que vous décidez de votre modèle et de la structure de votre prompt — pas trois sprints après le lancement.

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

La question du TTL est l’une des parties les plus questionnées et les moins expliquées de la mise en cache des prompts. Deux choses à comprendre :

3.1 La fraîcheur a deux sens — ne les confondez pas

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

Autrement dit : les réponses mises en cache ne sont pas « périmées » au sens de la qualité du modèle. Elles sont mathématiquement identiques aux réponses non mises en cache. Mais si vous placez « l’heure actuelle est 14:32:05 » dans votre prompt système et que vous comptez sur les correspondances de cache, votre « heure actuelle » reste à 14:32:05 jusqu’à l’expiration du TTL et votre modèle mentira avec assurance à vos utilisateurs à ce sujet.

3.2 Comportement du TTL selon les fournisseurs

La valeur par défaut de 5 minutes n’est pas arbitraire — elle correspond approximativement à l’horizon de pression mémoire GPU des modèles populaires en charge de pointe. Comme nous l’avons calculé au §1.4, le cache KV d’un grand contexte peut atteindre des dizaines de Go ; les fournisseurs ne peuvent pas se permettre de les conserver indéfiniment.

3.3 Concevoir en fonction du TTL

Trois schémas qui fonctionnent en production :

Schéma A — Garder les sessions au chaud. Pour le chat, la cadence naturelle des requêtes (quelques secondes à quelques minutes entre les tours) maintient le cache vivant par elle-même. Ne vous souciez pas du TTL ; ne mettez simplement pas de données dynamiques dans le préfixe.

Schéma B — Battement de cœur pour le batch. Pour les tâches par lots s’étalant sur des heures, envoyez une requête minimale tous les TTL/2 pour garder le cache au chaud. Le coût est essentiellement nul (quelques tokens d’entrée) et cela prévient les tempêtes d’éviction de cache.

Schéma C — Utiliser des fournisseurs à long TTL pour le stockage à froid. Si vous avez un document de 50 K tokens interrogé de façon sporadique (par ex. une fois par heure pendant une semaine), les caches explicites Gemini (TTL de 24 heures) ou les caches disque DeepSeek surpasseront les alternatives à court TTL malgré les frais de stockage.

4. Principes universels que tout développeur devrait connaître

Les fournisseurs exposent la mise en cache sous cinq formes très différentes — marqueurs explicites, entièrement automatique, hybride, sauvegarde sur disque architecturale, ou aucune. Nous consacrons le prochain article à cette comparaison (Partie 2 — Comparaison et évaluation des fournisseurs). Mais quatre principes s’appliquent quel que soit le fournisseur et découlent directement de l’architecture que nous venons de parcourir :

4.1 La mise en cache est basée sur le préfixe — l’ordre compte

Comme les K/V à la position i dépendent des tokens aux positions 1…i, les fournisseurs ne peuvent faire correspondre qu’un préfixe contigu à partir du token 0. Changez un seul caractère à la position 0 et tout le préfixe est invalidé. Le contenu stable d’abord, le contenu volatil en dernier. Ce n’est pas une heuristique — c’est une conséquence directe de la structure causale de l’auto-attention (§1.1).

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

Une correspondance de cache ne renvoie pas une réponse précédemment générée — elle renvoie des vecteurs K et V précédemment calculés, que le modèle utilise ensuite pour générer une réponse fraîche à la question actuelle. Cela signifie :

• La qualité de sortie est identique à un appel non mis en cache (§1.1).
• La sortie est non déterministe de la manière habituelle — la température, le top-p, etc. s’appliquent toujours.
• Les réponses mises en cache ne sont jamais « périmées » au sens de la qualité du modèle — seul le contenu de votre prompt (horodatages, prix) peut être périmé. Revoir le §3.1.

4.3 Les écritures de cache sont des investissements, pas du gratuit

Pour les fournisseurs qui facturent une prime d’écriture (Anthropic 125 %, Gemini explicite 125 %), le premier appel avec un nouveau préfixe coûte plus que pas de mise en cache du tout. Le seuil de rentabilité est vite atteint (généralement un seul hit), mais si votre préfixe « stable » change à chaque requête, vous paierez des coûts d’écriture encore et encore sans contrepartie. Surveillez ceci si vous triez les documents récupérés par pertinence — c’est l’anti-schéma classique.

4.4 Les API de mise en cache ne sont pas portables entre fournisseurs

cache_control (Anthropic) ≠ cached_content (Gemini) ≠ cache_id (Qwen). Si votre application doit fonctionner avec plusieurs fournisseurs, soit vous maintenez trois intégrations, soit vous placez une Token Gateway devant pour les unifier. La Partie 2 couvre cela en détail.

5. La mise en cache des prompts, est-ce de l’argent gratuit ?

Presque. Elle est rentable quand :

• Vos prompts ont un préfixe stable — prompt système, base de connaissances, schémas d’outils
• Vos appels sont fréquents ou connectés — même session, charges par lots, exécutions d’agent en cours
• Vous pouvez structurer les prompts pour que le contenu stable soit placé au début

Cochez ces trois cases et vous constaterez généralement 50–90 % de dépenses en moins et un TTFT 3–20× plus rapide sans changer de modèle.

À suivre : la Partie 2 — Comparaison de la mise en cache des fournisseurs et cadre d’évaluation reprend le tableau architectural ci-dessus et le transforme en une comparaison fonctionnalité par fonctionnalité de Claude, OpenAI, Gemini, DeepSeek et Qwen, avec une grille d’évaluation pour choisir le bon fournisseur selon votre charge de travail.

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

Synthorai expose un endpoint compatible OpenAI — pointez le SDK officiel openai vers lui et chaque modèle (Claude, GPT, Gemini, DeepSeek, Qwen) devient un changement de modèle en une seule ligne. La passerelle traduit cache_control dans la syntaxe de mise en 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 pour gpt-5.4-mini, gemini-2.5-pro, deepseek-v4-flash, qwen3-max — seul le champ model change. La passerelle renvoie les métadonnées de correspondance du cache de prompt dans le champ standard OpenAI prompt_tokens_details.cached_tokens, plus un champ cost en USD, de sorte que vous n’avez pas besoin de maintenir localement une matrice tarifaire par fournisseur.

FAQ

La mise en cache des prompts LLM est-elle la même chose que la mise en cache sémantique ? Non. La mise en cache des prompts est basée sur le préfixe — elle réutilise les valeurs K/V pour une correspondance exacte au niveau token au début du prompt. La mise en cache sémantique fait correspondre au niveau du sens (via des embeddings) et renvoie une réponse précédente. Les deux sont utiles, et une bonne Token Gateway les combine en couches.

La mise en cache des prompts change-t-elle la sortie du modèle ? Non. K et V sont des fonctions déterministes des tokens d’entrée (§1.1). Les logits que le modèle produit à partir d’un K/V mis en cache sont mathématiquement identiques à ceux issus d’un K/V fraîchement recalculé. La mise en cache est une optimisation d’efficacité pure, sans impact sur la qualité.

Pourquoi le TTL du cache est-il si court — ne peuvent-ils pas simplement le garder pour toujours ? Le cache KV est énorme (§1.4 : ~10 Go par contexte de 32 K pour un modèle de 70B). La mémoire GPU est le goulot d’étranglement ; les caches sont évincés dès que le serveur a besoin de cette mémoire pour des charges actives. Les caches sauvegardés sur disque (DeepSeek) peuvent vivre des heures, mais les caches en mémoire le peuvent rarement.

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 » est la réutilisation inter-requêtes de ce cache KV. Couche 1 versus Couche 2 au §1.5 ci-dessus.

Les prompts mis en cache deviennent-ils parfois périmés d’une manière qui dégrade la qualité ? Non, du point de vue du modèle. Oui, du point de vue de votre contenu si votre prompt encode 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 correspondance du cache ? Chaque fournisseur le renvoie dans l’objet usage de la réponse — cache_read_input_tokens (Anthropic), cached_tokens (OpenAI), cached_content_token_count (Gemini), prompt_cache_hit_tokens (DeepSeek). Suivez ces valeurs dans votre pipeline de journalisation.

Références & 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) — MLA architecture · Anthropic Prompt Caching docs · OpenAI Prompt Caching docs · Google Gemini Context Caching docs · DeepSeek KV Cache guide · Alibaba Bailian Context Cache

← Retour au blog