Contexte et rôle du cache de prompts
Les grands modèles de langage (LLM) utilisent un cache de clés‑valeurs (KV) pour mémoriser les représentations des tokens déjà traités. Lorsque le texte d’une requête est un préfixe exact d’une requête précédente, le serveur ne recalcule que la partie nouvelle ; les tokens « cached » sont ainsi servis à moindre coût énergétique. Cette technique, appelée prompt caching, dépend d’une correspondance stricte du préfixe : toute modification du texte déjà envoyé entraîne un cache break, obligeant le modèle à recomposer les tokens à partir du premier différend.
Mesure de l’efficacité du cache selon les harnesss
Neuralwatt a analysé un mois de trafic (8 sept. – 7 oct. 2026) sur plusieurs agents open‑source (OpenCode, Pi, omp, Kilo Code) et des intégrations d’IDE. Le taux de cache variait de 92 % à 97 % : à 92 % de cache, huit tokens sur cent restent non‑cachés, contre trois à 97 %. Cette différence de 5 tokens non‑cachés représente un facteur 2,7 d’augmentation du travail de pré‑remplissage pour une conversation identique. Le nombre de ruptures de cache était d’environ 1 % des tours pour le harness deepseek‑harness, contre 3 % pour OpenCode et Pi.
Coût énergétique d’un cache miss
Le tableau de facturation énergétique montre qu’une requête majoritairement non‑cachée consomme approximativement le double d’énergie d’une requête entièrement cachée. Sur le modèle GLM‑5.3, ce facteur grimpe à 2,5 ×. Le pré‑remplissage utilise les mêmes GPU que la génération, de sorte qu’un surplus de travail ralentit toutes les réponses concurrentes.
Dans les sessions profondes (> 128 k tokens de contexte), un seul tour qui relit plus de la moitié du prompt peut coûter l’équivalent de 600 tours classiques en pré‑remplissage. En moyenne, ces tours relisent 230 k tokens, alors qu’un tour normal ajoute seulement 370 nouveaux tokens. Ainsi, un événement rare (≈ 3 tours sur 1 000) représente 75 % du volume de re‑lecture à cette profondeur.
Origine des ruptures de cache et pistes d’amélioration
Les tests en laboratoire, reproduisant 539 requêtes consécutives, ont montré que 88 % des requêtes étaient de simples ajouts (préfixe intact). Les 12 % restants (≈ 65 requêtes) ont tous présenté un cache break dû à une modification du harness : aucun break n’est survenu à cause de modèles de chat ou de temps d’inactivité. Les modifications les plus coûteuses proviennent d’ajouts en début de prompt (ex. horodatage), qui forcent la recomputation de presque tout le contexte.
Ces constats suggèrent que la plupart des inefficacités sont évitables. En limitant les éditions du prompt aux positions terminales, ou en implémentant des stratégies de différenciation incrémentale (par ex. hash du préfixe), les harnesss pourraient maintenir des taux de cache supérieurs à 95 % et réduire de moitié la consommation énergétique des sessions longues.
