Open-Weight-LLM-Varianten, Formate und Quantization

Viacheslav Dubrov

2025-05-11 · Aktualisiert 2026-08-16 · 9 Min. · Modellentwicklung

Automatische Übersetzung Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

Namen wie Model-32B-A3B-Instruct-AWQ wirken dicht gepackt, weil sie mehrere unabhängige Entscheidungen kombinieren: Family und Größe, Architektur, Training Role und Quantization. Ein Repository kann diese Weights als geshardete Safetensors paketieren, während eine Community-Konvertierung desselben Checkpoints als Q4_K_M.gguf erscheint.

Diese Bezeichnungen gehören nicht alle derselben Kategorie an: GPTQ und AWQ sind Quantization-Methoden, GGUF ist ein Container und Runtime-Ökosystem, und MoE ist eine Architektur. Wenn die einzelnen Ebenen getrennt gelesen werden, fällt die Auswahl des Downloads leichter.

Wenn Sie zwischen einem Q4_K_M.gguf-Download für lokale Inference und einem AWQ-Safetensors-Repository für GPU Serving wählen, beginnen Sie mit dem Checkpoint-Verhalten und der für Ihre Aufgabe erforderlichen Architektur. Prüfen Sie anschließend, ob numerische Repräsentation, Package-Layout und Ziel-Runtime zur verfügbaren Hardware, zum Memory-Budget und zu den Serving-Constraints passen.

TL;DR. Wählen Sie einen Checkpoint anhand von Task-Qualität, Lizenz, Sprache, Context und Interface-Verhalten aus. Wählen Sie anschließend eine Runtime, die seine Architektur unterstützt. Erst danach wählen Sie eine Weight-Repräsentation und Quantization, die zu gemessenem Memory-Bedarf und gemessener Latency passen. GPTQ und AWQ sind Quantization-Methoden, Safetensors und GGUF sind Container, und MoE ist eine Architektur. Ein MoE-Label bedeutet nicht, dass alle Weights in den „Active-Parameter“-Memory passen.

Für die kompakte Deployment-Auswahl siehe LLM Quantization Formats.

Ein Model-Artefakt in sechs Ebenen lesen

Die Training-Provenance annotiert diese Ebenen, statt eine weitere Artefakt-Ebene hinzuzufügen. Beispielsweise beschreibt distilled, wie Verhalten übertragen wurde, nicht die Role des Checkpoints. Ein Checkpoint kann gleichzeitig distilled, instruction-tuned, reasoning-tuned und MoE sein.

Das Label „Open Source“ erfordert eine eigene Prüfung. Wenn ein Model lediglich downloadbare Weights veröffentlicht, sollten Sie nicht annehmen, dass seine Lizenz einer Open-Source-Definition entspricht oder Ihren Use Case erlaubt. Lesen Sie Model Card und Lizenz, bevor Sie Architektur oder Benchmarks vergleichen.

Training-Role-Labels beschreiben Verhalten, keine Capability-Garantien

Base

Ein Base-Checkpoint wird primär für Next-Token-Prediction trainiert. Er eignet sich für Continued Pretraining, kontrollierte Forschung oder Adaptation, wenn Sie das Instruction-Verhalten selbst bestimmen möchten. Er vervollständigt möglicherweise einen Prompt, statt ihn zu beantworten.

Gehen Sie nicht davon aus, dass jedes Fine-Tuning mit einem Base-Checkpoint beginnen sollte. Ein Instruct-Checkpoint kann die bessere Initialisierung sein, wenn sein vorhandenes Verhalten zum Ziel passt. Prüfen Sie mit Ihrer Evaluation, dass das bestehende Verhalten nicht mit dem neuen Objective kollidiert.

Instruct oder Chat

Diese Checkpoints erhalten Post-Training, das Instruction Following und Konversation verbessern soll. Das genaue Rezept kann Supervised Fine-Tuning, Preference Optimization, Reinforcement Learning, Distillation oder eine Kombination daraus umfassen. Es handelt sich nicht zwingend um Supervised Fine-Tuning gefolgt von RLHF.

Verwenden Sie einen Instruct-Checkpoint als erste Assistant-Baseline. Prüfen Sie sein Chat Template, das unterstützte Tool-Call-Format, das Verhalten bei System Messages und seine Refusal-Charakteristika. „Instruct“ allein garantiert weder zuverlässiges JSON noch zuverlässige Tool Use.

Reasoning-Tuned

Reasoning-orientierte Checkpoints werden auf Tasks oder Trajectories optimiert, die Multi-Step-Problem-Solving belohnen. Manche geben Reasoning-Text aus, manche trennen ihn über einen Serving-Parser, und manche präsentieren nur eine Antwort. Längere Generierung garantiert weder Faithful Reasoning noch weniger Hallucinations.

Setzen Sie einen solchen Checkpoint ein, wenn er die schwierigen Eval-Slices verbessert und dabei Output-Tokens, Latency und Verifikation berücksichtigt werden. Routinemäßige Extraction oder Classification kann dadurch langsamer werden, ohne besser zu werden.

Distilled

Distillation überträgt Verhalten von einem Teacher oder aus Teacher-generierten Daten in ein anderes Model. Der Student kann kleiner, gleich groß oder strukturell verschieden sein. Es gibt keine stabile Regel wie „70–80 % Qualität bei halber Größe“: Die erhaltene Qualität hängt von Teacher, Daten, Objective, Student-Capacity und Evaluation ab.

Betrachten Sie Distill als Provenance-Information zum Training und benchmarken Sie den Checkpoint anschließend wie jeden anderen.

Welche Bezeichnung sollte welchen Auswahlschritt beeinflussen? Diese Übersicht hält Training Role, Training Provenance und Architektur getrennt. Sie bewertet keine Model-Typen.

Die Transformers-Dokumentation zu Chat Templates erklärt, warum das exakte Message-Format eines instruction-tuned Models wichtig ist. Im ursprünglichen Paper zur Knowledge Distillation übertragen Hinton, Vinyals und Dean Verhalten auf einen Student, ohne ein festes Qualitätsverhältnis zu behaupten. Das Switch-Transformer-Paper beschreibt ein Design für Sparse Expert Routing. Eine konkrete MoE-Family kann Tokens anders routen; daher bleibt ihre Model Card maßgeblich.

Architektur-Labels beschreiben die Ausführung

!!! byte „Byte sagt“

Ich habe die GPU für ein Model mit 30B totalen und 3B aktiven Parametern dimensioniert, als wäre es ein Dense-3B-Model. Es ließ sich nicht laden. Alle 30B Weights müssen weiterhin irgendwo liegen.

Dense Models

Die meisten Parameter nehmen am Forward Pass jedes Tokens teil. Die Parameteranzahl ist ein grober Indikator für die Weight-Storage-Größe. Der Runtime-Memory-Bedarf umfasst außerdem KV cache, Activations oder Workspace, Allocator-Overhead sowie mitunter duplizierten oder geshardeten State.

Mixture of Experts

Eine MoE-Schicht routet jedes Token zu einer Teilmenge von Expert-Feed-Forward-Networks. Namen wie A3B bedeuten häufig, dass ungefähr drei Milliarden Parameter pro Token aktiv sind; Naming Conventions sind jedoch Family-spezifisch. Lesen Sie in der Model Card die totalen und aktiven Parameter, die Anzahl der Experts und das Routing-Design nach.

Die Anzahl aktiver Parameter beschreibt den gerouteten Compute, nicht die Platzierung der Weights. Beispielsweise shardet vLLM Expert Parallelism Expert Layers über Expert-Parallel-Ranks und leitet die Expert Allocation jedes Ranks aus der Gesamtzahl der Experts ab. Andere Runtimes können Weights anders platzieren oder Offloading verwenden. Ein Model mit 30B totalen und 3B aktiven Parametern passt daher nicht automatisch wie ein Dense-3B-Model.

Auch der Runtime-Support ist architekturspezifisch. Prüfen Sie vor dem Download die Model-Implementierung, den Support für Expert Parallelism oder Tensor Parallelism, die Quantization-Kernels und den maximalen Context.

Container und Quantization sind unterschiedliche Ebenen

Safetensors

Safetensors ist ein sicheres Tensor-Serialisierungsformat, das häufig in Hugging-Face-Repositories verwendet wird. Ein Model kann mehrere .safetensors-Shards sowie Configuration-, Tokenizer- und Generation-Dateien enthalten. Diese Tensoren können BF16/FP16 sein oder mit einer Methode wie GPTQ oder AWQ vorquantisiert worden sein.

Die Dateiendung allein sagt nichts über Precision oder Runtime-Kompatibilität aus. Prüfen Sie config.json, die Quantization-Configuration, die Model Card, den Tensor-Dtype und die Runtime-Dokumentation.

GGUF

GGUF paketiert Tensoren und Metadaten für das ggml/llama.cpp-Ökosystem. llama.cpp lädt GGUF und unterstützt Backends wie Metal, CUDA, HIP, Vulkan und CPU-Pfade. Architektur des Models und Qualität der Konvertierung bestimmen weiterhin die Kompatibilität.

GGUF ist ein Container. Er kann Tensoren mit hoher Precision oder quantisierte Tensoren enthalten. Multimodale Models benötigen möglicherweise zusätzlich eine separate Projector- oder Encoder-Datei. „Eine GGUF-Datei enthält alles“ ist keine universelle Regel.

GPTQ und AWQ

GPTQ und AWQ sind Post-Training-Weight-Quantization-Methoden, keine Dateiendungen. Ihre Artefakte verwenden häufig Safetensors zusammen mit einer methodenspezifischen Configuration. Serving Engines benötigen Kernels, die mit Methode, Bit Width, Group Size, Model-Architektur und Hardware kompatibel sind.

Keine der beiden Methoden ist universell qualitativ überlegen. Calibration Data, Implementation, Kernel-Pfad und Task sind relevant. Runtime-Support verändert sich; prüfen Sie daher das exakte Artefakt gegen die von Ihnen festgelegte Version. Lesen Sie als Nächstes die offiziellen Seiten zu Transformers Quantization und vLLM Quantization.

Die Hardware allein kann den Container nicht bestimmen. Wählen Sie zunächst eine Runtime, die Architektur und Serving Interface unterstützt. Verwenden Sie anschließend das Artefakt-Layout und den Quantization-Pfad, den diese Runtime dokumentiert.

Beispielsweise benötigt das Projekt llama.cpp GGUF und dokumentiert mehrere Hardware-Backends. Die GGUF-Spezifikation definiert einen Container für Tensoren und Metadaten. Transformers lädt Quantization-Methoden dagegen über Backend-spezifische Configuration, wie der Quantization-Workflow beschreibt. Keine dieser Quellen verspricht, dass eine passende Dateiendung jede Architektur unterstützt oder auf jedem Gerät gut läuft.

Quantization-Mathematik ist eine Untergrenze, keine Capacity-Planung

Für $P$ Weight-Parameter mit $b$ Bits beträgt der Raw-Weight-Storage ungefähr:

Ein 13B-Model mit nominellen 4-Bit-Weights benötigt daher zunächst etwa 6,5 GB. Es läuft nicht zwangsläufig mit 6,5 GB. Scales, Zero Points, Tensoren mit höherer Precision, Embeddings, Metadaten, Runtime-Buffers, KV cache und Fragmentierung erhöhen den Memory-Bedarf.

Context und Concurrency können den Unterschied zwischen „lädt“ und „serves“ bestimmen. Messen Sie den Peak-Memory-Bedarf mit der realen maximalen Sequence Length, Batch Policy, Cache-Dtype und Parallelism.

Quantization kann Memory reduzieren und manchmal die Geschwindigkeit erhöhen; Low-Bit-Kernels können auf nicht unterstützter Hardware jedoch auch langsamer sein. Vergleichen Sie Task-Qualität und End-to-End-Throughput, nicht nur die Dateigröße. Im llama.cpp Quantization Guide finden Sie Runtime-spezifische Recipes.

GGUF-Quantization-Namen sorgfältig lesen

In llama.cpp bezeichnet Q4_K_M ein Quantization-Rezept auf Dateiebene, nicht einen überall angewendeten Tensor-Typ. Die llama-quantize-Optionen führen Q4_K_M als auswählbaren Typ auf und beschreiben --pure als Deaktivierung von K-Quant-Mixes. Die Quantizer-Implementation verwendet Q4_K als Default für dieses Recipe und wendet auf bestimmte Tensor-Kategorien andere Typen an. Behandeln Sie das Suffix als Namen eines llama.cpp-Recipes, nicht als portable Bit-Width-Spezifikation.

Die aktuelle llama.cpp-Quantization-Dokumentation zeigt ebenfalls, dass Recipes je nach Architektur und Tensor-Kategorie variieren können. Eine Importance Matrix kann steuern, welche Weights mehr Precision behalten.

Vermeiden Sie universelle Aussagen, dass Q4_K_M von BF16 nicht zu unterscheiden sei oder dass ein größeres Q3-Model immer ein kleineres Q8-Model schlägt. Verwenden Sie für den exakten Checkpoint eine kleine Ladder:

1. Artefakt mit hoher Precision oder vertrauenswürdiges Referenzartefakt
2. ein Kandidat nahe am Memory-Limit
3. ein kleinerer Kandidat mit größerem Headroom

Führen Sie bei allen drei dieselben Prompts, Structured-Output-Checks, Long-Context-Fälle und Latency-Tests aus.

Ein Selection-Workflow, der neue Formate übersteht

1. Task Contract festlegen

Definieren Sie Sprache, Modalität, Context Length, Tool- oder Schema-Interface, Safety-Constraints, Lizenzanforderungen und Eval-Slices. Vergleichen Sie Checkpoints zunächst in einer ausreichend präzisen Repräsentation, damit Quantization die erste Runde nicht entscheidet.

2. Checkpoint auswählen

Wählen Sie den kleinsten Checkpoint, der die nicht verhandelbaren Qualitäts- und Verhaltens-Gates erfüllt. Dokumentieren Sie das exakte Repository und die Revision, den Tokenizer, das Chat Template und gegebenenfalls den benötigten Reasoning Parser.

3. Runtime auswählen

Prüfen Sie Architektur-Support, Hardware-Backend, Parallelism, Quantization-Kernels, Structured Output, Adapter und operatives Interface. Für lokale GGUF-Inference ist llama.cpp die Referenz-Runtime. Für GPU Serving vergleichen Sie aktuelle Versionen von vLLM, TGI, Transformers oder spezialisierten Engines mit dem tatsächlichen Artefakt.

4. Gemessenes Memory-Budget festlegen

Berücksichtigen Sie Weights, KV cache, Runtime-Workspace, erwartete Concurrency und Headroom für das Betriebssystem oder co-lokalisierte Prozesse. Dass eine Datei in RAM oder VRAM passt, ist notwendig, aber nicht ausreichend.

5. Repräsentation auswählen und validieren

Bevorzugen Sie vom Publisher bereitgestellte Artefakte mit dokumentierter Calibration und Provenance. Wenn Sie eine Community-Konvertierung verwenden, dokumentieren Sie Source-Revision, Converter-Revision, Quantization-Recipe, Calibration- oder Importance-Daten und Hashes.

6. Die Release Unit benchmarken

Messen Sie Task-Qualität, Schema-/Tool-Call-Korrektheit, Time to First Token, Output-Throughput, Peak-Memory und Fehler bei Ziel-Context und Ziel-Concurrency. Wiederholen Sie die Messung nach jeder Änderung an Checkpoint, Runtime, Kernel oder Quantization-Einstellung.

Beispielname

Angenommen, ein Repository heißt:

Acme-32B-A3B-Instruct-AWQ

Lesen Sie ihn als eine Reihe von Fragen:

• Acme: Welche Family, Lizenz und Revision?
• 32B: Totale Weights oder eine andere Publisher-Convention?
• A3B: Wie definiert diese Family aktive Parameter?
• Instruct: Welches Post-Training-Recipe und welches Chat Template?
• AWQ: Welche Bit Width, Group Size, Calibration und unterstützten Kernels?
• Repository-Dateien: Safetensors-Shards, Configs, Tokenizer und Custom Code?
• Ziel-Runtime: Unterstützt die festgelegte Version genau diese Architektur und Quantization?

Der Name ist ein Index in die Dokumentation, keine vollständige Deployment-Spezifikation.

Fazit

Die Model-Auswahl wird weniger verwirrend, sobald Labels nicht mehr derselben Kategorie zugeordnet werden. Die Training Role zeigt, welches Verhalten optimiert wurde. Die Architektur zeigt, wie der Compute organisiert ist. Quantization beschreibt, wie bestimmte Tensoren approximiert wurden, Container, wie Artefakte gespeichert sind, und Runtimes, was auf Ihrer Hardware effizient ausgeführt wird.

Wählen Sie in dieser Reihenfolge, bewahren Sie die exakte Provenance und lassen Sie eine Task-Evaluation die Release-Artefakte vergleichen. Ein vertrautes Suffix ist kein Beleg dafür, dass das Model passt, schnell läuft oder das benötigte Verhalten beibehält.

Referenzen

• Transformers Chat Templates – Message Formatting für kausale Language Models mit Base- und Instruction-Tuning.
• Distilling the Knowledge in a Neural Network – das ursprüngliche Distillation-Paper von Hinton, Vinyals und Dean.
• Switch Transformers – die Sparse-Expert-Routing-Architektur von Fedus, Zoph und Shazeer.
• GGUF-Spezifikation und llama.cpp Quantization Guide
• Quantization-Konzepte von Hugging Face Transformers
• GPTQ-Paper
• AWQ-Paper
• vLLM-Quantization-Dokumentation