Automatische Übersetzung
Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.
Open-Source-LLM-Varianten und Dateiformate: Instruct, GGUF, GPTQ, AWQ und MoE
Warum haben Open-Source-LLMs so viele verwirrende Namen?
Du hast wahrscheinlich Namen wie Llama-3.1-8B-Instruct.Q4_K_M.gguf oder Mistral-7B-v0.3-A3B.awq gesehen und dich gefragt, wofür die Suffixe stehen. Sie wirken überladen, sagen dir aber tatsächlich zwei verschiedene Dinge gleichzeitig.
Open-Source-LLMs unterscheiden sich entlang zweier unabhängiger Dimensionen:
- Modellvariante: Das Suffix im Namen (
-Instruct,-Distill,-A3B) beschreibt, wie das Modell trainiert wurde und wofür es optimiert ist. - Dateiformat: Die Endung (
.gguf,.gptq,.awq) beschreibt, wie die Gewichte gespeichert sind und wo sie am besten laufen (CPU, GPU, mobil).
Die Variante entscheidet, was das Modell kann. Das Format entscheidet, wo es effizient läuft.
Wenn du diese beiden Dinge verwechselst, verbringst du schnell einen Abend damit, CUDA-Fehler bei einem Modell zu verfolgen, das von Anfang an nie auf deine Karte gepasst hätte.
Modellvarianten erklärt (das Rezept)
Die Variante sagt dir, welche Art von Training die Gewichte durchlaufen haben.
Base-Modelle
Das rohe vortrainierte Modell. Es hat Sprachmuster aus riesigen Textkorpora gelernt, aber nie gelernt, Anweisungen zu befolgen; es sagt nur das nächste Token vorher.
Du nutzt es, wenn du es auf deinen eigenen Daten fine-tunen willst, wenn du Forschung betreibst und das „reine“ Foundation-Modell willst, oder wenn du gezielt ein Modell ohne Alignment-Training dazwischen möchtest.
Der Nachteil: Es befolgt Anweisungen nicht zuverlässig. Fragst du „Was ist die Hauptstadt von Frankreich?“, antwortet es vielleicht mit „und was ist die Hauptstadt von Deutschland?“, weil du aus seiner Sicht gerade eine Fragenliste begonnen hast.
Instruct- / Chat-Modelle
Ein Base-Modell, das zusätzlich trainiert wurde (Supervised Fine-Tuning plus RLHF), damit es menschliche Anweisungen befolgen kann. Das ist das, was die meisten tatsächlich meinen, wenn sie sagen, sie „wollen ein LLM“.
Das ist die richtige Wahl für Chatbots, Agenten und RAG. Genauso für Function Calling, Tool-Nutzung und alltägliche Hilfe beim Coden. Grob 95 % der Produktions-Use-Cases landen hier.
Der Preis dafür: Es ist durch das zusätzliche Training etwas größer und langsamer als das Base-Modell, und das Alignment kann es weniger „kreativ“ machen, weil es stärker in Richtung Vorhersagbarkeit und Hilfsbereitschaft gedrückt wurde.
Reasoning- / CoT-Modelle
Eine neuere Klasse wie DeepSeek-R1 oder die o1-Derivate, trainiert mit Chain-of-Thought Reinforcement Learning. Sie „denken“ vor der Antwort: Sie erzeugen interne Reasoning-Tokens, um komplexe Logik-, Mathematik- oder Coding-Probleme durchzuarbeiten, bevor sie die finale Antwort ausgeben.
Sie glänzen bei schwierigen Coding-Aufgaben, Debugging, Mathematikproblemen und Logikrätseln. Außerdem halluzinieren sie oft weniger, weil sie ihre eigene Arbeit gegenprüfen.
Der Haken ist die Latenz. Sie erzeugen einen langen Strom von „Gedanken“-Tokens, die du vielleicht nicht einmal siehst, auf die du aber trotzdem warten musst. Bei trivialen Prompts können sie außerdem unnötig ausführlich sein.
Destillierte Modelle
Ein kleineres „Schüler“-Modell, das darauf trainiert wurde, ein größeres „Lehrer“-Modell zu imitieren. Das Ergebnis ist komprimiertes Wissen: typischerweise 70–80 % der ursprünglichen Qualität bei 30–50 % der Größe.
Sie passen gut zu Mobil- oder Edge-Geräten, kostenkritischem SaaS, bei dem jede Millisekunde zählt, und Diensten, die viele Requests bedienen müssen.
Ein Stück der komplexen Reasoning-Fähigkeit geht verloren, aber die zurückgewonnene Effizienz ist schwer zu ignorieren.
MoE (Mixture-of-Experts): A3B, A22B usw.
Eine Architektur, bei der das Modell viele „Experten“-Subnetze hat, aber pro Token nur eine Teilmenge aktiviert. „A3B“ bedeutet, dass pro Token 3B Parameter aktiv sind, obwohl das Gesamtmodell 30B+ Parameter haben kann.
Das ist nützlich, wenn du die Fähigkeiten großer Modelle auf einer 12–24-GB-VRAM-Karte willst, ohne die vollen Inferenzkosten zu zahlen, oder wenn du lokal läufst und das beste Qualitäts-pro-Speicher-Verhältnis suchst.
Die Nachteile: größer auf der Platte (du musst trotzdem alle Experten speichern), und nicht jedes Inferenz-Framework unterstützt MoE-Routing bereits. Prüfe die Kompatibilität, bevor du dich auf einen 50-GB-Download festlegst.
Faustregel:
- Nimm standardmäßig ein Instruct-Modell. Das brauchen die meisten.
- Stoßt du an Speicher- oder Latenzgrenzen? Probiere eine destillierte oder MoE-Variante.
- Löst du wirklich harte Logikprobleme? Probiere ein Reasoning-Modell.
Dateiformate erklärt (der Container)
Sobald du weißt, welches Modell du willst, musst du wählen, wie es verpackt ist. Das Format entscheidet vor allem, wo es laufen kann und wie viel Speicher es braucht.
Quantisierung 101: warum wir Modelle verkleinern
Standardmodelle verwenden für jedes Gewicht 16-Bit-Zahlen (FP16). Präzise, aber schwergewichtig. Quantisierung reduziert die Gewichte auf 8-Bit-, 4-Bit- oder sogar 2-Bit-Zahlen.
- FP16: 2 Byte pro Parameter. Ein 13B-Modell ist ~26 GB.
- 4-bit: 0.5 Byte pro Parameter. Ein 13B-Modell ist ~6.5 GB.
Du gibst ein wenig „Intelligenz“ auf und bekommst dafür viel Geschwindigkeit und Speicher zurück.
GGUF (.gguf)
Der Nachfolger von GGML und heute de facto der Standard für lokale Inferenz. Eine einzelne Datei enthält die Gewichte, die Metadaten und sogar das Prompt-Template.
Das ist die richtige Wahl auf Apple Silicon (M1–M4), wo es nativ mit Metal-Beschleunigung läuft, und auf Maschinen ohne dedizierte GPU. Auch das Tooling ist bei diesem Format am besten: llama.cpp, Ollama und LM Studio konsumieren GGUF direkt.
Eine Datei, läuft fast überall, und es gibt für jedes Speicherbudget eine passende Quantisierungsstufe.
GGUF-Namen entschlüsseln (Q3_K_M, Q5_K_M usw.)
Du siehst oft eine lange Liste von Dateien wie Q3_K_M, Q4_K_S, Q5_K_M. Sie sind nicht zufällig; sie gehören zur K-quant-Familie.
So liest du Q3_K_M:
Q3: durchschnittliche 3-Bit-Quantisierung für die Gewichte.K: verwendet das K-quant-Schema (eine neuere Methode mit nichtuniformer Präzision).M: mittlere Blockgröße, wobeiSklein undLgroß ist.
Welche du wählen solltest:
Q3_K_M: die Budget-Option. Die Qualität sinkt spürbar, aber damit kannst du größere Modelle auf schwächerer Hardware ausführen.Q4_K_M: der Standard. Beste Balance aus Geschwindigkeit, Größe und Perplexity. Für die meisten Aufgaben ist es kaum von den unkomprimierten Gewichten zu unterscheiden.Q5_K_M: die Premium-Wahl. Nutze sie, wenn du VRAM übrig hast; die Qualität liegt sehr nah an FP16 / Q8 und bleibt dabei relativ kompakt.
Profi-Tipp: Es ist oft besser, ein größeres Modell mit niedrigerer Quantisierung zu betreiben (Llama-70B bei Q3) als ein kleineres Modell mit hoher Quantisierung (Llama-8B bei Q8). Die Parameterzahl bringt dir meist mehr Intelligenz als zusätzliche Präzision.
GPTQ (.safetensors + config.json)
Post-Training-Quantisierung mit Fokus auf Nvidia-GPUs. Sie nutzt Information zweiter Ordnung, um den Genauigkeitsverlust beim Komprimieren der Gewichte klein zu halten.
Das ist das richtige Format für Produktionsserver mit CUDA unter Linux und für High-Throughput-Setups bei 4-Bit. Mit dem ExLlamaV2-Loader wird es sehr schnell.
Der Haken ist die Hardware-Anforderung: Es braucht eine GPU und läuft auf CPUs oder Macs nicht effizient.
AWQ (.safetensors)
Activation-Aware Weight Quantization. Dabei wird betrachtet, welche Gewichte während der Inferenz am wichtigsten sind, und ihre Präzision erhalten, statt alle Gewichte gleichmäßig zu komprimieren.
Bei demselben 4-Bit-Budget liegt es in der Genauigkeit meist näher an FP16 als GPTQ und wird von vLLM nativ unterstützt. Wenn du aus einem 4-Bit-Modell die maximale Qualität herausholen willst, ist AWQ in der Regel der Gewinner.
PyTorch / Safetensors (FP16/BF16)
Volle Präzision, keine Quantisierung. Das ursprüngliche Format, in dem Modelle veröffentlicht werden.
Das willst du für Cloud-Inferenz auf ernsthafter GPU-Hardware (A100, H100), für Fine-Tuning und Continued Training und für Fälle, in denen Genauigkeit wichtiger ist als Speicher.
Die Kosten sind offensichtlich: Ein 70B-Modell in FP16 braucht rund 140 GB VRAM.
Tipp: Wenn du unsicher bist, starte mit GGUF Q4_K_M. Das läuft auf 8-GB-GPUs, modernen CPUs und fast allem dazwischen. Optimieren kannst du immer noch, sobald du den Bottleneck kennst.
Wie man das tatsächlich ausführt (Serving-Engines)
Du brauchst eine Serving-Engine, um das Modell zu laden und Requests zu beantworten.
- Ollama konsumiert GGUF und läuft auf Mac, Linux und Windows. Das einfachste CLI-Tool für lokale Entwicklung;
ollama run llama3und du bist fertig. - LM Studio verwendet ebenfalls GGUF und bietet eine ausgereifte GUI auf Mac und Windows. Gut, um Modelle visuell zu durchsuchen, bevor du dich auf eines festlegst.
- vLLM ist der Produktionsstandard. Es lädt AWQ-, GPTQ- und FP16-safetensors-Modelle und ist für High-Performance-Server und Docker-Deployments gebaut. GGUF-Support ist noch lückenhaft.
- llama.cpp ist die Engine unterhalb von Ollama. Nutze sie direkt, wenn du Low-Level-Integration brauchst oder wenn das Zielsystem klein ist (Raspberry Pi, Android, Embedded).
Alles zusammenführen: ein Entscheidungsrahmen
Ein praktischer Ablauf, an dem du dich orientieren kannst. Starte mit deinen Randbedingungen (Hardware und Use Case) und wähle dann die passende Variante und das passende Format.
Schnelle Empfehlungen nach Szenario
Chatbot auf einem MacBook Pro (16 GB RAM) bauen. Nutze ein Instruct-Modell wie Llama-3-8B oder Mistral-7B in GGUF Q4_K_M. Es läuft flüssig auf CPU und Metal, passt in den Speicher, und du musst nur mit einer Datei umgehen.
RAG-System auf einem Server mit einer RTX 4090 (24 GB VRAM). Nutze Instruct oder MoE (Mixtral 8x7B, Qwen-14B) in EXL2 (via ExLlamaV2) oder AWQ 4-bit. So holst du echten Nutzen aus 24 GB heraus; EXL2 ist auf Nvidia-Karten sehr schnell.
Fine-Tuning für domänenspezifische Nutzung auf einer Cloud-GPU. Nutze ein Base-Modell in FP16 safetensors. Für Training willst du volle Präzision, und der Start vom unalignierten Base-Modell vermeidet, dass du beim Fine-Tuning gegen das Alignment arbeitest.
High-Throughput-API mit Kostenrestriktionen. Nutze ein destilliertes Modell (DeepSeek-Distill oder ähnlich) in AWQ 4-bit auf vLLM. Der Throughput pro Dollar ist schwer zu schlagen.
Häufige Stolperfallen und Missverständnisse
„Alle 4-Bit-Modelle haben dieselbe Qualität“
Nein. Ein QAT-4-Bit-Modell (in 4-Bit trainiert) schlägt oft ein nachträglich auf 8-Bit quantisiertes Modell. Die Methode ist genauso wichtig wie die Bitzahl, und AWQ erhält normalerweise mehr Genauigkeit als naives GPTQ.
„MoE-Modelle funktionieren mit jeder Inferenz-Engine“
Noch nicht. llama.cpp beherrscht MoE-Routing gut, aber die Unterstützung in anderen Engines variiert. Immer erst prüfen, bevor du ein 50-GB-MoE-Modell herunterlädst.
„Destillierte Modelle sind einfach nur kleinere Versionen desselben Modells“
Genau das übersehen die meisten. Ein destilliertes 7B-Modell kann ein normales 13B-Modell schlagen, weil es von einem viel größeren Lehrer gelernt hat (oft 70B+). Es ist komprimiertes Wissen, nicht nur komprimierte Parameter.
„Ich sollte mein QAT-Modell weiter quantisieren, um Platz zu sparen“
Lass es. QAT-Modelle wurden bereits mit Low-Bit-Präzision trainiert. Wenn du sie danach noch einmal quantisierst, leidet die Qualität in der Regel stark. Verwende sie so, wie sie veröffentlicht wurden.
„Größer ist immer besser“
Oft, aber nicht immer. Ein gut abgestimmtes 8B-Instruct-Modell kann bei einer bestimmten Aufgabe besser abschneiden als ein schlecht aligniertes 70B-Base-Modell. Passe die Variante zuerst an den Use Case an, bevor du bloß Parameterzahlen jagst.
TL;DR - sag mir einfach, was ich herunterladen soll
Wenn du einfach etwas willst, das funktioniert:
- Lade eine
<model-name>-Instruct.Q4_K_M.gguf-Datei von Hugging Face herunter.- Führe sie mit Ollama oder LM Studio aus.
- Wenn es zu langsam ist, probiere ein kleineres Modell oder eine destillierte Variante.
- Wenn dir der Speicher ausgeht, wechsle auf eine Q3_K_M-Quantisierung.
- Wenn die Qualität nicht gut genug ist, gehe auf Q5_K_M hoch oder nimm ein größeres Modell.
Starte einfach und optimiere erst, wenn du es wirklich musst. Die Defaults funktionieren in ~90 % der Fälle.