--- title: "Quantisierung erklärt: Wie man ein 70B-Modell auf normaler Hardware betreibt" description: "Ein 70B-Modell braucht in voller Präzision 140 GB VRAM — bis man es quantisiert. Ein praxisnaher Leitfaden zu GGUF, K-Quants, Q4 vs. Q8, dem tatsächlichen Qualitätsverlust und dem genauen VRAM-Bedarf." author: Aleksei Aleinikov date: 2026-08-05 lang: de tags: [quantisierung, modell quantisierung, lokales llm, gguf, llm lokal betreiben, llm inferenz, q4_k_m, vram bedarf] canonical: https://www.alekseialeinikov.com/de/blog/topics/ai/quantisierung-erklaert-70b-modell-auf-normaler-hardware-2026 source: alekseialeinikov.com --- # Quantisierung erklärt: Wie man ein 70B-Modell auf normaler Hardware betreibt Das ist die Zahl, die die meisten davon abhält, ein ernsthaftes Modell auf der eigenen Maschine zu betreiben: Ein Modell mit 70 Milliarden Parametern braucht in der veröffentlichten Präzision rund **140 GB VRAM**. Das ist keine Grafikkarte — das ist ein Rack. Und trotzdem betreiben Leute 70B-Modelle auf zwei Gaming-GPUs oder auf einem MacBook. Möglich macht das die **Quantisierung**, eine der wirkungsvollsten Ideen der angewandten KI: eine Technik, die den Speicherbedarf viertelt und dafür einen Bruchteil eines Prozents an Qualität kostet. Dieser Leitfaden behandelt die tatsächliche Rechnung, die relevanten Formate, was wirklich verloren geht und wie du bestimmst, was auf deiner vorhandenen Hardware läuft. ![Quantisierung komprimiert Modellgewichte von 16 Bit auf 4 und macht aus einem 140-GB-Modell ein 42-GB-Modell.](https://www.alekseialeinikov.com/blog/quantization-2026.webp) ## Was Quantisierung tatsächlich macht Ein Sprachmodell ist ein sehr großer Haufen Zahlen. Jeder Parameter — jedes Gewicht — wird normalerweise als **16-Bit-Gleitkommawert** gespeichert: zwei Bytes, die einen riesigen Wertebereich fein abgestuft abbilden können. Quantisierung stellt eine unbequeme Frage: *Brauchen wir diese Präzision überhaupt?* Statt jedes Gewicht als einen von ~65.000 möglichen 16-Bit-Werten zu speichern, bildet man es auf eine viel kleinere Menge ab — 256 Stufen bei 8 Bit, 16 Stufen bei 4 Bit. Pro Gruppe von Gewichten behält man einen Skalierungsfaktor, sodass sich die Werte näherungsweise rekonstruieren lassen, und akzeptiert, dass „näherungsweise" reicht. Es ist verlustbehaftete Kompression, und die nächstliegende Analogie ist **JPEG**. Ein JPEG wirft Details weg, die das Auge nicht priorisiert, und landet bei einem Bruchteil der Originalgröße. Quantisierung wirft numerische Präzision weg, auf die das Modell nicht stark angewiesen ist. In beiden Fällen dieselbe Überraschung: Man kann erstaunlich viel wegwerfen, bevor es jemand merkt. ## Die VRAM-Rechnung Das ist die eine Rechnung, die man sich merken sollte: ``` Speicher (Bytes) = Parameter × Bits ÷ 8 ``` Angewandt auf ein 70B-Modell: | Präzision | Bits pro Gewicht | Größe der Gewichte | Passt auf | |---|---|---|---| | **FP16** (Original) | 16 | ~140 GB | Rechenzentrums-GPUs | | **Q8_0** | ~8,5 | ~75 GB | 4× 24-GB-GPUs | | **Q6_K** | ~6,6 | ~58 GB | 3× 24-GB-GPUs | | **Q5_K_M** | ~5,7 | ~50 GB | 64 GB Apple Silicon | | **Q4_K_M** | ~4,8 | **~42 GB** | **2× 24-GB-GPUs** | | **Q3_K_M** | ~3,9 | ~34 GB | 48 GB, knapp | | **Q2_K** | ~3,0 | ~26 GB | 32 GB, schlechte Qualität | Der eine Schritt von FP16 zu Q4_K_M ist die ganze Geschichte: **Aus 140 GB werden 42 GB.** Ein Modell, das Enterprise-Hardware verlangte, läuft nun auf zwei gebrauchten RTX 3090 oder einem Mac Studio. Dieselbe Rechnung gilt nach unten. Ein 8B-Modell braucht ~16 GB bei FP16 und **~4,9 GB bei Q4_K_M** — bequem auf jeder 8-GB-Karte. Deshalb fühlt sich der lokale Betrieb kleiner Modelle fast kostenlos an. > **Beachte, dass die Bits pro Gewicht keine runden Zahlen sind.** Moderne Quantisierung arbeitet mit *gemischter Präzision*: Attention-Layer und andere empfindliche Tensoren behalten mehr Bits, während die großen Feed-Forward-Gewichte stärker komprimiert werden. Genau dafür steht das `_K` in `Q4_K_M` — ein K-Quant, der Präzision dort vergibt, wo sie zählt. ## Die relevanten Formate Vier Familien dominieren, und die richtige Familie zu wählen ist wichtiger als die exakte Bitzahl. **GGUF** — das Format von `llama.cpp` und damit von **Ollama** und **LM Studio**. Eine in sich geschlossene Datei mit Gewichten und Metadaten. Seine Stärke ist Flexibilität: Es kann ein Modell zwischen GPU und CPU-RAM aufteilen, sodass ein Modell, das nicht ganz in den VRAM passt, trotzdem läuft — nur langsamer. Auf Apple Silicon ist es ebenfalls die beste Wahl, weil Unified Memory die Grenze zwischen CPU und GPU ohnehin auflöst. **GPTQ** — ein GPU-orientiertes Verfahren, das anhand eines Kalibrierungsdatensatzes entscheidet, wie jedes Gewicht gerundet wird, und den Fehler Schicht für Schicht minimiert. Schnell, wenn das Modell vollständig in den VRAM passt. **AWQ** (Activation-aware Weight Quantization) — dieselbe Idee, klügere Auswahl: Es identifiziert den kleinen Prozentsatz an Gewichten, der die Aktivierungen am stärksten beeinflusst, und schützt ihn. Oft bessere Qualität als GPTQ bei gleicher Bitbreite und weit verbreitet mit **vLLM** in Produktion. **bitsandbytes** — die On-the-fly-Variante im Hugging-Face-Ökosystem (`load_in_4bit`, NF4). Weniger auf reine Inferenzgeschwindigkeit optimiert, dafür die Grundlage für **QLoRA**-Finetuning: Adapter auf einem 4-Bit-Basismodell trainieren. Die Entscheidung ist einfacher, als die Liste vermuten lässt: - Betrieb auf Desktop, Laptop oder Mac → **GGUF** - Serving auf GPUs in Produktion → **AWQ** (oder GPTQ) - Finetuning mit kleinem Budget → **bitsandbytes / QLoRA** ![GGUF verteilt auf CPU und GPU; AWQ und GPTQ sind GPU-orientiert; bitsandbytes ermöglicht QLoRA-Finetuning.](https://www.alekseialeinikov.com/blog/quantization-formats-2026.webp) ## Was tatsächlich verloren geht Das Standardmaß ist die **Perplexität** — grob gesagt, wie überrascht das Modell von echtem Text ist. Niedriger ist besser, und der Vergleich zwischen quantisiertem Modell und Original zeigt, was die Kompression gekostet hat. Entscheidend ist die Form dieser Kurve: - **Q8** — praktisch identisch mit dem Original. Was man nicht messen kann, ist nicht da. - **Q6** — minimal hinter Q8. Exzellent, wenn der Speicher reicht. - **Q5** — sehr gut; sinnvolle Wahl, wenn Q4 zu aggressiv wirkt. - **Q4** — kleiner, aber realer Verlust. **Das ist der Sweet Spot** und die Standardempfehlung. - **Q3** — merklich schwächer. Reasoning und Code leiden. - **Q2** — bei schwierigen Aufgaben oft inkohärent. Meist eine Milchmädchenrechnung. Zwei Dinge daran überraschen regelmäßig. **Erstens ist die Kurve nicht linear.** Der Weg 16 → 8 → 4 Bit kostet pro Schritt fast nichts. Der Weg 4 → 3 → 2 kostet viel und spart weniger als erhofft, weil Q2_K durch die gemischte Präzision real bei rund 3 Bit pro Gewicht liegt, nicht bei 2. **Zweitens verteilt sich der Schaden ungleich.** Quantisierung schadet **mehrstufigem Reasoning, dem Erinnern in langen Kontexten und der Codegenerierung** weit mehr als lockerer Konversation. Ein stark quantisiertes Modell kann einen angenehmen Chat führen und dann an der eigentlichen Arbeit scheitern. Teste immer an deiner Aufgabe, nicht nach Gefühl. ![Qualität gegen Speicher über die Quantisierungsstufen: Von 16 auf 4 Bit bewegt sich die Kurve kaum, unter Q4 fällt sie steil ab.](https://www.alekseialeinikov.com/blog/quantization-levels-2026.webp) ## Die wichtigste Regel Wenn du dir eine praktische Heuristik aus diesem Artikel merkst: > **Bei festem Speicherbudget schlägt ein größeres, stärker quantisiertes Modell ein kleineres, leicht quantisiertes.** Ein 70B mit Q4 (~42 GB) ist generell besser als ein 13B mit Q8 (~14 GB) — und auch bei ähnlichem Speicherbedarf gewinnt die Parameterzahl. Größe kauft Wissen und Reasoning-Tiefe, die zusätzliche numerische Präzision schlicht nicht rekonstruieren kann. Das gilt, bis die Quantisierung extrem wird. Unter rund 3 Bit überwiegt der Schaden den Nutzen zusätzlicher Parameter, und du fährst mit einem kleineren Modell bei Q4 besser. Die Auswahlregel lautet also: **Nimm das größte Modell, das mit Q4 passt** — nicht das kleinste, das mit Q8 passt. ## Der KV-Cache verdirbt dir den Tag Hier der Fehler, den fast alle machen: Man prüft, ob ein 42-GB-Modell in 48 GB VRAM passt, lädt es, schickt einen langen Prompt — und sieht es abstürzen. Die Gewichte sind nicht das Einzige im Speicher. Während der Generierung cached das Modell Keys und Values für jedes bisher verarbeitete Token — den **KV-Cache** — und der wächst linear mit der Kontextlänge. Bei einem großen Modell und langem Kontext ist das kein Rundungsfehler, sondern können **viele Gigabyte** sein. Kalkuliere so: ``` Gesamt = Gewichte + KV-Cache + ~1–2 GB Overhead ``` Praktische Abkürzung: **Dateigröße nehmen und 20–25 % aufschlagen.** Passt das nicht bequem, geh eine Quantisierungsstufe runter oder verkürze das Kontextfenster. Zwei Stellschrauben helfen bei knappem Speicher: die konfigurierte Kontextlänge reduzieren oder die **KV-Cache-Quantisierung** aktivieren (den Cache selbst mit 8 Bit speichern), was die meisten modernen Runtimes inzwischen unterstützen. ![Der Gesamtspeicher besteht aus Gewichten, KV-Cache und Overhead — der KV-Cache wächst mit der Kontextlänge.](https://www.alekseialeinikov.com/blog/quantization-vram-2026.webp) ## Was auf deiner Hardware läuft Grobe Orientierung, ausgehend von Q4_K_M und moderatem Kontext: | Deine Hardware | Realistische Modellgröße | |---|---| | 8 GB VRAM | 7–8B bequem | | 12 GB VRAM | 8B locker, 13B knapp | | 16 GB VRAM | 13–14B bequem | | 24 GB VRAM (3090/4090) | 32B bequem | | 2× 24 GB | **70B** | | Mac, 32 GB Unified | bis ~32B | | Mac, 64 GB Unified | **70B** | | Mac, 128 GB Unified | 70B mit Q6 oder größere Modelle | Apple Silicon schlägt hier über seiner Gewichtsklasse. Unified Memory bedeutet, dass die GPU den gesamten Systemspeicher adressieren kann — ein Mac mit 64 GB betreibt Modelle, für die es sonst zwei dedizierte GPUs bräuchte. Langsamer als ein vergleichbares NVIDIA-Setup, aber mit deutlich weniger Aufwand. ## Und jetzt betreiben Der schnellste Weg von null zum laufenden Modell ist Ollama, das Download und Auswahl der Quantisierung übernimmt: ```bash # lädt standardmäßig einen Q4_K_M-Build ollama run llama3.3:70b # oder die Quantisierung explizit angeben ollama run llama3.3:70b-instruct-q5_K_M ``` Wenn du die Datei selbst wählen willst — etwa aus einem Hugging-Face-Repo mit GGUF-Builds — lässt sich der Name sauber entschlüsseln: ``` Model-70B-Instruct-Q4_K_M.gguf │ │ │ │ │ └── M = medium (S = small, L = large) │ └──── K-Quant: gemischte Präzision └─────── ~4 Bit pro Gewicht ``` Für serverseitige Inferenz, bei der das Modell vollständig auf die GPUs passt, übertrifft vLLM mit einem AWQ-Build GGUF beim Durchsatz deutlich — das ist das Setup, sobald du nicht mehr nur dich selbst bedienst. ## Wann man nicht quantisieren sollte Quantisierung ist fast kostenlos, aber nicht ganz: - **Evaluation und Benchmarking.** Wer Modellqualität misst, misst das echte Modell. Quantisierung fügt eine Variable hinzu, die im Experiment nichts zu suchen hat. - **Erzeugen von Trainingsdaten.** Fehler pflanzen sich fort; an der Quelle volle Präzision verwenden. - **Wenn es ohnehin passt.** Bei genug Speicher ersparen FP16 oder Q8 eine ganze Klasse von „Liegt es an der Quantisierung?"-Debugging. - **Sehr kleine Modelle.** Ein 1–3B-Modell verliert proportional mehr durch aggressive Quantisierung — es gibt weniger Redundanz zu opfern. ## Das Fazit Quantisierung hat lokale LLMs von einem Rechenzentrums-Hobby zu etwas gemacht, das auf vorhandener Hardware läuft. Die Mechanik passt in einen Gedanken: **Parameter × Bits ÷ 8**, plus einen KV-Cache, der mit dem Kontext wächst. Standard ist **Q4_K_M**. Auf Desktop oder Mac **GGUF**, beim Serving auf GPUs **AWQ mit vLLM**. Nimm das größte Modell, das mit Q4 passt, statt des kleinsten, das mit Q8 passt. Und kalkuliere 20–25 % über der Dateigröße, damit dich ein langer Prompt nicht umwirft. Das ist im Wesentlichen der Unterschied zwischen „dafür bräuchte ich einen Server" und einem 70B-Modell, das auf deinem Schreibtisch antwortet. Wie weit sich diese Idee in die andere Richtung treiben lässt, habe ich beim [Betrieb von KI-Modellen direkt im Browser mit WebGPU](https://www.alekseialeinikov.com/de/blog/topics/ai/ki-im-browser-webgpu-litert-js-2026) beschrieben — dieselbe Kompressionslogik bei noch engerem Speicherbudget. Und sobald ein lokales Modell echte Arbeit leistet, sind [MCP-Server der Weg, ihm sicher Werkzeuge zu geben](https://www.alekseialeinikov.com/de/blog/topics/ai/mcp-server-erklaert-selbst-bauen-und-sicher-betreiben-2026).