Quantizzare un modello locale senza andare a tentoni: come scegliere 4, 6 o 8 bit in base a VRAM, contesto e perdita accettabile

Il fatto che i pesi entrino nella VRAM non significa che il sistema funzioni

L'errore più comune nella scelta di un modello locale è confrontare la dimensione del file quantizzato con la memoria della GPU e considerare conclusa la decisione. Quel calcolo copre soltanto, in modo approssimativo, i pesi. Durante l'inferenza intervengono anche la cache di chiavi e valori — cache KV —, le attivazioni e i buffer temporanei, lo spazio riservato dal runtime, il contesto di ogni richiesta e, in un servizio, le richieste simultanee. Una configurazione può caricare il modello, rispondere a una domanda breve e fallire comunque quando riceve un documento lungo o più richieste nello stesso momento.

La conseguenza pratica è rilevante: «entra» deve voler dire che completa il carico massimo previsto con un margine misurato, non che avvia una sessione isolata. Se il margine scompare, il risultato può essere un errore di memoria, una riduzione automatica del contesto, il trasferimento di una parte del lavoro nella RAM di sistema oppure una latenza molto irregolare. Quale di questi comportamenti si verifichi dipende dal runtime e dalla sua configurazione; non va dato per scontato senza verifica.

La quantizzazione è una delle varie leve disponibili. Ridurre i bit dei pesi di solito libera memoria e può consentire di usare un modello più grande, ma non elimina da sola il costo crescente della cache KV quando aumentano il contesto o la concorrenza. Può inoltre modificare qualità, prestazioni o percorsi di esecuzione disponibili in base al formato e al backend. Per questo non esiste un'equivalenza universale tra «4 bit», «6 bit» e «8 bit».

Questa guida parte da un carico di lavoro concreto: quale lunghezza di input deve essere accettata, quanti token vengono generati, quante richieste coesisteranno, quale latenza è utile e quali errori sarebbero inaccettabili. Se si sta ancora scegliendo una famiglia di modelli, è opportuno consultare prima la guida ai modelli locali; se il dubbio riguarda modelli base diversi, usare la sezione di confronto prima di attribuire alla quantizzazione differenze che provengono in realtà dal modello.

Le componenti di memoria da separare

Una stima utile comincia scomponendo la memoria in componenti osservabili separatamente. La prima è costituita dai pesi del modello. La loro dimensione dipende dal numero di parametri, dalla rappresentazione quantizzata e da metadati propri del formato, quali scale, blocchi o strutture ausiliarie. Di conseguenza, dividere semplicemente i parametri per otto, sei o quattro fornisce un orientamento, ma non sostituisce la dimensione effettiva riportata dal formato e dal runtime.

La seconda componente è la cache KV. In un decoder autoregressivo, il sistema conserva chiavi e valori dei token già elaborati per non ricalcolarli a ogni token generato. La documentazione di Transformers descrive tensori di cache con dimensioni di batch, teste, lunghezza della sequenza e dimensione della testa. Esistono chiavi e valori, e questa memorizzazione si ripete per ogni livello. A parità di architettura, aumentare contesto, batch o concorrenza aumenta la memoria richiesta.

La terza componente raccoglie attivazioni e buffer temporanei. La sua dimensione dipende dal backend, dalla precisione di calcolo, dai kernel, dal prefill di input lunghi, dalla lunghezza della generazione e da come vengono raggruppate le richieste. Non è opportuno sostituirla con una costante universale. Il quarto elemento è la memoria non attribuita direttamente al modello, come contesto di esecuzione, librerie, allocatori e frammentazione. Il quinto è un margine operativo esplicito: memoria volutamente non allocata per tollerare picchi, differenze fra misurazioni e carico reale.

In un server, batch e concorrenza richiedono un'ulteriore precisazione. Un batch può essere il numero di sequenze elaborate insieme in un passaggio, mentre la concorrenza è il numero di richieste vive. A seconda dello scheduler, i due valori possono essere collegati ma non sono intercambiabili. Per stimare la cache occorre contare la somma dei token vivi delle sequenze che coesistono, non soltanto la lunghezza massima di una singola richiesta.

Stimare pesi e cache KV prima di scaricare o distribuire

La stima non mira a prevedere ogni byte: serve a scartare configurazioni non praticabili e a definire quali prove meritano di essere eseguite. Per i pesi, usare la dimensione indicata per lo specifico artefatto che si intende caricare, non una cifra generica relativa alla famiglia del modello. Se si conosce soltanto il numero di parametri, il risultato va trattato come un minimo teorico incompleto. I formati di quantizzazione archiviano informazioni aggiuntive e alcuni runtime convertono o duplicano strutture durante il caricamento.

Per un'architettura di tipo Llama, un'approssimazione concettuale della cache KV per sequenza è: numero di livelli moltiplicato per due, moltiplicato per il numero di teste chiave-valore, moltiplicato per la lunghezza della sequenza, moltiplicato per la dimensione della testa e per i byte di ciascun elemento della cache. Il fattore due rappresenta K e V. Per più sequenze simultanee, si sommano i token residenti di ciascuna. Se il runtime usa una cache statica, può riservare capacità fino a un massimo anche quando l'uso istantaneo è inferiore; se usa una cache dinamica, l'uso può crescere con la richiesta. Entrambe le strategie richiedono misurazione.

È essenziale usare il numero di teste chiave-valore, che non coincide sempre con il numero totale di teste di attenzione. Nell'attenzione multi-query o grouped-query, più teste di query condividono proiezioni KV. Questo può ridurre sensibilmente la cache rispetto a un'architettura con una proiezione KV per ogni testa di attenzione. La configurazione esatta del modello deve fornire livelli, teste KV e dimensione della testa; non vanno dedotti da un nome commerciale.

Anche i byte per elemento della cache devono essere verificati. Quantizzare i pesi non implica automaticamente quantizzare la cache KV. Alcuni ambienti consentono di scegliere un tipo di dati quantizzato per la cache, altri usano per impostazione predefinita una precisione differente e altri ancora applicano l'offloading. Queste opzioni modificano il budget di memoria e possono influenzare prestazioni o comportamento numerico. Annotare la configurazione effettiva del runtime, non solo i bit presenti nel nome del file.

Che cosa cambia passando da 8 a 6 o 4 bit

Come regola generale, ridurre la precisione dei pesi ne riduce l'impronta di memoria rispetto a una rappresentazione a precisione maggiore dello stesso modello. Questo può rendere praticabile una GPU più piccola, lasciare più budget per il contesto o permettere più richieste concorrenti. Tuttavia, la riduzione osservata non deve necessariamente seguire una proporzione esatta da otto a sei a quattro. Confezionamento, scale per gruppo, formato del file, conversioni interne e buffer del backend modificano il risultato.

La qualità non dipende soltanto dal numero di bit. Contano l'algoritmo di quantizzazione, la dimensione del gruppo, quali tensori ricevono un trattamento speciale, il modello base e il compito. Una quantizzazione a 4 bit ottenuta con un metodo può preservare bene un compito, mentre una a 6 bit ottenuta con un altro metodo può non farlo; è possibile anche il contrario. Per questo i bit servono a formulare ipotesi di test, non a certificare la precisione.

La velocità richiede la stessa cautela. Meno memoria può ridurre i trasferimenti e migliorare la praticabilità su un dispositivo limitato, ma un formato può non avere kernel efficienti in uno specifico backend o richiedere conversioni. Aumentare il contesto può spostare il collo di bottiglia verso la gestione della cache e il prefill. Le prestazioni vanno misurate con due metriche distinte: tempo al primo token per input rappresentativi e velocità di generazione successiva. Un singolo valore di token al secondo nasconde differenze rilevanti.

Come punto di partenza, provare 8 bit quando la qualità è critica e il budget lo consente; 6 bit quando occorre recuperare una parte significativa della memoria senza passare subito all'opzione più aggressiva; 4 bit quando la VRAM è il vincolo dominante o quando i test dimostrano che non c'è una perdita inaccettabile. Si tratta di priorità di prova, non di raccomandazioni universali.

Procedura decisionale: dal vincolo al candidato praticabile

Definire anzitutto il contratto operativo. Mettere per iscritto la lunghezza massima di input che deve essere davvero supportata, una riserva di token in output, il numero massimo di richieste vive, l'obiettivo di latenza e i compiti critici. Distinguere un massimo eccezionale da un obiettivo abituale. Se un'applicazione elabora documenti lunghi, misurare soltanto messaggi brevi non rappresenta né il rischio di memoria né la qualità utile.

Raccogliere poi i parametri dell'architettura e del runtime. Per il modello, registrare livelli, teste KV, dimensione della testa e formato dei pesi. Per il runtime, registrare il tipo di dati della cache, l'eventuale riserva di cache statica o dinamica, la possibilità di offloading, il limite di memoria GPU e qualsiasi impostazione relativa a batch o token in volo. Negli strumenti di serving, il budget della cache può essere configurato esplicitamente oppure derivato da una frazione della memoria disponibile; entrambi i casi devono risultare nell'esperimento.

Calcolare un intervallo, non una cifra unica: pesi osservati o stimati, cache KV per il carico obiettivo, una riserva per i temporanei e un margine. Se il totale supera la VRAM disponibile prima di applicare il margine, scartare la combinazione. Se entra di poco, classificarla come candidata rischiosa e testarla sotto carico massimo. Se entra con margine, non considerarla approvata finché non siano validate qualità e latenza.

Scegliere almeno tre candidati che rispondano a ipotesi differenti: il modello desiderato a 8 bit, a 6 bit e a 4 bit; oppure, quando un candidato non ha senso, un modello più piccolo a precisione superiore. Mantenere costanti modello base, revisione, prompt, contesto massimo, limite di output, seed quando compatibile, parametri di decodifica, hardware e versione del runtime. Cambiare più variabili insieme impedisce di attribuire una differenza alla quantizzazione.

Test minimo per rilevare una perdita che conta

Un test utile non deve necessariamente essere enorme, ma deve essere rappresentativo. Costruire un piccolo insieme di casi che includa il lavoro che giustifica il deployment: estrazione strutturata, classificazione, sintesi di documenti, assistenza al codice o risposte soggette a vincoli, secondo il caso. Includere input di lunghezza abituale e alcuni vicini al limite operativo. Gli input lunghi sono necessari perché possono rivelare sia errori di memoria sia perdite nel seguire istruzioni o nel recuperare dettagli.

Per ogni caso, definire cosa sarà validato prima di eseguire il modello. Alcuni compiti consentono un confronto esatto: uno schema JSON valido, etichette ammesse, campi obbligatori, una query che deve contenere valori specifici o test automatizzati per il codice. Altri richiedono una revisione umana con una rubrica: fedeltà al documento, copertura, assenza di invenzioni, rispetto del formato e utilità. Non confondere la fluidità con la correttezza.

Fissare una soglia esplicita. Per esempio, una configurazione può essere scartata se fallisce più casi critici del candidato di riferimento, se peggiora la validità strutturale oltre un limite deciso dal team oppure se produce nuovi errori su dati sensibili. La soglia appartiene al rischio dell'applicazione; non può essere dedotta dai bit. In un compito di bozza creativa può essere accettabile una variazione maggiore rispetto all'estrazione di dati destinati a un processo successivo.

Ripetere i test. Con decodifica stocastica, più esecuzioni aiutano a distinguere la variabilità della generazione da un degrado sistematico. Con decodifica deterministica, le ripetizioni restano utili per osservare stabilità delle prestazioni ed errori di memoria. Riportare i risultati per tipo di compito e lunghezza dell'input, non soltanto una media complessiva. Una quantizzazione apparentemente equivalente nella media può concentrare i propri fallimenti nei documenti più lunghi o nel compito con l'impatto maggiore.

Tre profili operativi e le loro priorità

Su un portatile con GPU limitata, la priorità è di solito evitare una configurazione che dipenda continuamente dalla RAM di sistema o dall'offloading per un'esperienza interattiva. Iniziare con un contesto realistico, una sola richiesta e un modello o una quantizzazione che lasci margine. Se 4 bit è l'unico modo per caricare il modello, confrontare anche un modello più piccolo a 6 o 8 bit. Il secondo può essere più stabile e più utile nel compito concreto, pur avendo meno parametri.

Su una workstation con una GPU, c'è più margine per scegliere fra qualità, contesto e velocità, ma il limite resta condiviso fra pesi, cache e temporanei. È un ambiente adatto a confrontare 4, 6 e 8 bit sullo stesso corpus e a decidere se riservare VRAM ai contesti lunghi. Se si prevede di alternare sessioni brevi e analisi documentale, misurare entrambi i profili: il risultato di una conversazione breve non dimensiona il secondo.

In un server con concorrenza moderata, l'unità di pianificazione non è più il file del modello, ma la capacità totale di token vivi. Il gestore della cache e lo scheduler delle richieste fanno parte della decisione. Una configurazione che funziona per una singola sessione può esaurire la memoria quando coincidono prefilling lunghi. Definire limiti di ammissione, lunghezza massima, riserva di output e concorrenza; quindi testare raffiche e combinazioni di richieste corte e lunghe. Le metriche di coda e i percentili di latenza sono più informativi del miglior risultato isolato.

In tutti e tre i profili, l'offloading è un'opzione che va dichiarata, non una soluzione invisibile. Può ampliare la capacità apparente trasferendo una parte dei dati, ma può anche modificare la latenza e dipendere dal collegamento tra CPU e GPU. Decidere tramite misurazioni se questo compromesso è accettabile per il caso d'uso.

Segnali per scartare una configurazione e checklist di adozione

Scartare una configurazione quando produce errori di memoria intermittenti, anche se una dimostrazione breve funziona. L'intermittenza indica spesso che la memoria disponibile dipende dalla forma delle richieste, dal picco di prefill, dalla frammentazione o da altri carichi del processo. Sono inoltre motivi di scarto il fatto che il runtime riduca silenziosamente il contesto effettivo, che il sistema sia stabile soltanto con un carico inferiore a quello previsto o che il margine osservato scompaia nei test ripetuti.

Il degrado della qualità va analizzato per schema. Errori concentrati nell'estrazione, nei calcoli, nei campi obbligatori, nel rispetto delle istruzioni o nei documenti estesi pesano più dei cambiamenti stilistici se tali compiti sono critici. Un output apparentemente ragionevole ma con valori inventati non deve essere approvato soltanto sulla base di un punteggio medio. Verificare inoltre la validità del formato quando l'output alimenta software successivo.

Prima di fissare un'opzione predefinita, verificare privacy e funzionamento operativo. Eseguire l'inferenza sul dispositivo non garantisce di per sé che nessun dato lo lasci: download di modelli, telemetria, registrazione dei prompt, aggiornamenti delle dipendenze e strumenti di osservabilità sono aspetti separati. Quali dati vengono conservati e quali comunicazioni effettua ciascun componente deve essere verificato nella configurazione e nell'ambiente di rete scelto.

Il risultato finale non deve per forza essere «la quantizzazione più alta possibile». Può essere 6 bit per un profilo interattivo, 4 bit per un profilo di analisi con ampio contesto oppure 8 bit per un compito nel quale la perdita rilevata non sia accettabile. Conservare le alternative insieme al loro registro di test. Se cambiano runtime, hardware, formato dei pesi o carico di lavoro, misurare nuovamente: la conclusione precedente non è più una garanzia.

Continua a esplorare

Correzioni e trasparenza

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