Mise en cache des prompts (Prompt Caching & Reuse of KV Cache)

1. Vue d'ensemble du concept et problématique système

Dans le développement moderne basé sur des agents (comme Claude Code ou Cursor), chaque dialogue se compose de dizaines d'itérations. Or, 90 à 95 % des informations contenues dans chaque requête sont entièrement statiques :

• Le prompt système incluant les règles du projet (5 000 tokens).
• Les schémas de 20 outils MCP connectés (10 000 tokens).
• Les fichiers indexés de documentation et de code (40 000 tokens).

Sans mise en cache, à chaque réplique du développeur, le serveur est contraint de recalculer l'intégralité des 55 000 tokens statiques à travers les matrices du transformeur (Phase Prefill) :

1. Coût financier élevé : Vous payez le prix fort pour la lecture des mêmes 55 000 tokens 30 fois par session.
2. Latence élevée (High TTFT) : Le temps jusqu'à l'apparition du premier caractère de la réponse s'étire à 5–10 secondes, ruinant l'expérience du vibe coding interactif.
3. Gaspillage des ressources GPU : La puissance de calcul des cartes graphiques est consommée pour répéter des calculs déterministes.

Le Prompt Caching élimine cette surcharge : le serveur calcule une seule fois l'état d'attention pour le préfixe statique, le fige dans une mémoire HBM ultra-rapide et récupère instantanément cet état prêt à l'emploi lors des appels suivants.

2. Taxonomie architecturale et modèle mental

L'architecture de la mise en cache des prompts s'articule autour des couches conceptuelles suivantes :

• 1. Structure des préfixes (Prefix Hierarchy) : Le prompt est structuré comme un matroïde, allant du plus statique au plus dynamique : [Static System Prompt] -> [MCP Tool Definitions] -> [Cached Project Context] -> [Dynamic Turn History] -> [User Input].
• 2. Économie des états de cache :
  • Cache Write : Premier appel ou écriture après modification du préfixe. Coûte 25 % plus cher que l'entrée standard, car cela nécessite la fixation de l'état en mémoire.
  • Cache Hit / Read : Appel répété vers un préfixe inchangé. Offre une réduction de 80–90 % sur le coût de base des tokens d'entrée.
• 3. Points de sauvegarde (Breakpoints) : Marqueurs spécifiques dans la structure de la requête qui indiquent au moteur d'inférence où se termine exactement le bloc stable sujet à la sauvegarde.
• 4. Mécanismes de recherche de cache :
  • Radix Tree / Prefix Trie : Structure de données en mémoire du serveur d'inférence (par exemple, dans vLLM / SGLang) qui trouve instantanément la plus longue chaîne commune de tokens parmi les sessions actives.

3. Pipeline technique et mécanique interne

Cycle de vie d'une requête utilisant le Prompt Caching :

1. Sérialisation & Vérification de Hash (Hachage du préfixe) : Le client envoie un tableau de messages. Le serveur prend la séquence de tokens depuis le début jusqu'au premier point cache_control et calcule un hash cryptographique du préfixe.
2. Recherche dans le Trie (Lookup dans l'arbre de caches) : Le gestionnaire de mémoire GPU vérifie si un bloc KV-cache vivant existe pour ce hash.
   • Si trouvé (Cache Hit) — le calcul Prefill est sauté, les matrices $K$ et $V$ sauvegardées sont immédiatement connectées au graphe de calcul.
   • Si non trouvé (Cache Miss) — le serveur effectue un calcul complet et écrit le résultat de manière asynchrone dans le buffer.
3. Traitement du suffixe dynamique (Dynamic Suffix Processing) : Le transformeur calcule l'attention uniquement pour le nouveau fragment — le dernier message utilisateur (par exemple, 200 tokens au lieu de 50 000).
4. Décodage immédiat & Rafraîchissement TTL (Génération) : Le modèle commence la génération de la réponse en seulement 200–400 millisecondes, et le timer de vie du cache est réinitialisé pour un nouvel intervalle de 5 minutes.

4. Scénarios d'ingénierie pratiques en production

01. Sessions de développement multi-étapes dans Claude Code et Cursor

L'agent effectue un refactoring complexe en 15 étapes. Grâce à la mise en cache, la base de code du projet (100 000 tokens) est cachée dès l'étape 1. Aux étapes 2–15, l'utilisateur ne paie que pour la delta des modifications, économisant jusqu'à 85 % du coût total du développement pour la soirée.

02. Mise en cache de grandes bibliothèques d'outils MCP

La connexion de 30 outils d'entreprise complexes nécessite des schémas JSON détaillés occupant 12 000 tokens. La mise en cache du bloc d'outils garantit que le développeur ne surpaye pas pour leur description à chaque question triviale posée dans le chat.

03. Assistants d'entreprise à forte charge basés sur une base de connaissances

Un chatbot de support interne utilise un seul document système caché (réglementations, instructions, FAQ) d'un volume de 50 000 tokens. Des milliers d'employés envoient des requêtes simultanément, tombant dans la même couche cachée sur le cluster de modèles, assurant ainsi un temps de réponse minimal.

5. Pièges, erreurs courantes et sécurité

• Fuite de données dynamiques dans le préfixe (Invalidation par Timestamp) : L'erreur d'ingénierie la plus fréquente consiste à ajouter une ligne dynamique telle que Current Time: 2026-09-09 12:15:30 au début du prompt système. Cela modifie les premiers tokens à chaque seconde et brise à 100 % la mise en cache pour tous les modules suivants. Placez les variables dynamiques dans les messages finaux.
• Démarrage à froid après inactivité : Si plus de 5 minutes se sont écoulées entre les étapes du développeur, le cache s'évapore. La requête suivante est facturée au tarif Cache Write avec une latence d'initialisation.
• Mélange des droits d'accès (Multi-Tenant Cache Bleed) : Sur les serveurs auto-hébergés (vLLM), assurez-vous que les sessions de différents utilisateurs n'utilisent pas un préfixe commun contenant des données personnelles confidentielles.