Prompt caching Bedrock : -90 % sur les tokens d'entrée

AWS a publié le 15 septembre 2026 un guide d'ingénierie sur le prompt caching Amazon Bedrock : comment réutiliser, d'une requête à l'autre, la partie stable d'un prompt (system prompt, documents, définitions d'outils) au lieu de la refaire calculer par le modèle. La promesse chiffrée est nette : jusqu'à 90 % de réduction du coût des tokens d'entrée mis en cache, et un temps jusqu'au premier token qui baisse à mesure que le préfixe caché grossit.

Pour une équipe qui exploite des agents ou un RAG en production, ce n'est pas une optimisation cosmétique. La facture d'un système d'agents est dominée par les tokens d'entrée, parce que chaque tour renvoie au modèle le même contexte : les mêmes instructions, les mêmes outils, les mêmes documents. Le prompt caching Bedrock s'attaque précisément à cette redondance.

Le contexte

Un modèle de langage n'a pas de mémoire entre deux appels. À chaque requête, l'application renvoie l'intégralité du contexte, et le fournisseur facture chaque token d'entrée comme s'il était nouveau. Sur un assistant documentaire qui répond à dix questions sur le même PDF de 10 000 tokens, ces 10 000 tokens sont traités et facturés dix fois.

Le prompt caching consiste à conserver, côté fournisseur, l'état de calcul intermédiaire d'un préfixe de prompt pour ne pas le recalculer. Anthropic l'a introduit sur son API en 2024 ; Bedrock l'expose de façon uniforme pour plusieurs familles de modèles via l'API Converse. Le billet d'AWS, écrit par des architectes solutions, documente le mécanisme, sa tarification et six patrons d'usage, avec du code testé sur Claude Sonnet 4.5.

Comment fonctionne le cache : checkpoints, minimums, TTL

Le bloc cachePoint

Dans l'API Converse, on marque la fin de la zone à cacher avec un bloc de contenu cachePoint. Tout ce qui précède le checkpoint est mis en cache ; tout ce qui suit reste dynamique :

content = [
    {"text": "<document stable>"},
    {"cachePoint": {"type": "default"}},
    {"text": "<question de l'utilisateur>"},
]

La syntaxe est la même pour Anthropic Claude et Amazon Nova, ce qui compte quand on route plusieurs modèles derrière une passerelle. Un seul cachePoint peut couvrir plusieurs blocs de contenu qui le précèdent : il n'est pas nécessaire d'en poser un par document.

Des minimums par modèle

Un checkpoint n'est honoré que si le préfixe atteint une taille minimale, propre à chaque modèle : 1 024 tokens pour Claude Sonnet 4.5 et 4.6, 4 096 tokens pour les modèles Opus. En dessous, la requête passe sans cache et sans erreur, ce qui est piégeux : l'application croit cacher et ne cache rien. Les champs cacheWriteInputTokens et cacheReadInputTokens de l'objet usage de la réponse sont le seul moyen fiable de le vérifier.

Durée de vie

La durée de vie par défaut est de 5 minutes ; certains modèles acceptent 1 heure ({"cachePoint": {"type": "default", "ttl": "1h"}}). Une même requête peut mélanger plusieurs TTL, à une condition : les checkpoints doivent être ordonnés du plus long au plus court. Un contexte d'entreprise qui change rarement va en tête avec 1 heure, le contexte de session derrière avec 5 minutes.

La tarification, et ce qu'elle implique

Le cache n'est pas gratuit à l'écriture. AWS donne trois règles :

• Écriture en cache : 25 % plus cher que le token d'entrée standard.
• Lecture en cache : 90 % moins cher que le token d'entrée standard.
• Écriture avec TTL d'une heure : 100 % plus cher (le double).

L'exemple du billet est parlant : un document de 10 000 tokens envoyé avec dix questions différentes coûte une écriture, puis neuf lectures à -90 %, soit environ 75 % d'économie nette sur les tokens d'entrée de ce contexte. Le calcul se retourne si le cache expire entre deux appels : chaque requête après expiration déclenche une nouvelle écriture, à 125 % du prix, et l'économie fond. Le prompt caching rapporte quand le contexte est réutilisé vite et souvent ; il coûte quand il est réutilisé rarement.

Deux contraintes de périmètre à connaître avant de projeter des économies : le cache est limité à un compte AWS et à une région, et les profils d'inférence inter-régions (le billet utilise le profil global de Claude Sonnet 4.5) peuvent augmenter la fréquence des écritures, parce que la requête n'atterrit pas toujours dans la région où le cache a été constitué.

Six patrons d'usage, du RAG au multi-tenant

Le billet décline le mécanisme sur six cas :

1. Contenu de message : le document d'un RAG, caché une fois pour toutes les questions qui suivent.
2. System prompt : la définition d'un persona ou d'une politique de réponse, identique à chaque appel.
3. Définitions d'outils : dans un agent, le catalogue d'outils est souvent la partie la plus volumineuse et la plus stable du prompt. Le cacher fait baisser le coût de chaque tour de boucle.
4. TTL mixtes : référentiel d'entreprise à 1 heure, contexte de session à 5 minutes, dans la même requête.
5. Isolation multi-tenant : un préfixe dérivé d'un hachage SHA-256 de l'identifiant du tenant, pour qu'un cache ne serve jamais un autre client.
6. LangChain : ChatBedrockConverse.create_cache_point() insère le checkpoint dans un tableau de messages ou un ChatPromptTemplate.

La latence, avec prudence

Sur le temps jusqu'au premier token, AWS reste mesuré : le gain existe et croît avec la taille du préfixe caché, mais sur de petits documents (2 000 à 5 000 tokens) il peut ne pas être statistiquement significatif sur un petit nombre d'itérations. Autrement dit, ne vendez pas le prompt caching Bedrock sur la latence pour un system prompt de 1 500 tokens ; vendez-le sur le coût, et sur la latence seulement quand le préfixe compte des dizaines de milliers de tokens.

Ce que ça change pour les équipes IA

Le prompt caching Bedrock est une décision d'architecture, pas un flag à activer. Trois conséquences concrètes.

Restructurer les prompts en couches. Pour que le cache serve, tout ce qui est stable doit précéder tout ce qui change, et le préfixe doit dépasser le minimum du modèle. Un prompt qui intercale la date du jour ou l'identifiant de session au milieu du system prompt casse le préfixe et perd le cache. L'ordre des blocs devient une règle de code revue, avec un test qui vérifie que cacheReadInputTokens est non nul sur la deuxième requête.

Instrumenter le taux de hit. Sans observabilité, on ne sait pas si l'on paie des écritures à 125 % pour rien. Les deux compteurs de l'objet usage doivent remonter dans les traces et les tableaux de bord, par agent et par tenant : taux de lecture, ratio écriture/lecture, coût effectif par tour. C'est exactement le genre de métrique que nous ajoutons dans une mise en production d'agent, à côté de la latence et du coût par requête.

Choisir la TTL avec la courbe d'usage. Un assistant interne sollicité toute la journée sur le même référentiel justifie la TTL d'une heure malgré son écriture à 200 %. Un chatbot public dont les sessions durent trois minutes n'en tirera rien : 5 minutes suffisent, et le contexte partagé entre utilisateurs (system prompt, outils) doit être séparé du contexte par session pour être caché indépendamment. Le patron multi-tenant par hachage est à adopter dès qu'un même déploiement sert plusieurs clients : c'est une question de sécurité autant que de coût.

Enfin, le prompt caching change l'arbitrage classique « prompt court ou prompt riche ». Un catalogue d'outils détaillé ou un guide de style de 8 000 tokens devient abordable dès que le cache est chaud, et la vraie variable n'est plus la taille du préfixe mais la fréquence de sa réutilisation.

En bref

• Le prompt caching Bedrock réutilise le préfixe stable d'un prompt via un bloc cachePoint dans l'API Converse, identique pour Claude et Nova.
• Minimums par checkpoint : 1 024 tokens (Claude Sonnet 4.5/4.6), 4 096 tokens (Opus). TTL 5 minutes par défaut, 1 heure sur certains modèles, ordonnées du plus long au plus court.
• Prix : écriture +25 %, lecture -90 %, écriture 1 h +100 %. Un document réutilisé dix fois économise environ 75 % de ses tokens d'entrée.
• Gain de latence réel mais dépendant de la taille du préfixe ; peu mesurable sous 5 000 tokens.
• Cache limité au compte et à la région ; les profils inter-régions augmentent les écritures ; isoler les tenants par hachage.

Vous industrialisez vos agents IA ? SeedVision propose des audits IA en 3-5 jours et des forfaits de mise en production de 15 à 30 jours. Voir les packages ou réserver un appel de 30 min.

Source : Optimizing cost and latency with Amazon Bedrock prompt caching (AWS Machine Learning Blog, 15 septembre 2026) et la documentation Bedrock sur le prompt caching.

Photo de couverture : Photo by Albert Stoynov on Unsplash.