La mise en cache par invite consiste à mettre en cache les préfixes récurrents dans la requête de modèle, puis à essayer de réutiliser directement les résultats de traitement lorsqu’on rencontre les mêmes préfixes ou des préfixes très cohérents à l’avenir, plutôt que de les compter à partir de zéro à chaque fois. La raison pour laquelle il est devenu de plus en plus populaire ces deux dernières années n’est pas à cause du nom avancé, mais parce que de plus en plus de produits ont finalement réalisé que les consignes système fixes, les définitions d’outils, les règles longues et les longs arrière-plans des documents constituent la véritable majeure partie des coûts et retards liés à l’IA.
Beaucoup confondent la mise en cache par prompts avec la mise en cache contextuelle, qui sont effectivement proches mais pas exactement le même objectif. La mise en cache par prompts met l’accent sur le « préfixe de prompt », surtout dans les situations où la première moitié de chaque requête est à peu près la même et ne change que dans la seconde moitié. Par exemple, les agents du service client, les assistants de code et les assistants de connaissances d’entreprise doivent souvent être d’abord remplis de règles système fixes, de descriptions d’outils et de contraintes de format, et le seul vrai changement est le problème utilisateur.
Pourquoi est-il particulièrement adapté aux agents multi-roues ? Parce qu’une fois qu’un agent entre dans les appels d’outils et l’inférence en plusieurs étapes, il comporte beaucoup de contexte répétitif. Si vous fournissez au modèle une liste complète d’outils, de longs conseils système et des instructions de workflow fixes à chaque étape, ce sera lent et la facture sera désagréable. La valeur du mécanisme de mise en cache est de diluer ces coûts récurrents autant que possible.
Mais la mise en cache des prompts n’est pas une solution miracle qui « sauvegarde automatiquement beaucoup quand on l’active ». Cela dépend beaucoup de la stabilité du préfixe. Tant que vous changez une ou deux positions de la demande système à chaque fois, que vous mélangez l’ordre des exemples et que vous laissez les définitions de l’outil évoluer d’un côté à l’autre, le taux de réussite baissera considérablement. Beaucoup d’équipes ont de mauvais effets de mise en cache, non pas parce que le modèle ne les supporte pas, mais parce que le projet d’invite lui-même est écrit trop librement et ne possède aucun préfixe stable réutilisable.
Il existe généralement trois catégories de contenu qui conviennent vraiment à la mise en cache des prompts. La première catégorie concerne les règles système inchangées à long terme, telles que les rôles, les tons, les frontières et les contraintes de sécurité. La deuxième catégorie est constituée des descriptions de blocs fortement multiplexées, telles que les descriptions d’index de la base de connaissances, les schémas de format et les listes d’outils. La troisième catégorie concerne les tâches chaînées qui se répètent entre les sessions. Au contraire, ces champs personnalisés par l’utilisateur, les données en temps réel et les résultats de recherche qui changent à chaque fois ne conviennent pas à l’espace cache devant.
Il a aussi un point mal compris : la mise en cache économise des coûts de prétraitement et de préfixe, ce qui ne signifie pas que les résultats seront exactement les mêmes, ni que le modèle « se souvient de tout l’historique ». La qualité de la réponse dépend toujours des entrées ultérieures, des paramètres d’échantillonnage, des rendements d’outils et de la justesse du contexte. Le cache résout le travail répétitif, pas la correction du raisonnement.
On voit donc maintenant la documentation d’API comme OpenAI et Anthropic mettre l’accent sur la mise en cache des prompts, disant essentiellement aux développeurs une chose : les prompts ne sont plus du texte à usage unique, mais des ressources système optimisables. Celui qui peut stabiliser la partie statique, reculer la partie dynamique et améliorer le taux de réussite sera plus susceptible de faire tourner les longs prompts et les scènes d’agents plus rapidement et de manière plus économique.