La mise en cache des prompts réduit le CO₂ LLM : 60 à 90 % de calcul économisé quand le préfixe KV est en cache

Dans un transformer, la passe avant sur le prompt (prefill) est un facteur majeur de coût et de latence à l'inférence. La mise en cache des prompts réutilise les tenseurs clé/valeur stockés des couches d'attention lorsqu'un long préfixe se répète—de sorte que le modèle évite le calcul redondant sur ces tokens. Les grands fournisseurs exposent désormais cette fonctionnalité comme un élément de produit, et non plus seulement comme une optimisation interne.

Pourquoi la mise en cache modifie à la fois le $ et le kWh

Les API commerciales facturent les tokens d'entrée mis en cache bien en dessous des tokens d'entrée non mis en cache car le fournisseur évite de répéter le coûteux travail de prefill. Les remises varient selon la famille de modèles et sont publiées sur la page de tarification de chaque fournisseur—traitez-les comme un proxy du calcul évité, et non comme un compteur d'énergie littéral. Pour la comptabilité carbone au niveau du client, l'approche honnête consiste toujours à allouer en utilisant les tokens facturés × vos coefficients méthodologiques (voir comment nous estimons le CO₂e), tout en utilisant les taux de cache hit comme levier de réduction dans les narratifs de durabilité.

Les modèles des fournisseurs diffèrent

Certaines infrastructures appliquent la mise en cache automatique des préfixes lorsque les prompts dépassent une taille minimale et que les préfixes correspondent exactement ; d'autres demandent aux développeurs de marquer les points de rupture de cache (par ex. contrôle de cache éphémère sur les longs prompts système). La documentation ouverte explique que la mise en cache cible les projections KV dans l'attention—la même couche où les serveurs d'inférence ouverts implémentent la mise en cache des préfixes pour réutiliser les blocs KV entre les requêtes. Vos choix d'intégration (prompts système stables, définitions d'outils ordonnées de manière cohérente) affectent directement le taux de cache hit.

Ce qu'il faut mesurer en interne

• Taux de cache hit sur les longs préfixes partagés (guides de support, clauses juridiques, corpus RAG).
• Temps jusqu'au premier token—souvent un effet secondaire de l'élimination du travail de prefill.
• Tokens encore générés—la mise en cache des entrées ne réduit pas la longueur de complétion ; les tokens de sortie dominent souvent l'énergie sur les tâches ouvertes (tokens vs. matériel).

Chiffres réels : Claude Code à 92 % de taux de cache hit

Claude Code démontre à quoi ressemble une mise en cache des prompts bien conçue à grande échelle : 92 % de taux de cache hit et 81 % de réduction des coûts par rapport à un fonctionnement sans cache. Le mécanisme : le prompt système, le contexte du projet et l'historique de conversation sont structurés de sorte que le préfixe statique soit toujours en tête et croisse de manière prévisible, maximisant la réutilisation KV entre les tours.

Pour la comptabilité CO₂e : si votre application atteint un taux de cache hit de 90 % sur un préfixe de 20 000 tokens, 90 % du calcul de prefill pour ces tokens est évité à chaque appel mis en cache. À grande échelle, c'est le levier d'efficacité par appel le plus important disponible sans changer de modèle ni d'infrastructure.

Des évaluations académiques (arXiv 2601.06007) confirment la réutilisation KV comme outil de contrôle des coûts et du calcul pour les agents à horizon long. La discipline est architecturale : structurez les prompts pour la répétabilité — contenu statique en premier, dynamique en dernier, pas d'horodatages ni de graines aléatoires dans les prompts système — puis vérifiez avec les tableaux de bord de facturation en suivant cache_read_input_tokens vs cache_creation_input_tokens dans les réponses API.