1114AWS ML Blog
Optimisation des coûts et de la latence grâce à la mise en cache des prompts sur Amazon Bedrock
Amazon Web Services a détaillé dans un billet technique le fonctionnement du prompt caching (mise en cache d'invites) sur Amazon Bedrock, une fonctionnalité qui peut réduire jusqu'à 90 % le coût des tokens d'entrée facturés aux modèles de fondation lorsqu'un même contexte est envoyé de façon répétée. L'exemple cité est parlant : un contrat de 10 000 tokens accompagné de 50 questions différentes génère, sans cache, 500 000 tokens d'entrée facturés au plein tarif, alors que le modèle a déjà traité ce contenu. Techniquement, la fonctionnalité s'appuie sur un marqueur cachePoint inséré dans les requêtes via l'API Converse : si le contenu qui précède ce marqueur correspond à une entrée déjà en cache (cache hit), le modèle saute le retraitement de ces tokens ; sinon (cache miss), il traite l'intégralité du contenu et l'enregistre pour de futures requêtes. Les entrées de cache sont limitées à un compte AWS et une région donnés, avec des seuils minimaux de tokens par point de contrôle, 1 024 tokens pour Claude Sonnet 4.5 et Sonnet 4.6, 4 096 pour les modèles Opus, et une durée de vie par défaut de cinq minutes, extensible jusqu'à une heure selon les modèles. Côté tarification, les tokens écrits en cache coûtent 25 % de plus qu'un token d'entrée standard, voire deux fois plus avec une durée de vie d'une heure, tandis que les tokens lus depuis le cache coûtent 90 % de moins. La syntaxe reste identique pour les familles Anthropic Claude et Amazon Nova. Cette optimisation vise directement les entreprises qui déploient des applications d'IA générative à grande échelle, où les coûts de tokens deviennent vite prohibitifs dès qu'un même document, une même définition d'outils ou un même prompt système est réutilisé sur de nombreuses requêtes. Les alternatives existantes, raccourcir les prompts, réduire la fenêtre de contexte ou mettre en place un cache applicatif, impliquent toutes des compromis : perte de qualité de contexte, capacité de raisonnement amoindrie sur des documents longs, ou inefficacité dès que la question change alors que le contexte reste identique. En traitant le problème au niveau de l'infrastructure, sans modifier le modèle ni la qualité du prompt, Amazon Bedrock réduit à la fois la latence, mesurée par le temps avant le premier token généré, et la facture, ce qui rend économiquement viables des cas d'usage comme l'analyse de longs documents juridiques ou financiers, les agents conversationnels à personas complexes, ou les workflows agentiques s'appuyant sur de nombreuses définitions d'outils. Cette annonce s'inscrit dans la compétition croissante entre fournisseurs de cloud autour de la maîtrise des coûts d'inférence, alors que les usages en production se multiplient et que les architectures se complexifient, notamment avec la montée des agents autonomes et des applications multi-tenants. Le billet d'AWS détaille six scénarios concrets avec l'API Converse : la mise en cache de documents longs pour des analyses multi-questions, celle de prompts système et de personas, celle de schémas d'outils pour les workflows agentiques, l'attribution de durées de vie différenciées selon les niveaux de contenu, l'isolation du cache par client dans les applications multi-tenants, et l'intégration avec le framework LangChain. Ces choix reflètent les priorités actuelles des équipes qui développent en production avec de grands modèles de langage : réduire les coûts sans dégrader la qualité des réponses, tout en gérant la complexité croissante des contextes envoyés aux modèles. D'autres fournisseurs de modèles proposent déjà des mécanismes similaires directement via leurs propres API, signe que la mise en cache de contexte devient un standard de facto pour quiconque exploite des modèles de fondation à grande échelle.
