Wer heute ein 70B-Modell auf eigener Hardware betreibt, tut das fast nie in voller Präzision. Quantisierung komprimiert die Gewichte, oft auch die Aktivierungen, und am Ende läuft das Modell mit einem Bruchteil des Speicherbedarfs. Das ist der ganze Sinn der Übung: Llama 3.1 70B passt in BF16 nicht auf eine einzelne H100, in 4-Bit aber sehr wohl. Ollama-Nutzer auf dem Mac mini, DGX-Spark-Besitzer, vLLM-Operatoren auf einer A6000: Alle profitieren vom selben Trick. Aus 16 Bit pro Gewicht werden 8, oft 4, manchmal weniger.
Der Standardreflex in der Community lautet seit Jahren ungefähr so: "Nimm Q4_K_M, das passt schon, kaum Qualitätsverlust." Das ist nicht völlig falsch. Es ist aber so undifferenziert, dass es Geld und Qualität liegen lässt. Denn Quantisierung ist kein Schalter zwischen "voll" und "komprimiert", sondern ein Feld mit Dutzenden Konfigurationen, sehr unterschiedlichen Verlustprofilen und einem unangenehmen Detail: Die Standard-Benchmarks zeigen den Verlust oft gar nicht. MMLU bleibt gleich, ARC bleibt gleich, und trotzdem antwortet das Modell auf konkrete Fragen anders als das Original. Das ist nicht Bauchgefühl. Das ist eine messbare Metrik, und sie hat einen Namen.
Einordnung: Dieser Artikel erklärt das Fundament von LLM-Quantisierung: warum Accuracy stabil bleiben kann, obwohl konkrete Antworten kippen. Die Blackwell-/NVFP4-Frage behandeln wir im Folgeartikel separat.
Accuracy ist nicht Qualität
Dutta et al. haben 2024 in der NeurIPS-Arbeit "Accuracy is Not All You Need" genau diesen Punkt sauber gemacht. Sie haben sechs Quantisierungsschemata auf sieben Standard-Tasks gegen das Basismodell gestellt und nicht nur die übliche Accuracy verglichen, sondern eine zweite Metrik eingeführt. Flips, also den Prozentanteil der Antworten, die zwischen Baseline und komprimiertem Modell von korrekt zu falsch oder von falsch zu korrekt wechseln.
Das Resultat ist ernüchternd für jeden, der bisher allein auf Benchmark-Scores geschaut hat. Die Accuracy-Differenz zwischen Basismodell und quantisierter Variante liegt in den meisten Konfigurationen bei null bis zwei Prozent. Die Flips-Rate erreicht im selben Setup bis zu 13,6 Prozent. Anders gesagt: Jede achte Antwort kann sich ändern, ohne dass die Summe der richtigen Antworten merklich kleiner wird. Die korrekten und die falschen Wechsel heben sich auf dem Aggregat gegenseitig auf. Das Modell wirkt gleich gut. Es ist aber nicht dasselbe Modell.
Wer noch wrong-to-wrong-Transitions mitzählt, also auch jene Fälle, in denen das komprimierte Modell zwar falsch antwortet, aber eine andere falsche Antwort gibt als das Original, kommt auf weitere zusätzliche Abweichung. Laut Paper reichen die Beispiele von 19 Prozent in Hellaswag über 41 Prozent in ARC bis zu 43 Prozent in MMLU. Die Korrelation zwischen KL-Divergence und Flips ist dabei nicht weich, sondern fast deterministisch. Spearman 0,981 auf MMLU. Die beiden Distanzmetriken messen denselben Effekt.
Daraus folgt eine Konsequenz für die ganze lokale-KI-Szene. Accuracy-Tabellen zeigen nicht, was Quantisierung wirklich kostet. Sie messen eine Eigenschaft, die durch Kompression kaum beschädigt wird, und übersehen genau jene Eigenschaft, die tatsächlich driftet: wie weit das Verhalten des komprimierten Modells vom Original abweicht. Diese Distanz ist in der Regel deutlich größer, als Leaderboards suggerieren.
Zwei Quantisierungsschemata fallen in der Dutta-Studie aus dem Rahmen, und sie tun es in entgegengesetzte Richtungen. GPTQ W8A16, also 8-Bit-Gewichte mit 16-Bit-Aktivierungen über GPTQ-Kalibrierung, behält die Accuracy und produziert vernachlässigbar wenige Flips. Es ist die Konfiguration, die der Baseline am nächsten kommt. Bitsandbytes W4A4, also extrem aggressive 4-Bit-Aktivierungsquantisierung, produziert auf MMLU 8 bis 16 Prozent Flips, auf PIQA noch 3 bis 6 Prozent. Und Llama2 70B im 4-Bit-Modus zeigt durchgängig 3 bis 8 Prozent Flips. Der grobe Trend: Je niedriger die Bit-Tiefe der Aktivierungen, desto stärker driftet das Verhalten ab, selbst wenn die Accuracy gleich bleibt.
Wichtig dabei: Die Autoren stützen sich vor allem auf Llama2 und Yi. Die Übertragbarkeit auf andere Familien ist eine Annahme, kein Beweis. Trotzdem hält sich das Kernmuster auch in späteren Arbeiten an anderen Modellen. Die Metrik selbst, Flips als Distanz statt Accuracy als Score, ist mittlerweile eine vernünftige Standardpraxis und wird zunehmend in seriösen Evaluationen mitgeführt.
Was die 500.000 Evaluationen auf Llama 3.1 zeigen
Knapp ein halbes Jahr nach dem Flips-Paper präzisierten Kurtic et al. mit "Give Me BF16 or Give Me Death? Accuracy-Performance Trade-Offs in LLM Quantization" das Bild für die heute relevanten Modelle. Über 500.000 Evaluationen auf der kompletten Llama-3.1-Familie, also 8B, 70B und 405B, mit den drei am häufigsten produktiv eingesetzten Schemata: W8A8 in FP8, W8A8 in INT8 und W4A16 in INT4.
Die Kernaussagen sind unangenehm präzise und widersprechen sehr direkt einem Teil des bisherigen Folklore-Wissens. FP8 ist über alle Modellgrößen und über alle untersuchten Benchmarks praktisch verlustfrei gegenüber BF16. Wer eine H100, H200 oder eine Hopper- oder Ada-Lovelace-Karte mit nativer FP8-Unterstützung betreibt, hat kaum noch eine Qualitätsbegründung, dort BF16 zu fahren. Der verbleibende Grund ist Tooling-Reife in bestimmten Frameworks oder ein konservatives Produktionsprofil. Inhaltlich bleibt FP8 der stabile Default moderner Inferenz-Stacks.
W8A8 in INT8 ist gegen den eigenen Ruf etwas freundlicher als noch vor zwei Jahren angenommen. Frühere Arbeiten hatten teils zweistellige Punktverluste berichtet, vor allem bei großen Modellen. Die Llama-3.1-405B-Resultate auf dem Open LLM Leaderboard V2 zeigen dagegen einen Abfall von 0,7 Punkten, nicht von zehn. Über alle Tasks gemittelt landet INT8 bei ein bis drei Prozent Accuracy-Differenz. Das ist in den meisten Anwendungsfällen ein vertretbarer Preis für deutlich besseren Durchsatz.
Und dann der eigentliche Twist: W4A16 in INT4, also 4-Bit-Gewichte bei 16-Bit-Aktivierungen, ist konkurrenzfähiger als seine Reputation. Allerdings nicht in jeder Variante. GPTQ mit sorgfältig gewählten Hyperparametern schlägt AWQ in den meisten Open-Ended-Benchmarks, obwohl AWQ in der Community oft als das robustere Verfahren gilt. Wer also W4A16 ernsthaft betreiben will und nicht nur das nächstbeste vorgefertigte Repository auf Hugging Face zieht, hat in GPTQ den stärkeren Kandidaten. Der Aufwand für eine eigene Kalibrierung ist überschaubar, der Qualitätsgewinn messbar.
Die Deployment-Empfehlung der Arbeit ist klar. Bei synchronen Workloads, also einzelne Requests, Chat-ähnlich, niedrige Last, ist W4A16-INT die kosteneffizienteste Wahl, weil der Engpass die Memory-Bandbreite ist. Bei asynchronen Continuous-Batching-Setups mit hohem Durchsatz, also produktive Inference-Server mit vielen parallelen Streams, ist W8A8 dominant. Der Grund ist nüchtern: Im Batched Regime ist die Aktivierungsquantisierung der eigentliche Hebel für Throughput, nicht die Gewichtsgröße. Wer das in eine grobe Kostenrechnung übersetzt: Im Lambda-Labs-Snapshot des Papers liegt 1x A6000 bei 0,80 USD pro Stunde, eine H100 bei 3,29, ein 8x-H100-Knoten bei 23,92. In diesen Preisklassen sind ein bis drei Prozent Accuracy-Differenz selten der Posten, an dem man optimiert.
Ein letzter Punkt aus dieser Arbeit ist subtil, aber konsumentenrelevant. Größere quantisierte Modelle bleiben dem BF16-Original in Wortwahl und Satzstruktur ähnlicher als kleinere. Wer also auf einem Mac mini ein 8B-Modell quantisiert, bekommt deutlich mehr stilistische Drift gegenüber dem Original als jemand, der ein 70B-Modell auf zwei A6000s in W4A16 fährt. Das ist intuitiv: Mehr Parameter bedeuten mehr Redundanz, und Redundanz absorbiert Quantisierungsfehler besser. Wer am unteren Ende der Modellgrößen quantisiert, zahlt prozentual mehr.
Long-Context und nicht-Englisch: Wo die Defaults zerbrechen
Bis hierhin ist das Bild halbwegs versöhnlich. Wer FP8 oder INT8 fährt, verliert fast nichts. Wer W4A16 mit GPTQ sauber kalibriert, verliert wenig. Wer bei BNB-nf4 landet, das in vielen Hugging-Face-Quickstarts als Default voreingestellt ist, verliert mehr als kommuniziert, aber im Standard-Benchmark-Setup noch im einstelligen Bereich.
Eine dritte Arbeit aus 2025 verschiebt diesen Frieden, und zwar präzise an den Stellen, die für ernsthafte Anwendungen entscheidend sind. 9.700 Testbeispiele, fünf Quantisierungsmethoden, fünf Modelle aus Llama-3.1 und Qwen-2.5. Ausgewählt wurde dabei nicht das gemütliche MMLU-Setup, sondern Long-Context-Aufgaben mit bis zu 128.000 Tokens und multilinguale Benchmarks über 26 Sprachen.
Im Durchschnitt bestätigt die Arbeit das bisherige Bild. FP8 verliert 0,2 Prozentpunkte gegenüber BF16, GPTQ-int8 0,8, AWQ-int4 1,8, GPTQ-int4 2,7, BNB-nf4 6,9. Das ist die Reihenfolge, die man erwartet, und die Größenordnungen sind moderat.
Dann kommen die Edge-Cases, und dort zerbricht der Konsens. In seinen Long-Context-Auswertungen dokumentiert das Paper bei 4-Bit-Quantisierung einen maximalen Leistungsabfall von bis zu 59 Prozent. Bei nicht-englischen Sprachen kann der Accuracy-Abfall bis zu fünfmal stärker ausfallen als im englischen Pendant. Das ist kein Effekt, den man wegdiskutiert.
Modellabhängig ist das Bild dabei nicht uniform. Qwen-2.5 72B bleibt unter BNB-nf4 in derselben Aufgabe relativ robust, während Llama-3.1 70B 32 Prozent verliert. Das ist ein konkreter Befund für die Modellwahl. Wer multilingual arbeitet und auf 4-Bit angewiesen ist, fährt mit Qwen besser als mit Llama. Wer für deutsche, französische oder italienische Texte ein lokales Modell sucht, sollte das im Hinterkopf behalten. Eine kompakte Übersicht der aktuellen Qwen-Modelle mit VRAM-Anforderungen und Use Cases liefert einen schnellen Einstieg in die Familie.
Methodisch ist die Arbeit dabei sauber. FP8 lief auf H100, die übrigen Experimente auf A100-80G, durchgängig mit Greedy Decoding und Temperatur 0.0. Das schließt zufällige Drift aus und macht die Ergebnisse reproduzierbar.
Die operative Konsequenz lautet: Bei Long-Context-Anwendungen, etwa lange Codebasen, Verträge, Logfiles, RAG-Pipelines mit großen Kontextfenstern, ist 4-Bit nicht der Reflex-Default. Bei nicht-englischen Sprachen gilt dasselbe. In beiden Fällen ist FP8 oder INT8 die konservative Wahl. Der Mehrverbrauch an Speicher ist hier Versicherung, nicht Verschwendung.
Q4_K_M, GGUF und lokale KI: Der Mac-mini-Default
Bis hierhin war von vLLM-Stacks die Rede, von Hugging-Face-Konfigurationen, von H100 und A100. Das ist eine Welt. Die zweite Welt heißt Ollama, llama.cpp, GGUF, und sie hat ihre eigene Quantisierungslogik. Q4_K_M, Q5_K_M, Q6_K, Q8_0. Diese K-Quants sind nicht identisch mit GPTQ oder AWQ. Sie verwenden eine Mischung aus Block-Quantisierung und unterschiedlichen Bit-Tiefen für verschiedene Tensor-Gruppen. Das ist clever konstruiert und im einfachen Chat-Betrieb auch sehr brauchbar.
Aber: Die oben zitierten Arbeiten haben K-Quants nicht direkt untersucht. Es gibt keine Studie auf demselben Niveau, die Q4_K_M gegen BF16 mit Flips, Long-Context und multilingual sauber misst. Was vorliegt, sind Community-Vergleiche, Perplexity-Werte und anekdotische Berichte. Daraus ein "passt schon" abzuleiten, ist verständlich, aber dünn.
Die plausible Brücke aus der Literatur lautet: Q4_K_M teilt das Risikoprofil von 4-Bit-Methoden. Im kurzen englischen Standardfall ist das oft brauchbar, bei Long-Context und nicht-englischen Texten steigt das Drift-Risiko. Die Block-Strategie der K-Quants mildert diesen Effekt, hebt ihn aber nicht auf. Wer auf einem Mac mini mit Ollama lokale KI ohne Cloud längere deutsche Dokumente verarbeitet, sollte mindestens Q5_K_M oder Q6_K versuchen. Der RAM-Aufpreis ist auf einem M4 mit 24 GB oder 32 GB gut zu rechtfertigen, wenn die Aufgabe ihn verlangt.
Das ist auch der Punkt, an dem die DGX-Spark-Praxis interessant wird. Auf einer 128-GB-Unified-Memory-Box muss man nicht in die engste Quantisierung gehen, nur weil das Modell sonst nicht passt. Man hat den Spielraum, FP8 oder INT8 zu fahren, wo die Studienlage solide ist. Genau dort liegt der strategische Wert lokaler Hardware: Die Wahl der Quantisierung wird vom Speicherzwang entkoppelt, und damit zu einer bewussten Entscheidung statt einer Notlösung.
Signal der Woche abonnieren
Eine Nachricht. Eine Analyse. Jeden Freitag im Newsletter.
Kostenlos als Member. Gratis abonnieren
Antipatterns & Systemische Risiken
Mehrere Verhaltensmuster sind in der Praxis verbreitet und systematisch problematisch.
Das erste Antipattern ist der Benchmark-Tunnelblick. Wer eine Quantisierung allein über MMLU oder Hellaswag validiert, misst die Eigenschaft, in der Quantisierung am wenigsten kostet, und übersieht die Eigenschaften, in denen sie am meisten kostet. Flips bleiben unsichtbar, Long-Context bleibt unsichtbar, nicht-englisch bleibt unsichtbar. Eine seriöse Validierung lokaler Modelle braucht mindestens eine Domain-spezifische Eval mit eigenen Prompts und im idealen Fall einen KL-Divergence- oder Flips-Vergleich gegen die nächsthöhere Präzision.
Das zweite Antipattern ist die Default-Akzeptanz aus Quickstart-Tutorials. Bitsandbytes-nf4 ist in vielen Hugging-Face-Beispielen voreingestellt, weil es schnell läuft und wenig Speicher braucht. In der Llama-3.1-Long-Context-Arbeit ist BNB-nf4 jedoch durchgängig das schwächste der untersuchten Schemata, mit dem stärksten Multilingual-Drop. Wer den Default übernimmt, ohne ihn zu prüfen, baut sich einen Floor an Qualitätsverlust ein, der vermeidbar wäre.
Das dritte Antipattern ist Quantisierung als Sicherheitsmaßnahme. Es ist ein Mythos, dass kleinere oder komprimierte Modelle weniger halluzinieren. Halluzinationen sind eine strukturelle Eigenschaft autoregressiver Sprachmodelle und werden durch Quantisierung tendenziell verstärkt, nicht reduziert. Wer das Thema im Detail durchgehen will, findet die Mechanik in der Analyse zu KI-Halluzinationen, Ursachen und Risiken. Quantisierung erhöht die Wahrscheinlichkeit, dass ein Modell knapp daneben antwortet, weil es genau die feinen Wahrscheinlichkeitsunterschiede verliert, die zwischen "knapp richtig" und "knapp falsch" entscheiden.
Das vierte Antipattern ist die unkritische Annahme, dass ein quantisiertes Modell auf einem Hardware-Stack genauso quantisiert auf einem anderen funktioniert. FP8 braucht passende Hardware-Unterstützung, etwa Hopper oder Ada Lovelace. INT8 läuft breiter, kostet aber je nach Stack mehr Genauigkeit oder Durchsatz. Activation-Outliers, die in der LLM.int8/SmoothQuant-Literatur als bis zu hundertmal größer als der Durchschnitt beschrieben werden, erschweren Aktivierungsquantisierung auf Karten ohne native Tensor-Core-Unterstützung. Eine Konfiguration, die auf einer H100 verlustfrei ist, kann auf einer A6000 messbare Drift erzeugen.
Zweite Ebene: Was sich in den nächsten 12 bis 24 Monaten ändert
Eine Folge ist nicht offensichtlich, aber wahrscheinlich.
Sie betrifft Open-Source-Modelle und ihre strategische Position gegenüber proprietären Modellen. Wenn die Flips-Metrik sich als Standard durchsetzt und Modelle nicht mehr nur über Accuracy, sondern über Verhaltensdistanz zur Referenz evaluiert werden, bekommen Open-Source-Modelle einen strukturellen Vorteil. Sie können in voller Präzision exakt geprüft, gegen ihre eigene quantisierte Version verglichen und mit gemessener Drift dokumentiert werden. Bei proprietären Modellen ist das nicht möglich, weil die Baseline nicht zugänglich ist. Eine Open-Source-Variante mit dokumentierter, kleiner Quantisierungsdrift ist dann für regulierte Anwendungen das ehrlichere Angebot, weil sie ihre Unschärfe ausweist statt sie zu verbergen. Das ist kein Marketing-Argument, sondern ein Compliance-Argument, und es wird im DACH-Raum bei Audits eine Rolle spielen, sobald die ersten KI-Verordnungs-Audits routinemäßig anlaufen.
Eine pragmatische Entscheidungsregel
Aus den drei Studien lässt sich eine knappe, brauchbare Entscheidungsregel destillieren.
- Moderne Hardware: FP8 (W8A8-FP), wenn die GPU es nativ unterstützt.
- Continuous-Batching: W8A8-INT, wenn der Durchsatzhebel wichtiger ist als maximale Nähe zur Baseline.
- Synchrone Workloads ohne FP8: W4A16-INT mit GPTQ und sauberer Kalibrierung.
- Long-Context oder nicht-englisch: mindestens INT8, idealerweise FP8; 4-Bit nur nach eigener Domain-Eval.
- Ollama / GGUF: Q6_K oder Q8_0 statt Q4_K_M, sobald RAM es erlaubt.
- Validierung: Domain-Eval mit eigenen Prompts plus Drift-Vergleich gegen die nächsthöhere Präzisionsstufe.
Das ist mehr Arbeit als der Standardreflex. Es ist auch die Disziplin, die lokale KI von einer Demo zu einem produktiven Werkzeug macht.
Was bedeutet "Flips" konkret, und warum reicht Accuracy nicht?
Flips messen, wie oft eine Antwort zwischen Basismodell und komprimierter Variante von korrekt zu falsch oder umgekehrt wechselt. Accuracy kann dabei fast gleich bleiben, weil sich richtige und falsche Wechsel im Aggregat aufheben. Das Modell wirkt gleich gut, antwortet aber merklich anders.
Ist Q4_K_M auf Ollama wirklich problematisch?
Im englischen Standard-Chat mit kurzen Kontexten ist Q4_K_M brauchbar. Bei längeren Kontexten, deutschen oder anderen nicht-englischen Inhalten und retrieval-lastigen Aufgaben driftet die Qualität stärker, als die populäre Empfehlung "passt schon" suggeriert. Wenn der RAM es zulässt, ist Q5_K_M oder Q6_K die ehrlichere Wahl.
Welche Quantisierung ist für lokale Produktiv-Inferenz empfehlenswert?
Auf Hopper- oder Ada-Lovelace-Hardware FP8 als Default, weil die Studienlage es als praktisch verlustfrei ausweist. Bei reinen Gewichtsquantisierungen W4A16 mit GPTQ und ordentlicher Kalibrierung. Bei Continuous-Batching-Servern W8A8-INT für Durchsatz. BNB-nf4 nur, wenn andere Optionen nicht möglich sind, und nie für Long-Context oder mehrsprachig.
Was bleibt
Lokale KI funktioniert besser, als die Skeptiker behaupten, und verliert weniger, als die naive Sicht annimmt. Aber sie verliert nicht nichts. FP8 ist nahezu kostenfrei, INT8 kostet wenig, W4A16 kostet vertretbar, BNB-nf4 kostet mehr als kommuniziert. Bei Long-Context oder nicht-englischen Sprachen können 4-Bit-Methoden trotzdem plötzlich sehr viel kosten.
Der nützlichste Begriff dafür bleibt Flips. Benchmark-Accuracy zeigt, ob die Summe der richtigen Antworten stabil bleibt. Flips zeigen, ob das Modell auf konkrete Fragen anders antwortet. Wer lokale KI ernsthaft betreibt, misst deshalb Verhalten, nicht nur Score.
Lokal plus die richtige Quantisierung ist die eigentliche Disziplin. Nicht ob das Modell läuft, sondern ob es verlässlich genug läuft, entscheidet über den Unterschied zwischen Bastelei und Werkzeug.
Lokale KI wird erst dann ernsthaft, wenn Quantisierung nicht als Download-Default behandelt wird. Wer die Unterschiede versteht, holt aus seiner Hardware mehr Qualität heraus; wer sie ignoriert, verschenkt genau den Spielraum, den lokale Kontrolle eigentlich eröffnen sollte.
FP4 auf Blackwell und was NVFP4 für lokale KI konkret ändert, behandle ich separat. Das ist kein Nebensatz dieses Artikels, sondern die nächste Quantisierungsfrage.
- →Dutta et al., "Accuracy is Not All You Need", arXiv 2407.09141 (Microsoft Research)
- →Kurtic et al., "Give Me BF16 or Give Me Death? Accuracy-Performance Trade-Offs in LLM Quantization", arXiv 2411.02355
- →Long-Context- und Multilingual-Quantisierungsstudie auf Llama-3.1 und Qwen-2.5, arXiv 2505.20276
- →vLLM-Dokumentation: Quantisierungs-Backends und Supported Hardware (FP8, INT8, W4A16, GPTQ, AWQ)
- →llama.cpp Quantisierungsoptionen, K-Quants (Q4_K_M, Q5_K_M, Q6_K, Q8_0)
- →Lambda Labs GPU-Cloud-Preisreferenz (A6000, A100, H100)