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.

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:

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

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.

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.

Was auf deiner Hardware läuft

Grobe Orientierung, ausgehend von Q4_K_M und moderatem Kontext:

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:

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