Inferenza LLM: come funziona la KV cache e quanto pesa

Nell'inferenza LLM, l'input già in cache costa meno perché il modello può riutilizzare il lavoro svolto. La KV cache conserva 2 insiemi di dati dell'attenzione, chiavi e valori, che permettono a un modello linguistico di grandi dimensioni di proseguire una conversazione senza ricostruire lo stato di ogni token precedente. Elaborare un contesto ripetuto diventa così meno costoso, ma le conversazioni lunghe continuano a occupare memoria e aumentano il contesto a cui ogni nuovo token deve prestare attenzione.

Conservare i prefissi utili e controllare quanta cronologia mantenere sono due compiti distinti. Un prefisso è la parte iniziale di una richiesta che rimane invariata: metterla in cache può ridurre l'elaborazione dell'input, ma il resto del lavoro dell'agente rimane.

I prezzi e le regole di caching riportati qui sono stati verificati sulle pagine dei prezzi e nella documentazione ufficiale dei fornitori il 15 ottobre 2026. I calcoli sulla memoria derivano dalle forme dei tensori documentate, non da misurazioni su una GPU specifica.

Che cos'è la KV cache nell'inferenza LLM?

La KV cache conserva lo stato dell'attenzione. L'attenzione è il meccanismo con cui un transformer incorpora nella previsione corrente le informazioni precedenti pertinenti. Un token, cioè un'unità di testo o di altro input del modello, produce rappresentazioni numeriche all'interno di ogni livello di attenzione. La cache mantiene le chiavi e i valori di quel livello per riutilizzarli in seguito. La spiegazione di Hugging Face sulla cache descrive questa memorizzazione per livello.

Per capire i tre ruoli dell'attenzione, pensiamo a una biblioteca usata per una ricerca:

• La query esprime ciò che la posizione corrente sta cercando.
• La chiave rende una posizione precedente disponibile per il confronto.
• Il valore fornisce le informazioni che una corrispondenza può apportare.

Immaginiamo di preparare appunti di ricerca con un indice prima di scrivere una relazione. Ogni nuova frase può attingere agli appunti già pronti. Ricostruire indice e appunti a ogni frase significherebbe ripetere il lavoro; conservarli, invece, occupa spazio. L'analogia si ferma quando si passa all'implementazione: il modello memorizza array numerici, non schede leggibili o riassunti dei documenti.

La query corrente viene confrontata con le chiavi precedenti; i pesi dell'attenzione risultanti combinano poi i rispettivi valori. In un transformer causale, le posizioni precedenti non possono guardare nel futuro. Aggiungere un token successivo, quindi, non richiede di modificare gli stati già calcolati per le posizioni precedenti. È questo a rendere valido il riutilizzo. Il paper originale su PagedAttention descrive questi calcoli dell'attenzione e il processo di generazione.

Ecco anche perché la cache di norma conserva K e V, anziché tutte le vecchie query. La previsione successiva richiede la query corrente e le chiavi e i valori accumulati; le query precedenti hanno già svolto il loro compito.

Per un agente di assistenza, gli stati conservati possono rappresentare le istruzioni, le definizioni degli strumenti, i documenti sulle procedure e la conversazione fino a quel momento. Dipendono dal modello e dal contesto precedente. Non sono i pesi appresi dal modello e non costituiscono un database permanente della memoria del cliente.

Un prefisso in cache è diverso anche da una risposta in cache. Il modello genera comunque una nuova continuazione. Una nuova domanda sullo stesso documento può riutilizzare lo stato già preparato del documento senza restituire la risposta precedente.

Prefill e decode: come viene usata la KV cache

Il prefill prepara l'input; il decode prosegue a partire da quell'input. Queste due fasi spiegano perché una richiesta può iniziare più rapidamente quando trova dati riutilizzabili in cache, pur impiegando ancora tempo per concludersi.

Per un transformer autoregressivo convenzionale, lo schema si può descrivere così:

Prefill: token del prompt → elaborazione del prompt → conservazione di chiavi e valori per ogni livello → previsione del primo token di output.

Decode: ultimo token generato + chiavi e valori conservati → elaborazione di quel token e applicazione dell'attenzione al contesto → previsione del token successivo; aggiunta delle nuove chiavi e dei nuovi valori calcolati.

Ripetizione del decode: riutilizzo della cache, che continua a crescere, fino al termine della generazione.

Il prefill può elaborare insieme le posizioni già note del prompt. Il decode procede invece lungo una continuazione i cui token successivi non sono ancora stati scelti. Questa distinzione è descritta nel flusso di generazione ed esecuzione del paper su PagedAttention.

La KV cache rende il token successivo meno costoso rispetto al ricalcolo dell'intero prefisso. Non lo rende indipendente dalla lunghezza del contesto. Con l'attenzione completa convenzionale, la sua query interagisce ancora con le chiavi e i valori conservati. Più contesto si mantiene, più dati dell'attenzione occorre utilizzare. Hugging Face documenta questo lavoro dell'attenzione che rimane a ogni passo.

Occorre poi distinguere due tipi di riutilizzo. All'interno di una risposta, il KV caching evita di ripetere i calcoli durante la generazione. Tra richieste diverse, il prefix caching, chiamato anche prompt caching nelle API gestite, conserva gli stati idonei affinché una chiamata successiva possa saltare parte del prefill. Un identificativo di conversazione, da solo, non dimostra che quegli stati siano disponibili.

Supponiamo che un agente legga un documento sulle procedure, chiami uno strumento e chieda poi al modello di decidere come usare il risultato. La richiesta successiva può mantenere le istruzioni e il documento precedenti come prefisso comune, aggiungendo in coda il risultato dello strumento. Se la cache è idonea e disponibile, il fornitore non deve preparare di nuovo quella parte iniziale comune.

Per chi sviluppa con le API, questo è un motivo per osservare sia l'attesa del primo token sia il tempo impiegato a generare la risposta. Un primo token più rapido non dimostra che il decode sia più veloce. La documentazione sull'Automatic Prefix Caching di vLLM distingue esplicitamente il risparmio sul prefill dal tempo di decode.

Prompt caching: come il lavoro riutilizzato riduce il costo dell'input

Lo sconto riguarda il lavoro sull'input riutilizzato, secondo le regole di fatturazione del fornitore. Non esiste una percentuale universale e una richiesta che trova una corrispondenza in cache non ottiene uno sconto su tutti i suoi token.

Per le API che distinguono input ordinario, scritture in cache e letture dalla cache, la componente di costo dell'input si può esprimere così:

Costo dell'input = (U × p_input + W × p_write + R × p_read) / 1,000,000

Qui U indica i token di input ordinario, W i token fatturati come scritture in cache e R quelli fatturati come letture dalla cache. Ogni p è il prezzo per milione di token della categoria corrispondente. Le categorie devono essere mutuamente esclusive: un token di scrittura non va addebitato di nuovo alla tariffa dell'input ordinario. È un semplice calcolo basato sulle unità di misura e sulle categorie di prezzo di OpenAI e Anthropic.

Vanno poi aggiunti l'output, gli eventuali costi degli strumenti e lo spazio di archiviazione della cache fatturato separatamente. La cache esplicita di Google introduce anche una componente legata alla durata della conservazione: un modello di costo basato solo su scritture e letture non basta. Quelli che seguono sono esempi delle regole applicate, non una classifica dei modelli.

Anthropic: indicare il prefisso da riutilizzare

Anthropic offre il prompt caching tramite cache_control, collocabile al livello principale della richiesta per gestire automaticamente i breakpoint oppure nei singoli blocchi di contenuto. Un breakpoint segna la fine del prefisso da conservare. La documentazione sui prezzi descrive entrambi gli approcci.

Esempio di prezzo, Claude API standard: per Claude Sonnet 5.5 l'input costa $2, le letture dalla cache $0.10, le scritture con durata di 5 minuti $2.50 e quelle con durata di 1 ora $4, sempre per milione di token. Prezzi Anthropic.

Per questo modello, il prefisso minimo memorizzabile in cache è di 512 token. Il contenuto deve coincidere esattamente fino al limite della cache. Le letture ne rinnovano la durata senza un nuovo addebito di scrittura, ma il tempo decorre dall'inizio della richiesta: la generazione della risposta consuma quindi parte dell'intervallo. Altri modelli Claude prevedono soglie minime e sconti sulle letture diversi. Regole del prompt caching di Anthropic.

Per un agente che lavora sui documenti e riprende dopo una lunga pausa dell'utente, la durata di conservazione può determinare se la chiamata successiva leggerà un prefisso esistente o lo scriverà di nuovo. Nei dati di utilizzo vanno controllati cache_creation_input_tokens e cache_read_input_tokens: ripresentare lo stesso documento, da solo, non dimostra che sia avvenuta una lettura scontata. Campi di utilizzo.

OpenAI: verificare le regole di scrittura del modello

OpenAI abilita il prompt caching per impostazione predefinita sui modelli supportati; quelli più recenti supportano breakpoint sia impliciti sia espliciti. Il comportamento dipende dal modello. Prompt caching di OpenAI.

Esempio di prezzo, fascia Standard per contesti brevi: per GPT-6.1 Sol l'input costa $2.00, l'input in cache $0.10 e le scritture in cache $2.50 per milione di token; oltre 272K token di input, le tariffe di input e cache raddoppiano per l'intera richiesta. Prezzi OpenAI, soglia del modello.

Per GPT-5.6 e successivi, il minimo è di 1,024 token di input visibili e la durata documentata della cache è di almeno 30 minuti dall'ultima scrittura o dall'ultimo riutilizzo. Per quei token, la tariffa di scrittura in cache sostituisce quella dell'input ordinario: non duplica il costo dell'intero input. I modelli precedenti hanno regole di scrittura e conservazione diverse. Regole attuali del caching.

Nella Responses API, vanno esaminati usage.input_tokens_details.cached_tokens e cache_write_tokens. Mantenere una sessione non garantisce una corrispondenza in cache. La guida alla diagnostica del prompt caching di GPT-6 del sito aiuta a indagare la struttura della richiesta e l'utilizzo riportato.

Google Gemini: riutilizzo implicito e archiviazione esplicita sono diversi

Google Gemini offre il caching implicito automatico, applicando il risparmio quando trova una corrispondenza in cache. Nell'esempio di Gemini 3.8 Flash, il minimo documentato è di 4,096 token di input. Mettere i contenuti comuni all'inizio e inviare richieste ravvicinate aumenta la probabilità di riutilizzo. Guida di Google al context caching.

Esempio di prezzo, Gemini Developer API a pagamento in modalità Standard: per Gemini 3.8 Flash l'input costa $0.75 e l'input in cache $0.075 per milione di token; l'archiviazione della cache esplicita costa $0.50 per milione di token all'ora, fino al 31 dicembre 2026. Prezzi Google.

Il caching esplicito usa una risorsa di contenuto in cache dotata di nome e scadenza, a cui fanno riferimento le successive richieste generateContent. Il costo di archiviazione implica che conservare un documento inutilizzato può comunque comportare una spesa. Riferimento dell'API di caching di Google.

La scelta dell'API conta: la Interactions API supporta solo il caching implicito. La guida attuale di Google esclude inoltre il caching esplicito per Gemini 4 Argon e successivi; i modelli Gemini 3 e 2.5 supportati usano generateContent per le cache esplicite. Per la Interactions API, occorre controllare usage.total_cached_tokens, come documentato nella guida. Regole di Google per ciascuna API.

Per chi gestisce un servizio basato su API, la differenza pratica è tra osservare riutilizzi automatici e pagare deliberatamente per conservare una risorsa. Un livello di astrazione della cache comune a più fornitori non dovrebbe presumere che i due casi abbiano lo stesso ciclo di vita.

La memoria della KV cache cresce con il contesto conservato

Nei livelli convenzionali ad attenzione completa, la memoria grezza della KV cache cresce linearmente con i token conservati. Una conversazione lunga comporta un insieme di dati di lavoro sempre più grande, anche quando la parte iniziale beneficia di uno sconto in fattura.

Per sequenze di uguale lunghezza e livelli di attenzione con geometria uniforme:

KV bytes ≈ 2 × B × T × L × H_kv × D × S

• 2: un array di chiavi e un array di valori.
• B: sequenze concorrenti, supponendo che i dati delle rispettive cache non siano condivisi.
• T: token elaborati e conservati per sequenza, inclusi quelli del prompt e quelli generati.
• L: livelli di attenzione che conservano questo tipo di cache.
• H_kv: teste key/value per livello.
• D: valori scalari per testa.
• S: byte usati per memorizzare ciascun valore scalare.

La formula deriva dal conteggio degli elementi nella forma documentata della cache per livello e nella struttura delle teste key/value di vLLM. Stima le dimensioni dei tensori grezzi, non la memoria totale del dispositivo.

Il numero di teste è determinante. Con la grouped-query attention, in cui più teste query condividono teste key/value, la formula richiede il numero di teste KV. Inserire il numero maggiore delle teste query porterebbe a sovrastimare la cache.

A parità di modello e precisione di memorizzazione, raddoppiando T la cache densa grezza raddoppia. Raddoppiando sia T sia il numero di sequenze concorrenti indipendenti, diventa quattro volte più grande. È un risultato algebrico, non un'affermazione sulla capacità di una GPU specifica o sul throughput misurato.

Per un servizio di assistenza ospitato su infrastruttura propria, questo suggerisce una domanda utile per il dimensionamento: quanti token conservati sono attivi contemporaneamente tra tutti i clienti? Far entrare il modello in memoria è solo il primo passo. Il server deve ospitare anche lo stato di inferenza dei clienti, che cambia nel tempo.

La documentazione sulle strategie di cache di Hugging Face descrive il limite dei livelli con attenzione a finestra, mentre il progetto della prefix cache di vLLM illustra i blocchi fisici riutilizzabili. Quando l'architettura si discosta da questi array densi convenzionali di chiavi e valori, va usata la struttura dello stato documentata per quell'architettura.

Per chi usa un'API gestita, la stessa crescita ha una conseguenza visibile diversa: a ogni turno possono essere fatturati più token come letture, anche con un tasso di hit stabile. Un prezzo unitario più basso, moltiplicato per un input in espansione, produce comunque un costo crescente. Anche la generazione dell'output continua ad applicare l'attenzione al contesto e le soglie tariffarie possono dipendere dalla lunghezza complessiva dell'input.

Come ottimizzare la KV cache con vLLM

vLLM, un motore open source per servire LLM, permette a chi gestisce la propria infrastruttura di controllare allocazione, riutilizzo e rappresentazione dei dati. Prima di modificare il deployment, conviene scegliere il controllo adatto al collo di bottiglia riscontrato.

PagedAttention: allocare blocchi man mano che cresce la conversazione

PagedAttention consente all'attenzione di lavorare su dati KV memorizzati in blocchi fisici separati. Una sequenza logica non richiede un'unica grande area contigua riservata per tutta la sua possibile crescita futura. Il progetto originale riduce gli sprechi nell'allocazione e permette la condivisione. Paper su PagedAttention.

L'analogia della biblioteca funziona ancora: a un progetto di ricerca in espansione si assegnano porzioni di scaffale disponibili, mantenendo una mappa del loro ordine. Non occorre riservare un enorme corridoio vuoto prima di sapere quanto materiale verrà prodotto.

La paginazione, da sola, non riduce le informazioni memorizzate per ciascun token. Migliora il modo in cui quelle informazioni trovano posto nella memoria disponibile. Inoltre, vLLM classifica la propria pagina sul kernel Paged Attention come storica: il concetto rimane utile, ma quella vecchia descrizione del kernel non va scambiata per l'implementazione attuale.

Prefix caching: evitare il lavoro già svolto per una richiesta precedente

Automatic Prefix Caching riutilizza lo stato KV di un prefisso corrispondente. vLLM documenta l'impostazione enable_prefix_caching=True: è la funzione pertinente quando domande ripetute su documenti o turni di un agente ripresentano la stessa parte iniziale. Automatic Prefix Caching.

L'identità della cache include il prefisso precedente, non soltanto il testo di un blocco isolato. Paragrafi identici che compaiono dopo istruzioni iniziali diverse, quindi, non possono essere considerati automaticamente intercambiabili. Il progetto della cache basato su hash di vLLM rende esplicita questa dipendenza.

Il limite dipende dal carico di lavoro: prompt senza contenuti in comune offrono poco da riutilizzare, mentre nelle risposte lunghe il decode può continuare a dominare i tempi. Per scegliere il motore nel suo complesso, il confronto tra vLLM e SGLang affronta la decisione più ampia.

Quantizzazione della KV cache: meno byte per ogni valore

La quantizzazione della KV cache riduce la precisione dei valori numerici memorizzati. vLLM supporta la memorizzazione della cache in FP8 tramite kv_cache_dtype="fp8" e, per tutelare la qualità, raccomanda di calibrare i fattori di scala su un dataset. Le opzioni disponibili dipendono dal backend dell'attenzione. Documentazione di vLLM sulla cache quantizzata.

Passare da valori a 16 bit a valori a 8 bit dimezza i dati scalari grezzi nella formula, prima dei metadati di scala e dell'overhead di allocazione. Non dimezza tutta la memoria del server e non dimostra un aumento misurato della velocità. Quantizzare i pesi del modello è una scelta distinta dalla quantizzazione dello stato dell'attenzione.

Per un agente in produzione, vanno valutati i compiti lunghi che contano davvero: mantenere i vincoli, scegliere gli strumenti e recuperare dettagli dai messaggi precedenti. Uno stato più piccolo serve solo se il compito continua a riuscire. Il fatto che il server si avvii non dimostra che la qualità sia rimasta invariata.

Compressione della KV cache: distinguere precisione e contenuto

Conservare valori meno precisi e conservare meno posizioni comporta compromessi diversi. La quantizzazione cambia la rappresentazione dei valori. Una finestra di attenzione limitata cambia invece quali posizioni rimangono disponibili per quel livello. I rispettivi modi di fallire non andrebbero confusi sotto una generica promessa di compressione. Strategie di cache di Hugging Face.

Un primo intervento pratico è smettere di inviare output irrilevanti degli strumenti. Si riduce così il contesto futuro alla fonte, ma è una decisione applicativa: prima di ottimizzare lo stato conservato, occorre preservare gli elementi su cui l'agente deve basarsi.

Offloading della KV cache: conservare più stato in cambio di trasferimenti

L'offloading sposta lo stato riutilizzabile in un altro livello di memoria. L'OffloadingConnector di vLLM può conservare i blocchi completati nella memoria dell'host CPU e nei livelli secondari supportati, per poi riportare sulla GPU quelli richiesti quando servono. Guida all'offloading di vLLM.

Può essere utile quando i prefissi rimangono validi più a lungo della loro permanenza sulla GPU. Introduce però anche trasferimenti di dati. Sul proprio carico di lavoro va confrontato il beneficio del ricalcolo evitato con il costo dei trasferimenti: non esiste un guadagno di latenza universale da citare.

Quando lo stato KV attivo mette sotto pressione la memoria, vLLM può sospendere le richieste e ricalcolarle in seguito. La sua guida all'ottimizzazione raccomanda di esaminare concorrenza e allocazione della memoria quando queste sospensioni, o preemption, diventano frequenti. Per chi gestisce il servizio, un aumento delle preemption è un segnale più utile su cui intervenire rispetto alla semplice constatazione che la memoria della GPU appare piena.

Perché i cache hit vengono sopravvalutati

Un tasso di hit elevato non equivale a un agente efficiente. Misura il riutilizzo, mentre ciò che serve all'azienda è un compito completato con successo entro tempi e costi accettabili.

Una conversazione può riutilizzare quasi tutto l'input precedente e continuare a crescere a ogni turno. Può rileggere più volte materiale irrilevante a tariffa scontata. Può anche passare la maggior parte del tempo a generare output, fase in cui il riutilizzo del prefisso non offre scorciatoie dirette.

Non conviene conservare una cronologia gonfiata solo per proteggere una metrica della cache. Quando il materiale vecchio non è più utile, è meglio compattare o ricominciare, accettando che un prefisso modificato possa richiedere una nuova elaborazione. La scelta deve dipendere dalla qualità del risultato e dal lavoro complessivo. La guida al context engineering del sito spiega come decidere quali informazioni inserire nel contesto di lavoro.

Chi sviluppa usando API a pagamento dovrebbe ottimizzare subito la struttura del prompt se le richieste condividono ripetutamente contenuti consistenti. Una gestione elaborata della cache può aspettare se il carico di lavoro ripete raramente un prefisso. Chi gestisce un'infrastruttura propria dovrebbe indagare la pressione sull'allocazione e le preemption prima di concludere che al modello serva più potenza di calcolo. Richieste brevi, isolate e senza contenuti in comune offrono poco lavoro riutilizzabile tra una chiamata e l'altra.

Domande frequenti sulla KV cache degli LLM

ChatGPT usa la KV cache?

OpenAI documenta il prompt caching basato su KV per le proprie API. Questo chiarisce il funzionamento della funzione pubblica dell'API, non ogni dettaglio dell'infrastruttura interna che serve ChatGPT. Per sviluppare un'applicazione, occorre basarsi sulle regole di caching pubblicate e sui campi di utilizzo del modello API scelto. Documentazione OpenAI.

Conviene fare offloading della KV cache verso la memoria GPU?

Nell'inferenza su GPU, lo stato attivo dell'attenzione viene usato sulla GPU. Con la funzione di offloading di vLLM, i blocchi riutilizzabili vengono spostati nella memoria dell'host o in altri livelli supportati e tornano quando servono. È una possibilità da valutare quando conservare più prefissi giustifica il costo dei trasferimenti. Offloading di vLLM.

Che cosa succede quando la KV cache è piena?

vLLM può rimuovere i blocchi in cache inutilizzati; quando le richieste attive mettono sotto pressione la memoria, può sospendere il lavoro e ricalcolarlo in seguito. Questo influisce sulla latenza. È un fenomeno distinto dal superamento del limite della finestra di contesto del modello. Gestione della cache, preemption.

Come si riduce la KV cache?

Si può ridurre il contesto conservato o il numero di sequenze concorrenti, riutilizzare i prefissi condivisi idonei oppure valutare una memorizzazione della cache a precisione inferiore. L'offloading cambia dove risiede lo stato, senza necessariamente ridurne le dimensioni complessive. Per giudicare il risultato, oltre alla memoria vanno considerate la qualità del compito e la latenza osservata. Strategie di cache.

Tre abitudini per mantenere alto il tasso di cache hit degli agenti

Durante un compito attivo, mantenere stabile l'inizio e aggiungere le modifiche solo in coda. Il riutilizzo di un prefisso esatto premia richieste prevedibili, entro i limiti di lunghezza minima, conservazione e disponibilità stabiliti dal fornitore.

1. 1

   Mettere per primo il prompt di sistema stabile

   Collocare istruzioni durature, definizioni degli strumenti e materiale di riferimento riutilizzabile prima dei dati variabili del compito, rispettando la struttura dei messaggi prevista dall'API. Mantenere stabili formulazioni, ordine degli strumenti e serializzazione. La gerarchia di Anthropic è strumenti, sistema e infine messaggi: cambiare l'insieme degli strumenti può invalidare il riutilizzo di ciò che segue. Struttura della cache di Anthropic.

2. 2

   Aggiungere alla cronologia senza riscriverla

   Conservare i messaggi precedenti e aggiungere in coda il nuovo turno dell'utente, la chiamata a uno strumento dell'assistente o il risultato dello strumento. Evitare di ricostruire i turni precedenti con riassunti o formattazioni che cambiano a ogni chiamata. Quando la compattazione diventa necessaria, trattarla come un punto di discontinuità intenzionale e stabilire poi un nuovo prefisso stabile. Questo rispetta la dipendenza di ogni blocco dai token che lo precedono. Identità del prefisso in vLLM.

3. 3

   Non mettere i timestamp all'inizio

   Collocare l'ora corrente, l'identificativo della richiesta e gli altri metadati variabili dopo il materiale riutilizzabile. Un timestamp all'inizio può invalidare il riutilizzo del contesto che segue. Con i breakpoint espliciti, segnare la fine del prefisso stabile prima del suffisso variabile. Indicazioni di Anthropic sui breakpoint.

Il prossimo giorno lavorativo, conviene esaminare una conversazione rappresentativa dell'agente nel punto in cui vengono inviate le richieste. Confrontare il prefisso esatto tra chiamate successive, poi leggere le scritture e le letture dalla cache riportate dal fornitore insieme a input totale, output e latenza. Prima di cambiare fornitore, correggere un eventuale prefisso instabile. Se il tasso di hit è già buono ma l'agente rimane lento, passare a esaminare il contesto conservato, la lunghezza dell'output e la contesa per le risorse del server.

Iscriviti alla newsletter per spiegazioni pratiche dei sistemi su cui si basano gli agenti AI.