La rincorsa a modelli sempre più grandi si scontra con un vincolo fisico: la VRAM disponibile sulle GPU. Il recente lavoro su Ornith-1.0-35B, un LLM da 35 miliardi di parametri, mostra che la quantization spinta può trasformare un modello altrimenti ingombrante in una soluzione adatta a singola scheda video, senza sacrificare del tutto l’affidabilità delle risposte.

Dalla BF16 alla Q3_K_M: un taglio drastico

Il quantizzatore llama-quantize ha portato i pesi da una rappresentazione BF16 a 16.01 BPW fino a 3.87 BPW nel formato Q3_K_M. Il risultato è un file GGUF da 16.8 GB su disco, che una volta caricato occupa circa 17 GiB di VRAM. Rispetto alla variante Q4_K_M (21.2 GB), la riduzione è del 21%; rispetto a Q8_0 (36.9 GB), la memoria necessaria si dimezza. Per chi lavora con GPU consumer da 24 GB, questa compressione apre la porta a inference locale senza dover ricorrere a configurazioni multi-GPU.

La comunità conosce bene i pericoli delle quantizzazioni aggressive: perdita di coerenza, allucinazioni più frequenti, degradazione dei compiti di codice. Per verificare la tenuta del Q3_K_M, l’autore ha costruito una sonda di KL divergence sui top-64 token successivi, confrontando la distribuzione di probabilità del modello quantizzato con quella del BF16 originale su 32 prompt di programmazione. Il risultato è una divergenza media di 0.366, che sale progressivamente con le quantizzazioni meno spinte: 0.086 per Q4, 0.035 per Q5, 0.017 per Q6. Parallelamente, l’accordo top-1 (la capacità di predire esattamente lo stesso token del riferimento) scende all’84.4% per Q3_K_M, contro il 100% di Q6_K.

Prestazioni di serving e una correzione importante

L’inference su singola GPU con server CUDA di llama.cpp ha prodotto ~240 token al secondo in single-stream, con un picco di ~493 tok/s a 16 richieste concorrenti. La latenza p95 al primo token (TTFT) si attesta sui 78 ms in condizioni di singola connessione. Sono numeri più che sufficienti per applicazioni interattive locali, soprattutto considerando che il modello non richiede acceleratori enterprise.

Un dettaglio emerso durante i test rivela una trappola comune: con il reasoning mode di llama.cpp lasciato in auto, prompt brevi di codice possono consumare l’intero budget di risposta in contenuti di ragionamento interni, restituendo risposte finali vuote. La correzione – impostare REASONING=off negli script di serving – ha riportato il comportamento sui binari, confermato dal superamento della batteria completa 14/14 su un profilo a 16 slot. È il classico bug che in produzione può trasformarsi in un incubo diagnostico, e averlo documentato insieme ai quantizzati aggiunge un livello di praticità al repository.

Lo scenario on-premise: quando ogni gigabyte conta

Per le organizzazioni che valutano deployment locali di LLM, il trade-off tra accuratezza e costo hardware è centrale. Un Q6_K garantisce la massima fedeltà ma esige 28.5 GB di VRAM, fuori portata per molte schede consumer e persino per alcune workstation professionali. Il Q3_K_M, con i suoi 17 GB, può girare su una RTX 4090 o su una A4000, permettendo di mantenere dati e inference interamente on-premise. La perdita di precisione – 16 punti di accordo top-1 – va pesata in base al dominio applicativo: in compiti di coding potrebbe essere tollerabile, in contesti dove la correttezza lessicale è critica meno.

Non si tratta di una scelta binaria. Strumenti come la sonda KL descritta offrono una metrica riproducibile per valutare se una quantization è adatta al proprio caso d’uso, e il repository mette a disposizione l’intera scala di riferimento (Q4, Q5, Q6, Q8) per confronti diretti. L’approccio, testato anche con uno smoke test LoRA per validare la pipeline di training, segnala una direzione: chi opera on-premise può sfruttare metriche oggettive invece di affidarsi a sensazioni o benchmark generici. Il fatto che la suite comportamentale 14/14 sia stata superata con serving a 16 slot suggerisce inoltre che il degrado non è caotico ma prevedibile.

Prospettive

L’autore annuncia di stare lavorando alle quantizzazioni per la variante da 397 miliardi di parametri e a miglioramenti prestazionali per i quant attuali. Se il salto da 35B a 397B segue la stessa logica, il confronto tra compressione e affidabilità diventerà ancora più stringente. Nel frattempo, per chi cerca un punto di partenza concreto, il repository HuggingFace unisce quantizzati, script di serving monolitici e verifiche di correttezza OpenAI-compatible: un piccolo laboratorio riproducibile che riduce il rischio di sorprese in produzione.