Prompt caching: come dimezzare i costi API di un chatbot RAG

Tempo di lettura: 6 minuti — Livello: intermedio

Il conto che non ti aspetti

Costruisci il tuo primo assistente IA serio — un chatbot RAG sulla knowledge base aziendale, per esempio. Funziona, il team lo usa, sei contento. Poi arriva la prima fattura API vera e scopri una cosa controintuitiva: la maggior parte dei costi non viene dalle risposte, ma da quello che mandi TU al modello, a ogni singola richiesta.

Vediamo perché, e come il prompt caching sistema le cose.

Anatomia di una richiesta

Le API dei modelli linguistici fatturano a token (frammenti di parola), distinguendo input e output. Ogni volta che il tuo chatbot risponde a una domanda, l'input che parte è composto da:

• Il system prompt: le istruzioni fisse ("sei l'assistente di..., rispondi così, non fare questo...") — facilmente 1-2.000 token se fatto bene
• Il contesto RAG: i frammenti recuperati dalla knowledge base — altri 2-5.000 token
• La cronologia della conversazione
• La domanda dell'utente — spesso... 20 token Hai visto la sproporzione? L'utente scrive due righe, e tu paghi ogni volta il trasporto di un piccolo saggio di istruzioni e contesto. E qui il punto chiave: i modelli non hanno memoria tra una chiamata e l'altra. Il system prompt identico a ieri, a un'ora fa, a trenta secondi fa, viene ritrasmesso — e rifatturato — integralmente ogni volta.

Cos'è il prompt caching

I provider (Anthropic, OpenAI e gli altri, con meccanismi leggermente diversi) hanno introdotto la soluzione: se la parte iniziale della tua richiesta è identica a una recente, il modello non la rielabora da zero — la recupera dalla cache. E i token letti dalla cache costano una frazione del prezzo pieno: nel caso di Anthropic, il 10% (con un piccolo sovrapprezzo la prima volta che scrivi la cache).

Nota bene cosa NON è: non è una cache delle risposte (le risposte restano generate fresche ogni volta), è una cache dell'elaborazione dell'input. Domande diverse, stessa base: paghi la base una volta sola ogni finestra di cache.

La regola d'oro: stabile prima, variabile dopo

Il caching funziona sul prefisso: la parte iniziale e identica della richiesta. Appena qualcosa cambia, da lì in poi la cache non vale più. Quindi tutta l'ottimizzazione si riduce a un principio di impaginazione:

[ system prompt — identico sempre ]        ← cache
[ istruzioni e esempi — identici sempre ]  ← cache
[ contesto RAG — cambia per domanda ]      ← prezzo pieno
[ domanda utente — cambia sempre ]         ← prezzo pieno

L'errore che azzera tutto: infilare qualcosa di variabile in cima. Il classico è il timestamp ("oggi è il 28/9/2026 alle 14:32:07...") messo all'inizio del system prompt: ogni richiesta ha un prefisso diverso, cache mai riutilizzata, e magari nemmeno te ne accorgi. Se ti serve la data, mettila in fondo, dopo le parti stabili — o arrotondala al giorno.

Quanto si risparmia, in pratica

Facciamo i conti su un caso realistico: system prompt + istruzioni da 3.000 token, e 500 richieste al giorno.

• Senza caching: 3.000 × 500 = 1,5 milioni di token/giorno a prezzo pieno, solo di parte fissa
• Con caching: la stessa parte fissa viaggia quasi sempre a prezzo cache (10%) Su quella componente il risparmio è del ~90%; sul totale della fattura, dipende dal peso della parte variabile, ma per un chatbot con un system prompt curato dimezzare il costo complessivo è un risultato normale, non ottimistico. Ed è uno dei rari casi nella vita in cui l'ottimizzazione non richiede compromessi: stessa qualità, stessa latenza (anzi, spesso migliore), metà prezzo.

Come si attiva

Dipende dal provider: con alcuni è automatico sopra una certa soglia di token, con altri (come Anthropic) marchi esplicitamente i punti di cache nella richiesta. I dettagli li trovi nella documentazione del tuo provider e cambiano nel tempo, quindi non li incollo qui — quello che non cambia è il principio architetturale: progetta i tuoi prompt con la parte stabile in testa, e il caching (comunque sia attivato) farà il suo lavoro.

La lezione più generale

Questa storia insegna una cosa che va oltre i costi: i sistemi con l'IA dentro si ottimizzano guardando cosa viaggia davvero, non a intuito. Prima di ottimizzare, io ho loggato le mie richieste e ho contato i token per sezione. La sproporzione tra parte fissa e domanda dell'utente era sotto i miei occhi da settimane — bastava guardarla. Come sempre: misura, poi ottimizza. Nell'ordine inverso si ottimizzano le cose sbagliate, con grande soddisfazione e zero risultati.

---

Questo articolo fa parte della serie "Sviluppare con l'IA" su perfetti.tech — dove racconto quello che costruisco davvero, errori compresi.