Optimisation des LLM : Caching d'Inference Décrypté

Introduction au Caching d'Inference dans les LLM

Dans le domaine des modèles de langage de grande taille (LLM), le caching d'inference est une technique cruciale pour optimiser les performances. Lorsqu'un utilisateur envoie un prompt à un LLM, le modèle effectue une quantité substantielle de calcul pour traiter l'entrée et générer chaque token de sortie. Ce processus est non seulement coûteux en temps, mais également en ressources financières. Le caching d'inference permet de stocker les résultats de ces calculs à différents niveaux de granularité et de les réutiliser lors de requêtes similaires ou identiques, réduisant ainsi le coût et le temps de traitement.

Les Trois Types de Caching

Il existe trois types principaux de caching d'inference, chacun opérant à un niveau différent de la pile :

• KV caching : Ce type de cache stocke les états d'attention internes, c'est-à-dire les paires clé-valeur, calculés lors d'une seule demande d'inférence. Cela permet au modèle de ne pas recalculer ces états à chaque étape de décodage. Le KV caching est automatique et toujours actif.

• Prefix caching : Également connu sous le nom de prompt caching ou context caching, il étend le KV caching à plusieurs demandes. Lorsqu'un préfixe de tokens est partagé entre différentes requêtes, les états KV pour ce préfixe sont stockés et réutilisés à travers toutes ces demandes. Le prefix caching est l'optimisation la plus efficace que vous pouvez ajouter à la plupart des applications de production.

• Semantic caching : Ce cache de niveau application stocke des paires d'entrée/sortie complètes de LLM et les récupère en fonction de la similarité sémantique. Contrairement au prefix caching, qui opère sur les états d'attention en cours de calcul, le semantic caching court-circuite complètement l'appel au modèle lorsqu'une requête suffisamment similaire a déjà été vue.

Ces types ne sont pas des alternatives interchangeables, mais des couches complémentaires. Le KV caching fonctionne toujours, le prefix caching est l'optimisation la plus efficace pour la plupart des applications de production, et le semantic caching est une amélioration supplémentaire lorsque le volume de requêtes et la similarité sont suffisamment élevés pour le justifier.

Comprendre le KV Caching

Le KV caching est la base sur laquelle tout le reste est construit. Pour le comprendre, il est nécessaire d'avoir un aperçu rapide de la façon dont l'attention des transformateurs fonctionne pendant l'inférence.

Le Mécanisme d'Attention et Son Coût

Les LLM modernes utilisent l'architecture transformer avec auto-attention. Pour chaque token dans l'entrée, le modèle calcule trois vecteurs :

• Q (Query) — Que cherche ce token ?

• K (Key) — Que propose ce token aux autres tokens ?

• V (Value) — Quelle information ce token porte-t-il ?

Les scores d'attention sont calculés en comparant la requête de chaque token avec les clés de tous les tokens précédents, puis en utilisant ces scores pour pondérer les valeurs. Cela permet au modèle de comprendre le contexte sur l'ensemble de la séquence.

Les LLM génèrent des sorties de manière autoregressive — un token à la fois. Sans caching, générer le token N nécessiterait de recalculer K et V pour tous les N-1 tokens précédents à partir de zéro. Pour de longues séquences, ce coût s'accumule à chaque étape de décodage.

Comment le KV Caching Résout Cela

Lors d'un passage avant, une fois que le modèle a calculé les vecteurs K et V pour un token, ces valeurs sont sauvegardées dans la mémoire GPU. Pour chaque étape de décodage suivante, le modèle consulte les paires K et V stockées pour les tokens existants plutôt que de les recalculer. Seul le token nouvellement généré nécessite un calcul frais. Voici un exemple simple :

• Sans KV caching (génération du token 100) :

  • Recalculer K, V pour les tokens 1–99 → puis calculer le token 100

• Avec KV caching (génération du token 100) :

  • Charger K, V stockés pour les tokens 1–99 → calculer uniquement le token 100

Ceci est le KV caching dans son sens original : une optimisation au sein d'une seule demande. Il est automatique et universel ; chaque cadre d'inférence LLM l'active par défaut. Vous n'avez pas besoin de le configurer. Cependant, le comprendre est essentiel pour appréhender le prefix caching, qui étend ce mécanisme à travers les demandes.

Utiliser le Prefix Caching pour Réutiliser les États KV à Travers les Demandes

Le prefix caching — également appelé prompt caching ou context caching selon le fournisseur — prend le concept de KV caching un pas plus loin. Au lieu de cacher les états d'attention uniquement au sein d'une seule demande, il les cache à travers plusieurs demandes — spécifiquement pour tout préfixe partagé que ces demandes ont en commun.

L'Idée Principale

Considérez une application typique de LLM en production. Vous avez un long prompt système — instructions, un document de référence, et des exemples à quelques coups — qui est identique à chaque demande. Seul le message de l'utilisateur à la fin change. Sans prefix caching, le modèle recalculerait les états KV pour tout ce prompt système à chaque appel. Avec le prefix caching, il les calcule une fois, les stocke, et chaque demande subséquente qui partage ce préfixe passe directement au traitement du message de l'utilisateur.

L'Exigence Strict : Correspondance Exacte du Préfixe

Le prefix caching ne fonctionne que lorsque la portion mise en cache du prompt est identique byte à byte. Une seule différence de caractère — un espace à la fin, un signe de ponctuation changé, ou une date reformatée — invalide le cache et force un recalcul complet. Cela a des implications directes sur la façon dont vous structurez vos prompts.

• Placez le contenu statique en premier et le contenu dynamique en dernier. Les instructions système, les documents de référence, et les exemples à quelques coups devraient précéder chaque prompt. Les variables par demande — le message de l'utilisateur, un ID de session, ou la date actuelle — devraient apparaître à la fin.

• Évitez également la sérialisation non déterministe. Si vous injectez un objet JSON dans votre prompt et que l'ordre des clés varie entre les demandes, le cache ne sera jamais atteint, même lorsque les données sous-jacentes sont identiques.

Implémentations des Fournisseurs

Plusieurs grands fournisseurs d'API exposent le prefix caching comme une fonctionnalité de premier plan.

• Anthropic l'appelle prompt caching. Vous devez l'activer en ajoutant un paramètre cache_control aux blocs de contenu que vous souhaitez mettre en cache.

• OpenAI applique le prefix caching automatiquement pour les prompts de plus de 1024 tokens. La même règle structurelle s'applique : la portion mise en cache doit être le préfixe stable de votre prompt.

• Google Gemini l'appelle context caching et facture le cache stocké séparément de l'inférence. Cela le rend le plus rentable pour des contextes très grands et stables qui sont réutilisés de nombreuses fois à travers les demandes.

• Des frameworks open-source comme vLLM et SGLang supportent le prefix caching automatique pour les modèles auto-hébergés, géré de manière transparente par le moteur d'inférence sans modifications de votre code d'application.

Comprendre le Fonctionnement du Semantic Caching

Le semantic caching opère à un niveau différent : il stocke des paires d'entrée/sortie complètes de LLM et les récupère en fonction de la signification, et non des correspondances exactes de tokens.

La Différence Pratique

La différence pratique est significative. Le prefix caching rend le traitement d'un long prompt système partagé moins coûteux à chaque demande. Le semantic caching évite complètement l'appel au modèle lorsqu'une requête sémantiquement équivalente a déjà été répondue, peu importe si la formulation exacte correspond.

Voici comment le semantic caching fonctionne en pratique :

• Une nouvelle requête arrive. Calculez son vecteur d'embedding.

• Recherchez dans un magasin de vecteurs des entrées mises en cache dont les embeddings de requête dépassent un seuil de similarité cosinus.

• Si une correspondance est trouvée, retournez directement la réponse mise en cache sans appeler le modèle.

• Si aucune correspondance n'est trouvée, appelez le LLM, stockez l'embedding de requête et la réponse dans le cache, et retournez le résultat.

En production, vous pouvez utiliser des bases de données vectorielles telles que Pinecone, Weaviate, ou pgvector, et appliquer un TTL approprié afin que les réponses mises en cache périmées ne persistent pas indéfiniment.

Quand le Semantic Caching Vaut le Coût Supplémentaire

Le semantic caching ajoute une étape d'embedding et une recherche vectorielle à chaque demande. Ce coût supplémentaire n'est justifié que lorsque votre application a un volume de requêtes suffisant et des questions répétées de sorte que le taux de réussite du cache justifie la latence et l'infrastructure ajoutées. Il fonctionne mieux pour des applications de type FAQ, des bots de support client, et des systèmes où les utilisateurs posent les mêmes questions de manières légèrement différentes à un volume élevé.

Choisir la Bonne Stratégie de Caching

Ces trois types fonctionnent à différents niveaux et résolvent différents problèmes.

STRATÉGIE DE CACHING PAR CAS D'UTILISATION

• Toutes les applications, toujours : KV caching (automatique, rien à configurer)

• Long prompt système partagé entre de nombreux utilisateurs : Prefix caching

• Pipeline RAG avec de grands documents de référence partagés : Prefix caching pour le bloc de document

• Flux de travail d'agent avec un contexte large et stable : Prefix caching

• Application à fort volume : Semantic caching pour éviter les appels redondants et optimiser les performances.