Jour de la chèvre terrestre pour les agents d’IA : Patterns de stockage des prompts pour utiliser les modèles OpenAI sur Amazon Bedrock

Chaque fois que vous lancez votre agent, il doit relire toute son histoire de vie avant d’agir. Voici comment le faire se souvenir sans avoir besoin de lui fournir le même contexte à nouveau.

Dans le film Groundhog Day, le personnage de Bill Murray vit chaque jour le même événement du 2 février. Il se réveille avec la même chanson diffusée à la radio, dans le même auberge, et dans la même petite ville, encore et encore, pendant ce que certains fans de cinéma estiment être 34 ans.

Rien de ce qu’il a accompli la veille ne se transmet, à moins qu’il ne le réapprene de zéro. Les agents IA vivent dans une version de « Groundhog Day ». Chaque fois qu’un agent fait un pas (appelle un outil, lit le résultat, décide quoi faire ensuite), il doit envoyer au modèle toute son histoire jusqu’à présent pour maintenir la continuité : les définitions des outils, les instructions, chaque appel précédent à un outil et chaque résultat. Le modèle ne prédit que le prochain token en se basant sur l’entrée que vous fournissez. Il n’a pas de mémoire interne entre les requêtes, il doit donc tout relire à nouveau. À la 20e itération d’une session de codage, le modèle relit les itérations 1–19, et c’est vous qui payez pour chacun de ces tokens, encore et encore.

Le stockage en mémoire du prompt brise le cycle. Le service stocke votre prompt d’entrée (instructions, outils et contenu) et le réutilise lors de la prochaine demande, pour un coût inférieur à une fraction du coût initial.

Dans cet article, je vous explique la vie d’un agent, de sa première tournée jusqu’à l’obtention de nouvelles outils et la création d’aides. En cours de route, je vous montre comment le stockage en mémoire cache permet de réduire les coûts et de maintenir les agents réactifs et cohérents.

Qu’un agent envoie à son LLM

Avant de parler du stockage en cache, il est utile de voir ce que contient la première invocation d’un agent typique vers le grand modèle de langage (LLM) :

• Liste des outils – Les définitions de chaque fonction que l’agent peut appeler. Ces modifications s’appliquent lors de la sortie d’une nouvelle version.
• Instructions – Le prompt du développeur : règles, personnage, politiques, exemples. De plus, les changements varient selon chaque version.
• Histoire – Tout ce qui s’est passé jusqu’à présent dans cette session : la tâche, les appels de l’outil du modèle, et les résultats de l’outil (qui augmentent à chaque tour).
• Nouvelle tour – Le résultat de l’outil le plus récent ou le message utilisateur (qui peut varier à chaque fois).

Ce que l’agent envoie au modèle, tour après tour, si vous ne configurez pas le stockage en cache :

Figure 1 : Ce que l’agent envoie au modèle à chaque tour

Comment le cachement instantané fonctionne en arrière-plan

Lorsqu’un modèle lit un prompt, il effectue d’abord une opération appelée prefill. Pendant le prefill, il traite chaque token d’entrée et construit ses vecteurs clé-vale (appelés KV), qui constituent l’état de fonctionnement du modèle. Cela se produit avant que le modèle n’écrive son premier token.

Le stockage en cache du prompt conserve cet état, qui contient le prompt système, les outils, le contenu, l’histoire, etc. Lorsqu’une demande ultérieure commence avec les mêmes tokens d’entrée (c’est-à-dire le même texte), le service de stockage en cache du prompt charge l’état sauvegardé plutôt que de le calculer à nouveau. Il ne traite alors que ce qui est nouveau dans la prochaine donnée au modèle. Le stockage en cache du prompt peut être implicite, où Amazon Bedrock détermine où se termine le préfixe réutilisable, ou explicite, où votre code marque cet point d’arrêt via prompt_cache_breakpoint. Vous pouvez utiliser les deux approches ensemble, et nous recommandons de le faire.

Le tour 1 par rapport au tour 2

Figure 2 : La tour 1 conserve le préfixe du prompt jusqu’au point de rupture, et la tour 2 l’utilise à nouveau et paie le prix complet uniquement pour la nouvelle question

Implicite ou explicite, et pourquoi avons-nous besoin des deux ?

Pour les charges de travail agentiques, le stockage implicite permet à Bedrock de choisir ce qui sera stocké au fur et à mesure que la conversation se développe. Avec le stockage explicite, vous pouvez marquer le contenu partagé, comme les outils et les instructions, afin de l’utiliser à nouveau entre les sessions et lors de l’initialisation des agents auxiliaires. Vous n’avez pas toujours besoin des deux formes de stockage, mais en les combinant, vous obtenez un point de départ réutilisable, tandis que Bedrock gère automatiquement la conversation en croissance.

Les nouvelles sessions peuvent également réutiliser ce point de départ partagé, tandis que chaque conversation s’appuie sur son propre historique enregistré en cache. Dans cet article, nous commençons avec la première étape, puis montrons comment transmettre le contenu enregistré en cache lors des échanges ultérieurs, des nouveaux outils et entre les sous-agentes.

Bonjour, monde stocké en cache

La première victoire consiste à stocker en cache la partie statique du prompt : les outils et instructions qui restent inchangés entre les requêtes. Ces exemples utilisent votre client Amazon Bedrock existant, TOOLS et task. Remplacez la chaîne abrégée INSTRUCTIONS par vos politiques et exemples réels. Le préfixe réutilisable doit atteindre 1 024 tokens pour être valide.

Lors de la mise en cache du contenu statique, utilisez le mode explicite : choisissez où se termine le préfixe sauvegardé.

KEY = "support-agent:v7:gpt-6-astra"
INSTRUCTIONS = "Your full support policies and examples..."

# Rendered context: [provider context][TOOLS][INSTRUCTIONS] | [task]
# Cache starts at the beginning; the marker below chooses its end.
resp = client.responses.create(
    model="us.openai.gpt-6-astra",
    store=False,  # Response storage; prompt caching still works.
    include=["reasoning.encrypted_content"],
    prompt_cache_key=KEY,
    prompt_cache_options={"mode": "explicit", "ttl": "30m"},
    tools=TOOLS,  # Rendered before instructions; keep order stable.
    input=[
        {
            "role": "developer",
            "content": [{
                "type": "input_text",
                "text": INSTRUCTIONS,
                # Save through this whole block, including TOOLS.
                "prompt_cache_breakpoint": {"mode": "explicit"},
            }],
        },
        # User message is processed but not cached.
        {"role": "user", "content": task},
    ],
)

Le prompt_cache_key indique au service quelles requêtes doivent partager une cache. Nous reviendrons sur son utilisation lors de la lecture de la cache dans de nouvelles sessions. Dans l’un de nos tests utilisant le stockage explicite de la cache, les outils et instructions préfixés par « tools-and-instructions » comprenant environ 4 000 tokens ont écrit 4 120 tokens lors de la première requête, et ces 4 120 tokens ont été lus lors des requêtes ultérieures. La task (ou la requête utilisateur) se situe après la limite de la cache, donc cela ne déclenche pas une écriture dans la cache.

Gardez à l’esprit que le stockage en cache du prompt fonctionne uniquement lorsque vous passez exactement le même texte. Assurez-vous que les instructions de l’agent et la liste des outils sont serialisées de la même manière à chaque fois. Les serveurs du protocole de contexte de modèle (MCP) et autres formes de livraison d’outils doivent être indexés pour garantir leur cohérence. Gardez tout ce qui varie, comme la date, le nom de l’utilisateur ou un ID de demande, après les instructions stockées en cache.

Comme le contenu augmente et varie (différents outils et contenus), utilisez le mode implicite pour permettre au service de suivre la conversation. Ici, la première demande n’a pas de marque explicite. Son message le plus récent est la tâche de l’utilisateur, donc le point de rupture automatique survient après cette tâche et couvre les outils, les instructions et la tâche dans son ensemble. Le mode est indiqué explicitement dans l’exemple suivant pour clarté, bien que le mode implicite soit par défaut. Lorsque vous définit store=False, l’histoire de conversation reste dans votre application. Cela ne désactive pas le stockage en cache.

def ask_with_implicit_cache(history):
    return client.responses.create(
        model="us.openai.gpt-6-astra",
        store=False,
        include=["reasoning.encrypted_content"],
        prompt_cache_key=KEY,
        prompt_cache_options={"mode": "implicit", "ttl": "30m"},
        tools=TOOLS,
        input=history,  # Everything gets cached
    )

history = [
    {"role": "developer", "content": INSTRUCTIONS},
    {"role": "user", "content": task},
]
# Automatic endpoint: the end of the user message.
resp = ask_with_implicit_cache(history)

Cela est utile lorsque la prochaine étape continue la même tâche. Une tâche différente ne correspond pas au préfixe de la tâche précédente, et l’écriture implicite ne crée pas nécessairement une entrée distincte uniquement pour les outils et instructions. Utilisez un marqueur explicite là où vous avez besoin que ce préfixe partagé soit réutilisable entre les tâches.

Utilisez les deux lorsque l’agent a besoin d’un point de départ partagé et d’une histoire en croissance. Commencez avec le bloc développeur marqué dans l’exemple de code suivant et appelez la fonction ask_with_implicit_cache. Le mode au niveau du demande reste implicite. Le marqueur au niveau du bloc ajoute un point de sauvegarde explicite après les instructions. Le service peut également enregistrer via le dernier message éligible. Cela garantit que le préfixe partagé reste disponible pendant que la conversation se développe.

history = [
    {
        "role": "developer",
        "content": [{
            "type": "input_text",
            "text": INSTRUCTIONS,
            "prompt_cache_breakpoint": {"mode": "explicit"}, 
        }],
    },
    {"role": "user", "content": task},
]
# Still implicit mode, now with an explicit startup save point in the history.
resp = ask_with_implicit_cache(history)

Mettre en cache le historique de la conversation et les résultats des outils

Le modèle demande des outils par nom et leur argumentation. Votre application doit les exécuter. execute_function est un assistant que vous construisez pour diriger ces requêtes vers les fonctions Python correspondantes et retourner leurs résultats. Le cycle suivant utilise cet assistant pour exécuter chaque outil demandé. Il ajoute la sortie du modèle et tous les résultats des outils à la liste history, puis envoie cette liste à nouveau jusqu’à ce que le modèle fournisse une réponse finale. En mode implicite, Amazon Bedrock peut réutiliser le préfixe inchangé et stocker le contenu ajouté grâce au dernier résultat de l’outil. Les messages antérieurs et le TOOLS initial restent inchangés.

import json

# Map tool names to their Python implementations.
TOOL_HANDLERS = {
    "get_owner": get_owner,
    # Register your other initial tools here.
}

def execute_function(name, arguments):
    """Run the requested tool and return its result."""
    handler = TOOL_HANDLERS.get(name)
    if handler is None:
        return {"error": f"Unknown tool: {name}"}
    return handler(**arguments)

while True:
    # Preserve all output items, including encrypted reasoning.
    history.extend(resp.output)
    calls = [x for x in resp.output if x.type == "function_call"]
    if not calls:
        break
    for call in calls:
        result = execute_function(call.name, json.loads(call.arguments))
        history.append({
            "type": "function_call_output",
            "call_id": call.call_id,
            "output": json.dumps(result),
        })
    # The last result in this group supplies the automatic endpoint.
    resp = ask_with_implicit_cache(history)

Pour les questions complémentaires, ajoutez un nouveau message utilisateur et appelez à nouveau l’assistant. Les messages antérieurs restent inchangés afin que leurs endpoints stockés restent disponibles.

Points de rupture glissants : Chaque tour lit tout ce qui précède

Figure 3 : Points de rupture rotative, où chaque tour lit tout ce qui précède et ne met que le résultat de son propre outil en évidence

Pour une exécution séparée uniquement en mode explicite, reconstituez l’histoire de deux messages à partir de l’exemple combiné « Hello cached world ». Ce cycle enveloppe les résultats du outil dans des blocs input_text et marque le résultat final dans chaque lot. Les marqueurs précédents restent dans history. Consultez les règles de recherche actuelles pour les conversations longues.

import json

while True:
    resp = client.responses.create(
        model="us.openai.gpt-6-astra", store=False,
        include=["reasoning.encrypted_content"],
        tools=TOOLS, prompt_cache_key=KEY, input=history,
        prompt_cache_options={"mode": "explicit", "ttl": "30m"},
    )
    d = resp.usage.input_tokens_details
    print("read", d.cached_tokens, "write", d.cache_write_tokens)
    history.extend(resp.output)  # Includes encrypted reasoning.
    calls = [x for x in resp.output if x.type == "function_call"]
    if not calls:
        break
    batch = []
    for call in calls:
        result = execute_function(call.name, json.loads(call.arguments))
        batch.append({
            "type": "function_call_output", "call_id": call.call_id,
            "output": [{"type": "input_text", "text": json.dumps(result)}],
        })
    # Add the newest boundary; retain every earlier marker.
    batch[-1]["output"][-1]["prompt_cache_breakpoint"] = {"mode": "explicit"}
    history.extend(batch)

GPT-6 Astra est en tête pour le meilleur résultat implicite dans cette charge de travail à six tours : les coûts d’entrée sont environ 62 % plus faibles que lorsque aucun cache n’est utilisé. Les points de rupture rotatives explicites ont permis d’économiser environ 61 % pour le même modèle. Les deux systèmes réutilisent davantage l’histoire à mesure que la conversation se prolonge. Ce sont les résultats liés à la charge de travail. Mesurez les économies de votre propre agent.

Figure 4 : Coût d’entrée de chaque configuration de mise en cache sur GPT-6 Astra, par rapport à aucune mise en cache

Faites attention à :

• Seulement un point de rupture statique en mode explicite uniquement – Les outils et les instructions sont mémorisés, mais l’historique croissant est traité à nouveau à chaque tour (0,61). Cette limitation ne s’applique pas à l’exemple combiné, qui est également sauvegardé à la fin d’une conversation valide.
• Déplacer un seul point de rupture peut empêcher la réutilisation de la mémoire cache et provoquer des écritures répétées en mode uniquement explicite. Gardez également le point de rupture de la tour précédente.
• Seulement une écriture implicite via une tâche en cours de modification – Une nouvelle tâche peut utiliser les outils et les instructions, mais pas l’endpoint précédemment enregistré. Ajoutez un marqueur explicite après les instructions partagées si des tâches différentes doivent réutiliser ce préfixe plus court.

Lorsque les outils changent

Parfois, la liste d'outils d'un agent change, ou de nouveaux outils sont ajoutés. Gardez la liste initiale stable : l'ajout, la suppression ou le réordonnancement des définitions peut rendre invalide le préfixe stocké. Choisissez l'approche qui correspond à la manière dont les outils deviennent disponibles.

Lorsque des outils connus sont invoqués dans différentes étapes du flux de l’agent : Envoyez le même ensemble trié de TOOLS et utilisez allowed_tools pour limiter ce que le modèle peut appeler. Avec allowed_tools, "mode": "auto" permet au modèle de décider s’il doit appeler un outil autorisé, et "mode": "required" exige au moins une appel d’outil autorisé. Transmettez cela sous tool_choice. La restriction ne modifie pas le catalogue en cache :

tool_choice={"type": "allowed_tools", "mode": "auto",
             "tools": [{"type": "function", "name": "get_owner"}]}

Nouveaux outils pendant une session. Tant Amazon Bedrock Runtime que les endpoints Amazon Bedrock Mantle acceptent un type d’élément de entrée appelé additional_tools pour GPT-6 Astra, GPT-6.1 Sol et GPT-5.6 Luna. Pour connaître la disponibilité des modèles selon la région AWS, veuillez consulter Les modèles pris en charge par la région AWS dans Amazon Bedrock. Enregistrez le nouvel outil get_due_date dans la fonction d’aide execute_function, puis ajoutez son schéma à l’histoire complète issue du cycle de l’agent. Conservez le TOOLS initial inchangé :

TOOL_HANDLERS["get_due_date"] = get_due_date
NEW_TOOL = {
    "type": "function", "name": "get_due_date",
    "description": "Return the due date for a support case.",
    "strict": True,
    "parameters": {
        "type": "object",
        "properties": {"case_id": {"type": "string"}},
        "required": ["case_id"], "additionalProperties": False,
    },
}
history.append({
    "type": "additional_tools", "role": "developer",
    "tools": [NEW_TOOL],
})
history.append({
    "role": "user", "content": "Find the due date for case C-123.",
})
# Implicit mode saves through this new user message, including NEW_TOOL.
resp = ask_with_implicit_cache(history)
d = resp.usage.input_tokens_details
print("old prefix read", d.cached_tokens, "new write", d.cache_write_tokens)

# Example output:
# old prefix read 2048 new write 256

Un nouvel outil arrive au milieu de la session

Figure 5 : L’ajout d’un outil permet de réutiliser le préfixe antérieur, avec des exemples de comptes provenant de GPT-6 Astra sur Amazon Bedrock Runtime

Continuez le cycle d'exécution de l'outil avec la nouvelle réponse. Le cycle ajoute les résultats de l'modèle dans history, exécute tous les outils demandés et enregistre leurs résultats. Conservez l'élément additional_tools dans les demandes ultérieures afin que le nouvel outil reste disponible. En mode implicite, Amazon Bedrock peut stocker en cache le message d'utilisateur, y compris les définitions des outils qui le précèdent. En mode explicite uniquement, conservez les points de rupture antérieurs et ajoutez un point de rupture dans un bloc input_text dans ce message d'utilisateur. L'élément additional_tools lui-même ne peut pas contenir un point de rupture.

Différentes rôles, différents catalogues. Lorsque les rôles d’agent différents nécessitent des outils distincts, choisissez un profil d’outil stable, tel que le support ou la facturation, au début de chaque session. Chaque profil possède son propre préfixe enregistré dans le cache. Marquez les instructions partagées afin que les tâches ultérieures utilisant ce profil puissent les réutiliser, puis utilisez soit le mode support soit le mode facturation selon l’évolution de la conversation.

Profils d'outil en cache

Figure 6 : Chaque profil d’outil possède son propre préfixe stocké, pouvant être réutilisé par les sessions correspondantes

Sous-agents et appels secondaires

La délégation ne devrait pas obliger chaque assistant à relire la même information de base. Partagez le préfixe, puis ajoutez les tâches de chaque assistant à la fin. Veillez à ce que, lors de l’utilisation du stockage en cache avec des agents IA, les outils et les prompts du système puissent être volés ou exploités. Mettez en place des pratiques responsables en matière d’IA, incluant la mise en œuvre du stockage en cache des prompts dans cette gestion.

Faire une fois chaud, puis se disperser. Envoyez d’abord une demande ordinaire et attendez qu’elle soit terminée avant de lancer les aides. Marquez explicitement le contexte partagé dans chaque demande, même lorsque le mode est implicite :

shared = {"role": "developer", "content": [{
    "type": "input_text", "text": INSTRUCTIONS,
    "prompt_cache_breakpoint": {"mode": "explicit"},
}]}
warm = client.responses.create(
    model="us.openai.gpt-6-astra", store=False,
    tools=TOOLS, prompt_cache_key=KEY,
    prompt_cache_options={"mode": "implicit", "ttl": "30m"},
    max_output_tokens=16,
    input=[shared, {"role": "user", "content": "Reply READY."}],
)
d = warm.usage.input_tokens_details
if not (d.cache_write_tokens or d.cached_tokens):
    raise RuntimeError("Shared prefix was not cached.")
from concurrent.futures import ThreadPoolExecutor

# helper_tasks contains the task text for each helper.
helper_inputs = [
    [shared, {"role": "user", "content": task}]
    for task in helper_tasks
]
with ThreadPoolExecutor(max_workers=4) as pool:
    helpers = list(pool.map(ask_with_implicit_cache, helper_inputs))

Les aides utilisent les mêmes TOOLS, modèle et KEY que le warm-up. Un warm-up qui se termine à la limite d’échantillonnage peut encore remplir la mémoire cache. Le vérification d’utilisation confirme l’activité de la mémoire cache avant que les aides ne commencent.

Subagents : Chauffer le préfixe partagé une fois, puis se disperser

Figure 7 : Chauffer le préfixe partagé avant de lancer les assistants, et chaque assistant ajoute ensuite sa propre tâche

Donnez aux appels latéraux le même début. Le cycle de l’agent construit history en ajoutant chaque resp.output et les résultats correspondants des outils, y compris les raisonnements chiffrés. Une fois le parent terminé, copiez cette liste complète pour un résumateur ou un juge. Le même assistant conserve les outils, le modèle et la clé inchangés :

from copy import deepcopy

# history is the completed history built by the agent loop above.
# Copy it so the helper can add instructions without changing the parent.
helper_history = deepcopy(history)
helper_history.append({
    "role": "developer",
    "content": "Summarize this conversation in one sentence. Do not call tools.",
})
summary = ask_with_implicit_cache(helper_history)
d = summary.usage.input_tokens_details
print("history read", d.cached_tokens, "write", d.cache_write_tokens)
print(summary.output_text)

# Example output (assumed values and conversation):
# history read 4096 write 32
# Case C-123 is due on October 31, 2026.

L’aidant peut réutiliser la partie stockée dans le history, mais le message développeur ajouté ne prolonge pas automatiquement la cache pour inclure l’instruction de résumé. Si les demandes ultérieures réutilisent la même histoire et instruction, placez l’instruction dans un bloc input_text avec prompt_cache_breakpoint. Pour un résumé unique, aucun marqueur supplémentaire n’est nécessaire.

Pauses, restarts, et la clé de cache

Pauses. Les préfixes stockés ont un délai minimum de 30 minutes (TTL) avant de pouvoir être réutilisés avec succès, et peuvent rester plus longtemps. Si la session se relance rapidement, une préparation ordinaire peut mettre à jour le préfixe avant son expiration. Comparez le coût de cette requête avec celui de la désactivation de la cache. Pour les règles du TTL, consultez la documentation Amazon Bedrock.

Nouvelles sessions. Conservez prompt_cache_key stable pour les requêtes destinées à partager un préfixe. Une clé spécifique à la session isole les sessions, même lorsque leurs prompts sont identiques. Dans l'exemple suivant, passer à une clé partagée permet aux sessions de réutiliser le préfixe.

Les nouvelles sessions réutilisent le cache uniquement si elles partagent la clé

Figure 8 : Une clé spécifique à la session sépare les entrées de la mémoire cache, et une clé partagée permet aux sessions correspondantes de les réutiliser.

La réutilisation du contenu de cache existant nécessite le même modèle, un compte AWS et une région, ainsi qu’un préfixe correspondant disponible. L’exemple suivant combine un marqueur de démarrage explicite avec un mode implicite. Chaque session commence avec les mêmes instructions et sa propre tâche. Les deux utilisent le même identifiant calculé :

import hashlib

def cache_key(app, model, prompt_version, instructions):
    digest = hashlib.sha256(instructions.encode()).hexdigest()[:12]
    return f"{app}:{prompt_version}:{model}:{digest}"

KEY = cache_key("support-agent", "us.openai.gpt-6-astra", "v7", INSTRUCTIONS)
prefix = {"role": "developer", "content": [{
    "type": "input_text", "text": INSTRUCTIONS,
    "prompt_cache_breakpoint": {"mode": "explicit"},
}]}
for label, question in [
    ("session A", "Explain the refund policy without calling tools."),
    ("session B", "Explain the escalation policy without calling tools."),
]:
    # A fresh conversation for each session; the startup prefix matches.
    session_history = [prefix, {"role": "user", "content": question}]
    result = ask_with_implicit_cache(session_history)
    d = result.usage.input_tokens_details
    print(label, "read", d.cached_tokens, "write", d.cache_write_tokens)

Sur un démarrage froid, la session 1 écrit le préfixe partagé. La session 2 peut le lire, même si sa tâche peut être différente. Chaque tâche peut également être stockée implicitement dans la cache. Vérifier les comptesurs d’utilisation : les clés et les marqueurs correspondants permettent la réutilisation, mais une entrée de cache doit toujours être disponible.

Ce que le stockage en mémoire des prompts apporte

Coût. Pour un agent alimenté par GPT-6 Astra, avec un préfixe de 8 000 tokens de démarrage et six tours ajoutant 2 000 tokens chacun, le coût d’un cache statique unique est réduit à 0,50 $, et les points de rupture dynamiques ont diminué le coût de l’entrée modélisée de 64 % : passant de 0,87 $ à 0,32 $ par session.

Figure 9 : Coût d’entrée cumulé par session pour l’exemple de support-agent, utilisant les prix sur demande Amazon Bedrock pour GPT-6 Astra

Comment savoir si le stockage en cache fonctionne ?

Commencer par l’utilisation des réponses. cached_tokens indique les entrées lues dans la cache, et cache_write_tokens indique les entrées écrites dans la cache. À mesure que la conversation se développe, veillez à ce que les tournants ultérieurs réutilisent l’histoire précédente et à ce que les nouvelles entrées reflètent le contenu ajouté.

Pour le monitoring de production sur l’endpoint Amazon Bedrock Runtime, utilisez les métriques CacheReadInputTokenCount et CacheWriteInputTokenCount dans Amazon CloudWatch. Activez le journalisation des invocations de modèle lorsque vous avez besoin de registres individuels des requêtes, puis interrogez-les via Amazon CloudWatch Logs Insights. Pour l’endpoint Amazon Bedrock Mantle, enregistrez les champs relatifs à l’utilisation de la réponse dans les logs de votre application. Son espace de noms Amazon CloudWatch ne dispose actuellement pas de comptes de cache distincts.

Pour vérifier les coûts, filtrez AWS Cost Explorer vers Amazon Bedrock et regroupez par Type d’utilisation. Les lectures de cache, les écritures de cache et les entrées non en cache apparaissent comme des entrées distinctes pour chaque modèle. Excluez les entrées contenant un token de sortie lors du calcul de leur part dans le coût des entrées.

Un bref tableau de contrôle

• Conservez le préfixe réutilisable stable. Placez les outils et instructions partagés en premier, puis ajoutez l’historique de conversation et les nouveaux échanges. Changer un timestamp, un message ou une définition d’outil empêche la réutilisation au-delà de cette modification. Un préfixe plus court peut néanmoins être réutilisé si il possède son propre point d’extrusion sauvegardé.
• Choisissez des limites autour du contenu que vous souhaitez réutiliser. Utilisez le stockage à cache implicite pour une histoire croissante, des marqueurs explicites pour les préfixes partagés, ou les deux. Le mode explicite uniquement évite d’écrire des suffixes temporaires. Lors de l’extension d’une conversation explicite uniquement, conservez les marqueurs antérieurs afin que les demandes ultérieures puissent trouver les préfixes sauvegardés.
• Conservez le catalogue initial des outils inchangé. Utilisez allowed_tools pour restreindre les outils qui peuvent être appelés. Ajoutez les définitions connues avec additional_tools, ou découvrez-les via le tool_search du côté client nommage. Choisissez un profil d’outil stable lorsque différentes rôles d’agent nécessitent des catalogues distincts.
• Vérifiez la taille et la durée de vie du préfixe. Un préfixe cacheable doit contenir au moins 1 024 tokens. Les préfixes enregistrés restent éligibles à la réutilisation pendant au moins 30 minutes après leur dernière écriture ou réutilisation réussie.
• Contenu partagé chaud avant l’exécution des aides. Marquez le préfixe partagé dans les requêtes de préchauffage et d’aide, y compris lors de l’utilisation du mode implicite. Terminez la requête de préchauffage avant de lancer les appels parallèles.
• Maintenez les clés de cache stables au sein de chaque groupe de partage. Les requêtes visant à réutiliser un préfixe doivent utiliser la même clé. Des clés distinctes permettent de maintenir une comptabilisation différente pour chaque client ou utilisateur.
• Mettez en évidence les économies au sein du flux de travail. Les écritures de cache coûtent 1,25 fois le taux d’entrée normal. L’écoute des prix dépend du modèle. Suivez les coûts d’écriture en même temps que les économies liées à la lecture, en utilisant les données d’utilisation pendant le développement, les données de surveillance et les données de facturation en production.

Se réveiller le 3 février

Bill Murray ne échappe à la journée de Groundhog que lorsqu’il cesse de répéter les mêmes erreurs et commence à appliquer ce qu’il a appris d’un jour à l’autre. Les agents y parviennent de manière similaire, mais moins romantique : en maintenant le début de leur prompt de manière stable, et en utilisant des limites de cache automatiques ou explicites à mesure que l’histoire se développe.

Dans cet article, nous avons abordé comment stocker les outils et instructions partagés en cache, augmenter la capacité de la cache au fil des tours d’agent, et préserver la réutilisation lors de l’ajout d’outils, du lancement d’aides ou du démarrage de nouvelles sessions. Il est important de maintenir le préfixe partagé stable et d’ajouter de nouvelles informations au fur et à mesure que le workflow progresse. Utiliser le stockage de cache implicite pour les conversations en développement, et des points de décomposition explicites pour le contenu partagé. Combiner ces deux approches lorsque nécessaire, ou choisir le mode explicite uniquement lorsqu’il est peu probable que le suffixe change. Comparer les lectures et écritures de la cache, le coût total d’entrée et la latence pour déterminer quelle méthode convient le mieux à votre agent. Pour appliquer ces schémas, suivez la documentation Amazon Bedrock sur le stockage de cache pour les modèles OpenAI et consultez l’disponibilité des modèles selon la région AWS et l’endpoint. Commencez avec un seul workflow et mesurez les économies à mesure que vos conversations se développent.

Sur l’auteur