2025-05-11 · Aktualisiert 2026-07-15

[!NOTE] Automatische Übersetzung Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

Offene Weight LLM Varianten, Quantization, sowie Formate: Instruct, MoE, GGUF, GPTQ, und AWQ

Namen wie zum Beispiel Model-32B-A3B-Instruct-AWQ es wirkt komplex, da mehrere unabhängige Entscheidungen kombiniert werden: Familie und Größe, Architektur, Trainingsrolle sowie Quantization. Ein Repository kann diese Weights als aufgeteilte Safetensors verpacken, während eine von der Community durchgeführte Umwandlung desselben Checkpoint in Form von Q4_K_M.gguf.

Diese Labels gehören nicht derselben Kategorie an: GPTQ und AWQ sind Quantization-Methoden, GGUF ist ein Container sowie ein Runtime-Ökosystem, und MoE stellt eine Architektur dar. Wenn man die einzelnen Schichten getrennt betrachtet, fällt die Auswahl beim Herunterladen deutlich leichter.

Zusammenfassung. Wählen Sie einen Checkpoint hinsichtlich der Aufgabengüte, Lizenz, Sprache, Kontext sowie Interface-Verhalten aus. Anschließend wählen Sie einen Runtime, der die Architektur dieses Elements unterstützt. Erst danach sollten Sie eine Weight-Repräsentation sowie eine Quantization auswählen, die zu den verfügbaren Speichermengen und den Anforderungen bezüglich Latency passen. GPTQ und AWQ sind Quantization-Methoden, Safetensors sowie GGUF sind Container, während MoE lediglich eine Architektur darstellt – es gibt keine Garantie dafür, dass alle Weights in den „aktiven Parameter“-Speicher passen.

Ein Model-Objekt in sechs Schichten lesen

Diese Schichten sind nicht gegenseitig ausschließend. Ein Checkpoint kann gleichzeitig abstrahiert, instruktionsspezifisch angepasst, Reasoning-spezifisch angepasst sowie MoE werden.

„Open-source“-Projekte erfordern ebenfalls sorgfältige Prüfung. Viele herunterladbare Models sind zwar open-Weight, unterliegen jedoch Lizenzen, die weder der Definition von Open Source entsprechen noch Nutzungseinschränkungen aufweisen. Lesen Sie vor der Durchführung von Architektur- oder Benchmark-Vergleichen unbedingt die dazugehörige Model-Karte sowie die Lizenzbedingungen.

Die Labels der Trainingsrolle beschreiben das Verhalten, nicht Garantien bezüglich der Fähigkeiten

Basis

Eine Basis Checkpoint wird hauptsächlich zur Vorhersage des nächsten Token trainiert. Sie eignet sich für fortlaufende Pretraining, kontrollierte Forschungsarbeiten oder Anpassungen, bei denen man das Verhalten der Anweisungen selbst steuern möchte. Anstelle einer direkten Antwort kann sie gegebenenfalls einen Prompt ausführen.

Man sollte nicht davon ausgehen, dass jede Feinabstimmung unbedingt von der Basisversion aus beginnen muss. Ein Instruktor Checkpoint stellt eine bessere Initialisierung dar, wenn sein bisheriges Verhalten mit den Anforderungen des Ziels übereinstimmt und Ihre Bewertung bestätigt, dass er nicht im Widerspruch zum neuen Ziel steht.

Anweisungen geben oder chatten

Diese Checkpoints erhalten Post-Training mit dem Ziel, die Befolgung von Anweisungen sowie den Konversationsverlauf zu verbessern. Das genaue Verfahren kann überwachte Fine-Tuning, Optimierung von Präferenzen, Verstärkungslernen, Destillation oder Kombinationen dieser Ansätze umfassen – es müssen dabei nicht unbedingt klassische SFT zusammen mit RLHF verwendet werden.

Verwenden Sie einen Instruktionen-Checkpoint als Grundlage für den ersten Assistenten. Überprüfen Sie dessen Chat-Vorlage, das unterstützte Format für Tool-Aufrufe, das Verhalten von Systemnachrichten sowie die Eigenschaften bei Ablehnungen. Allein die Angabe „Instruct“ garantiert keine zuverlässige Erstellung von JSON oder Tool Use.

Reasoning-anpassung

Reasoning-orientierte Checkpoints sind auf Aufgaben oder Handlungsabläufe optimiert, bei denen mehrstufiges Problemlösen belohnt wird. Einige liefern Reasoning-Text direkt, andere trennen diesen mithilfe eines Serving-Parsers, und wieder andere geben lediglich eine Antwort aus. Eine längere Generierung garantiert weder eine zuverlässige Reasoning noch weniger Hallucinations.

Wählen Sie einen solchen Ansatz erst dann aus, wenn er die kritischen Bereiche verbessert, die nach Berücksichtigung der Ausgabe Tokens, Latency sowie der Überprüfung von Bedeutung sind. Eine routinemäßige Extraktion oder Klassifizierung kann ohne entsprechende Verbesserungen langsamer werden.

Verdünnt

Durch Distillation wird das Verhalten eines Lehrsystems oder von vom Lehrsystem erzeugten Daten auf ein anderes Model übertragen. Das Lernsystem kann dabei kleiner sein, die gleiche Größe haben oder strukturell unterschiedlich aufgebaut sein. Es gilt keine feste Regel wie „70–80 % der Qualität bei der Hälfte der Größe“: Die beibehaltene Qualität hängt vom Lehrsystem, den Daten, dem Ziel, der Kapazität des Lernsystems sowie der Bewertungsmethode ab.

behandeln Distill Als Herkunftsinformation bezüglich des Trainings wird Benchmark genauso behandelt wie jeder andere Checkpoint.

Architektur-Labels beschreiben die Ausführung

Dichte Models

Die meisten Parameter nehmen an der Vorwärtspropagierung jedes Token teil. Die Anzahl der Parameter gibt einen groben Hinweis auf den Speicherbedarf von Weight, doch der Runtime-Speicher umfasst außerdem KV cache, Activations bzw. das Arbeitsumfeld, die Overhead-Kosten des Allocators sowie gegebenenfalls duplizierte oder in Teile aufgeteilte Zustände.

Mischung aus Expertenmodellen

Eine MoE-Schicht leitet jeden Token an eine Teilmenge von Experten-Feedforward-Netzwerken weiter. Bezeichnungen wie A3B In der Praxis sind in der Regel etwa drei Milliarden Parameter pro Token aktiv, wobei sich die Namenskonventionen je nach Familie unterscheiden. Auf der Karte zu Model finden Sie Angaben zum Gesamtanzahl der Parameter, zu den aktiven Parametern, zur Anzahl der Experten sowie zu den Aspekten des Routing-Designs.

Aktive Parameter beschreiben hauptsächlich Rechenoperationen. Es sei denn, der Runtime Entlastet Experten, alle Experten Weights braucht weiterhin Speicher sowie in der Regel auch den Arbeitsspeicher des Geräts Serving Topologie. Gesamtgröße 30 Milliarden, aktive Parameteranzahl 3 Milliarden. Model passt nicht automatisch wie ein dichter 3B-Modell. Model.

Die Unterstützung für Runtime ist zudem architekturspezifisch. Überprüfen Sie vor dem Herunterladen die Implementierung von Model – insbesondere die Unterstützung für Expertenparallellität oder Tensorparallellität – sowie die Eigenschaften von Quantization Kernels und den maximal zulässigen Kontextumfang.

Container und Quantization stellen unterschiedliche Schichten dar

Safetensors

Safetensors ist ein sicheres Serialisierungsformat für Tensorstrukturen, das häufig in Hugging Face-Repositorien verwendet wird. Ein Model kann mehrere solcher Tensorstrukturen enthalten. .safetensors Shards zusammen mit der Konfiguration, Tokenizer, sowie den Generierungsdateien. Diese Tensorstrukturen können entweder BF16/FP16 sein oder mithilfe von Methoden wie GPTQ oder AWQ im Voraus quantisiert werden.

Allein die Erweiterung gibt keine Informationen über die Genauigkeit oder die Kompatibilität mit Runtime her. Prüfen Sie daher sorgfältig. config.json, Quantization-Konfiguration, Model-Karte, Tensor-Datentyp sowie Runtime-Dokumentation.

GGUF

GGUF Pakete für Tensoren sowie Metadaten im ggml/llama.cpp-Ökosystem. llama.cpp Es erfordert GGUF und unterstützt Backends einschließlich Metal, CUDA, HIP, Vulkan sowie CPU-Pfade. Die Model-Architektur sowie die Qualität der Konvertierung bestimmen weiterhin die Kompatibilität.

GGUF ist ein Container. Er kann hochpräzise oder quantisierte Tensor speichern. Multimodale Models-Daten benötigen möglicherweise außerdem eine separate Projektions- oder Kodierungsdatei; die Aussage, dass „eine GGUF-Datei alles enthält“, gilt nicht universell.“

GPTQ und AWQ

GPTQ und AWQ sind Post-Training Weight-Quantization-Methoden und keine Dateierweiterungen. Ihre Erzeugnisse machen in der Regel von Safetensors sowie methodenspezifischer Konfiguration Gebrauch. Serving-Engines benötigen Kernels, die mit der jeweiligen Methode, der Bitbreite, der Gruppengröße, der Model-Architektur sowie der Hardware kompatibel sind.

Keine der beiden Methoden stellt eine universell beste Lösung hinsichtlich der Qualität dar. Calibration Data, die Implementierung, der Kernel-Pfad sowie die jeweilige Aufgabe spielen dabei eine entscheidende Rolle. Stromwandler, TGI und vLLM unterstützen mehrere Quantization Backends, wobei sich ihre Matrizen ändern können; es ist daher ratsam, die festgelegten Runtime zu überprüfen, anstatt sich auf statische Tabellen in Blogs zu verlassen.

Quantization Die Mathematik liefert einen Untergrenzwert, nicht eine Kapazität Planning

Für die (P) Weight-Parameter bei (b) Bits beträgt der Speicherbedarf für rohe Weight-Daten ungefähr:

[ \text{Weight Bytes} \approx \frac{P \times b}{8} ]

Ein 13B Model mit einem nominalen vierbitigen Weights-Speicherbedarf beginnt daher bei etwa 6,5 GB. Es muss jedoch nicht unbedingt innerhalb dieses Speicherraums laufen. Skalierungen, Nullpunkte, Tensor mit höherer Präzision, Embeddings, Metadaten, Runtime-Puffer sowie KV cache fügen zusätzlich Speicher hinzu.

Kontext und Konkurrenz können den Unterschied zwischen „Ladungen“ und „Dienstleistungen“ maßgeblich beeinflussen. Messen Sie den Spitzenwert des Arbeitsspeichers unter Berücksichtigung der tatsächlichen maximalen Abfolge, der Batch-Strategie, des Typs des Caches sowie des Parallelismus.

Quantization kann den Speicherverbrauch verringern und gelegentlich die Geschwindigkeit erhöhen, doch ein niedrigbitiger Kernels kann auf nicht unterstütztem Hardware-Setup ebenfalls langsamer arbeiten. Vergleichen Sie dabei die Qualität der Aufgabe sowie die Gesamtleistung des Throughput – und nicht nur die Dateigröße.

Decode GGUF Quantization sorgfältig auswählen

In Q4_K_M:

• Q4 es weist auf eine vierbitige Quantization-Familie hin, wobei nicht jeder Tensor exakt vier Bit verwendet. K erkennt das K-Quant-Schema. M Es wird ein gemischtes Rezept erkannt, das für ausgewählte Weights unterschiedliche Tensor-Typen verwendet. Damit ist keineswegs eine „mittlere Blockgröße“ gemeint.

der aktuelle llama.cpp Quantization Die Dokumentation weist darauf hin, dass die Rezepte je nach Architektur und Tensorkategorie variieren können. Eine Bedeutungsmatrix kann zudem dabei helfen zu entscheiden, welche Weights Mehr Präzision beibehalten.

Vermeiden Sie allgemeingültige Aussagen. Q4_K_M ist nicht von BF16 zu unterscheiden, oder dass ein größerer Q3 Model stets einem kleineren Q8 Model überlegen ist. Verwenden Sie für den exakten Checkpoint eine kleine Leiterstruktur:

1. Referenzobjekt mit hoher Präzision oder zuverlässiger Qualität
2. Ein Kandidat, der nahe am Speichermanagement-Limit liegt
3. Ein kleinerer Kandidat mit mehr verfügbarem Speicherplatz

Führen Sie bei allen dreien die gleichen Prompts-Prüfungen für strukturierte Ausgaben, Fälle mit langen Kontexten sowie die Latency-Tests durch.

Eine Auswahl Workflow, die auch bei neuen Formaten erhalten bleibt

1. Beheben Sie den Auftragsvertrag.

Definieren Sie Sprache, Modalität, Kontextlänge, Tool- oder Schema-Schnittstelle, Sicherheitsbeschränkungen, Lizenzanforderungen sowie Bewertungsschnitte. Vergleichen Sie Checkpoints in einer Darstellung, die ausreichend präzise ist, um zu verhindern, dass Quantization in der ersten Runde eine Entscheidung trifft.

2. Wählen Sie den Checkpoint aus.

Wählen Sie den kleinsten Checkpoint aus, der die unverhandelbaren Qualitäts- und Verhaltenskriterien erfüllt. Dokumentieren Sie dabei den genauen Repository-Ort sowie die Revision, Tokenizer, das Chat-Template sowie jeden erforderlichen Reasoning-Parser.

3. Wählen Sie den Runtime aus.

Überprüfen Sie die Architekturunterstützung, die Hardware Backend, die Parallelisierbarkeit, Quantization Kernels, Structured Output, die Adapter sowie die Betriebsinterface. Bei lokalen GGUF Inference, llama.cpp Der Referenzwert ist Runtime. Bei GPU Serving sollte man den aktuellen Wert von vLLM, TGI, Transformers oder spezialisierten Engines mit dem tatsächlichen Artefakt vergleichen.

4. Definieren eines maßvollen Speicherkapitals

Es müssen der Weights, der KV cache, der Runtime-Arbeitsbereich sowie die erwartete Konkurrenzfähigkeit berücksichtigt werden, ebenso wie der verfügbare Puffer für das Betriebssystem oder gleichzeitig laufende Prozesse. Ein Datei, die in den RAM oder in VRAM passt, ist zwar notwendig, reicht jedoch nicht aus.

5. Auswahl und Überprüfung einer Repräsentation

Wählen Sie vorzugsweise von dem Verlag bereitgestellte Artefakte mit dokumentierten Calibration-Informationen sowie Nachweisen zur Herkunft. Falls eine Konvertierung aus der Community verwendet wird, müssen die Quelldateiversion, die Version des Konvertierungsprogramms, die Quantization-Konfiguration, die Calibration-Daten oder die Relevanzangaben sowie die Hash-Werte aufgezeichnet werden.

6. Benchmark die Veröffentlichungseinheit

Es müssen die Aufgabengüte, die Richtigkeit des Schemas sowie der Tool-Aufrufe, die Zeit bis zum ersten Token, die Ausgabe Throughput, der maximale Speicherverbrauch sowie Fehler im Zielkontext unter Berücksichtigung der Konkurrenzsituation gemessen werden. Nach Änderungen von Einstellungen wie Checkpoint, Runtime, Kernel oder Quantization muss die Messung erneut durchgeführt werden.

Benutzerdefinierter Name

Angenommen, ein Repository trägt den Namen:

Acme-32B-A3B-Instruct-AWQ

Lesen Sie es als eine Reihe von Fragen:

• Acme: Welche Familie, Lizenz und Revision? 32B: Gesamtanzahl Weights oder eine andere Konvention des Verlags? A3B: Wie definiert diese Familie die aktiven Parameter? Instruct: Welches Post-Training-Rezept und welches Chat-Template? AWQ: Welche Bitbreite, Gruppengröße, Calibration und unterstützte Kernels?
• Repository-Dateien: Safetensors-Shards, Konfigurationen, Tokenizer sowie benutzerdefinierter Code?
• Ziel-Runtime: Unterstützt die festgelegte Version genau diese Architektur sowie Quantization?

Der Name dient lediglich als Index zu den Dokumentationen und stellt keine vollständige Spezifikation für Deployment dar.

Fazit

Die Model wird weniger verwirrend, sobald die Labels nicht mehr denselben Bereich teilen. Die Trainingsrolle gibt an, welches Verhalten optimiert wurde. Die Architektur zeigt, wie die Berechnungen organisiert sind. Quantization macht deutlich, wie bestimmte Tensor approximiert wurden. Container informieren darüber, wie Artefakte gespeichert werden. Runtimes bestimmen, was auf Ihrer Hardware effizient ausgeführt werden kann.

Wählen Sie in dieser Reihenfolge, behalten Sie die genaue Herkunft bei, und lassen Sie eine Aufgabewertung die Veröffentlichungsartefakte miteinander vergleichen. Ein bekannter Suffix ist kein Beweis dafür, dass der Model geeignet ist, schnell läuft oder das von Ihnen gewünschte Verhalten beibehält.

Referenzen

• GGUF-Spezifikation und llama.cpp Quantization Leitfaden
• Hugging Face Transformer-Modelle Quantization Konzepte
• GPTQ-Artikel
• AWQ-Artikel
• vLLM Quantization Dokumentation