GGUF, quantizzazione e VRAM: calcolare la memoria per eseguire modelli in locale

La quantizzazione riduce i pesi, ma non tutta la memoria necessaria

La quantizzazione rappresenta i pesi di un modello con una precisione numerica inferiore, riducendo lo spazio occupato e, su alcuni sistemi, accelerando l’inferenza. In GGUF si trovano etichette come Q4_K_M, Q5_K_M e Q8_0. Sono indicazioni sulla quantizzazione, non una specifica completa dell’utilizzo di memoria né una garanzia di qualità o velocità.

GGUF è un contenitore per modelli usato spesso con llama.cpp e con strumenti basati su questo motore. Non è sinonimo di quantizzazione: può contenere pesi con diversi tipi e livelli di precisione. Inoltre, «Q4» non significa che ogni parametro occupi esattamente quattro bit. Metadati, scale e parti memorizzate con una precisione diversa aumentano le dimensioni. Quando disponibile, è quindi preferibile controllare la dimensione effettiva del file quantizzato che verrà caricato.

Per dimensionare un’installazione bisogna distinguere almeno quattro componenti: pesi, cache chiave-valore (KV), memoria temporanea per il calcolo e overhead del motore. Il totale dipende dall’architettura del modello, dal contesto, dal batch, dalla distribuzione tra i dispositivi e dal software. Un calcolo basato soltanto sul numero di parametri può escludere una configurazione che entrerebbe in memoria oppure far sembrare fattibile un’installazione che poi non riesce a riservare spazio per la conversazione.

La prima domanda non è «qual è la GPU migliore?», ma «quale modello, contesto, concorrenza e latenza mi servono?». Solo dopo si può stimare la memoria e provare configurazioni compatibili. Per confrontare motori o modelli diversi, consulta una comparativa e definisci un carico di lavoro comune; per esplorare alternative di inferenza locale, filtra in base al compito e all’hardware disponibile.

Che cosa indicano Q4_K_M, Q5_K_M e Q8_0

In generale, quantizzare significa ridurre la precisione con cui vengono memorizzati i pesi. Il vantaggio atteso è occupare meno memoria per i pesi; il possibile costo è una differenza nelle risposte rispetto al modello di riferimento. Il rapporto tra i due effetti non è uguale per tutti i modelli e non si può riassumere in modo affidabile con una percentuale fissa di perdita.

Nelle varianti GGUF, il numero indica una classe di quantizzazione, ma non descrive da solo la composizione completa del file. I suffissi distinguono metodi e assegnazioni di precisione. In un’etichetta come Q4_K_M, la famiglia K e la variante M fanno parte dello schema: non vanno interpretate come un moltiplicatore uniforme di quattro bit. La dimensione del file è un dato più attendibile che dedurre il numero esatto di byte dal nome.

Come indicazione qualitativa, una configurazione Q4 richiede di solito meno spazio per i pesi rispetto a una Q5 o Q8 dello stesso modello. Q5 e Q8 conservano più precisione nei pesi, ma occupano più memoria. Questo non dimostra che produrranno risultati migliori in ogni compito: occorre misurarli nell’applicazione concreta. Un classificatore, un generatore di codice e un chatbot generalista possono reagire in modo diverso alla stessa quantizzazione.

GGUF consente anche di scegliere diversi formati di quantizzazione per una stessa famiglia di modelli, ma la compatibilità dipende dal motore e dalla sua implementazione. Non presumere che due file con etichette simili si eseguano alla stessa velocità o producano gli stessi risultati. Verifica che il modello sia compatibile con il motore, che venga caricato il backend previsto e che la valutazione confronti la stessa revisione del modello.

Calcolare separatamente pesi, cache KV e margine

Per una prima stima, la dimensione dei pesi residenti può basarsi sul file del modello effettivamente caricato. Se si conosce solo il numero di parametri, si può usare come orientamento il prodotto tra parametri e byte medi per parametro; tuttavia, il valore medio deve corrispondere alla quantizzazione reale, non al numero riportato nel nome come se fosse esatto. Nei file GGUF, la combinazione di precisioni diverse può rendere questa semplificazione imprecisa.

La cache KV conserva informazioni sui token precedenti di cui il modello ha bisogno durante la generazione. In genere cresce con la lunghezza della sequenza e con la dimensione del batch, e dipende dall’architettura: numero di layer, teste KV, dimensione delle teste e tipo di dato della cache. Una formula generale è: due volte il numero di layer, moltiplicato per teste KV, dimensione della testa, token memorizzati, batch e byte per elemento. La formula va adattata all’implementazione e alle architetture che usano meccanismi di attenzione differenti.

Per ottenere le dimensioni pertinenti, consulta la configurazione del modello e la documentazione del motore invece di dedurle dal solo numero di parametri o dalle teste di query. Nell’attenzione raggruppata, le teste KV possono essere meno numerose delle teste di query: calcolare la cache come se ogni testa di query ne avesse una propria può quindi sovrastimare il risultato. Altri progetti architetturali possono richiedere una formula diversa.

La memoria temporanea e l’overhead non equivalgono a una percentuale fissa dei pesi. Il prefill di prompt lunghi può richiedere buffer più grandi rispetto alla generazione token per token. Incidono anche frammentazione, backend, prenotazione della memoria, librerie e numero di GPU. Il metodo di stima di AIMultiple separa pesi, KV, attivazioni e overhead: è utile come struttura di calcolo, ma i risultati vanno verificati per il modello, il motore e la configurazione esatti.

Non esiste una risposta univoca e verificabile alla domanda «quanta VRAM serve per un 7B Q4_K_M con 4096 token?» senza specificare modello, batch, tipo di cache KV, motore, distribuzione e margine. Un contesto di 4096 token indica la lunghezza della sequenza, ma da solo non determina la cache: servono le dimensioni dell’architettura e altri dettagli. La dimensione del file può fornire un riferimento per i pesi, non per il fabbisogno totale.

Scegliere tra VRAM, RAM e offload parziale

La VRAM disponibile stabilisce quanto può rimanere nella GPU; la RAM di sistema può servire a caricare parti del modello quando il motore supporta l’offload parziale. Ma molta RAM non garantisce automaticamente un’esperienza interattiva: trasferire dati tra RAM e GPU può ridurre le prestazioni, e il risultato dipende dal collegamento tra i due componenti e dal modo in cui vengono distribuiti i layer.

Se servono risposte rapide e frequenti, dai priorità a una configurazione in cui pesi e cache attiva entrino nella memoria della GPU con un margine adeguato. Se invece l’obiettivo è eseguire un modello che altrimenti non entrerebbe, l’offload su RAM può risolvere un problema di capacità al costo di una maggiore latenza. Non confondere «si carica» con «rispetta il requisito di velocità».

Su Apple Silicon la memoria unificata è condivisa tra CPU e GPU, ma viene utilizzata anche dal sistema e dalle altre applicazioni. La RAM installata non coincide necessariamente con quella disponibile per il modello. Anche con più GPU non basta sommarne la capacità: ci sono costi di comunicazione e riserve per dispositivo, e il software deve supportare la distribuzione prevista.

La larghezza di banda incide soprattutto sulla generazione, quando i pesi vengono letti ripetutamente. La capacità determina se i dati entrano in memoria; la larghezza di banda e l’implementazione contribuiscono alla velocità una volta caricati. Motore, supporto dei kernel, tipo di quantizzazione e concorrenza possono cambiare il risultato: scegliere l’hardware solo in base alla VRAM o a una larghezza di banda teorica lascia fuori fattori decisivi.

Non esiste un minimo universale per 7B Q4 e 4096 token

Un modello da 7 miliardi di parametri in Q4_K_M occupa in genere meno memoria per i pesi rispetto alla stessa famiglia in Q5 o Q8, ma questo principio non si traduce in un valore minimo universale di VRAM o RAM. Il numero di parametri non descrive interamente l’architettura, i tensori mantenuti a una precisione diversa o la dimensione esatta del file.

Nemmeno 4096 token bastano per calcolare la cache. Per stimarla servono almeno architettura, numero di layer, teste KV, dimensione per testa, tipo di dato della cache KV e batch. Se si usa una finestra di attenzione o un meccanismo diverso, il calcolo cambia. La risposta corretta è misurare una configurazione specifica, non garantire che qualsiasi 7B Q4_K_M funzioni con una quantità fissa di memoria.

Come procedura pratica, usa la dimensione effettiva del file come riferimento per i pesi, calcola la cache KV con i parametri dell’architettura e aggiungi memoria temporanea e riserva del motore. Poi verifica il picco durante il caricamento e la generazione. Se il sistema dispone solo di RAM, l’esecuzione può essere possibile con un motore compatibile, ma la velocità non si può dedurre dalla dimensione del modello.

Di conseguenza, non è consigliabile acquistare una scheda video sulla base di una tabella generica del tipo «7B = X GB». Prima definisci il modello esatto e l’obiettivo di servizio: utente singolo o concorrenza, contesto normale e massimo, risposta in tempo reale o elaborazione batch. Un caso d’uso definito permette di dimensionare il sistema; il solo numero di parametri non basta.

Prestazioni: misura velocità, prima risposta e concorrenza

I token al secondo descrivono una parte delle prestazioni, ma occorre specificare se la misura riguarda il prefill del prompt o la generazione. La latenza fino al primo token comprende ricezione, prefill e preparazione: può aumentare con prompt estesi anche quando la generazione successiva è rapida. Per un’applicazione interattiva sono importanti entrambi i valori.

Il confronto deve mantenere costanti modello, prompt, lunghezza dell’output, contesto, batch, motore, versione software e temperatura del dispositivo. Esegui più prove e registra mediana e variabilità, oltre alla memoria massima. Non confrontare un test con una risposta breve con un altro che usa un contesto esteso: misurerebbero carichi diversi.

Le fonti fornite non sono sufficienti per indicare i token al secondo o la latenza attesi per un 13B Q5_K_M su una GPU da 16 GB. Il risultato dipende dalla GPU specifica, dalla larghezza di banda, dal modello e dalla sua architettura, dal motore, dai layer scaricati, dal contesto e dalla configurazione. Una stima della capacità non sostituisce un benchmark eseguito sulla macchina interessata.

Per un servizio multiutente, misura anche il throughput aggregato e la latenza per richiesta sotto carico. Un motore ottimizzato per richieste simultanee può comportarsi diversamente da uno locale pensato per una sola conversazione. Il test deve riprodurre l’uso reale: un singolo utente che genera codice non rappresenta un server con più sessioni e prompt lunghi.

Valutare la perdita di qualità sui compiti rilevanti

Non esiste una singola percentuale di degrado che descriva il passaggio da Q8 a Q4 per tutti i modelli e tutti i compiti. La differenza dipende dall’architettura, dal metodo di quantizzazione, dal set di valutazione e dal criterio di punteggio. Un’affermazione come «perde il 2%» non è interpretabile se non specifica metrica, dati, versione e condizioni del confronto.

Prepara una valutazione con esempi rappresentativi e risposte attese, oppure con criteri di punteggio definiti prima dei test. Per la classificazione, usa un set etichettato e confronta accuratezza, precisione, richiamo o F1 in base al costo di falsi positivi e falsi negativi. Per la generazione, valuta aderenza alle istruzioni, correttezza verificabile, formato ed errori critici con una griglia coerente. Per il codice, esegui test automatici sulle risposte: non basta un’impressione soggettiva che «sembri corretto».

Confronta ogni quantizzazione con lo stesso modello di riferimento usando prompt, modello di conversazione e parametri di generazione identici. Mantieni gli stessi seed quando il motore lo consente e ripeti i compiti stocastici. Riporta sia la media sia i fallimenti gravi: una media simile può nascondere un calo significativo in un gruppo ristretto di casi.

Il lavoro disponibile su alphaXiv su Qwen3.5-4B descrive un caso specifico di inferenza INT4 con distillazione consapevole della quantizzazione, decodifica speculativa e una GPU A10G. È una prova relativa a quel sistema e a quella configurazione, non dimostra che ogni Q4 in GGUF mantenga la qualità o raggiunga la stessa accelerazione. Inoltre, l’estratto non permette di generalizzare i risultati a un modello da 13B o a un’altra GPU.

Criteri per scegliere quantizzazione e hardware

Parti dal livello di qualità richiesto dal compito, non dalla quantizzazione più aggressiva che entra in memoria. Se la qualità di riferimento è indispensabile e hai memoria sufficiente, mantieni una precisione superiore e verifica la differenza rispetto a Q4. Se il limite è la memoria, prova Q4_K_M, misura le prestazioni e controlla la qualità. Se i risultati non bastano, valuta Q5, una riduzione del contesto o un modello diverso prima di concludere che serva necessariamente acquistare hardware.

La scelta dell’hardware deve tenere conto della capacità di memoria, della larghezza di banda, della compatibilità con il motore e della facilità di manutenzione. Un sistema con VRAM sufficiente può comunque essere lento se la quantizzazione non dispone di kernel efficienti o se una parte del modello viene trasferita. Al contrario, un modello che entra nella RAM può essere utile per test o carichi non interattivi, pur senza raggiungere la latenza di una GPU.

Valuta ogni combinazione con una tabella decisionale personalizzata: modello, quantizzazione, contesto, batch, picco di memoria, latenza al primo token, velocità di generazione e punteggio di qualità. Questa tabella aiuta a giustificare un acquisto perché rende esplicito il requisito che manca davvero. Evita anche di usare il prezzo di una scheda come sostituto di una prova.

Per confrontare motori e configurazioni, mantieni lo stesso protocollo e consulta una comparativa tecnica. Per trovare modelli compatibili, filtra in base ad architettura, formato, licenza e dimensione effettiva del file; non presumere che tutte le varianti abbiano lo stesso comportamento.

Conclusione: la stima iniziale va verificata sul sistema reale

GGUF semplifica la distribuzione di modelli locali con diverse quantizzazioni, ma il nome Q4, Q5 o Q8 non basta a dimensionare un’installazione. Usa la dimensione reale del file per stimare i pesi, calcola la cache KV in base all’architettura e alla configurazione prevista, quindi aggiungi buffer e riserva del motore.

Non esiste un valore universale di VRAM per un modello 7B Q4_K_M con 4096 token, né una previsione affidabile dei token al secondo per un 13B Q5_K_M su una GPU da 16 GB senza ulteriori dettagli. Presentare questi valori come garanzie nasconderebbe le variabili che determinano il risultato.

La decisione finale richiede due verifiche: memoria e prestazioni sul carico reale, e qualità nei compiti che giustificano l’installazione. Registra contesto, batch, motore, versioni, picco di memoria, latenza e metriche di qualità. Potrai così scegliere con dati confrontabili tra quantizzazione, contesto più breve, offload parziale, un altro modello o un aggiornamento hardware.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.