LLM Quantizzazione: BF16 vs FP8 vs INT4

Ekrem Sarı

con

Sıla Ermut

aggiornato il 17 mar. 2026

Guarda il nostro norme etiche

Cita Questa Ricerca

Abbiamo benchmarkato Qwen3-32B a 4 livelli di precisione (BF16, FP8, GPTQ-Int8, GPTQ-Int4) su una singola NVIDIA H100 80GB GPU. Ogni configurazione è stata valutata su 2 benchmark (~12,2K domande) che coprono conoscenza e generazione di codice, oltre a oltre 2.000 esecuzioni di inferenza per misurare il throughput. Int4 è 2,7x più veloce di BF16 pur perdendo meno di 2 punti su MMLU-Pro, ma la generazione di codice (HumanEval) perde 8 punti.

Risultati del benchmark di quantizzazione

Loading Chart

MMLU-Pro verifica il ragionamento ampio su 14 domini (~12K domande, 5-shot). Questa è la versione più difficile di MMLU con domande a 10 scelte invece di 4.

HumanEval verifica la generazione di codice (164 problemi, pass@1). Il modello scrive funzioni Python che vengono eseguite su test unitari. Questo è l'unico benchmark in cui l'output viene eseguito, non solo valutato.

Throughput è token di output al secondo con dimensione batch 1.

Dimensione del modello è la memoria GPU consumata solo dai pesi, misurata dopo il caricamento.

Sudddivisione MMLU-Pro per categoria

Categoria	BF16	FP8	GPTQ-Int8	GPTQ-Int4
Biologia	86.19%	86.47%	86.61%	86.05%
Business	75.67%	76.43%	77.44%	77.19%
Chimica	74.12%	73.41%	73.94%	72.08%
Informatica	74.15%	75.37%	74.39%	73.90%
Economia	81.75%	81.75%	81.40%	80.69%
Ingegneria	49.64%	45.41%	47.06%	43.45%
Salute	73.59%	72.49%	73.72%	71.52%
Storia	62.20%	61.15%	60.63%	62.47%
Legge	43.05%	41.69%	43.78%	40.60%
Matematica	81.87%	81.87%	81.87%	80.24%

Ingegneria e legge mostrano i maggiori cali con Int4. Matematica rimane stabile su tutte le precisioni.

Capacità di memoria e concorrenza

Strumenti di monitoraggio GPU come nvidia-smi riportano un utilizzo quasi pieno indipendentemente dalla dimensione del modello perché vLLM pre-alloca tutta la memoria disponibile. La vera domanda è come quella memoria si divide tra pesi del modello e KV cache, perché la KV cache determina quanti utenti puoi servire contemporaneamente.

Il numero massimo di utenti è il limite di memoria prima dell'OOM: capacità totale di token divisa per la lunghezza del contesto per utente. Questo è il massimo teorico. In pratica, l'overhead di scheduling lo riduce leggermente.

Ciò ha implicazioni dirette per i modelli di ragionamento. DeepSeek-R1 e Qwen-QwQ generano migliaia di token interni di “pensiero” (spesso 2K-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 concorrenti.

Risultati principali

FP8 non perde alcuna accuratezza misurabile

FP8 ottiene 69,64% su MMLU-Pro contro 70,24% per BF16, una differenza di 0,6 punti su 12.000 domande. Su HumanEval, sia FP8 che BF16 ottengono lo stesso punteggio di 39,02%. FP8 ti dà 1,5x di throughput e dimezza la dimensione del modello per un costo di 0,6 punti.

GPTQ-Int8 ottiene 70,32% su MMLU-Pro ma perde 1,8 punti su HumanEval (37,20%). Se la generazione di codice è importante, FP8 è la scelta più sicura.

Int4 degrada la generazione di codice più della conoscenza

MMLU-Pro perde 1,6 punti con Int4 (70,24% a 68,66%). HumanEval perde 8 punti (39,02% a 31,10%). La generazione di codice richiede previsioni precise dei token in cui piccoli errori di peso si accumulano attraverso i corpi delle funzioni.

Il vero vantaggio è la concorrenza, non la velocità

Int4 è 2,7x più veloce di BF16. Ma l'effetto maggiore è sulla memoria. BF16 lascia solo 4,4 GB per la KV cache, sufficienti per circa 4 utenti concorrenti con contesto 4K. Int4 libera 47,3 GB, sufficienti per 47 utenti, un aumento di 12x della capacità di servizio dalla stessa GPU.

I punteggi di matematica reggono su tutte le precisioni

I punteggi di matematica si muovono appena: 81,87% con BF16, 81,87% con FP8, 81,87% con Int8, 80,24% con Int4. Ingegneria (49,64% a 43,45%) e legge (43,05% a 40,60%) sono più sensibili.

Costo per token

Utilizzando il prezzo di H100 SXM su RunPod ($2,69/ora) con dimensione batch 1:

Questi numeri riflettono la generazione in tempo reale per singolo utente. L'elaborazione batch riduce ulteriormente il costo.

Non perderti i nostri benchmark e approfondimenti basati sui dati. Il pulsante apre Google; selezionare AIMultiple conferma che desideri vedere AIMultiple più spesso nei risultati di ricerca di Google.

Aggiungi come fonte preferita

LLM metodologia del benchmark di quantizzazione

Ambiente

GPU: Singola NVIDIA H100 80GB HBM3 (SXM) via 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-addestrato/instruction-tuned) da HuggingFace. Nessun fine-tuning applicato.

Valutazione dell'accuratezza

Benchmark	Domande	Tipo	Few-shot	Metrica
MMLU-Pro (completo, 14 categorie)	~12K	generate_until	5-shot	exact_match
HumanEval	164	generate_until	0-shot	pass@1

Tutte le valutazioni vengono eseguite tramite lm-evaluation-harness con batch_size="auto".
Ogni task viene eseguito in un sottoprocesso separato. Il modello viene caricato ex novo ogni volta, GPU completamente pulita tra i task. Questo previene l'OOM dovuto alla frammentazione della memoria.
HumanEval viene eseguito con HF_ALLOW_CODE_EVAL=1 (esecuzione del codice abilitata).
I risultati MMLU-Pro includono la suddivisione per categoria (biologia, matematica, fisica, legge, ecc.).
La modalità di pensiero di Qwen3 non era attiva durante le valutazioni. lm-evaluation-harness invia prompt formattati grezzi senza applicare il template di chat del modello (apply_chat_template=False per impostazione predefinita), quindi il token <think> non viene mai iniettato.

Valutazione delle prestazioni

5 prompt rotanti tra domini (scienza, programmazione, conoscenze generali)
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/s), utilizzo memoria GPU (GB)

Configurazione vLLM per precisione

Precisione	HuggingFace ID	Configurazione vLLM
BF16	`Qwen/Qwen3-32B`	`dtype="bfloat16"`
FP8	`Qwen/Qwen3-32B-FP8`	`dtype="bfloat16"`
GPTQ-Int8	`JunHowie/Qwen3-32B-GPTQ-Int8`	`dtype="float16", quantization="gptq_marlin"`
GPTQ-Int4	`JunHowie/Qwen3-32B-GPTQ-Int4`	`dtype="float16", quantization="gptq_marlin"`

Tutte le precisioni usano gpu_memory_utilization=0.90, max_model_len=4096.

Architettura a processo diviso

Ogni benchmark viene eseguito come due processi separati per prevenire OOM:

Passo 1: Carica modello, riscaldamento, benchmark throughput, salva su file temporaneo, esci.
Pulizia: Forza la chiusura dei processi vLLM e Ray, attendi 10 secondi.
Passo 2: Carica modello ex novo, esegui ogni task di valutazione in un sottoprocesso separato, unisci con le metriche del passo 1, salva JSON finale.

Variabili controllate

Per eliminare fattori esterni, i seguenti parametri sono stati fissati in tutte le esecuzioni:

Parametro	Valore	Motivazione
Dimensione batch	1	Simula la latenza per singolo utente. Dimensioni di batch maggiori amplificano il vantaggio di banda dei modelli quantizzati, ma la dimensione batch 1 è il caso peggiore per l'utilizzo del calcolo.
Lunghezza output	256 token	Limite di generazione fisso per garantire che il throughput sia misurato su un carico di lavoro coerente.
Temperatura	0.7	Parametro di campionamento standard.
Top-p	0.9	Soglia standard di campionamento nucleus.
Utilizzo memoria GPU	0.90	Tarato empiricamente. Valori più alti (0.95, 0.98) causavano OOM durante il riscaldamento del grafo CUDA o valutazione con batch grandi.
Protocollo di pulizia	Rigoroso	Tra ogni esecuzione, tutti i processi vLLM e Ray vengono forzatamente chiusi e la memoria GPU viene verificata pulita prima dell'inizio dell'esecuzione successiva.

Prompt di test

I 5 prompt di test:

“Spiega la teoria della relatività in termini semplici.” (Scienza/Astratto)
“Scrivi una funzione Python per trovare la più lunga sottostringa palindroma.” (Programmazione)
“Quali sono le principali cause del cambiamento climatico e i loro effetti?” (Ragionamento complesso)
“Descrivi il processo di fotosintesi passo dopo passo.” (Descrizione di processo)
“Come impara una rete neurale dai dati?” (Spiegazione tecnica)

Verifica dei dati: telemetria runtime di vLLM

Le cifre di memoria e concorrenza in questo articolo sono state derivate direttamente dai log di inizializzazione del motore vLLM engine initialization durante l'esecuzione del benchmark.

BF16 inizializzazione:

1INFO ... Model loading took 61.03 GiB memory
2INFO ... Available KV cache memory: 4.38 GiB
3INFO ... GPU KV cache size: 17,952 tokens
4INFO ... Maximum concurrency for 4,096 tokens per request: 4.38x

GPTQ-Int4 inizializzazione:

1INFO ... Model loading took 18.14 GiB memory
2INFO ... Available KV cache memory: 47.28 GiB
3INFO ... GPU KV cache size: 193,632 tokens
4INFO ... Maximum concurrency for 4,096 tokens per request: 47.27x

Limitazioni

Tutti i test usano dimensione batch 1. In scenari ad alto throughput, il divario di prestazioni 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 H100 SXM. Le GPU più vecchie (A100, A10) mancano del supporto nativo FP8. Le GPU consumer (RTX 4090) hanno caratteristiche di larghezza di banda della memoria diverse.

I modelli GPTQ (JunHowie) sono quantizzazioni fornite dalla comunità. I rilasci ufficiali potrebbero usare dataset di calibrazione o parametri diversi, che possono influenzare l'accuratezza.

Abbiamo testato solo GPTQ. Altri metodi di quantizzazione (AWQ, BitsAndBytes NF4, GGUF, HQQ) potrebbero offrire compromessi diversi.

Conclusione

Per Qwen3-32B su una H100, FP8 è la scelta predefinita. Ottieni 1,5x il throughput, metà dell'ingombro di memoria e un costo di accuratezza di 0,6 punti.

Int4 ha senso quando hai bisogno del massimo throughput o concorrenza: velocità 2,7x, concorrenza 12x, al costo di 1,6 punti su MMLU-Pro e 8 punti su HumanEval.

Int8 si colloca a metà e non offre un chiaro vantaggio rispetto a FP8 in questa configurazione. Il guadagno di throughput rispetto a FP8 è piccolo (43,3 contro 37,9 tok/s) e l'accuratezza è comparabile. FP8 è più semplice perché è fornito ufficialmente dagli autori del modello e non richiede un checkpoint quantizzato di terze parti.

L'impatto pratico più grande della quantizzazione non è la velocità, è la concorrenza. BF16 può servire 4 utenti con contesto 4K su una singola H100. Int4 può servirne 47. A $2,69/ora, ciò porta il costo per 1M token da $28,73 a $10,69.

Cita questa ricerca

Scegli il formato adatto a dove pubblicherai. Incollare la versione con link nel tuo CMS preserva il backlink.

Ekrem Sarı and Sıla Ermut (2026) - "LLM Quantizzazione: BF16 vs FP8 vs INT4". Pubblicato online su AIMultiple.com. Consultato il 17 Marzo 2026, da: https://aimultiple.com/llm-quantization [Risorsa online]

Sarı, E., & Ermut, S. (2026, 17 Marzo). LLM Quantizzazione: BF16 vs FP8 vs INT4. AIMultiple. https://aimultiple.com/llm-quantization

@misc{sar2026,
  author = {Sarı, Ekrem and Ermut, Sıla},
  title  = {{LLM Quantizzazione: BF16 vs FP8 vs INT4}},
  year   = {2026},
  month  = mar,
  howpublished    = {\url{https://aimultiple.com/llm-quantization}},
  note   = {AIMultiple. Consultato il 17 Marzo 2026}
}

Ekrem Sarı

Ricercatore di intelligenza artificiale

Segui

Ekrem è un ricercatore di intelligenza artificiale presso AIMultiple, specializzato in automazione intelligente, GPU, agenti di intelligenza artificiale e framework RAG.

Visualizza il profilo completo

Ricercato da

Sıla Ermut

Analista di settore

Segui

Sıla Ermut è un'analista di settore presso AIMultiple, specializzata in email marketing e video di vendita. In precedenza, ha lavorato come reclutatrice in società di project management e consulenza. Sıla ha conseguito un Master in Psicologia Sociale e una laurea in Relazioni Internazionali.

Visualizza il profilo completo