LLM-Quantisierung: BF16 vs FP8 vs INT4
Wir haben Qwen3-32B mit vier Präzisionsstufen (BF16, FP8, GPTQ-Int8, GPTQ-Int4) auf einer einzelnen NVIDIA H100 80GB GPU getestet. Jede Konfiguration wurde anhand von zwei Benchmarks (~12.200 Fragen) zur Wissens- und Codegenerierung sowie über 2.000 Inferenzläufen zur Messung des Durchsatzes evaluiert. Int4 ist 2,7-mal schneller als BF16 und verliert dabei weniger als 2 Punkte im MMLU-Pro-Benchmark, jedoch 8 Punkte in der Codegenerierung (HumanEval).
Benchmark-Ergebnisse der Quantisierung
MMLU-Pro testet das allgemeine Denkvermögen in 14 Bereichen (ca. 12.000 Fragen, 5-Shot-Test). Dies ist die schwierigere Version von MMLU mit 10-Antwortmöglichkeiten anstelle von 4.
HumanEval testet die Codegenerierung (164 Aufgaben, 1 bestanden). 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.
Der Durchsatz gibt die Anzahl der ausgegebenen Token pro Sekunde bei einer Batchgröße von 1 an.
Die Modellgröße entspricht dem GPU-Speicher, der ausschließlich von den Gewichten belegt wird, gemessen nach dem Laden.
MMLU-Pro-Aufschlüsselung nach Kategorien
Ingenieurwesen und Jura weisen die größten Rückgänge bei Int4 auf. Mathematik bleibt über alle Genauigkeiten 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 vorreserviert. Die eigentliche Frage ist, wie dieser Speicher zwischen Modellgewichten und KV-Cache aufgeteilt wird, da der KV-Cache die Anzahl der gleichzeitig bedienbaren Benutzer bestimmt.
Die maximale Anzahl an Benutzern (Max Users) ist die speicherbedingte Obergrenze vor einem OutOfMemoryError (OOM): die gesamte Tokenkapazität geteilt durch die Kontextlänge pro Benutzer. Dies ist das theoretische Maximum. In der Praxis wird es durch den Scheduling-Overhead geringfügig reduziert.
Dies hat direkte Auswirkungen auf die Schlussfolgerungsmodelle. DeepSeek-R1 und Qwen-QwQ generieren Tausende interner „Gedanken“-Token (oft 2.000–5.000), bevor sie eine endgültige Antwort liefern. Auf BF16 könnte eine einzelne Schlussfolgerungsanfrage die gesamte Token-Kapazität von 17.000 belegen und einen zweiten Benutzer blockieren. Auf Int4 reicht die Kapazität von 193.000 Token für mehrere gleichzeitige Schlussfolgerungssitzungen aus.
Wichtigste Erkenntnisse
FP8 verliert keine messbare Genauigkeit
FP8 erzielt auf MMLU-Pro 69,64 % gegenüber 70,24 % für BF16 – ein Unterschied von 0,6 Punkten bei 12.000 Fragen. Auf HumanEval erreichen FP8 und BF16 mit 39,02 % das gleiche Ergebnis. FP8 bietet den 1,5-fachen Durchsatz und halbiert die Modellgröße bei einem Leistungsverlust von 0,6 Punkten.
GPTQ-Int8 erzielt 70,32 % im MMLU-Pro-Test, fällt aber im HumanEval-Test um 1,8 Punkte auf 37,20 %. Wenn die Codegenerierung wichtig ist, ist FP8 die sicherere Wahl.
Int4 verschlechtert die Codegenerierung stärker 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 Codegenerierung erfordert präzise Tokenvorhersagen, da sich kleine Gewichtungsfehler über Funktionsrümpfe hinweg summieren.
Der eigentliche Gewinn liegt in der Parallelverarbeitung, nicht in der Geschwindigkeit.
Int4 ist 2,7-mal schneller als BF16. Der größere Effekt zeigt sich jedoch im Speicherverbrauch. BF16 lässt nur 4,4 GB für den KV-Cache übrig, ausreichend für etwa 4 gleichzeitige Benutzer im 4K-Kontext. Int4 gibt 47,3 GB frei, genug für 47 Benutzer – eine 12-fache Steigerung der Serverkapazität mit derselben GPU.
Die Mathematik-Ergebnisse gelten für alle Genauigkeitsstufen.
Die Mathematik-Ergebnisse verändern sich kaum: 81,87 % bei BF16, 81,87 % bei FP8, 81,87 % bei Int8, 80,24 % bei Int4. Ingenieurwesen (49,64 % auf 43,45 %) und Jura (43,05 % auf 40,60 %) reagieren sensibler.
Kosten pro Token
Bei Verwendung des H100 SXM-Preises auf RunPod (2,69 $/Stunde) bei einer Batchgröße von 1:
Diese Zahlen beziehen sich auf die Echtzeitgenerierung durch einen einzelnen Benutzer. Die Stapelverarbeitung senkt die Kosten weiter.
LLM-Quantisierungs-Benchmark-Methodik
Umfeld
- 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 (nach dem Training/der Instruktionsoptimierung) von HuggingFace. Keine Feinabstimmung angewendet.
Genauigkeitsbewertung
- Alle Auswertungen werden über
lm-evaluation-harnessmitbatch_size="auto"durchgeführt. - Jeder Task läuft in einem separaten Subprozess . Das Modell wird jedes Mal neu geladen, die GPU zwischen den Tasks vollständig bereinigt. Dadurch wird ein Speichermangel aufgrund von Speicherfragmentierung verhindert.
- HumanEval wird mit
HF_ALLOW_CODE_EVAL=1(Codeausführung aktiviert) ausgeführt. - Die Ergebnisse von MMLU-Pro beinhalten eine Aufschlüsselung nach Kategorien (Biologie, Mathematik, Physik, Jura usw.).
- Der Denkmodus von Qwen3 war während der Auswertungen nicht aktiv. lm-evaluation-harness sendet formatierte Rohdaten-Prompts, ohne die Chatvorlage des Modells anzuwenden (
apply_chat_template=Falsestandardmäßig), sodass das<think>-Token nie eingefügt wird.
Leistungsbeurteilung
- 5 wechselnde Aufgabenstellungen aus verschiedenen Bereichen (Wissenschaft, Programmierung, Allgemeinwissen)
- 10 Aufwärmiterationen (nicht gemessen), dann 500 gemessene Iterationen
- Feste Ausgabe:
max_tokens=256, temperature=0.7, top_p=0.9, batch_size=1 - Kennzahlen: Durchsatz (Token/Sek.), GPU-Speichernutzung (GB)
vLLM-Konfiguration pro Präzision
Alle Präzisionen verwenden gpu_memory_utilization=0.90, max_model_len=4096 .
Split-Prozess-Architektur
Jeder Benchmark wird als zwei separate Prozesse ausgeführt, um einen Speichermangel zu verhindern:
- Schritt 1: Modell laden, Aufwärmphase, Durchsatzmessung, in temporärer Datei speichern, beenden.
- Aufräumarbeiten: Die vLLM- und Ray-Prozesse zwangsweise beenden, 10 Sekunden warten.
- Schritt 2: Modell neu laden, jede Auswertungsaufgabe in einem separaten Unterprozess ausführen, mit den Metriken aus Schritt 1 zusammenführen, endgültiges JSON speichern.
Kontrollierte Variablen
Um externe Faktoren auszuschließen, wurden die folgenden Parameter in allen Durchläufen festgelegt:
Testaufforderungen
Die 5 Testfragen:
- „Erklären Sie die Relativitätstheorie in einfachen Worten.“ (Wissenschaft/Abstract)
- „Schreiben Sie eine Python-Funktion, die die längste palindromische Teilzeichenkette findet.“ (Programmierung)
- „Was sind die Hauptursachen des Klimawandels und seine Auswirkungen?“ (Komplexes Denken)
- „Beschreiben Sie den Ablauf der Photosynthese Schritt für Schritt.“ (Prozessbeschreibung)
- „Wie lernt ein neuronales Netzwerk aus Daten?“ (Technische Erklärung)
Datenverifizierung: vLLM-Laufzeittelemetrie
Die in diesem Artikel genannten Speicher- und Parallelitätswerte wurden direkt aus den Initialisierungsprotokollen der vLLM-Engine während der Benchmark-Ausführung abgeleitet.
BF16-Initialisierung:
GPTQ-Int4-Initialisierung:
Einschränkungen
Alle Tests verwenden eine Batchgröße von 1. In Szenarien mit hohem Durchsatz vergrößert sich die Leistungslücke zwischen Int4 und BF16, da die Sättigung der Speicherbandbreite zum dominierenden Flaschenhals wird.
Die Ergebnisse gelten speziell für die H100 SXM. Ältere GPUs (A100, A10) unterstützen FP8 nicht nativ. Consumer-GPUs (RTX 4090) weisen unterschiedliche Speicherbandbreiten auf.
Die GPTQ-Modelle (JunHowie) sind von der Community bereitgestellte Quantisierungen. Offizielle Versionen verwenden möglicherweise andere Kalibrierungsdatensätze oder Parameter, was die Genauigkeit beeinträchtigen kann.
Wir haben nur GPTQ getestet. Andere Quantisierungsmethoden (AWQ, BitsAndBytes NF4, GGUF, HQQ) könnten andere Vor- und Nachteile bieten.
Abschluss
Für Qwen3-32B auf einem H100 ist FP8 die Standardwahl. Sie erhalten die 1,5-fache Durchsatzrate, den halben Speicherbedarf und einen Genauigkeitsverlust von 0,6 Punkten.
Int4 ist sinnvoll, wenn maximaler Durchsatz oder maximale Parallelität erforderlich ist: 2,7-fache Geschwindigkeit, 12-fache Parallelität, allerdings auf Kosten von 1,6 Punkten beim MMLU-Pro und 8 Punkten beim HumanEval.
Int8 liegt dazwischen und bietet in dieser Konfiguration keinen klaren Vorteil gegenüber FP8. Der Durchsatzgewinn gegenüber FP8 ist gering (43,3 vs. 37,9 kT/s), und die Genauigkeit ist vergleichbar. FP8 ist einfacher, da es offiziell von den Modellentwicklern bereitgestellt wird und keinen externen quantisierten Checkpoint benötigt.
Der größte praktische Vorteil der Quantisierung liegt nicht in der Geschwindigkeit, sondern in der Parallelverarbeitung. BF16 kann auf einem einzelnen H100-Server 4 Benutzer mit 4K-Kontext bedienen. Int4 schafft 47. Bei 2,69 $/Stunde sinken die Kosten pro 1 Million Token von 28,73 $ auf 10,69 $.
Seien Sie der Erste, der kommentiert
Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich.