Dimensionierung-Guide · 10 Min. Lesezeit

# Welches Quantisierungsformat Sie tatsächlich einsetzen sollten.

Ein Serving-Stack fragt zuerst nach einem Zahlenformat, noch vor allem anderen, und die Antwort verschiebt Ihre monatliche Rechnung um den Faktor acht. Das Format mit den kleinsten Gewichten ist nicht immer das, das Ihnen das kleinste Modell verschafft.

Die kurze Antwort

- **Die Faustregel:** Die Gewichte schrumpfen exakt im Verhältnis, das der Name angibt — BF16 / FP16 **2 B/param** · FP8 **1 B/param** · 4-bit (AWQ, GPTQ) **0.5 B/param**. Sonst nichts.
- **Was es wert ist:** Qwen 3 32B benötigt [NVIDIA A100 PCIe](https://gpuserver.io/de/gpu/a100-80gb) für **$1,091** pro Monat bei voller Präzision und [NVIDIA L4](https://gpuserver.io/de/gpu/nvidia-l4) für **$125** in 4-Bit. Gleiches Modell, gleicher Kontext.
- **Die Falle:** Der Key/Value-Cache folgt den Gewichten nicht nach unten. Bei 128k Kontext ist ein 4-Bit-Llama 3.3 70B zu **53 %** Cache und nur zu 47 % Gewichte.
- **Wo 4-Bit klar verliert:** Llama 3.1 8B braucht bei 128k **23.0 GB** in 4-Bit gegenüber **18.4 GB** in FP8 — mehr Speicher für schlechtere Qualität

## 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.

**Passt das Modell bereits bei voller Präzision, mit Platz für Ihren Kontext?** Führen Sie es in BF16 aus und hören Sie hier auf zu lesen. Quantisierung ist eine Möglichkeit, eine kleinere Maschine zu kaufen, und Sie haben bereits eine gekauft, die funktioniert. Es gibt keine Belohnung dafür, ein Modell zu komprimieren, das ohnehin passt.

**Ist Ihr Kontext kurz und Ihr Modell groß?** Hier verdient sich 4-Bit seinen Ruf. Die Gewichte dominieren den Speicher, und sie auf ein Viertel zu kürzen kommt nahe daran, die Maschine auf ein Viertel zu kürzen.

**Ist Ihr Kontext lang und Ihr Modell klein?** Verwenden Sie FP8, auf einer Karte, die es unterstützt. FP8 halbiert den Cache ebenso wie die Gewichte, und ab einer bestimmten Länge ist genau diese zweite Halbierung die entscheidende — die Tabelle unten zeigt den genauen Punkt, an dem es 4-Bit überholt.

**Bedienen Sie eine einzelne Person auf einer einzelnen Maschine?** GGUF über Ollama ist mit Abstand am wenigsten Aufwand, und der Durchsatz, auf den Sie verzichten, ist Durchsatz, den ein einzelner Leser ohnehin nie genutzt hätte.

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](https://gpuserver.io/de/guides/vram-sizing), 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.

**Die drei Zahlenformate, und wofür jeder Byte-Wert gilt**

| Format | Byte pro Gewicht | Byte pro Cache-Element | Wofür es gedacht ist |
|---|---|---|---|
| BF16 / FP16 Die Gewichte, wie veröffentlicht | 2 | 2 | Referenzqualität |
| FP8 Vom Serving-Stack selbst erzeugt | 1 | 1 | Nahe am Referenzdesign, Hopper und Blackwell |
| 4-bit (AWQ, GPTQ) Ein im Voraus vorbereiteter Checkpoint | 0.5 | 2 | Kleinste Gewichte, Cache bleibt FP16 |

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.

### AWQ und GPTQ

Zwei Wege zum selben 4-Bit-Ziel. AWQ entscheidet anhand der Aktivierungen, welche Gewichte wichtig sind, und schützt diese; GPTQ komprimiert Schicht für Schicht und korrigiert den Fehler dabei laufend. Beide erzeugen einen Checkpoint, den vLLM und SGLang direkt laden, und bei jedem beliebigen Modell ist der Abstand zwischen ihnen kleiner als der Abstand zwischen jedem der beiden und 16-Bit.

### GGUF

Die llama.cpp-Familie, und das, was Ollama darunter verwendet. Es ist eher ein Container als eine einzelne Methode: Eine Datei enthält die Gewichte in einer von einem Dutzend Präzisionen, und sie lagert Schichten in den System-RAM aus, wenn die Karte zu klein ist. Unschlagbar für einen Nutzer auf einer Maschine, und das schwächste der drei bei echter Nebenläufigkeit.

### FP8

Weniger ein Checkpoint-Format als ein Modus. Geben Sie einem Serving-Stack 16-Bit-Gewichte, wandelt er sie beim Laden in FP8 um, ohne separaten Download und ohne Kalibrierungsdurchlauf. Es ist das einzige der vier, das auch den Cache komprimieren kann, weshalb es unten dort auftaucht, wo man es nicht erwarten würde.

### BF16 und FP16

Die Gewichte, wie die Autoren sie veröffentlicht haben, und die Referenz, an der jede andere Zeile gemessen wird. Zwei Byte pro Parameter, kein Kalibrierungsdatensatz, keine Kernel-Unterstützung zu prüfen, keine Qualitätsdiskussion zu führen. Wenn es passt, ist es die richtige Antwort, und der Rest dieser Seite ist eine Ablenkung.

Jede von ihnen anzufordern ist ein einziges Flag. Das sind dieselben Optionen, die der [vLLM-Guide](https://gpuserver.io/de/guides/serve-llama-70b) ausführlich behandelt; hier geht es nur darum, wie klein der Unterschied zwischen ihnen ist.

Derselbe Server, auf vier Arten

```
# 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](https://gpuserver.io/de/configure) anbietet — Gewichte gegen Cache.

**Gewichte und Cache eines 4-Bit-70B-Modells, nach Kontextlänge**

| Kontext | Gewichte | KV-Cache | Cache-Anteil |
|---|---|---|---|
| 4k Token | 35.0 GB | 1.3 GB | 3 % |
| 8k Token | 35.0 GB | 2.5 GB | 7 % |
| 32k Token | 35.0 GB | 10.0 GB | 22 % |
| 128k Token | 35.0 GB | 40.0 GB | 53 % |

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.

**Bei 128k ist ein 4-Bit-Llama 3.3 70B zu 53 % Cache.** Sie haben die Gewichte auf ein Viertel ihrer Größe quantisiert, und die benötigte Maschine hat sich kaum verändert, weil Sie den Teil komprimiert haben, der ohnehin nicht mehr das Problem war. Wer ein Long-Context-Deployment allein anhand der Gewichtsgröße bemisst, bestellt um mehr als die Hälfte zu klein.

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.

**Gesamtspeicher in FP8 gegen 4-Bit, nach Modell und Kontextlänge**

| Modell | 4k | 8k | 32k | 128k |
|---|---|---|---|---|
| Llama 3.1 8B 8 B Parameter · 32 Schichten · 8 KV-Heads | 5.24-Bit, um 4.3 GB | 5.84-Bit, um 4.0 GB | 9.24-Bit, um 2.3 GB | 23.0FP8 gewinnt — 18.4 GB |
| Qwen 3 32B 32 B Parameter · 64 Schichten · 8 KV-Heads | 19.54-Bit, um 17.8 GB | 20.74-Bit, um 17.2 GB | 27.64-Bit, um 13.8 GB | 55.2ein Gleichstand |
| Llama 3.3 70B 70 B Parameter · 80 Schichten · 8 KV-Heads | 41.74-Bit, um 39.5 GB | 43.14-Bit, um 38.8 GB | 51.74-Bit, um 34.5 GB | 86.34-Bit, um 17.2 GB |

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.

**Karten im Katalog nach Generation, und ihre FP8-Unterstützung**

| Generierung | Karten, die wir vermieten | FP8 |
|---|---|---|
| Ampere | NVIDIA RTX A6000 48GB, NVIDIA A100 PCIe 40GB, NVIDIA A100 PCIe 80GB, NVIDIA A100 SXM4 80GB | Keine in Hardware — auf 16-Bit ausgepackt |
| Ada Lovelace | NVIDIA L4 24GB, NVIDIA RTX 4090 24GB, NVIDIA L40S 48GB | In den Tensor-Cores — Gewichte und Cache |
| Hopper | NVIDIA H100 PCIe 80GB, NVIDIA H100 SXM5 80GB, NVIDIA H200 SXM5 141GB | In den Tensor-Cores — Gewichte und Cache |
| Blackwell | NVIDIA RTX 5090 32GB, NVIDIA B200 SXM6 180GB | In den Tensor-Cores — Gewichte und Cache |

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.

**Auf einer Ampere-Karte ist FP8 nur eine Ersparnis beim Download, mehr nicht.** Die NVIDIA RTX A6000, NVIDIA A100 PCIe und NVIDIA A100 SXM4 haben keinen FP8-Pfad in den Tensor-Cores. Wenn Ihr Plan war, den Cache auf einer von ihnen zu halbieren, wird das nicht passieren — und die Speicherwerte in der FP8-Spalte oben sind auf dieser Hardware nicht erreichbar. Wählen Sie Karte und Format zusammen, in dieser Reihenfolge.

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](https://gpuserver.io/de/configure) 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](https://gpuserver.io/de/guides/api-vs-self-hosting) 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.

**Einzel-Stream-Generierungsrate für ein 8B-Modell nach Karte und Format**

| Karte | Bandbreite | BF16 / FP16 | FP8 | 4-bit (AWQ, GPTQ) |
|---|---|---|---|---|
| NVIDIA L4 24 GB · $125 pro Monat | 300 GB/s | ~ 8 Tok/s | ~ 17 Tok/s | ~ 34 Tok/s |
| NVIDIA RTX A6000 48 GB · $286 pro Monat | 768 GB/s | ~ 22 Tok/s | ~ 43 Tok/s | ~ 86 Tok/s |
| NVIDIA L40S 48 GB · $714 pro Monat | 864 GB/s | ~ 24 Tok/s | ~ 49 Tok/s | ~ 97 Tok/s |
| NVIDIA RTX 4090 24 GB · $193 pro Monat | 1008 GB/s | ~ 28 Tok/s | ~ 57 Tok/s | ~ 113 Tok/s |
| NVIDIA A100 PCIe 40 GB · $392 pro Monat | 1555 GB/s | ~ 44 Tok/s | ~ 87 Tok/s | ~ 175 Tok/s |
| NVIDIA RTX 5090 32 GB · $335 pro Monat | 1792 GB/s | ~ 50 Tok/s | ~ 101 Tok/s | ~ 202 Tok/s |
| NVIDIA A100 PCIe 80 GB · $1,091 pro Monat | 1935 GB/s | ~ 54 Tok/s | ~ 109 Tok/s | ~ 218 Tok/s |
| NVIDIA H100 PCIe 80 GB · $1,469 pro Monat | 2000 GB/s | ~ 56 Tok/s | ~ 113 Tok/s | ~ 225 Tok/s |

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.

**FP8 liegt nah genug dran, um unumstritten zu sein.** Es ist immer noch ein Gleitkommaformat — ein Exponent und eine Mantisse, mit jeweils weniger Bits — und nicht das Integer-Raster, auf das ein 4-Bit-Checkpoint mit Skalierungsfaktoren pro Gruppe abgebildet werden muss. Deshalb verschlechtert es sich so sanft, und deshalb braucht es keinen Kalibrierungsdurchlauf. Die meisten Teams übernehmen es ohne eigene Evaluation, und die meisten kommen damit durch.

**4-Bit ist ein echter Kompromiss, und er trifft ungleichmäßig.** Der durchschnittliche Benchmark-Wert bewegt sich meist nur wenig. Was sich bewegt, ist der Rand der Verteilung: lange Argumentationsketten, exakte Arithmetik, seltene Sprachen, strikte Ausgabeformate. Ein Modell, das in einer Multiple-Choice-Suite noch gut abschneidet, kann anfangen, JSON fehlerhaft zu schließen.

**Größere Modelle verkraften es besser.** 4-Bit auf einem 70B ist ein routinemäßiges Deployment. 4-Bit auf einem 8B, dessen Parameter jeweils mehr tragen, ist der Punkt, an dem sich der Qualitätsverlust bemerkbar macht — und, laut Tabelle oben, wo es am wenigsten bringt.

**Die Kalibrierungsdaten zählen mehr als die Buchstaben.** AWQ und GPTQ komprimieren beide gegen ein Beispielkorpus. Ein Checkpoint, der auf englischer Prosa kalibriert und für Code verwendet wird, fällt schlechter aus, als es die Methode verdient, und keine Benchmark-Tabelle wird Ihnen das verraten.

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.

**Testen Sie in der Reihenfolge, die am wenigsten kostet.** Beginnen Sie mit BF16, wenn es überhaupt passt, denn es ist die Referenz, die Ihre anderen Läufe brauchen. Gehen Sie als Nächstes zu FP8 — derselbe Checkpoint, ein Flag, nichts herunterzuladen. Greifen Sie erst dann zu einem 4-Bit-Checkpoint, wenn die beiden oben am Speicher gescheitert sind, und vergleichen Sie ihn dann mit dem FP8-Lauf statt mit Ihren Erwartungen.

## Welche Maschine das bedeutet

Der Grund, warum das alles zählt, ist die Rechnung. Unten steht die günstigste Maschine in [unserem Katalog](https://gpuserver.io/de/#catalog), 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](https://gpuserver.io/de/guides/nvlink-vs-pcie) ins Spiel, und das ist ein anderer Guide.

**Günstigste Maschine, die jedes Modell ungeteilt hält, nach Format**

| Modell | BF16 / FP16 | FP8 | 4-bit (AWQ, GPTQ) |
|---|---|---|---|
| Llama 3.1 8B | [NVIDIA L4](https://gpuserver.io/de/gpu/nvidia-l4) $125 pro Monat · benötigt 19.5 GB | [NVIDIA L4](https://gpuserver.io/de/gpu/nvidia-l4) $125 pro Monat · benötigt 9.8 GB | [NVIDIA L4](https://gpuserver.io/de/gpu/nvidia-l4) $125 pro Monat · benötigt 5.8 GB |
| Qwen 3 32B | [NVIDIA A100 PCIe](https://gpuserver.io/de/gpu/a100-80gb) $1,091 pro Monat · benötigt 75.9 GB | [NVIDIA RTX A6000](https://gpuserver.io/de/gpu/rtx-a6000) $286 pro Monat · benötigt 37.9 GB | [NVIDIA L4](https://gpuserver.io/de/gpu/nvidia-l4) $125 pro Monat · benötigt 20.7 GB |
| Llama 3.3 70B | [4 × NVIDIA B200 SXM6](https://gpuserver.io/de/gpu/b200) $11,790 pro Monat · benötigt 163.9 GB | [4 × NVIDIA H200 SXM5](https://gpuserver.io/de/gpu/h200) $8,405 pro Monat · benötigt 81.9 GB | [NVIDIA RTX A6000](https://gpuserver.io/de/gpu/rtx-a6000) $286 pro Monat · benötigt 43.1 GB |

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.

**Lesen Sie die mittlere Zeile durch: $1,091 gegen $125, etwa 9×.** Derselbe Qwen 3 32B, derselbe 8k-Kontext, dieselbe einzelne Karte und derselbe Root-Zugriff — und ein Zahlenformat als einziger Unterschied. Das ist das ganze wirtschaftliche Argument für Quantisierung, und deshalb lohnt sich auch ein Abend des Messens mehr als ein Nachmittag des Lesens.

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](https://gpuserver.io/de/configure) 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](https://gpuserver.io/de/guides/api-vs-self-hosting) gesondert berechnet, und Quantisierung verschiebt ihn deutlich zugunsten der Hardware.

## Prüfen Sie Format und Maschine gemeinsam.

Der Konfigurator zeigt, was Ihr Modell bei jeder Präzision braucht und welche Knoten es auf einer einzelnen Karte halten, bevor Sie irgendetwas bezahlen.

[Konfigurator öffnen](https://gpuserver.io/de/configure) [Guides lesen](https://gpuserver.io/de/guides)

## Weitere Guides

- [Dimensionierung · 10 Min. Ein Mixture-of-Experts-Modell betreiben Gesamtparameter entscheiden über die Maschine, aktive Parameter über die Geschwindigkeit: der VRAM-Bedarf von DeepSeek V3 und Qwen 3 235B, und welcher Knoten passt. Guide lesen](https://gpuserver.io/de/guides/mixture-of-experts)
- [Kosten · 6 Min. Wann Monatsmiete die Stundenmiete schlägt Der Break-even anhand realer Zahlen, die drei Kosten, die ein Stundenpreis bis zur Rechnung verbirgt, und die Leerlauf-Falle, die eine Schätzung verdreifacht. Guide lesen](https://gpuserver.io/de/guides/monthly-vs-hourly)
- [Kosten · 9 Min. Self-Hosting gegen eine API mit Preis pro Token Der Break-even zwischen einer API mit Preis pro Token und einer gemieteten GPU, mit unseren eigenen Zahlen — und vier Dinge, die dabei fehlen. Guide lesen](https://gpuserver.io/de/guides/api-vs-self-hosting)

---

Quelle: https://gpuserver.io/de/guides/awq-vs-gptq-vs-fp8/. Diese Datei wird aus denselben Daten wie die Website erzeugt; weicht eine Zahl hier von einer Seite ab, ist die Seite maßgeblich und diese Datei veraltet — die kanonische Quelle ist https://gpuserver.io/.