Di cosa parleremo..
Il problema dei costi nei modelli linguistici
Ogni volta che interroghi un LLM, il modello deve processare l’intera sequenza di token che gli invii: system prompt, cronologia conversazione, documenti allegati, tool definitions. Più è lunga, più paghi e più aspetti. Con modelli che accettano 128k, 200k o addirittura 1 milione di token di contesto, il costo della fase di prefill può diventare rapidamente dominante.
La cache LLM è il meccanismo che evita di ricalcolare da zero le porzioni di prompt che si ripetono tra una richiesta e l’altra. Invece di processare ogni volta l’intero input, il sistema salva le rappresentazioni intermedie (i key/value tensors dell’attenzione) di un prefisso del prompt e le riutilizza nelle richieste successive. Il risparmio? Fino al 90% sul costo dei token di input e una riduzione di latenza che può arrivare all’80%.
Non è una feature di nicchia: tutti i principali provider la offrono, ognuno con la propria implementazione. Vediamo come funziona e come sfruttarla al meglio.
Come funziona tecnicamente
I transformer elaborano il prompt in due fasi:
- prefill (processa tutti i token di input in parallelo, calcolando le rappresentazioni intermedie),
- decoding (genera i token di output uno alla volta).
La fase di prefill è quella che scala col numero di token in input e che consuma più risorse.
La caching interviene qui: se una porzione del prompt è identica a quella di una richiesta precedente, il sistema salta il ricalcolo e recupera i key/value tensors già pronti. In pratica il server mantiene in memoria (GPU RAM o storage locale) queste rappresentazioni per un determinato intervallo di tempo, tipicamente da 5 minuti a 24 ore a seconda del provider e della configurazione.
Condizione essenziale: il contenuto da cache deve trovarsi all’inizio del prompt (un prefisso contiguo) e deve essere identico parola per parola, token per token. Anche una virgola in più o una lettera che passa da minuscola a maiuscola, rompe il match.
I quattro provider a confronto
OpenAI: Prompt Caching automatico
OpenAI è il provider che ha reso la cache più trasparente. Dal gpt-4o in poi, il Prompt Caching è attivo di default su tutte le richieste API. Nessuna modifica al codice: se il tuo prompt supera 1024 token, OpenAI prova automaticamente a fare cache hit instradando la richiesta su un server che ha già processato lo stesso prefisso.
Il routing si basa su un hash del prefisso del prompt (tipicamente i primi ~256 token) e opzionalmente su un parametro prompt_cache_key che puoi specificare per migliorare la probabilità di hit. La cache ha una durata di 5-10 minuti (in-memory) o fino a 24 ore se usi l’Extended Prompt Caching, disponibile su modelli recenti come gpt-4.1, gpt-5 e successivi.
Il risparmio è automatico: i token che fanno cache hit vengono fatturati al 10% del prezzo standard. Non c’è un costo aggiuntivo per scrivere in cache. Puoi monitorare l’efficacia controllando il campo prompt_tokens_details.cached_tokens nella response.
Una particolarità: cache e rate limits non sono correlati. I token in cache contano comunque per i tuoi limiti di TPM, anche se non paghi per processarli.
Anthropic (Claude): Automatica ed esplicita
Anthropic supporta due modalità. La cache automatica si attiva aggiungendo un flag cache_control: {"type": "ephemeral"} a livello top della richiesta. Il sistema applica automaticamente il breakpoint di cache sull’ultimo blocco cacheable e lo sposta in avanti man mano che la conversazione cresce. In una conversazione multi-turno, ogni nuova richiesta fa cache hit sulla cronologia precedente e crea una nuova cache che include il turno corrente.
La cache esplicita dà il controllo totale: puoi piazzare marcatori cache_control su singoli blocchi di contenuto (system prompt, tool definitions, knowledge base, conversazione) con un massimo di 4 breakpoint per richiesta. Il contenuto deve superare 1024 token per essere cacheable.
La durata predefinita è 5 minuti, rinnovata automaticamente a ogni hit senza costi aggiuntivi. Esiste anche una variante da 1 ora a prezzo maggiorato (2x il costo di scrittura base).
Il pricing è trasparente: la scrittura in cache costa il 25% in più rispetto al prezzo base dei token di input, mentre ogni hit successivo costa solo il 10% del prezzo base. Con un solo hit sei già in pari. Su Claude Opus 4.8, per esempio, scrivere in cache costa $6.25/MTok mentre leggere dalla cache costa $0.50/MTok, contro i $5/MTok dell’input normale.
Google (Gemini): Context Caching implicito ed esplicito
Google chiama la sua implementazione Context Caching. L’implicit caching è attivo di default su tutti i progetti Google Cloud, senza costi di storage aggiuntivi: cache hit significa 90% di sconto sui token di input ripetuti. Funziona su Gemini 2.5 Pro, 2.5 Flash e modelli successivi.
La soglia minima è più alta rispetto agli altri: 4096 token per i modelli Gemini 3, 2048 token per Gemini 2.
L’explicit caching è più flessibile: puoi creare, aggiornare il TTL (default 60 minuti), e cancellare cache specifiche via API. Il contenuto cacheable può includere testo, audio e video fino a 10 MB. Lo sconto è del 90% su Gemini 2.5+, del 75% su Gemini 2.0.
Un dettaglio importante: le cache esplicite interagiscono con l’implicit caching, quindi possono generare ulteriore caching non dichiarato. Se hai requisiti stringenti di retention dati, devi disabilitare esplicitamente l’implicit caching.
Alibaba Cloud (Qwen): Explicit Cache
L’implementazione di Alibaba Cloud Model Studio (via DashScope) segue da vicino lo standard Anthropic, supportando sia API OpenAI-compatible che Anthropic-compatible. La cache si attiva con il marcatore "cache_control": {"type": "ephemeral"} sul blocco di contenuto da cacheare. Anche qui: minimo 1024 token, massimo 4 marcatori per richiesta, TTL di 5 minuti con rinnovo automatico a ogni hit.
La caratteristica distintiva è l’integrazione nativa con strumenti come Claude Code, OpenCode, Hermes Agent, e, pensa te, anche OpenClaw. Se usi l’endpoint Anthropic-compatible di Alibaba Cloud, OpenClaw inietta automaticamente i marcatori di cache sul system prompt e sull’ultimo messaggio utente. In più, supporta un boundary custom: se inserisci nel system prompt, il cache viene applicato solo alla parte stabile prima del marcatore, migliorando la cross-session hit rate.
Il pricing segue lo stesso schema: scrittura in cache a 1.25x il prezzo base, lettura dalla cache al 10% del prezzo base.
Strategie pratiche per massimizzare i risparmi
1. Organizza il prompt per stabilità
Metti il contenuto che cambia meno all’inizio e quello variabile alla fine.
L’ordine ideale: system prompt (quasi mai cambia) → tools/function definitions (cambia occasionalmente) → contesto/knowledge base (cambia tra sessioni) → cronologia conversazione (cresce a ogni turno).
Su Anthropic e Alibaba Cloud, se usi breakpoint multipli, ogni marcatore indipendente permette di cacheare porzioni diverse con diversi livelli di stabilità. Su OpenAI invece la cache lavora solo sul prefisso, quindi devi essere ancora più rigoroso: tutto ciò che è statico nelle prime posizioni, tutto ciò che è dinamico in fondo.
2. Conversazioni multi-turno
In una chat lunga, il carico è dominato dalla cronologia. La strategia migliore: aggiungi un cache marker all’ultimo messaggio utente. In questo modo ogni turno fa cache hit sulla cronologia del turno precedente (comprensiva di system prompt e contesto) e crea una nuova cache che include il turno corrente per il prossimo giro. Più è lunga la conversazione, più è alto il risparmio proporzionale.
3. Agenti e tool calling
Gli agenti AI (ChatGPT con strumenti, Claude Code, OpenClaw, Cursor) sono il caso d’uso ideale perché alternano fasi di contesto stabile (istruzioni di sistema, definizioni di tool) a fasi variabili (stato del progetto, comandi utente, output di tool). La best practice è usare 3-4 marcatori di cache: uno per il system prompt, uno per le definizioni dei tool, uno per il contesto del progetto, uno per la cronologia della conversazione. Così anche quando lo stato del progetto cambia, system prompt e tool definitions restano in cache.
4. Batch processing
Se processi tanti input brevi con lo stesso system prompt lungo (classificazione, estrazione dati, moderazione contenuti), la mossa è semplice: marcatore di cache solo sul system prompt. Tutte le richieste successive faranno cache hit finché il system prompt rimane invariato. Il risparmio qui è enorme perché la porzione cacheata può essere il 90%+ del prompt totale.
Cosa non può essere cacheato
La cache LLM ha dei limiti precisi. Il contenuto deve essere un prefisso contiguo del prompt: se il contenuto che si ripete è in mezzo o in fondo, non viene cacheato. Le tool definitions sono incluse nel contesto cacheable su Anthropic e Alibaba Cloud (fanno parte del system prompt a tutti gli effetti), ma se cambi la definizione di un tool, la cache non fa più hit.
Le immagini possono essere cacheate se sono identiche e con lo stesso parametro detail (su OpenAI). Su Google Gemini puoi cacheare addirittura video e audio. Ma attenzione: ogni variazione nel contenuto multimediale rompe il match, deve combaciare proprio a livello di HASH!
La cache non è persistente oltre il TTL. Non esiste un’opzione per fare “cache forever”. Se non usi un prefisso per un po’, il server lo scarta. Su OpenAI e Anthropic la durata standard è 5-10 minuti; con Extended Prompt Caching su OpenAI arrivi a 24 ore. Su Google puoi impostare esplicitamente il TTL senza limite massimo.
Infine, la cache non condivide dati tra organizzazioni diverse. Due account OpenAI diversi che usano lo stesso prompt non condividono la stessa cache. I key/value tensors sono specifici del server che li ha generati: se il server cambia, la cache è persa.
FAQ
La cache LLM influisce sulla qualità delle risposte?
No. La cache salva solo le rappresentazioni intermedie del prompt, non le risposte. La generazione dei token di output avviene sempre da zero a partire dal prompt cacheato. La risposta è identica a quella che avresti avuto senza cache. Su Anthropic e Alibaba Cloud è garantito che l’output sia bit-a-bit identico.
Posso forzare manualmente la creazione della cache?
Dipende dal provider. Su OpenAI la cache è automatica quando il prompt supera 1024 token, non puoi forzarla né cancellarla manualmente. Su Anthropic e Alibaba Cloud devi aggiungere esplicitamente il cache_control marker. Su Google puoi creare cache esplicite con TTL personalizzato via API. Nessun provider permette di cancellare la cache manualmente: l’eviction avviene per inattività o scadenza TTL.
Quanto dev’essere lungo il contenuto per essere cacheato?
OpenAI, Anthropic, Alibaba Cloud: minimo 1024 token. Google Gemini 3: 4096 token. Gemini 2: 2048 token. Sotto queste soglie non viene creata cache. Puoi comunque vedere il campo cached_tokens nella response, ma sarà zero.
La cache funziona con Zero Data Retention (ZDR)?
Sì, con alcune sfumature. Su OpenAI la cache in-memory non salva dati su disco, quindi è compatibile con ZDR. L’Extended Prompt Caching invece può salvare key/value tensors in storage locale per massimo 24 ore. Su Anthropic la cache è compatibile con ZDR. Su Google devi disabilitare esplicitamente l’implicit caching se vuoi ZDR completo.
I rate limits tengono conto della cache?
Su OpenAI sì: i token cacheati contano comunque per i TPM rate limits, anche se non li paghi. Su Anthropic e Alibaba Cloud seguono la stessa logica: la cache riduce il costo ma non la contabilizzazione ai fini dei limiti. Su Google il discorso è analogo.
Posso usare la cache con immagini o file audio?
OpenAI supporta la cache sulle immagini purché siano identiche e con lo stesso parametro detail. Google Gemini è il più flessibile: supporta caching di testo, audio e video fino a 10 MB. Anthropic supporta immagini nei messaggi utente. La condizione è sempre la stessa: contenuto identico token per token.
La cache persiste tra sessioni diverse?
Solo se le richieste arrivano entro il TTL della cache (5 minuti, 1 ora o 24 ore a seconda della configurazione). Non esiste cache persistente a lungo termine. Serve un flusso continuo di richieste con lo stesso prefisso per mantenere la cache attiva. Se la frequenza di richieste è irregolare, rischi di pagare spesso la scrittura in cache senza mai beneficiare degli hit.
Quale provider ha la cache più conveniente?
OpenAI è il più comodo perché è automatico e gratuito (nessun sovrapprezzo per scrivere in cache). Se non vuoi pensare alla gestione dei marcatori, è la scelta migliore. Se invece controlli l’infrastruttura e vuoi massimizzare l’efficienza, Anthropic e Alibaba Cloud offrono più granularità con i breakpoint multipli, utili per agenti complessi. Google è il più flessibile sui formati multimediali e sulla durata della cache. La scelta dipende dal tuo caso d’uso.
Leggere i segnali di cache nella response API
Ogni provider espone metriche per capire se la cache sta funzionando. Su OpenAI cerchi prompt_tokens_details.cached_tokens nella response. Su Anthropic è usage.cache_read_input_tokens per gli hit e usage.cache_creation_input_tokens per le scritture. Su Google c’è cachedContentTokenCount. Su Alibaba Cloud i campi sono gli stessi di OpenAI o Anthropic a seconda dell’endpoint che usi.
Monitorare questi valori è il modo più semplice per capire se la tua strategia di caching funziona. Se cached_tokens è sempre zero, significa che il prefisso non è abbastanza stabile o la frequenza delle richieste è troppo bassa. Se invece vedi hit regolari, stai risparmiando. Molto.
