Come scegliere, quantizzare e valutare un modello linguistico locale

1. Definisci il problema prima di scegliere il modello

Un modello locale esegue l’inferenza su hardware sotto il tuo controllo, invece di inviare ogni richiesta a un servizio remoto. Questo può ridurre l’esposizione dei dati a terzi e consentire di lavorare offline dopo aver scaricato il modello e le relative dipendenze. Tuttavia, non garantisce di per sé la privacy: un’interfaccia, un’estensione, un registro delle attività o uno strumento connesso potrebbe comunque trasmettere informazioni.

Inizia descrivendo l’attività, i dati ammessi, il livello minimo di qualità e il volume previsto. Un modello piccolo può bastare per classificare messaggi o estrarre campi; un assistente che usa strumenti, interpreta documenti complessi o sostiene conversazioni lunghe richiede prove più rigorose. Il numero di parametri, da solo, non predice il risultato nel tuo caso specifico.

2. Scegli modello, licenza e formato

Confronta i modelli candidati che possono funzionare nel tuo ambiente e la cui licenza consente l’uso previsto. Consulta la scheda ufficiale del modello: architettura, dimensioni, limiti di contesto, lingue, capacità multimodali e condizioni di ridistribuzione. Verifica anche che il runtime scelto supporti quell’architettura e quella specifica variante dei pesi: un modello con molti parametri o una community attiva non è necessariamente adatto alla produzione.

GGUF è un formato comune nei flussi basati su llama.cpp e negli strumenti compatibili, ma non è un requisito universale per eseguire inferenza in locale. Altri stack utilizzano formati e motori differenti. Per ogni candidato, annota identificativo esatto, revisione dei pesi, formato, quantizzazione, runtime e configurazione. In questo modo potrai ripetere i test e rilevare le modifiche introdotte dagli aggiornamenti.

3. Quantizza solo dopo aver stabilito un riferimento

La quantizzazione riduce la precisione numerica dei pesi o di altri valori del modello per risparmiare memoria e, a seconda dell’hardware e del runtime, può modificare la velocità di inferenza. Il risparmio può rendere caricabili modelli che non entrerebbero nella loro rappresentazione a precisione più elevata, ma può anche ridurre la qualità. L’effetto dipende dal modello, dal metodo, dall’attività e dal backend: non si deve promettere una perdita fissa né presumere che un’etichetta a quattro o cinque bit predica da sola il risultato.

Q4_0, Q5_1 e Q4_K_M non sono denominazioni intercambiabili. Le varianti appartengono a formati e schemi differenti; prima di scaricare un modello, controlla la descrizione della quantizzazione e le dimensioni effettive del file. LoRA, invece, è una tecnica di adattamento tramite parametri aggiuntivi, non un livello di quantizzazione. Può essere combinata con alcuni flussi di quantizzazione, ma non è un’alternativa equivalente a Q4 o Q5.

4. Dimensiona memoria e hardware lasciando un margine

Per stimare lo spazio iniziale occupato dai pesi, moltiplica il numero di parametri per i byte utilizzati per rappresentarli. Per esempio, un modello da sette miliardi di parametri in FP16 richiede circa quattordici miliardi di byte per i pesi, prima di considerare gli altri consumi. Con una quantizzazione a quattro bit, il calcolo ideale dei pesi risulta inferiore, ma le dimensioni del file e la memoria effettivamente occupata non coincidono esattamente con quel minimo: incidono metadati, scale, tensori mantenuti a una precisione diversa e requisiti del runtime.

La VRAM è importante quando si trasferiscono i layer su una GPU; la RAM di sistema consente l’esecuzione su CPU o ospita le parti che non entrano nella GPU. Anche il contesto della conversazione, la cache KV, le attivazioni e le richieste simultanee richiedono memoria. Per questo un file che sembra rientrare nella VRAM può non caricarsi o esaurire la memoria con contesti lunghi. Le dimensioni del file aiutano a escludere alcune opzioni, ma non bastano a completare il dimensionamento.

5. Configura privacy e funzionamento offline

L’inferenza locale può mantenere i dati sul dispositivo, ma «locale» non significa automaticamente «isolato». Il download dei modelli, gli aggiornamenti, la telemetria, le interfacce web, i proxy, le estensioni e i log possono generare comunicazioni. Identifica ogni componente e definisci quali destinazioni di rete gli sono necessarie. Se il sistema deve funzionare senza internet, scarica e verifica in anticipo pesi, dipendenze e licenze; poi prova a bloccare le connessioni in uscita nell’ambiente reale.

Usa la segmentazione di rete e regole firewall basate sul principio del minimo privilegio. Limita gli accessi all’endpoint di inferenza, evita di esporlo direttamente alle reti pubbliche e proteggi i log. Tratta prompt, risposte e documenti come dati sensibili se contengono informazioni interne. Un test offline deve verificare che l’applicazione funzioni senza chiamate esterne, non soltanto che il modello sia già stato scaricato.

6. Valuta qualità, latenza e prestazioni

Valuta ogni configurazione con un insieme di test rappresentativo e stabile, distinto dagli esempi usati per ottimizzare i prompt. Per la qualità, scegli metriche adatte all’attività: accuratezza o F1 per la classificazione, percentuale di campi corretti per l’estrazione e revisione umana basata su criteri condivisi per le risposte aperte. BLEU e ROUGE possono essere utili in alcuni confronti testuali, ma non sostituiscono la valutazione di factualità, rispetto delle istruzioni o rischio; un’elevata corrispondenza lessicale non dimostra che la risposta sia corretta.

Misura il tempo di caricamento, il tempo al primo token, il tempo totale e i token al secondo. Distingui l’esecuzione a freddo da quella con il modello già caricato. Registra hardware, driver, runtime, versione del modello, quantizzazione, contesto, dimensione del batch e concorrenza. L’inferenza locale elimina una parte della latenza di rete, ma non garantisce una latenza totale inferiore: dipende dal dispositivo, dal modello e dal carico.

7. Gestisci versioni e manutenzione del servizio

Fissa le versioni dei pesi, della quantizzazione, del runtime, delle librerie e della configurazione. Quando disponibili, conserva le checksum degli artefatti e archivia i modelli in posizioni controllate. Prima di aggiornare, ripeti i test di qualità, prestazioni, compatibilità e isolamento. Un aggiornamento può modificare le risposte, l’uso della memoria o il comportamento degli strumenti anche se il nome commerciale del modello rimane simile.

Monitora errori, saturazione della memoria, latenza e disponibilità. Definisci una procedura di rollback verso una versione già testata e una politica per ritirare gli artefatti vulnerabili o privi di una licenza adeguata. Se il sistema usa strumenti, applica permessi minimi e convalida le chiamate prima di eseguirle: anche un modello locale può produrre istruzioni errate o contenuti manipolati.

8. Checklist e criteri pratici di scelta

La scelta corretta è la configurazione più piccola e semplice che soddisfa i requisiti misurati, non necessariamente il modello più grande o la quantizzazione più aggressiva. Se un’opzione non raggiunge la qualità minima, cambia modello o configurazione e ripeti la valutazione; se supera i limiti di memoria o latenza, controlla prima contesto, concorrenza e ripartizione tra CPU e GPU.

Le fonti disponibili supportano i principi generali della quantizzazione e documentano le opzioni di una specifica piattaforma, ma non stabiliscono una perdita di qualità universale passando da FP16 a una determinata quantizzazione, né requisiti di VRAM universali per modelli 7B o 13B. Questi valori vanno verificati in relazione all’artefatto, al runtime, all’attività e all’hardware specifici.

Continua a esplorare

Correzioni e trasparenza

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