Come valutare i modelli locali quantizzati: qualità e velocità sul tuo hardware

Perché misurare prima di scegliere

La quantizzazione riduce la memoria necessaria per caricare i pesi, ma da sola non permette di prevedere quanto cambierà la qualità per un’attività specifica. E sapere quanti parametri ha un modello non basta per stimare la velocità sul tuo computer: contano il processore, la memoria disponibile, la configurazione di inferenza, il contesto e il carico del sistema. La scelta utile si basa su misurazioni effettuate con input rappresentativi dell’uso reale.

Uno studio del 2025 ha confrontato sei modelli eseguiti localmente con Ollama in un sistema di recupero delle informazioni accademiche, valutando accuratezza, latenza fino al primo token e velocità di generazione. È un esempio pertinente di approccio empirico, ma non dimostra che una specifica quantizzazione GGUF mantenga la qualità con altri modelli, attività o computer. Questa guida traduce quel principio in un protocollo personale: prima definisci che cosa significa avere successo e quali prestazioni ti servono; poi confronta ogni configurazione con un riferimento esplicito.

1. Definisci l’attività e la baseline

Inizia descrivendo che cosa farà il modello in produzione: chi lo userà, quali input riceverà, che output dovrà produrre, quali errori sono costosi e quanto può impiegare. Per estrarre campi servono misure di corrispondenza dei valori; per rispondere sulla base di documenti occorre verificare la fedeltà alle fonti; per generare codice bisogna eseguire test, non limitarsi a giudicare se la risposta sembra plausibile. Se riunisci attività diverse in un unico punteggio, rischi di nascondere problemi importanti.

Prepara un insieme di test che rappresenti la distribuzione prevista: tipi di input frequenti, casi limite, input ambigui ed esempi difficili. Per ogni caso includi un riferimento verificabile, come la risposta corretta, i campi attesi, test automatizzati o una rubrica di valutazione, e registra da dove proviene. Separa un insieme di sviluppo, che puoi usare per modificare prompt o parametri, da un insieme di valutazione che non userai per ottimizzare ripetutamente. Così riduci il rischio di scegliere una configurazione che funziona bene solo sugli esempi già visti.

2. Misura la qualità in base al lavoro da svolgere

La qualità non si riduce a una sola metrica. Per risposte con una soluzione nota, calcola l’accuratezza o il tasso di successo; per l’estrazione, la corrispondenza esatta per campo e per record; per la classificazione, indica precisione e richiamo quando i costi dei falsi positivi e dei falsi negativi sono diversi. Per la generazione aperta, usa una rubrica esplicita — per esempio factualità, copertura, chiarezza e utilità — e conserva esempi di errori per interpretare il punteggio. Una valutazione automatica o basata su un altro modello può aiutare a esaminare molti casi, ma non va considerata una verità di riferimento senza averne verificato la validità per quello specifico uso.

Quando il sistema richiede JSON, una struttura fissa, una chiamata a uno strumento o un limite di lunghezza, misura la formattazione come criterio indipendente. Verifica se l’output supera il parser effettivamente usato e rispetta campi obbligatori, tipi, enumerazioni e vincoli. Se il campionamento non è deterministico, registra anche la coerenza tra esecuzioni: una singola risposta corretta non dimostra che il sistema sia affidabile. Per le attività ad alto rischio, conteggia esplicitamente gli errori gravi e definisci una regola di rifiuto o di revisione umana prima della valutazione.

3. Misura velocità, latenza e memoria

Registra almeno la latenza fino al primo token e la velocità di generazione in token al secondo. La prima indica quanto aspetta una persona prima di vedere una risposta; la seconda descrive la produzione successiva. Aggiungi il tempo totale necessario per completare l’output: una risposta lunga può richiedere molto tempo anche con un’elevata velocità di generazione. Specifica quale strumento fornisce ogni misura e che cosa include: caricamento iniziale del modello, preparazione del prompt, elaborazione dell’input o solo generazione.

Annota l’uso della memoria durante l’inferenza e il contesto testato. La dimensione del file GGUF non corrisponde automaticamente alla memoria totale necessaria: il contesto, la cache di attenzione, il runtime e il sistema operativo possono incidere. Confronta lo stesso modello e la stessa attività usando identici limiti di contesto, parametri di generazione e hardware. Se una configurazione non entra in memoria e ricorre allo swap su disco o a un percorso di esecuzione diverso, registralo: il confronto non è più equivalente.

4. Esegui un confronto controllato

Per attribuire le differenze alla configurazione che stai valutando, mantieni costanti l’insieme di input, il template del prompt, il limite di token, la temperatura e gli altri parametri rilevanti. Annota il nome e la revisione del modello, la provenienza del file GGUF e la quantizzazione esatta. Registra anche le versioni di Ollama o LM Studio, il sistema operativo, il processore, l’acceleratore, la memoria e le opzioni di offloading dei layer. Specifica nel protocollo se il modello era già caricato o se misuri anche il caricamento iniziale.

Esegui prima una prova di riscaldamento, se serve a caricare e stabilizzare il modello, e non mescolarla alle misurazioni abituali, a meno che l’avvio non faccia parte dei requisiti operativi. Ripeti ogni test più volte e riporta mediana e variabilità, non l’esecuzione più favorevole. Se l’applicazione produce output stocastici, imposta il seed quando lo strumento lo consente oppure valuta più campioni con la stessa politica. Alterna l’ordine delle configurazioni se il carico termico o di sistema può cambiare durante la sessione. Ripeti i test in condizioni simili a quelle di distribuzione, non solo subito dopo aver riavviato il computer.

5. Scegli tra quantizzazione e dimensione del modello

Per prima cosa verifica se ciascuna opzione soddisfa i requisiti di qualità e prestazioni definiti in anticipo. Scarta le configurazioni che non superano un criterio critico, anche se ottengono risultati migliori su un’altra metrica. Tra quelle ammissibili, confronta tempo totale, latenza iniziale, memoria e stabilità del formato. Una quantizzazione più aggressiva di un modello grande può essere preferibile se mantiene la qualità necessaria e rientra nei limiti hardware; se invece perde precisione in un’attività sensibile, un modello più piccolo con quantizzazione più conservativa potrebbe dare risultati migliori. Non esiste una regola generale che risolva questa scelta senza misurazioni.

È anche possibile che l’opzione migliore sia un modello diverso da quello previsto inizialmente, o che il flusso assegni le attività semplici a un modello rapido e riservi quello più capace ai casi difficili. Lo studio su Ollama citato in precedenza ha rilevato differenze di velocità e accuratezza tra modelli nel proprio sistema RAG; i suoi risultati non garantiscono lo stesso comportamento in un’altra configurazione. Per motivare una decisione tecnica, conserva i risultati per tipo di attività e spiega quali compromessi accetta il team. Se due alternative sono molto vicine, considera l’incertezza delle misurazioni e ripeti il test prima di trarre una conclusione definitiva.

6. Limiti e buone pratiche

Un insieme di test piccolo può non rilevare errori rari; uno troppo simile agli esempi di sviluppo può favorire la configurazione adattata a quei casi. Anche un punteggio aggregato può nascondere problemi legati a lingua, lunghezza, tipo di documento o classe minoritaria. Esamina i risultati suddivisi per categoria e conserva esempi degli errori. Se una differenza rientra nella variabilità tra esecuzioni, non descriverla come un miglioramento certo senza ulteriori ripetizioni o altre evidenze.

I risultati di uno studio pubblicato su un sistema RAG accademico costituiscono evidenza relativa a quello specifico lavoro e alla sua configurazione, non una valutazione di GGUF né una raccomandazione universale. Allo stesso modo, valori generici che attribuiscono una perdita fissa di qualità a ogni livello di quantizzazione non sostituiscono un test sul modello e sull’attività specifici. Documenta la provenienza dei file, evita di includere dati personali nei prompt di test senza autorizzazione e prevedi revisione umana o meccanismi di rifiuto quando un errore può causare danni. Dopo la distribuzione, controlla periodicamente un campione dell’uso reale e ripeti il protocollo se cambiano modello, runtime, hardware o distribuzione degli input.

Continua a esplorare

Correzioni e trasparenza

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