La quantization della KV cache è una delle leve più discusse nel deployment locale dei LLM. Il nuovo benchmark su Qwen3.8 27B aggiunge un dato raro: non un confronto di velocità, ma una misura della divergenza KL token per token rispetto a un riferimento bf16. Il risultato sposta il dibattito: il formato a 8 bit è quasi indistinguibile dal calcolo a piena precisione nei motori GGUF ed EXL3, mentre il 4 bit introduce una penalità che cresce con la profondità del contesto.

L’autore ha provato 35 quantizzazioni dei pesi con llama.cpp, ExLlamaV3 e vLLM. Ogni configurazione è stata valutata con cache a 16, 8 e, dove supportato, 4 bit. Il dataset mescola task agentici generati dal modello a piena precisione e testi settoriali diversi, con contesti fino a 64k token per riga.

8 bit: quasi una cache gratuita

I numeri sulla memoria spiegano perché il tema è così caldo. A 64k token, una cache a 16 bit pesa 4 GiB. Scendere a 8 bit porta l’ingombro a 2,13 GiB con llama.cpp ed ExLlamaV3 e a 2 GiB con vLLM FP8: un risparmio di 1,9–2 GiB. In termini di divergenza KL, l’effetto su llama.cpp ed ExLlamaV3 è inferiore a 0,00012, un movimento che l’autore considera dentro il rumore numerico. vLLM aggiunge da 0,0004 a 0,0006, un valore ancora piccolo ma sistematico, forse legato al passaggio da FlashAttention a FlashInfer quando si attiva la cache FP8.

Il 4 bit non è una scorciatoia lineare

Con cache a 4 bit la lettura cambia. In llama.cpp il formato q4_0 aggiunge da +0,0016 a +0,0027 di KL. L’effetto relativo dipende dalla precisione dei pesi: su quantizzazioni di classe Q3 l’incremento è del 6–10 per cento, su UD-Q4_K_XL sale al 39 per cento, su Q8_0 arriva al 390 per cento. In quest’ultimo caso la divergenza passa da 0,0007 a 0,0034, superando un UD-Q5_K_XL con cache a 16 bit. ExLlamaV3 mostra un andamento simile: la penalità cresce con la precisione dei pesi, da circa +0,0002 sui modelli a 2,0–2,5 bpw fino a +0,0032–+0,0033 sui pesi a 6–8 bpw.

Nei documenti lunghi il danno non è uniforme. Su Q8_0 con cache q4_0 si passa da +0,0035 nei primi 4k token a +0,0041 nella fascia 16–32k; su UD-Q5_K_XL da +0,0030 a +0,0038; su ExLlamaV3 8.0 bpw da +0,0041 a +0,0050. L’aumento relativo è del 15–30 per cento rispetto ai primi 4k. Le stesse quantizzazioni con cache a 16 bit non mostrano variazioni, quindi il segnale è chiaro: è la cache a 4 bit a degradare con la posizione. L’autore si aspetta che a contesti da 128k token in su il framework peggiori ulteriormente.

Il confronto con i checkpoint vLLM aggiunge un’altra variabile. Tutti i checkpoint vLLM testati sono battuti da quantizzazioni GGUF o EXL3 più piccole, in parte per via della quantization delle attivazioni. Il checkpoint NVFP4 di NVIDIA esegue i layer MLP come W4A4 e l’attenzione come FP8 W8A8; il FP8 di Qwen è W8A8 su tutta la rete. Rieseguendo NVFP4 e FP8 con i kernel Marlin di vLLM, che mantengono le attivazioni in bf16, la divergenza KL di NVFP4 scende da 0,0256 a 0,0117 e quella di FP8 da 0,0039 a 0,0028. Anche così il risultato pareggia soltanto un UD-Q5_K_XL più piccolo di 8,7 GiB.

Per chi valuta deployment on-premise, il punto strutturale è che il risparmio di memoria non è un parametro unico: va letto insieme al tipo di pesi e alla lunghezza del contesto. La cache a 8 bit è quasi trasparente e offre il doppio del contesto utile o libera VRAM per modelli più grandi. Il 4 bit, al contrario, penalizza proprio i modelli con pesi più precisi e i contesti lunghi, cioè i due scenari in cui l’inference locale promette più valore. In workload agentici con finestre da decine di migliaia di token, la corruzione della cache a 4 bit non è rumore uniforme: si accumula man mano che il token è più lontano dal prompt, toccando le decisioni più sensibili alla coerenza di lungo periodo. AI-RADAR offre su /llm-onpremise framework analitici per confrontare questi trade-off.