La mise en cache des prompts LLM peut rendre une API premium moins chère qu’un GPU local sous-utilisé pour un contexte répété. Elle peut aussi ne générer aucune économie. Les variables déterminantes ne sont pas les prix catalogue des modèles. Ce sont la réutilisation des préfixes, le coût d’écriture du cache, les remises à la lecture, l’expiration, l’éviction, l’utilisation et le coût du travail échoué.
Public visé : praticiens avancés responsables des coûts, de la latence ou des décisions d’infrastructure liées à la plateforme LLM.
La règle pratique : mesurez les lectures du cache et les invalidations sur votre workload réel avant d’acheter de la capacité GPU. Une nouvelle étude de cas sur un agent de programmation d’entreprise souligne ce point avec un résultat impressionnant de 99,3 % de cache-hit, mais ses auteurs ont étudié un seul développeur, deux périodes séquentielles de 28 jours, différentes familles de modèles et une seule base de code en production. Considérez l’article comme une invitation à mesurer, et non comme un verdict cloud-versus-local.
Ce que la mise en cache des prompts LLM change
Un LLM traite l’entrée en deux grandes phases :
Au niveau du serving, la mise en cache des préfixes peut stocker les états d’attention ou les états key-value réutilisables pour un préfixe de prompt. Une requête ultérieure avec le même préfixe éligible peut éviter une partie du travail de prefill répété. Le suffixe variable doit toujours être traité, et le modèle doit toujours décoder une nouvelle réponse.
Cette distinction est importante. La mise en cache des prompts n’est pas de la mise en cache des réponses. Elle ne renvoie pas une réponse stockée, ne raccourcit pas la sortie, ne corrige pas un prompt faible et ne garantit pas une latence de bout en bout plus faible. Elle cible principalement le calcul répété sur l’entrée et améliore souvent le time to first token.
L’article original sur le Prompt Cache a formalisé les modules de prompts réutilisables et rapporté des améliorations prototypes du time-to-first-token allant de 8× sur GPU à 60× sur CPU. Il s’agit de résultats obtenus avec les modèles, le matériel, les prompts et l’implémentation testés dans l’article — et non d’une prévision pour les API commerciales actuelles.
L’étude de cas à 99,3 % : des éléments utiles, mais des limites étroites
Un preprint de juillet 2026, *Inference Economics of Enterprise Coding Agents*, a comparé deux périodes contiguës de 28 jours sur un monorepo de production :
Les auteurs ont analysé la télémétrie LLM et l’historique Git. Ils ont rapporté un taux de cache-hit des prompts de 99,3 % pour la période API, un coût API effectif de 0,573 $ par million de tokens traités et un coût unitaire amorti de 2,83 $ pour l’allocation on-premise partagée. L’API a traité 16,9 fois plus de tokens, tandis que le matériel local était peu utilisé ; ces prix normalisés par token ne suffisent donc pas à trancher la question de l’infrastructure.
Les résultats en coût total vont dans des directions différentes selon l’allocation. Selon les hypothèses de marché taïwanais et de main-d’œuvre de l’article, une capacité locale partagée réduisait de 40,1 % le coût total de possession estimé. Une réservation locale dédiée coûtait 43,8 % de plus que l’API avec cache. La période locale était également associée à un ratio plus élevé de commits de correction : 74,9 % contre 45,9 %.
Ce que les auteurs ont mesuré
Ce qu’ils en ont déduit
Ce que l’étude ne peut pas établir
Le protocole n’était ni randomisé ni simultané. La base de code, le développeur, la répartition des tâches et les pratiques de travail ont pu changer entre les périodes. Les capacités du modèle, la stack de serving, le harness et la quantification ont changé simultanément. Le premier auteur connaissait l’hypothèse. Le label de commit de correction est un proxy, et non un audit indépendant des défauts. La télémétrie brute de production et l’environnement complet de replay n’ont pas été publiés.
La conclusion durable est plus étroite que les chiffres mis en avant : la réutilisation des prompts et l’utilisation des GPU peuvent dominer les comparaisons de prix catalogue, tandis que le travail de correction peut dominer les économies de tokens.
Définissez le contrat de mesure avant de calculer un taux de hit
« Taux de cache-hit » est ambigu si le dénominateur n’est pas explicite. Un dashboard peut diviser les tokens lus depuis le cache par les tokens de préfixe éligibles. Un autre peut diviser les requêtes ayant une lecture du cache par l’ensemble des requêtes. Un troisième peut présenter les tokens mis en cache comme une part de l’entrée totale, suffixe non mis en cache compris.
Utilisez des métriques distinctes :
Conservez séparément les champs d’utilisation fournis par le fournisseur et les métriques que vous dérivez. Les décomptes de tokens peuvent également changer avec les tokenizers et les templates des modèles ; l’explication de la taxe tokenizer des LLM→ montre pourquoi le simple comptage des caractères est un mauvais substitut.
Le comportement actuel des API et du self-hosted n’est pas uniforme
L’instantané suivant a été vérifié le 30 juillet 2026. Vérifiez à nouveau la documentation liée avant de l’utiliser pour des achats ou la facturation.
| Plateforme | Contrôle du cache | Signal observable | Contrainte opérationnelle |
|---|---|---|---|
| --- | --- | --- | --- |
| OpenAI API | GPT-5.6 prend en charge la mise en cache implicite et explicite des prompts | `cached_tokens` et `cache_write_tokens` | Les recommandations actuelles de GPT-5.6 facturent les écritures explicites à 1,25× l’entrée non mise en cache ; les lectures bénéficient d’une remise |
| Anthropic API | Mise en cache automatique ou points de rupture explicites des blocs | Utilisation distincte pour la création et la lecture du cache | L’ordre des préfixes est tools, system, puis messages ; la TTL par défaut est de 5 minutes, avec une option payante d’une heure |
| Gemini Interactions API | La mise en cache implicite du contexte est activée par défaut pour Gemini 2.5 et les modèles plus récents | `usage.total_cached_tokens` | Le contenu commun doit être placé au début ; les minimums actuels vont de 2 048 à 4 096 tokens selon le modèle |
| vLLM | Automatic Prefix Caching peut être activé dans le moteur | Métriques du moteur et temps des requêtes | Votre équipe est responsable de la capacité, de l’éviction, de l’isolation, des mises à niveau et de l’observabilité |
Les recommandations actuelles d’OpenAI pour les modèles indiquent aux utilisateurs de GPT-5.6 de surveiller les écritures et les lectures du cache, car les écritures explicites coûtent plus cher que l’entrée non mise en cache. La documentation d’Anthropic sur la mise en cache des prompts documente des écritures de 5 minutes à 1,25× l’entrée de base, des écritures d’une heure à 2× et des lectures du cache à 0,1×. Le guide de Google sur la mise en cache du contexte indique que la mise en cache implicite est automatique dans son Interactions API et que les tokens mis en cache sont signalés dans l’utilisation. L’exemple d’Automatic Prefix Caching de vLLM montre la même idée de préfixe partagé dans un moteur self-hosted.
Ces implémentations partagent un principe, et non un contrat de facturation portable. Les longueurs minimales de préfixe, la portée du cache, la rétention, les frais de stockage, les champs d’utilisation et l’isolation peuvent différer.
*Mesurez le cache avant de modifier l’infrastructure : stabilisez le préfixe, exécutez des tests à froid et à chaud, forcez l’invalidation, puis comparez le coût total.*
Une formule de seuil de rentabilité pour le préfixe réutilisable
Soit :
En ignorant les frais de stockage, le coût moyen du préfixe réutilisable par requête est :
`(W + (N - 1) × R) / N`
La mise en cache est moins chère que le traitement non mis en cache de ce préfixe lorsque :
`N > (W - R) / (U - R)`
Cette équation isole le préfixe réutilisable. Elle exclut le suffixe variable, les tokens de sortie, la longueur minimale pouvant être mise en cache, les frais de stockage, les échecs dus à l’éviction, les effets de concurrence, le travail d’ingénierie et les tâches échouées.
Pour un exemple daté, les multiplicateurs de 5 minutes d’Anthropic au 30 juillet 2026 étaient `U = 1`, `W = 1.25` et `R = 0.1`. Le seuil limité à l’entrée est `N > 1.28` ; la deuxième utilisation pendant la durée de vie du cache amortit donc la charge d’écriture plus élevée pour ce préfixe éligible. Cela ne signifie pas que deux appels API au total rendent la mise en cache rentable. Un préfixe court, un long suffixe non mis en cache, un cache miss ou une sortie coûteuse peuvent annuler l’économie.
Utilisez l’équation comme test unitaire de votre modèle de coûts. Remplacez chaque variable par les valeurs du contrat actuel du fournisseur et de votre workload mesuré.
Pourquoi des prompts apparemment stables ratent le cache
La plupart des cache miss commencent dans la construction du prompt, et non dans le modèle.
Des données volatiles apparaissent trop tôt
Un horodatage, un identifiant de requête, un nonce aléatoire, un nom d’utilisateur ou un nouveau résultat de retrieval placé près du début modifie chaque token qui suit. Placez d’abord les tools, politiques, templates et documents réutilisables et stables. Déplacez les données propres à la requête après le préfixe réutilisable ou le point de rupture explicite.
La sérialisation change entre les requêtes
L’ordre des clés JSON, les espaces, l’ordre des tools et l’ordre des documents peuvent modifier un préfixe par ailleurs équivalent. Utilisez une sérialisation déterministe. Triez les définitions des tools et les documents récupérés selon des identifiants stables lorsque la sémantique le permet.
Le gestionnaire de contexte détruit la continuité du préfixe
Un pruning agressif peut économiser des tokens d’entrée tout en invalidant les préfixes mis en cache. TokenPilot, un preprint en cours de juin 2026, traite cela comme un problème d’optimisation conjointe. Ses auteurs stabilisent l’ingestion et retardent l’éviction jusqu’à ce que le contexte perde sa valeur pour la tâche. Ils rapportent des réductions de coûts de 56 % à 87 % sur deux benchmarks et deux modes d’exécution, tout en maintenant des performances compétitives. Ces résultats doivent être répliqués au-delà des workloads de l’article et de l’intégration LightMem2.
Le cache expire ou est évincé sous la charge réelle
Un test local à chaud peut masquer les limites de TTL et la pression sur la capacité. La mise en cache des préfixes en self-hosted partage la même réalité de mémoire finie que les autres systèmes de KV-cache. Le guide approfondi sur l’éviction du KV-cache→ explique pourquoi la réutilisation peut s’effondrer lorsque la concurrence et la longueur des séquences augmentent.
Le modèle ou le template change
Une version de modèle, un tokenizer, un chat template, un réglage de détail d’image, un schéma de tool ou un préambule de sécurité peut créer un nouveau préfixe. Traitez les releases et les migrations de prompts comme des événements d’invalidation du cache.
Les discussions d’ingénierie actuelles de vLLM illustrent cette pression. Une proposition de rétention tenant compte du contexte soutient que les workloads d’agents concurrents peuvent évincer des préfixes précieux, tandis qu’une proposition de KV-cache sémantique explore la réutilisation au-delà des correspondances exactes. Il s’agit de discussions de conception ouvertes, et non de garanties de production ou de mesures d’adoption.
Un test reproductible du cache des prompts
Utilisez le même ensemble de tâches que celui employé pour benchmarker des modèles AI sur du travail réel→. Le test du cache ajoute des mutations contrôlées du préfixe et la comptabilisation de l’infrastructure.
1. Figez un workload représentatif
Choisissez 30 à 100 tâches issues du trafic de production ou d’un jeu de replay respectueux de la confidentialité. Préservez la distribution réelle des longueurs de préfixe, des longueurs de suffixe, des longueurs de sortie, des tools, des documents et de la concurrence. Définissez la réussite d’une tâche avant d’exécuter le test.
N’optimisez pas sur un seul long prompt de démonstration. Un workflow de support favorable au cache et un workflow de recherche défavorable au cache peuvent avoir une économie opposée.
2. Séparez le contenu stable et volatil
Étiquetez chaque segment du prompt :
Construisez un assembleur de prompts déterministe. Enregistrez une version opaque du préfixe ou un hash clé afin que chaque requête identifie le préfixe qu’elle a tenté de réutiliser. Ne placez pas de secrets ni de contenu client brut dans les logs.
3. Exécutez une matrice contrôlée
Pour chaque classe de tâches, mesurez :
| Essai | Modification | Question à laquelle il répond |
|---|---|---|
| --- | --- | --- |
| À froid | Nouveau préfixe sans état réutilisable | Quel est le coût de base de l’écriture ou du prefill ? |
| À chaud | Préfixe éligible identique | Le fournisseur ou le moteur signale-t-il une lecture ? |
| Mutation précoce | Modifier un token près du début | Quelle part de la réutilisation disparaît ? |
| Mutation tardive | Modifier uniquement le suffixe | Le préfixe stable reste-t-il réutilisable ? |
| Limite de TTL | Répéter avant et après l’expiration | À quelle fréquence le trafic de production arrivera-t-il à temps ? |
| Concurrence | Augmenter progressivement les requêtes parallèles | L’éviction ou la planification réduisent-elles la réutilisation ? |
| Changement de version | Modifier le modèle, les tools ou le template | Quels déploiements invalident le cache ? |
Effectuez suffisamment de répétitions pour rapporter des distributions plutôt qu’une seule valeur de latence. Séparez le time to first token p50 et p95 de la latence de bout en bout.
4. Enregistrez facturation et qualité ensemble
Capturez :
La réutilisation d’un état pour un préfixe exact doit éviter le calcul de prefill répété ; elle ne dispense pas d’un contrôle qualité. Un changement de modèle, de niveau de quantification, de politique de routage ou de stack de serving peut modifier la qualité des sorties même lorsque le mécanisme de cache fonctionne correctement.
5. Calculez trois visions des coûts
Si l’option locale dépend d’une utilisation soutenue, testez cette hypothèse d’utilisation. Un achat de GPU ne devient pas rentable parce qu’un tableur attribue chaque heure inactive à une demande future.
API cloud, GPU local ou routage hybride ?
La décision est rarement binaire.
Préférez une API avec cache lorsque
Préférez une capacité locale partagée lorsque
Utilisez le routage hybride lorsque
Les endpoints gratuits ou subventionnés peuvent aider pour les prototypes, mais ils ne suppriment pas le besoin de comptabiliser le workload. L’étude de cas sur l’API de modèles AI gratuits→ constitue un bon point de départ pour séparer le prix d’accès de la fiabilité en production.
La sécurité du cache des prompts nécessite son propre test
La mise en cache crée une temporisation dépendante des données : un préfixe réutilisé peut renvoyer son premier token plus rapidement qu’un cache miss. Un audit ICML 2025 a utilisé des mesures de timing pour tester de vraies API et rapporté des indices de partage du cache entre utilisateurs chez sept fournisseurs pendant la période étudiée.
Ce résultat constitue un élément historique et spécifique à certains fournisseurs. Il ne permet pas d’établir comment ces services isolent leurs caches aujourd’hui.
Demandez aux fournisseurs actuels et aux responsables de la plateforme interne :
Pour les systèmes self-hosted, incluez des tests de timing et d’éviction entre tenants. Ne journalisez pas les préfixes sensibles réutilisables simplement pour déboguer le cache. Stockez des hashes, des décomptes de tokens, des identifiants de version et des métadonnées conformes aux règles de sécurité.
La checklist de décision
N’approuvez pas un achat de GPU ou une migration d’API sur la seule base des prix catalogue. Exigez :
La mise en cache des prompts est précieuse parce que le contexte répété est courant. Elle est dangereuse comme raccourci d’achat parce que la réutilisation dépend du workload. Mesurez le préfixe, mesurez les cache miss, puis comparez le coût total.
Vérification des affirmations
| Affirmation importante | Type de preuve | Vérification et limite |
|---|---|---|
| --- | --- | --- |
| L’étude sur l’agent de programmation a rapporté un taux de cache-hit des prompts de 99,3 % | Recherche primaire, preprint de juillet 2026 | Un développeur, une base de code, deux périodes séquentielles ; le résultat n’est pas transposable |
| L’article a rapporté 0,573 $/M de tokens API traités contre 2,83 $/M pour l’allocation locale partagée | Recherche primaire | L’API a traité 16 fois plus de tokens et l’utilisation locale était faible ; les dépenses totales et le TCO sont des comparaisons plus solides |
| La capacité locale partagée a réduit le TCO de 40,1 %, tandis que la capacité dédiée coûtait 43,8 % de plus | Recherche primaire | Dépend des hypothèses de l’article concernant le matériel, l’allocation, le marché taïwanais, la main-d’œuvre et la qualité |
| La mise en cache des préfixes réutilise l’état d’attention pour les segments répétés des prompts | Recherche primaire évaluée par les pairs et documentation officielle des moteurs | Elle réduit le travail de prefill répété ; le décodage et le traitement du suffixe variable restent nécessaires |
| Les écritures de cache de 5 minutes d’Anthropic coûtent 1,25× et les lectures 0,1× l’entrée de base | Documentation officielle vérifiée le 30 juillet 2026 | Les prix et les modèles pris en charge peuvent changer ; l’exemple exclut la sortie, le suffixe et le stockage |
| La mise en cache implicite de Gemini est activée par défaut pour Gemini 2.5 et les modèles plus récents dans l’Interactions API | Documentation officielle mise à jour le 7 juillet 2026 | Les nombres minimaux de tokens et la prise en charge du cache explicite diffèrent selon l’API et le modèle |
| TokenPilot a rapporté des réductions de coûts de 56 % à 87 % dans les configurations testées | Recherche primaire, preprint en cours | Deux benchmarks et une intégration spécifique ; une réplication indépendante est nécessaire |
| Le timing du cache des prompts peut exposer des informations lorsque la portée du cache traverse les utilisateurs | Recherche primaire ICML 2025 | Audit historique des fournisseurs testés ; ne pas en déduire le comportement actuel des fournisseurs |