Come funziona la cache dei prompt negli LLM: KV cache e TTL

TL;DR: La cache dei prompt negli LLM non è un’ottimizzazione aggiunta a posteriori: deriva direttamente dal modo in cui l’architettura Transformer calcola l’attenzione. Una volta capito perché i vettori Key/Value di un prefisso stabile sono matematicamente riutilizzabili, emerge il doppio vantaggio: una drastica riduzione dei costi (50-90%) e del time-to-first-token (5-20×). Questo articolo, il primo di una serie in cinque parti, spiega perché la cache esiste a livello architetturale, il compromesso tra memoria e calcolo che ne determina la convenienza e il comportamento del TTL che ogni sviluppatore deve conoscere. La Parte 2 approfondisce le implementazioni specifiche dei vari provider.

Serie: Parte 1 di 5 — Principi della cache · Prossimo articolo: Parte 2 — Confronto e valutazione dei provider · Parte 3 — Tutorial con codice funzionante · Parte 4 — Il miglior LLM per ogni caso d’uso · Parte 5 — Integrazione con LangChain · Versione in una pagina: la guida completa alla cache dei prompt

Perché la spesa in token della tua app AI cresce più velocemente degli utenti

Se hai messo in produzione un chatbot, un’app RAG o un agente AI, probabilmente hai già incontrato lo stesso problema: la fattura raddoppia, ma l’utilizzo no. Basta aprire i log delle richieste per trovare sempre lo stesso system prompt da migliaia di token, le stesse descrizioni dei tool e gli stessi blocchi della knowledge base, inviati di nuovo a ogni chiamata.

È il problema economico centrale dell’inferenza LLM: il modello è stateless. Ogni richiesta rielabora da zero l’intero contesto. Un system prompt da 8K token chiamato 1,000 volte comporta 8 milioni di token di lavoro ripetuto. Paghi per ciascuno di essi e i tuoi utenti aspettano che vengano elaborati.

La cache dei prompt risolve il problema. A differenza della maggior parte delle ottimizzazioni delle prestazioni, però, non viene aggiunta all’architettura: è una conseguenza naturale della definizione dell’attenzione nei Transformer. Chiarito questo punto, diventano immediati anche tutti gli altri aspetti dell’articolo: prezzi, TTL e differenze tra provider.

1. Perché gli LLM hanno una cache: l’inferenza Transformer passo per passo

Questa è la parte che quasi tutti i tutorial sulla cache dei prompt saltano. Spiega perché la cache esiste e perché gli sconti offerti dai provider non sono cifre di marketing arbitrarie, ma riflettono i costi reali delle GPU.

1.1 La self-attention in una formula

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

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

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

Due proprietà di questa formula sono fondamentali per la cache:

Proprietà 1: Causal masking. Durante la generazione, il token i può prestare attenzione soltanto ai token nelle posizioni ≤ i. La matrice di attenzione è triangolare inferiore: i vettori K e V dei primi token vengono usati da ogni token successivo, ma i token successivi non li modificano mai.

Proprietà 2: K e V dipendono soltanto dal prefisso. Poiché vengono calcolati dagli embedding di input nelle posizioni 1…i tramite matrici di pesi fisse, i vettori K e V alla posizione i sono una funzione deterministica dei token nelle posizioni 1…i, e solo di quei token. Nulla nella posizione i+1 può modificare 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 è l’intera base teorica della cache dei prompt. Tutto il resto è implementazione.

1.2 Le due fasi dell’inferenza

L’inferenza degli LLM moderni si divide in due fasi distinte, che usano il tempo GPU in modo molto diverso. Questa separazione è descritta in dettaglio in Efficiently Scaling Transformer Inference (Pope et al., 2022).

Fase di prefill. Il modello acquisisce l’intero prompt in una sola volta. Per ogni layer calcola Q, K e V per tutti i token di input ed esegue la self-attention. Il prefill è compute-bound: satura le unità della GPU dedicate alle moltiplicazioni tra matrici. Il costo cresce come O(N²) rispetto alla lunghezza del prompt, a causa della matrice di attenzione.

Fase di decode. Il modello genera un token di output alla volta, in modo autoregressivo. Al passo t viene calcolato soltanto Q del nuovo token, che presta attenzione ai K/V di tutti i token precedenti. Il decode è memory-bandwidth-bound: la maggior parte del tempo viene impiegata per leggere K/V dalla memoria GPU, non per eseguire moltiplicazioni. Il costo per token cresce come O(N), quindi linearmente rispetto alla lunghezza corrente del contesto.

Per un carico tipico da chatbot, con un system prompt da 8K token, una query utente da 100 token e una risposta da 300 token, il prefill pesa sul tempo totale e sul costo in dollari all’incirca quattro volte più del decode. È questo il lavoro eliminato dalla cache.

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

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

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

In origine, “KV cache” indicava un’ottimizzazione interna alla singola richiesta. Durante il decode, ogni nuovo token generato deve prestare attenzione ai K e V di tutti i token precedenti. Ricalcolarli a ogni passo trasformerebbe il decode da O(N) a O(N²). Tutti gli inference engine, quindi, memorizzano in GPU i K e V prodotti durante il prefill e li riutilizzano per l’intera fase di decode. È un meccanismo universale, adottato da ogni LLM commerciale. Senza, la generazione non sarebbe gestibile.

Quella che i provider espongono come “cache dei prompt” è l’estensione successiva: mantenere la KV cache anche dopo la fine della richiesta e riutilizzarla per la richiesta seguente che condivide lo stesso prefisso.

1.4 Il compromesso tra memoria e calcolo: perché esistono i TTL

Perché i provider non conservano tutto in cache per sempre? Perché la KV cache è enorme.

Per un modello con L layer Transformer, H attention head, D dimensioni per head e B byte per valore, in genere 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 nella classe 70B con 80 layer, 8 KV head dopo la grouped-query attention, head dimension pari a 128 e pesi fp16, si tratta di circa 320 KB per token. Un contesto da 32K token richiede ~10 GB di KV cache per una sola richiesta. Una GPU H100 moderna dispone di 80 GB: può contenerne contemporaneamente soltanto una manciata.

È il vincolo principale che PagedAttention (Kwon et al., 2023, il paper alla base di vLLM) è stato progettato per risolvere a livello di batch. Lo stesso vincolo limita la cache dei prompt tra richieste diverse:

Il TTL della cache di un provider è quindi, in sostanza, una policy di eviction dalla memoria: prima o poi la GPU deve usare quella memoria per i carichi attivi di altri utenti e il prefisso in cache viene rimosso. 5 minuti per le cache residenti in HBM; fino a 1 ora per quelle spostate in DRAM tramite paging; ore per le cache su disco.

La soluzione di DeepSeek. DeepSeek-V2 ha introdotto 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 consente di persistere la KV cache su disco anziché in HBM. Di conseguenza, l’unità minima di cache può essere molto più piccola, 64 token invece dei 1,024 delle cache residenti in HBM, e i TTL effettivi molto più lunghi.

Per lo stesso motivo, la cache tra richieste richiede prefissi identici token per token. La cache è indicizzata tramite un hash dei token ID: qualsiasi differenza, anche un solo carattere che produca una tokenizzazione diversa, genera K e V differenti da quel punto in avanti. A questo livello non esiste alcun “fuzzy match”. Quello è il compito della cache semantica, un meccanismo diverso implementato nel gateway.

1.5 Due livelli di cache

┌──────────────────────────────────────────────────────────────┐
│  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 quasi tutto ciò che dovrai configurare come sviluppatore, riguarda il Layer 2.

2. Due vantaggi: costi E latenza

La maggior parte degli articoli presenta la cache come un’ottimizzazione dei costi. È una visione riduttiva. Per i team che gestiscono sistemi in produzione, soprattutto chat rivolte agli utenti, la riduzione della latenza è spesso il vantaggio più importante.

2.1 Il calcolo dei costi

Le pagine dei prezzi riportano le cifre principali, ma raramente le applicano a un carico realistico. Prendiamo un bot per l’assistenza clienti con un system prompt da 8,000 token, 100K query al giorno e messaggi utente da 200 token. Calcoliamo il costo su claude-sonnet-4-5 usando le tariffe Anthropic pubblicate per il 2026: input in cache al 10% e sovrapprezzo del 125% per la scrittura in cache.

Senza cache

• Input per chiamata: 8,200 token × tariffa base dell’input
• Costo per chiamata (misurato su una singola chiamata): ~$0.022
• Costo mensile: 100K × 30 × $0.022 = ~$66,000

Con la cache dei prompt

• Scrittura iniziale in cache: 8,000 token × sovrapprezzo del 125% (trascurabile rispetto al volume mensile)
• Chiamate successive: 8,000 token × 10% della tariffa base + 200 token × tariffa base + output
• Costo effettivo per chiamata: ~$0.003
• Costo mensile: ~$9,000

Risparmio di ~86%. È lo sconto pubblicato da Anthropic applicato a una struttura di input realistica. L’articolo successivo, Parte 3, Tutorial, riporta misurazioni reali per tutti gli altri provider.

2.2 Il vantaggio sulla latenza, spesso ancora più importante

Il prefill non è soltanto costoso: per qualsiasi prompt più lungo di poche centinaia di token, è il principale fattore che determina il time-to-first-token. Con un cache hit è possibile saltarlo quasi interamente.

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

Singola esecuzione, single-tenant. Il miglioramento del TTFT è più evidente con prompt lunghi (>5K token); nei prompt brevi il prefill incide troppo poco per dominare la latenza. Per Claude, il beneficio maggiore rilevato riguarda i costi, con una riduzione di ~88-89% dell’input in caso di lettura dalla cache. Per prompt da 100K+ token, i dati pubblicati da Anthropic mostrano che anche il vantaggio sul TTFT cresce in modo significativo.

Nelle UI di chat, gli utenti iniziano a percepire consapevolmente il ritardo intorno a 1 s di TTFT e ~2 s per il primo testo utile. Senza cache, un prompt RAG da 10K token supera nettamente questa soglia. Con la cache, lo stesso carico sembra istantaneo.

Per i loop di agenti con oltre 15 passaggi, il risparmio sui costi è interessante, circa il 50%, ma è la latenza a rendere il prodotto concretamente distribuibile: 15 passaggi × 5s di prefill = 75 s di attesa per attività → con la cache, 15 × 0.5s = 7.5 s.

2.3 Perché influisce sulla strategia di prodotto

Un errore comune è considerare la cache come “un’ottimizzazione dei costi di competenza delle operations”, da aggiungere dopo il lancio. La riduzione della latenza rende invece la cache parte integrante della UX:

• Un chatbot con TTFT inferiore a 1 s sembra reattivo; a 3 s sembra non funzionare.
• Un prodotto RAG in cui retrieval e prefill richiedono 4 s perde rispetto allo stesso prodotto che ne impiega 1.
• Un agente che completa un’attività in 20 s batte uno che ne richiede 90.

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

3. Aggiornamento della cache, TTL e modello operativo

Il TTL è uno degli aspetti più discussi e meno spiegati della cache dei prompt. Ci sono due punti da capire:

3.1 “Freshness” ha due significati diversi: non confonderli

Aggiornamento della cache ≠ aggiornamento della risposta. Spesso vengono confusi due concetti distinti:

Le risposte ottenute usando la cache non sono quindi “stale” dal punto di vista della qualità del modello. Se però inserisci “l’ora corrente è 14:32:05” nel system prompt e continui a usare i cache hit, l‘“ora corrente” resterà 14:32:05 fino alla scadenza del TTL e il modello comunicherà agli utenti un dato falso con assoluta sicurezza.

3.2 Comportamento del TTL nei vari provider

I 5 minuti predefiniti non sono arbitrari: corrispondono approssimativamente all’orizzonte della pressione sulla memoria GPU per i modelli più usati nei momenti di picco. Come calcolato nel §1.4, la KV cache di un singolo contesto di grandi dimensioni può occupare decine di GB. I provider non possono conservarla indefinitamente.

3.3 Progettare tenendo conto del TTL

Tre pattern efficaci in produzione:

Pattern A: Mantieni calde le sessioni. Nelle chat, la frequenza naturale delle richieste, con pochi secondi o minuti tra un turno e l’altro, mantiene attiva la cache senza interventi. Non serve preoccuparsi del TTL; basta evitare 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 calda la cache. Il costo è praticamente nullo, pochi token di input, e impedisce eviction massive della cache.

Pattern C: Usa provider con TTL lunghi per il cold storage. Se hai un documento da 50K token interrogato sporadicamente, per esempio una volta all’ora per una settimana, le cache esplicite di Gemini con TTL di 24 ore o le cache su disco di DeepSeek offrono prestazioni migliori delle alternative con TTL breve, nonostante il costo di storage.

4. Principi universali che ogni sviluppatore dovrebbe conoscere

I provider espongono la cache in cinque forme molto diverse: marker espliciti, gestione completamente automatica, modalità ibrida, persistenza architetturale su disco oppure nessun supporto. Il prossimo articolo è interamente dedicato al confronto: Parte 2, Confronto e valutazione dei provider. Quattro principi, però, valgono per qualunque provider e derivano direttamente dall’architettura appena descritta:

4.1 La cache è basata sul prefisso: l’ordine conta

Poiché K/V alla posizione i dipende dai token nelle posizioni 1…i, i provider possono trovare corrispondenze soltanto su un prefisso contiguo che parte dal token 0. Se cambia un solo carattere alla posizione 0, l’intero prefisso viene invalidato. Il contenuto stabile va all’inizio, quello variabile alla fine. Non è un’euristica, ma una conseguenza diretta della struttura causale della self-attention (§1.1).

4.2 La cache memorizza K/V, non le risposte

Un cache hit non restituisce una risposta generata in precedenza, ma i vettori K e V già calcolati. Il modello li usa per generare una nuova risposta alla domanda corrente. Di conseguenza:

• La qualità dell’output è identica a quella di una chiamata senza cache (§1.1).
• L’output resta non deterministico come sempre: temperature, top-p e così via continuano ad applicarsi.
• Le risposte ottenute dalla cache non diventano mai “stale” dal punto di vista della qualità del modello. Solo il contenuto del prompt, come timestamp e prezzi, può diventare obsoleto. Vedi di nuovo §3.1.

4.3 Le scritture in cache sono un investimento, non sono gratuite

Per i provider che applicano un sovrapprezzo alla scrittura, Anthropic 125% e Gemini esplicito 125%, la prima chiamata con un nuovo prefisso costa più di una chiamata senza cache. Il break-even arriva rapidamente, in genere con un solo hit, ma se il prefisso “stabile” cambia a ogni richiesta continuerai a pagare le scritture senza ottenere alcun vantaggio. È un rischio da tenere sotto controllo quando ordini i documenti recuperati in base alla rilevanza: è il classico anti-pattern.

4.4 Le API di cache non sono portabili tra provider

cache_control (Anthropic) ≠ cached_content (Gemini) ≠ cache_id (Qwen). Se l’applicazione deve funzionare con più provider, devi mantenere tre integrazioni oppure anteporre un Token Gateway che le uniformi. La Parte 2 tratta l’argomento in dettaglio.

5. La cache dei prompt è un risparmio garantito?

Quasi. Conviene quando:

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

Se soddisfi queste tre condizioni, in genere ottieni una riduzione dei costi del 50-90% e un TTFT da 3 a 20 volte più rapido, senza cambiare modello.

Prossimo articolo: Parte 2, Confronto tra provider di cache e framework di valutazione trasforma il quadro architetturale descritto sopra in un confronto funzionalità per funzionalità tra Claude, OpenAI, Gemini, DeepSeek e Qwen, con criteri per scegliere il provider più adatto al tuo carico.

Quickstart: usare l’SDK OpenAI con qualsiasi provider

Synthorai espone un endpoint compatibile con OpenAI. Basta configurare l’SDK ufficiale openai per usarlo e passare da un modello all’altro, Claude, GPT, Gemini, DeepSeek o Qwen, modificando una sola riga. Il gateway traduce cache_control nella sintassi di cache nativa di ogni 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 con gpt-5.4-mini, gemini-2.5-pro, deepseek-v4-flash e qwen3-max: cambia soltanto il campo model. Il gateway restituisce i metadati dei cache hit nel campo OpenAI standard prompt_tokens_details.cached_tokens, oltre a un campo cost in USD, evitando di dover mantenere localmente una matrice dei prezzi per ogni vendor.

FAQ

La cache dei prompt degli LLM è uguale alla cache semantica? No. La cache dei prompt è basata sul prefisso: riutilizza i valori K/V quando l’inizio del prompt corrisponde esattamente a livello di token. La cache semantica trova corrispondenze a livello di significato, tramite embedding, e restituisce una risposta precedente. Entrambe sono utili e un buon Token Gateway le combina in livelli.

La cache dei prompt modifica l’output del modello? No. K e V sono funzioni deterministiche dei token di input (§1.1). I logit prodotti dal modello a partire da K/V in cache sono matematicamente identici a quelli ottenuti ricalcolando K/V da zero. La cache è una pura ottimizzazione dell’efficienza e non incide sulla qualità.

Perché il TTL della cache è così breve? Non possono conservarla per sempre? La KV cache è enorme (§1.4: ~10 GB per un contesto da 32K su un modello 70B). La memoria GPU è il collo di bottiglia; le cache vengono rimosse quando il server deve usare quella memoria per carichi attivi. Le cache su disco, come quelle di DeepSeek, possono durare ore, mentre in genere quelle in memoria no.

Qual è la differenza tra KV cache e cache dei prompt? La KV cache è la struttura dati in memoria usata durante l’inferenza. La “cache dei prompt” è il riutilizzo della KV cache tra richieste diverse. Sono rispettivamente il Layer 1 e il Layer 2 del §1.5.

I prompt in cache possono diventare obsoleti e ridurre la qualità? No, dal punto di vista del modello. Sì, dal punto di vista del contenuto, se il prompt contiene informazioni sensibili al tempo. La cache memorizza vettori K/V, non fatti sul mondo reale. Vedi §3.1.

Come si misura 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). Registra questi valori nella 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): architettura MLA · Documentazione Anthropic sulla cache dei prompt · Documentazione OpenAI sulla cache dei prompt · Documentazione Google Gemini sulla cache del contesto · Guida DeepSeek alla KV cache · Cache del contesto di Alibaba Bailian

← Torna al blog