Come funziona il caching dei prompt negli LLM: KV Cache e TTL spiegati

TL;DR — Il caching dei prompt LLM non è un’ottimizzazione aggiuntiva; deriva da come l’architettura Transformer calcola effettivamente l’attenzione. Una volta compreso perché i vettori Key/Value di un prefisso stabile sono matematicamente riutilizzabili, la vera sorpresa diventa il duplice beneficio: drastica riduzione dei costi (50–90%) e drastica riduzione del time-to-first-token (5–20×). Questo articolo — Parte 1 di una serie in cinque parti — tratta la ragione architetturale per cui esiste il caching, il compromesso memoria-vs-calcolo che determina se una cache è vantaggiosa e il comportamento del TTL che ogni sviluppatore deve comprendere. La Parte 2 approfondisce le implementazioni specifiche dei provider.

Serie: Parte 1 di 5 — Principi di Caching · Successivo: Parte 2 — Confronto e Valutazione dei Provider · Parte 3 — Tutorial con Codice Funzionante · Parte 4 — Miglior LLM per Caso d’Uso · Parte 5 — Integrazione con LangChain

Perché il conto dei token della tua app AI cresce più in fretta degli utenti

Se stai sviluppando un chatbot, un’app RAG o un agente AI, probabilmente hai sbattuto contro lo stesso muro: la fattura raddoppia mentre l’utilizzo no. Apri il log delle richieste e trovi sempre lo stesso system prompt da migliaia di token, le stesse descrizioni dei tool, gli stessi chunk della knowledge base, rispediti a ogni chiamata.

Questo è il problema economico centrale dell’inferenza LLM: il modello è stateless. Ogni richiesta rielabora l’intero contesto da zero. Un system prompt da 8K token chiamato 1.000 volte fa 8 milioni di token di lavoro ripetuto. Paghi per ognuno di essi, e i tuoi utenti aspettano per ognuno di essi.

Il prompt caching risolve questo problema. Ma a differenza della maggior parte dei trucchi per le performance, non viene aggiunto all’architettura: è una conseguenza naturale di come è definita l’attention nei Transformer. Una volta capito questo, tutto il resto dell’articolo (prezzi, TTL, differenze tra provider) si incastra alla perfezione.

1. Perché gli LLM hanno una cache: come funziona l’inferenza in un Transformer

Questa è la parte che quasi tutti i tutorial sul “prompt caching” saltano. È la parte che spiega perché la cache esiste in primo luogo, e perché gli sconti offerti dai provider non sono numeri di marketing arbitrari, ma riflettono l’economia reale delle GPU.

1.1 La self-attention in un’equazione

Un Transformer decoder-only (la famiglia a cui appartengono GPT-4, Claude, Gemini, DeepSeek, Qwen) elabora i token applicando ripetutamente la self-attention. Per una sequenza di N token, l’output di attention per ogni token i è:

Attention(Q, K, V) = softmax( Q · Kᵀ / √d ) · V

dove Q, K, V sono matrici di forma [N × d] ottenute dagli embedding di input tramite tre proiezioni lineari apprese (una per layer per head). La definizione originale viene da Attention Is All You Need (Vaswani et al., 2017).

Due proprietà di questa equazione contano moltissimo per il caching:

Proprietà 1 — Mascheramento causale. Durante la generazione, il token i può fare attention solo sui token in posizione ≤ i. La matrice di attention è triangolare inferiore: i vettori K e V dei token iniziali vengono usati da ogni token successivo, ma i token successivi non li modificano mai.

Proprietà 2 — K e V dipendono solo dal prefisso. Dato che si calcolano dagli embedding di input delle posizioni 1…i tramite matrici di pesi fisse, i vettori K e V in posizione i sono una funzione deterministica dei token nelle posizioni 1…i — e solo di quei token. Niente relativo alla posizione i+1 può cambiare K_i o V_i.

La conseguenza è immediata: se due richieste condividono un prefisso identico di lunghezza P, le prime P righe di K e V sono identiche bit per bit.

Questa è tutta la base teorica del prompt caching. Il resto è ingegneria.

1.2 Le due fasi dell’inferenza

L’inferenza LLM moderna si svolge in due fasi distinte che consumano tempo GPU in modo molto diverso. Questa divisione è documentata in dettaglio in Efficiently Scaling Transformer Inference (Pope et al., 2022).

Fase di prefill. Il modello ingerisce l’intero prompt in una volta sola. Per ogni layer calcola Q, K, V per ogni token di input ed esegue la self-attention. Il prefill è compute-bound: satura le unità di moltiplicazione matriciale della GPU. Il costo scala come O(N²) rispetto alla lunghezza del prompt, a causa della matrice di attention.

Fase di decode. Il modello produce un token di output alla volta, in modo autoregressivo. Al passo t viene calcolata solo la Q del nuovo token, che fa attention contro K/V di tutti i token precedenti. Il decode è memory-bandwidth-bound: la maggior parte del tempo se ne va a leggere K/V dalla memoria GPU, non a moltiplicare. Il costo scala come O(N) per token (lineare nella lunghezza del contesto corrente).

Per un carico di lavoro tipico da chatbot (system prompt da 8K token + query utente da 100 token + risposta da 300 token), il prefill domina il tempo effettivo e il costo in dollari con un rapporto di circa 4:1. Ed è proprio questa la parte che il caching risparmia.

Per call breakdown (8K prompt, 300 output tokens, Claude-class model):

  ████████████████████████████████░░░░░░░░  Prefill: ~80% of compute
  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░████████  Decode:  ~20% of compute

1.3 La KV cache: risparmiare il lavoro di prefill per il decode

Il termine “KV cache” indicava in origine un’ottimizzazione interna alla singola richiesta. Durante il decode, ogni nuovo token generato deve fare attention su K e V di tutti i token precedenti. Ricalcolarli a ogni passo trasformerebbe un decode O(N) in un decode O(N²). Per questo ogni motore di inferenza memorizza K e V dal prefill nella memoria GPU e li riutilizza per tutta la fase di decode. È una pratica universale: lo fa ogni LLM commerciale. È ciò che rende la generazione praticabile.

Quello che i provider espongono come “prompt caching” è la generalizzazione successiva: mantenere la KV cache anche dopo la fine della richiesta, e riutilizzarla per la richiesta successiva che condivide lo stesso prefisso.

1.4 Il tradeoff memoria–calcolo (perché esistono i TTL)

Perché allora un provider non mette semplicemente tutto in cache per sempre? Perché la KV cache è enorme.

Per un modello con L layer transformer, H attention head, D dimensione per head e B byte per valore (di solito 2 per fp16), la dimensione della KV cache per N token è:

KV cache size  =  2 × L × H × D × B × N
                  ↑   ↑   ↑   ↑   ↑   ↑
                  K&V layers heads head bytes tokens

Per un modello da 70B con 80 layer, 8 KV head (dopo grouped-query-attention), head-dim 128 e pesi fp16, sono circa 320 KB per token. Un contesto da 32K token significa ~10 GB di KV cache, e questo per una singola richiesta. Una GPU H100 moderna ha 80 GB: al massimo ci stanno una manciata di queste richieste in contemporanea.

Questo è il vincolo centrale che PagedAttention (Kwon et al., 2023, il paper dietro vLLM) è stato progettato per risolvere a livello di batch, ed è lo stesso vincolo che limita il prompt caching a livello cross-request:

Il TTL della cache di un provider è quindi in sostanza una politica di eviction della memoria: a un certo punto la GPU ha bisogno di quella memoria per i workload attivi di altri utenti, e il prefisso in cache viene sfrattato. 5 minuti per le cache residenti in HBM; fino a 1 ora per le cache paginate su DRAM; ore per le cache su disco.

Il trucco di DeepSeek. DeepSeek-V2 ha introdotto la Multi-head Latent Attention (MLA), che comprime la KV cache di circa 4× rispetto alla grouped-query attention standard (DeepSeek-AI, 2024). È proprio questa compressione a permettere di persistere la KV cache su disco invece che in HBM, cosa che a sua volta abilita un’unità minima di cache molto più piccola (64 token contro i 1.024 delle cache residenti in HBM) e TTL effettivi molto più lunghi.

È anche il motivo per cui il caching cross-request richiede prefissi identici token per token. La cache è indicizzata tramite un hash degli ID dei token, e qualsiasi divergenza — anche un solo carattere che viene tokenizzato in modo diverso — produce K e V diversi da quel punto in avanti. A questo livello non esiste il “fuzzy match” (quello lo fa il semantic caching, ma è un meccanismo diverso nel gateway).

1.5 Due livelli di caching

┌──────────────────────────────────────────────────────────────┐
│  Layer 1: Per-request KV cache (always on, every provider)    │
│  → keeps decode O(N) instead of O(N²)                        │
│  → you don't pay attention to it; the provider just does it  │
└──────────────────────────────────────────────────────────────┘
                              ↓
┌──────────────────────────────────────────────────────────────┐
│  Layer 2: Cross-request Prompt Cache (the money-and-time      │
│           saver this series is about)                         │
│  → reuses prefill K/V across requests with matching prefixes  │
│  → exposed as: explicit / fully automatic / hybrid           │
│  → bounded by TTL (memory-eviction-driven)                   │
└──────────────────────────────────────────────────────────────┘

Il resto della serie — e la maggior parte di ciò che andrai a regolare da sviluppatore — vive nel Layer 2.

2. I due vantaggi: costo E latenza

La maggior parte degli articoli presenta il caching come un’ottimizzazione dei costi. Ma così lo si sottovaluta. Il vantaggio in termini di latenza è spesso il motivo più importante per cui i team in produzione adottano il caching, soprattutto per le chat rivolte agli utenti.

2.1 I conti sui costi

Le pagine di pricing mostrano i numeri di riferimento, ma quasi mai li applicano a un carico di lavoro realistico. Prendiamo un bot di customer support con un system prompt da 8.000 token, 100K query al giorno e messaggi utente da 200 token. Calcoliamo i costi su claude-sonnet-4-5 con le tariffe pubblicate da Anthropic per il 2026 (input in cache al 10%, premio del 125% per la scrittura in cache):

Senza caching

• Input per chiamata: 8.200 token × tariffa base di input
• Costo per chiamata (misurato su singola chiamata): ~$0,022
• Costo mensile: 100K × 30 × $0,022 = ~$66.000

Con prompt caching

• Scrittura in cache una tantum: 8.000 token × premio del 125% (trascurabile rispetto al volume mensile)
• Per ogni chiamata successiva: 8.000 token × 10% base + 200 token × base + output
• Costo effettivo per chiamata: ~$0,003
• Costo mensile: ~$9.000

~86% risparmiato. È lo sconto pubblicato da Anthropic applicato a una forma di input realistica. L’articolo successivo (Parte 3 — Tutorial) mostra i numeri reali misurati sugli altri provider.

2.2 Il guadagno sulla latenza (spesso la parte più importante)

Il prefill non è solo costoso: è il fattore che più incide sul time-to-first-token per qualsiasi prompt oltre le poche centinaia di token. I cache hit ti permettono di saltarne quasi tutto.

TTFT in streaming misurato sul gateway pubblico Synthorai, il 2026-05-25, con un system prompt stabile da ~7.300 token:

Singola esecuzione, single-tenant. Il guadagno sul TTFT si vede soprattutto sui prompt lunghi (>5K token); sui prompt corti la porzione di prefill è troppo piccola per dominare la latenza. Per Claude il guadagno misurato più grande è sul costo (~88–89% in meno sull’input in caso di cache read); per prompt nell’ordine dei 100K+ token, il guadagno sul TTFT si accumula in modo sostanziale secondo i numeri pubblicati da Anthropic.

Nelle chat UI, la soglia oltre cui l’utente percepisce coscientemente un ritardo è intorno a 1 s per il TTFT e ~2 s per il primo testo utile. Un prompt RAG da 10K token senza caching sta ben oltre quella soglia. Con il caching lo stesso carico sembra istantaneo.

Per i loop agentici con 15+ step, il risparmio sui costi è buono (50%), ma è la latenza a rendere il prodotto davvero rilasciabile: 15 step × 5 s di prefill = 75 s di tempo morto per task → con il caching, 15 × 0,5 s = 7,5 s.

2.3 Perché conta per la product strategy

Un errore comune è trattare il caching come “ottimizzazione dei costi lato ops”, una cosa da attaccare dopo il lancio. Ma il guadagno sulla latenza fa sì che il caching sia anche parte della UX:

• Un chatbot con TTFT sotto 1 s sembra vivo; lo stesso bot a 3 s sembra rotto.
• Un prodotto RAG dove retrieval+prefill impiegano 4 s perde contro lo stesso prodotto che ci mette 1 s.
• Un agente che completa un task in 20 s vince contro uno che ci mette 90 s.

La strategia di cache va decisa insieme al modello e alla struttura del prompt, non tre sprint dopo il lancio.

3. Freschezza della cache, TTL e il modello operativo

La questione del TTL è una delle parti più discusse e meno spiegate del prompt caching. Due cose da capire:

3.1 “Freshness” ha due significati — non confonderli

Freshness della cache ≠ freshness della risposta. Sono due concetti distinti che spesso vengono confusi:

Le risposte in cache non sono “stantie” in alcun senso legato alla qualità del modello: sono matematicamente identiche a quelle non cached. Ma se metti “l’ora attuale è le 14:32:05” nel system prompt e fai affidamento sui cache hit, la tua “ora attuale” resta le 14:32:05 fino alla scadenza del TTL, e il modello continuerà a mentire agli utenti con la massima convinzione.

3.2 Comportamento del TTL nei vari provider

Il default di 5 minuti non è casuale: corrisponde più o meno all’orizzonte di pressione sulla memoria GPU per i modelli più usati sotto carico di picco. Come abbiamo calcolato nel §1.4, la KV cache per un singolo contesto ampio può arrivare a decine di GB; i provider non possono permettersi di tenerla in memoria all’infinito.

3.3 Progettare tenendo conto del TTL

Tre pattern che funzionano in produzione:

Pattern A — Mantieni le sessioni “calde”. Nelle chat, la cadenza naturale delle richieste (da secondi a minuti tra un turno e l’altro) mantiene viva la cache da sola. Non preoccuparti del TTL; basta non mettere dati dinamici nel prefisso.

Pattern B — Heartbeat per i batch. Per i job batch che durano ore, invia una richiesta minima ogni TTL/2 per mantenere la cache calda. Il costo è praticamente nullo (pochi token di input) ed evita ondate di cache eviction.

Pattern C — Usa provider con TTL lungo per lo storage a freddo. Se hai un documento da 50K token interrogato in modo sporadico (es. una volta all’ora per una settimana), le cache esplicite di Gemini (TTL di 24 ore) o le disk cache di DeepSeek rendono meglio delle alternative con TTL breve, nonostante il costo di storage.

4. Principi universali che ogni sviluppatore dovrebbe conoscere

I provider espongono il caching in cinque forme molto diverse tra loro — marker espliciti, completamente automatico, ibrido, disk-backing a livello architetturale, oppure niente del tutto. Dedichiamo il prossimo articolo a questo confronto (Parte 2 — Confronto e valutazione dei provider). Ma quattro principi valgono a prescindere dal provider e derivano direttamente dall’architettura che abbiamo appena visto:

4.1 Il caching è basato sul prefisso — l’ordine conta

Poiché i K/V alla posizione i dipendono dai token nelle posizioni 1…i, i provider possono fare match solo su un prefisso contiguo che parte dal token 0. Basta cambiare un singolo carattere alla posizione 0 e l’intero prefisso viene invalidato. Il contenuto stabile va all’inizio, quello volatile alla fine. Non è un’euristica: è una conseguenza diretta della struttura causale della self-attention (§1.1).

4.2 La cache memorizza le K/V, non le risposte

Un cache hit non restituisce una risposta generata in precedenza: restituisce i vettori K e V già calcolati, che il modello usa poi per generare una risposta nuova alla domanda corrente. Questo significa che:

• La qualità dell’output è identica a quella di una chiamata senza cache (§1.1).
• L’output non è deterministico nei modi consueti: temperature, top-p, ecc. continuano ad applicarsi.
• Le risposte in cache non sono mai “stantie” dal punto di vista della qualità del modello: solo il contenuto del tuo prompt (timestamp, prezzi) può essere obsoleto. Rivedi il §3.1.

4.3 Scrivere in cache è un investimento, non è gratis

Per i provider che applicano un sovrapprezzo sulla scrittura (Anthropic 125%, Gemini esplicito 125%), la prima chiamata con un nuovo prefisso costa di più rispetto al non usare la cache. Il punto di pareggio arriva in fretta (di solito basta un hit), ma se il tuo prefisso “stabile” cambia a ogni richiesta pagherai i costi di scrittura più e più volte senza alcun ritorno. Fai attenzione a questo se ordini i documenti recuperati per rilevanza: è l’anti-pattern classico.

4.4 Le API di caching non sono portabili tra provider

cache_control (Anthropic) ≠ cached_content (Gemini) ≠ cache_id (Qwen). Se la tua applicazione deve funzionare con più provider, o mantieni tre integrazioni oppure metti davanti un Token Gateway per unificarle. La Parte 2 approfondisce questo aspetto.

5. Il prompt caching è denaro gratis?

Quasi. Conviene quando:

• I tuoi prompt hanno un prefisso stabile: system prompt, knowledge base, schemi dei tool
• Le tue chiamate sono frequenti o collegate: stessa sessione, workload in batch, run di agenti in corso
• Puoi strutturare i prompt in modo che il contenuto stabile stia all’inizio

Se centri questi tre punti, di norma vedrai una spesa più bassa del 50–90% e un TTFT più veloce di 3–20× senza cambiare modello.

Prossimo articolo: Parte 2 — Confronto del caching tra provider e framework di valutazione prende il quadro architetturale visto sopra e lo trasforma in un confronto funzione per funzione tra Claude, OpenAI, Gemini, DeepSeek e Qwen, con una griglia di valutazione per scegliere il provider giusto per il tuo workload.

Quickstart: usa l’SDK OpenAI con ogni provider

Synthorai espone un endpoint compatibile con OpenAI: punta l’SDK ufficiale openai verso di esso e ogni modello (Claude, GPT, Gemini, DeepSeek, Qwen) diventa uno scambio di una sola riga. Il gateway traduce cache_control nella sintassi di caching nativa di ciascun provider.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["SYNTHORAI_KEY"],
    base_url="https://synthorai.io/v1",
)

resp = client.chat.completions.create(
    model="claude-sonnet-4-5",                       # swap freely
    max_tokens=256,
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user",   "content": "Hello"},
    ],
)

print(resp.choices[0].message.content)
print(resp.usage.prompt_tokens_details)  # cached_tokens when upstream reports it
print(resp.usage.cost)                   # USD per call (gateway-computed)

La stessa chiamata funziona per gpt-5.4-mini, gemini-2.5-pro, deepseek-v4-flash, qwen3-max: cambia solo il campo model. Il gateway restituisce i metadati sul prompt-cache hit nel campo standard OpenAI prompt_tokens_details.cached_tokens, più un campo cost in USD, così non devi mantenere in locale una matrice di prezzi per ogni vendor.

FAQ

Il prompt caching degli LLM è la stessa cosa del semantic caching? No. Il prompt caching è basato sul prefisso: riutilizza i valori K/V per una corrispondenza esatta a livello di token all’inizio del prompt. Il semantic caching fa il match a livello di significato (tramite embedding) e restituisce una risposta precedente. Entrambi sono utili, e un buon Token Gateway li combina a livelli.

Il prompt caching cambia l’output del modello? No. K e V sono funzioni deterministiche dei token in input (§1.1). I logit che il modello produce da un K/V in cache sono matematicamente identici a quelli ottenuti da un K/V ricalcolato da zero. Il caching è puramente un’ottimizzazione di efficienza, senza alcun impatto sulla qualità.

Perché il TTL della cache è così breve? Non si può tenerla per sempre? La KV cache è enorme (§1.4: ~10 GB per 32K di contesto su un modello da 70B). La memoria della GPU è il collo di bottiglia; le cache vengono sfrattate ogni volta che il server ha bisogno di quella memoria per i carichi attivi. Le cache su disco (DeepSeek) possono durare ore, ma quelle in memoria di solito no.

Qual è la differenza tra KV cache e prompt cache? La KV cache è la struttura dati in memoria usata durante l’inferenza. Il “prompt cache” è il riutilizzo di quella KV cache tra richieste diverse. Layer 1 contro Layer 2, come visto sopra in §1.5.

Un prompt in cache può degradare in modo da peggiorare la qualità? Dal punto di vista del modello, no. Dal punto di vista dei tuoi contenuti, sì, se il prompt codifica informazioni sensibili al tempo. La cache memorizza vettori K/V, non fatti sul mondo. Vedi §3.1.

Come misuro il cache hit rate? Ogni provider lo restituisce nell’oggetto usage della risposta: cache_read_input_tokens (Anthropic), cached_tokens (OpenAI), cached_content_token_count (Gemini), prompt_cache_hit_tokens (DeepSeek). Tienili tracciati nella tua pipeline di logging.

Riferimenti e fonti: Vaswani et al., “Attention Is All You Need” (NeurIPS 2017) · Pope et al., “Efficiently Scaling Transformer Inference” (2022) · Kwon et al., “Efficient Memory Management for LLM Serving with PagedAttention” (SOSP 2023, vLLM) · DeepSeek-AI, “DeepSeek-V2: A Strong, Economical, and Efficient MoE Language Model” (2024) — MLA architecture · Anthropic Prompt Caching docs · OpenAI Prompt Caching docs · Google Gemini Context Caching docs · DeepSeek KV Cache guide · Alibaba Bailian Context Cache

← Torna al blog