La KV cache e il peso dell'attenzione: tre strade un problema

Llama-3.1-70B, eseguito in precisione BF16, accumula circa 0,31 megabyte di KV cache per ogni singolo token elaborato. Con un contesto di 128.000 token il conto sale a 40 gigabyte, una cifra già scomoda. Con un milione di token, lo standard verso cui i modelli più recenti si stanno spingendo, si superano i 300 gigabyte: più dei 140 gigabyte occupati dai pesi del modello stesso. È un dettaglio che ribalta un'intuizione diffusa, quella per cui la memoria critica in un grande modello linguistico sia quella dei suoi parametri. Non è più così, o almeno non sempre. La memoria che davvero spaventa chi progetta sistemi di inferenza a lungo contesto è quella della KV cache, l'archivio dove il modello tiene in serbo le rappresentazioni di chiave e valore di ogni token già visto, per non dover ricalcolare tutto da capo a ogni nuova parola generata.

Il problema non è soltanto la dimensione. Ogni token decodificato deve far transitare l'intera cache dalla memoria ad alta banda fino alle unità di calcolo, il che rende la fase di decoding un collo di bottiglia di banda passante più che di potenza di calcolo. È un po' come avere un magazzino capiente ma corridoi troppo stretti per portarci dentro i faldoni: non importa quanto spazio c'è, se non si riesce a farlo fluire abbastanza in fretta il sistema si inceppa comunque.

Negli ultimi anni la ricerca ha risposto a questo problema lungo cinque direttrici principali. La prima è lo sfratto dei token, l'eviction, di cui H2O e SnapKV sono gli esempi più citati: si decide quali token siano meno importanti e si elimina la loro cache. La seconda è la quantizzazione, dove KIVI e GEAR hanno aperto la strada riducendo il numero di bit usati per rappresentare ogni valore. La terza è la proiezione di basso rango, con Palu come capofila, che attacca la ridondanza nascosta nelle dimensioni interne dei vettori chiave e valore invece che nel numero di token o nei bit per valore. La quarta è la fusione, KVMerger, che combina più voci di cache in una rappresentazione condivisa. La quinta è la condivisione architetturale, di cui la Multi-head Latent Attention di DeepSeek-V2 è l'esempio più noto, con una riduzione della KV cache del 93,3% incorporata direttamente nel design del modello fin dall'addestramento.

Negli ultimi mesi tre approcci hanno acceso particolare attenzione, e meritano di essere raccontati non come tre concorrenti in lizza per il trono, ma come tre risposte a domande leggermente diverse poste allo stesso problema.

TurboQuant, l'antefatto

Di TurboQuant ne avevamo già parlato in un articolo dedicato, quindi qui basta un richiamo. Il metodo, firmato da ricercatori di Google Research e New York University e accettato all'ICLR 2026, applica una rotazione casuale ai vettori chiave e valore prima di quantizzarli. La rotazione non altera la lunghezza del vettore ma ne ridistribuisce le componenti in una forma statisticamente nota e prevedibile, eliminando la necessità di calibrare il quantizzatore sui dati specifici. A questo si aggiunge un secondo stadio, costruito sulla tecnica QJL (Quantized Johnson-Lindenstrauss), che corregge il residuo della quantizzazione con un singolo bit aggiuntivo, garantendo che le stime dei prodotti interni, cioè esattamente i calcoli che il meccanismo di attenzione esegue in continuazione, non siano sistematicamente distorte.

Il risultato dichiarato è una compressione superiore a cinque volte con neutralità qualitativa a 3,5 bit per canale, e un'accelerazione dell'attenzione fino a otto volte su GPU H100. Come avevamo già notato, il metodo è solido ma non privo di zone grigie: il confronto con il precedente RabbitQ ha acceso polemiche in fase di revisione, e i benchmark più severi su LongBench mostrano che il vantaggio reale rispetto a metodi come KIVI è nell'ordine di un bit, non di una rivoluzione. Per i dettagli su rotazione casuale, bit residuale e le domande aperte sulla trasferibilità a modelli più grandi, il rimando è all'articolo originale.

OSCAR e la rotazione che ascolta l'attenzione

Se TurboQuant punta sulla generalità, sulla capacità di funzionare senza sapere nulla della distribuzione dei dati, OSCAR di Together AI nasce da un'osservazione quasi opposta: ignorare l'attenzione ha un costo, e a 2 bit quel costo diventa insostenibile.

Il punto di partenza è una distinzione sottile ma decisiva. Una rotazione come quella di Hadamard, usata da molti metodi precedenti, è efficace perché distribuisce i valori anomali su più canali, rendendo la distribuzione più uniforme e quindi più facile da quantizzare. Ma è una rotazione cieca: tratta tutte le direzioni dello spazio vettoriale come equivalenti, mentre l'attenzione non lo fa. Alcune direzioni contano molto di più di altre per il calcolo finale dei punteggi di attenzione e per l'output che ne deriva. Minimizzare l'errore di ricostruzione del vettore chiave o valore, l'obiettivo implicito di molte tecniche di quantizzazione, non equivale a minimizzare l'errore che effettivamente raggiunge l'output del modello.

Il team di Together AI ha quindi costruito un sistema in due fasi. Nella fase offline, durante una breve calibrazione su un piccolo insieme di dati, si stima la covarianza delle query e quella dei punteggi di attenzione, e da queste si derivano due rotazioni distinte, una per le chiavi e una per i valori, costruite specificamente per allinearsi con le direzioni che l'attenzione consuma davvero. Queste rotazioni vengono poi composte con una trasformata di Hadamard e una permutazione, in modo da ottenere il meglio di entrambi i mondi: l'attenzione alla geometria del problema, e la capacità di spalmare ulteriormente gli eccessi residui. Nella fase online, il sistema applica queste trasformazioni fisse durante il servizio del modello, mantenendo in alta precisione solo una piccola finestra di token recenti e i primissimi token della sequenza, che fungono da ancoraggio per l'attenzione, mentre tutto il resto della storia conversazionale viene compresso a 2 bit.

Il vantaggio di questa scelta è che la trasformazione è fissa, calcolata una sola volta in fase di calibrazione, e non richiede alcun intervento durante l'inferenza vera e propria. Questo la rende compatibile con le architetture di servizio già esistenti, in particolare con il paged-attention layout usato da framework come SGLang e vLLM, dove i blocchi di cache vengono gestiti come pagine di memoria indipendenti. OSCAR è stato integrato direttamente nello stack di SGLang con un kernel Triton dedicato per l'attenzione a 2 bit.

I numeri parlano chiaro sull'entità del problema che OSCAR risolve. Su Qwen3-4B-Thinking, la quantizzazione INT2 ingenua, senza alcuna rotazione, collassa praticamente a zero di accuratezza sul benchmark di matematica AIME25. Con la sola rotazione di Hadamard, senza l'accortezza attention-aware, il punteggio resta sotto 1,5. OSCAR, sullo stesso compito e sulla stessa quantità di bit, raggiunge un'accuratezza paragonabile a quella del modello non compresso. Su Qwen3-8B il gap rispetto alla precisione piena BF16 si riduce a 1,42 punti, mentre la memoria della cache si riduce di circa otto volte e il throughput a batch grandi sale fino a sette volte, sempre a parità di budget di memoria. Anche su modelli decisamente più grandi, come Qwen3-32B e il GLM-4.7 da 358 miliardi di parametri, OSCAR mantiene un'accuratezza vicina al BF16 fino a contesti di 128.000 token nei test RULER-NIAH, dove invece la rotazione ingenua collassa.

Va detto che lo stesso campo si muove con una rapidità che rende difficile fissare un punto fermo: quasi in contemporanea con OSCAR è emerso anche un metodo dal nome quasi identico ma diverso nella sostanza, OScaR (Omni-Scaled Canalized Rotation), che attacca lo squilibrio di norma tra token come causa primaria del degrado a bassa precisione, proponendo una soluzione più leggera ma con obiettivi simili. Un segnale di quanto sia caldo, in questo momento, il fronte della rotazione attention-aware. Immagine tratta dal paper ufficiale su arxiv.org

EpiCache, il problema che nessuno guardava

Mentre TurboQuant e OSCAR competono sullo stesso terreno, quello della rappresentazione numerica più efficiente di ogni singolo vettore, EpiCache di Apple sposta l'attenzione altrove: non quanti bit servono per rappresentare un token, ma quali token vale la pena conservare quando la conversazione si protrae per giorni o settimane.

Il problema che EpiCache affronta è specifico delle conversazioni di lunga durata, quelle in cui un assistente accumula sessioni su sessioni di dialogo con lo stesso utente. In questo scenario la KV cache di un modello relativamente piccolo come LLaMA3.2-3B può superare i 7 gigabyte dopo solo trenta sessioni, più dello spazio occupato dai pesi del modello stesso. La risposta più ovvia, applicare l'eviction dopo aver elaborato tutto il contesto, ha però un difetto strutturale: il picco di memoria cresce comunque in modo lineare con la lunghezza dell'input, perché prima di poter scartare qualcosa bisogna prima processare tutto. È come decidere quali libri buttare solo dopo aver già riempito ogni scaffale della casa.

EpiCache risolve questo con un'eviction a blocchi: il contesto viene elaborato in segmenti di dimensione fissa, e dopo ogni segmento si scartano subito i token meno rilevanti, mantenendo il budget di memoria costante indipendentemente da quanto lunga sia la conversazione complessiva. Il problema è che applicare questa strategia in modo elementare degrada pesantemente l'accuratezza, perché le tecniche più sofisticate di selezione dei token rilevanti, quelle basate su un prompt aggiuntivo che misura quanto ogni token riceve attenzione da una query, hanno bisogno di sapere in anticipo cosa l'utente chiederà. E in una conversazione reale, quella domanda futura non è disponibile al momento della compressione.

La soluzione proposta è elegante nella sua semplicità concettuale. Anziché indovinare la domanda futura, EpiCache la approssima usando il passato: raggruppa la storia conversazionale in episodi tematicamente coerenti tramite clustering, individua per ciascun episodio il segmento più rappresentativo, quello la cui rappresentazione semantica è più vicina al centro del cluster, e usa quel segmento come prompt guida per decidere quali token conservare nella cache specifica di quell'episodio. Quando arriva una nuova domanda dell'utente, il sistema la confronta con i centroidi di tutti gli episodi memorizzati e recupera la cache dell'episodio più affine, costruendo così una risposta basata sul contesto realmente pertinente, anche se quella porzione di conversazione risale a giorni prima.

A questo si aggiunge un secondo accorgimento, forse meno vistoso ma altrettanto utile: non tutti gli strati di un Transformer reagiscono allo stesso modo all'eviction a blocchi. Misurando quanto gli stati delle chiavi si discostano tra l'elaborazione completa e quella a blocchi, gli autori hanno scoperto che la sensibilità varia molto da strato a strato, in modo consistente al variare dell'input ma diverso da modello a modello. EpiCache distribuisce quindi il budget di memoria assegnando più spazio agli strati più sensibili e meno a quelli che tollerano meglio la compressione, invece di applicare un taglio uniforme su tutta la rete.

I risultati, misurati su tre benchmark dedicati a conversazioni di lunga durata (LongMemEval, Realtalk e LoCoMo), mostrano un miglioramento di accuratezza fino al 30% rispetto alle tecniche di compressione precedenti applicate nello stesso scenario a blocchi, con prestazioni vicine a quelle della cache piena anche con una compressione di quattro o sei volte. Sul fronte dell'efficienza, il sistema riduce la latenza di decoding fino a 2,4 volte e il picco di memoria fino a 3,7 volte rispetto alla cache non compressa. Immagine tratta dal paper ufficiale su arxiv.org

Tre filosofie a confronto

Messi uno di fianco all'altro, i tre metodi rivelano più complementarità che competizione, perché in realtà rispondono a tre domande diverse. TurboQuant chiede: come comprimo un vettore qualsiasi, senza sapere nulla del modello o del compito, con garanzie teoriche solide? OSCAR chiede: dato che conosco il modello e posso permettermi una breve calibrazione, come allineo la compressione a quello che l'attenzione effettivamente usa? EpiCache chiede invece una cosa completamente diversa: in una conversazione che dura settimane, quali porzioni della storia vale la pena tenere a portata di mano, indipendentemente da quanti bit per token si stiano usando?

Questo significa che, in linea di principio, non si è obbligati a scegliere uno e abbandonare gli altri. EpiCache decide quali token sopravvivono nella cache; OSCAR o TurboQuant decidono con quanta precisione quei token sopravvissuti vengono rappresentati. Un sistema di produzione pensato per un assistente conversazionale di lunga durata potrebbe in teoria applicare entrambe le logiche in sequenza, sebbene nessuno dei tre paper discuta esplicitamente questa combinazione, e l'integrazione pratica resti un esercizio da verificare sul campo.

Sul piano pratico, però, le differenze contano eccome a seconda dello scenario. Per chi deve servire un modello generico in produzione senza poter permettersi una fase di calibrazione specifica per ogni modello e ogni hardware, l'approccio data-oblivious di TurboQuant resta attraente, anche se i benchmark più severi suggeriscono un vantaggio reale più modesto di quanto la comunicazione abbia lasciato intendere. Per chi opera con un singolo modello fisso e vuole spingere la compressione fino al limite di 2 bit senza rinunce drastiche di qualità, soprattutto su compiti di ragionamento o codice dove ogni errore di attenzione si propaga e si amplifica nei passaggi successivi, la calibrazione attention-aware di OSCAR offre un margine di sicurezza che le rotazioni cieche non garantiscono. E per chi costruisce assistenti che accompagnano l'utente nel tempo, dove il problema non è tanto la precisione bit per bit quanto la capacità di ricordare la cosa giusta al momento giusto, EpiCache affronta un collo di bottiglia che gli altri due non toccano nemmeno.

C'è poi una distinzione di costo operativo che vale la pena sottolineare. TurboQuant non richiede calibrazione di alcun tipo, il che lo rende immediatamente applicabile a qualsiasi modello pre-addestrato. OSCAR richiede una calibrazione offline leggera, dell'ordine di poche migliaia di token per stimare le covarianze necessarie, ma poi resta fisso e non comporta costi aggiuntivi durante l'inferenza. EpiCache, infine, introduce un costo computazionale ricorrente, perché ogni volta che la conversazione supera un certo budget bisogna ripetere il clustering e ricostruire le cache episodiche, un'operazione che ha un prezzo ma che si ripaga con un'accuratezza molto più alta proprio nello scenario per cui è stato progettato.

Per chi volesse approfondire o sperimentare in autonomia, gli autori di OSCAR hanno reso disponibili sia il codice che una raccolta di rotazioni precalcolate su Hugging Face, mentre per chi lavora più sul lato della proiezione di basso rango Palu mette a disposizione un repository completo con script di valutazione e kernel GPU dedicati, una conferma che in questo campo la teoria, per quanto elegante, vale solo nella misura in cui si traduce in codice eseguibile su hardware reale.

Chi vince, chi aspetta

Resta una domanda di fondo che nessuno dei tre paper risolve da solo: la compressione della KV cache è davvero il vincolo principale dell'inferenza a lungo contesto, o esistono altri fattori, la larghezza di banda della memoria, la latenza di accesso, la parallelizzazione del calcolo di attenzione, che pesano altrettanto o di più? I numeri citati in questo articolo sono tutti reali e verificabili, ma vanno letti nel contesto specifico in cui sono stati misurati: modelli della famiglia Qwen3 e GLM per OSCAR, LLaMA per EpiCache, Llama-2-7B per TurboQuant. La trasferibilità a famiglie di modelli diverse, ad architetture con attenzione raggruppata o multi-query dove le dimensioni dei vettori chiave e valore sono già ridotte in partenza, resta in larga parte da verificare sul campo, non perché manchi fiducia nella teoria sottostante, ma perché ogni architettura porta con sé idiosincrasie che i benchmark pubblicati raramente esauriscono.

C'è infine una considerazione che vale la pena fare a voce alta. La rapidità con cui sono comparsi tre approcci distinti nell'arco di poche settimane, e la quasi contemporanea apparizione di un quarto metodo dal nome quasi omonimo a uno dei tre, racconta meno una corsa competitiva e più la maturazione di un problema che l'industria ha finalmente smesso di considerare secondario. Per anni la conversazione pubblica sull'efficienza dei grandi modelli linguistici si è concentrata quasi esclusivamente sulla dimensione dei pesi, sulla quantizzazione del modello, sulla distillazione. La KV cache è rimasta, per la maggior parte di questo tempo, un dettaglio implementativo. I numeri di apertura di questo articolo dovrebbero bastare a spiegare perché quel dettaglio sia diventato, di fatto, il vero limite dei sistemi che vorremmo capaci di ricordare tutto, per sempre, senza pagarne il prezzo in gigabyte.

Nota tecnica: i benchmark citati provengono dai paper originali e non sono stati riprodotti in modo indipendente da questa redazione; come sempre in questo campo, i numeri di laboratorio non garantiscono automaticamente le stesse prestazioni in scenari di produzione con carichi di lavoro reali.