Pourquoi se soucier de la mise en cache des invites dans les LLM ?

nous avons beaucoup parlé quel outil incroyable est RAG pour exploiter la puissance de l’IA sur des données personnalisées. Mais qu’il s’agisse de requêtes API LLM simples, d’applications RAG ou d’agents IA plus complexes, une question courante reste la même. Comment toutes ces choses évoluent-elles ? En particulier, qu’arrive-t-il au coût et à la latence à mesure que le nombre de requêtes dans ces applications augmente ? Ces questions revêtent une importance particulière, en particulier pour les agents d’IA plus avancés, qui peuvent contenir plusieurs appels à un LLM pour traiter une seule requête utilisateur.

Heureusement, en réalité, lors d’appels vers un LLM, les mêmes jetons d’entrée sont généralement répétés sur plusieurs requêtes. Les utilisateurs vont poser certaines questions spécifiques beaucoup plus que d’autres, les invites du système et les instructions intégrées dans les applications basées sur l’IA sont répétées dans chaque requête utilisateur, et même pour une seule invite, les modèles effectuent des calculs récursifs pour générer une réponse complète (rappelez-vous comment les LLM produisent du texte en prédisant les mots un par un ?). Comme pour d’autres applications, l’utilisation du cacheCe concept peut contribuer de manière significative à optimiser les coûts et la latence des requêtes LLM. Par exemple, selon Documentation OpenAIn, Prompt Caching peut réduire la latence jusqu’à 80 % et les coûts des jetons d’entrée jusqu’à 90 %.

---

Et la mise en cache ?

En général, mise en cache en informatique n’est pas une idée nouvelle. À la base, un cache est un composant qui stocke temporairement les données afin que les futures demandes concernant les mêmes données puissent être traitées plus rapidement. De cette manière, nous pouvons distinguer deux états de base du cache : un succès de cache et un échec de cache. En particulier:

• Un accès au cache se produit lorsque les données demandées sont trouvées dans le cache, ce qui permet une récupération rapide et peu coûteuse.
• Un échec de cache se produit lorsque les données ne sont pas dans le cache, obligeant l’application à accéder à la source d’origine, ce qui est plus coûteux et prend plus de temps.

L’une des implémentations les plus courantes du cache concerne les navigateurs Web. Lors de la première visite d’un site Web, le navigateur vérifie l’URL dans son cache mémoire, mais ne trouve rien (ce sera un manque de cache). Étant donné que les données que nous recherchons ne sont pas disponibles localement, le navigateur doit effectuer une requête plus coûteuse et plus longue au serveur Web sur Internet, afin de trouver les données sur le serveur distant où elles existent à l’origine. Une fois la page chargée, le navigateur copie généralement ces données dans son répertoire local. cache. Si nous essayons de recharger la même page 5 minutes plus tard, le navigateur la recherchera dans son stockage local. Cette fois, il le trouvera (un accès au cache) et le chargera à partir de là, sans revenir au serveur. Cela permet au navigateur de fonctionner plus rapidement et de consommer moins de ressources.

Comme vous pouvez l’imaginer, la mise en cache est particulièrement utile dans les systèmes où les mêmes données sont demandées plusieurs fois. Dans la plupart des systèmes, l’accès aux données est rarement uniforme, mais tend plutôt à suivre une distribution dans laquelle une petite fraction des données représente la grande majorité des requêtes. Une grande partie des applications réelles suit le Principe de Paretoce qui signifie qu’environ 80 % des demandes représentent environ 20 % des données. Sans le principe de Pareto, la mémoire cache devrait être aussi grande que la mémoire principale du système, ce qui la rendrait très, très coûteuse.

---

Mise en cache rapide et quelques informations sur l’inférence LLM

Le concept de mise en cache – stocker les données fréquemment utilisées quelque part et les récupérer à partir de là, au lieu de les récupérer à partir de leur source principale – est utilisé de la même manière pour améliorer l’efficacité des appels LLM, permettant ainsi de réduire considérablement les coûts et la latence. La mise en cache peut être utilisée dans divers éléments pouvant être impliqués dans une application d’IA, le plus important étant la mise en cache d’invite. Néanmoins, la mise en cache peut également offrir de grands avantages en étant appliquée à d’autres aspects d’une application d’IA, comme, par exemple, la mise en cache lors de la récupération RAG ou la mise en cache requête-réponse. Néanmoins, cet article se concentrera uniquement sur la mise en cache des invites.

---

Pour comprendre le fonctionnement de Prompt Caching, nous devons d’abord comprendre un peu comment fonctionne l’inférence LLM – utilisant un LLM formé pour générer du texte. L’inférence LLM n’est pas un processus unique et continu, mais est plutôt divisée en deux étapes distinctes. Ce sont :

• Pré-remplirqui fait référence au traitement de l’intégralité de l’invite en même temps pour produire le premier jeton. Cette étape nécessite des calculs lourds, et il est donc lié au calcul. Nous pouvons imaginer une version très simplifiée de cette étape où chaque jeton s’occupe de tous les autres jetons, ou quelque chose comme comparer chaque jeton avec chaque jeton précédent.
• Décodagequi ajoute le dernier jeton généré dans la séquence et génère le suivant de manière auto-régressive. Cette étape est lié à la mémoirecar le système doit charger l’intégralité du contexte des jetons précédents à partir de la mémoire pour générer chaque nouveau jeton.

Par exemple, imaginez que nous ayons l’invite suivante :

What should I cook for dinner? 

D’où nous pouvons alors obtenir le premier jeton :

Here

et les itérations de décodage suivantes :

Here 
Here are 
Here are 5 
Here are 5 easy 
Here are 5 easy dinner 
Here are 5 easy dinner ideas

Le problème est que pour générer la réponse complète, le modèle devrait traiter encore et encore les mêmes jetons précédents pour produire chaque mot suivant pendant l’étape de décodage, ce qui, comme vous pouvez l’imaginer, est très inefficace. Dans notre exemple, cela signifie que le modèle traiterait à nouveau les jetons ‘Que dois-je cuisiner pour le dîner ? En voici 5 faciles‘pour produire le résultat’idées‘, même s’il a déjà traité les jetons ‘Que dois-je cuisiner pour le dîner ? Voici 5′ il y a quelques millisecondes.

Pour résoudre cela, Mise en cache KV (valeur-clé) est utilisé dans les LLM. Cela signifie que les tenseurs de clé et de valeur intermédiaires pour l’invite de saisie et les jetons générés précédemment sont calculés une fois, puis stockés dans le cache KV, au lieu d’être recalculés à partir de zéro à chaque itération. Le modèle effectue ainsi le minimum de calculs nécessaires pour produire chaque réponse. En d’autres termes, pour chaque itération de décodage, le modèle effectue uniquement des calculs pour prédire le jeton le plus récent, puis l’ajoute au cache KV.

Néanmoins, la mise en cache KV ne fonctionne que pour une seule invite et pour générer une seule réponse. La mise en cache des invites étend les principes utilisés dans la mise en cache KV pour utiliser la mise en cache entre différentes invites, utilisateurs et sessions.

---

En pratique, avec la mise en cache des invites, nous sauvegardons les parties répétées d’une invite après la première requête. Ces parties répétées d’une invite ont généralement la forme d’un grand préfixescomme les invites système, les instructions ou le contexte récupéré. De cette manière, lorsqu’une nouvelle requête contient le même préfixe, le modèle utilise les calculs effectués précédemment au lieu de recalculer à partir de zéro. C’est incroyablement pratique car cela peut réduire considérablement les coûts d’exploitation d’une application d’IA (nous n’avons pas à payer pour des entrées répétées contenant les mêmes jetons), ainsi que réduire la latence (nous n’avons pas besoin d’attendre que le modèle traite les jetons déjà traités). Ceci est particulièrement utile dans les applications où les invites contiennent de grandes instructions répétées, telles que les pipelines RAG.

Il est important de comprendre que cette mise en cache fonctionne au niveau du jeton. En pratique, cela signifie que même si deux invites diffèrent à la fin, tant qu’elles partagent le même préfixe de jeton, les calculs mis en cache pour cette partie partagée peuvent toujours être réutilisés et effectuer de nouveaux calculs uniquement pour les jetons qui diffèrent. La partie délicate ici est que les jetons communs doivent être au début de l’invite, donc la façon dont nous formons nos invites et nos instructions devient d’une importance particulière. Dans notre exemple de cuisine, nous pouvons imaginer les invites consécutives suivantes.

Prompt 1
What should I cook for dinner? 

et puis si nous saisissons l’invite :

Prompt 2
What should I cook for launch? 

Les jetons partagés’Que dois-je cuisiner’ devrait être un succès dans le cache, et il faut donc s’attendre à consommer des jetons considérablement réduits pour l’invite 2.

Néanmoins, si nous avions les invites suivantes…

Prompt 1
Dinner time! What should I cook? 

et puis

Prompt 2
Launch time! What should I cook? 

Ce serait un échec de cache, puisque le premier jeton de chaque invite est différent. Étant donné que les préfixes d’invite sont différents, nous ne pouvons pas accéder au cache, même si leur sémantique est essentiellement la même.

Par conséquent, une règle de base pour faire fonctionner la mise en cache des invites consiste à toujours ajouter toute information statique, comme des instructions ou des invites système, au début de l’entrée du modèle. D’un autre côté, toutes les informations généralement variables telles que les horodatages ou les identifications des utilisateurs doivent figurer à la fin de l’invite.

---

Se salir les mains avec l’API OpenAI

De nos jours, la plupart des modèles de fondations frontières, comme Google Tag ou Claudefournissent une sorte de fonctionnalité de mise en cache d’invite directement intégrée à leurs API. Plus précisément, dans les API mentionnées, Prompt Caching est partagé entre tous les utilisateurs d’une organisation accédant à la même clé API. En d’autres termes, une fois qu’un utilisateur fait une demande et que son préfixe est stocké dans le cache, pour tout autre utilisateur saisissant une invite avec le même préfixe, nous obtenons un accès au cache. Autrement dit, nous pouvons utiliser des calculs précalculés, qui réduisent considérablement la consommation de jetons et accélèrent la génération de réponses. Ceci est particulièrement utile lors du déploiement d’applications d’IA dans l’entreprise, où l’on s’attend à ce que de nombreux utilisateurs utilisent la même application, et donc les mêmes préfixes d’entrées.

Sur la plupart des modèles récents, Prompt Caching est automatiquement activé par défaut, mais un certain niveau de paramétrage est disponible. On peut distinguer :

• En mémoire conservation rapide du cache, où les préfixes mis en cache sont conservés pendant environ 5 à 10 minutes et jusqu’à 1 heure, et
• Étendu rétention rapide du cache (disponible uniquement pour des modèles spécifiques), permettant une conservation plus longue du préfixe mis en cache, jusqu’à un maximum de 24 heures.

Mais regardons de plus près !

Nous pouvons voir tout cela en pratique avec l’exemple Python minimal suivant, envoyant des requêtes à l’API OpenAI, en utilisant Prompt Caching et les invites de cuisson mentionnées précédemment. J’ai ajouté un préfixe partagé assez volumineux à mes invites, afin de rendre les effets de la mise en cache plus visibles :

from openai import OpenAI
api_key = "your_api_key"
client = OpenAI(api_key=api_key)

prefix = """
You are a helpful cooking assistant.

Your task is to suggest simple, practical dinner ideas for busy people.
Follow these guidelines carefully when generating suggestions:

General cooking rules:
- Meals should take less than 30 minutes to prepare.
- Ingredients should be easy to find in a regular supermarket.
- Recipes should avoid overly complex techniques.
- Prefer balanced meals including vegetables, protein, and carbohydrates.

Formatting rules:
- Always return a numbered list.
- Provide 5 suggestions.
- Each suggestion should include a short explanation.

Ingredient guidelines:
- Prefer seasonal vegetables.
- Avoid exotic ingredients.
- Assume the user has basic pantry staples such as olive oil, salt, pepper, garlic, onions, and pasta.

Cooking philosophy:
- Favor simple home cooking.
- Avoid restaurant-level complexity.
- Focus on meals that people realistically cook on weeknights.

Example meal styles:
- pasta dishes
- rice bowls
- stir fry
- roasted vegetables with protein
- simple soups
- wraps and sandwiches
- sheet pan meals

Diet considerations:
- Default to healthy meals.
- Avoid deep frying.
- Prefer balanced macronutrients.

Additional instructions:
- Keep explanations concise.
- Avoid repeating the same ingredients in every suggestion.
- Provide variety across the meal suggestions.

""" * 80   
# huge prefix to make sure i get the 1000 something token threshold for activating prompt caching

prompt1 = prefix + "What should I cook for dinner?"

et puis pour l’invite 2

prompt2 = prefix + "What should I cook for lunch?"

response2 = client.responses.create(
    model="gpt-5.2",
    input=prompt2
)

print("\nResponse 2:")
print(response2.output_text)

print("\nUsage stats:")
print(response2.usage)

Ainsi, pour l’invite 2, seule la partie restante et non identique de l’invite nous serait facturée. Ce serait les jetons d’entrée moins les jetons mis en cache : 20 014 – 19 840 = seulement 174 jetons, ou en d’autres termes, 99 % de jetons en moins.

Dans tous les cas, étant donné qu’OpenAI impose un seuil minimum de 1 024 jetons pour l’activation de la mise en cache des invites et que le cache peut être conservé pendant un maximum de 24 heures, il devient clair que ces avantages en termes de coûts ne peuvent être obtenus en pratique que lors de l’exécution d’applications d’IA à grande échelle, avec de nombreux utilisateurs actifs effectuant de nombreuses requêtes quotidiennement. Néanmoins, comme expliqué pour de tels cas, la fonctionnalité Prompt Caching peut offrir des avantages substantiels en termes de coût et de temps pour les applications basées sur LLM.

---

Dans mon esprit

Prompt Caching est une optimisation puissante pour les LLM qui peut améliorer considérablement l’efficacité des applications d’IA à la fois en termes de coût et de temps. En réutilisant les calculs précédents pour des préfixes d’invite identiques, le modèle peut ignorer les calculs redondants et éviter de traiter de manière répétée les mêmes jetons d’entrée. Le résultat est des réponses plus rapides et des coûts réduits, en particulier dans les applications où une grande partie des invites, telles que les instructions système ou le contexte récupéré, restent constantes sur de nombreuses requêtes. À mesure que les systèmes d’IA évoluent et que le nombre d’appels LLM augmente, ces optimisations deviennent de plus en plus importantes.

---

Vous avez adoré cet article ? Soyons amis ! Rejoignez-moi sur :

📰Sous-pile 💌 Moyen 💼LinkedIn ☕Achetez-moi un café!

Toutes les images sont de l’auteur, sauf mention contraire.