Prompt caching : ce que le cache KV change pour les LLM

Le prompt caching réduit le coût des entrées en permettant au modèle de réutiliser un travail déjà effectué. Un cache KV conserve 2 ensembles de données d’attention, les clés et les valeurs : un grand modèle de langage peut ainsi poursuivre une conversation sans recalculer l’état de chaque token précédent. Le contexte répété coûte donc moins cher à traiter. Mais une longue conversation continue d’occuper de la mémoire et laisse à chaque nouveau token davantage de contexte à prendre en compte.

Conservez les préfixes utiles, puis maîtrisez la quantité d’historique retenue. Ce sont deux tâches distinctes. Un préfixe est le début inchangé d’une requête. Le mettre en cache peut alléger le traitement des entrées, sans pour autant supprimer le reste du travail de l’agent.

Les tarifs et les règles de cache présentés ici ont été vérifiés dans les pages tarifaires et la documentation en ligne des fournisseurs le 15 octobre 2026. Les calculs de mémoire reposent sur les dimensions documentées des tenseurs, et non sur des mesures réalisées avec un GPU particulier.

Qu’est-ce que le cache KV ? Ce que le modèle réutilise d’un prompt

Le cache KV conserve l’état de l’attention. L’attention est le mécanisme qui permet à un transformer d’intégrer les informations antérieures pertinentes à sa prédiction en cours. Un token, unité de texte ou autre élément d’entrée du modèle, produit des représentations numériques dans chaque couche d’attention. Le cache garde les clés et les valeurs de cette couche pour les réutiliser ensuite. L’explication du cache par Hugging Face décrit ce stockage couche par couche.

Pour comprendre les trois rôles de l’attention, imaginez une bibliothèque de recherche :

• Une requête, ou query, exprime ce que recherche la position courante.
• Une clé, ou key, permet de déterminer si une position antérieure correspond à cette recherche.
• Une valeur, ou value, fournit l’information qu’une correspondance peut apporter.

Imaginez que vous prépariez un ensemble de notes indexées avant de rédiger un rapport. Chaque nouvelle phrase peut s’appuyer sur ces notes. Reconstituer l’index et les notes à chaque phrase répéterait inutilement le travail ; les conserver prend de la place. L’analogie s’arrête à la mise en œuvre : le modèle stocke des tableaux de nombres, pas des fiches lisibles ni un résumé de vos documents.

La requête courante est comparée aux clés antérieures. Les poids d’attention qui en résultent servent à combiner les valeurs correspondantes. Dans un transformer causal, les positions antérieures ne peuvent pas consulter le futur. L’ajout d’un token ne nécessite donc pas de modifier les états déjà calculés pour les positions précédentes. C’est ce qui rend leur réutilisation possible. L’article de recherche original sur PagedAttention décrit ces calculs d’attention et le processus de génération.

Cela explique aussi pourquoi le cache habituel conserve K et V, plutôt que toutes les anciennes requêtes. La prédiction suivante a besoin de la requête courante et des clés et valeurs accumulées ; les anciennes requêtes ont déjà rempli leur rôle.

Pour un agent d’assistance, les états conservés peuvent représenter ses instructions, les définitions de ses outils, les documents de procédure et la conversation jusque-là. Ils dépendent du modèle et du contexte qui les précède. Ce ne sont ni les poids appris par le modèle ni une base de données permanente sur les clients.

Un préfixe en cache n’est pas non plus une réponse en cache. Le modèle génère toujours une nouvelle suite. Poser une autre question sur le même document peut réutiliser l’état préparé pour ce document sans renvoyer la réponse précédente.

Prompt caching : quelle différence entre prefill et decode ?

Le prefill prépare l’entrée ; le decode génère la suite. Ces deux phases expliquent pourquoi une requête peut commencer à répondre plus vite lorsqu’elle trouve un préfixe en cache, tout en mettant encore du temps à se terminer.

Pour un transformer autorégressif classique, le déroulement se résume ainsi :

Prefill : tokens du prompt → traitement du prompt → conservation des clés et des valeurs de chaque couche → prédiction du premier token de sortie.

Decode : dernier token généré + clés et valeurs conservées → traitement de ce token et prise en compte du contexte par l’attention → prédiction du token suivant ; ajout des clés et des valeurs nouvellement calculées.

Répétition du decode : réutilisation du cache, qui s’enrichit jusqu’à la fin de la génération.

Le prefill peut traiter ensemble les positions connues du prompt. Le decode avance dans une suite dont les tokens à venir n’ont pas encore été choisis. Cette distinction est décrite dans le déroulement de la génération et de l’exécution présenté par l’article sur PagedAttention.

Le cache KV réduit le coût du token suivant par rapport à un recalcul de tout le préfixe. Il ne rend pas ce coût indépendant de la longueur du contexte. Avec une attention complète classique, la requête du nouveau token interagit toujours avec les clés et les valeurs conservées. Plus le contexte retenu est long, plus l’attention doit exploiter de données. Hugging Face documente ce travail d’attention qui subsiste à chaque étape.

Il faut alors distinguer deux formes de réutilisation. Au sein d’une réponse, le cache KV évite de répéter les calculs pendant la génération. Entre plusieurs requêtes, le cache de préfixe, aussi appelé prompt caching dans les API hébergées, conserve les états éligibles pour qu’un appel ultérieur puisse éviter une partie du prefill. Un identifiant de conversation ne suffit pas, à lui seul, à garantir que ces états sont disponibles.

Prenons un agent qui lit un document de procédure, appelle un outil, puis demande au modèle de décider quoi faire du résultat. La requête suivante peut garder les instructions et le document précédents comme préfixe commun, puis ajouter le résultat de l’outil. Si ce préfixe est éligible et disponible en cache, le fournisseur n’a pas besoin de préparer à nouveau ce début commun.

Si vous développez avec une API, mesurez donc à la fois le délai avant le premier token et le temps de génération de la réponse. Un premier token plus rapide ne prouve pas que le decode s’est accéléré. La documentation Automatic Prefix Caching de vLLM distingue explicitement les économies de prefill du temps de decode.

Comment le travail réutilisé devient une entrée facturée au tarif cache

La remise porte sur le travail d’entrée réutilisé, selon les règles de facturation du fournisseur. Il n’existe pas de pourcentage universel, et une requête qui trouve un préfixe en cache ne bénéficie pas d’une remise sur tous ses tokens.

Pour les API qui distinguent entrée ordinaire, écritures en cache et lectures du cache, le coût des entrées s’écrit :

Coût des entrées = (U × p_input + W × p_write + R × p_read) / 1,000,000

Ici, U désigne les tokens d’entrée ordinaires, W les tokens facturés comme écritures en cache et R les tokens facturés comme lectures du cache. Chaque p est le prix de sa catégorie par million de tokens. Les catégories doivent être mutuellement exclusives : un token écrit en cache ne doit pas être facturé une seconde fois au tarif d’entrée ordinaire. Ce calcul découle des unités et des catégories tarifaires d’OpenAI et d’Anthropic.

Ajoutez ensuite les sorties, les éventuels frais d’outils et le stockage du cache lorsqu’il est facturé séparément. Le cache explicite de Google ajoute une dimension de durée de conservation : un calcul limité aux écritures et aux lectures ne suffit donc pas. Les exemples qui suivent illustrent ces modalités, sans classer les modèles.

Anthropic : délimiter le préfixe réutilisable

Anthropic expose le prompt caching via cache_control, soit au niveau global de la requête pour gérer automatiquement les points de coupure, soit sur des blocs de contenu individuels. Un point de coupure marque la fin du préfixe à conserver. Sa documentation tarifaire décrit les deux approches.

Exemple de tarifs, API Claude standard : pour Claude Sonnet 5.5, l’entrée coûte $2, les lectures du cache $0.10, les écritures pour 5 minutes $2.50 et celles pour 1 heure $4, dans chaque cas par million de tokens. Tarifs Anthropic.

Pour ce modèle, le préfixe doit compter au moins 512 tokens pour être mis en cache. Le contenu doit correspondre exactement jusqu’à la limite du cache. Les lectures renouvellent sa durée de vie sans nouveaux frais d’écriture, mais le décompte commence au début de la requête : la génération de la réponse consomme donc une partie de cet intervalle. Les autres modèles Claude ont des minimums et des remises sur les lectures différents. Règles du prompt caching Anthropic.

Pour un agent documentaire qui reprend après une longue pause de l’utilisateur, la durée de conservation peut déterminer si l’appel suivant lit un préfixe existant ou le réécrit. Vérifiez cache_creation_input_tokens et cache_read_input_tokens dans les données d’usage : la présence du même document ne prouve pas qu’une lecture à tarif réduit a eu lieu. Champs d’usage.

OpenAI : vérifier les règles d’écriture propres au modèle

OpenAI active par défaut le prompt caching sur les modèles compatibles, et les modèles plus récents prennent en charge des points de coupure implicites et explicites. Le comportement dépend du modèle. Prompt caching OpenAI.

Exemple de tarifs, niveau Standard à contexte court : pour GPT-6.1 Sol, l’entrée coûte $2.00, l’entrée en cache $0.10 et les écritures en cache $2.50 par million de tokens ; les tarifs d’entrée et de cache de la requête entière doublent au-delà de 272K tokens d’entrée. Tarifs OpenAI, seuil du modèle.

Pour GPT-5.6 et les modèles ultérieurs, le minimum est de 1,024 tokens d’entrée visibles et la durée de vie documentée du cache est d’au moins 30 minutes après la dernière écriture ou réutilisation. Le tarif d’écriture remplace celui de l’entrée ordinaire pour les tokens concernés ; il ne vient pas doubler la facture de l’ensemble des entrées. Les modèles antérieurs suivent d’autres règles d’écriture et de conservation. Règles actuelles du cache.

Dans l’API Responses, examinez usage.input_tokens_details.cached_tokens et cache_write_tokens. Conserver une session ne garantit pas une réutilisation du cache. Consultez le guide de diagnostic du prompt caching de GPT-6 du site pour analyser l’organisation de la requête et l’usage déclaré.

Google Gemini : distinguer réutilisation implicite et stockage explicite

Google Gemini propose un cache implicite automatique, dont les économies sont répercutées lorsque le cache est utilisé. Pour l’exemple Gemini 3.8 Flash, le minimum documenté est de 4,096 tokens d’entrée. Placer le contenu commun au début et rapprocher les requêtes dans le temps augmente les chances de réutilisation. Guide du cache de contexte Google.

Exemple de tarifs, API Gemini Developer payante au niveau Standard : pour Gemini 3.8 Flash, l’entrée coûte $0.75, l’entrée en cache $0.075 par million de tokens et le stockage du cache explicite $0.50 par million de tokens et par heure, jusqu’au 31 décembre 2026. Tarifs Google.

Le cache explicite utilise une ressource nommée de contenu en cache, assortie d’un paramètre d’expiration, à laquelle les requêtes generateContent suivantes font référence. Avec cette facturation du stockage, conserver un document inutilisé peut encore coûter de l’argent. Référence de l’API de cache Google.

Le choix de l’API compte : l’API Interactions ne prend en charge que le cache implicite. Le guide actuel de Google exclut également le cache explicite pour Gemini 4 Argon et les modèles ultérieurs ; les modèles Gemini 3 et 2.5 compatibles utilisent generateContent pour les caches explicites. Pour l’API Interactions, examinez usage.total_cached_tokens, comme l’indique le guide. Règles propres aux API Google.

En pratique, la distinction est la suivante : observez-vous des réutilisations automatiques, ou payez-vous délibérément pour conserver une ressource ? Si vous exploitez ces API, ne concevez pas une abstraction de cache commune à plusieurs fournisseurs en supposant que ces deux mécanismes ont le même cycle de vie.

La taille du cache KV augmente avec le contexte conservé

Pour les couches d’attention complète classiques, la mémoire brute du cache KV augmente linéairement avec le nombre de tokens conservés. Une longue conversation représente un ensemble de données de travail qui grossit, même si son début bénéficie d’une remise à la facturation.

Pour des séquences de même longueur et des couches d’attention de géométrie uniforme :

KV bytes ≈ 2 × B × T × L × H_kv × D × S

• 2 : un tableau de clés et un tableau de valeurs.
• B : nombre de séquences simultanées, en supposant que les données de leurs caches ne sont pas partagées.
• T : nombre de tokens traités et conservés par séquence, comprenant le prompt et les tokens générés.
• L : nombre de couches d’attention qui conservent ce type de cache.
• H_kv : nombre de têtes de clés/valeurs par couche.
• D : nombre de valeurs scalaires par tête.
• S : nombre d’octets utilisés pour stocker chaque valeur scalaire.

Ce calcul compte les éléments à partir de la forme documentée du cache de chaque couche et de l’organisation des têtes de clés/valeurs de vLLM. Il estime la taille des tenseurs bruts, pas la mémoire totale du matériel.

Le nombre de têtes est déterminant. Avec l’attention à requêtes groupées (grouped-query attention), plusieurs têtes de requête partagent des têtes de clés/valeurs. Il faut donc utiliser le nombre de têtes KV dans la formule. Le remplacer par le nombre, plus élevé, de têtes de requête surestimerait la taille du cache.

À modèle et précision de stockage constants, doubler T double le cache dense brut. Doubler à la fois T et le nombre de séquences simultanées indépendantes le rend quatre fois plus volumineux. C’est un résultat algébrique, pas une affirmation sur la capacité d’un GPU particulier ni sur un débit mesuré.

Pour un service d’assistance auto-hébergé, cela conduit à une question utile pour dimensionner l’infrastructure : combien de tokens conservés sont actifs au même moment, tous clients confondus ? Faire tenir le modèle en mémoire n’est qu’un début. Le serveur doit aussi héberger l’état d’inférence évolutif de ces clients.

La documentation des stratégies de cache de Hugging Face décrit la limite des couches à fenêtre, tandis que la conception du cache de préfixe de vLLM couvre les blocs physiques réutilisables. Lorsque l’architecture s’écarte de ces tableaux denses classiques de clés/valeurs, utilisez la structure d’état qu’elle documente.

Pour le client d’une API hébergée, cette même croissance a une autre conséquence visible : davantage de tokens peuvent être facturés en lecture à chaque tour, même avec un taux de réutilisation stable. Un prix unitaire réduit multiplié par un volume d’entrée croissant reste une dépense croissante. La génération continue elle aussi d’appliquer l’attention au contexte, et les seuils tarifaires peuvent dépendre de la longueur totale des entrées.

Optimiser le cache KV avec vLLM

vLLM, moteur open source de service d’inférence pour LLM, donne aux équipes qui hébergent leurs modèles des leviers sur l’allocation, la réutilisation et la représentation du cache. Identifiez celui qui répond à votre goulot d’étranglement avant de modifier le déploiement.

PagedAttention : allouer des blocs au fil de la conversation

PagedAttention permet à l’attention de travailler sur des données KV réparties dans des blocs physiques distincts. Une séquence logique n’a pas besoin d’une grande réservation contiguë couvrant toute sa croissance future possible. La conception originale réduit le gaspillage d’allocation et autorise le partage. Article de recherche sur PagedAttention.

L’analogie de la bibliothèque reste valable : attribuez à un projet de recherche qui grandit des portions d’étagères disponibles, en gardant un plan de leur ordre. Inutile de réserver d’emblée une immense allée vide avant de savoir combien de documents il produira.

La pagination ne réduit pas, à elle seule, l’information stockée pour chaque token. Elle améliore la façon dont cette information occupe la mémoire disponible. Par ailleurs, vLLM présente sa page sur le noyau Paged Attention comme historique : retenez le principe sans prendre cette ancienne description du noyau pour l’implémentation actuelle.

Cache de préfixe : réutiliser le travail commun à une requête précédente

Automatic Prefix Caching réutilise l’état KV d’un préfixe identique. vLLM documente enable_prefix_caching=True : c’est la fonctionnalité à examiner lorsque des questions répétées sur un document ou des tours d’agent présentent toujours le même début. Automatic Prefix Caching.

L’identité du cache inclut le préfixe qui précède un bloc, pas seulement le texte du bloc pris isolément. Des paragraphes identiques placés après des instructions différentes ne peuvent donc pas être considérés d’office comme interchangeables. La conception du cache de vLLM fondée sur le hachage rend cette dépendance explicite.

La limite vient de la charge de travail : des prompts sans rapport entre eux offrent peu de calculs communs à réutiliser, et de longues réponses peuvent rester dominées par le decode. Si vous devez aussi choisir le moteur, le comparatif vLLM et SGLang traite cette décision plus largement.

Quantifier le cache KV : réduire les octets par valeur stockée

La quantification du cache KV réduit la précision des valeurs numériques conservées. vLLM prend en charge le stockage du cache en FP8 via kv_cache_dtype="fp8" et recommande de calibrer les facteurs d’échelle sur un jeu de données pour préserver la qualité. Les possibilités dépendent du backend d’attention. Documentation du cache quantifié de vLLM.

Passer de valeurs sur 16 bits à des valeurs sur 8 bits divise par deux les données scalaires brutes de la formule, avant les métadonnées d’échelle et les surcoûts d’allocation. Cela ne divise pas par deux toute la mémoire du serveur et ne démontre pas une accélération mesurée. Quantifier les poids du modèle et quantifier l’état d’attention sont deux décisions distinctes.

Pour un agent en production, évaluez les tâches longues qui comptent : conserver les contraintes, choisir les outils et retrouver des détails dans les messages antérieurs. Un état plus compact n’est utile que si la tâche aboutit toujours. Le simple fait que le serveur démarre ne permet pas de conclure que la qualité est inchangée.

Compresser le cache KV : distinguer précision et contenu

Réduire la précision des valeurs et conserver moins de positions sont deux compromis différents. La quantification change la représentation des valeurs. Une fenêtre d’attention bornée change les positions qui restent accessibles à la couche concernée. Leurs modes de défaillance ne doivent pas être regroupés sous une promesse générique de compression. Stratégies de cache de Hugging Face.

Un premier geste concret consiste à ne plus envoyer les résultats d’outils sans pertinence pour la tâche. Cela réduit le contexte futur à la source, mais relève d’une décision applicative : préservez les éléments dont l’agent a besoin avant d’optimiser l’état conservé.

Déporter le cache KV : accepter des transferts pour conserver davantage d’état

Le déport, ou offloading, déplace l’état réutilisable vers un autre niveau de mémoire. L’OffloadingConnector de vLLM peut conserver les blocs terminés dans la mémoire du système hôte côté CPU et dans les niveaux secondaires pris en charge, puis les ramener sur le GPU lorsqu’ils sont réutilisés. Guide du déport de cache vLLM.

Cette approche peut aider lorsque les préfixes restent utiles plus longtemps qu’ils ne résident sur le GPU. Elle ajoute aussi des déplacements de données. Comparez, sur votre charge de travail, le bénéfice des recalculs évités au coût des transferts ; il n’existe pas de gain de latence universel à annoncer.

Lorsque les caches KV actifs mettent la mémoire sous pression, vLLM peut interrompre temporairement des requêtes, puis reprendre leur traitement en recalculant leur état. Son guide d’optimisation recommande d’examiner la concurrence entre requêtes et l’allocation mémoire lorsque ces préemptions deviennent fréquentes. Pour l’exploitation, une hausse du nombre de préemptions est un signal plus utile que le simple constat d’une mémoire GPU apparemment pleine.

Ce que le taux de réutilisation du cache ne dit pas

Un taux de réutilisation élevé ne suffit pas à rendre un agent efficace. Il mesure la réutilisation, alors que votre activité a besoin d’une tâche menée à bien dans un délai et un budget acceptables.

Une conversation peut réutiliser presque toutes ses entrées précédentes tout en grossissant à chaque tour. Elle peut relire sans cesse des éléments inutiles, à tarif réduit. Elle peut aussi passer l’essentiel de son temps à générer des sorties, phase pour laquelle la réutilisation du préfixe n’offre aucun raccourci direct.

Ne conservez pas un historique surchargé dans le seul but de protéger un indicateur de cache. Condensez-le ou repartez de zéro lorsque les anciens éléments n’aident plus, en acceptant qu’un préfixe modifié puisse nécessiter un nouveau traitement. La décision doit dépendre de la qualité du résultat et du travail total. Le guide d’ingénierie du contexte du site explique comment choisir ce qui mérite de rester dans le contexte de travail.

Si vous utilisez des API, optimisez dès maintenant l’organisation des prompts lorsque vos requêtes partagent régulièrement une quantité importante de contenu. Attendez avant de mettre en place une gestion élaborée du cache si votre charge de travail réutilise rarement un préfixe. Si vous hébergez les modèles, examinez la pression sur l’allocation et les préemptions avant de conclure qu’il faut davantage de puissance de calcul. Une charge composée de requêtes courtes, isolées et sans rapport entre elles offre peu de réutilisation entre appels.

Questions fréquentes sur le cache KV des LLM

ChatGPT utilise-t-il un cache KV ?

OpenAI documente un prompt caching fondé sur le cache KV pour ses API. Cela établit le fonctionnement de cette fonctionnalité publique, sans décrire tous les détails de l’infrastructure interne de ChatGPT. Pour développer une application, appuyez-vous sur les règles de cache publiées et les champs d’usage du modèle d’API choisi. Documentation OpenAI.

Faut-il déporter le cache KV vers la mémoire GPU ?

Lors d’une inférence sur GPU, l’état d’attention actif est utilisé sur le GPU. Dans la fonction de déport de vLLM, les blocs réutilisables sont déplacés vers la mémoire hôte ou d’autres niveaux pris en charge, puis reviennent à la demande. Envisagez cette option lorsque conserver davantage de préfixes justifie le travail de transfert. Déport de cache vLLM.

Que se passe-t-il quand le cache KV est plein ?

vLLM peut évincer les blocs en cache inutilisés ; sous la pression des requêtes actives, il peut interrompre un traitement et le recalculer ultérieurement. Cela affecte la latence. Ce phénomène est distinct du dépassement de la fenêtre de contexte du modèle. Gestion du cache, préemption.

Comment réduire la taille du cache KV ?

Réduisez le contexte conservé ou le nombre de séquences simultanées, réutilisez les préfixes partagés éligibles ou évaluez un stockage du cache à précision réduite. Le déport change l’emplacement de l’état sans nécessairement réduire sa taille totale. Jugez le résultat sur la qualité de la tâche et la latence observée, en plus de la mémoire. Stratégies de cache.

Trois habitudes pour favoriser la réutilisation du cache des agents

Pendant une tâche en cours, gardez un début stable et ajoutez les changements à la fin. La réutilisation d’un préfixe exact bénéficie d’une requête prévisible, dans les limites de longueur minimale, de conservation et de disponibilité du fournisseur.

1. 1

   Placer le prompt système stable en premier

   Placez les instructions durables, les définitions d’outils et les références réutilisables avant les données variables de la tâche, en respectant la structure de messages imposée par l’API. Gardez une formulation, un ordre des outils et une sérialisation stables. Chez Anthropic, la hiérarchie est outils, système, puis messages ; modifier l’ensemble des outils peut invalider la réutilisation de ce qui suit. Structure du cache Anthropic.

2. 2

   Enrichir l’historique sans le réécrire

   Conservez les messages précédents et ajoutez le nouveau tour utilisateur, l’appel d’outil de l’assistant ou le résultat de l’outil. Évitez de reconstruire les tours passés avec des résumés ou une mise en forme qui changent à chaque appel. Lorsqu’il devient nécessaire de condenser l’historique, faites-en une rupture délibérée, puis établissez un nouveau préfixe stable. Cette règle découle de la dépendance de chaque bloc aux tokens qui le précèdent. Identité des préfixes dans vLLM.

3. 3

   Éloigner les horodatages du début

   Placez l’heure courante, l’identifiant de requête et les autres métadonnées variables après le contenu réutilisable. Un horodatage au début peut invalider la réutilisation du contexte qui le suit. Avec des points de coupure explicites, marquez la fin du préfixe stable, avant le suffixe variable. Consignes Anthropic sur les points de coupure.

Dès le prochain jour de travail, examinez une conversation d’agent représentative au moment de l’envoi des requêtes. Comparez le préfixe exact d’un appel au suivant, puis rapprochez les écritures et les lectures déclarées par le fournisseur du total des entrées, des sorties et de la latence. Corrigez un préfixe instable avant de changer de fournisseur. Si le cache est déjà bien réutilisé et que l’agent reste lent, examinez ensuite le contexte conservé, la longueur des sorties et la contention sur le serveur.

Abonnez-vous à la newsletter pour comprendre concrètement les systèmes qui font fonctionner les agents IA.