Was ist GGUF? Das LLM-Dateiformat hinter Ollama und llama.cpp im Überblick

GGUF (üblicherweise als ‚GPT-Generated Unified Format‘ ausgeführt) ist ein binäres Dateiformat zur Speicherung großer Sprachmodelle: Es enthält Gewichte, Tokenizer und sämtliche Konfigurationsmetadaten in einer einzigen, eigenständigen Datei. Es ist das native Format von llama.cpp, und es ist das Format, das Ollama, LM Studio, KoboldCpp, Jan und die meisten anderen lokalen LLM-Anwendungen tatsächlich ausführen. Wenn Sie jemals eine Datei mit der Endung .ggufheruntergeladen oder ein Modell mittels ollama runabgerufen haben, haben Sie dieses Format verwendet.

Was eine GGUF-Datei tatsächlich enthält

Eine GGUF-Datei beginnt mit den vier ASCII-Bytes GGUF, gefolgt von einer Versionsnummer, einem Schlüssel-Wert-Metadatenabschnitt und anschließend den Tensoren selbst. Die Metadaten stellen die entscheidende Designentscheidung dar: Sie speichern Architektur, Kontextlänge, Tokenizer-Vokabular, Chat-Vorlage und Quantisierungsdetails als benannte Schlüssel, sodass eine Laufzeitumgebung jede GGUF-Datei laden kann, ohne separate config.json oder Tokenizer-Dateien daneben.

Daraus ergeben sich drei praktische Konsequenzen:

• Eine Datei ist das gesamte Modell. Sie können eine .gguf Datei zwischen Rechnern kopieren, und sie funktioniert sofort. (Sehr große Modelle werden manchmal in nummerierte Teile wie -00001-of-00002.ggufaufgeteilt, doch handelt es sich dabei immer noch um ein logisches Modell.)
• Die Datei ist speicherabbildbar (memory-mappable). Laufzeitumgebungen können die Datei mittels mmap abbilden und Gewichte bei Bedarf seitenweise laden – dadurch erfolgt das Laden schnell, und selbst Modelle, die größer als der verfügbare Arbeitsspeicher sind, können gestartet werden.
• Quantisierung ist fest in das Format integriert. Eine GGUF-Datei speichert bereits komprimierte Gewichte mit 2 bis 8 Bit pro Gewicht; daher kann ein Modell mit acht Milliarden Parametern beispielsweise eine 4,9-GB-Datei statt einer 16-GB-Datei sein.

Warum GGUF GGML ersetzt hat

Vor August 2023 verwendete llama.cpp ein Format namens GGML (benannt nach der zugrundeliegenden Tensor-Bibliothek). GGML funktionierte zwar, wies aber einen strukturellen Nachteil auf: Die Dateistruktur war starr und nicht versioniert. Jedes Mal, wenn llama.cpp eine neue Funktion hinzufügte – etwa neue Architekturen, verbesserte Quantisierungsmethoden oder RoPE-Skalierungsparameter – musste das Format angepasst werden, wodurch sämtliche bestehenden Modell-Dateien auf jedem Datenträger unbrauchbar wurden. Nutzer mussten ihre gesamten Modellsammlungen innerhalb weniger Monate mehrfach neu herunterladen oder konvertieren.

GGUF, das im August 2023 vom llama.cpp-Projekt eingeführt wurde, löste dieses Problem mit zwei Änderungen:

• Versionierung. Die Datei deklariert ihre Formatversion, sodass Leseprogramme genau wissen, wie sie sie parsen müssen.
• Erweiterbare Schlüssel-Wert-Metadaten. Neue Informationen (z. B. ein neues Architekturfeld, eine Chat-Vorlage oder ein zusätzlicher Hyperparameter) werden einfach als neuer Schlüssel hinzugefügt. Alte Dateien ohne diesen Schlüssel lassen sich weiterhin laden; neue Dateien mit dem Schlüssel funktionieren in aktualisierten Laufzeitumgebungen. Es kommt zu keiner rückwirkenden Inkompatibilität.

llama.cpp stellte die Unterstützung für GGML kurz danach ein, und das gesamte Ökosystem folgte diesem Schritt. Heute lebt GGML lediglich noch als Name der zugrundeliegenden Tensor-Bibliothek fort; sollten Sie eine .ggml oder .bin Modell-Datei aus dem Jahr 2023 finden, wird sie von keinem aktuellen Tool geladen – laden Sie stattdessen besser eine GGUF-Version herunter.

Wie man die Quantisierungserweiterungen liest

Jeder GGUF-Dateiname enthält ein Suffix wie Q4_K_M , das angibt, wie stark die Gewichte komprimiert wurden. Das Muster lautet:

• Die Zahl nach Q gibt die ungefähre Bitanzahl pro Gewicht an: Q4 ≈ 4 Bit, Q8 ≈ 8 Bit. Weniger Bits bedeuten eine kleinere Datei und geringere Qualität.
• _K markiert die neueren „k-quant“-Methoden, die zusätzliche Bits auf die Tensoren verwenden, die für die Ausgabequalität am wichtigsten sind. Bei gleicher Dateigröße übertrifft eine K-Quantisierung die ältere Variante.
• _S / _M / _L (small/medium/large) sind Varianten innerhalb einer K-Familie – _M behält einige besonders empfindliche Tensoren mit höherer Genauigkeit als _S.
• _0 (wie in Q8_0, Q4_0) kennzeichnet die ältere, einfachere Block-Quantisierung. Q8_0 wird nach wie vor häufig verwendet, da die einfache Methode bei 8 Bit bereits nahezu verlustfrei ist; Q4_0 ist weitgehend veraltet – bevorzugen Sie stattdessen Q4_K_M.
• IQ -Präfixe (IQ2_M, IQ3_XS…) sind sogenannte „i-quants“, die mithilfe einer Wichtigkeitsmatrix erstellt werden und es ermöglichen, Modelle unter 4 Bit zu komprimieren, wobei die Qualität weniger stark leidet als bei Alternativen.
• F16 / BF16 / F32 bedeutet nicht quantisierte 16- oder 32-Bit-Gewichte – die Referenzqualität bei maximaler Dateigröße.

Im Folgenden sehen Sie die praktischen Kosten der gängigen Optionen am Beispiel von Llama-ähnlichen 8-Milliarden-Parameter-Instruct-Modellen (Größenangaben sind annähernd und variieren je nach Modell leicht):

Zwei nützliche Regeln: Quantisierung beeinträchtigt kleinere Modelle stärker als größere (ein 70B-Modell in Q3 behält seine Qualität deutlich besser bei als ein 8B-Modell in Q3), und unterhalb von Q4 fällt die Qualitätskurve steil ab. Bei Unsicherheit gilt: Q4_K_M ist aus gutem Grund die Community-Standardvorgabe.

Auswahl einer geeigneten Quantisierung für Ihre VRAM

Der gesamte benötigte Arbeitsspeicher beträgt ungefähr Dateigröße + Kontext-Cache + Overhead. Planen Sie zusätzlich zur Dateigröße 1–2 GB für einige tausend Kontext-Token ein; bei sehr langen Kontexten benötigen Sie mehr. Das Modell läuft am schnellsten, wenn der gesamte Speicherbedarf in den GPU-VRAM passt; Tools auf Basis von llama.cpp können den verbleibenden Teil in den System-Arbeitsspeicher auslagern – dies funktioniert zwar noch, wird aber umso langsamer, je mehr Schichten ausgelagert werden müssen.

Für exakte Zahlen zu einem bestimmten Modell und einer bestimmten Kontextlänge berechnet Ihnen der VRAM-Rechner die Werte automatisch, und eine modellspezifische Aufschlüsselung finden Sie in VRAM-Anforderungen für alle wichtigen Sprachmodelle. Wenn Sie Hardware und nicht die Quantisierung auswählen, beginnen Sie am besten mit den besten GPUs für lokale LLMs.

GGUF im Vergleich zu safetensors

Diese beiden Formate koexistieren, weil sie unterschiedliche Laufzeitumgebungen bedienen – nicht etwa, weil eines das andere übertrifft.

Die Entscheidung hängt letztlich davon ab, welche Software Sie verwenden: Desktop-Tools und Ollama benötigen GGUF; GPU-basierte Bereitstellungsstacks sowie alle Anwendungen, die Feinabstimmung erfordern, nutzen safetensors. Modellanbieter veröffentlichen typischerweise zunächst safetensors; die Community konvertiert diese innerhalb weniger Tage in das GGUF-Format.

Woher GGUF-Dateien stammen

Fast alle GGUF-Dateien befinden sich auf Hugging Face. Labs veröffentlichen gelegentlich offizielle GGUF-Versionen, doch die Mehrzahl stammt von Community-Quantisierern – Konten wie bartowski, unsloth, lmstudio-community und ggml-org – die jede neue Veröffentlichung in sämtliche Quantisierungsstufen konvertieren. Ein Repository mit einem Namen wie Meta-Llama-3.1-8B-Instruct-GGUF enthält jeweils eine Datei pro Quantisierungsstufe.

Sie können ein Modell auch selbst mit den Tools von llama.cpp konvertieren: convert_hf_to_gguf.py wandelt ein Hugging-Face-Modell in ein F16-GGUF-Format um, und das Binary llama-quantize (das beim Kompilieren von llama.cpp erstellt wird) komprimiert es in die gewünschte Quantisierungsstufe, z. B. llama-quantize model-f16.gguf model-Q4_K_M.gguf Q4_K_M.

Ein GGUF-Modell in Ollama laden

Ollama kann GGUF-Repositories direkt von Hugging Face herunterladen; die Quantisierungsstufe wird nach dem Doppelpunkt angegeben:

ollama run hf.co/bartowski/Meta-Llama-3.1-8B-Instruct-GGUF:Q4_K_M

Für eine bereits auf der Festplatte vorhandene Datei erstellen Sie eine reine Textdatei mit dem Namen Modelfile mit folgendem Inhalt:

FROM ./my-model.gguf

und registrieren sowie starten Sie sie anschließend wie folgt:

ollama create my-model -f Modelfile
ollama run my-model

Aktuelle Ollama-Versionen lesen die im GGUF-Metadaten eingebettete Chatvorlage automatisch ein; falls ein importiertes Modell fehlerhafte Ausgaben erzeugt, hilft die Lösung meistens, eine explizite TEMPLATE -Zeile in die Modelfile einzufügen. Der umfassende Ollama-Leitfaden behandelt Modelfiles ausführlich.

Ein GGUF-Modell in LM Studio laden

Der übliche Weg ist der integrierte Downloader: Öffnen Sie den Reiter „Discover“, suchen Sie nach einem Modell, und LM Studio listet die verfügbaren GGUF-Quantisierungen auf und kennzeichnet, welche Modelle auf Ihrer Hardware lauffähig sind. Um eine bereits vorhandene Datei zu importieren, verwenden Sie die Befehlszeilenschnittstelle (lms import path/to/model.gguf) oder kopieren Sie die Datei in das Modellverzeichnis von LM Studio – der genaue Standardpfad variiert je nach Version und Betriebssystem, doch der Reiter „My Models“ zeigt ihn an und ermöglicht dessen Änderung. Damit die Dateien erkannt werden, müssen sie in einer Unterverzeichnisstruktur der Form publisher/model-name/ gespeichert sein. Den vollständigen Ablauf finden Sie im umfassenden LM Studio-Leitfaden .

Häufig gestellte Fragen

Ist GGUF ausschließlich CPU-basiert oder nutzt es auch die GPU?

Beides. llama.cpp entstand ursprünglich als CPU-Inferenz-Projekt, doch es entlastet Modellschichten auf die GPU (CUDA, Metal, Vulkan, ROCm) und führt die gesamte Berechnung vollständig auf der GPU durch, sobald das Modell komplett in den VRAM passt. Ollama und LM Studio regeln die Aufteilung zwischen CPU und GPU automatisch; bei direkter Nutzung von llama.cpp steuern Sie diese mittels des Flags -ngl (Anzahl der GPU-Schichten).

Was ist der Unterschied zwischen Q4_K_M und Q4_K_S?

Beide sind ~4-Bit-k-Quantisierungen; der Buchstabe kennzeichnet die Variantengröße. _M „M“ (medium) behält mehr qualitätsempfindliche Tensoren in höherer Genauigkeit als _S „S“ (small), weshalb Q4_K_M geringfügig größer und leistungsfähiger ist. Der Unterschied ist jedoch gering – wählen Sie Q4_K_M, _M es sei denn, die letzten paar hundert Megabyte entscheiden darüber, ob das Modell auf Ihre Hardware passt.

Wie viel Qualität geht durch Quantisierung tatsächlich verloren?

Bei Q8_0 und Q6_K ist der Verlust praktisch vernachlässigbar – in Blindtests fällt es schwer, diese von F16 zu unterscheiden. Q4_K_M weist einen geringfügigen, messbaren Qualitätsverlust auf, den die meisten Nutzer im Chatbetrieb nicht bemerken; bei präzisen Aufgaben wie Codegenerierung oder mathematischen Berechnungen kann er jedoch relevant werden. Unterhalb von Q4 wird der Qualitätsverlust deutlich spürbar, wobei kleinere Modelle stärker betroffen sind als größere.

Kann ich GGUF mit transformers oder vLLM verwenden?

Es existiert zwar eine begrenzte Unterstützung, doch ist dies nicht der native Weg – transformers kann einige GGUF-Dateien beim Laden dequantisieren, und vLLM bietet experimentelle GGUF-Unterstützung, deren Funktionalität je nach Architektur variiert. Falls Sie auf diesen Frameworks aufbauen, verwenden Sie stattdessen safetensors; GGUF ist primär als Format für Laufzeiten der llama.cpp-Familie gedacht.

Warum ist mein Modell in mehrere .gguf-Dateien aufgeteilt?

Sehr große Modelle werden in Teile („shards“) mit Namen wie model-00001-of-00002.ggufaufgeteilt, hauptsächlich um Dateigrößenbeschränkungen auf Hosting-Plattformen einzuhalten. Speichern Sie alle Teile im selben Ordner und verweisen Sie Ihre Laufzeit auf die erste Datei – llama.cpp und darauf basierende Tools laden die restlichen Teile automatisch.

Sobald Sie wissen, welche Quantisierung auf Ihrer Hardware läuft, stellt sich die praktische nächste Frage: Welches Modell soll darin eingesetzt werden? Die Modell-Datenbank Liste enthält Spezifikationen, VRAM-Anforderungen und Preise für 37 aktuelle Modelle; die besten lokalen Modelle für Ollama bietet eine gute Kurzliste, um zu beginnen.