Réduire les Coûts LLM de 90% : Prompt Caching et Optimisation de Préfixes

1. Le fonctionnement du Prompt Caching KV

Chaque appel d’inférence à un LLM recalcule l’attention sur l’intégralité de la séquence d’entrée, à moins que le fournisseur du modèle ne mette en cache les tenseurs clé-valeur intermédiaires d’un appel précédent partageant un préfixe commun. Le prompt caching, proposé comme un niveau de facturation distinct par tous les grands fournisseurs, permet de réutiliser ces tenseurs KV précalculés pour la portion d’une nouvelle requête qui correspond exactement à un préfixe déjà mis en cache, en évitant complètement le calcul pour ce segment et en n’exécutant la passe avant que sur les nouveaux tokens ajoutés ensuite.

La structure de coût qui en résulte est asymétrique par conception : les tokens d’entrée en cache sont généralement facturés à environ un dixième du coût des tokens d’entrée non mis en cache chez les principaux fournisseurs, tandis que le prix des tokens de sortie n’est pas affecté par la mise en cache, la génération étant intrinsèquement séquentielle et donc impossible à précalculer. Pour des charges de travail avec un large contexte partagé et stable, un long prompt système, un ensemble de documents récupérés, ou un extrait de code source, sollicité de façon répétée sur de nombreuses requêtes, ce facteur dix sur le coût du côté entrée se cumule pour produire les économies globales importantes pour lesquelles cette technique est connue.

Le mécanisme apporte aussi un bénéfice de latence souvent aussi précieux que le bénéfice de coût : sauter la passe avant sur les tokens en cache réduit directement le temps jusqu’au premier token, puisque le modèle n’a pas besoin d’exécuter de calcul d’attention sur un contenu déjà traité, ce qui compte de façon disproportionnée pour les applications sensibles à la latence comme les agents conversationnels, où les utilisateurs remarquent davantage le délai avant le premier token que la durée totale de génération.

2. Durée de vie du cache, invalidation et différences entre fournisseurs

Un préfixe mis en cache n’est pas permanent : les fournisseurs évincent les entrées de cache après une période d’inactivité, allant typiquement de quelques minutes à environ une heure selon le fournisseur et le niveau de cache, et un cache miss retombe silencieusement sur un traitement à plein tarif et pleine latence plutôt que de générer une erreur, ce qui signifie qu’une stratégie de mise en cache qui paraît correcte en test peut cesser discrètement de générer des économies en production si les schémas de requêtes deviennent trop peu fréquents ou trop espacés dans le temps pour maintenir le cache chaud.

Les fournisseurs diffèrent sensiblement dans la façon dont la mise en cache est déclenchée et facturée : certains exigent un marqueur explicite de contrôle de cache dans la requête identifiant précisément quel segment de préfixe doit être mis en cache, tandis que d’autres le font automatiquement dès qu’une correspondance de préfixe dépasse un seuil minimal de tokens, sans opt-in explicite, et les coûts d’écriture en cache (mettre un nouveau préfixe en cache pour la première fois) sont parfois facturés avec une surprime par rapport au tarif d’entrée standard, ce qu’il faut prendre en compte pour estimer les économies dès la toute première requête d’une session, pas seulement en régime stationnaire.