Analyse approfondie · Environ 7 min de lecture
AWS détaille le cache de prompts des agents Bedrock : préfixes stables et exemples de coûts distincts
Le guide associe préfixe partagé explicite et historique implicite, en distinguant outils, agents auxiliaires, coûts modélisés et suivi selon le point de terminaison.
- Publié ici
- Date de la source
- Source vérifiée
Le guide technique de Claudio Mazzoni publié par AWS le 26 octobre explique la réutilisation du calcul avec les modèles OpenAI sur Amazon Bedrock. Il ne constitue pas une annonce de nouveau modèle. Notre analyse s’appuie sur le texte complet et ses graphiques ; AISubHub n’a exécuté aucun code ni mesuré indépendamment coût, latence ou disponibilité.
Écouter les actualités
Écoutez cet article ou poursuivez la lecture des actualités.
Préparation de la lecture…
Voix de l’appareil
La voix est traitée par votre navigateur ou appareil. AISubHub n’envoie pas le texte à une API audio. Les voix et la lecture écran verrouillé dépendent de l’appareil.
La reprise peut répéter une courte phrase.
En bref
- Un préfixe exige au moins 1 024 tokens ; AWS indique une durée minimale de 30 minutes renouvelée par une réutilisation réussie, et une écriture à 1,25 fois le tarif normal d’entrée.
- La figure 4 montre un coût relatif de 0,38 pour une configuration implicite et 0,39 pour les points mobiles, contre 1,00 sans cache : des résultats propres à cette charge.
- Un autre exemple modélisé part de 8 000 tokens et ajoute 2 000 tokens sur chacun de six tours : 0,87 USD sans cache, 0,50 en statique et 0,32 avec points mobiles.
1. Réutiliser le calcul ne crée pas une mémoire permanente
L’agent renvoie normalement outils, instructions et échanges antérieurs. Le prefill construit l’état des clés et valeurs ; le cache réutilise un préfixe correspondant puis traite le nouveau suffixe. Les tokens doivent être identiques : il faut stabiliser sérialisation et ordre des outils, en plaçant dates, noms et identifiants variables après le préfixe réutilisable.
Les marqueurs explicites fixent une borne partagée après outils et instructions ; le mode implicite suit les fins de conversation admissibles. Les deux se combinent, avec au moins 1 024 tokens. Dans les exemples, store=False laisse l’historique à l’application sans désactiver le cache. Cette optimisation n’est pas une mémoire persistante et n’autorise pas à supprimer l’historique nécessaire à la requête.
2. Conserver les bornes précédentes quand l’historique grandit
La boucle ajoute les sorties du modèle et les résultats correspondants des outils, raisonnement chiffré compris, sans modifier les anciens messages. En mode uniquement explicite, elle marque le dernier lot et conserve les anciennes bornes. Une borne statique seule retraite l’historique suivant ; déplacer une borne unique sur le dernier tour peut aussi perdre la réutilisation. Une fin implicite après une tâche ne garantit pas un préfixe partagé plus court pour une autre tâche.
La figure 4 porte sur six tours d’outils avec GPT-6 Astra, environ 2 000 tokens de résultats d’outils par tour. Le coût relatif d’entrée est 0,38 pour la configuration implicite montrée, 0,39 pour les bornes mobiles, 0,61 en statique et 0,72 avec le seul dernier tour marqué, contre 1,00 sans cache. Les baisses approximatives de 62 % et 61 % concernent ces configurations, pas les 64 % modélisés de la figure 9.
3. Modifier les appels possibles sans réécrire le catalogue
Pour les outils connus, le guide garde le même TOOLS trié et modifie allowed_tools dans tool_choice. auto laisse le modèle décider d’un appel autorisé ; required exige au moins un appel parmi les outils permis. Le catalogue mis en cache reste inchangé. AISubHub y voit une organisation du prompt, pas la preuve que les autorisations et l’exécution de l’application sont sécurisées.
Pour un ajout en cours de session, AWS indique que Runtime et Mantle acceptent additional_tools pour GPT-6 Astra, GPT-6.1 Sol et GPT-5.6 Luna. Le schéma est ajouté à l’historique, le catalogue initial reste stable et cet élément est conservé ensuite. additional_tools ne peut pas porter une borne : l’exemple uniquement explicite la place dans un bloc input_text ultérieur et conserve les anciennes. Des rôles différents utilisent des catalogues stables distincts ; aucune disponibilité universelle par modèle ou région n’est établie.
4. Préchauffer avant de répartir le travail entre auxiliaires
La requête ordinaire de préchauffage doit finir avant les appels parallèles. Elle et les auxiliaires marquent le préfixe partagé, même en mode implicite, avec les mêmes outils, modèle et clé. Les compteurs vérifient d’abord l’activité du cache. Un résumeur peut copier l’historique complet du parent et ajouter sa consigne sans modifier l’original ; cela ne crée pas automatiquement une nouvelle borne en cache.
La réutilisation exige mêmes modèle, compte AWS, Region, clé et préfixe, avec une entrée encore disponible. Une clé propre à chaque session sépare des sessions identiques ; une clé stable autorise le partage prévu. AWS annonce au moins 30 minutes après la dernière écriture ou réutilisation réussie, parfois davantage. Rafraîchir a aussi un coût : ni durée ni clé ne garantissent la permanence ou ne font d’une séparation comptable une protection de sécurité.
5. Distinguer coût modélisé et facture de production
La figure 9 modélise un agent de support GPT-6 Astra avec un préfixe de 8 000 tokens et six tours ajoutant chacun 2 000 tokens. Avec les hypothèses de tarifs à la demande du guide, l’entrée cumulée atteint 0,87 USD sans cache, 0,50 avec borne statique et 0,32 avec bornes mobiles. Les 64 % appartiennent à cet exemple modélisé, pas à la figure 4 ni à un déploiement testé par AISubHub.
L’écriture coûte 1,25 fois l’entrée normale ; le prix de lecture dépend du modèle. Des tâches courtes ou des préfixes changeants pourraient ne pas amortir écriture et préchauffage. L’auteur recommande de confronter ces dépenses aux économies de lecture. Les tokens de sortie sont exclus du calcul des parts du coût d’entrée, mais ajoutés séparément à la facture totale. Ces montants illustratifs ne sont ni un devis actuel ni une baisse garantie des dépenses globales.
6. Choisir les bons compteurs et maintenir la gouvernance
usage expose cached_tokens et cache_write_tokens. Runtime fournit aussi CacheReadInputTokenCount et CacheWriteInputTokenCount dans CloudWatch ; les journaux d’invocation permettent un examen par requête. Selon le guide, l’espace CloudWatch de Mantle n’a actuellement pas de compteurs de cache séparés : l’application doit enregistrer usage. Cost Explorer regroupe par Usage type pour séparer lectures, écritures et entrées non cachées.
L’auteur avertit que définitions d’outils et prompts système peuvent fuiter ou être exploités et demande une gouvernance incluant le cache. Notre lecture impose des contrôles propres sur partage, permissions et suivi ; le texte ne démontre ni incident précis ni défense complète contre les fuites. Nous n’avons pas examiné indépendamment les documents liés ou exécuté les exemples. Modèle, point de terminaison, région, coût et latence restent à vérifier dans chaque environnement.
Pourquoi cela compte
La distinction utile sépare préfixe partagé stable, historique enrichi uniquement par ajout et partage intentionnel entre auxiliaires. Les économies dépendent de ces frontières et des lectures et écritures observées, au-delà de l’activation du cache.
Limites et disponibilité
Analyse fondée sur le guide officiel complet et les graphiques nécessaires. Résultats de charge et coûts modélisés sont des preuves différentes attribuées à AWS. Aucun test indépendant du code, des documents complémentaires, des prix actuels ou du déploiement.
Sources et preuves
Date de la source: · Source vérifiée:
Articles assistés par IA, vérifiés avec les sources primaires citées. Les affirmations des fournisseurs sont attribuées ; la présence ne vaut pas recommandation.