Amazon Bedrock lit un préfixe mis en cache avec environ 90 % de réduction, mais une écriture en cache coûte plus cher qu'un token d'entrée normal, donc un cache qui ne reçoit jamais de hit rend votre facture pire, pas meilleure. La fonctionnalité est disponible en général depuis avril 2025, et la durée de cache d'une heure lancée en janvier 2026 la rend utile pour des sessions entières et des jobs batch. La plupart des équipes la laissent désactivée, ou l'activent au mauvais endroit et paient silencieusement une prime. La remise est réelle. La capturer dépend entièrement de l'endroit où vous placez le point de rupture du cache.

Le modèle mental qui piège les gens consiste à traiter le cache comme une accélération gratuite que l'on saupoudre. Ce n'est pas gratuit. Chaque point de contrôle de cache est un pari que les tokens qui le précèdent seront renvoyés, inchangés, avant que le cache n'expire. Gagnez le pari et vous payez un dixième du prix de lecture. Perdez-le et vous avez payé une prime d'écriture pour rien.

Comment fonctionne réellement la tarification

Trois classes de tokens comptent, et elles sont tarifées différemment :

  • Écriture en cache : la première fois que Bedrock stocke un préfixe, ces tokens sont facturés au-dessus du tarif d'entrée normal. Sur les modèles Anthropic, l'écriture coûte environ 1,25x l'entrée de base pour la courte durée de cache et environ 2x pour la durée d'une heure.
  • Lecture en cache : chaque requête ultérieure qui correspond au préfixe stocké lit ces tokens à environ 0,1x, l'économie phare de 90 %.
  • Entrée non mise en cache : tout ce qui suit le dernier point de contrôle de cache, facturé au tarif normal à chaque fois.

La prime d'écriture est tout le jeu. Vous prépayez pour rendre les futures lectures moins chères. Le point d'équilibre est simple : il vous faut assez de hits sur un préfixe mis en cache pour rembourser le supplément payé pour l'écrire. Une écriture plus une lecture peut coûter plus cher que deux appels ordinaires. Les économies ne s'accumulent que quand le même préfixe est lu de nombreuses fois.

Où placer le point de rupture

Un point de contrôle de cache dit : « tout ce qui précède ce point est stable, stockez-le ». Placez-le donc après les parties du prompt qui ne changent pas entre les appels, et avant celles qui changent. Dans un assistant typique, cet ordre est :

[ system prompt        ]  stable
[ tool / function defs ]  stable
[ retrieved context    ]  semi-stable, per session
---- cache checkpoint here ----
[ conversation history ]  grows every turn
[ user's new message   ]  changes every turn

Le system prompt et les définitions d'outils sont identiques à chaque appel, ils appartiennent donc à l'intérieur du préfixe mis en cache. Le nouveau tour de l'utilisateur ne se répète jamais, il appartient donc à l'extérieur. Le contexte récupéré se trouve au milieu : mettez-le en cache si les mêmes documents sont réutilisés tout au long d'une session, laissez-le non mis en cache si chaque appel récupère quelque chose de nouveau. Vous vous trompez dans cet ordre, placez le point de contrôle avant les définitions d'outils, et vous ne mettez presque rien en cache tout en payant pour l'écrire.

Quand un miss coûte plus cher que l'absence de cache

Les hits de cache nécessitent une correspondance exacte du préfixe, octet pour octet, et l'entrée doit encore être active. Vous perdez le pari de trois manières courantes :

  • Vous modifiez le préfixe. Injecter un horodatage, un ID de requête, ou une salutation personnalisée près du haut du system prompt change les octets, donc chaque appel est une écriture fraîche et jamais une lecture. C'est l'autogoal le plus courant.
  • Le trafic est trop espacé pour le TTL. Si les requêtes arrivent plus espacées que la durée de vie du cache, chacune écrit et expire avant l'arrivée de la suivante. La durée d'une heure a beaucoup élargi cette fenêtre, mais un endpoint à faible trafic peut quand même rater à chaque fois.
  • Le préfixe est en dessous du minimum. Bedrock ne met en cache que les préfixes au-delà d'un seuil de tokens propre à chaque modèle. Un system prompt court peut ne pas être cachable du tout, donc le point de contrôle est ignoré et vous ne gagnez rien.

Dans chaque cas, vous payez soit la prime d'écriture sans lectures pour l'amortir, soit vous ne payez rien de plus mais n'économisez rien non plus tout en pensant avoir optimisé. Les deux valent moins qu'une décision lucide de laisser le cache désactivé pour ce chemin.

Un moyen rapide de savoir si ça fonctionne

Ne supposez pas que le cache est chaud. Les réponses Converse et InvokeModel rapportent les compteurs de tokens de lecture et d'écriture de cache dans leurs champs d'usage. Enregistrez-les et observez le ratio. Un chemin mis en cache sain montre un flux faible et constant d'écritures et un grand volume de lectures. Si les écritures et les lectures se suivent un pour un, votre préfixe n'est pas stable et vous payez la prime pour un cache que personne ne touche. Corrigez le préfixe ou désactivez le point de contrôle.

# usage block to watch on every response
cacheWriteInputTokens  -> should be rare after warmup
cacheReadInputTokens   -> should dominate on a hot path
inputTokens            -> only the tail after your checkpoint

À retenir

Le prompt caching sur Bedrock n'est pas un interrupteur que vous activez pour une remise gratuite de 90 %. C'est une remise prépayée : vous payez une prime d'écriture d'avance et la remboursez par des lectures répétées d'un préfixe inchangé. Placez le point de contrôle après le system prompt et les définitions d'outils stables, gardez tout ce qui est volatile hors de la région mise en cache, et enregistrez le ratio lecture/écriture pour prouver que le pari rapporte. Bien fait, c'est la plus grande économie la moins chère disponible sur Bedrock. Fait à la légère, c'est une ligne budgétaire qui aggrave votre facture tout en ayant l'air d'une optimisation.

À lire ensuite

Pour le playbook plus large d'optimisation des coûts sur AWS, les notes de terrain cloud se trouvent sur ercan.cloud, et le hub est sur ercanermis.com.