Welches Quantisierungsformat Sie tatsächlich einsetzen sollten.

Hier beginnen

Der Großteil dieser Seite ist Rechnung, deshalb zuerst das Ergebnis. Vier Fragen entscheiden das Format, und sie werden in dieser Reihenfolge gestellt, weil jede für sich die Diskussion beenden kann.

Alles danach erklärt, warum diese vier Antworten so ausfallen, wie sie ausfallen, und liefert Ihnen die Zahlen, um sie an Ihrem eigenen Modell statt an unserem zu prüfen. Wenn Sie noch nicht ermittelt haben, wie viel Speicher Ihr Modell überhaupt braucht, ist diese Rechnung ein eigener Guide, und der kommt zuerst.

Drei Formate, vier Namen

Für das Serving sind nur drei Zahlenformate gebräuchlich, und sie unterscheiden sich in genau einer Sache: wie viele Byte jeder Parameter kostet. Alles andere — AWQ, GPTQ, GGUF, bitsandbytes — ist eine Methode, eines dieser drei zu erzeugen, kein viertes Format.

Lesen Sie die beiden Zahlenspalten als Paar. Sie sind in den ersten beiden Zeilen gleich und in der dritten nicht gleich, und genau diese eine Asymmetrie ist für die meisten Überraschungen weiter unten auf dieser Seite verantwortlich.

Die vier Namen, denen Sie in einem Modell-Repository tatsächlich begegnen, ordnen sich dieser Tabelle wie folgt zu.

Jede von ihnen anzufordern ist ein einziges Flag. Das sind dieselben Optionen, die der vLLM-Guide ausführlich behandelt; hier geht es nur darum, wie klein der Unterschied zwischen ihnen ist.

# 1. Reference. The weights as published, nothing to prepare.
$ vllm serve meta-llama/Llama-3.3-70B-Instruct --dtype bfloat16

# 2. FP8, quantised while it loads. No second download, no calibration.
#    --kv-cache-dtype is the half everyone forgets: it is what
#    halves the CACHE as well as the weights.
$ vllm serve meta-llama/Llama-3.3-70B-Instruct \
    --quantization fp8 --kv-cache-dtype fp8

# 3. Four-bit AWQ. A DIFFERENT checkpoint, prepared by someone else.
$ vllm serve casperhansen/llama-3.3-70b-instruct-awq \
    --quantization awq_marlin

# 4. Four-bit GPTQ. Same idea, different repository and flag.
$ vllm serve TechxGenus/Llama-3.3-70B-Instruct-GPTQ \
    --quantization gptq_marlin

Die Hälfte, die nicht schrumpft

Gewichte auf 4 Bit zu quantisieren, quantisiert nicht den Key/Value-Cache. AWQ und GPTQ komprimieren Gewichte und nur Gewichte; der Cache bleibt bei 16 Bit, sofern Sie nicht separat einen FP8-Cache anfordern, und bei einem 4-Bit-Checkpoint tun das die meisten nie. Das ist die dritte Spalte der Tabelle oben, und deshalb verläuft die Rechnung unten nicht so, wie man es erwartet.

Die Konsequenz lässt sich an einem Modell am leichtesten zeigen. Unten steht Llama 3.3 70B, in 4-Bit, bei jeder Kontextlänge, die der Konfigurator anbietet — Gewichte gegen Cache.

Die Gewichtsspalte bewegt sich nie — genau darum geht es beim Quantisieren. Die Cache-Spalte wächst linear mit dem Kontext, bis sie in der letzten Zeile größer ist als das Modell, zu dem sie gehört.

Treiben Sie das weit genug, und 4-Bit gewinnt gar nicht mehr. FP8 halbiert beide Hälften; 4-Bit viertelt eine Hälfte und lässt die andere unangetastet. Für jedes Modell gibt es also eine Kontextlänge, bei der sich die beiden kreuzen, und sie tritt umso früher ein, je kleiner das Modell ist — weil ein kleines Modell wenig Gewicht einzusparen hat, aber dasselbe Cache-Wachstum pro Token.

Werte in Gigabyte, für das kleinere der beiden Formate, mit dem Verlierer darunter benannt. Lesen Sie von links nach rechts und beobachten Sie, wie der Vorsprung der 4-Bit-Spalte mit wachsendem Kontext schwindet.

Die letzte Zeile behält überall ihren Vorsprung, denn 70 Milliarden Parameter sind eine Menge Gewicht, die sich einsparen lässt. Die mittlere Zeile endet in einem Gleichstand: Bei 128k kostet Qwen 3 32B in beiden Formaten exakt gleich viel, und der Qualität wegen würden Sie FP8 nehmen. Und die erste Zeile kehrt sich vollständig um at 128k, wo 4-Bit mehr Speicher braucht als FP8 und dabei auch noch das weniger originalgetreue der beiden ist. Diese Kombination — mehr Speicher und schlechtere Ausgabe — ist der mit Abstand häufigste Quantisierungsfehler, den wir sehen, und er ist unsichtbar, wenn man nur auf die Größe der Gewichtsdatei schaut.

Was Ihre Karte tatsächlich leistet

FP8 ist zuerst eine Hardware-Eigenschaft und erst dann eine Software-Eigenschaft. Eine Karte, deren Tensor-Cores es nicht beherrschen, lädt trotzdem einen FP8-Checkpoint — der Stack packt die Gewichte auf dem Weg zur Multiplikation auf 16 Bit aus —, aber Sie behalten nur die Ersparnis beim Download und nichts von der Geschwindigkeit, und ein FP8-Cache steht Ihnen gar nicht zur Verfügung. 4-Bit ist das Gegenteil: Es läuft überall, weil die Gewichte ohnehin vor der Berechnung auf 16 Bit ausgepackt werden.

Diese Spalte beschreibt das Silizium, was nicht ganz dieselbe Frage ist wie die, wo FP8 sinnvoll ist. Der eigene Vermerk des Katalogs beim Format nennt Hopper and Blackwell, und das ist eine Aussage über die Serving-Stacks, nicht über die Tensor-Cores: Das sind die Generationen, auf denen FP8-Kernel und FP8-Caches am meisten Einsatz und am wenigsten Überraschungen hatten. Ada Lovelace führt es aus. Hopper und Blackwell sind, wo wir ein Deployment platzieren würden, das darauf angewiesen ist.

Noch etwas Wissenswertes, bevor Sie eine Karte wählen. Llama 3.3 70B in FP8 bei 8k braucht 81.9 GB, und einer 80 GB-Karte — unter anderem der NVIDIA A100 PCIe — fehlen dafür 1.9 GB. Nicht knapp genug, um in einer Tabelle aufzufallen, aber knapp genug, um auf der Maschine zu scheitern. Die Karte, die es allein schafft, ist die nächstgrößere, und der Konfigurator sagt Ihnen, welche das ist, bevor Sie zahlen, statt danach.

Was es an Geschwindigkeit bringt

Ein Token zu erzeugen bedeutet, die aktiven Gewichte einmal aus dem Speicher zu lesen. Weniger Byte pro Gewicht bedeutet weniger zu lesende Byte, was mehr Token pro Sekunde bedeutet — und bei einem einzelnen ungebatchten Stream ist dieser Zusammenhang nahezu linear, weil die Karte auf nichts anderes wartet. Das ist dieselbe Speicherbandbreiten-Grenze, durch die der Kosten-pro-Token-Guide teilt, und sie ist bewusst konservativ angesetzt. Unten wird sie auf ein Modell angewendet, das klein genug ist, um auf jeder Einzelkartenmaschine zu laufen, die wir vermieten, sodass Format und Karte an derselben Tabelle abgelesen werden können.

Llama 3.1 8B auf einer Karte, ein Stream nach dem anderen. Jede gelistete Maschine fasst es in allen drei Formaten, sodass die Zeilen sowohl quer als auch untereinander vergleichbar sind — und das Verhältnis zwischen den drei Spalten ist in jeder Zeile gleich, weil es allein von den Bytes pro Gewicht bestimmt wird.

Zwei Vorbehalte zum Lesen dieser Tabelle. Der erste: Sie beschreibt eine Anfrage nach der anderen, und fast niemand bedient eine Anfrage nach der anderen: Unter kontinuierlichem Batching werden die Gewichte einmal für den ganzen Batch gelesen, sodass die Rechenleistung statt des Speichers zur Grenze wird und sich das Verhältnis zwischen den Spalten verengt. Der zweite: Dequantisieren kostet etwas. 4-Bit-Gewichte müssen vor der Multiplikation ausgepackt werden, und bei einem kleinen Modell mit niedriger Batch-Größe kann dieses Auspacken einen sichtbaren Teil dessen auffressen, was das kleinere Lesen eingebracht hat. Die Richtung der Tabelle ist verlässlich; die genauen Vielfachen sind kein Versprechen.

Was es Sie kostet

Das ist der Teil des Themas, in dem selbstsicheren Zahlen misstraut werden sollte, auch unseren. Der Quantisierungsfehler hängt weit mehr vom Modell ab als von der Methode, und die veröffentlichten Vergleiche widersprechen einander, weil sie unterschiedliche Modelle bei unterschiedlichen Aufgaben messen. Was sich ehrlich sagen lässt, ist die grobe Tendenz.

Das führt zur einzigen Empfehlung auf dieser Seite, die keine Rechnung ist: beides ausprobieren. Sie mieten eine Maschine mit Root-Zugriff und ohne jede Verbrauchsabrechnung, sodass es nur einen Abend kostet, dasselbe Modell zweimal auf zwei Ports zu betreiben und je hundert eigene Prompts hindurchzuschicken, und das beantwortet die Frage für Ihren Workload statt für den eines Fremden. Das ist eine deutlich bessere Antwort als jede Tabelle, auch diese hier — und deshalb zeigen wir Ihnen lieber die Formel als eine Punktzahl.

Welche Maschine das bedeutet

Der Grund, warum das alles zählt, ist die Rechnung. Unten steht die günstigste Maschine in unserem Katalog, die jedes Modell bei 8k Kontext ungeteilt hält, in jedem der drei Formate — ungeteilt heißt: auf einer Karte, ohne Aufteilung, denn ein über mehrere Karten aufgeteiltes Modell bringt den Interconnect ins Spiel, und das ist ein anderer Guide.

Bei 8k Kontext, auf den Maschinen, die wir tatsächlich vermieten. Wo eine Zelle mehrere Karten nennt, ist das der kleinste Knoten, in dem die Karte ausgeliefert wird, und kein aufgeteiltes Modell: Die größten Karten werden zu viert und zu acht verkauft, sodass der günstigste Weg, ein 70B bei voller Präzision nicht aufteilen zu müssen, darin besteht, vier davon zu kaufen und nur eine zu nutzen. Genau diese Rechnung soll Quantisierung vermeiden.

Zwei Gewohnheiten entscheiden darüber, ob Sie diese Tabelle richtig nutzen oder von ihr überrascht werden. Bemessen Sie nach dem Kontext, den Sie tatsächlich nutzen werden, nicht nach dem Maximum des Modells — die zweite Tabelle auf dieser Seite zeigt, was passiert, wenn man beides verwechselt. Und prüfen Sie das Format gegen die Karte, bevor Sie bestellen, nicht danach: NVIDIA RTX A6000, NVIDIA A100 PCIe und NVIDIA A100 SXM4 kann Ihnen die FP8-Werte nicht liefern, egal welches Flag Sie setzen. Der Konfigurator zeigt den benötigten Speicher und ob er auf eine Karte passt, für jeden Knoten und jedes Format, bevor irgendetwas bezahlt wird. Falls Sie abwägen, ob Sie überhaupt mieten sollten statt eine API pro Token zu bezahlen, wird dieser Break-even gesondert berechnet, und Quantisierung verschiebt ihn deutlich zugunsten der Hardware.