TurboQuant : quantizzare i grandi modelli per farli funzionare in locale

#Perché TurboQuant?

I K-quants GGUF (Q4_K_M, Q5_K_M…) sono il riferimento dal 2023: supportati universalmente da llama.cpp, Ollama e LM Studio, e facili da produrre. Ma raggiungono il loro limite con i modelli molto grandi. Un modello denso da 70B in Q4_K_M richiede circa 40 GB di VRAM, fuori portata di una RTX 4090 da 24 GB. Scendere a Q3 o Q2 fa crollare la qualità.

La quantizzazione TurboQuant affronta specificamente questa lacuna. È una famiglia di tecniche che combinano calibrazione su dataset, allocazione non uniforme dei bit per livello e compressione a blocchi con un dizionario condiviso. Il risultato: da 2,5 a 3 bit effettivi per peso, con una perdita di qualità inferiore a quella di un Q3_K_M GGUF.

#Come funziona la compressione

Tre meccanismi si sommano. Nessuno è rivoluzionario preso singolarmente; è la loro combinazione a fare la differenza.

Calibrazione sui dati

Alcune centinaia di prompt rappresentativi vengono elaborati dal modello per misurare quali pesi influenzano davvero gli output. Gli altri possono essere quantizzati in modo aggressivo.

Assegnazione di bit per layer

Invece di un budget fisso (4 bit ovunque), TurboQuant assegna 5-6 bit agli strati di attenzione critici e scende a 2 bit per gli MLP ridondanti. Il totale medio scende a 2,7-3,2 bpw.

Compressione per blocchi

I pesi sono raggruppati in blocchi di 32 o 64 valori che condividono uno scale e un offset, con un codebook compresso per gruppo. Ciò evita l'overhead per parametro dei K-quants.

#TurboQuant vs GGUF classico

Per un modello denso da 70B, ecco l'ordine di grandezza tipico:

GGUF Q4_K_M (~4,5 bpw)

~40 GB, qualità quasi pari a FP16, supportato ovunque. Il punto di riferimento.

GGUF Q3_K_M (~3.4 bpw)

~32 GB, perdita sensibile nei ragionamenti lunghi, compaiono allucinazioni.

GGUF Q2_K (~2.6 bpw)

~26 GB, modello chiaramente degradato, da evitare per un uso serio.

TurboQuant ~3.0 bpw

~28 GB, qualità simile a Q4_K_M. Rientra nella memoria di 1×RTX 3090 o 1×4090 con un contesto breve.

TurboQuant ~2.5 bpw

~23 GB, leggermente sotto il Q4 ma ben sopra il Q3. Permette il 70B su 24 GB di VRAM.

#Risparmio di VRAM misurato in base alla dimensione del modello

Le cifre riportate di seguito sono ordini di grandezza per modelli densi recenti (Qwen 3.5, Granite 4.2), con un contesto da 4k, senza Flash Attention. Aggiungi un margine del 10-20% per la cache KV e l'overhead del runtime.

7B — Q4_K_M: 4.4 GB

TurboQuant 3.0 bpw: ~2,9 GB. Interesse limitato: il 7B entra già in memoria ovunque.

13B — Q4_K_M : 7,8 GB

TurboQuant 3.0 bpw: ~5,1 GB. Permette un contesto di 16k+ su 8 GB di VRAM.

32B — Q4_K_M : 19 GB

TurboQuant 3.0 bpw: ~13 GB. Sta comodamente nella memoria di una RTX 4080 da 16 GB con un contesto di 8k.

70B — Q4_K_M : 40 GB

TurboQuant 2.5 bpw: ~23 GB. Permette di eseguire il 70B su 1×RTX 4090 24 GB o 1×3090 24 GB.

120B MoE — Q4_K_M : ~70 GB

TurboQuant 2.7 bpw: ~42 GB. Fattibile su 2×3090 o un Mac Studio 64 GB.

#Impatto sulla qualità

Nei benchmark abituali (MMLU, HellaSwag, HumanEval), un modello 70B quantizzato con TurboQuant a 3,0 bpw rimane a una distanza di 0,5-1,5 punti dal FP16. Nel ragionamento a più passaggi e nel codice lungo, si cominciano a vedere differenze più nette. Il test che distingue più chiaramente i metodi: un lungo estratto di codice Python con dipendenze incrociate.

Conoscenze generali

Quasi impercettibile. Se fai domande di cultura generale, non noterai la differenza.

Ragionamento breve

Perdita minima. Le catene di pensiero rimangono coerenti per 5-10 passaggi.

Ragionamento lungo (matematica/dimostrazioni)

Perdita di qualità visibile. Il modello può saltare un passaggio o perdersi dopo 20+ turni di ragionamento. Preferisci 3,5+ bpw se questo è il tuo caso d'uso.

Codice

Sensibile alle quantizzazioni aggressive. Sotto 3,0 bpw, aspettati più bug subdoli (indici errati, condizioni invertite). Resta su Q4_K_M o TurboQuant ≥3,5 bpw per Aider/Continue.

Lingue rare

Il francese mantiene una buona qualità fino a 2,5 bpw. Le lingue poco rappresentate nel corpus di calibrazione ne risentono maggiormente.

#Requisiti hardware e software

Quantizzare tu stesso un modello rimane un'operazione pesante. Scaricare un modello già quantizzato da Hugging Face è quasi sempre più semplice. Se comunque vuoi produrre la tua versione:

GPU per la calibrazione

È necessario poter caricare il modello in FP16 o in BF16 durante l'analisi. Per un 70B, ciò implica 2×A100 da 80 GB o un Mac Studio M2 Ultra da 192 GB. Per un 32B, una RTX 4090 da 24 GB basta con offload parziale.

Modello base

I pesi non quantizzati (safetensors) scaricati dal repository originale su Hugging Face. Calcola 140 GB per un modello 70B FP16.

Dataset di calibrazione

Da 256 a 1024 campioni rappresentativi del tuo utilizzo. Wikipedia FR, codice, i tuoi prompt. Evita i dataset generici se hai un settore specifico.

Runtime di destinazione

Decidi in anticipo: ExLlamaV3 (il più veloce su Nvidia), llama.cpp con backend turbo oppure un fork specifico. Il formato del file varia a seconda del runtime.

Python 3.10+ e CUDA 12+

Toolchain standard. Per AMD, ROCm 6.x funziona con llama.cpp ma non (ancora) con tutti i fork turbo.

#Workflow per quantizzare autonomamente

Il percorso tipico, dal modello Hugging Face FP16 fino a un file eseguibile in Ollama o llama.cpp.

1. 01
   Recuperare i pesi originali

   Clonare il repository Hugging Face del modello non quantizzato. Prevedere almeno un'ora per un 70B con una buona connessione. Usa huggingface-cli download per poter riprendere il download dopo un'interruzione.
2. 02
   Preparare il dataset di calibrazione

   Creare un file JSONL con 256-1024 prompt. La diversità è più importante della quantità: codice, prosa francese, dialoghi, domande tecniche. Un file da 5-20 MB basta ampiamente.
3. 03
   Avviare la calibrazione

   Lo strumento (ad esempio lo script quantize fornito dal progetto TurboQuant scelto) carica il modello, esegue un passaggio in avanti per ogni prompt e raccoglie statistiche di attivazione strato per strato. Metti in conto 1-4 ore per un 70B, a seconda della GPU.
4. 04
   Quantizzare ed esportare

   L'allocazione dei bit è calcolata a partire dalle statistiche, poi ogni tensore viene codificato. Output: un file .safetensors o .gguf in base al runtime. Prevedi da 30 minuti a 2 ore in più.
5. 05
   Convertire nel formato runtime

   Per Ollama: creare un Modelfile che punti al file quantizzato, poi eseguire ollama create monmodele -f Modelfile. Per llama.cpp: il binario main accetta direttamente il .gguf.
6. 06
   Verificare la qualità

   Eseguire una piccola batteria di test: 20-30 prompt che coprano i tuoi casi d’uso. Confrontare i risultati fianco a fianco con quelli della versione GGUF Q4_K_M di riferimento. Se il peggioramento è troppo marcato, ripetere con più bit o un dataset migliore.

# Une fois le .gguf TurboQuant produit
cat > Modelfile <<EOF
FROM ./glm-4.7-turboquant-3.0bpw.gguf
PARAMETER num_ctx 8192
PARAMETER temperature 0.7
EOF

ollama create glm-4.7-turbo -f Modelfile
ollama run glm-4.7-turbo "Explique le théorème de Bayes en 3 phrases."

#Insidie comuni e risoluzione dei problemi

Il runtime non riconosce il file

TurboQuant non è un formato standard unico. Verifica che carichi il file con il runtime corrispondente al metodo utilizzato (ExLlamaV3 per EXL3, versione recente di llama.cpp per i GGUF turbo).

Capacità della VRAM superata durante l'inferenza, anche se il file ci stava

Stai trascurando la cache KV. Con un contesto da 32k, la cache KV può richiedere altri 4-8 GB. Riduci num_ctx o attiva Flash Attention tramite OLLAMA_FLASH_ATTENTION=1.

Qualità catastrofica nel tuo caso d'uso

Il dataset di calibrazione non copre il tuo settore. Ripeti l'operazione aggiungendo 100-200 prompt rappresentativi. È di gran lunga la leva più potente.

Il modello quantizzato è più lento del Q4_K_M

È normale su alcune architetture: la decompressione turbo comporta un overhead. Sulle schede più vecchie (RTX 20xx), il risparmio di VRAM può costare una riduzione dei token al secondo. Misura le prestazioni prima di adottarla.

Differenze tra i run

La calibrazione introduce non determinismo. Due quantizzazioni dello stesso modello con lo stesso dataset possono differire leggermente in qualità. Esegui più prove e conserva la quantizzazione migliore.

#Per approfondire

TurboQuant è uno strumento tra gli altri per ampliare i limiti di ciò che può stare in memoria in locale. Alcune possibilità complementari:

Scegliere la quantizzazione (Q4, Q5, Q8, FP16)

Per capire bene come si colloca TurboQuant rispetto ai K-quants GGUF classici e scegliere caso per caso.

Fine-tuning di LLM in locale: LoRA e QLoRA

Se vuoi andare oltre la quantizzazione e adattare un modello al tuo settore — spesso un intervento più efficace di una quantizzazione più aggressiva.

Scegliere la GPU per l'IA locale

Per decidere su quale scheda puntare, sapendo che la VRAM resta il vincolo principale, anche con TurboQuant.