Amazon Bedrock offre ora il prompt-caching per Claude 4.6, una funzionalità che può ridurre la latenza di risposta e la spesa per l'inferenza nelle applicazioni di IA generativa. La capacità funziona ricordando una parte statica di un prompt per un massimo di cinque minuti, in modo che le chiamate successive saltino la costosa rielaborazione di quel testo.

Come la cache si inserisce nella catena delle richieste

Quando arriva una richiesta per Claude 4.6, cooperano due livelli.

  • Livello modello – Claude 4.6 mantiene una cache key-value (KV) nella memoria della GPU. La prima volta che il modello analizza un blocco di istruzioni, memorizza la rappresentazione interna risultante. Nelle chiamate successive che riutilizzano lo stesso blocco, il modello può recuperare la rappresentazione invece di ricalcolarla.

  • Livello Bedrock – Bedrock calcola un fingerprint del segmento statico del prompt. Se una nuova richiesta presenta un fingerprint corrispondente, Bedrock la instrada direttamente alla GPU che contiene già lo stato in cache, saltando la fase di "warm-up".

Immaginalo come il caricamento di un salvataggio piuttosto che l'inizio di una nuova partita ogni volta.

Regole per mantenere attiva la cache

  1. Conteggio minimo di token – Claude Sonnet 4.6 richiede almeno 1.024 token nel segmento in cache; Claude Opus 4.6 ne richiede 4.096. Qualsiasi valore inferiore viene ignorato.

  2. Durata di cinque minuti – La cache scade dopo cinque minuti di inattività. Ogni hit resetta il timer, quindi un flusso costante di chiamate può mantenere la cache attiva indefinitamente.

  3. Ordine del prompt – Bedrock legge il prompt sequenzialmente. Le istruzioni statiche devono apparire per prime, seguite da un marker cachePoint, con tutti i messaggi generati dall'utente dopo tale marker. Cambiare anche un solo carattere prima del marker interrompe il fingerprint e forza una lettura a freddo (cold read).

Mettere in pratica la funzionalità

La Bedrock Converse API è il punto di ingresso. Di seguito è riportato un breve snippet Python che dimostra la struttura richiesta.

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)}")

Il cachePoint indica a Bedrock dove termina il segmento immutabile. Dopo la prima chiamata, la metrica cacheReadInputTokens dovrebbe mostrare un valore diverso da zero, confermando che la cache è stata utilizzata.

Perché gli sviluppatori dovrebbero interessarsene

Separare le istruzioni statiche dall'input dinamico dell'utente sposta il carico di lavoro dai costosi cicli della GPU a una fase di routing leggera. Per i chatbot, le pipeline di retrieval-augmented generation (RAG) o qualsiasi servizio che ripete lo stesso system prompt, il risultato è una risposta più rapida e un numero inferiore di token fatturabili. In scenari ad alto throughput, anche una modesta riduzione del tempo di calcolo può tradursi in un risparmio di costi notevole.

Limiti e compromessi

La funzionalità aiuta solo quando il segmento del prompt soddisfa i minimi di token e rimane invariato. Le applicazioni che modificano frequentemente le istruzioni di sistema, o che si affidano a prompt brevi, trarranno scarso beneficio. La finestra di cinque minuti significa anche che un traffico a raffiche con lunghi periodi di inattività potrebbe causare ripetute letture a freddo, erodendo il vantaggio in termini di latenza. Infine, la cache risiede nella memoria della GPU; se più modelli condividono lo stesso hardware, la contesa potrebbe influire sulle prestazioni, sebbene Bedrock non esponga questi dettagli.

Cosa monitorare in seguito

  • Dashboard delle metriche – Tieni d'occhio cacheReadInputTokens e la latenza complessiva per verificare che la cache venga utilizzata come previsto.
  • Prompt engineering – Progettare prompt che soddisfino le soglie di dimensione senza appesantire la richiesta è una nuova disciplina per gli sviluppatori.
  • Estensioni future – Se Bedrock dovesse estendere la durata della cache o allentare i limiti di token, l'economia delle conversazioni di lunga durata potrebbe cambiare ulteriormente.

In sintesi: Il prompt caching offre agli utenti di Claude 4.6 una leva concreta per ridurre sia i tempi di risposta che la spesa, a condizione che riescano a bloccare un prompt sufficientemente grande e immutabile e a mantenere le chiamate entro una finestra temporale breve. Per qualsiasi servizio GenAI che ripete le stesse istruzioni di sistema, la funzionalità vale la pena di essere testata presto.