Quantizzazione e inferenza veloce sull'hardware proprio
Come adattare modelli più grandi su GPU più piccole e servirli velocemente.
La prima reazione di molti ingegneri quando guardano i requisiti hardware per un large language model all'avanguardia è lo shock per i prezzi. Un modello da 70 miliardi di parametri nel suo formato FP32 nativo richiederebbe circa 280 GB di memoria GPU — più di quanto la maggior parte delle organizzazioni abbia in un singolo server e molto più di quanto voglia fornire solo per rispondere alle query dei dipendenti. La quantizzazione è la tecnica che rende questi numeri gestibili, e comprenderla è essenziale per chiunque progetta uno stack AI on-premise.
Cosa fa davvero la quantizzazione
Una rete neurale è in ultima analisi una raccolta molto grande di numeri — i pesi appresi durante l'addestramento. Per default quei pesi sono archiviati come valori in virgola mobile a 32 bit (FP32), ciascuno che consuma 4 byte di memoria. La quantizzazione sostituisce i numeri ad alta precisione con rappresentazioni a precisione inferiore: float a 16 bit (FP16 o BF16), interi a 8 bit (INT8) o persino interi a 4 bit (INT4). Il footprint di memoria si riduce proporzionalmente e su hardware con supporto nativo per l'aritmetica a precisione inferiore, l'inferenza diventa anche più veloce.
- FP16 / BF16 — float a mezza precisione. Virtualmente senza perdite per la maggior parte dei compiti; la scelta predefinita per i deployment in produzione dove l'accuratezza è critica. Risparmio di memoria: 2x rispetto a FP32.
- INT8 — interi a 8 bit, tipicamente prodotti da metodi di post-training quantization (PTQ) come GPTQ o llm.int8(). Modesto degrado della qualità sul ragionamento complesso; significativo per la maggior parte dei compiti pratici. Risparmio di memoria: 4x rispetto a FP32.
- INT4 — interi a 4 bit, la frontiera della quantizzazione aggressiva. Strumenti come GGUF Q4_K_M e AWQ offrono qualità sorprendentemente buona per la loro dimensione. Risparmio di memoria: 8x rispetto a FP32, con degrado accettabile per carichi di lavoro di chat e sintesi.
Il compromesso qualità-dimensione
La quantizzazione non è gratuita. Ogni bit che si rimuove è informazione scartata, e a un certo punto questo si manifesta come output degradato — allucinazioni, errori di ragionamento o perdita di sfumatura. Il riscontro pratico dai deployment Privonis è che il compromesso è sorprendentemente favorevole per la maggior parte dei compiti enterprise. Un modello 70B quantizzato a INT4 tipicamente supera un modello 13B a FP16, anche se entrambi stanno in memoria GPU simile. In caso di dubbio, usa il modello più grande che entra alla precisione più alta che il tuo hardware supporta.
Scegliere la quantizzazione giusta riguarda meno il numero di bit e più l'abbinamento della capacità del modello al compito: un 70B INT4 ben scelto batte ogni volta un 13B FP16 approssimativo.
Server di inferenza: da dove viene il throughput
Eseguire un modello quantizzato è solo metà della storia. Servirlo efficientemente sotto carico concorrente richiede un server di inferenza che comprenda la struttura dell'attenzione transformer. L'opzione open-source dominante oggi è vLLM, che ha introdotto PagedAttention — una tecnica di gestione della memoria presa in prestito dalla memoria virtuale del sistema operativo che consente al server di interleave molte richieste simultaneamente senza sprecare memoria GPU su blocchi KV-cache pre-allocati. L'effetto pratico è un miglioramento del throughput di 10–30x rispetto a un loop a richiesta singola ingenuo.
Altre opzioni notevoli includono llama.cpp (CPU-friendly, eccellente per modelli più piccoli su hardware commodity), Ollama (wrapper developer-friendly attorno a llama.cpp), TGI di Hugging Face (forte supporto per i formati di modello Hugging Face) e TensorRT-LLM di NVIDIA (throughput più alto su hardware NVIDIA, al costo di una pipeline di compilazione più complessa). Privonis valuta e benchmarca tutte queste per ogni configurazione del cliente.
Batching e throughput
Le GPU raggiungono la massima efficienza quando elaborano molte operazioni simultaneamente — è per questo che sono state progettate. Il continuous batching (chiamato anche dynamic batching o iteration-level scheduling) consente a un server di inferenza di raggruppare token da più richieste concorrenti in una singola chiamata kernel GPU, migliorando drasticamente l'utilizzo. Senza batching, una singola query utente potrebbe usare il 5% della capacità GPU; con il continuous batching, puoi spingere l'utilizzo al 70–80% con pattern di traffico nel mondo reale. Per un'enterprise con decine di utenti concorrenti, la differenza tra un server consapevole del batching e uno ingenuo può significare la differenza tra aver bisogno di un server GPU o di quattro.
Scegliere la quantizzazione giusta per la propria GPU
L'albero decisionale è più semplice di quanto sembra. Inizia dal budget VRAM della tua GPU, sottrai il margine per il sistema operativo e il server di inferenza (tipicamente 4–8 GB), poi trova il modello più grande che entra al livello di precisione più alto. Alcuni punti di riferimento pratici:
- 24 GB VRAM (es. RTX 4090, A5000) — esegue comodamente un modello 13B a FP16, o un modello 34B a INT4.
- 48 GB VRAM (es. RTX 6000 Ada, A6000) — esegue un modello 34B a FP16, o un modello 70B a INT4.
- 2 × 80 GB (es. coppia A100 tramite NVLink) — esegue un modello 70B a FP16, o un modello 140B a INT4 con tensor parallelism.
- Solo CPU (nessuna GPU) — llama.cpp con un modello Q4_K_M da 7B o 13B è praticabile per strumenti developer a bassa concorrenza; aspettati 5–15 token/s.
Mettere tutto insieme con Privonis
Selezionare un formato di quantizzazione e un server di inferenza è lavoro di ingegneria che richiede profilazione sull'hardware specifico con il carico di lavoro specifico. Privonis gestisce quel benchmarking come parte di ogni deployment: eseguiamo test di throughput, misuriamo la qualità dell'output su un campione rappresentativo dei tuoi prompt reali e consegniamo una configurazione che massimizza le prestazioni nel tuo budget hardware. Il risultato è uno stack di inferenza in produzione che il tuo team può gestire senza un ingegnere ML specialista di guardia. Se sei pronto a esplorare cosa si adatta al tuo ambiente, il nostro team è felice di fare i calcoli con te.
Parliamo del tuo progetto IA
Prenota una chiamata