LLM-Quantisierung: 7 Methoden im Vergleich (mit Benchmark-Zahlen)

LLM-Quantisierung: 7 Methoden im Vergleich (mit Benchmark-Zahlen)

Llama 3.3 70B braucht in FP16 allein 140 GB für die Gewichte. Zwei H100. Bei Q4_K_M passt dasselbe Modell in rund 42 GB, das ist eine gebrauchte RTX A6000 von eBay. Diese Lücke ist der gesamte Grund, warum es LLM-Quantisierung überhaupt gibt. Die falsche Methode kostet Sie entweder sichtbare Qualität oder VRAM, den Sie nicht haben.

Dieser LLM-Quantisierungsleitfaden vergleicht die 7 Methoden, die 2026 zählen. Jede Zahl ist auf eine veröffentlichte Quelle zurückgeführt.

Kernaussagen

• Quantisierung tauscht Speicher und Bandbreite gegen einen messbaren, meist kleinen Qualitätsverlust.
• GPTQ und AWQ sind GPU-first; GGUF ist das Format, das auch auf der CPU läuft.
• Q4_K_M liegt bei etwa 4,8 Bit pro Gewicht, nicht bei 4. Die Namensgebung verschleiert den Overhead.
• 6-Bit-Quantisierung bleibt laut dem llama.cpp K-Quants-PR innerhalb von ~0,1 % der FP16-Perplexität.

Was macht LLM-Quantisierung tatsächlich mit Ihrem Modell?

LLM-Quantisierung speichert Modellgewichte mit geringerer numerischer Präzision und reduziert so Speicherbedarf und Bandbreite auf Kosten von Rundungsfehlern. Ein 70B-Parameter-Modell sinkt von 140 GB bei FP16 auf etwa 42 GB bei 4 Bit. Die Intelligenz bleibt; die Nachkommastellen gehen. Jede Methode in diesem Leitfaden ist eine Variante dieses Tauschs.

Die Präzisionsleiter läuft von FP32 (32 Bit) über FP16 und BF16 (je 16 Bit) hinab zu INT8 und dann INT4. Jede Stufe halbiert die Bytes pro Parameter. Der IEEE-754-Standard definiert die Gleitkommaformate; Mark Horowitz' Paper von 2014 "Computing's Energy Problem" zeigte, warum das Verschieben dieser Bytes und nicht die Rechenoperationen darauf die Energiekosten dominiert. Das ist der physikalische Grund, warum Quantisierung die Inferenz beschleunigt.

Zwei Parameter machen Quantisierung funktionsfähig: ein Skalierungsfaktor (Multiplikator, der den Integerbereich auf reale Werte zurückbildet) und ein Nullpunkt (der Integerwert, der 0,0 repräsentiert). Symmetrische Quantisierung zentriert den Bereich um null und verzichtet auf den Nullpunkt; asymmetrische Quantisierung versetzt ihn, um den vollen Integerbereich zu nutzen, wenn die Gewichte nicht um null gruppiert sind.

Gewichte lassen sich sauber quantisieren, weil sie statisch und normalverteilt sind. Aktivierungen nicht. Ausreißer-Aktivierungen, manchmal das 100-Fache des Medians, sprengen den Rundungsfehler bei naiver Quantisierung. Diese Asymmetrie ist der Grund, warum die meisten Methoden hier nur Gewichte quantisieren (W4A16) und Aktivierungen in FP16 belassen.

Post-Training-Quantisierung (PTQ) wandelt ein fertiges Modell nach dem Training um. Quantisierungsbewusstes Training (QAT) simuliert Rundung während des Trainings, damit sich das Modell anpasst. Alles in diesem Beitrag ist PTQ. QAT kostet mehr Rechenleistung und einen Trainingslauf; das ist eine separate Entscheidung.

Die INT4- und NF4-Zeilen sind theoretische reine 4-Bit-Werte: 4 Bit pro Gewicht und sonst nichts. Reale 4-Bit-Formate tragen Block-Skalierungen und Minima obendrauf, daher landen sie höher. Ein 70B-Modell bei Q4_K_M ist etwa 42 GB, nicht 35. Die VRAM-Tabelle weiter unten verwendet stattdessen die effektiven Raten.

Quantisierung schrumpft nicht die Intelligenz des Modells. Sie schrumpft die Anzahl der Nachkommastellen, in denen diese Intelligenz gespeichert wird. Und wenn Sie pro Token für API-Inferenz zahlen, beginnt das Senken Ihrer LLM-API-Kosten oft damit, ein quantisiertes Modell selbst zu betreiben.

Die 7 Quantisierungsmethoden im direkten Vergleich

Die sieben Methoden unten decken jeden Produktionspfad für die Quantisierung eines LLM im Jahr 2026 ab. Zwei sind GPU-only (GPTQ, AWQ), eine läuft überall (GGUF), eine quantisiert beim Laden (BitsandBytes), zwei zielen auf Hochdurchsatz-Serving (SmoothQuant, FP8), und eine ist PyTorch-nativ (TorchAO). Die richtige Wahl hängt von Ihrer Hardware ab, nicht davon, welche Methode auf einem Leaderboard am höchsten punktet.

GPTQ quantisiert Schicht für Schicht und nutzt die inverse Hesse-Matrix, um Rundungsfehler auf die verbleibenden Gewichte umzuverteilen. Es braucht einen Kalibrierungsdatensatz und eine GPU. Das GPTQ-Paper berichtet über die Quantisierung eines 175B-Modells auf 3-4 Bit in etwa 4 GPU-Stunden.

AWQ identifiziert die ~1 % der Gewichte, die am wichtigsten sind (saliente Gewichte, ermittelt aus Aktivierungsbeträgen), und skaliert sie, um sie vor Rundung zu schützen. Das AWQ-Paper (MLSys 2024 Best Paper) berichtet über mehr als 3x Beschleunigung gegenüber der HuggingFace-FP16-Implementierung auf Desktop- und Mobil-GPUs.

GGUF ist ein Dateiformat, kein Algorithmus. Der Algorithmus darin ist das K-Quant-Blockschema aus llama.cpp PR #1684. Es ist die einzige Methode hier, die auf der CPU läuft, was sie zum Standard für lokale Inferenz macht. Siehe Open-Weight-Modelle, die sich zum Quantisieren lohnen für geeignete Kandidaten.

BitsandBytes quantisiert beim Laden statt im Voraus. NF4 (4-Bit NormalFloat) ist das Signaturformat und das Rückgrat von QLoRA-Feintuning. Kein Kalibrierungsdatensatz nötig.

SmoothQuant migriert Aktivierungsausreißer in die Gewichte, damit beide mit INT8 laufen können. Das Paper berichtet über bis zu 1,56x Beschleunigung und 2x Speicherreduktion und zielt auf Durchsatz bei Large-Batch-Serving, wo W4A16-Methoden Leistung verschenken.

FP8 (W8A8) ist der native Pfad auf H100- und B200-GPUs. Near-lossless bei 8 Bit, kein Kalibrierungsaufwand, und vLLM unterstützt es direkt.

TorchAO ist PyTorchs eigene Quantisierungsbibliothek, gebaut für die Zusammenarbeit mit torch.compile. Wenn Ihre Pipeline bereits PyTorch ist, ist es der Weg des geringsten Widerstands.

Es gibt nur zwei echte Fragen: Läuft es auf Ihrer Hardware, und können Sie mit den Qualitätskosten leben?

Was zeigen die veröffentlichten Benchmarks wirklich?

Veröffentlichte Benchmarks besagen, dass 4-Bit-Quantisierung bei einem 7B-Modell 1-2 % Perplexität kostet und 6 Bit unter 0,1 %. Diese Zahlen stammen aus llama.cpp PR #1684 (2023), gemessen von den llama.cpp-Maintainern an einem einzigen 7B-Modell auf einer RTX 4080. Sie sind die meistzitierten Werte im Quantisierungsbereich, und sie sind real. Sie sind auch n = 1.

Quelle: llama.cpp PR #1684 (2023). 7B-Modell, RTX 4080, gemessen von den llama.cpp-Maintainern. n = 1 Modell.

Ein Hinweis zur Bit/Gewicht-Spalte: Das sind die nominalen Raten für den Basis-K-Quant-Typ, und die _K-Mischungen erhöhen die effektive Rate. Q2_K ist ein gutes Beispiel. Wendet man die Formel aus diesem Beitrag auf die nominalen 2,5625 und ein 6,74B-Parameter-Modell an, erhält man ~2,0 GB, aber die Zeile meldet eine 2,67-GB-Datei, was rückgerechnet ~3,4 Bit pro Gewicht ergibt. Der Rest dieses Beitrags verwendet die effektiven Raten, abgeleitet aus diesen Dateigrößen.

Die GPU-Methoden-Zahlen stammen direkt aus den Papern. GPTQ berichtet über End-to-End-Inferenzbeschleunigungen gegenüber FP16 von etwa 3,25x auf einer A100 und ~4,5x auf einer A6000, wobei ein 175B-Modell in etwa 4 GPU-Stunden auf 3-4 Bit quantisiert wurde. AWQ berichtet über „mehr als 3x Beschleunigung gegenüber der HuggingFace-FP16-Implementierung auf Desktop- und Mobil-GPUs" sowie das erste 70B-Llama-2-Deployment auf einer Mobil-GPU via TinyChat. Wir zitieren die Formulierung des Papers, statt eine Zahl in falsche Präzision umzuformulieren.

Der originale Beitrag hier ist Arithmetik. Der Speicher für Gewichte folgt: Gewichte (GB) ≈ Parameter (Mrd.) × Bit pro Gewicht ÷ 8. Der Haken ist, welchen Bit-pro-Gewicht-Wert man einspeist. PR #1684 veröffentlicht die Rate für den Basis-K-Quant-Typ (Q4_K = 4,5), und die _S/_M/_L-Mischungen liegen über dieser Basisrate, weil sie den Aufmerksamkeits- und Feed-Forward-Tensoren zusätzliche Bits zuweisen. Also haben wir die effektiven Raten aus den Dateigrößen abgeleitet, die der PR selbst veröffentlicht, an einem 7B-Modell, das tatsächlich 6,74B Parameter hat: Q2_K bei 2,67 GB ergibt rückgerechnet ~3,4 bpw, Q4_K_S bei 3,56 GB ~4,5, Q6_K bei 5,15 GB ~6,6. Q4_K_M landet bei etwa 4,8.

Das ändert die Schlagzeilenzahl. Ein 70B-Modell bei Q4_K_M: 70 × 4,8 ÷ 8 = 42 GB. Die meisten Beiträge sagen 35 GB. Sie verwenden 4,0 bpw und überspringen den Block-Skalierungs-Overhead komplett. Der Gegencheck kostet einen Klick: Llama-3.3-70B-Instruct-Q4_K_M.gguf wird auf HuggingFace mit 42,5 GB ausgeliefert, in den bartowski-, lmstudio-community- und second-state-Repos gleichermaßen. Wir haben jede Zelle in der VRAM-Tabelle unten auf dieser Basis neu berechnet.

Unsere Lesart dieser Zahlen: Die Perplexitätslücke zwischen Q6_K (5.9110) und F16 (5.9066) beträgt 0,0044, was kleiner ist als die Lücke zwischen zwei verschiedenen Feintunings desselben Basismodells. Deshalb ist „Nehmen Sie einfach Q4_K_M oder Q5_K_M" der Rat, der den Kontakt mit realer Hardware übersteht. Die ms/Token-Spalte zeigt auch, dass Q2_K keinen Geschwindigkeitsvorteil gegenüber Q4_K_S bringt (beide 15,5 ms/Token), dabei aber 0,75 Perplexität kostet. Q2_K ist der schlechteste Tausch in der Tabelle.

Was die Zahlen Ihnen nicht sagen: Wikitext-Perplexität ist nicht dasselbe wie Qualität auf Ihren Prompts. Ein Modell auf einer GPU ist n = 1. Geschwindigkeitswerte sind von der Batch-Größe abhängig. Behandeln Sie diese als richtungsweisend, nicht als universell.

6-Bit-Quantisierung landet innerhalb von etwa 0,1 % der Perplexität des Vollpräzisionsmodells. Die Komprimierung ist auf diesem Niveau nahezu kostenlos.

GPTQ vs. AWQ: Die Wahl zwischen den zwei GPU-Methoden

GPTQ und AWQ erzeugen beide 4-Bit-GPU-Checkpoints aus einem Kalibrierungsdatensatz, und beide werden in vLLM gut unterstützt. Der Unterschied liegt im Umgang mit Rundungsfehlern. GPTQ verteilt sie über die inverse Hesse-Matrix auf die verbleibenden Gewichte um. AWQ schützt die 1 % der Gewichte, die Aktivierungen als wichtig markieren. Beide funktionieren. Die Wahl hängt von Ihrem Serving-Muster ab.

GPTQ arbeitet Schicht für Schicht. Für jede Schicht quantisiert es ein Gewicht nach dem anderen und passt dann die verbleibenden Gewichte dieser Schicht an, um die gerade durchgeführte Rundung zu kompensieren. Die Anpassung nutzt Informationen zweiter Ordnung aus der Hesse-Matrix, weshalb ein Kalibrierungsdatensatz zur Berechnung nötig ist. Das Ergebnis ist stark bei Batch-Inferenz, wo Durchsatz wichtiger ist als Pro-Token-Latenz.

AWQ wählt einen anderen Ansatz. Es identifiziert saliente Gewichte durch Betrachtung der Aktivierungsbeträge über den Kalibrierungsdatensatz, grob die obersten 1 % der Kanäle. Diese Gewichte erhalten einen Pro-Kanal-Skalierungsfaktor, der sie während der Rundung in einem höherpräzisen Bereich hält. Der Kalibrierungsdatensatz kann kleiner sein als bei GPTQ, und AWQ überanpasst weniger daran, weil es strukturelle Merkmale schützt statt sich an spezifische Eingaben anzupassen. Das Paper berichtet über starke Ergebnisse bei latenzkritischem Serving.

Wählen Sie GPTQ, wenn: Sie Batch-Inferenz auf einer GPU betreiben, einen guten Kalibrierungsdatensatz haben, der Ihrer Domäne entspricht, und Durchsatz die Metrik ist.

Wählen Sie AWQ, wenn: Sie Einzelanfragen mit niedriger Latenz bedienen, einen kleineren Kalibrierungsdatensatz wollen oder auf Edge-/Mobil-GPUs deployen.

# Serve a published AWQ checkpoint with vLLM
vllm serve TheBloke/Llama-2-7B-Chat-AWQ \
  --quantization awq \
  --max-model-len 4096

# Serve a published GPTQ checkpoint with vLLM
vllm serve TheBloke/Llama-2-7B-Chat-GPTQ \
  --quantization gptq \
  --max-model-len 4096

Wenn Sie auch zwischen Serving-Engines wählen, behandelt vLLM gegen SGLang diese Entscheidung separat.

GGUF und K-Quants: Was Q4_K_M tatsächlich bedeutet

GGUF ist ein Dateiformat, kein Quantisierungsalgorithmus. Die GGUF-Spezifikation definiert einen Container für Modellgewichte, Metadaten und Tokenizer-Daten. Der Quantisierungsalgorithmus innerhalb einer GGUF-Datei ist das K-Quant- (oder I-Quant-) Blockschema aus llama.cpp PR #1684. Den Container mit dem Algorithmus zu verwechseln ist der häufigste Fehler in diesem Bereich und führt zu Fragen wie „Was ist besser, GGUF oder GPTQ?", die nicht ganz aufgehen.

Das Namensschema entschlüsselt sich wie folgt. Q bedeutet K-Quant-Blockschema; IQ bedeutet Importance-Matrix-I-Quant (eine neuere Variante, die eine Importance-Matrix für bessere Qualität bei gleicher Bittiefe nutzt). Die Zahl ist die nominale Bittiefe. _K markiert die K-Quant-Familie gegenüber Legacy-Formaten wie Q4_0. _S, _M, _L steuern, welche Tensorgruppen zusätzliche Bits erhalten: small, medium, large. Höheres Suffix bedeutet mehr Bits für die Aufmerksamkeits- und Feed-Forward-Tensoren, die am wichtigsten sind.

Effektive Raten, rückgerechnet aus den 7B- (6,74B-Parameter-) Dateigrößen aus PR #1684, nicht die Basis-Typ-Werte. Die Legacy-Zeilen sind konstruktionsbedingt exakt: Ein Q4_0-Block ist 32 Gewichte à 4 Bit plus eine FP16-Skalierung, also 4,5 Bit pro Gewicht, und Q8_0 ist 32 Gewichte à 8 Bit plus eine FP16-Skalierung, also 8,5. Der PR bestätigt das und listet die 7B Q4_0- und Q4_K_S-Dateien mit denselben 3,56 GB.

Q4_K_M ist nicht 4 Bit pro Gewicht. Es sind etwa 4,8. Die Block-Skalierungen und Minima müssen irgendwo wohnen, und die _M-Mischung investiert dann zusätzliche Bits in die Aufmerksamkeits- und Feed-Forward-Tensoren, was genau der Grund ist, warum Q4_K_M über Q4_K_S liegt und Q3_K_M über Q3_K_S statt gleichauf.

Warum GGUF dort läuft, wo GPTQ nicht kann: Es unterstützt CPU-Inferenz und Layer-Offloading zwischen GPU-VRAM und Systemspeicher. Ein 32B-Modell, das nicht vollständig auf Ihre GPU passt, kann mit der Hälfte seiner Schichten im Offload laufen, langsam aber funktional. GPTQ hat keinen CPU-Pfad.

# Pull a specific quant tag with Ollama
ollama run llama3.1:8b-instruct-q4_K_M

# Convert an F16 GGUF to Q4_K_M with llama.cpp
llama-quantize model-f16.gguf model-q4_k_m.gguf Q4_K_M

Neu bei lokalen Modellen? Starten Sie mit Ihr erstes lokales Modell zum Laufen bringen, bevor Sie irgendetwas quantisieren. Und wenn Sie eine Browser-Oberfläche wollen, braucht Open WebUI auf Ollama etwa zehn Minuten. Die HuggingFace-GGUF-Dokumentation erklärt, wie der Hub die Quant-Typ-Namen offenlegt.

BitsandBytes, Marlin, SmoothQuant und TorchAO

Diese vier decken die verbleibenden Produktionspfade ab. Keine davon ist ein „besseres GPTQ". Sie lösen unterschiedliche Probleme.

BitsandBytes quantisiert zur Ladezeit, nicht im Voraus. Sie zeigen auf einen FP16-Checkpoint, und es konvertiert on-the-fly zu NF4 oder FP4. Kein Kalibrierungsdatensatz, kein Offline-Schritt. Der Hauptanspruch auf Bekanntheit ist QLoRA: ein 4-Bit-eingefrorenes Basismodell mit darauf trainierten LoRA-Adaptern, was Single-GPU-Feintuning eines 65B-Modells auf 48 GB VRAM ermöglicht. QLoRA ist eine Trainingstechnik, keine Inferenztechnik, aber der Grund, warum die meisten BitsandBytes zuerst begegnen.

Marlin ist keine Quantisierungsmethode. Es ist ein INT4xFP16-Mixed-Precision-GEMM-Kernel, der bestehende 4-Bit-Checkpoints bei moderaten Batch-Größen beschleunigt. Das Marlin-Paper berichtet über Beschleunigungen auf A100 und H100. Wenn Ihr Serving-Stack es unterstützt, aktivieren Sie es auf einem bereits quantisierten Modell. Man „quantisiert nicht mit Marlin".

SmoothQuant verschiebt Aktivierungsausreißer über einen Pro-Kanal-Skalierungsfaktor in die Gewichte und macht W8A8 (sowohl Gewichte als auch Aktivierungen bei INT8) praktikabel. Das Paper zielt auf Large-Batch-Serving, wo W4A16-Methoden Durchsatz verschenken. Wenn Sie Hunderte gleichzeitiger Anfragen bedienen, ist das der richtige Zug.

TorchAO ist PyTorch-native Quantisierung, die mit torch.compile funktioniert. Keine externen Abhängigkeiten, keine Formatkonvertierung. Wenn Ihre Inferenz-Pipeline bereits PyTorch ist, ist es die Option mit der geringsten Reibung. Für das lokale Ausführen von Embedding-Modellen ist der Ollama-Pfad meist einfacher, aber TorchAO passt zu individuellen PyTorch-Stacks.

Wie viel VRAM braucht ein quantisiertes Modell?

Die Formel lautet Gewichte (GB) ≈ Parameter (Mrd.) × Bit pro Gewicht ÷ 8. Ein 70B-Modell bei Q4_K_M: 70 × 4,8 ÷ 8 = 42,0 GB. Die Raten unten sind effektive Werte, rückgerechnet aus den Dateigrößen, die llama.cpp PR #1684 veröffentlicht, statt aus den Basis-Typ-Zahlen, weil die _M-Mischungen immer über ihrer Basis-K-Quant-Rate liegen. Wir haben neu berechnet statt den üblichen 4,0-bpw-Wert zu kopieren.

Berechnet aus effektiven Bit-pro-Gewicht-Werten: Q8_0 = 8,5, Q6_K = 6,56, Q5_K_M = 5,7, Q4_K_M = 4,8, Q3_K_M = 3,9. Abgeleitet aus den 7B- (6,74B-Parameter-) Dateigrößen in PR #1684, dann gegen einen veröffentlichten 70B-Build gegengeprüft: Llama-3.3-70B-Instruct-Q4_K_M.gguf ist 42,5 GB auf HuggingFace, gegenüber 42,0 GB hier vorhergesagt.

Der ehrliche Vorbehalt: Das sind nur Gewichte. KV-Cache, Kontextlänge und Framework-Overhead kommen obendrauf. Der KV-Cache skaliert mit Kontextlänge und Batch-Größe. Eine 32k-Kontext-Sitzung auf einem 70B-Modell kann mehrere GB hinzufügen. Die Gewichtstabelle ist die Untergrenze, nicht das Budget. Ihr Kontextfenster mietet ebenfalls VRAM. Für das vollständige Bild siehe VRAM-Anforderungen pro Modell im Detail.

Welche Quantisierungsmethode sollten Sie verwenden?

Ihre Hardware entscheidet vor Ihren Präferenzen. Eine Methode, die auf Ihrer GPU nicht läuft, ist keine Wahl, sondern ein Wunsch. Die Tabelle unten ordnet gängige Setups der Methode zu, die tatsächlich für sie funktioniert, basierend auf den oben behandelten Hardware-Beschränkungen und Qualitätstradeoffs.

Für die meisten Leser auf Consumer-Hardware ist ein vorquantisiertes Q4_K_M- oder Q5_K_M-GGUF die richtige Antwort. Von HuggingFace laden, in Ollama oder llama.cpp ausführen, und aufhören zu optimieren. Der Qualitätsunterschied zwischen Q4_K_M und Q5_K_M ist klein genug, dass Sie nach Dateigröße entscheiden sollten, nicht nach einer Perplexitätstabelle. Alles darüber hinaus ist Optimierung um der Optimierung willen und lohnt sich erst, wenn Sie bestätigt haben, dass das Modell Ihr Problem bei Q4 tatsächlich löst.

Der Leitfaden Tools, die diese Modelle tatsächlich lokal ausführen behandelt die Serving-Seite, sobald Sie eine Quant-Stufe gewählt haben.

Fünf Wege, wie Quantisierung schiefgeht

Quantisierungsfehler sind fast immer Konfigurationsprobleme, keine Methodenprobleme. Diese fünf tauchen ständig auf.

1. Kalibrierungsdatensatz passt nicht zu Ihrer Domäne. GPTQ und AWQ passen sich beide an die Kalibrierungsdaten an. Wenn Sie auf Wikipedia kalibrieren und auf medizinischen Transkripten deployen, unterperformt das quantisierte Modell bei den Tokens, die es nie gesehen hat. Lösung: Verwenden Sie einen Kalibrierungsdatensatz aus Ihrer tatsächlichen Eingabeverteilung, selbst 128 Stichproben helfen.

2. Gruppengröße zu groß eingestellt. GPTQs Gruppengröße steuert, wie viele Gewichte sich einen Skalierungsfaktor teilen. 128 ist der Standard. 256 oder 512 spart Rechenzeit bei der Quantisierung, trifft aber bei kleineren Modellen eine Qualitätswand. Lösung: Bleiben Sie bei 128, außer Sie haben bestätigt, dass die Qualität auf Ihren Prompts hält.

3. Erwarten, dass Q2_K brauchbar ist. Laut den PR-#1684-Daten kostet Q2_K ~0,87 Perplexität gegenüber F16 und bringt keinen Geschwindigkeitsvorteil gegenüber Q4_K_S (beide 15,5 ms/Token im 7B-Benchmark). Sie erhalten eine kleinere Datei und schlechtere Ausgabe ohne Latenzgewinn. Lösung: Q4_K_S ist die Untergrenze, außer Dateigröße ist eine harte Beschränkung.

4. Benchmarking auf Wikitext-Perplexität statt auf eigenen Prompts. Perplexität ist eine Sprachmodell-Metrik. Sie misst nicht, ob das Modell Ihrem System-Prompt folgt, JSON korrekt formatiert oder Ihr Domänenvokabular beherrscht. Lösung: Schicken Sie 20-30 Ihrer echten Prompts durch das quantisierte und das nicht-quantisierte Modell und vergleichen Sie die Ausgaben.

5. GGUF den Container mit dem Quantisierungsalgorithmus darin verwechseln. Das führt zum Vergleich „GGUF vs. GPTQ", als wären sie dieselbe Kategorie. Sind sie nicht. GGUF ist ein Dateiformat. Das K-Quant-Schema darin ist der Algorithmus. Lösung: Vergleichen Sie K-Quant-Stufen (Q4_K_M vs. Q5_K_M), nicht Dateiformate.

Häufig gestellte Fragen

Was ist LLM-Quantisierung?

LLM-Quantisierung reduziert die numerische Präzision der Gewichte eines Modells, typischerweise von 16-Bit-Gleitkomma auf 4-Bit- oder 8-Bit-Integer. Das senkt den Speicherverbrauch und beschleunigt die Inferenz durch reduzierte Bandbreite. Ein 70B-Modell sinkt von 140 GB auf etwa 42 GB bei 4 Bit. Die Qualitätskosten liegen meist bei 1-2 % Perplexität bei 4 Bit, weniger bei 6 Bit.

Reduziert Quantisierung die Genauigkeit eines Modells?

Ja, aber weniger als die meisten erwarten. Laut den llama.cpp-PR-#1684-Benchmarks kostet Q4_K_S auf einem 7B-Modell etwa 2 % Perplexität gegenüber F16, und Q6_K kostet unter 0,1 %. Die praktische Auswirkung auf echte Prompts ist oft kleiner als die Perplexitätszahl vermuten lässt, besonders ab Q4_K_M aufwärts.

Ist GPTQ oder AWQ besser?

Keines ist universell besser. GPTQ nutzt inverse-Hesse-Fehlerumverteilung und eignet sich für Batch-GPU-Inferenz. AWQ schützt saliente Gewichte über aktivierungsbewusste Skalierung und eignet sich für latenzkritisches Serving. AWQ braucht einen kleineren Kalibrierungsdatensatz und überanpasst weniger daran. Wenn Sie Einzelanfragen mit niedriger Latenz bedienen, starten Sie mit AWQ.

Was bedeutet Q4_K_M?

Q4_K_M ist eine K-Quant-GGUF-Quantisierungsstufe. „Q4" bedeutet nominale 4-Bit-Tiefe, „K" markiert das K-Quant-Blockschema (gegenüber Legacy Q4_0), und „M" bedeutet medium: Aufmerksamkeits- und Feed-Forward-Tensoren erhalten zusätzliche Bits. Effektive Bit pro Gewicht liegen bei etwa 4,8, nicht 4,0, weil Block-Skalierungen und Minima Overhead hinzufügen und die Medium-Mischung zusätzlich investiert.

Kann ich ein quantisiertes Modell auf einer CPU ausführen?

Ja, aber nur über GGUF. GPTQ und AWQ sind GPU-only-Formate. GGUFs K-Quant-Modelle laufen auf der CPU über llama.cpp oder Ollama und unterstützen Layer-Offloading zwischen GPU-VRAM und Systemspeicher. Q4_K_M ist die Standard-CPU-Quantisierung. Erwarten Sie langsamere Token-Generierung als auf der GPU, aber funktionale Inferenz.

Was ist der Unterschied zwischen GGUF und GGML?

GGML ist die ältere Tensor-Bibliothek und das Dateiformat, das llama.cpp ursprünglich nutzte. GGUF ersetzte es im August 2023 als flexibleres Containerformat mit besserer Metadaten-Unterstützung. GGUF-Dateien sind es, was Sie heute von HuggingFace herunterladen. GGML-Dateien sind Legacy und werden kaum noch verteilt.

Sollte ich ein Modell selbst quantisieren oder ein vorquantisiertes herunterladen?

Laden Sie zuerst ein vorquantisiertes herunter. Die llama.cpp- und HuggingFace-Communities haben die meisten gängigen Modelle bereits auf jeder Stufe quantisiert. Selbst zu quantisieren ergibt nur Sinn, wenn Sie einen spezifischen Kalibrierungsdatensatz für Ihre Domäne brauchen oder keine vorquantisierte Version für Ihr Modell existiert.

Wann sollte ich Quantisierung statt eines kleineren Modells verwenden?

Verwenden Sie Quantisierung, wenn Sie die Fähigkeit des größeren Modells brauchen, aber nicht in den Speicher passen. Ein quantisiertes 70B-Modell übertrifft generell ein nicht-quantisiertes 13B-Modell bei komplexen Reasoning-Aufgaben. Verwenden Sie stattdessen ein kleineres Modell, wenn Latenz die Beschränkung ist, da kleinere Modelle unabhängig von Quantisierung schneller Tokens generieren.

Was ist der Unterschied zwischen Quantisierung und Destillation?

Quantisierung reduziert die numerische Präzision der Gewichte eines bestehenden Modells. Destillation trainiert ein kleineres Modell, ein größeres zu imitieren, und erzeugt eine genuinely andere (kleinere) Architektur. Quantisierung bewahrt die Architektur des Originalmodells und ist prinzipiell umkehrbar. Destillation erzeugt ein neues Modell und erfordert einen Trainingslauf.

Die Kurzversion: Quantisierung ist der Weg, ein gewünschtes Modell in vorhandene Hardware zu bekommen. Für die meisten auf Consumer-GPUs oder Apple Silicon ist ein vorquantisiertes Q4_K_M-GGUF von HuggingFace die gesamte Lösung. GPTQ und AWQ sind die GPU-Serving-Antworten. FP8 und SmoothQuant sind die Produktions-Durchsatz-Antworten. Alles andere ist Optimierung, nachdem Sie bestätigt haben, dass das Modell funktioniert.

Wenn Sie entscheiden, was Sie selbst hosten wollen, und eine zweite Meinung zur Hardware-Methoden-Kombination möchten, sprechen Sie uns gerne an.