Modellformate

Ein Modell-Release ist nicht eine Datei — es ist ein Checkpoint, der pro Engine neu verpackt wird. Diese Seite kartiert die Formate, denen Sie lokal tatsächlich begegnen: GGUF für die llama.cpp-Welt, Safetensors für den PyTorch/HF-Stack, engine-native GPU-Quants und ONNX für Edge-Runtimes. Wählen Sie zuerst die Engine; das Format folgt.

GGUF: eine Datei, alles drin

Eine .gguf-Datei packt Modellgewichte, Tokenizer-Vokabular, Chat-Template und Per-Tensor-Metadaten in eine einzige Binärdatei. Ein Download, null Konfiguration, und jede GGUF-sprechende App fährt dieselbe Datei: llama.cpp und llama-server, Ollama, LM Studio, Jan, KoboldCpp. Das Format ist memory-mappable, also streamen Gewichte Seite für Seite von der Platte — der Start ist schnell, und der OS-Seitencache macht das Caching gratis.

Dateinamen-Anatomie, Feld für Feld, für Qwen3-8B-Q4_K_M.gguf:

Inspizieren Sie jedes GGUF, ohne es zu laden:

python gguf-py/gguf/scripts/gguf_dump.py model.gguf

general.architecture     : qwen3
general.name             : Qwen3 8B
qwen3.context_length     : 32768
tokenizer.ggml.model     : gpt2 (BPE)
tokenizer.chat_template  : {%- ... ein Jinja-Template ... %}

Dieser Metadatenblock ist der Grund, warum ein GGUF über fünf verschiedene Apps hinweg „einfach funktioniert“: Die Engine liest die Architektur, baut den Graphen, lädt den Tokenizer, und Chat-Frontends wenden das eingebettete Template an. Keine Konfigurationssuche, kein Vokabular-Mismatch, kein separater Tokenizer-Download.

Safetensors: das Hugging-Face-Native

Safetensors ist ein absichtlich langweiliger Container: ein JSON-Header aus Tensor-Namen, Formen und dtypes, gefolgt von rohen Bytes. Er speichert nur Tensoren — keinen ausführbaren Code, anders als pickle-artige .bin-Checkpoints, die blind zu laden unsicher ist — und er unterstützt Zero-Copy-mmap, weshalb der PyTorch-Start schnell ist. Transformers, vLLM, SGLang, TRL und das ganze Fine-Tuning-Ökosystem sprechen ihn nativ.

Weil er nur Tensoren speichert, ist ein funktionierendes Model das ganze Repo-Verzeichnis:

model-00001-of-00004.safetensors   ← Gewicht-Shards (~5 GB je)
model-00002-of-00004.safetensors
model-00003-of-00004.safetensors
model-00004-of-00004.safetensors
model.safetensors.index.json        ← Shard-Map: Tensorname → Shard-Datei
config.json                         ← Architektur + Hyperparameter
generation_config.json              ← Standard-Sampling-Einstellungen
tokenizer.json                      ← der Tokenizer selbst
tokenizer_config.json               ← hier lebt das Chat-Template

Sharding existiert, weil ein 70B-FP16-Checkpoint ~140 GB ist — eine Datei wäre unhandlich. Serven Sie mit vLLM, laden Sie alle Shards herunter; es gibt keinen „nur die 4-Bit-Datei“-Abkürzer innerhalb eines Safetensors-Releases. Quanti­siertes Serving ist ein separates Repo (eine AWQ- oder GPTQ-Variante desselben Modells).

Engine-native GPU-Quants: AWQ, GPTQ, EXL2

Diese Formate existieren für GPU-Inferenz-Server, wo Durchsatz mehr zählt als Datei-Bequemlichkeit:

• AWQ — activationsbewusste Quantisierung. Kalibrierungs-Prompts finden die ~1% der Gewicht-Kanäle, von denen Aktivierungen am stärksten abhängen; diese bekommen geschütztes Skaling, alles andere geht auf 4-Bit. Nahezu originale Qualität bei 4-Bit mit schnellen Kernels; die Standard-4-Bit-Wahl in vLLM.
• GPTQ — der klassische GPU-Quant, abstammend von Optimal Brain Quantization: Layer für Layer quantisieren, wobei der Fehler jedes Layers gegen die noch nicht quantisierten Gewichte kompensiert wird. 4-Bit, reine GPU-Kernels, noch überall in Serving-Konfigurationen.
• EXL2 — exllamav2s Format mit variablen Bits pro Gewicht. Ein Repo kann etwa bei 4,65 bpw sitzen, indem 2–8-Bit-Tensoren gemischt werden, sodass die Summe exakt unter Ihrer VRAM-Kappe landet. Das Werkzeug für den Fall, dass Q4 nicht passt, Q3 aber wehtun würde.

Alle drei brauchen Kalibrierungsdaten und einen einmaligen Konversionslauf, und keiner von ihnen läuft auf der CPU.

ONNX, MLX, rohes FP16/BF16

ONNX ist das portable Compute-Graph-Format: Ein Transformers-Modell einmal exportieren und überall ausführen, wo onnxruntime läuft — Windows-Kisten ohne CUDA, Handys, WebGPU-Demos im Browser. onnxruntime kann den Graph auch für die CPU auf INT8 quantisieren. Sie zahlen Setup-Reibung und oft Spitzengeschwindigkeit; Sie gewinnen Portabilität auf Maschinen ohne PyTorch-Stack. Edge und Embedded sind sein Revier, nicht der Desktop-Chat.

MLX ist Apples Array-Framework für Apple Silicon; die Organisation mlx-community verpackt die meisten großen Releases ins MLX-Format, 4-Bit und 8-Bit inklusive. Auf einem M-Serie-Mac mit mlx-lm ist das Ihr Format — siehe Apple Silicon.

Rohe FP16/BF16-Checkpoints zählen, wenn Sie eine verlustfreie Referenz, eine Fine-Tuning-Basis oder eine Konversionsquelle wollen. BF16 behält den 8-Bit-Exponentenbereich von FP32 und tauscht dafür Mantissen-Bits — fürs Training weit stabiler als FP16, bei denselben 2 Bytes pro Gewicht. Ein 7–8B-Modell bei FP16/BF16 ist allein ~16 GB Gewichte, vor jedem Kontext.

Welches Format für welche Engine

Formate zu mischen ist der klassische Anfängerfehler: vLLM auf eine .gguf zeigen lassen oder llama.cpp auf Safetensors-Shards. Beides funktioniert nicht — die Engine bricht entweder mit einem Fehler ab oder braucht zuerst einen Konversionsschritt.

Konversionspfade

Der Standardpfad von einem Hugging-Face-Repo zu einer lokalen Datei hat zwei Schritte — den Checkpoint in ein 16-Bit-GGUF konvertieren, dann hinunter quantisieren:

git clone https://github.com/ggerganov/llama.cpp
pip install -r llama.cpp/requirements.txt

# 1. den HF-Checkpoint (Safetensors) nach GGUF konvertieren
python llama.cpp/convert_hf_to_gguf.py ./Qwen3-8B --outtype bf16 --outfile qwen3-8b-bf16.gguf

# 2. auf die Zielgröße quantisieren
llama-quantize qwen3-8b-bf16.gguf qwen3-8b-Q4_K_M.gguf Q4_K_M

In der Praxis konvertieren Sie selten selbst: Quantisierer wie bartowski und mradermacher veröffentlichen jede Größe jedes nennenswerten Releases binnen Stunden. Konvertieren Sie selbst, wenn Sie einen privaten Fine-Tune haben, ein imatrix-kalibriertes I-Quant wollen oder ein ungewöhnliches Bit-Ziel brauchen — Details in Quantisierung.

Embedding-Modelle — die Retrieval-Hälfte von RAG — erscheinen in denselben Formaten: GGUF für llama.cpps Embedding-Endpunkt, Safetensors für sentence-transformers. Dieselbe Regel wie überall oben: Passen Sie das Format an die Engine an, die Sie wirklich fahren werden.

Verwandt: Quantisierung · Modellfamilien · Engines · RAG