Quantizzazione LLM: BF16 vs FP8 vs INT4
Abbiamo eseguito un benchmark di Qwen3-32B a 4 livelli di precisione (BF16, FP8, GPTQ-Int8, GPTQ-Int4) su una singola GPU NVIDIA H100 da 80 GB. Ogni configurazione è stata valutata su 2 benchmark (~12.200 domande) che coprono la generazione di conoscenza e di codice, oltre a più di 2.000 esecuzioni di inferenza per misurare il throughput. Int4 è 2,7 volte più veloce di BF16 perdendo meno di 2 punti su MMLU-Pro, ma la generazione di codice (HumanEval) perde 8 punti.
Risultati del benchmark di quantificazione
MMLU-Pro valuta il ragionamento generale in 14 ambiti (circa 12.000 domande, 5 tentativi). Questa è la versione più difficile di MMLU, con domande a 10 opzioni di risposta anziché 4.
HumanEval testa la generazione di codice (164 problemi, superato al primo tentativo). Il modello scrive funzioni Python che vengono eseguite tramite test unitari. Questo è l'unico benchmark in cui l'output viene eseguito, non solo valutato.
La velocità di elaborazione corrisponde al numero di token elaborati al secondo con una dimensione del batch pari a 1.
La dimensione del modello corrisponde alla memoria GPU utilizzata esclusivamente dai pesi, misurata dopo il caricamento.
Analisi MMLU-Pro per categoria
Ingegneria e giurisprudenza mostrano i cali maggiori a livello Int4. Matematica rimane stabile a tutti i livelli di precisione.
Capacità di memoria e concorrenza
Strumenti di monitoraggio della GPU come nvidia-smi segnalano un utilizzo quasi completo indipendentemente dalle dimensioni del modello, perché vLLM prealloca tutta la memoria disponibile. La vera questione è come tale memoria si suddivide tra i pesi del modello e la cache KV, poiché quest'ultima determina il numero di utenti che è possibile servire simultaneamente.
Il numero massimo di utenti rappresenta il limite massimo di memoria prima dell'esaurimento della memoria (OOM): la capacità totale dei token divisa per la lunghezza del contesto per utente. Questo è il massimo teorico. In pratica, l'overhead di pianificazione lo riduce leggermente.
Ciò ha implicazioni dirette per i modelli di ragionamento. DeepSeek-R1 e Qwen-QwQ generano migliaia di token di "pensiero" interni (spesso da 2K a 5K) prima di produrre una risposta finale. Su BF16, una singola richiesta di ragionamento potrebbe consumare l'intera capacità di 17K token, bloccando un secondo utente. Su Int4, la capacità di 193K consente più sessioni di ragionamento simultanee.
Principali risultati
FP8 non perde alcuna precisione misurabile
FP8 ottiene un punteggio del 69,64% su MMLU-Pro contro il 70,24% di BF16, con una differenza di 0,6 punti percentuali su 12.000 domande. Su HumanEval, sia FP8 che BF16 ottengono lo stesso punteggio del 39,02%. FP8 offre una velocità di elaborazione 1,5 volte superiore e dimezza le dimensioni del modello a un costo di 0,6 punti percentuali.
GPTQ-Int8 ottiene un punteggio del 70,32% su MMLU-Pro, ma perde 1,8 punti su HumanEval (37,20%). Se la generazione del codice è importante, FP8 è la scelta più sicura.
Int4 degrada la generazione del codice più della conoscenza
MMLU-Pro perde 1,6 punti a Int4 (dal 70,24% al 68,66%). HumanEval perde 8 punti (dal 39,02% al 31,10%). La generazione del codice richiede previsioni precise dei token, dove piccoli errori di peso si accumulano nei corpi delle funzioni.
La vera vittoria è la simultaneità, non la velocità.
Int4 è 2,7 volte più veloce di BF16. Ma l'effetto maggiore si nota sulla memoria. BF16 riserva solo 4,4 GB per la cache KV, sufficienti per circa 4 utenti simultanei con contesto 4K. Int4 libera 47,3 GB, sufficienti per 47 utenti, con un aumento di 12 volte della capacità di gestione a parità di GPU.
I punteggi matematici rimangono validi per tutte le precisioni
I punteggi di matematica rimangono pressoché invariati: 81,87% a BF16, 81,87% a FP8, 81,87% a Int8, 80,24% a Int4. Ingegneria (dal 49,64% al 43,45%) e giurisprudenza (dal 43,05% al 40,60%) mostrano una maggiore sensibilità.
Costo per token
Utilizzo del prezzo H100 SXM su RunPod (2,69 $/ora) con dimensione del batch pari a 1:
Questi numeri si riferiscono alla generazione in tempo reale da parte di un singolo utente. L'elaborazione in batch riduce ulteriormente i costi.
Metodologia di riferimento per la quantificazione LLM
Ambiente
- GPU: Singola NVIDIA H100 80GB HBM3 (SXM) tramite RunPod (2,69 $/ora)
- Software: vLLM 0.17.0, lm-evaluation-harness 0.4.11, PyTorch 2.8.0, CUDA 12.8, Python 3.11
- Modello: Qwen3-32B (post-trained/instruction-tuned) di HuggingFace. Nessuna messa a punto applicata.
Valutazione dell'accuratezza
- Tutte le valutazioni vengono eseguite tramite
lm-evaluation-harnessconbatch_size="auto". - Ogni attività viene eseguita in un sottoprocesso separato . Il modello viene caricato da zero ogni volta e la GPU viene completamente ripulita tra un'attività e l'altra. Questo previene errori di memoria insufficiente (OOM) dovuti alla frammentazione della memoria.
- HumanEval viene eseguito con
HF_ALLOW_CODE_EVAL=1(esecuzione del codice abilitata). - I risultati di MMLU-Pro includono una ripartizione per categoria (biologia, matematica, fisica, diritto, ecc.).
- La modalità di pensiero di Qwen3 non era attiva durante le valutazioni. lm-evaluation-harness invia prompt formattati in modo grezzo senza applicare il modello di chat (
apply_chat_template=Falseper impostazione predefinita), quindi il token<think>non viene mai iniettato.
Valutazione delle prestazioni
- 5 spunti di riflessione a rotazione tra diversi ambiti (scienza, programmazione, cultura generale)
- 10 iterazioni di riscaldamento (non misurate), poi 500 iterazioni misurate
- Output fisso:
max_tokens=256, temperature=0.7, top_p=0.9, batch_size=1 - Metriche: throughput (token/sec), utilizzo della memoria GPU (GB)
Configurazione vLLM per precisione
Tutte le precisioni utilizzano gpu_memory_utilization=0.90, max_model_len=4096.
Architettura a processi separati
Ogni benchmark viene eseguito come due processi separati per evitare la perdita di memoria (OOM):
- Passaggio 1: Carica il modello, esegui il riscaldamento, esegui il benchmark del throughput, salva nel file temporaneo, esci.
- Pulizia: Termina forzatamente i processi vLLM e Ray, attendi 10 secondi.
- Passaggio 2: Caricare il modello da zero, eseguire ogni attività di valutazione in un sottoprocesso separato, unire i risultati con le metriche del passaggio 1 e salvare il JSON finale.
Variabili controllate
Per eliminare i fattori esterni, i seguenti parametri sono stati mantenuti fissi in tutte le prove:
Suggerimenti per il test
I 5 quesiti del test:
- “Spiega la teoria della relatività in termini semplici.” (Scienza/Abstract)
- “Scrivi una funzione Python per trovare la sottostringa palindroma più lunga.” (Programmazione)
- “Quali sono le principali cause del cambiamento climatico e i loro effetti?” (Ragionamento complesso)
- “Descrivi il processo di fotosintesi passo dopo passo.” (Descrizione del processo)
- "Come fa una rete neurale ad apprendere dai dati?" (Spiegazione tecnica)
Verifica dei dati: telemetria in fase di esecuzione di vLLM
I valori relativi alla memoria e alla concorrenza riportati in questo articolo sono stati ricavati direttamente dai log di inizializzazione del motore vLLM durante l'esecuzione del benchmark.
Inizializzazione BF16:
Inizializzazione di GPTQ-Int4:
Limitazioni
Tutti i test utilizzano una dimensione batch pari a 1. Negli scenari ad alto throughput , il divario prestazionale tra Int4 e BF16 si amplia perché la saturazione della larghezza di banda della memoria diventa il collo di bottiglia dominante.
I risultati sono specifici per la H100 SXM. Le GPU più vecchie (A100, A10) non supportano nativamente FP8. Le GPU consumer (RTX 4090) hanno caratteristiche di larghezza di banda della memoria diverse.
I modelli GPTQ (JunHowie) sono quantizzazioni fornite dalla comunità scientifica. Le versioni ufficiali potrebbero utilizzare set di dati o parametri di calibrazione diversi, il che potrebbe influire sulla precisione.
Abbiamo testato solo GPTQ. Altri metodi di quantizzazione (AWQ, BitsAndBytes NF4, GGUF, HQQ) potrebbero offrire compromessi diversi.
Conclusione
Per Qwen3-32B su un H100, FP8 è la scelta predefinita. Si ottiene una velocità di elaborazione 1,5 volte superiore, metà dell'ingombro di memoria e un costo di precisione di 0,6 punti.
Int4 è la scelta ideale quando si necessita della massima velocità di elaborazione o di un elevato numero di operazioni concorrenti: velocità 2,7 volte superiore, concorrenza 12 volte maggiore, al costo di 1,6 punti su MMLU-Pro e 8 punti su HumanEval.
Int8 si posiziona a metà strada e in questa configurazione non offre un chiaro vantaggio rispetto a FP8. Il guadagno in termini di throughput rispetto a FP8 è minimo (43,3 contro 37,9 token/s) e l'accuratezza è comparabile. FP8 è più semplice perché è fornito ufficialmente dagli autori del modello e non richiede un checkpoint quantizzato di terze parti.
Il maggiore impatto pratico della quantizzazione non è la velocità, bensì la concorrenza. BF16 può servire 4 utenti con un contesto 4K su un singolo H100. Int4 può servirne 47. A 2,69 dollari l'ora, il costo per 1 milione di token scende da 28,73 dollari a 10,69 dollari.
Prossimo da leggere
Parametro di riferimento di Agentic LLM: confronto tra i 13 migliori LLM.
Motori di inferenza LLM: vLLM vs LMDeploy vs SGLang
Il panorama della valutazione dei Master in Giurisprudenza (LLM) con i relativi framework
Sii il primo a commentare
Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori.