Il prompt caching di Amazon Bedrock legge un prefisso in cache con uno sconto di circa il 90 percento, ma una scrittura in cache costa più di un normale token di input, quindi una cache che non riceve mai un hit peggiora la bolletta invece di migliorarla. La funzionalità è disponibile in generale da aprile 2025, e la durata di cache di un'ora arrivata a gennaio 2026 la rende utile per intere sessioni e per i job batch. La maggior parte dei team la lascia comunque disattivata, oppure la attiva nel punto sbagliato e finisce per pagare un sovrapprezzo senza accorgersene. Lo sconto è reale. Se riesci a incassarlo dipende interamente da dove posizioni il breakpoint della cache.

Il modello mentale che trae in inganno è trattare la cache come un'accelerazione gratuita da spolverare ovunque. Non è gratuita. Ogni checkpoint di cache è una scommessa: che i token che lo precedono vengano rinviati, invariati, prima che la cache scada. Se vinci la scommessa paghi un decimo del prezzo di lettura. Se la perdi, hai pagato un sovrapprezzo di scrittura per niente.

Come funziona davvero il pricing

Contano tre classi di token, e sono prezzate in modo diverso:

  • Scrittura in cache: la prima volta che Bedrock memorizza un prefisso, quei token sono fatturati sopra la tariffa normale di input. Sui modelli Anthropic la scrittura costa circa 1,25x l'input base per la durata di cache breve e circa 2x per la durata di un'ora.
  • Lettura dalla cache: ogni richiesta successiva che corrisponde al prefisso memorizzato legge quei token a circa 0,1x, il famoso risparmio del 90 percento.
  • Input non in cache: tutto ciò che segue l'ultimo checkpoint di cache, fatturato alla tariffa normale ogni volta.

Il sovrapprezzo di scrittura è tutto il gioco. Stai pagando in anticipo per rendere economiche le letture future. Il punto di pareggio è semplice: ti servono abbastanza hit su un prefisso in cache per recuperare l'extra pagato per scriverlo. Una scrittura più una lettura può costare più di due chiamate semplici. I risparmi si moltiplicano solo quando lo stesso prefisso viene letto molte volte.

Dove posizionare il breakpoint

Un checkpoint di cache dice "tutto ciò che precede questo punto è stabile, memorizzalo". Quindi va posizionato dopo le parti del prompt che non cambiano tra una chiamata e l'altra, e prima di quelle che cambiano. In un assistente tipico questo ordine è:

[ 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

Il system prompt e le definizioni dei tool sono identici a ogni chiamata, quindi appartengono all'interno del prefisso in cache. Il nuovo turno dell'utente non si ripete mai, quindi va lasciato fuori. Il contesto recuperato sta nel mezzo: mettilo in cache se gli stessi documenti vengono riutilizzati nell'ambito di una sessione, lascialo fuori se ogni chiamata recupera qualcosa di nuovo. Sbagliare questo ordine, mettendo il checkpoint prima delle definizioni dei tool, significa mettere in cache quasi nulla pur pagando comunque per scriverla.

Quando un miss costa più di nessuna cache

Gli hit di cache richiedono una corrispondenza esatta del prefisso, byte per byte, e la voce deve essere ancora viva. Si perde la scommessa in tre modi comuni:

  • Muti il prefisso. Inserire un timestamp, un request ID, o un saluto per singolo utente vicino all'inizio del system prompt cambia i byte, quindi ogni chiamata è una nuova scrittura e mai una lettura. È l'autogol più comune.
  • Il traffico è troppo rado rispetto al TTL. Se le richieste arrivano più distanziate della durata di vita della cache, ognuna scrive e scade prima che arrivi la successiva. La durata di un'ora ha ampliato molto questa finestra, ma un endpoint a basso traffico può comunque mancare ogni volta.
  • Il prefisso è sotto la soglia minima. Bedrock mette in cache solo i prefissi oltre una soglia di token specifica per modello. Un system prompt breve potrebbe non essere affatto memorizzabile, quindi il checkpoint viene ignorato e non ottieni nulla.

In ciascun caso o paghi il sovrapprezzo di scrittura senza letture che lo ammortizzino, oppure non paghi nulla in più ma non risparmi nulla pur pensando di aver ottimizzato. Entrambi gli scenari sono peggiori di una decisione lucida di lasciare la cache disattivata su quel percorso.

Un modo rapido per sapere se sta funzionando

Non dare per scontato che la cache sia calda. Le risposte di Converse e InvokeModel riportano i conteggi dei token letti e scritti in cache nei campi di utilizzo. Registrali e osserva il rapporto. Un percorso in cache sano mostra un flusso piccolo e costante di scritture e un grande volume di letture. Se scritture e letture si muovono uno a uno, il tuo prefisso non è stabile e stai pagando il sovrapprezzo per una cache che nessuno colpisce. Correggi il prefisso o disattiva il checkpoint.

# 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

Il punto chiave

Il prompt caching su Bedrock non è un interruttore da attivare per uno sconto gratuito del 90 percento. È uno sconto prepagato: paghi un sovrapprezzo di scrittura in anticipo e lo recuperi tramite letture ripetute di un prefisso invariato. Metti il checkpoint dopo il system prompt e le definizioni dei tool stabili, tieni fuori dalla regione in cache tutto ciò che è volatile, e registra il rapporto letture/scritture così puoi dimostrare che la scommessa sta ripagando. Fatto bene, è il risparmio più economico e più grande disponibile su Bedrock. Fatto con superficialità, è una voce di costo che peggiora la bolletta pur sembrando un'ottimizzazione.

Da leggere ora

Per il playbook più ampio di ottimizzazione dei costi su AWS, le note di campo sul cloud sono su ercan.cloud, e l'hub è su ercanermis.com.