Il segnale non è il modello, è il runtime che amministra la VRAM

Un modello dense da 27 miliardi di parametri con una finestra di contesto da 100.000 token su una scheda consumer da 16 GB non dovrebbe essere una notizia particolarmente comoda. Eppure il setup documentato su Reddit sposta l’attenzione su un dettaglio che spesso resta invisibile nelle discussioni sull’hardware: il runtime di inference non si limita a eseguire il modello, ma negozia in continuazione la memoria tra pesi, cache e attivazioni. Il risultato, tra 47 e 50 token al secondo con 15,93 GB di VRAM occupati e circa 70 MB liberi, è il prodotto di una gestione quasi maniacale di quel budget, non di un salto generazionale della GPU o del modello scelto.

Il modello è una versione community di Qwen3.8-27B, quantizzata con schema IQ4_XS e pubblicata su Hugging Face da jrell. Il motore è beellama.cpp, un fork non mainstream scelto per un motivo preciso: introduce tipi di cache chiamati kvarn che non sono disponibili nel progetto principale. La cache K usa kvarn5, la cache V usa kvarn4. È una configurazione asimmetrica, con una precisione diversa per chiavi e valori. Questo dettaglio, apparentemente minore, è il cuore della storia: non è il modello a essere speciale, né la scheda, ma il modo in cui il software decide cosa comprimere e dove mantenere più informazione.

Per chi segue AI-Radar, il segnale è chiaro. Il deployment locale di LLM non è più solo una questione di scegliere la scheda con più VRAM o il modello con meno parametri. La leva più economica, almeno in questo caso, è stata una variazione del 6% nell’occupazione della cache, ottenuta modificando il tipo di quantization sul vettore V. Quella percentuale ha permesso di estendere il contesto da 88.000 a 100.000 token senza cambiare hardware né modello. In un contesto in cui le schede consumer hanno budget di memoria rigidi, piccoli risparmi sul software possono spostare il limite di ciò che è realisticamente eseguibile.

Cache KV asimmetrica: perché il 6% non è solo un numero

La cache KV è uno dei punti in cui la pressione sulla VRAM cresce in modo significativo quando si allungano i contesti, perché il sistema deve conservare le rappresentazioni necessarie all’attenzione per ogni token. Su una GPU da 16 GB, quella pressione diventa presto il vincolo dominante, più dei pesi del modello. La scelta di usare kvarn5 per la cache K e kvarn4 per la cache V introduce un trattamento differenziato: la componente chiave mantiene una precisione più elevata, mentre i valori vengono compressi un po’ di più. La fonte descrive la quantization kvarn come quasi lossless, con una fedeltà paragonabile a q5 ma un footprint di memoria da q4. È una affermazione da verificare, ma il principio è concreto: non tutta l’informazione nella cache ha lo stesso valore, e il runtime può sfruttare questa asimmetria.

Il passaggio dalla coppia kvarn5/kvarn5 alla coppia kvarn5/kvarn4 ha liberato circa il 6% di VRAM. Non sembra molto, ma quando la scheda viaggia oltre i 15,9 GB occupati, quel margine è esattamente ciò che separa un contesto da 88.000 token da uno da 100.000. In pratica, il setup è arrivato al limite fisico: 70 MB liberi sono pochissimi, e qualunque picco, anche minimo, può far fallire l’inference. La lezione non è che il 6% sia un risultato miracoloso, ma che la differenziazione tra runtime si gioca su controlli fini di questo tipo, non solo su flag generici di compressione.

A un livello più ampio, questo dettaglio segnala un cambiamento di prospettiva. Per anni il dibattito sull’inference locale è stato dominato dalla quantità di VRAM, dalla larghezza di banda e dalle dimensioni dei modelli. Qui il vincolo viene aggirato con una combinazione di tipi di cache non disponibili nel progetto principale. La scelta di un fork come beellama.cpp, con le sue estensioni specifiche, diventa essa stessa una decisione architetturale. Non è una mossa da principianti: significa accettare un software con una governance diversa, un supporto potenzialmente ridotto e un ciclo di aggiornamento meno prevedibile. Ma per chi ha bisogno di contesti lunghi su hardware consumer, può essere la differenza tra un deployment possibile e uno irrealistico.

Decodifica speculativa e coda di precisione: la qualità non è uniforme

Il setup documentato non punta solo a risparmiare memoria. Attiva anche la decodifica speculativa con --spec-type draft-mtp e due draft token, sfruttando il supporto Multi-Token Prediction del modello. In sostanza, il sistema prova a proporre più token per volta e poi li valida, con l’obiettivo di mantenere una velocità di generazione elevata anche quando la cache è compressa e la scheda è quasi satura. Il risultato dichiarato, tra 47 e 50 token al secondo, va letto in questa luce: non è solo il modello a generare velocemente, ma il runtime a orchestrare memoria, predizione e validazione in un budget che lascia pochissimo respiro.

Il comando mantiene inoltre gli ultimi 1.024 token a piena precisione, attraverso --kv-tail-tokens 1024. Questo è un compromesso selettivo: il contesto più recente, spesso più rilevante per la coerenza della generazione, resta intatto, mentre il resto della cache viene compresso. È una forma di gerarchia della precisione, non una riduzione uniforme. Protegge la qualità dell’output recente senza dover mantenere l’intera finestra allo stesso livello. Il costo in memoria è limitato a quella coda, ma il beneficio può essere rilevante su compiti che dipendono dagli ultimi scambi, come l’analisi di documenti lunghi in cui la parte finale della finestra ha un peso specifico.

Le tre leve — cache KV asimmetrica, coda di precisione e decodifica speculativa — non sono indipendenti. La decodifica speculativa tende a consumare risorse e a generare lavoro aggiuntivo, ma in questo caso serve a mitigare il costo della compressione e a mantenere una frequenza accettabile. Al tempo stesso, la coda a piena precisione aiuta a non degradare troppo la qualità dove conta. L’equilibrio è fragile: la VRAM libera è quasi inesistente, quindi il sistema non ha margine per assorbire variazioni. Ma la configurazione mostra che il serving locale sta diventando un problema di politiche di gestione della memoria, non solo di potenza bruta.

Self-hosted, sovranità e TCO: il punto di convenienza si sposta

Per chi valuta il self-hosted, il setup ha una implicazione immediata. Una scheda consumer di fascia media può ora sostenere contesti lunghi che normalmente spingerebbero verso configurazioni con più VRAM o verso API di terze parti. Questo cambia il punto di convenienza per i workload sensibili al dato: team legali, sanitari o finanziari che devono mantenere documenti lunghi sotto controllo possono esplorare l’inference locale senza dover necessariamente investire in hardware accelerato di fascia enterprise. La RTX 4070 Ti SUPER non è una scheda da data center, ma in questa configurazione si avvicina a un caso d’uso reale.

Il ragionamento sul TCO va però fatto con onestà. Il costo dell’hardware è solo una parte del totale. Un runtime fork non mainstream, tipi di cache specifici, comandi lunghi e un margine di memoria di 70 MB introducono costi operativi e rischi. Chi replica il setup deve validare la qualità su compiti lunghi, monitorare i picchi e prepararsi a gestire crash o regressioni del fork. Inoltre, il dato sui 50 token al secondo riguarda la generazione; non dice nulla sulla latenza di primo token, sul tempo di prefill o sul comportamento con richieste concorrenti. Il TCO, in questo contesto, include il tempo tecnico necessario per trasformare una prova in un servizio affidabile.

Nonostante questi limiti, il segnale per l’infrastruttura è rilevante. La sovranità dei dati non è solo una scelta tra cloud e on-premise, ma una questione di soglie di convenienza. Se il software di serving riesce a spostare il punto in cui un contesto lungo diventa gestibile su hardware consumer, allarga la platea di organizzazioni che possono realisticamente evitare di inviare documenti a API esterne. Questo non elimina il cloud, ma ne riduce la presa su una classe specifica di workload sensibili. I framework raccolti su AI-Radar hanno senso proprio perché trade-off di questo tipo non si misurano solo sulla scheda tecnica, ma sulla combinazione di runtime, quantization e vincoli operativi.

I limiti del setup: margini, metriche e replicabilità

Il primo limite è fisico: 70 MB liberi su 16 GB non lasciano margini per picchi o multitasking. Basta un framebuffer più alto, un’altra applicazione che usa la GPU o un picco di allocazione per far cadere il processo. In un contesto di laboratorio, il risultato regge. In produzione, un margine così stretto è una fragilità strutturale. Questo non sminuisce il valore della prova, ma ne definisce il perimetro: è una dimostrazione di possibilità, non una configurazione operativa pronta.

Il secondo limite è metodologico. La fonte descrive la perdita di qualità sulla cache V come minima, ma non pubblica metriche standard. Non ci sono benchmark su compiti lunghi, né valutazioni comparative tra kvarn5/kvarn4, kvarn5/kvarn5 o altre combinazioni. Il risparmio del 6% è reale in termini di memoria, ma il costo in termini di fedeltà resta da quantificare. Chi volesse replicare il risultato dovrebbe costruire un proprio harness di valutazione, magari su riassunti, estrazione di informazioni o ragionamento su documenti lunghi, per verificare se la precisione asimmetrica regge sul proprio dominio. Non è una verifica banale, perché la cache KV tende a pesare in modo diverso a seconda della lunghezza e della struttura del contesto.

Il terzo limite è la dipendenza da un fork. beellama.cpp introduce i tipi kvarn non disponibili nel progetto principale. Questo significa che il setup può rompersi con un aggiornamento, essere meno testato o non beneficiare delle ottimizzazioni future del ramo principale. Per un team che valuta un deployment di medio periodo, la scelta del runtime diventa paragonabile alla scelta del modello o dell’hardware: non è un dettaglio di implementazione, ma un elemento del rischio tecnicico. La domanda da porsi non è solo se il setup funziona oggi, ma se potrà essere mantenuto, esteso e protetto nel tempo.

Cosa guardare nei prossimi mesi: cache KV, runtime e hardware consumer

Il caso documentato indica alcune traiettorie da monitorare. La prima è l’evoluzione dei tipi di cache nei runtime mainstream. Se i principali progetti di serving locale integrano varianti asimmetriche simili a kvarn, il vantaggio di dover usare fork si riduce, e il controllo della cache KV diventa una funzionalità standard. La seconda è la formalizzazione della qualità: senza metriche condivise sulla perdita introdotta dalla compressione di K e V, ogni setup resta un’isola. L’arrivo di benchmark specifici per contesti lunghi sarebbe un segnale di maturazione.

Un’altra traiettoria riguarda l’hardware. Se una scheda da 16 GB può essere portata a gestire contesti da 100.000 token con controlli software, il valore relativo delle configurazioni con più VRAM si riduce per una certa fascia di workload. Non sparisce, perché i margini restano stretti e le richieste concorrenti richiedono memoria aggiuntiva, ma la pressione a comprare più memoria si sposta in parte sul software. È un cambiamento che può influenzare le strategie di acquisto e il ciclo di vita delle GPU consumer.

Infine, va osservata l’interazione tra Multi-Token Prediction, decodifica speculativa e quantization della cache. Il fatto che un modello supporti nativamente MTP e che il runtime possa sfruttarlo con due draft token indica che il serving locale sta diventando un problema di co-progettazione tra modello e runtime. I prossimi segnali da seguire sono il supporto diffuso per MTP, la standardizzazione delle code di precisione e la comparsa di profili di memoria condivisi tra tool di deployment. Per AI-Radar, il punto è che la frontiera dell’inference on-premise non si misura più solo in parametri e teraflop, ma in come il software gestisce ogni MB di VRAM e decide cosa sacrificare per primo.