Cache de contexte en IA : ce qu’elle réutilise et pourquoi cela ne signifie pas « se souvenir »

Définition : réutiliser des calculs, pas acquérir des souvenirs

Dans le domaine de l’intelligence artificielle, un cache de contexte est un stockage temporaire de résultats de traitement qu’un modèle peut réutiliser afin de ne pas recalculer certaines parties d’une entrée. Pour les modèles de langage, le terme désigne souvent deux mécanismes liés, mais distincts : le cache KV, qui conserve des états internes d’attention pendant la génération, et le cache de préfixe ou de prompt, qui permet de tirer parti du traitement d’un début identique ou commun à plusieurs requêtes.

Le mot « contexte » peut prêter à confusion. Ici, il ne signifie pas que le système a intégré des informations à ses connaissances permanentes, ni qu’il se souvient nécessairement d’une conversation une fois celle-ci terminée. Il désigne les données que le modèle traite pour répondre, ainsi que les résultats intermédiaires qu’une implémentation peut garder disponibles pendant un certain temps. Un cache réduit le travail répétitif lorsque les conditions nécessaires sont réunies ; il n’ajoute pas, à lui seul, de nouvelles informations à la réponse.

Le mécanisme exact dépend du modèle, du runtime et du service. Une implémentation peut exposer des métriques d’utilisation du cache, proposer des contrôles pour partager ou isoler certaines données, ou ne pas rendre ce mécanisme visible à l’utilisateur. « Cache de contexte » est donc une appellation utile, mais il est préférable de préciser le type de cache dont on parle.

Fonctionnement du cache KV pendant la génération

Un modèle autorégressif génère le texte token après token : à chaque étape, il prédit le token suivant à partir des tokens précédents. Pour calculer l’attention, le modèle produit des représentations internes appelées clés (keys) et valeurs (values). Le cache KV conserve ces tenseurs pour les tokens déjà traités, afin que les étapes suivantes puissent les réutiliser au lieu de tout recalculer depuis le début.

En simplifiant, le modèle traite le prompt, calcule les états nécessaires et enregistre les clés et valeurs correspondantes. Lorsqu’il génère ensuite un nouveau token, il calcule les états de cette nouvelle étape et consulte aussi les états mémorisés pour les tokens précédents. Le cache s’agrandit au fil de la génération, dans la limite de la mémoire disponible et de la stratégie de gestion employée par le système.

Cette description porte sur le fonctionnement général ; elle ne signifie pas que tous les modèles utilisent une structure identique. Il existe plusieurs variantes de cache et différentes stratégies pour les gérer, les conserver ou les placer à divers niveaux de mémoire. Un service peut également disposer de mécanismes permettant de réutiliser des blocs entre plusieurs requêtes ; il ne faut pas confondre automatiquement cette fonction avec le cache KV d’une seule séquence.

Cache de préfixe : réutilisation entre plusieurs requêtes

Le cache de préfixe ou de prompt tire parti de parties initiales répétées dans différentes requêtes. Au lieu de recalculer le traitement d’un préfixe déjà présent dans le cache, le système peut réutiliser les blocs d’états KV associés à ce préfixe et poursuivre le calcul à partir de là. Un serveur peut, par exemple, appliquer cette technique lorsque de nombreuses requêtes partagent les mêmes instructions initiales ou un fragment commun de contexte.

Cette réutilisation exige une correspondance suffisante au regard des règles de l’implémentation. Dans les systèmes qui organisent le cache en blocs, le préfixe est réparti en blocs et le système vérifie si les blocs précédents correspondent ; il ne suffit pas que deux requêtes portent sur le même sujet. Des différences de texte, d’ordre ou de tokenisation peuvent empêcher la correspondance. D’autres éléments de configuration peuvent aussi intervenir, selon le système.

Le cache de préfixe ne signifie pas qu’une réponse est enregistrée pour être simplement renvoyée telle quelle. Ce qui est réutilisé, c’est le traitement d’une partie commune de l’entrée ; la nouvelle requête peut contenir d’autres éléments et nécessiter des calculs supplémentaires. La correspondance, la disponibilité des blocs et les règles d’expiration ou d’éviction déterminent si la réutilisation est possible.

Certains fournisseurs décrivent cette fonction à l’aide de métriques spécifiques, telles que le nombre de tokens d’entrée traités à partir du cache. Ces métriques et les conditions de conservation sont propres à l’implémentation documentée : il ne faut pas les extrapoler à d’autres fournisseurs ou runtimes.

Trois exemples concrets

Les exemples ci-dessous décrivent des usages possibles du mécanisme. Ils ne garantissent pas qu’une plateforme donnée implémente le cache de la même manière, ni qu’elle obtienne toujours une amélioration mesurable.

Dans chaque cas, il faut distinguer les données de traitement temporairement réutilisées des informations que l’application pourrait conserver pour d’autres raisons. La première fonction relève du cache ; la seconde dépend, par exemple, des règles de gestion de l’historique ou d’une mémoire persistante.

Notions souvent confondues

Le cache et la fenêtre de contexte ne sont pas synonymes. La fenêtre de contexte correspond à la quantité d’informations que le modèle peut prendre en compte au cours d’une exécution, dans les limites définies par le modèle ou le service. Le cache est un mécanisme qui conserve ou réutilise des calculs. À lui seul, il n’agrandit pas la fenêtre et ne permet pas d’inclure davantage de texte que le système ne l’autorise.

Le cache et la mémoire persistante sont également deux choses différentes. Une mémoire d’agent ou d’application peut conserver des informations afin de les retrouver lors d’interactions ultérieures, selon les règles de conception retenues. Un cache de traitement sert à réutiliser des résultats intermédiaires et peut disparaître, expirer ou être évincé. Même si ces deux fonctions peuvent stocker temporairement des données, elles n’ont pas le même objectif.

Le cache KV et le cache de préfixe ne désignent pas non plus exactement la même opération. Le premier renvoie généralement aux états conservés pendant la génération d’une séquence ; le second, à la possibilité de réutiliser les états d’un préfixe commun à plusieurs requêtes. Un système de cache de préfixe peut s’appuyer sur des blocs KV, mais la réutilisation entre requêtes ajoute des conditions de correspondance, de gestion et d’isolation.

Enfin, réutiliser un traitement n’équivaut pas à réutiliser le contenu textuel d’une réponse toute faite. Si deux requêtes partagent un préfixe, la partie commune peut bénéficier d’états internes déjà calculés. Cela ne signifie pas que le texte de sortie est enregistré, que la nouvelle réponse sera identique à une précédente ou que le modèle a acquis une compréhension supplémentaire.

Limites, confidentialité et exploitation

Un cache n’est pas illimité. Les états KV occupent de la mémoire, et les systèmes de service doivent gérer les blocs qu’ils gardent disponibles. Lorsque les ressources viennent à manquer, une implémentation peut évincer des blocs ou appliquer d’autres stratégies de gestion ; une entrée qui pouvait être réutilisée auparavant peut donc ne plus être disponible à l’arrivée d’une nouvelle requête. La durée effective de conservation et les règles d’expiration ne sont pas universelles.

La correspondance compte également. Un préfixe qui ressemble à un autre par son sens peut ne pas correspondre pour le cache si la séquence de tokens diffère. Des changements de modèle, de template ou de configuration peuvent modifier le traitement ou la manière de détecter les préfixes. Il ne faut donc pas supposer que répéter une instruction garantit sa réutilisation.

En matière de confidentialité, il faut consulter la documentation et la configuration du système concerné. Il est utile de vérifier combien de temps les données restent dans le cache, comment les requêtes ou les utilisateurs sont isolés, s’il existe des contrôles de partitionnement ou d’invalidation et quelles métriques sont exposées. Un cache partagé entre requêtes peut soulever des questions d’isolation ; la documentation de certains systèmes signale, par exemple, des risques de canal auxiliaire et décrit des mesures précises pour les atténuer. Cet avertissement ne prouve pas que tous les services présentent le même risque, ni qu’une mesure particulière soit disponible partout.

Les métriques doivent également être interprétées avec précaution. Un compteur de tokens servis depuis le cache peut décrire la réutilisation d’une entrée, mais ne permet pas, à lui seul, de conclure à une réduction précise des coûts ou de la latence. Ces résultats dépendent de l’API, du matériel, de la charge, de la configuration et des méthodes de facturation ou de mesure. Toute affirmation chiffrée doit être rapportée au fournisseur et aux conditions dans lesquelles elle a été mesurée.

Notions connexes et repères pratiques

L’attention est le mécanisme du modèle qui relie différentes parties de la séquence ; les clés et les valeurs sont des composants internes utilisés dans ce calcul. Les tokens sont les unités d’entrée et de sortie sur lesquelles le modèle opère. L’inférence est le processus par lequel le modèle produit une sortie. Le cache KV aide à éviter de répéter une partie du travail lié à l’attention, tandis que le cache de préfixe cherche à réutiliser le traitement d’une entrée commune. Ces notions sont liées, mais ne sont pas interchangeables.

Pour lire une documentation ou configurer un système, commencez par demander ce qui est stocké : des états KV, un préfixe traité, du texte conversationnel ou un autre type de données. Cherchez ensuite à savoir à quelle échelle le cache fonctionne — une génération, une session ou plusieurs requêtes —, combien de temps il dure, ce qui rend une correspondance valide et comment le système réagit au manque de mémoire. Enfin, distinguez les données mesurées par la plateforme des attentes : réutiliser des calculs peut réduire les tâches répétées, mais les économies concrètes et la latence dépendent des circonstances.

En règle générale, si votre objectif est de poursuivre une génération token après token, cherchez des informations sur le cache KV et ses stratégies. Si plusieurs requêtes partagent un long début, consultez la documentation du cache de préfixe et de ses règles de correspondance. Si vous voulez que le système retrouve des données utilisateur d’une session à l’autre, renseignez-vous sur la mémoire persistante ou le stockage de l’application ; ne partez pas du principe qu’un cache de contexte remplira cette fonction.

Concepts associés