Amazon Bedrock biedt nu prompt-caching voor Claude 4.6, een functie die de responslatentie kan verlagen en de kosten voor inferentie voor generatieve AI-toepassingen kan verminderen. Deze mogelijkheid werkt door een statisch deel van een prompt tot vijf minuten te onthouden, zodat opeenvolgende aanroepen het kostbare opnieuw verwerken van die tekst overslaan.

Hoe de cache in de verzoekketen past

Wanneer een Claude 4.6-verzoek binnenkomt, werken twee lagen samen.

  • Modelniveau – Claude 4.6 houdt een key-value (KV)-cache bij in het GPU-geheugen. De eerste keer dat het model een blok instructies analyseert, slaat het de resulterende interne representatie op. Bij latere aanroepen die hetzelfde blok hergebruiken, kan het model de representatie ophalen in plaats van deze opnieuw te berekenen.

  • Bedrock-niveau – Bedrock berekent een vingerafdruk van het statische promptsegment. Als een nieuw verzoek een overeenkomende vingerafdruk heeft, stuurt Bedrock dit rechtstreeks naar de GPU die de gecachte staat al bevat, waardoor de "warm-up"-fase wordt overgeslagen.

Zie het als het laden van een opgeslagen spel in plaats van telkens een nieuw spel te starten.

Regels die de cache in stand houden

  1. Minimaal aantal tokens – Claude Sonnet 4.6 vereist ten minste 1.024 tokens in het gecachte segment; Claude Opus 4.6 heeft 4.096 tokens nodig. Alles wat kleiner is, wordt genegeerd.

  2. Levensduur van vijf minuten – De cache verloopt na vijf minuten inactiviteit. Elke hit zet de timer opnieuw, waardoor een constante stroom aan aanroepen de cache onbeperkt in stand kan houden.

  3. Promptvolgorde – Bedrock leest de prompt sequentieel. De statische instructies moeten eerst verschijnen, gevolgd door een cachePoint-marker, met alle door de gebruiker gegenereerde berichten na die marker. Het wijzigen van zelfs maar één karakter vóór de marker verbreekt de vingerafdruk en dwingt een cold read af.

De functie in de praktijk brengen

De Bedrock Converse API is het toegangspunt. Hieronder staat een minimaal Python-fragment dat de vereiste structuur demonstreert.

import boto3

bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")
MODEL_ID = "anthropic.claude-sonnet-4-6"

# Must be >1,024 tokens for Sonnet
BASE_SYSTEM_PROMPT = "Your long instructions here..."

system_configuration = [
    {"text": BASE_SYSTEM_PROMPT},
    {"cachePoint": {"type": "default"}}
]

conversation_history = []

def run_chat_turn(user_input):
    global conversation_history
    conversation_history.append(
        {"role": "user", "content": [{"text": user_input}]}
    )

    response = bedrock.converse(
        modelId=MODEL_ID,
        system=system_configuration,
        messages=conversation_history,
        inferenceConfig={"maxTokens": 500, "temperature": 0.4}
    )

    assistant_message = response["output"]["message"]
    conversation_history.append(assistant_message)

    metrics = response["usage"]
    print(f"Read from cache: {metrics.get('cacheReadInputTokens', 0)}")

De cachePoint vertelt Bedrock waar het onveranderlijke segment eindigt. Na de eerste aanroep zou de cacheReadInputTokens-metriek een waarde groter dan nul moeten tonen, wat bevestigt dat de cache is geraakt.

Waarom ontwikkelaars dit belangrijk moeten vinden

Het scheiden van statische instructies van dynamische gebruikersinvoer verplaatst het werk van dure GPU-cycli naar een lichtgewicht routeringsstap. Voor chatbots, retrieval-augmented generation (RAG)-pipelines, of elke dienst die dezelfde systeemprompt herhaalt, is het resultaat snellere antwoorden en lagere factureerbare tokenaantallen. In scenario's met een hoge doorvoer kan zelfs een bescheiden vermindering van de rekentijd leiden tot merkbare kostenbesparingen.

Limieten en afwegingen

De functie helpt alleen wanneer het promptsegment aan de minimale tokenlimieten voldoet en ongewijzigd blijft. Applicaties die systeeminstructies vaak aanpassen, of die afhankelijk zijn van korte prompts, zullen weinig voordeel merken. Het venster van vijf minuten betekent ook dat grillige verkeersstromen met lange inactiviteitsperioden herhaaldelijk cold reads kunnen veroorzaken, waardoor het voordeel in latentie verloren gaat. Ten slotte bevindt de cache zich in het GPU-geheugen; als meerdere modellen dezelfde hardware delen, kan concurrentie de prestaties beïnvloeden, hoewel Bedrock deze details niet prijsgeeft.

Waar u op moet letten

  • Metrische dashboards – Houd cacheReadInputTokens en de algehele latentie in de gaten om te verifiëren of de cache naar behoren wordt gebruikt.
  • Prompt engineering – Het ontwerpen van prompts die voldoen aan de drempelwaarden voor grootte zonder het verzoek onnodig op te blazen, is een nieuwe discipline voor ontwikkelaars.
  • Toekomstige uitbreidingen – Als Bedrock de cacheduur verlengt of de tokenlimieten versoepelt, kunnen de economische aspecten van langlopende gesprekken verder verschuiven.

Conclusie: Prompt-caching geeft Claude 4.6-gebruikers een concreet middel om zowel de responstijd als de kosten te verlagen, mits ze een voldoende grote, onveranderlijke prompt kunnen vastleggen en de aanroepen binnen een kort tijdsbestek houden. Voor elke GenAI-dienst die dezelfde systeeminstructies herhaalt, is de functie het waard om vroegtijdig te testen.