La mise en cache des invites réduit les coûts de l'IA et conserve vos données en mémoire

Une invite initiale de 3 000 tokens suivie de cinq tours de conversation, chacun ajoutant 1 000 tokens. Sans mise en cache, cette session coûte 30 unités. Avec un cache chaud et un TTL de 5 minutes, elle coûte 12,2. Avec un cache froid, elle coûte 37,5, plus que si la mise en cache n’avait jamais été activée. Même invite, même modèle, la seule variable est si le préfixe correspondait. Un préfixe est le début immuable d’une requête, comme les instructions et le contexte, que l’IA peut réutiliser au lieu de retraiter à chaque fois.

Basé sur les multiplicateurs de prix d’Anthropic (lecture cache 0,1x, écriture 5 minutes 1,25x), en comptant uniquement les tokens d’entrée.

La diffusion de l'exemple suffit à justifier l'apprentissage de la mise en cache des prompts. Le cache contient aussi tout ce que vos équipes et pipelines mettent dans le prompt, et cette partie reçoit beaucoup moins d'attention.

Qu'est-ce que la mise en cache des invites et comment ça fonctionne

Lorsqu’un modèle lit une invite, il calcule des états clé-valeur (KV) pour chaque jeton afin de pouvoir s’y référer lors de la rédaction de la réponse. Normalement, ces états sont supprimés à la fin de la réponse. La mise en cache de l’invite les conserve. Le cache stocke les tenseurs KV, pas les jetons bruts, et une requête ultérieure commençant par le même préfixe réutilise cet état sauvegardé et ne traite que les nouveautés.

La correspondance est exacte et basée sur un préfixe. Les fournisseurs comparent le début de votre requête avec ce qu’ils ont récemment mis en cache, dans cet ordre : outils, puis invite système, puis messages. Changez une date dans l’invite système et tout ce qui suit ne correspond plus. Une écriture en cache enregistre la conversation jusqu’à présent pour un temps de vie (TTL), et chaque accès réinitialise ce compteur, gardant la session active automatiquement.

Cinq façons dont la mise en cache rapide empêche d’économiser de l’argent

Valeurs volatiles près du haut. Une date actuelle, un nom d’utilisateur ou un ID de requête ajouté pour la journalisation transforme chaque appel en écriture. Une équipe a déplacé un seul champ volatile à la fin de l’invite, après la partie mise en cache, et les lectures ont enfin commencé à fonctionner.

Pauses plus longues que le TTL. En vous éloignant d’une session de 5 minutes pour une réunion, le tour suivant est facturé au prix plein pour toute la conversation. La ligne « tous manqués » dans le tableau ci-dessus illustre cela.

Compactage. Chaque compactage est un démarrage à froid, un cycle au prix plein sur un historique résumé que le fournisseur n’a jamais vu. Lancez /compact avant une pause tant que le cache est encore chaud. Une fois expiré, compacter coûte plus cher que de continuer.

Modifications en cours de session. Changer le modèle, le niveau d'effort, les plugins ou les serveurs MCP peut modifier l'invite système et invalider le cache. Consultez la documentation du fournisseur avant de modifier les paramètres en cours de tâche longue.

Mise à l’échelle et routage. À fort volume, les requêtes arrivent sur des machines sans votre entrée en cache. La vérification automatique du préfixe de Bedrock ne remonte qu’à environ 20 blocs de contenu depuis un point de contrôle, donc une longue section statique nécessite plusieurs.

Comment vérifier que la mise en cache des invites fonctionne

Comparez les jetons d’écriture en cache aux jetons de lecture en cache pour chaque fonctionnalité. Si les écritures suivent votre nombre de requêtes, rien n’est réutilisé. Vérifiez que cache_read_input_tokens est supérieur à zéro au premier tour après une période d’inactivité. Sur l’API Converse de Bedrock, lisez cacheReadInputTokens et cacheWriteInputTokens, et rappelez-vous que inputTokens compte alors uniquement les jetons non mis en cache, donc l’entrée totale est inputTokens plus les deux champs de cache. Sur GPT-5.6 et versions ultérieures, une réponse avec cached_tokens supérieur à zéro et cache_write_tokens à zéro signifie une correspondance complète.

Pour maintenir une longue session active, envoyez une petite requête utile toutes les 20 à 25 minutes. Un minuteur basé sur l'inactivité fonctionne mieux qu'un ping fixe, car le travail réel le réinitialise de toute façon.

Mise en cache des invites et données sensibles

La règle d’or du cache est : contenu statique d’abord, question de l’utilisateur en dernier. Considérez cette règle comme un inventaire des données. Les parties mises en cache sont les définitions d’outils, les invites système, les exemples few-shot, les gros documents de référence et les anciens échanges de conversation. Dans une configuration RAG, les documents de référence sont les mêmes fichiers injectés à chaque requête. Dans un chat, l’historique correspond à ce que les utilisateurs ont tapé.

Supposons qu’un employé soumette une entrée d’événement système incluant un ID utilisateur interne, un horodatage et un code de suivi de transaction. Dans une session mise en cache, ce texte figure dans le préfixe à chaque tour suivant, et chaque tour actualise son horloge.

Les fournisseurs prennent cela en compte. Les caches ne sont pas partagés entre organisations, même pour des invites identiques en octets. Anthropic et OpenAI décrivent la mise en cache comme éligible à une conservation nulle des données : le texte brut de l'invite n'est pas stocké au repos, seul l'état KV calculé reste en mémoire ou est brièvement déchargé pour une conservation prolongée, jusqu'à la fin du TTL. La mise en cache explicite de Google prend en charge les contrôles de service VPC sur sa plateforme entreprise. Ce sont de vrais contrôles.

Ils laissent aussi une fenêtre, et vous choisissez sa durée. De 5 minutes à 1 heure sur les modèles Anthropic, de 30 minutes à 12 heures sur GPT-5.6 d’OpenAI et suivants, et jusqu’à 24 heures sur les anciens modèles OpenAI avec rétention prolongée. Les pings heartbeat l’allongent tant qu’ils sont envoyés. Lisez les conditions actuelles de gestion des données de chaque fournisseur avant de stocker des données sensibles.

L’ajustement des coûts peut aussi aller dans la mauvaise direction. Un préfixe stable plus grand met mieux en cache, donc une équipe visant 50 % de répétition a une raison de charger plus de documents. Les calculs d’économies ne disent rien sur le contenu de ces documents.

L'injection de prompt augmente les enjeux. L'injection indirecte dissimule des instructions dans des fichiers qu'un assistant est susceptible de lire, comme un PDF habituel ou une invitation de calendrier, et l'exploit EchoLeak avait un score CVSS de 9,3. Un fichier empoisonné dans un ensemble de références en cache est relu à chaque requête jusqu'à ce que quelqu'un le retire.

Shadow AI ajoute la partie que l'informatique ne peut pas voir. La plupart des équipes ne voient qu'une petite partie des outils d'IA utilisés par leurs collaborateurs, de Claude.ai et Perplexity à Gemini et aux extensions de navigateur. Les interdire pousse les employés vers des appareils personnels, où les outils de sécurité ne peuvent pas intervenir. Les responsables sécurité optent plutôt pour des garde-fous spécifiques par groupe : scanners pour clés API fuitées et secrets codés pour l'ingénierie, et blocages de téléchargements ou identifiants tokenisés pour le juridique et la finance.

La tokenisation est une solution côté entrée. Une passerelle remplace un nom de patient par un jeton logique comme [PERSON_01] en moins de 300 millisecondes, permettant au modèle de suivre le récit sans voir l’identité. Un scanner ne peut masquer que ce qu’il reconnaît, ce qui fait de la classification l’étape préalable.

Les auditeurs demandent la même traçabilité. SOX, PCI DSS 4.0 et l'article 25 de la loi européenne sur l'IA exigent tous la journalisation et la traçabilité des interactions avec l'IA, incluant un ID de requête unique par prompt et une raison enregistrée pour chaque blocage. Le cache est un autre endroit où les données résident, et la durée de conservation est aussi une question à considérer.

Avant d’activer la mise en cache des invites

• Placez d'abord le contenu statique, puis la question de l'utilisateur en dernier.
• Décidez quelles sources peuvent entrer dans un préfixe mis en cache, et excluez les dossiers clients, les identifiants et les données réglementées.
• Choisissez le TTL le plus court qui génère encore des hits.
• Suivez les lectures et écritures du cache pour chaque fonctionnalité.
• Vérifiez le contenu de vos documents de référence avant de les intégrer au prompt.

Classez ce qui est dans le prompt avant sa mise en cache

Chaque contrôle ci-dessus dépend de la connaissance des fichiers sensibles. Netwrix Data Classification répond à cela à la source. Il découvre et classe en continu les données sensibles et réglementées sur les serveurs de fichiers Windows, NetApp, Dell EMC, Nutanix Files, SharePoint, Microsoft 365, Exchange, SQL Server, Oracle, MySQL, Box, Dropbox et Google Drive. Les règles prédéfinies couvrent le RGPD, HIPAA et PCI DSS, et les taxonomies personnalisées gèrent le reste.

Les étiquettes de classification intégrées aux fichiers alimentent les outils DLP et IRM, permettant qu’un document marqué sensible soit exclu d’un flux de travail IA avant qu’il ne soit chargé dans un préfixe. Détection ROT détecte les fichiers redondants, obsolètes et triviaux, réduisant ainsi le contenu périmé dans vos ensembles de référence. La remédiation automatisée déplace les données sensibles vers des emplacements sécurisés, supprime les permissions excessives et caviarde les contenus confidentiels.