Cos'è la KV cache negli LLM?

La KV cache è la struttura dati con cui un modello Transformer memorizza le proiezioni Key e Value dei token già elaborati durante la generazione autoregressiva, per non doverle ricalcolare a ogni nuovo token: il modello riusa quanto già calcolato e aggiunge solo il Key e il Value del token appena generato. Esiste per ogni singola richiesta, non è condivisa tra utenti diversi, e vive quanto dura la generazione di quella risposta: è un meccanismo interno del motore di inferenza, non una funzionalità che si attiva o disattiva a piacere. Va tenuta distinta dal prompt caching: quest'ultimo riusa il prefisso fisso di un prompt tra richieste diverse per risparmiare sul costo di elaborazione, mentre la KV cache esiste anche dentro una singola conversazione e non è una leva di pricing del provider, ma una struttura del motore che genera la risposta. Sono meccanismi imparentati, a volte combinati in produzione, ma governano problemi diversi.

Perché è il vero vincolo di memoria

La dimensione della KV cache cresce linearmente con la lunghezza del contesto e con il numero di richieste gestite in parallelo: ogni token aggiunto alla conversazione aggiunge il suo K e il suo V per ogni livello del modello. Quante copie servano per livello dipende dall'architettura di attenzione: i modelli recenti condividono K e V fra più teste (GQA), il che riduce la cache di un fattore che sui modelli diffusi va da quattro a otto volte rispetto a una copia per testa. Su un modello di grandi dimensioni, questo si traduce in gigabyte di memoria GPU occupati non dai pesi del modello, che restano fissi, ma dalle conversazioni attive in quel momento. È per questo che la KV cache, non i pesi, è spesso il fattore che decide quante richieste concorrenti un server può gestire con la stessa GPU: superata la capacità disponibile, il servizio deve mettere in coda le nuove richieste o rifiutarle.

L'esempio che i team enterprise sottovalutano

Raddoppiare la finestra di contesto di un assistente aziendale, per esempio per fargli leggere documenti più lunghi, non raddoppia solo la latenza percepita: raddoppia anche l'occupazione di memoria per ogni conversazione attiva, e quindi dimezza (a parità di hardware) quanti utenti lo stesso cluster GPU può servire in parallelo. Un team che dimensiona la capacità guardando solo ai pesi del modello e ignorando la KV cache scopre il problema in produzione, quando l'assistente inizia a rallentare o a rifiutare richieste nelle ore di picco, non durante i test con un utente solo.

Perché conta per chi decide

Capire la KV cache è il prerequisito per valutare tecniche di serving come il PagedAttention, che gestisce questa memoria a blocchi non contigui per ridurre lo spreco, e il continuous batching, che sfrutta la stessa struttura per far entrare e uscire richieste dal batch senza aspettare che tutte finiscano insieme. Chi valuta un motore di inferenza o dimensiona una flotta GPU per un'applicazione AI non sta scegliendo solo un modello: sta scegliendo quanto efficientemente quella memoria verrà gestita, ed è lì che si gioca buona parte del costo per utente servito.

Fonti: Sebastian Raschka, Understanding and Coding the KV Cache in LLMs from Scratch; documentazione tecnica vLLM su PagedAttention e continuous batching.