Quantisierung ohne Qualitätsverlust: int4, int8, AWQ, GPTQ, GGUF entzaubert

Der Freitagabend-Anruf: Das Modell passt nicht mehr

Es ist Freitagabend, und ein Entwickler eines Zürcher Fintech-Startups schickt eine Nachricht in den Team-Chat: CUDA out of memory. Das 70B-Modell läuft nicht mehr auf der einen H100. Ein Kollege liefert ein neues Feature aus, das mehr Kontext braucht, der KV-Cache frisst zusätzliches VRAM, und plötzlich reicht der Speicher nicht mehr. Die naheliegende Antwort wäre eine zweite GPU: teuer, und am Freitagabend nicht in zwei Stunden beschafft. Also schlägt jemand vor: Quantisier das Ding doch einfach auf int4. Stille im Chat. Die Sorge ist verständlich, schliesslich klingt Modellgewichte komprimieren erstmal nach einem Kompromiss, den man später bereut. Zwei Stunden später läuft das AWQ-quantisierte Modell auf derselben Karte, die Antworten sind in den Stichproben praktisch nicht von den fp16-Antworten zu unterscheiden, und der Freitagabend ist gerettet. Genau diese Geschichte spielt sich in Schweizer Engineering-Teams ständig ab, und das Erstaunliche ist: Quantisierung ist heute selten der Kompromiss, den alle fürchten. Sie ist meistens einfach die richtige Standardentscheidung. Aber meistens ist nicht immer, und genau da wird es interessant.

Was in den Bits eigentlich passiert

Ein Sprachmodell besteht aus Milliarden Parametern, und jeder davon ist eine Zahl. Im Training werden diese Zahlen typischerweise als fp16 oder bf16 gespeichert: 16 Bit pro Gewicht. Quantisierung heisst schlicht: Du drückst diese Zahlen in ein gröberes Zahlenformat, meistens int8 (8 Bit) oder int4 (4 Bit), und akzeptierst dabei einen gewissen Rundungsfehler pro Gewicht. Der Effekt ist zunächst rein arithmetisch: Ein 70-Milliarden-Parameter-Modell braucht in fp16 rund 140 GB VRAM, in int8 noch etwa 70 GB, in int4 nur noch rund 35 GB. Das ist der Unterschied zwischen passt auf keine einzelne Consumer- oder Prosumer-GPU und läuft komfortabel auf einer einzelnen Karte.

Weniger offensichtlich, aber mindestens so wichtig: Quantisierung macht Inferenz auch schneller, nicht nur speichersparender. Der Grund liegt darin, dass die Textgenerierung (der Decode-Schritt, bei dem ein Token nach dem anderen erzeugt wird) auf modernen GPUs praktisch immer bandbreitenlimitiert ist, nicht rechenlimitiert. Für jedes einzelne Token muss die GPU sämtliche Modellgewichte aus dem HBM-Speicher lesen. Bei einer H100 mit rund 3,35 TB/s Speicherbandbreite ist genau dieses Lesen der Flaschenhals, nicht die Matrixmultiplikation selbst. Halbierst du die Bitbreite der Gewichte, halbierst du auch die Datenmenge, die pro Token durch den Speicherbus muss, und der Durchsatz steigt entsprechend. Das ist der Grund, warum ein int4-quantisiertes Modell auf identischer Hardware nicht nur weniger Platz braucht, sondern auch spürbar mehr Tokens pro Sekunde liefert. Wer eigene Bare-Metal-GPUs betreibt, merkt diesen Effekt direkt an der Rechnung: mehr Durchsatz pro Karte heisst weniger Karten für dieselbe Last.

GPTQ, AWQ, GGUF, bitsandbytes: wer für wen

Hier beginnt die Verwirrung, denn die Formate klingen alle ähnlich kryptisch, lösen aber unterschiedliche Probleme. GPTQ und AWQ sind beides Post-Training-Quantisierungsverfahren, die mit einem kleinen Kalibrierungsdatensatz arbeiten: Sie schauen sich an, welche Gewichte für die tatsächliche Modellausgabe besonders wichtig sind, und runden diese vorsichtiger als unwichtige Gewichte. AWQ (Activation-aware Weight Quantization) geht dabei noch gezielter vor, indem es die Aktivierungsgrössen einbezieht statt nur die Gewichte selbst zu betrachten. In der Praxis liefert AWQ bei vergleichbarer Bitbreite meist die stabileren Ergebnisse. Beide sind für GPU-Server-Inferenz gebaut und laufen gut mit vLLM, das mittlerweile die naheliegende Wahl für produktive Bedienung ist, wie wir im Vergleich von vLLM, Ollama und TGI im Detail zeigen.

GGUF stammt aus dem llama.cpp-Ökosystem und verfolgt ein anderes Ziel: maximale Portabilität. Es läuft auf CPU, auf Apple-Silicon-Metal-Beschleunigung und auf GPUs, oft sogar gemischt: ein Teil der Layer auf der Grafikkarte, der Rest auf der CPU, wenn der VRAM knapp ist. GGUF bietet zudem eine ganze Palette an Abstufungen wie Q4KM, Q5KS oder Q80, die nicht einfach 4 Bit oder 8 Bit bedeuten, sondern gemischte Präzisionsschemata sind: wichtige Layer bekommen mehr Bits, unwichtige weniger. Genau das macht Q4K_M zu einem der stabilsten Kompromisse im gesamten Quantisierungs-Zoo. Wer lokal experimentiert oder auf Geräten wie dem DGX Spark arbeitet, landet fast automatisch bei GGUF, weil dort Flexibilität wichtiger ist als der letzte Prozentpunkt Durchsatz.

bitsandbytes schliesslich ist der pragmatische Blitzstart: Es quantisiert on-the-fly beim Laden des Modells, ohne separaten Kalibrierungsschritt und ohne vorquantisierte Checkpoints. Das ist bequem für schnelle Experimente, aber spürbar langsamer als AWQ oder GPTQ im Produktivbetrieb, weil die Quantisierung nicht vorab optimiert wurde. Die Faustregel, die sich in der Praxis bewährt hat: AWQ oder GPTQ für Server-GPU-Inferenz mit hohem Durchsatz, GGUF für lokale oder gemischte Umgebungen, bitsandbytes nur für schnelle Prototypen.

Der nüchterne Qualitätsabfall (mit Zahlen)

Jetzt zum Teil, den Marketingfolien gerne überspringen. int8 ist in praktisch allen seriösen Messungen quasi verlustfrei: Die Perplexity-Verschlechterung liegt typischerweise im Bereich von einem Zehntel bis wenigen Zehntelprozent, also unterhalb dessen, was du in einer Konversation überhaupt bemerken würdest. Bei int8 gibt es kaum noch einen Grund, zu zögern, ausser du hast wirklich jedes letzte Gigabyte VRAM nötig.

Bei int4 wird es differenzierter, und genau hier trennt sich die seriöse von der unseriösen Darstellung. Mit guten Verfahren (AWQ, GPTQ oder GGUF-Q4KM) ist der Qualitätsabfall bei den meisten alltäglichen Aufgaben kaum spürbar, oft im Bereich von ein bis zwei Prozentpunkten auf Standard-Benchmarks. Aber kaum spürbar bei den meisten Aufgaben heisst nicht nie spürbar. Bei anspruchsvollem mehrstufigem Reasoning, bei Code-Generierung mit komplexer Logik, bei Mathematik-Aufgaben und bei langen Antwortketten zeigt sich der Unterschied deutlicher: Die Fehlerrate steigt messbar, auch wenn ein einzelner Blick auf eine einzelne Antwort das nicht verrät. Unterhalb von int4, also bei int3 oder gar int2, kippt die Kurve: Der Qualitätsabfall wird steil statt allmählich, und für die meisten praktischen Anwendungen lohnt sich dieser letzte Bitbreite-Schritt nicht mehr. Die Ersparnis an VRAM ist real, aber der Preis in Zuverlässigkeit übersteigt in unserer Erfahrung fast immer den Nutzen, ausser in sehr spezifischen Nischenfällen mit extremem Speicherdruck.

Wann es dir egal ist und wann es dich killt

Die nüchterne Antwort lautet: Es kommt fast ausschliesslich auf die Aufgabe an, nicht auf das Modell. Für einen grossen Teil der produktiven Anwendungen ist der Unterschied zwischen fp16 und einem gut quantisierten int4-Modell in der Praxis nicht der entscheidende Faktor:

• Chat und allgemeine Konversation: Die Nutzer merken den Unterschied so gut wie nie.
• Zusammenfassungen von Dokumenten oder Meetings: Die Kernaussagen bleiben stabil.
• Klassifikation von Text, Tickets oder E-Mails in feste Kategorien: Hier zählt vor allem die Trainingsqualität, nicht die letzte Nachkommastelle der Gewichte.
• RAG-Antworten, bei denen das Modell primär den bereitgestellten Kontext zusammenfasst statt eigenständig komplex zu schlussfolgern.

Andere Aufgaben reagieren dagegen empfindlich, und genau dort solltest du vorsichtig sein: präzises mehrstufiges Reasoning, Code-Generierung mit vielen Abhängigkeiten, die Genauigkeit von Funktionsaufrufen (Tool- und Function-Calling) und vor allem lange agentische Ketten. Bei Letzterem multiplizieren sich Fehler auf eine Weise, die man leicht unterschätzt: Wenn ein Modell bei jedem einzelnen Schritt einer Kette mit 99 statt 98 Prozent Wahrscheinlichkeit richtig liegt, ist der Unterschied bei einem einzelnen Schritt vernachlässigbar, aber über zwanzig aufeinanderfolgende Agenten-Schritte hinweg wird aus dieser kleinen Differenz ein massiver Unterschied in der Erfolgsrate der gesamten Kette. Genau deshalb lohnt es sich, bei agentischen Workflows und Function-Calling-lastigen Systemen entweder auf int8 zu bleiben oder int4 besonders sorgfältig zu testen, bevor du es produktiv einsetzt.

Die Faustregel: grösser und komprimiert schlägt oft kleiner und makellos

Hier kommt die vielleicht wichtigste praktische Erkenntnis, die in kaum einem Marketing-Deck auftaucht: Bei gleichem VRAM-Budget schlägt ein grösseres Modell in int4 sehr häufig ein kleineres Modell in fp16. Ein 70B-Modell in int4 passt ungefähr in denselben Speicher wie ein 17-18B-Modell in fp16, aber das grössere, quantisierte Modell hat in der Regel mehr Weltwissen, bessere Reasoning-Fähigkeiten und robusteres Verhalten bei Randfällen aufgebaut, weil es schlicht mit mehr Kapazität trainiert wurde. Der Rundungsfehler der Quantisierung wiegt in den meisten Fällen weniger schwer als der Kapazitätsverlust eines kleineren Modells. Das ist keine Ausnahme, sondern mittlerweile fast schon die Regel, und ein guter Grund, bei der Auswahl offener Modelle nicht am kleinsten Modell zu sparen, sondern lieber ein grösseres, gut quantisiertes Modell zu wählen.

Aber (und das ist der Teil, den wir bei twentyone.ch nicht müde werden zu betonen) diese Faustregel gilt im Schnitt über viele Benchmarks, nicht garantiert für deinen konkreten Anwendungsfall. Öffentliche Benchmarks sind Durchschnittswerte über breite Aufgabenspektren. Dein Produkt ist kein Durchschnitt. Wenn dein Anwendungsfall eine sehr spezifische Domäne betrifft (etwa juristische Vertragsprüfung, medizinische Kodierung oder ein enges technisches Fachgebiet), kann die Quantisierung dort anders wirken als im allgemeinen Benchmark-Mittel. Genau deshalb ist ich habe im Benchmark gelesen, dass int4 nur 1 Prozent verliert kein Ersatz für eigene Tests.

Teste selbst, vertraue keinem Benchmark blind

Quantisierung ist keine Blackbox, vor der du dich fürchten musst, und sie ist auch kein Freifahrtschein, den du unreflektiert überall einsetzt. Sie ist ein Ingenieurstrade-off mit klaren, messbaren Grenzen: int8 fast immer sicher, int4 mit guten Verfahren für die meisten Aufgaben solide, alles darunter selten den Aufwand wert. Die einzige verlässliche Methode, um herauszufinden, ob dein konkretes Modell mit deiner konkreten Quantisierungsstufe für deinen konkreten Anwendungsfall funktioniert, ist eine kleine, selbst gebaute Eval-Suite mit echten Beispielen aus deinem Produkt, nicht MMLU-Zahlen aus einem Modell-Card, nicht Marketingfolien, nicht die Meinung eines Twitter-Threads. Fünfzig bis hundert reale Fälle, die deine kritischsten Aufgaben abdecken, mit und ohne Quantisierung durchgerechnet, verraten dir in wenigen Stunden mehr als jeder öffentliche Leaderboard-Vergleich. Wer dabei unsicher ist, wie man Kosten, Hardware und Modellwahl sauber gegeneinander abwägt, findet in unserem Artikel zu den Kosten des selbst betriebenen LLM-Betriebs eine gute Ausgangsbasis für die Rechnung.

Wenn du das nicht selbst durchtesten willst oder deinem Team schlicht die Zeit dafür fehlt: Genau dafür gibt es Managed Inference bei twentyone.ch. Wir wählen mit dir gemeinsam die passende Quantisierungsstufe für deinen Use-Case, betreiben sie auf souveräner Schweizer Infrastruktur und sagen dir offen, wenn eine niedrigere Präzision für deinen Fall eben doch nicht reicht.