LLM Quantisierung: BF16 vs FP8 vs INT4
Wir haben Qwen3-32B auf 4 Genauigkeitsstufen (BF16, FP8, GPTQ-Int8, GPTQ-Int4) auf einer einzelnen NVIDIA H100 80GB GPU getestet. Jede Konfiguration wurde auf 2 Benchmarks (~12,2K Fragen) bewertet, die Wissen und Code-Generierung abdecken, sowie auf 2.000+ Inferenzläufen zur Messung des Durchsatzes. Int4 ist 2,7-mal schneller als BF16, verliert jedoch weniger als 2 Punkte auf MMLU-Pro, während die Code-Generierung (HumanEval) um 8 Punkte sinkt.
Ergebnisse des Quantisierungs-Benchmarks
MMLU-Pro testet das breite Denken über 14 Domänen hinweg (~12K Fragen, 5-Shot). Dies ist die schwierigere Version von MMLU mit 10-Auswahl-Fragen statt 4.
HumanEval testet die Code-Generierung (164 Probleme, pass@1). Das Modell schreibt Python-Funktionen, die gegen Unit-Tests ausgeführt werden. Dies ist der einzige Benchmark, bei dem die Ausgabe ausgeführt und nicht nur bewertet wird.
Durchsatz ist die Anzahl der Tokens pro Sekunde bei Batch-Größe 1.
Modellgröße ist der von den Gewichten allein verbrauchte GPU-Speicher, gemessen nach dem Laden.
MMLU-Pro-Aufschlüsselung nach Kategorie
Ingenieurwesen und Recht zeigen die größten Rückgänge bei Int4. Mathematik bleibt über alle Genauigkeitsstufen hinweg stabil.
Speicherkapazität und Parallelität
GPU-Überwachungstools wie nvidia-smi melden eine nahezu vollständige Auslastung, unabhängig von der Modellgröße, da vLLM den gesamten verfügbaren Speicher vorab zuweist. Die eigentliche Frage ist, wie sich dieser Speicher zwischen Modellgewichten und KV-Cache aufteilt, da der KV-Cache bestimmt, wie viele Benutzer Sie parallel bedienen können.
Max-Benutzer ist die speichergebundene Obergrenze vor OOM: Gesamte Token-Kapazität geteilt durch Kontextlänge pro Benutzer. Dies ist das theoretische Maximum. In der Praxis reduziert der Scheduling-Overhead dies leicht.
Dies hat direkte Auswirkungen auf Reasoning-Modelle. DeepSeek-R1 und Qwen-QwQ generieren Tausende interner „Gedanken"-Tokens (oft 2K-5K), bevor sie eine endgültige Antwort produzieren. Bei BF16 könnte eine einzelne Reasoning-Anfrage die gesamte 17K-Token-Kapazität verbrauchen und einen zweiten Benutzer blockieren. Bei Int4 passt die 193K-Kapazität mehrere parallele Reasoning-Sitzungen.
Wichtige Erkenntnisse
FP8 verliert keine messbare Genauigkeit
FP8 erzielt 69,64% auf MMLU-Pro im Vergleich zu 70,24% für BF16, ein Unterschied von 0,6 Punkten über 12.000 Fragen. Auf HumanEval erzielen sowohl FP8 als auch BF16 identisch 39,02%. FP8 bietet Ihnen 1,5-fachen Durchsatz und halbiert Ihre Modellgröße für einen Kostenpunkt von 0,6.
GPTQ-Int8 erzielt 70,32% auf MMLU-Pro, verliert jedoch 1,8 Punkte auf HumanEval (37,20%). Wenn Code-Generierung wichtig ist, ist FP8 die sicherere Wahl.
Int4 beeinträchtigt die Code-Generierung mehr als das Wissen
MMLU-Pro sinkt bei Int4 um 1,6 Punkte (von 70,24% auf 68,66%). HumanEval sinkt um 8 Punkte (von 39,02% auf 31,10%). Die Code-Generierung erfordert präzise Token-Vorhersagen, bei denen kleine Gewichtsfehler sich über Funktionskörper hinweg summieren.
Der eigentliche Gewinn ist die Parallelität, nicht die Geschwindigkeit
Int4 ist 2,7-mal schneller als BF16. Aber der größere Effekt betrifft den Speicher. BF16 lässt nur 4,4 GB für den KV-Cache übrig, genug für etwa 4 parallele Benutzer bei 4K-Kontext. Int4 gibt 47,3 GB frei, genug für 47 Benutzer, eine 12-fache Steigerung der服务能力 derselben GPU.
Mathematikergebnisse bleiben über alle Genauigkeitsstufen hinweg stabil
Mathematikergebnisse bewegen sich kaum: 81,87% bei BF16, 81,87% bei FP8, 81,87% bei Int8, 80,24% bei Int4. Ingenieurwesen (von 49,64% auf 43,45%) und Recht (von 43,05% auf 40,60%) sind empfindlicher.
Kosten pro Token
Unter Verwendung von H100 SXM-Preisen auf RunPod (2,69 $/Stunde) bei Batch-Größe 1:
Diese Zahlen spiegeln die Echtzeit-Generierung für einzelne Benutzer wider. Die Batch-Verarbeitung senkt die Kosten weiter.
Als bevorzugte Quelle hinzufügenLLM-Quantisierungs-Benchmark-Methodik
Umgebung
- GPU: Einzelne NVIDIA H100 80GB HBM3 (SXM) über RunPod (2,69 $/Std.)
- Software: vLLM 0.17.0, lm-evaluation-harness 0.4.11, PyTorch 2.8.0, CUDA 12.8, Python 3.11
- Modell: Qwen3-32B (nachtrainiert/anweisungsangepasst) von HuggingFace. Keine Fine-Tuning angewendet.
Genauigkeitsbewertung
- Alle Bewertungen werden über
lm-evaluation-harnessmitbatch_size="auto"ausgeführt. - Jede Aufgabe wird in einem separaten Subprozess ausgeführt. Das Modell wird jedes Mal frisch geladen, GPU zwischen den Aufgaben vollständig bereinigt. Dies verhindert OOM durch Speicherd fragmentation.
- HumanEval wird mit
HF_ALLOW_CODE_EVAL=1ausgeführt (Code-Ausführung aktiviert). - MMLU-Pro-Ergebnisse umfassen eine Aufschlüsselung pro Kategorie (Biologie, Mathematik, Physik, Recht usw.).
- Der Denkmodus von Qwen3 war während der Bewertungen nicht aktiv. lm-evaluation-harness sendet rohe formatierte Prompts, ohne die Chat-Vorlage des Modells anzuwenden (
apply_chat_template=Falsestandardmäßig), sodass das<think>-Token niemals eingefügt wird.
Leistungsbewertung
- 5 rotierende Prompts über Domänen hinweg (Wissenschaft, Codierung, Allgemeinwissen)
- 10 Warmup-Iterationen (nicht gemessen), dann 500 gemessene Iterationen
- Feste Ausgabe:
max_tokens=256, temperature=0.7, top_p=0.9, batch_size=1 - Metriken: Durchsatz (Tokens/Sekunde), GPU-Speichernutzung (GB)
vLLM-Konfiguration pro Genauigkeit
Alle Genauigkeiten verwenden gpu_memory_utilization=0.90, max_model_len=4096.
Split-Prozess-Architektur
Jeder Benchmark wird als zwei separate Prozesse ausgeführt, um OOM zu verhindern:
- Schritt 1: Modell laden, Warmup, Durchsatz testen, in temporäre Datei speichern, beenden.
- Bereinigung: vLLM- und Ray-Prozesse erzwingen, 10 Sekunden warten.
- Schritt 2: Modell frisch laden, jede Eval-Aufgabe in einem separaten Subprozess ausführen, mit Schritt-1-Metriken zusammenführen, finales JSON speichern.
Kontrollierte Variablen
Um externe Faktoren auszuschließen, wurden folgende Parameter über alle Läufe hinweg festgelegt:
Test-Prompts
Die 5 Test-Prompts:
- „Erklären Sie die Relativitätstheorie in einfachen Worten." (Wissenschaft/Abstrakt)
- „Schreiben Sie eine Python-Funktion, um die längste palindromische Teilzeichenkette zu finden." (Codierung)
- „Was sind die Hauptursachen des Klimawandels und ihre Auswirkungen?" (Komplexes Denken)
- „Beschreiben Sie den Prozess der Photosynthese Schritt für Schritt." (Prozessbeschreibung)
- „Wie lernt ein neuronales Netzwerk aus Daten?" (Technische Erklärung)
Datenverifizierung: vLLM-Laufzeit-Telemetrie
Die Speicher- und Parallelitätszahlen in diesem Artikel wurden direkt aus den vLLM-Engine-Initialisierungs-Protokollen während der Benchmark-Ausführung abgeleitet.
BF16-Initialisierung:
GPTQ-Int4-Initialisierung:
Einschränkungen
Alle Tests verwenden Batch-Größe 1. In High-Throughput-Szenarien vergrößert sich die Leistungslücke zwischen Int4 und BF16, da die Sättigung der Speicherbandbreite zum dominierenden Engpass wird.
Die Ergebnisse sind spezifisch für das H100 SXM. Ältere GPUs (A100, A10) verfügen nicht über native FP8-Unterstützung. Consumer-GPUs (RTX 4090) haben unterschiedliche Speicherbandbreitenmerkmale.
Die GPTQ-Modelle (JunHowie) sind von der Community bereitgestellte Quantisierungen. Offizielle Releases können andere Kalibrierungsdatensätze oder Parameter verwenden, was die Genauigkeit beeinflussen kann.
Wir haben nur GPTQ getestet. Andere Quantisierungsmethoden (AWQ, BitsAndBytes NF4, GGUF, HQQ) könnten andere Kompromisse bieten.
Fazit
Für Qwen3-32B auf einer H100 ist FP8 die Standardwahl. Sie erhalten 1,5-fachen Durchsatz, die Hälfte des Speicherverbrauchs und einen Genauigkeitsverlust von 0,6 Punkten.
Int4 macht Sinn, wenn Sie maximalen Durchsatz oder Parallelität benötigen: 2,7-fache Geschwindigkeit, 12-fache Parallelität, auf Kosten von 1,6 Punkten auf MMLU-Pro und 8 Punkten auf HumanEval.
Int8 liegt in der Mitte und bietet in diesem Setup keinen klaren Vorteil gegenüber FP8. Der Durchsatzgewinn gegenüber FP8 ist gering (43,3 vs. 37,9 tok/s) und die Genauigkeit ist vergleichbar. FP8 ist einfacher, da es offiziell von den Modellautoren bereitgestellt wird und keinen Drittanbieter-Quantisierungscheckpoint erfordert.
Die größte praktische Auswirkung der Quantisierung ist nicht die Geschwindigkeit, sondern die Parallelität. BF16 kann 4 Benutzer bei 4K-Kontext auf einer einzelnen H100 bedienen. Int4 kann 47 bedienen. Bei 2,69 $/Std. sinken die Kosten pro 1M Tokens von 28,73 $ auf 10,69 $.
Diese Forschung zitieren
Wählen Sie das Format, das zu Ihrem Veröffentlichungsort passt. Wenn Sie die Link-Version in Ihr CMS einfügen, bleibt der Backlink erhalten.
@misc{sar2026,
author = {Sarı, Ekrem and Ermut, Sıla},
title = {{LLM Quantisierung: BF16 vs FP8 vs INT4}},
year = {2026},
month = mar,
howpublished = {\url{https://aimultiple.com/llm-quantization}},
note = {AIMultiple. Abgerufen am 17. März 2026}
}
Seien Sie der Erste, der kommentiert
Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.