Quando si parla di ottimizzare gli LLM, il dibattito ruota quasi sempre attorno alla compressione dei pesi. TurboQuant, algoritmo di quantizzazione vettoriale annunciato da Google nei giorni scorsi, sceglie un bersaglio diverso (e per certi versi più insidioso) rappresentato dalla KV cache, quel segmento di memoria che i transformer usano per conservare i vettori chiave e valore generati durante l’elaborazione del testo.

Invece di ricalcolarli a ogni step, il modello li archivia. Soluzione efficiente in linea di principio ma costosa in pratica, visto che per un modello da 8 miliardi di parametri con un contesto da 32.000 token la sola KV cache può occupare circa 4,6 GB di VRAM in piena precisione FP16, e cresce linearmente con la lunghezza del contesto.

TurboQuant affronta il problema con un’architettura in due fasi pensata per essere indipendente dai dati e dall’addestramento. La prima si chiama PolarQuant e cambia il riferimento geometrico dei vettori. Invece di operare in coordinate cartesiane, li converte in coordinate polari, scomponendo ciascun vettore in un raggio e in un insieme di angoli che ne descrivono la direzione nello spazio.

Questa separazione non è puramente formale. Le distribuzioni angolari dei vettori nei transformer mostrano regolarità prevedibili, che TurboQuant sfrutta per eliminare la normalizzazione per blocco che i quantizzatori tradizionali richiedono. Il risultato è compressione ad alta qualità senza l’overhead delle costanti di quantizzazione.

La seconda fase entra in gioco per gestire ciò che la prima lascia inevitabilmente indietro, ovvero l’errore residuo. Qui interviene il Quantized Johnson-Lindenstrauss (QJL), un algoritmo che proietta tale errore in uno spazio a dimensionalità ridotta, correggendolo a 1 bit ed eliminando la distorsione sistematica che altrimenti si accumulerebbe nel calcolo degli score di attenzione.

TurboQuant google

TurboQuant dimostra ottime prestazioni di compressione della cache KV nel benchmark LongBench rispetto a vari metodi di compressione sul modello Llama-3.1-8B-Instruct (le larghezze di bit sono indicate tra parentesi).

L’effetto combinato delle due fasi permette di quantizzare l’intera KV cache a 3 bit per valore senza toccare i pesi del modello e senza alcun ciclo di fine-tuning. La variante a 4 bit arriva a moltiplicare per 8 le prestazioni nel calcolo degli attention logit rispetto a chiavi non quantizzate a 32 bit su GPU H100.

A questo punto è necessario fare una distinzione che il clamore mediatico tende ad appianare. TurboQuant non è infatti un compressore general-purpose per i modelli, né va confuso con la quantizzazione classica. I due approcci risolvono problemi strutturalmente separati. La quantizzazione tradizionale riduce la precisione dei pesi e abbassa il footprint in VRAM necessario per caricare il modello.

TurboQuant invece non sposta di un byte il costo di caricamento, per cui un modello da 70 miliardi di parametri che richiede 140 GB di VRAM per essere istanziato resta tale, con o senza TurboQuant. La compressione della KV cache interviene a runtime, durante l’inferenza, non prima.

Anche il contesto d’uso ha un peso determinante sull’efficacia reale della tecnica. Sotto i 1.000 token, la KV cache rimane abbastanza contenuta da rendere trascurabili i risparmi di compressione e, in alcuni scenari, l’overhead introdotto dalla rotazione e dalla quantizzazione può addirittura risultare negativo netto. Il vantaggio diventa tangibile dai 4.000 token in su e raggiunge la sua piena espressione nei contesti da decine di migliaia di token. Non a caso, i benchmark di riferimento sono stati condotti su GPU H100, hardware enterprise nell’ordine delle decine di migliaia di euro e lontanissimo da qualsiasi configurazione consumer.

Il vero terreno elettivo di TurboQuant è il deployment cloud su larga scala con contesti lunghi, batch massivi e inferenza distribuita. Per chi usa LLM in locale su hardware consumer, esiste comunque uno scenario limitato ma reale in cui TurboQuant porta un vantaggio ed è quello dei contesti molto lunghi. Spesso il vincolo non è caricare il modello, ma mantenere la finestra di conversazione aperta. Un utente che lavora con un modello da 7 o 13 miliardi di parametri e vuole sfruttare contesti da 128.000 token invece di tagliarli a 32.000 potrebbe effettivamente beneficiare della compressione della KV cache, ma si tratta di un caso d’uso specifico e presuppone comunque che il modello sia già caricato in memoria.