Il progetto llama.cpp, uno dei runtime di riferimento per eseguire LLM in locale, ha aggiunto il supporto per una cache chiave-valore (KV cache) in formato FP8. La modifica non aggiunge un nuovo modello né promette benchmark spettacolari: interviene su un componente invisibile ma decisivo per chi fa girare modelli su GPU consumer, workstation o server senza dipendere dal cloud.

La KV cache è il meccanismo con cui un modello transformer conserva le rappresentazioni dei token già generati, evitando di ricalcolarle a ogni passo. È una struttura che cresce linearmente con la lunghezza della sequenza e con il numero di layer: in pratica, più lungo è il contesto, più VRAM viene consumata. Finora, in molte configurazioni, questa cache veniva memorizzata a 16 bit. Passare a 8 bit in virgola mobile (FP8) dimezza la memoria necessaria per quella specifica componente, a parità di token gestiti. Non è una riduzione uniforme dell'intero modello, ma incide su una delle voci che più spesso costringe a tagliare la finestra di contesto o a passare a schede con più memoria.

Per chi fa deployment self-hosted, il significato è diretto: consente di spingere modelli con contesti più lunghi su hardware che altrimenti non li sosterrebbe. Questo sposta l'equilibrio del TCO. Invece di acquistare una GPU con più VRAM o di cedere al cloud per carichi con documenti lunghi, un team può rimanere su infrastruttura locale, con latenza prevedibile e dati sotto controllo. Il vantaggio non è solo economico: nei contesti regolati o air-gapped, mantenere l'inference on-premise è spesso un requisito, non una preferenza.

Il secondo effetto riguarda la maturità dell'ecosistema intorno ai runtime locali. Llama.cpp è diventato un laboratorio di ottimizzazioni che poi influenzano altri framework e tool. L'adozione del formato FP8 per la KV cache normalizza un approccio che prima era limitato a contesti di ricerca o a implementazioni proprietarie. Non è una coincidenza che il tema emerga in un momento in cui i modelli open-weight spingono verso finestre di contesto sempre più estese e gli utenti chiedono di sfruttarle senza dover aggiornare l'hardware.

Certo, FP8 non è gratis. La riduzione di precisione può introdurre degradazione nella qualità delle risposte, soprattutto su sequenze lunghe o compiti che richiedono attenzione fine. E il supporto hardware per FP8 è eterogeneo: alcune GPU lo accelerano nativamente, altre lo emulano via software, con costi di calcolo che possono erodere parte del beneficio in bandwidth. Ma il punto non è se FP8 sostituirà ovunque FP16. È che il runtime sta offrendo una leva in più per bilanciare memoria, qualità e costi. Chi valuta un deployment on-premise oggi ha un parametro in più da testare, non una soluzione universale.

In questo senso, la notizia è meno piccola di quanto sembri. Segnala che l'ottimizzazione dell'inference locale sta maturando dal livello dei modelli a quello dei runtime, e che la corsa ai contesti più lunghi non passerà solo da hardware più potente ma anche da scelte di rappresentazione numerica. Per la sovranità dei dati, ogni riduzione della barriera hardware rende più credibile l'alternativa al cloud.