Leitfaden zu Quantisierungsformaten für lokale LLMs

In Borges' Parabel über das Kaiserreich und seine Karte zeichnen die Kartografen schließlich eine Karte, die so groß ist wie das Territorium selbst, nur um festzustellen, dass sie zu nichts nütze ist. Ein Sprachmodell mit 16 Bit entspricht dieser Karte: vollkommen getreu, im Maßstab eins zu eins, aber viel zu sperrig für den Schreibtisch. Quantisierung ist die Kunst, den Maßstab zu verkleinern, ohne die entscheidenden Straßen zu verlieren. Im Jahr 2026 gibt es dafür so viele Werkzeuge, dass man ein Glossar braucht, bevor man überhaupt eine Auswahl trifft. Nach dem Leitfaden zu Inferenz-Engines bringt dieser Beitrag Ordnung in die Formate: Was sie sind, was sie an Qualität kosten und für welche Hardware sie sich eignen.

Eine Vorbemerkung wie immer: Dies ist eine Analyse von Papers, Dokumentationen und Repositories, kein Benchmark. Die Zahlen stammen aus den verlinkten Quellen und wurden nicht unabhängig reproduziert. Wo die Quelle ein kommerzielles Interesse hat, weisen wir darauf hin.

Container versus Methoden

Das erste Missverständnis ist lexikalischer Natur. Ein Container legt fest, wie Zahlen auf die Festplatte geschrieben werden, während eine Quantisierungsmethode festlegt, wie sie reduziert werden. Zu den Containern zählen safetensors, GGUF und die alten Pickle-Dateien (.bin, .pt); zu den Methoden gehören GPTQ, AWQ, NF4 sowie die K-Quants und I-Quants von llama.cpp; hinzu kommen hybride Fälle: EXL2 und EXL3 sind sowohl Methode als auch Dateistruktur, die an eine einzelne Bibliothek gebunden sind. Pickle-Dateien können beim Laden Code ausführen: Misstrauen Sie Dateien unbekannter Herkunft. GGUF hingegen umfasst laut Hugging-Face-Dokumentation Standard-Tensoren sowie Metadaten und stammt von Georgi Gerganov, dem Entwickler von llama.cpp.

Die Grundrechnung ist arithmetischer Natur: Die Tabelle, die Hugging Face für ein Llama-2 mit 7 Milliarden Parametern verwendet, zeigt es deutlich: 13 GB im Original, 4,1 GB in Q4KM.

Die zweite Rechnung: der Cache

Die Gewichte sind nur der sichtbare Teil. Wie wir im Artikel über den KV-Cache beschrieben haben, sammelt Llama-3.1-70B bei 16 Bit etwa 0,31 Megabyte Cache pro Token an: Bei 128.000 Tokens sind das rund 40 GB, bei einer Million mehr als 300 GB—weit mehr als die 140 GB der Gewichte selbst. Der Cache ist das Archiv, in dem das Modell Schlüssel und Werte des bereits Gelesenen aufbewahrt. Mit jedem generierten Wort muss dieser Cache vollständig durchlaufen werden: Der Flaschenhals ist die Bandbreite, noch vor dem Speicherplatz.

Die Lösungsansätze teilen sich in zwei Familien. Die erste komprimiert: TurboQuant, OSCAR und EpiCache, die in jenem Artikel untersucht wurden, arbeiten an den Bits pro Wert oder an der Frage, was aufbewahrt wird; bei OSCAR auf Qwen3-8B sinkt der Abstand zu BF16 auf 1,42 Punkte bei einem achtmal kleineren Cache. Die zweite Familie verwaltet, was Thema des Beitrags über PagedAttention und RadixAttention ist. Das Paper zu vLLM maß, dass in früheren Systemen nur 20,4 bis 38,2 Prozent des Cache-Speichers tatsächliche Tokens enthielten. Mit Paginierung geht die Verschwendung nahezu gegen null und der Durchsatz steigt um das Zwei- bis Vierfache. Warum wir hier darüber sprechen? Weil das Komprimieren des Caches ein zweiter Stellknopf ist, der unabhängig von den Gewichten funktioniert: ExLlamaV3 beispielsweise quantisiert den Cache von 2 auf 8 Bit. Wenn ein Format einen langen Kontext auf einer kleinen Grafikkarte verspricht, ist der Erfolg fast immer beiden Mechanismen zu verdanken.

GGUF, der Generalschlüssel

Wenn ein Format das Rennen bei der lokalen Inferenz gewonnen hat, dann ist es GGUF—aus einem wenig spektakulären Grund: Es funktioniert überall. Wie wir beim Überblick über Inferenz-Engines gesehen haben, führt llama.cpp das Format auf CPU, NVIDIA, AMD, Intel und Apple aus. Hugging Face führt LM Studio, Ollama und GPT4All unter den Werkzeugen auf, die es nutzen. Eine einzige Datei enthält sowohl Gewichte als auch Metadaten.

Der Name verrät das Rezept. Laut derselben Tabelle von Hugging Face nutzt Q4K 4,5 Bit pro Gewicht, Q5K 5,5 Bit, Q6K 6,5625 Bit; die I-Quants sinken auf 4,25 (IQ4XS), 2,06 (IQ2XXS) und 1,56 (IQ1S) und stützen sich auf eine Importance Matrix—eine Textstichprobe, die dem Quantisierer anzeigt, welche Gewichte am wichtigsten sind. Die Buchstaben S, M und L stehen für Mischungen, bei denen einige Teile auf höherer Bit-Präzision verbleiben, weshalb eine Q4KM-Datei größer ist als die reine mathematische Berechnung vermuten lässt.

Auf dieser Grundlage begann das Zeitalter der dynamischen Quantisierung. Unsloth, das Lesern aus Unsloth Studio bekannt ist, weist jeder Schicht eine unterschiedliche Bitanzahl zu. In Benchmarks zu Qwen3.5 behauptet Unsloth, dass seine Varianten Q4KXL und IQ3_XXS auf der optimalen Pareto-Grenze zwischen Größe und Treue liegen. Vorsicht ist geboten: Diejenigen, die Quantisierungen messen, produzieren sie oft auch selbst, obwohl sie Rohdaten veröffentlichen. Zudem haben I-Quants ihren Preis: In den Tests verlangsamt sich die Inferenz um 5 bis 10 Prozent.

Wo GGUF an seine Grenzen stößt, ist der Mehrbenutzerbetrieb: Die vLLM-Dokumentation bezeichnet das Format als hochgradig experimentell sowie wenig optimiert und erfordert derzeit ein externes Plugin. Der Vorteil für die heimische Nutzung besteht darin, dass ein Modell, das größer als der Grafikspeicher ist, dennoch ausgeführt werden kann, indem die Arbeit unter Qualitätsverlust bei der Geschwindigkeit zwischen GPU und CPU aufgeteilt wird.

GPTQ und AWQ, die Arbeitstiere

Stellen Sie sich einen Schreiner vor, der hundert Bretter auf Standardstärken zuschneiden muss: GPTQ schneidet sie einzeln zu und korrigiert nachfolgende Schnitte, um den gerade gemachten Fehler auszugleichen. Abseits der Metapher ist es laut Paper eine One-Shot-Methode, die Informationen zweiter Ordnung nutzt, um Rundungen Schicht für Schicht anhand einer kleinen Kalibrierungsstichprobe (128 Abschnitte à 2048 Tokens) zu entscheiden. Bei OPT-175B verändert sich die Perplexity mit 4-Bit-GPTQ von 8,34 auf 8,37, während einfaches Runden sie auf 10,54 treibt; bei 3 Bit bricht einfaches Runden über die 7000er-Marke ein, während GPTQ bei 8,68 hält. Ein Modell mit 175 Milliarden Parametern lässt sich in etwa vier Stunden auf einer einzelnen GPU komprimieren. Die angegebenen Beschleunigungen—das 3,25-Fache auf einer A100 und das 4,5-Fache auf einer A6000 im Vergleich zu FP16—gelten für Einzelanfragen und resultieren aus geringerem Datentransfer im Speicher, nicht aus weniger Rechenoperationen, wie die Autoren selbst unter den Einschränkungen festhalten.

AWQ aus der Gruppe um Song Han am MIT (ausgezeichnet als bestes Paper auf der MLSys 2024) geht von einer Beobachtung aus: Nicht alle Gewichte sind gleich wichtig, und das Schützen von etwa 1 Prozent reduziert den Quantisierungsfehler erheblich. Der Trick liegt in ihrer Identifizierung—indem man die Aktivierungen statt der Gewichte betrachtet—und in ihrer Schutzmethode: Nicht durch höhere Bitraten, sondern durch Skalierung mit einer äquivalenten Transformation, damit das Format einheitlich bleibt. Ohne Backpropagation, so die Autoren, generalisiert die Methode besser, ohne sich an die Kalibrierungsstichprobe überzuanpassen. Ihr TinyChat übertrifft die FP16-Implementierung von Hugging Face um mehr als das Dreifache an Geschwindigkeit.

Wer gewinnt? Die Quellen nennen keinen eindeutigen Sieger: Jedes Paper vergleicht seine Methode mit FP16 oder einfachem Runden, nicht jedoch direkt mit der anderen Methode auf derselben Engine. Sie werden ihnen vor allem in vLLM und SGLang begegnen, wo viele parallele Benutzer bedient werden müssen.

Heikler ist die Werkzeuglandschaft. Ein Issue bei vLLM merkt an, dass AutoGPTQ und AutoAWQ nicht mehr gewartet werden. Die GPTQ- und AWQ-Ladekomponenten bleiben vorerst bestehen, werden jedoch künftig eingestellt, da bereits zu viele quantisierte Modelle im Umlauf sind. Die Dokumentation bezeichnet AutoAWQ als veraltet und verweist auf llm-compressor. GPTQModel gibt an, diese Bibliotheken in Transformers, Optimum und PEFT ersetzt zu haben. Praktischer Rat: Prüfen Sie, mit welchem Werkzeug und wann ein 4-Bit-Modell erstellt wurde, denn ein weit verbreitetes Format ist nicht zwangsläufig aktiv gepflegt.

EXL3, NF4, MLX: die Spezialisten

Wenn Sie eine NVIDIA-Gaming-Grafikkarte besitzen und diese im Einzelbetrieb voll auslasten möchten, werden Sie auf ExLlamaV3 stoßen. Das EXL3-Format basiert auf QTIP, einer Technik der Cornell University. Laut README erfolgt die Konvertierung allein mit dem Originalmodell und den gewünschten Ziel-Bits (auch gebrochenen): Ein 70B-Modell benötigt einige Stunden auf einer RTX 4090, verglichen mit etwa 720 A100-GPU-Stunden (und 850 Dollar), die das README AQLM zuschreibt. Die meistzitierte Zahl ist eine Anekdote: Llama-3.1-70B bleibt bei 1,6 Bit pro Gewicht kohärent und passt mit einer Ausgabeschicht auf 3 Bit sowie einem 4096-Token-Cache in unter 16 GB VRAM. Kohärent bedeutet nicht gemessen: Es handelt sich um keinen formalen Benchmark-Wert. Einschränkungen: CUDA 12.4+ ist erforderlich, und die ROCm-Unterstützung gehört noch zu den offenen Aufgaben; die ursprüngliche Dateistruktur bleibt erhalten, was eine Portierung auf Transformers und vLLM möglich machen würde, worüber das README jedoch in der Zukunftsform spricht.

Einen anderen Zweck erfüllt NF4, der 4-Bit-NormalFloat-Typ in bitsandbytes, der mit QLoRA eingeführt wurde. Das Paper zeigt, wie ein Modell mit 65 Milliarden Parametern auf einer einzelnen 48-GB-GPU feingetunt werden kann, während die Leistung eines 16-Bit-Feintunings erhalten bleibt: Das quantisierte Basismodell bleibt eingefroren, und die Gradienten fließen durch es hindurch zu kleinen trainierbaren Adapter-Schichten. Es ist kein Format zum Herunterladen, sondern wird beim Laden ohne Kalibrierungsphase angewendet. Marktechpost weist darauf hin, dass es keine Inferenzbeschleunigung garantiert. Es ist der Workflow, den Werkzeuge wie Unsloth Studio ohne Terminal anbieten.

Auf dem Mac sieht die Lage anders aus. Laut Hugging-Face-Dokumentation ist MLX das Apple-Framework für Apple Silicon. MLX-LM konvertiert und quantisiert Modelle mit einem einzigen Befehl, während die mlx-community fertige Gewichte veröffentlicht. Die Einschränkung liegt in der Ökosystem-Bindung: Es funktioniert nur dort. Auf dem Mac bleibt GGUF eine starke Alternative.

Was der Verlust von Bits kostet

Anfang der 2000er-Jahre nahm William Basinski seine Disintegration Loops auf, indem er alte Tonbänder abspielte, die mit jedem Durchlauf ein Stück zerfielen: Die Musik entstand aus dem Zerfall. Bei Modellgewichten ist der Verlust nicht poetisch, folgt aber demselben Muster: anfangs gering, dann abrupt.

In der Tabelle von Hugging Face steigt die Perplexity (wie überrascht das Modell bei echtem Text ist) für ein Llama-2-7B im Vergleich zu 16 Bit um 0,03 Prozent bei Q80, um 0,13 Prozent bei Q6K, um 0,39 Prozent bei Q5KM und um 1,68 Prozent bei Q4KM, während die Dateigröße von 13 auf 4,1 GB sinkt. Weiter unten steigen die Kosten rasch an: 6,07 Prozent bei Q3KM und 15,3 Prozent bei Q2_K. Dies betrifft ein Modell aus dem Jahr 2023; neuere Architekturen können anders reagieren.

Perplexity ist jedoch ein grobes Thermometer. In der erwähnten Analyse zeigt Unsloth einen Fall, in dem eine IQ2XXS-Datei unter 11 GB eine IQ3S-Datei in realen Tests (LiveCodeBench und MMLU Pro) schlägt—trotz schlechterer Perplexity- und Divergenzwerte. Unsloth warnt, dass diese Indizes stark vom Kalibrierungstext (oft Wikipedia) abhängen. Obwohl es sich um eine interessierte Quelle handelt, hält die praktische Aussage stand: Das Thermometer ersetzt nicht den Test an der eigenen Aufgabenstellung. Ein direkter, wissenschaftlich strenger Vergleich aller Formate bei identischem Modell, gleicher Hardware und exakt derselben Aufgabe fehlt in der konsultierten Fachliteratur.

FP4, ternäre Modelle und QAT

In Return of the Obra Dinn erschuf Lucas Pope eine dreidimensionale Welt in nur zwei Farben, und das Ergebnis funktioniert, weil jedes Pixel mit Sorgfalt gewählt wurde. Das ist das Bild dieser Entwicklungsgrenze: Unter vier Bit gelangt man nicht durch einfaches Abrunden, sondern durch gezieltes Design von Grund auf.

Die erste Neuerungen sind 4-Bit-Gleitkommazahlen, NVFP4 und MXFP4, die Gewichte in kleine Blöcke mit eigenem Skalierungsfaktor unterteilen. NVIDIA präsentiert NVFP4 als Format für seine Blackwell-GPUs mit etwa 3,5-mal weniger Speicherbedarf als 16 Bit und einer Genauigkeit, die meist innerhalb von 1 Prozent zu FP8 liegt, empfiehlt jedoch eine Evaluierung im konkreten Anwendungsfall (Herstellerangaben). In llama.cpp wurde Anfang April 2026 ein generischer CUDA-Kernel für NVFP4 integriert, und der PR kündigt einen spezifischen Kernel für Blackwell an: Die volle Beschleunigung betrifft somit nur wenige Grafikkarten. In den Tests von Unsloth nutzt MXFP4 zudem 4,25 Bit pro Gewicht gegenüber 4,5 bei Q4_K und schneidet bei vielen Tensoren schlechter ab.

Der zweite Weg ist Quantization-Aware Training (QAT)—das Modell wird in dem Wissen trainiert, dass es quantisiert wird. Unsloth berichtet für Gemma 3 12B in Q4_0 von 67,07 Prozent bei MMLU (5-shot) gegenüber 67,15 Prozent bei der 16-Bit-Version: ein Zehntel Prozentpunkt Unterschied. Das ist der Maßanzug statt der nachträglichen Änderung.

Der dritte, radikale Weg sind ternäre Modelle. Ternary Bonsai 2 27B von PrismML, erschienen am 18. September, nutzt Gewichte, die Werte von minus eins, null oder plus eins annehmen, und belegt 5,93 GB gegenüber 53,80 GB bei 16 Bit. Das Unternehmen gibt an, 98,2 Prozent der Leistung des Ausgangsmodells in zwanzig internen Tests zu erreichen. Bei langen Agentenaufgaben sinkt dieser Wert jedoch auf etwa 75 Prozent (Terminal-Bench 2.1: 52,8 gegenüber 69,7), und zur Ausführung wird der llama.cpp-Fork des Herstellers benötigt, da die offizielle Version diese Dateien ablehnt.

Für die Vorgängerversion veröffentlichte ein unabhängiger Entwickler auf GitHub einen Benchmark-Test auf einer RTX 5060 Ti mit 16 GB gegen eine IQ2XXS-Quantisierung desselben Basismodells. Bei Allgemeinwissen (MMLU-Redux) gab es ein statistisches Unentschieden (0,871 gegenüber 0,860); bei AIME26 mit 60.000 Reasoning-Tokens gewann das ternäre Modell (0,867 gegenüber 0,633). Dieser Abstand entstand jedoch primär durch die Konvergenz: Die IQ2XXS-Variante rechnete länger und stieß häufiger an das Token-Limit, antwortete aber korrekt, wenn sie konvergierte. Daraus folgt die Lerneffekt des Autors: Geben Sie stets das Reasoning-Budget an. Vorbehalte: ein einzelner Autor, kleine Stichproben (30 Aufgaben bei AIME26, wo die Genauigkeitsdifferenz einen p-Wert von 0,072 aufweist), eine laut Autor mit einem KI-Assistenten erstellte Analyse und keine Peer-Review. Für den Mehrbenutzerbetrieb, so der Autor, sei dies derzeit das falsche Werkzeug.

Auswahl nach Hardware

Wenn Sie eine passende Konfiguration auswählen möchten, sollten Sie von der Hardware ausgehen, wie im Leitfaden zu Inferenz-Engines beschrieben. Wenn Sie eine AMD-GPU besitzen, wie die 16-GB-Radeon in unserem Testsystem, ist GGUF der praktikabelste Weg: EXL3 erfordert CUDA, während llama.cpp HIP problemlos unterstützt. Wenn Sie eine NVIDIA-Gaming-Grafikkarte nutzen und das Modell allein ausführen, wählen Sie GGUF aus Praktikabilität oder EXL3, wenn Sie die maximalen Tokens pro Sekunde suchen und ein enges Ökosystem in Kauf nehmen. Wenn Sie viele Benutzer gleichzeitig bedienen, greifen Sie zu GPTQ oder AWQ in vLLM und SGLang oder zu FP8 und FP4 auf neueren Grafikkarten. Auf dem Mac liegt die Wahl zwischen MLX und GGUF, und zum Feintuning eines großen Modells mit wenig Speicher bleibt QLoRA der Standard.

Wie viel Qualität darf man opfern? Eine vorsichtige Faustregel: Starten Sie bei Q4KM und gehen Sie auf Q5KM oder Q6_K hoch, wenn Arbeitsspeicher frei ist. Unter drei Bit sollten Sie nur mit speziell dafür entwickelten Quantisierungen gehen (dynamisch oder ternär) und stets an der eigenen Aufgabe messen—sei es Code, Reasoning oder eine weniger repräsentierte Sprache wie Italienisch. Die konsultierten Quellen messen die Leistung für Italienisch nicht: Es bleibt ein blinder Fleck, und das Urteil liegt bei Ihnen.

Faustregel zur Qualität:

Wer gewinnt bei all dem? Wer 16 GB VRAM und Ambitionen für 27-Milliarden-Parameter-Modelle hat. Wer verliert, ist derjenige, der sich auf eine einzelne Benchmark-Zahl oder ein einzelnes Format verlässt, während Forks die Ausnahmen vervielfachen. Offene Fragen bleiben die Stabilität bei langen Aufgaben, die Reproduzierbarkeit der Herstellerangaben und die Einbindung ternärer Modelle in Standard-Engines. Die perfekte Karte, so erinnerte Borges, nützt niemandem: Es zählt die Karte, die in den Rucksack passt und Sie ans Ziel bringt.

Technischer Hinweis: Die Daten stammen aus verlinkten Papers, offiziellen Dokumentationen und Repositories und wurden nicht unabhängig reproduziert. Die Zahlen der Hugging-Face-Tabelle zu Llama-2-7B stammen aus dem Jahr 2023; die Tests von Unsloth, NVIDIA und PrismML stammen von den Herstellern der Formate; der Benchmark-Test zu Bonsai stammt von einem einzelnen, nicht überprüften unabhängigen Autor.