Was bedeutet GGUF?

GGUF ist ein binäres Dateiformat für GGML-basierte Inferenz-Engines. Es speichert Modellgewichte, Tokenizer-Daten und Metadaten in einer einzigen Datei. Wenn Du mit Tools wie Ollama, llama.cpp oder LM Studio arbeitest, lädst Du in der Regel GGUF-Dateien herunter. GGUF wird häufig für quantisierte Modelle genutzt, kann aber auch Gewichte in voller Präzision tragen, etwa in F16, BF16 oder F32. Es hat die älteren Formate GGML, GGMF und GGJT abgelöst und ist heute der De-facto-Standard im llama.cpp-nahen Ökosystem für lokale Inferenz.

GGUF leicht erklärt

Ein Sprachmodell wie Llama 3 oder Mistral entsteht durch Training auf großen Textmengen. Das Ergebnis ist eine Sammlung von Milliarden numerischer Parameter (Modellgewichte), die das gesamte Wissen des Modells kodieren. Diese Gewichte werden standardmäßig in hoher Genauigkeit gespeichert, typischerweise als 16 Bit pro Wert (bf16 oder fp16). Ein Modell mit 7 Milliarden Parametern belegt als Rohgewichte in bf16 rund 14 GB.

14 GB nur für ein mittelgroßes Modell. Größere Modelle mit 70 Milliarden Parametern kommen auf rund 140 GB an reinen Gewichten. Der tatsächliche Speicherbedarf zur Laufzeit liegt noch darüber, weil zusätzlich der KV-Cache (abhängig von Kontextlänge und Batchgröße) sowie Verwaltungsstrukturen im Speicher gehalten werden müssen.

Hier kommt Quantisierung ins Spiel. Sie reduziert die Genauigkeit jedes einzelnen Parameters. Statt 16 Bit pro Wert werden nur noch 4 oder 5 Bit verwendet. Die Idee dahinter: Ein Sprachmodell braucht nicht für jeden Parameter die volle Präzision. Viele Gewichte lassen sich mit deutlich weniger Speicher darstellen, ohne dass die Textqualität spürbar leidet.

GGUF ist das Dateiformat, das diese Modelle speichert und nutzbar macht. Es packt drei Dinge in eine einzige Datei:

• Modellgewichte in der gewählten Quantisierungsstufe (oder in voller Präzision)
• Tokenizer-Daten, die festlegen, wie Text in Zahlen zerlegt und zurückverwandelt wird. Der eingebettete Tokenizer kann in Einzelfällen vom Original des Trainingsprojekts abweichen.
• Metadaten zur Modellarchitektur, Kontextlänge und Herkunft des Modells

Durch diese Bündelung reicht eine einzige Datei aus, um ein Modell lokal auszuführen. Kein Nachladen von Konfigurationen, kein Zusammensuchen einzelner Dateien.

Die konkreten Zahlen verdeutlichen den Effekt der Quantisierung: Ein 7B-Modell in bf16 hat eine Dateigröße von rund 14 GB. Dasselbe Modell als GGUF-Datei in Q4-Quantisierung wiegt nur noch etwa 4 GB. Der tatsächliche Speicherbedarf zur Laufzeit hängt zusätzlich von der eingestellten Kontextlänge und dem genutzten Offload-Modus (GPU, CPU oder gemischt) ab. Mit Quantisierung läuft ein 7B-Modell auf einer normalen Grafikkarte oder sogar auf einem aktuellen Laptop. Genau das macht GGUF so relevant: Es bringt leistungsfähige Sprachmodelle auf Consumer-Hardware.

Wie hängen GGUF und Checkpoint zusammen?

Wenn ein Sprachmodell trainiert wird, speichert der Trainingsprozess regelmäßig den aktuellen Zustand. Solche Trainings-Checkpoints enthalten neben den Modellgewichten auch Optimizer-Zustände, Scheduler-Konfigurationen und weitere Trainingsdaten. Sie dienen dazu, das Training fortsetzen zu können. Für die Konvertierung nach GGUF werden nur die Modellgewichte benötigt, nicht der gesamte Trainings-Checkpoint. Veröffentlichte Modelle auf Hugging Face liegen typischerweise als reine Gewichte im Safetensors- oder PyTorch-Format vor.

Diese Modellgewichte sind das Rohmaterial. GGUF ist das Endprodukt für die lokale Nutzung. Dazwischen liegt ein Konvertierungsprozess mit zwei Schritten:

• Schritt 1: Die Modellgewichte werden eingelesen und die Modellarchitektur analysiert.
• Schritt 2: Die Gewichte werden quantisiert (oder in der Originalpräzision übernommen) und zusammen mit Tokenizer und Metadaten in eine GGUF-Datei geschrieben.

Das Werkzeug dafür ist llama.cpp. Es enthält Konvertierungsskripte, die Safetensors- und PyTorch-Gewichte direkt in GGUF umwandeln. Der Befehl convert_hf_to_gguf.py nimmt ein Hugging-Face-Modell entgegen und erzeugt daraus eine GGUF-Datei in der gewünschten Quantisierungsstufe.

In der Praxis musst Du diese Konvertierung selten selbst durchführen. Auf Plattformen wie Hugging Face stellen Community-Mitglieder bereits fertig quantisierte GGUF-Dateien bereit. Du lädst die passende Variante herunter und kannst sofort loslegen. Wenn Du allerdings ein eigenes Modell trainiert oder feinabgestimmt hast, ist der Weg von den exportierten Gewichten zur GGUF-Datei ein notwendiger Schritt, bevor Du es lokal nutzen kannst.

Wofür braucht Quantisierung das GGUF-Format?

Quantisierung ist ein Verarbeitungsschritt. GGUF ist ein häufig genutztes Zielformat im GGML-Umfeld, aber Quantisierung ist nicht an GGUF gebunden und GGUF ist nicht auf quantisierte Modelle beschränkt. Quantisierung reduziert die Präzision der Modellparameter, und GGUF speichert diese reduzierten Werte in einem Format, das Inferenz-Tools direkt verarbeiten können.

Die verschiedenen Quantisierungsstufen tragen Kürzel, die Dir auf Hugging Face oder in Ollama ständig begegnen. Die Zahlen in den Namen geben die nominale Quantisierungsklasse an. Die effektive Speicherbelegung pro Parameter liegt durch Skalierungsfaktoren und Blockstrukturen etwas über dem Nominalwert:

• Q2_K: Nominell 2-Bit-Klasse. Extrem kompakt, aber spürbar schlechtere Textqualität. Nur sinnvoll, wenn Dein Speicher sehr knapp ist.
• Q4_K_M: Nominell 4-Bit-Klasse. Der meistgenutzte Kompromiss. Gute Qualität bei deutlich reduziertem Speicherbedarf.
• Q5_K_M: Nominell 5-Bit-Klasse. Etwas besser als Q4, braucht entsprechend mehr Speicher.
• Q8_0: 8-Bit-Quantisierung. Nahe an der Originalqualität, aber nur halb so groß wie bf16.

Das "K" in den Bezeichnungen kennzeichnet die K-Quant-Familie: eine Gruppe blockbasierter Quantisierungsschemata in llama.cpp. Die Buchstaben S, M und L stehen für die Größenvarianten Small, Medium und Large. Sie unterscheiden sich in der Anzahl und Verteilung der Quantisierungsblöcke und damit im Verhältnis von Dateigröße zu Qualität.

Der Tradeoff ist klar: Weniger Bits bedeuten kleinere Dateien, schnellere Inferenz und geringeren Speicherbedarf. Gleichzeitig sinkt die Qualität der generierten Texte. Bei Q4_K_M ist der Unterschied zur Vollfassung für die meisten Anwendungen kaum wahrnehmbar. Bei Q2_K wirst Du merken, dass das Modell häufiger Fehler macht oder weniger kohärent antwortet.

Für den Einstieg ist Q4_K_M ein häufig empfohlener Startpunkt. Es bietet ein gutes Verhältnis aus Qualität und Ressourcenverbrauch. Die optimale Wahl hängt aber von Modell, Aufgabe, Kontextlänge und Backend ab. Wenn Du mehr VRAM zur Verfügung hast, greife zu Q5_K_M oder Q8_0.

GGUF und VRAM: Welches Modell passt auf Deine Hardware?

Die wichtigste Frage bei der Modellwahl: Passt es in Deinen Speicher? Die folgenden Dateigrößen zeigen, wie viel Platz die reinen Modellgewichte als Q4_K_M-quantisierte GGUF-Dateien einnehmen:

• 7B-Modell (z.B. Mistral 7B, Llama 3 8B): ca. 4 bis 5 GB Dateigröße
• 13B-Modell (z.B. Llama 2 13B): ca. 8 bis 9 GB Dateigröße
• 34B-Modell (z.B. CodeLlama 34B): ca. 20 GB Dateigröße
• 70B-Modell (z.B. Llama 3 70B): ca. 40 GB Dateigröße

Der tatsächliche VRAM-Bedarf zur Laufzeit liegt über der reinen Dateigröße. Dazu kommen der KV-Cache (wächst mit der Kontextlänge), Compute-Buffer und Overhead des Inferenz-Frameworks. Bei einem 7B-Modell in Q4_K_M mit 4096 Token Kontext kannst Du mit etwa 5 bis 6 GB VRAM rechnen. Bei maximaler Kontextlänge (z.B. 32K Token) steigt der Bedarf deutlich. Außerdem lässt sich das Modell teilweise auf CPU/RAM auslagern (Offloading), was den VRAM-Bedarf senkt, aber die Geschwindigkeit reduziert.

Typische Hardware und ihre Möglichkeiten:

• RTX 3060: 12 GB VRAM. Reicht für 7B-Modelle komfortabel und für 13B knapp.
• RTX 4090: 24 GB VRAM. Damit laufen 13B-Modelle problemlos und 34B-Modelle gerade noch.
• MacBook mit M2/M3: 16 bis 24 GB Unified Memory. Besonders effizient, weil CPU und GPU sich den Speicher teilen.
• MacBook mit M2/M3 Max: 36 bis 128 GB Unified Memory je nach Konfiguration. Hier laufen auch 70B-Modelle.

Drei Erfahrungsregeln helfen Dir bei der Auswahl:

• Erfahrungsregel 1: Dein verfügbarer VRAM sollte mindestens 10 bis 20 Prozent über der Dateigröße des Modells liegen. Der KV-Cache und das Betriebssystem brauchen ebenfalls Speicher.
• Erfahrungsregel 2: Wenn ein Modell nicht komplett in den VRAM passt, kann ein Teil in den Arbeitsspeicher (RAM) ausgelagert werden. Das funktioniert, macht die Inferenz aber deutlich langsamer.
• Erfahrungsregel 3: Nimm lieber ein kleineres Modell in höherer Quantisierung als ein großes in niedriger. Ein 7B-Modell in Q5_K_M liefert für viele Aufgaben bessere Ergebnisse als ein 13B-Modell in Q2_K.

GGUF und Inferenz: Vom Format zur Antwort

Inferenz bezeichnet den Vorgang, bei dem ein trainiertes Modell auf eine Eingabe reagiert und Text erzeugt. Die GGUF-Datei ist dabei der Ausgangspunkt. Der Weg von der Datei zur fertigen Antwort läuft in mehreren Schritten ab.

Zuerst lädt das Inferenz-Tool die GGUF-Datei. Die Modellgewichte werden in den VRAM (bei GPU-Nutzung) oder in den RAM (bei CPU-Nutzung) geschrieben. Da der Tokenizer direkt in der GGUF-Datei enthalten ist, muss nichts separat geladen werden.

Dann gibst Du Deinen Prompt ein. Der Tokenizer zerlegt Deinen Text in Tokens, also numerische Einheiten, die das Modell verarbeiten kann. Aus "Erkläre mir Quantisierung" werden beispielsweise fünf bis sechs Token-IDs.

Das Modell verarbeitet diese Token-IDs durch seine Schichten und berechnet, welches Token als nächstes am wahrscheinlichsten folgt. Dieses Token wird ausgegeben, an die bisherige Sequenz angehängt, und der Prozess wiederholt sich. So entsteht Token für Token die Antwort.

Die gängigen Tools für diesen Prozess sind:

• Ollama: Am einfachsten zu bedienen. Ollama lädt beim Ausführen eines Modells eine passende Modellvariante und startet die Inferenz.
• llama.cpp: Das Fundament, auf dem die meisten anderen Tools aufbauen. Maximale Kontrolle über alle Parameter.
• LM Studio: Grafische Oberfläche für GGUF-Modelle. Du ziehst die Datei hinein und kannst sofort chatten.

Die Geschwindigkeit der Textgenerierung hängt von mehreren Faktoren ab: Quantisierungsstufe, verfügbarer VRAM, Kontextlänge und Hardware. Niedrigere Quantisierung (weniger Bits) bedeutet weniger Rechenaufwand pro Token und damit schnellere Ausgabe. Wenn das gesamte Modell in den VRAM passt, ist die Inferenz am schnellsten. Sobald Teile in den langsameren RAM ausgelagert werden, sinkt die Geschwindigkeit spürbar. Grobe Erfahrungswerte: Auf einer RTX 4090 erzeugt ein 7B-Modell in Q4_K_M in der Größenordnung von 80 bis 120 Token pro Sekunde. Auf einem MacBook M2 mit 16 GB sind es etwa 20 bis 40 Token pro Sekunde. Die tatsächliche Geschwindigkeit hängt stark von Modell, Backend, Kontextlänge, Offload-Modus und Software-Version ab.