GGUF, safetensors: Verständnis der Formate Modelle

#Warum diese Formate existieren

Ein LLM ist nach dem Training nichts anderes als ein riesiger Sack voller Zahlen: die Gewichte (weights), also die Milliarden von Parametern, die codieren, was das Modell „weiß“. Das Dateiformat ist einfach die Art und Weise, wie diese Zahlen auf dem Datenträger angeordnet sind. Man muss entscheiden, wie sie gespeichert werden, wie sie sich schnell wieder einlesen lassen und welche zusätzlichen Informationen (das Vokabular, die Architektur, die Einstellungen) zusammen mit ihnen gespeichert werden.

Früher wurden diese Gewichte im .bin-Format von PyTorch (Python-Pickle) gespeichert, das zwar praktisch, aber langsam zu laden und vor allem gefährlich ist: Eine Pickle-Datei kann beim Öffnen beliebigen Code ausführen. Zwei Formate haben sich durchgesetzt, um unterschiedliche Probleme zu lösen. safetensors erfüllt die Anforderungen von Forschern und Plattformen: sichere und schnelle Speicherung unter Beibehaltung der ursprünglichen Präzision. GGUF erfüllt die Anforderungen der lokalen Inferenz: eine einzige, kompakte, quantisierte Datei, die direkt auf einer handelsüblichen CPU oder GPU ausgeführt werden kann.

#safetensors: das Hugging-Face-Format

safetensors ist das Standardformat im Hugging-Face-Ökosystem. Es wurde entwickelt, um PyTorch-Pickle zu ersetzen, und sein wichtigstes Argument steckt bereits im Namen: Sicherheit. Die Datei enthält nur Daten (die Gewichtstensoren) und einen kleinen JSON-Header, der ihre Form und ihren Typ beschreibt. Kein ausführbarer Code, also kein Risiko beim Öffnen einer manipulierten Datei. Zusätzlicher Vorteil: Das Laden geht dank Memory-Mapping schneller. Damit lassen sich die Gewichte direkt vom Laufwerk lesen, ohne zunächst alles in den RAM zu kopieren.

Sicher durch Design

Kein ausführbarer Code, anders als bei den älteren .bin/.pt-Dateien im Pickle-Format. Eine safetensors-Datei lässt sich herunterladen, ohne eine Codeausführung befürchten zu müssen.

Volle Präzision

Die Gewichte werden üblicherweise in FP16 oder BF16 (16 Bit), teils sogar in FP32 gespeichert. Das ist die numerische Präzision beim Training, die als Referenz dient.

Für die Weiterverarbeitung gemacht

Dies ist das Ausgangsformat für Fine-Tuning, Modellfusion (Merge), Quantisierung oder Umwandlung in andere Formate.

Häufig in Teile aufgeteilt

Ein großes Modell wird auf mehrere Dateien (Shards) verteilt, zu denen ein JSON-Index gehört, da eine einzelne Datei mit mehreren Dutzend GB kaum handhabbar wäre.

Der Nachteil: Eine safetensors-Datei in FP16 ist groß. Ein 7B-Modell benötigt etwa 14 GB (2 Bytes pro Parameter), ein 70B-Modell rund 140 GB. Für Training und Forschung auf Server-GPUs ist das die richtige Wahl. Für den Betrieb eines Modells auf Ihrem Rechner ist das oft zu umfangreich – deshalb sind Quantisierung und GGUF interessant.

#GGUF: das Format für lokale Inferenz

GGUF (GPT-Generated Unified Format) ist das Format, das aus dem Projekt llama.cpp hervorging, der Inferenz-Engine, die LLMs effizient sowohl auf CPUs als auch auf GPUs ausführt. Es ersetzte 2023 das alte GGML-Format. Sein zentraler Ansatz: alles in einer einzigen Datei bündeln. Die Gewichte, das Tokenizer-Vokabular, die Architekturmetadaten (Anzahl der Schichten, Kontextgröße), das Chat-Template – alles ist zusammengepackt. Sie laden eine Datei herunter, starten sie, und es funktioniert.

Eine einzige, eigenständige Datei

Modellgewichte + Tokenizer + Metadaten in einer einzigen .gguf-Datei. Kein Konfigurationsordner muss zusammengestellt werden, keine Python-Abhängigkeit muss installiert werden.

Quantisiert

Für die Speicherung komprimierter Gewichte (4, 5, 6, 8 Bit) entwickelt. Dadurch werden große Modelle auf handelsüblicher Hardware nutzbar.

CPU + GPU + offload

llama.cpp kann die Schichten zwischen GPU und System-RAM verteilen. So lässt sich ein Modell ausführen, das größer ist als der verfügbare VRAM, auf Kosten von etwas Geschwindigkeit.

Portabel

Die gleiche .gguf-Datei funktioniert unter Windows, macOS (Metal), Linux, mit Ollama, LM Studio, Jan oder direkt mit llama.cpp.

Die Quantisierung ist der Kern des Themas. Dabei wird jedes Gewicht mit weniger Bits gespeichert (z. B. 4 statt 16), was die Größe bei guter Wahl um den Faktor 3 bis 4 reduziert und nur einen minimalen Qualitätsverlust verursacht. Dadurch passt ein 7B-Modell in etwa 5 GB VRAM statt in 14. Die gängigen Stufen, die man findet: Q4_K_M (der beste Kompromiss, standardmäßig empfohlen), Q5_K_M (eine Stufe höher in der Qualität), Q8_0 (nahezu verlustfrei, aber größer) und FP16 (nicht quantisiert, Referenz).

#Warum Ollama und LM Studio GGUF benötigen

Ollama und LM Studio bauen auf llama.cpp (oder einer gleichwertigen Engine) auf, und llama.cpp unterstützt GGUF nativ. Das ist keine willkürliche Entscheidung: Genau das macht diese Tools so einfach. Da GGUF bereits den Tokenizer, die Architektur und die Chat-Vorlage enthält, muss das Tool nichts erraten. Es liest die Datei, reserviert Speicher und antwortet Ihnen. Keine Python-Umgebung, keine aufzulösenden Abhängigkeiten, keine zu schreibende Konfiguration.

Wenn Sie `ollama pull llama3.2` ausführen, lädt Ollama tatsächlich eine GGUF-Datei aus seiner Registry herunter und legt sie in seinem Modellspeicher ab. Sie sehen die Datei nie, aber unter der Haube handelt es sich tatsächlich um GGUF. LM Studio hingegen zeigt Ihnen beim Herunterladen ausdrücklich die verfügbaren GGUF-Dateien und ihre Quantisierungen an.

# Ollama récupère un GGUF depuis sa registry et le sert sur localhost:11434
ollama pull llama3.2
ollama run llama3.2

# Vérifier que le daemon répond
curl http://localhost:11434/api/tags

#Einen Dateinamen richtig lesen

Auf Hugging Face folgen die GGUF-Dateinamen einer lesbaren Konvention, sobald man den Code kennt. Nehmen Sie ein typisches Beispiel: `Qwen2.5-7B-Instruct-Q4_K_M.gguf`. Jeder Teil enthält Informationen.

Qwen2.5

Die Familie und die Version des Modells.

7B

Die Anzahl der Parameter: 7 Milliarden. Das ist der erste Anhaltspunkt für den benötigten VRAM.

Instruct

Die Variante, die darauf trainiert wurde, Anweisungen zu befolgen und Dialoge zu führen (im Gegensatz zu -base: unverarbeitet und nicht auf Chat-Nutzung abgestimmt).

Q4_K_M

Quantisierung: 4 Bit, Variante K_M (medium). Der empfohlene Standard für die Balance zwischen Qualität und Größe.

.gguf

Das Format. Sie wissen, dass es in Ollama, LM Studio oder llama.cpp ohne Umwandlung läuft.

Das Quantisierungssuffix ist der Teil, den zu entschlüsseln am nützlichsten ist. Die Zahl gibt die Anzahl der Bits pro Gewicht an; die Buchstaben K_S / K_M / K_L bezeichnen Varianten (Small, Medium, Large), die empfindliche Schichten unterschiedlich stark schützen. Je höher die Zahl, desto größer die Datei und desto originalgetreuer das darin gespeicherte Modell.

Q4_K_M

~4 Bit, Medium-Variante. Die Standardwahl: in der überwältigenden Mehrheit der Fälle die beste Qualität im Verhältnis zur Größe.

Q5_K_M

~5 Bit. Eine Stufe mehr Qualität, eine etwas größere Datei. Gut geeignet, wenn der VRAM ausreicht.

Q8_0

8 Bit. Kaum vom nicht quantisierten Modell zu unterscheiden, benötigt aber doppelt so viel Speicher wie Q4. Für Puristen oder anspruchsvolle Aufgaben.

Q2_K / Q3_K

2–3 Bit. Sehr kompakt, aber mit deutlich erkennbaren Qualitätseinbußen. Nur für Fälle verwenden, in denen der Speicher wirklich knapp ist.

FP16 / F16

Nicht quantisiert, volle 16-Bit-Präzision. Die Referenz, aber mit hohem Speicherbedarf – in diesem Fall kann man ebenso gut bei safetensors bleiben.

#Welches Format je nach verwendetem Tool herunterladen

Die praktische Frage ist: Welches Tool werde ich verwenden? Der Formattyp ergibt sich aus der Antwort, nicht umgekehrt.

Ollama, LM Studio, Jan, llama.cpp

→ GGUF. Diese Tools sind dafür gemacht. Wählen Sie die Quantisierung entsprechend Ihrem verfügbaren VRAM (standardmäßig Q4_K_M).

vLLM, TGI, Transformers (Python)

→ safetensors. Diese Server-Engines laden das native Hugging-Face-Format, oft in FP16 oder mit ihrer eigenen Quantisierung (AWQ, GPTQ).

Fine-Tuning, Zusammenführen und eigene Quantisierung

→ safetensors. Das ist das Arbeitsformat: Man geht von voller Präzision aus, um das Modell umzuwandeln.

Sie wissen es noch nicht

→ Quantisiertes GGUF, wenn Sie das Modell lokal auf Ihrem Rechner nutzen möchten. Das ist die einfachste und ressourcensparendste Option.

Um die richtige Quantisierung zu wählen, orientieren Sie sich an Ihrem verfügbaren VRAM. Richtwerte für Q4: Ein 3B-Modell passt in ~2 GB, ein 7B-Modell in ~5 GB, ein 14B-Modell in ~9 GB, ein 32B-Modell in ~19 GB und ein 70B-Modell in ~40 GB. Auf einer RTX 3060 mit 12 GB lassen sich Modelle von 7B bis 14B in Q4 problemlos betreiben; eine RTX 4090 mit 24 GB ist für 32B ausgelegt; für 70B sollten Sie eine Karte mit viel VRAM oder einen Mac mit vereinheitlichtem Speicher (M4 Pro 24–48 GB) anstreben.

#safetensors in GGUF umwandeln

Manchmal wird ein Modell nur im safetensors-Format veröffentlicht (häufig am Erscheinungstag), und Sie möchten es in Ollama ausführen. Dann müssen Sie es in GGUF konvertieren und anschließend gegebenenfalls quantisieren. Das maßgebliche Werkzeug ist das von llama.cpp bereitgestellte Skript `convert_hf_to_gguf.py`. Der Vorgang erfolgt in zwei Schritten: zuerst in GGUF mit voller Präzision konvertieren, anschließend mit dem Werkzeug `llama-quantize` quantisieren.

1. 01
   llama.cpp und seine Abhängigkeiten herunterladen

   Klonen Sie das Repository llama.cpp und installieren Sie die Python-Abhängigkeiten des Konvertierungsskripts. Das Repository enthält convert_hf_to_gguf.py.
2. 02
   Modell als safetensors herunterladen

   Laden Sie das vollständige Modellverzeichnis von Hugging Face herunter (Gewichte im .safetensors-Format + config.json + Tokenizer-Dateien). Alles muss vorhanden sein, nicht nur die Gewichte.
3. 03
   In GGUF FP16 umwandeln

   Führen Sie convert_hf_to_gguf.py für das Modellverzeichnis aus. Sie erhalten eine .gguf-Datei mit voller Präzision (16 Bit), die viel Speicherplatz benötigt, aber originalgetreu ist.
4. 04
   In Q4_K_M quantisieren

   Geben Sie den GGUF FP16 an llama-quantize weiter und wählen Sie das gewünschte Niveau (Q4_K_M standardmäßig). Die endgültige Datei ist 3 bis 4 Mal leichter.
5. 05
   In Ollama importieren

   Schreiben Sie eine Modelfile-Datei, die auf die quantisierte .gguf-Datei verweist, und erstellen Sie das Modell mit ollama create. Es lässt sich dann wie jedes andere Ollama-Modell verwenden.

# 1. Cloner llama.cpp et installer les dépendances de conversion
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
pip install -r requirements.txt

# 2. Convertir le dossier safetensors en GGUF pleine précision
python convert_hf_to_gguf.py ./mon-modele-hf --outfile mon-modele-f16.gguf --outtype f16

# 3. Quantifier en Q4_K_M (compromis recommandé)
./llama-quantize mon-modele-f16.gguf mon-modele-Q4_K_M.gguf Q4_K_M

# Créer un Modelfile minimal
printf 'FROM ./mon-modele-Q4_K_M.gguf\n' > Modelfile

# Enregistrer le modèle dans Ollama
ollama create mon-modele -f Modelfile
ollama run mon-modele

#Weitere Formate, denen man begegnet

GGUF und safetensors decken das Wesentliche ab, aber beim Herunterladen begegnen Ihnen auch einige andere Namen. Wer sie kennt, vermeidet unangenehme Überraschungen.

.bin / .pt (pickle)

Das alte PyTorch-Format. Funktioniert, ist aber unsicher (kann Code ausführen). Wird nach und nach durch safetensors ersetzt – vermeiden, wenn eine Alternative verfügbar ist.

GPTQ / AWQ

GPU-seitige Quantisierungen für vLLM und Transformers, gespeichert im safetensors-Format. Schnell auf NVIDIA-GPUs, aber von Ollama/llama.cpp nicht lesbar.

MLX

Apples Format für sein MLX-Framework, optimiert für Apple-Silicon-Chips. Wird von einigen nativen Mac-Apps verwendet und unterscheidet sich von GGUF.

ONNX

Ein Austauschformat für mehrere Frameworks, vor allem für industrielle Bereitstellungen und den Edge-Einsatz. Für die lokale Nutzung von LLMs durch die breite Öffentlichkeit ist es selten.

GGML

Der Vorgänger von GGUF (aus demselben Projekt). Veraltet: Wenn Sie auf .ggml stoßen, suchen Sie die entsprechende .gguf-Version.

#Häufig gestellte Fragen

GGUF oder safetensors – welches Format ist besser?

Keines von beiden ist grundsätzlich besser: Sie dienen unterschiedlichen Zwecken. GGUF zum lokalen Ausführen eines Modells (Ollama, LM Studio), safetensors für das Hugging-Face-Ökosystem, Fine-Tuning und Server-Engines. Welches Format „besser“ ist, hängt von Ihrem Tool ab.

Ist ein GGUF schlechter als ein safetensors?

Ein quantisiertes GGUF-Modell verliert gegenüber dem ursprünglichen FP16-Modell im safetensors-Format etwas an Genauigkeit. Bei Q4_K_M oder Q5_K_M ist der Unterschied minimal und im Gebrauch selten wahrnehmbar. Bei Q2/Q3 wird er sichtbar.

Kann ich eine safetensors-Datei direkt in Ollama verwenden?

In den meisten Fällen nicht direkt: Ollama erwartet GGUF. Die safetensors-Datei muss zuvor mit llama.cpp in GGUF konvertiert werden. Einige neuere Versionen unterstützen den Import von safetensors, aber GGUF bleibt der zuverlässige Weg.

Warum so viele Dateien auf einer Hugging Face-Seite?

Ein Modell ist oft in mehrere Shards (safetensors oder GGUF) aufgeteilt; hinzu kommen die Konfigurations- und Tokenizer-Dateien. Bei GGUF benötigen Sie in der Regel eine einzige Datei pro Quantisierung (oder alle Teile einer aufgeteilten Serie).

#Weiterführende Informationen

Nachdem die Formate nun keine Geheimnisse mehr für Sie bergen, führen diese Leitfäden das Thema auf natürliche Weise weiter.

Quantisierung wählen (Q4, Q5, Q8, FP16)

Der ausführliche Leitfaden zur Wahl der Quantisierungsstufe eines GGUF entsprechend Ihrem VRAM und Ihren Qualitätsanforderungen.

Was ist Ollama und wie funktioniert es

Das Tool verstehen, das GGUF lokal herunterlädt und bereitstellt, einschließlich der grundlegenden Befehle.

Das Kontextfenster verstehen

Der andere Parameter, der den Speicherbedarf beeinflusst: Token und Kontext, die zusammen mit der Wahl der Quantisierung berücksichtigt werden müssen.