LLM Quantization: Speicher sparen, Formate richtig wählen

Die beste Wahl ist die höchste Präzision, die zur Arbeitslast passt und die eigenen Qualitätsprüfungen besteht. Ein kleinerer Download hilft nur, wenn das Modell weiterhin korrekt antwortet und genügend Speicher für den Gesprächsverlauf übrig bleibt.

Die Dokumentation und die Aussagen zur Kompatibilität wurden am 20. Oktober 2026 anhand der aktuellen Projektseiten geprüft. Die Speicherangaben sind Berechnungen auf Basis der dokumentierten Parameterzahl von Qwen2.5-7B-Instruct, keine Messwerte zum GPU-Speicherverbrauch oder Benchmark-Ergebnisse.

Was bedeutet LLM Quantization? Weniger Präzision bei gleichem Modellaufbau

Bei der Quantisierung werden die erlernten Zahlenwerte eines Modells mit weniger Bits gespeichert. Ein großes Sprachmodell, kurz LLM, erzeugt Text mithilfe erlernter numerischer Parameter, der sogenannten Gewichte. Eine geringere Präzision senkt den Aufwand für Speicherung und Datentransport, führt aber zu Näherungsfehlern. Die Quantisierungsübersicht von Hugging Face erläutert diesen Zielkonflikt zwischen Speicherbedarf und Genauigkeit.

Als Vergleich eignet sich ein Bauplan, dessen Maße sehr genau eingetragen sind. Werden die Maße gerundet, lässt sich der Plan kompakter festhalten; einige Abmessungen verändern sich dabei geringfügig. Das Gebäude hat trotzdem dieselben Räume. Genauso macht die übliche Gewichtsquantisierung aus einem großen Modell keines mit weniger Schichten oder weniger erlernten Parametern. Sie verändert, wie genau die Gewichte dargestellt werden.

Der Vergleich hat allerdings Grenzen: Quantisierung ist gezielter als das bloße Streichen von Nachkommastellen. Werte lassen sich gruppieren, mit einem Skalierungsfaktor versehen und auf eine kleinere Menge darstellbarer Werte abbilden. Mithilfe der Skalierung kann die Laufzeitumgebung bei der Berechnung einen Näherungswert wiederherstellen. Wichtige Bestandteile können ihre höhere Präzision behalten. IBMs Erklärung zur Quantisierung behandelt diese Zuordnungen und die dabei entstehenden Fehler.

Vor der Auswahl einer Modelldatei sollten drei Dinge auseinandergehalten werden:

• Gewichte: die erlernten Werte, die mit dem Modell gespeichert werden.
• Aktivierungen: Zwischenwerte, die bei der Verarbeitung der Eingabe entstehen.
• KV-Cache: gespeicherte Attention-Daten zum bereits verarbeiteten Kontext. Mit einem längeren Gespräch belegen sie zusätzlichen Speicher.

Eine reine Gewichtsquantisierung verkleinert die erste Kategorie. Die beiden anderen schrumpfen dadurch nicht automatisch. Deshalb kann ein Modell problemlos laden und bei einer langen Anfrage trotzdem an die Speichergrenze stoßen. Ollamas Dokumentation zu Speicher und Cache behandelt Kontextkapazität und Cache-Präzision getrennt.

Quantisierung nach dem Training oder schon währenddessen?

Wer ein fertiges Modell herunterlädt, beschäftigt sich in der Regel zuerst mit Post-Training Quantization. Bei der Post-Training Quantization, kurz PTQ, wird ein bereits trainierter Checkpoint umgewandelt. Einige Verfahren verwenden Kalibrierungsdaten: repräsentative Eingaben, die dabei helfen, eine geeignete Annäherung an die Gewichte zu wählen. Quantization-Aware Training, kurz QAT, berücksichtigt die Auswirkungen niedriger Präzision schon während des Trainings oder der Feinabstimmung. IBM beschreibt beide Ansätze.

Um einen veröffentlichten quantisierten Checkpoint einzusetzen, muss kein eigenes Modell trainiert werden. Bekannt sein sollten aber das ursprüngliche Modell, das verwendete Quantisierungsverfahren und die Laufzeitumgebung, die den Checkpoint laden kann. Ein Dateiname allein ersetzt diese Informationen kaum.

GGUF, AWQ, GPTQ und FP8: Was passt zu welcher Laufzeitumgebung?

Die Bezeichnungen betreffen unterschiedliche Ebenen des Systems und sind deshalb keine beliebig austauschbaren Alternativen. GGUF ist ein Container. AWQ und GPTQ sind Quantisierungsverfahren. FP8 ist ein Zahlenformat. Ein Checkpoint ist das gespeicherte Modellartefakt: Es enthält die Gewichte und die Informationen, die zum Laden nötig sind.

Hugging Face, Plattform für das Hosting von Modellen und Entwickler von Transformers, dokumentiert sowohl Dateiformate als auch Ladeverfahren. Die Tabelle führt diese Dokumentation mit den Hinweisen der Laufzeitumgebungen zusammen. Sie dient als Orientierung für die Auswahl; sie besagt nicht, dass jede Modellarchitektur auf jedem aufgeführten Weg funktioniert.

Auch die Endung .safetensors beantwortet die Frage nach der Präzision nicht. Sie kennzeichnet ein Speicherformat für Tensoren. Wie diese Tensoren dargestellt werden und welcher Lader vorgesehen ist, steht in der Quantisierungskonfiguration und der Modellkarte des Checkpoints. Die GGUF-Dokumentation von Hugging Face unterscheidet zwischen Container-Metadaten und Tensordaten; der AWQ-Leitfaden zeigt die relevanten Felder unter quantization_config.

Was bedeutet Q4_K_M?

Q4_K_M ist ein Preset mit gemischter Präzision, keine Zusage, dass jeder Parameter exakt vier Bits belegt. Q4 bezeichnet die nominelle Vier-Bit-Familie, K das K-Quant-Blockschema und M das mittlere Preset. Ausgewählte Tensoren können je nach Modellarchitektur und Regeln des Quantisierers eine höhere Präzision verwenden. Die Quantisierungsimplementierung von llama.cpp legt diese Auswahl offen.

Schon ein einfacher Q4_K-Block benötigt Verwaltungsdaten: Die Tabelle der Tensorcodierungen des Projekts nennt 4.5 Bits pro Gewicht, wenn Angaben zu Skalierung und Minimum eingerechnet werden. Das ist ein Wert auf Blockebene, kein Durchschnitt für jedes Q4_K_M-Modell.

Bei einem lokalen Rechner mit knappem Speicher ist Q4_K_M ein sinnvoller Kandidat für einen Test. Passt eine Variante mit höherer Präzision zusammen mit dem vorgesehenen Kontext in den Speicher, sollte sie ebenfalls verglichen werden. Eine kleinere Datei allein ist kein Grund, Abstriche bei der Antwortqualität zu machen.

Speicherbedarf berechnen: das Beispiel Qwen2.5-7B-Instruct

Zuerst zählt die gesamte Parameterzahl; hinzu kommt der Speicher für den laufenden Betrieb. Qwen2.5-7B-Instruct, das hier als Beispiel verwendete, auf Anweisungen abgestimmte Modell von Qwen, hat insgesamt 7.61 Milliarden Parameter. Seine Modellkarte nennt separat 6.53 Milliarden Parameter ohne Embeddings. Wer mit dieser kleineren Zahl rechnet, lässt einen Teil des gespeicherten Modells weg. Qwen-Modellkarte.

Die idealisierte Rechnung lautet:

Gewichtsspeicher in Bytes ≈ Parameterzahl × Bits pro Parameter ÷ 8

Für 16 Bit ergibt sich 7,610,000,000 × 16 ÷ 8 = 15,220,000,000 bytes. Bei den anderen Präzisionsstufen sieht die Rechnung so aus:

Das sind eigene Berechnungen anhand der gerundeten Parameterzahl aus der Modellkarte. Sie setzen voraus, dass jeder Parameter die angegebene Bitbreite nutzt. Für dezimale GB wird die Bytezahl durch 1,000,000,000 geteilt, für GiB durch 1,073,741,824. Die Einheit verändert den angezeigten Zahlenwert, nicht die Speichermenge.

Die Tabelle lässt Skalierungsfaktoren der Quantisierung, Tensoren mit höherer Präzision, Dateimetadaten, Cache, Aktivierungen, temporäre Arbeitspuffer und Speicherreservierungen der Laufzeitumgebung bewusst außen vor. Ein Q4_K_M-Download wird daher nicht exakt der idealisierten Vier-Bit-Zeile entsprechen. Ebenso wenig belegt diese Zeile, dass das Modell auf einer hypothetischen GPU mit 4 GB läuft.

Bei einem lokalen Programmierassistenten reicht ein kurzer Chat deshalb nicht aus, um die Kapazität zu prüfen. Ein aussagekräftiger Test umfasst die vorgesehenen Quelldateien, Anweisungen und Antwortlängen. Bei einem Server kommen gleichzeitige Anfragen hinzu. Ollama dokumentiert ausdrücklich, wie sich parallele Anfragen und die Kontextzuweisung auf den Speicherbedarf auswirken.

Die separate Berechnung des Kontextspeichers erläutert der Leitfaden zum KV-Cache. Gewichtsquantisierung und Cache-Quantisierung sind unterschiedliche Stellschrauben. Auch vLLM dokumentiert die KV-Cache-Quantisierung als eigenständige Funktion.

Das Format richtet sich nach der Laufzeitumgebung

Zuerst wird der Ausführungsweg gewählt, dann die Präzisionsstufe. Kompatibilität ist eine zwingende Voraussetzung. Ist sie gegeben, entscheiden der verfügbare Speicher, die Antwortqualität und die gemessene Latenz bei der vorgesehenen Arbeitslast.

llama.cpp: mit einer kompatiblen GGUF-Datei beginnen

llama.cpp ist eine lokale Inferenz-Engine und der direkte Weg zu GGUF, wenn Modellartefakt und Gerätezuordnung gezielt gesteuert werden sollen. Die Projektdokumentation nennt CPU-Ausführung, Unterstützung für Apple Silicon und gemischte CPU/GPU-Ausführung. Das ist hilfreich, wenn die Modellgewichte nicht vollständig auf eine dedizierte GPU passen. Projektdokumentation von llama.cpp.

Die Grenze dieses Ansatzes: Ein erfolgreich geladenes Modell ist noch kein ausreichend schnelles Modell. Die Aufteilung auf CPU und GPU verändert die Ausführungsbedingungen. Daher müssen der tatsächliche Prompt und die Antwort weiterhin gemessen werden. Die sinnvolle Reihenfolge lautet: zuerst die Modellarchitektur, dann eine kompatible GGUF-Datei, schließlich das Quantisierungs-Preset.

Bei der Auswahl des Basismodells hilft der Leitfaden zu den besten lokalen LLMs. Quantisierung kann ein ungeeignetes Basismodell nicht dazu bringen, eine Aufgabe zu verstehen, mit der es schon bei höherer Präzision schlecht zurechtkommt.

Ollama: die gewünschte quantisierte Variante importieren

Ollama, eine Laufzeitumgebung für lokale Modelle, kann eine vorbereitete GGUF-Datei importieren. Der Import selbst quantisiert sie jedoch nicht. Laut aktueller Importanleitung muss die quantisierte Datei vorher erstellt werden. Das ist entscheidend, wenn erwartet wird, dass ein Importbefehl ein Modell mit höherer Präzision automatisch in Q4_K_M umwandelt. Ollamas Importdokumentation.

Ist Ollama installiert und liegt eine kompatible, bereits quantisierte Datei unter dem Namen model.gguf im aktuellen Verzeichnis, ergibt sich aus der Dokumentation folgender Ablauf:

printf 'FROM ./model.gguf\n' > Modelfile
ollama create quant-check
ollama run quant-check

Mit ollama ps in einem weiteren Terminal lässt sich prüfen, wie das geladene Modell auf CPU und GPU verteilt ist. Der Befehl zeigt, was geladen wurde; er ist kein Qualitätsbenchmark. Ollama-FAQ.

Auch bei Ollama setzt der Speicherbedarf der Arbeitslast die Grenze. Ein bequemer Modellbefehl hebt das Speicherbudget für Kontext und parallele Anfragen nicht auf. Der Vergleich von Ollama und llama.cpp erklärt, welche Kontrolle über Modellartefakt und Laufzeitumgebung jeweils sinnvoll ist.

vLLM: Checkpoint, Kernel und GPU aufeinander abstimmen

vLLM, eine Engine für Inferenz und Modellbereitstellung, benötigt einen quantisierten Checkpoint, der zu einem unterstützten Ausführungsweg passt. Ausgangspunkt ist ein vom Modellherausgeber unterstütztes AWQ-, GPTQ- oder FP8-Artefakt. Danach wird die GPU anhand der Hardwarematrix von vLLM geprüft. Ein Kernel ist die hardwarenahe Implementierung der Rechenoperationen, die ein Format auf der jeweiligen Hardware effizient ausführbar macht.

Für neue AWQ-Quantisierungen verweist die aktuelle Dokumentation auf LLM Compressor. AutoAWQ ist abgekündigt; AWQ als Verfahren und Checkpoint-Familie besteht weiter. Für GPTQ in Transformers ist GPTQModel das gepflegte Backend. Die Kompatibilität kann von den Einstellungen des Checkpoints abhängen. AWQ-Hinweise von vLLM, GPTQ-Hinweise von Hugging Face.

Bei FP8 ist eine weitere Unterscheidung nötig. W8A8 steht für Gewichte und Aktivierungen mit jeweils acht Bit; W8A16 für Acht-Bit-Gewichte und Sechzehn-Bit-Aktivierungen. vLLM dokumentiert natives FP8 W8A8 für NVIDIA Ada, Hopper und Blackwell. Turing und Ampere können dagegen über Marlin einen W8A16-Ausführungsweg nutzen, bei dem nur die Gewichte quantisiert sind. Die Angabe „FP8 unterstützt“ sagt deshalb noch nicht, welcher Rechenweg tatsächlich zum Einsatz kommt. FP8-Dokumentation von vLLM.

GGUF sollte nicht allein deshalb zum Standardartefakt für ein vLLM-Deployment werden, weil es lokal funktioniert hat. Die aktuelle Dokumentation bindet GGUF über vllm-gguf-plugin ein und beschreibt den Weg weiterhin als experimentell und noch wenig optimiert. Zudem sind Inkompatibilitäten bei einzelnen Funktionen möglich. Das ist eine Einschränkung beim Wechsel der Umgebung, kein Beleg für eine grundsätzliche Unterlegenheit von GGUF. GGUF-Dokumentation von vLLM.

Gehostete API: nur die angebotenen Optionen wählen

Bietet eine gehostete API keine Präzisionseinstellung an, gibt es auf Anwenderseite auch keine lokale Quantisierungsentscheidung. Maßgeblich ist die Spezifikation des Endpunkts. Werden benannte Präzisionsvarianten angeboten, muss die gewählte Variante geprüft werden. Andernfalls zählen Ausgabequalität und Latenz des Dienstes, ohne über seine interne Zahlendarstellung zu spekulieren.

Der gleiche Modellname reicht nicht aus, um bei verschiedenen Anbietern auf dieselbe Quantisierung, Laufzeitumgebung oder dieselben Ergebnisse zu schließen. Ein dokumentierter Checkpoint oder eine garantierte Präzision ist nur dann nötig, wenn die Anwendung darauf angewiesen ist. Eigene Gewichte hochzuladen und bereitzustellen ist eine separate Deployment-Entscheidung. Damit stellen sich erneut die Fragen nach Laufzeitumgebung und Hardwarekompatibilität.

Was bringt Quantisierung bei Speicher, Tempo und Qualität?

Kompaktere Zahlendarstellungen sparen Speicher. Geschwindigkeit und Qualität müssen getrennt geprüft werden. Weniger Daten im Speicher können den Aufwand für den Transport der Gewichte reduzieren. Die Laufzeitumgebung muss die Werte vor der Berechnung unter Umständen aber erst entpacken oder umwandeln. Die GPTQ-Dokumentation von Hugging Face erklärt, wie ein Fused Kernel niedrigbitige Gewichte für die Berechnung wiederherstellt, ohne das gesamte Modell im globalen GPU-Speicher zu expandieren.

Darin liegen Chance und Grenze zugleich. Ein unterstützter Kernel kann den Vorteil kompakter Gewichte nutzbar machen. Ein ungeeigneter Ausführungsweg kann ihn wieder aufheben. Gemessen werden sollten die Zeit bis zum ersten Token, die Generierungsgeschwindigkeit und der Durchsatz bei der vorgesehenen Zahl gleichzeitiger Anfragen. Die Dateigröße ist kein Geschwindigkeitsbenchmark.

Auch die Qualität hängt von der konkreten Aufgabe ab. Bei einem Programmierassistenten zählt, ob die vorgeschlagene Änderung die relevanten Tests besteht. Bei der Dokumentenextraktion geht es um die benötigten Felder und eine gültige strukturierte Ausgabe. Bei einem mehrsprachigen Assistenten müssen die tatsächlich angebotenen Sprachen in die Prüfung einfließen. Eine flüssig klingende Antwort belegt noch nicht, dass das Modell die Aufgabe nach der Quantisierung weiterhin zuverlässig bewältigt.

Ein aussagekräftiger Vergleich verwendet denselben ursprünglichen Checkpoint einmal mit höherer Präzision und einmal in der zu prüfenden Quantisierung. Prompts, Chat-Template und Generierungseinstellungen bleiben dabei gleich. Werden gleichzeitig unterschiedliche Modelle verglichen, lässt sich der Einfluss der Quantisierung nicht isolieren.

Wann lohnt sich Quantisierung nicht – und welche Versprechen gehen zu weit?

Höhere Präzision sollte erhalten bleiben, wenn sie bereits in den Speicher passt und die quantisierte Variante keinen messbaren betrieblichen Vorteil bringt. Zusätzliche Kompression schafft ein weiteres Artefakt und ein weiteres Modellverhalten, das geprüft werden muss. Sie sollte ein tatsächlich vorhandenes Problem lösen.

Eine Variante mit niedrigerer Präzision ist ungeeignet, wenn sie wichtige Aufgabentests nicht besteht, ihr Ausführungsweg schlecht unterstützt wird oder die Arbeitslast mit langem Kontext weiterhin den Speicher sprengt. Im letzten Fall sollten Kontextlänge und parallele Anfragen geprüft werden, bevor die Gewichte immer weiter verkleinert werden.

Ebenso wenig ist ein für Inferenz quantisiertes Modell automatisch ein universell nutzbarer Trainings-Checkpoint. Bitsandbytes dokumentiert Training mit niedriger Bitbreite für zusätzliche Parameter, etwa Adaptergewichte. Das ist ein bestimmter Ablauf zur Feinabstimmung. Daraus folgt nicht, dass jede heruntergeladene quantisierte Variante ein gewöhnliches Training sämtlicher Gewichte unterstützt. bitsandbytes-Dokumentation von Hugging Face.

Diese verbreiteten Versprechen greifen zu kurz:

• „Mit vier Bit braucht die gesamte Anwendung nur ein Viertel des Speichers.“ Gemeint ist das ideale Verhältnis der Bitbreite der Gewichte gegenüber sechzehn Bit. Der Speicherbedarf zur Laufzeit umfasst weitere Bestandteile.
• „Acht Bit sind ein einziges Format.“ FP8, INT8 und Q8_0 unterscheiden sich in Darstellung und Ausführungsweg.
• „Weniger Bits sind immer schneller.“ Ob weniger Speicherbedarf zu geringerer Latenz oder höherem Durchsatz führt, entscheiden Checkpoint, Kernel, Hardware und Arbeitslast.
• „Ein größeres quantisiertes Modell schlägt immer ein kleineres mit hoher Präzision.“ Parameterzahl und Bitbreite allein belegen keine Aufgabenqualität. Passen beide Kandidaten in den Speicher, sollten beide geprüft werden.

Für Programmieraufgaben bietet der Leitfaden zu den besten lokalen KI-Modellen fürs Coding eine Vorauswahl. Anschließend sollten die Quantisierungsvarianten des gewählten Checkpoints anhand der tatsächlich vorgesehenen Aufgaben verglichen werden.

LLM-Quantisierung in der Praxis: der nächste Schritt

Der Einstieg gelingt mit einem unterstützten Modellartefakt und einer kleinen, wiederholbaren Prüfung. Das ursprüngliche Modell sollte unverändert bleiben, bis die Auswirkungen der Präzision verstanden sind.

Häufige Fragen

Praktische Anleitungen zum Betrieb und zur Bereitstellung von KI-Systemen gibt es im Newsletter.