Prompt caching per LLM: guida 2026 (costi input -50/-90%)

Se stai sviluppando un chatbot, un’app RAG o un agente AI basato su un large language model, il prompt caching è l’ottimizzazione più efficace: consente di ridurre del 50-90% i costi di input e di 3-10 volte il time-to-first-token, senza compromettere la qualità. Non è un espediente aggiunto a posteriori: deriva direttamente dalla definizione dell’attenzione nei Transformer. Una volta compreso questo principio, anche il resto dello stack, come TTL, differenze tra provider e struttura dei prompt, diventa chiaro.

TL;DR

• Il prompt caching riduce del 50-90% i costi di input e rende il time-to-first-token 3-10 volte più rapido, senza compromettere la qualità.
• Nelle misurazioni del 2026-05-25, i marker cache_control di Claude hanno ridotto i costi di input dell’88-89%; con l’auto-cache di GPT-5.4-mini il TTFT è sceso da 3.6s a 0.73s; DeepSeek-v4-flash ha offerto uno sconto del 74% grazie a una cache su disco.
• I TTL sono brevi perché lo stato KV occupa moltissima memoria: circa 10 GB per un contesto da 32K token su un modello di classe 70B.
• DeepSeek usa una granularità di cache di 64 token, contro la soglia abituale di 1,024 token. Anche le corrispondenze parziali del prefisso possono quindi ottenere uno sconto.

Questa pagina è l’indice di una serie in cinque parti, dalla teoria alla matrice decisionale per la produzione, fino al livello dei framework in cui vengono effettivamente assemblati i prompt. Parti dalla sezione più adatta a ciò che già conosci.

Da dove iniziare

Ogni parte può essere letta da sola, ma seguendo l’ordine si ottiene una visione completa senza ripetizioni.

Parte 1: Come funziona il prompt caching negli LLM

Come funziona il prompt caching negli LLM: KV cache e TTL →

L’articolo sull’architettura. Riassume la self-attention in una sola equazione, spiega perché i vettori K e V di un prefisso stabile sono matematicamente riutilizzabili e mostra come il compromesso tra memoria e calcolo determini il comportamento dei TTL che ogni sviluppatore deve considerare in fase di progettazione.

Punti chiave:

• Il prompt caching non è un’ottimizzazione aggiunta sopra il modello: è una conseguenza diretta dell’attenzione con mascheramento causale. K/V alla posizione i è una funzione deterministica dei token 1…i; prefissi identici producono quindi K/V identici bit per bit.
• Il caching evita il prefill, che è compute-bound e ha complessità O(N²). Il decode, memory-bandwidth-bound e con complessità O(N) per token, è già ottimizzato da ogni motore di inferenza.
• I TTL esistono perché la KV cache è enorme: circa 10 GB per un contesto da 32K su un modello 70B. 5 minuti è l’orizzonte imposto dalla pressione sulla memoria GPU; durate di ore o giorni sono possibili solo con cache su disco, come nell’architettura MLA di DeepSeek.
• Il caching migliora sia i costi (50-90% in meno sull’input in caso di cache hit) sia la latenza (TTFT ridotto di 3-10 volte per prompt da 5-10K token, e molto di più oltre i 100K).

Parte 2: Confronto del prompt caching tra provider LLM

Prompt caching a confronto: Claude, GPT-5, Gemini, DeepSeek e Qwen (2026) →

La guida alla scelta. Cinque provider espongono il prompt caching in cinque modi molto diversi: marker espliciti per Claude, gestione completamente automatica per GPT-5 e DeepSeek-v4, approccio ibrido implicito ed esplicito per Gemini e Qwen, oppure cache su disco a livello architetturale con MLA di DeepSeek. L’articolo propone un confronto funzionalità per funzionalità e un framework di valutazione su 5 dimensioni per assegnare un punteggio in base al carico specifico.

Punti chiave:

• Non confrontare i prezzi base. Confronta il costo effettivo ponderato in base all’hit rate, usando la formula nella §4.1. Il confronto aggiornato dei prezzi degli LLM e il calcolatore dei costi permettono di applicarlo al tuo carico.
• Claude offre lo sconto più elevato sulla singola chiamata, circa il 90%, ma richiede marker cache_control espliciti.
• DeepSeek-v4 è l’unico provider con cache su disco su larga scala. Le corrispondenze parziali del prefisso ottengono uno sconto perché la granularità è di 64 token invece di 1,024.
• La cache esplicita di Gemini prevede costi orari di storage; il punto di pareggio dipende dalla frequenza delle chiamate.
• A parità di hit rate, i provider si distinguono davvero per cinque fattori: ergonomia delle API, prevedibilità dell’hit rate, compatibilità del TTL con il carico, latenza in caso di miss e costo della migrazione.

Parte 3: Tutorial pratico in Python

Prompt caching per LLM in Python: tutorial con codice funzionante →

L’articolo pratico. Un solo gateway, un SDK OpenAI e un SDK Anthropic, con misurazioni effettuate il 2026-05-25 sull’intera famiglia Claude, da haiku-4-5 a opus-4-7, oltre a GPT-5.x, Gemini 2.5, DeepSeek-v4 e Qwen3.

Punti chiave:

• Claude con marker cache_control: riduzione dei costi misurata dell’88-89% su tutti i modelli haiku/sonnet/opus 4-x. Usa l’SDK Anthropic con base_url="https://synthorai.io/".
• Auto-cache di GPT-5.4-mini: TTFT migliorato di 5 volte, da 3.6 s a 0.73 s su un prompt da 7K token, con un cache hit rate del 93% sui token di sistema.
• Cache implicita di Gemini 2.5-flash: riduzione dei costi dell’88% sui cache hit quando vengono acquisiti i dati di utilizzo dello streaming.
• DeepSeek-v4-flash: sconto del 74% e cache su disco, che sopravvive a periodi di inattività nell’ordine delle ore.
• Pattern che tengono conto del TTL: heartbeat keep-alive per i cron job, regole per mantenere stabile il prefisso e dati da registrare per ogni chiamata.

Parte 4: Modello migliore per caso d’uso

LLM migliori per chat, RAG e agenti: matrice decisionale 2026 per modello e costi →

L’articolo per scegliere. Ogni tipo di carico agisce diversamente sulle leve di costo e latenza: le chat sfruttano naturalmente la cache, il RAG deve gestire l’instabilità del prefisso, mentre gli agenti dipendono dalla coerenza del prefisso cumulativo. L’articolo consiglia un modello per ogni forma di carico, con stime dei costi.

Punti chiave:

• Chatbot: va bene qualsiasi modello con auto-cache, perché le sessioni generano cache hit in modo naturale. Scegli in base a costo e qualità. gpt-5.4-nano è il più economico, gpt-5.4-mini ha il TTFT più rapido con cache e claude-haiku-4-5 segue meglio le istruzioni, con un sovrapprezzo contenuto.
• RAG: riordinare i documenti recuperati elimina i cache hit nella parte centrale del prompt. Ci sono tre soluzioni: spostare i riferimenti alla fine, ordinare i chunk in modo deterministico oppure usare più breakpoint cache_control di Claude.
• Agenti: chiamate e risultati dei tool devono essere aggiunti solo in coda e rimanere identici byte per byte tra uno step e l’altro. claude-sonnet-4-5 con 4 marker cache_control offre lo sconto più elevato sul prefisso cumulativo; gpt-5.4-mini consente un risparmio del 50% senza modifiche al codice.
• Scelta del TTL: 5 min per le chat, 1 ora per gli agenti con passaggi human-in-the-loop, cache su disco per batch sporadici.

Parte 5: Integrazione con LangChain

Prompt caching con LangChain: configurazioni che usano davvero la cache →

L’articolo sul framework. Le parti 1-4 presuppongono il controllo diretto dei byte del prompt. LangChain, invece, assembla il prompt e la sua sintassi più comoda disattiva silenziosamente la cache di Claude. Le misurazioni sono state effettuate con langchain-core 1.4.8 e un prefisso di sistema con marker.

Punti chiave:

• Il template basato sulla tupla di stringhe ("system", "...") non può contenere cache_control: nelle misurazioni, chiamate identiche non hanno prodotto alcuna attività della cache. La soluzione è usare un SystemMessage con blocchi di contenuto.
• L’ordine del prompt determina l’hit rate. Inserire il contesto RAG recuperato prima delle regole statiche ha trasformato ogni chiamata in una scrittura a freddo che, a causa del sovrapprezzo di scrittura di Claude, costa più che non usare affatto la cache.
• Un marker sul blocco di sistema include anche i tool associati. bind_tools produce una serializzazione stabile a livello di byte, mentre un marker su un dizionario tool in formato Anthropic viene inoltrato senza modifiche.
• Agenti multi-turn: spostando il marker sull’ultimo messaggio, a ogni turno viene riletto l’intero prefisso precedente e scritto solo il delta. Valori misurati: 1,864 in lettura e 15 in scrittura.
• Con i modelli dotati di cache automatica, come GPT, GLM e DeepSeek, un ordine errato non produce segnali: nessun sovrapprezzo, nessun errore, ma neppure lo sconto. Controlla i campi di utilizzo.

Come leggere la serie

• Se non conosci ancora l’argomento: segui l’ordine. L’architettura spiegata nella Parte 1 permette di capire subito le Parti 2-4.
• Se sei un PM o un architect e devi scegliere un fornitore: vai direttamente alle Parti 2 e 4. Consulta la Parte 1 se qualcuno del team chiede perché esistono i TTL.
• Se devi mettere in produzione oggi un carico specifico: inizia dalla Parte 4, trova la riga corrispondente nella matrice e passa alla Parte 3 per il codice esatto.
• Se usi già LangChain: vai direttamente alla Parte 5. I pattern basati sull’SDK diretto della Parte 3 restano validi, ma i problemi relativi a template di stringhe, posizione delle variabili e nomi dei campi di utilizzo dipendono dal framework.
• Se stai ottimizzando un’app esistente: usa il benchmark cross-provider della Parte 3 §6 e ripetilo con il tuo prompt. Richiede un giorno, non una migrazione di più settimane.

Dati misurati nella serie

I dati delle Parti 1-4 sono stati raccolti il 2026-05-25; quelli di LangChain nella Parte 5 il 2026-07-04. Le misurazioni sono state eseguite tramite il gateway Synthorai (https://synthorai.io/v1 per la compatibilità OpenAI, https://synthorai.io/ per l’interfaccia nativa Anthropic), in modalità single-tenant, con una sola esecuzione sequenziale e senza carico concorrente. I risultati variano in base alla regione, all’orario e al carico degli altri tenant. Usali come punto di partenza e ripeti i test sul tuo traffico prima di citarli.

Le tabelle dei prezzi e il comportamento dei TTL riflettono la documentazione pubblica dei provider disponibile al 2026-05. I provider aggiornano questi dati ogni pochi mesi. I principi architetturali della Parte 1 restano validi, mentre i valori comparativi delle Parti 2 e 3 cambiano nel tempo.

← Torna al blog