[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"reazon-page-\u002Fde\u002Fwissen\u002Fquantisierung-int4-int8-awq-gptq-gguf":3,"reazon-angebot-subnav":30,"reazon-mainnav":31,"reazon-footernav":41,"reazon-offering-angebot-zielgruppen":65,"reazon-articles-\u002Fde\u002Fwissen":66,"reazon-offering-angebot-leistungen":191},{"data":4},{"id":5,"path":6,"slug":7,"published_at":8,"page_type":9,"no_index":12,"fields":13,"blocks":29},1446,"\u002Fde\u002Fwissen\u002Fquantisierung-int4-int8-awq-gptq-gguf","quantisierung-int4-int8-awq-gptq-gguf","2026-07-07T12:12:01.067Z",{"identifier":10,"name":11},"article","Blog Post",false,{"title":14,"summary":15,"publication_date":16,"big5_category":17,"primary_service":18,"meta_title":25,"meta_description":26,"body":27,"body_html":28},"Quantisierung ohne Qualitätsverlust: int4, int8, AWQ, GPTQ, GGUF entzaubert","int8 ist fast immer verlustfrei, int4 meistens auch, aber nicht bei Reasoning, Code und langen Agenten-Ketten. Wir zeigen dir ungeschönt, was Quantisierung wirklich kostet und wo GPTQ, AWQ, GGUF und bitsandbytes hingehören.","2026-07-07T00:00:00Z","problems",{"id":19,"slug":20,"path":21,"page_type":22,"published":23,"type":24},676,"managed-inference","\u002Fde\u002Fmanaged-inference","service",true,"Cms::Page","Quantisierung entzaubert: int4, int8, AWQ, GPTQ, GGUF | Twentyone","int8 ist fast immer verlustfrei, int4 meistens auch, aber nicht bei Reasoning, Code und langen Agenten-Ketten. Ein nüchterner Blick auf GPTQ, AWQ, GGUF und bitsandbytes.","## Der Freitagabend-Anruf: \"Das Modell passt nicht mehr\"\n\nEs 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.\n\n## Was in den Bits eigentlich passiert\n\nEin 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\".\n\nWeniger 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\u002Fs 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](\u002Fde\u002Fbare-metal) betreibt, merkt diesen Effekt direkt an der Rechnung: mehr Durchsatz pro Karte heisst weniger Karten für dieselbe Last.\n\n## GPTQ, AWQ, GGUF, bitsandbytes: wer für wen\n\nHier 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](\u002Fde\u002Fwissen\u002Fvllm-ollama-tgi-vergleich) im Detail zeigen.\n\n**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 Q4_K_M, Q5_K_S oder Q8_0, die nicht einfach \"4 Bit\" oder \"8 Bit\" bedeuten, sondern gemischte Präzisionsschemata sind: wichtige Layer bekommen mehr Bits, unwichtige weniger. Genau das macht Q4_K_M zu einem der stabilsten Kompromisse im gesamten Quantisierungs-Zoo. Wer lokal experimentiert oder auf Geräten wie dem [DGX Spark](\u002Fde\u002Fdgx-spark) arbeitet, landet fast automatisch bei GGUF, weil dort Flexibilität wichtiger ist als der letzte Prozentpunkt Durchsatz.\n\n**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.**\n\n## Der nüchterne Qualitätsabfall (mit Zahlen)\n\nJetzt 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.\n\nBei int4 wird es differenzierter, und genau hier trennt sich die seriöse von der unseriösen Darstellung. **Mit guten Verfahren (AWQ, GPTQ oder GGUF-Q4_K_M) 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.\n\n## Wann es dir egal ist und wann es dich killt\n\nDie 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:\n\n- **Chat und allgemeine Konversation**: Die Nutzer merken den Unterschied so gut wie nie.\n- **Zusammenfassungen** von Dokumenten oder Meetings: Die Kernaussagen bleiben stabil.\n- **Klassifikation** von Text, Tickets oder E-Mails in feste Kategorien: Hier zählt vor allem die Trainingsqualität, nicht die letzte Nachkommastelle der Gewichte.\n- **RAG-Antworten**, bei denen das Modell primär den bereitgestellten Kontext zusammenfasst statt eigenständig komplex zu schlussfolgern.\n\nAndere 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.\n\n## Die Faustregel: grösser und komprimiert schlägt oft kleiner und makellos\n\nHier 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](\u002Fde\u002Fwissen\u002Foffene-modelle-auswahl) nicht am kleinsten Modell zu sparen, sondern lieber ein grösseres, gut quantisiertes Modell zu wählen.\n\nAber (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.\n\n## Teste selbst, vertraue keinem Benchmark blind\n\nQuantisierung 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](\u002Fde\u002Fwissen\u002Fllm-selbst-betreiben-kosten) eine gute Ausgangsbasis für die Rechnung.\n\nWenn du das nicht selbst durchtesten willst oder deinem Team schlicht die Zeit dafür fehlt: Genau dafür gibt es [Managed Inference](\u002Fde\u002Fmanaged-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.","\u003Ch2>Der Freitagabend-Anruf: \u003Cq>Das Modell passt nicht mehr\u003C\u002Fq>\u003C\u002Fh2>\n\n\u003Cp>Es ist Freitagabend, und ein Entwickler eines Zürcher Fintech-Startups schickt eine Nachricht in den Team-Chat: \u003Cq>CUDA out of memory. Das 70B-Modell läuft nicht mehr auf der einen H100.\u003C\u002Fq> 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: \u003Cq>Quantisier das Ding doch einfach auf int4.\u003C\u002Fq> Stille im Chat. Die Sorge ist verständlich, schliesslich klingt \u003Cq>Modellgewichte komprimieren\u003C\u002Fq> 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: \u003Cstrong>Quantisierung ist heute selten der Kompromiss, den alle fürchten.\u003C\u002Fstrong> Sie ist meistens einfach die richtige Standardentscheidung. Aber \u003Cq>meistens\u003C\u002Fq> ist nicht \u003Cq>immer\u003C\u002Fq>, und genau da wird es interessant.\u003C\u002Fp>\n\n\u003Ch2>Was in den Bits eigentlich passiert\u003C\u002Fh2>\n\n\u003Cp>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: \u003Cstrong>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.\u003C\u002Fstrong> Das ist der Unterschied zwischen \u003Cq>passt auf keine einzelne Consumer- oder Prosumer-GPU\u003C\u002Fq> und \u003Cq>läuft komfortabel auf einer einzelnen Karte\u003C\u002Fq>.\u003C\u002Fp>\n\n\u003Cp>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\u002Fs Speicherbandbreite ist genau dieses Lesen der Flaschenhals, nicht die Matrixmultiplikation selbst. \u003Cstrong>Halbierst du die Bitbreite der Gewichte, halbierst du auch die Datenmenge, die pro Token durch den Speicherbus muss, und der Durchsatz steigt entsprechend.\u003C\u002Fstrong> 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 \u003Ca href=\"\u002Fde\u002Fbare-metal\">Bare-Metal-GPUs\u003C\u002Fa> betreibt, merkt diesen Effekt direkt an der Rechnung: mehr Durchsatz pro Karte heisst weniger Karten für dieselbe Last.\u003C\u002Fp>\n\n\u003Ch2>GPTQ, AWQ, GGUF, bitsandbytes: wer für wen\u003C\u002Fh2>\n\n\u003Cp>Hier beginnt die Verwirrung, denn die Formate klingen alle ähnlich kryptisch, lösen aber unterschiedliche Probleme. \u003Cstrong>GPTQ und AWQ sind beides Post-Training-Quantisierungsverfahren\u003C\u002Fstrong>, 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 \u003Ca href=\"\u002Fde\u002Fwissen\u002Fvllm-ollama-tgi-vergleich\">Vergleich von vLLM, Ollama und TGI\u003C\u002Fa> im Detail zeigen.\u003C\u002Fp>\n\n\u003Cp>\u003Cstrong>GGUF stammt aus dem llama.cpp-Ökosystem und verfolgt ein anderes Ziel: maximale Portabilität.\u003C\u002Fstrong> 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 Q4\u003Cu>K\u003C\u002Fu>M, Q5\u003Cu>K\u003C\u002Fu>S oder Q8\u003Cu>0, die nicht einfach \u003Cq>4 Bit\u003C\u002Fq> oder \u003Cq>8 Bit\u003C\u002Fq> bedeuten, sondern gemischte Präzisionsschemata sind: wichtige Layer bekommen mehr Bits, unwichtige weniger. Genau das macht Q4\u003C\u002Fu>K_M zu einem der stabilsten Kompromisse im gesamten Quantisierungs-Zoo. Wer lokal experimentiert oder auf Geräten wie dem \u003Ca href=\"\u002Fde\u002Fdgx-spark\">DGX Spark\u003C\u002Fa> arbeitet, landet fast automatisch bei GGUF, weil dort Flexibilität wichtiger ist als der letzte Prozentpunkt Durchsatz.\u003C\u002Fp>\n\n\u003Cp>\u003Cstrong>bitsandbytes\u003C\u002Fstrong> 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: \u003Cstrong>AWQ oder GPTQ für Server-GPU-Inferenz mit hohem Durchsatz, GGUF für lokale oder gemischte Umgebungen, bitsandbytes nur für schnelle Prototypen.\u003C\u002Fstrong>\u003C\u002Fp>\n\n\u003Ch2>Der nüchterne Qualitätsabfall (mit Zahlen)\u003C\u002Fh2>\n\n\u003Cp>Jetzt zum Teil, den Marketingfolien gerne überspringen. \u003Cstrong>int8 ist in praktisch allen seriösen Messungen quasi verlustfrei\u003C\u002Fstrong>: 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.\u003C\u002Fp>\n\n\u003Cp>Bei int4 wird es differenzierter, und genau hier trennt sich die seriöse von der unseriösen Darstellung. \u003Cstrong>Mit guten Verfahren (AWQ, GPTQ oder GGUF-Q4\u003Cu>K\u003C\u002Fu>M) ist der Qualitätsabfall bei den meisten alltäglichen Aufgaben kaum spürbar\u003C\u002Fstrong>, oft im Bereich von ein bis zwei Prozentpunkten auf Standard-Benchmarks. Aber \u003Cq>kaum spürbar bei den meisten Aufgaben\u003C\u002Fq> heisst nicht \u003Cq>nie spürbar\u003C\u002Fq>. 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: \u003Cstrong>Der Qualitätsabfall wird steil statt allmählich, und für die meisten praktischen Anwendungen lohnt sich dieser letzte Bitbreite-Schritt nicht mehr.\u003C\u002Fstrong> 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.\u003C\u002Fp>\n\n\u003Ch2>Wann es dir egal ist und wann es dich killt\u003C\u002Fh2>\n\n\u003Cp>Die nüchterne Antwort lautet: \u003Cstrong>Es kommt fast ausschliesslich auf die Aufgabe an, nicht auf das Modell.\u003C\u002Fstrong> 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:\u003C\u002Fp>\n\n\u003Cul>\n\u003Cli>\u003Cstrong>Chat und allgemeine Konversation\u003C\u002Fstrong>: Die Nutzer merken den Unterschied so gut wie nie.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Zusammenfassungen\u003C\u002Fstrong> von Dokumenten oder Meetings: Die Kernaussagen bleiben stabil.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Klassifikation\u003C\u002Fstrong> von Text, Tickets oder E-Mails in feste Kategorien: Hier zählt vor allem die Trainingsqualität, nicht die letzte Nachkommastelle der Gewichte.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>RAG-Antworten\u003C\u002Fstrong>, bei denen das Modell primär den bereitgestellten Kontext zusammenfasst statt eigenständig komplex zu schlussfolgern.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>Andere Aufgaben reagieren dagegen empfindlich, und genau dort solltest du vorsichtig sein: \u003Cstrong>präzises mehrstufiges Reasoning, Code-Generierung mit vielen Abhängigkeiten, die Genauigkeit von Funktionsaufrufen (Tool- und Function-Calling) und vor allem lange agentische Ketten.\u003C\u002Fstrong> 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.\u003C\u002Fp>\n\n\u003Ch2>Die Faustregel: grösser und komprimiert schlägt oft kleiner und makellos\u003C\u002Fh2>\n\n\u003Cp>Hier kommt die vielleicht wichtigste praktische Erkenntnis, die in kaum einem Marketing-Deck auftaucht: \u003Cstrong>Bei gleichem VRAM-Budget schlägt ein grösseres Modell in int4 sehr häufig ein kleineres Modell in fp16.\u003C\u002Fstrong> 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 \u003Ca href=\"\u002Fde\u002Fwissen\u002Foffene-modelle-auswahl\">Auswahl offener Modelle\u003C\u002Fa> nicht am kleinsten Modell zu sparen, sondern lieber ein grösseres, gut quantisiertes Modell zu wählen.\u003C\u002Fp>\n\n\u003Cp>Aber (und das ist der Teil, den wir bei twentyone.ch nicht müde werden zu betonen) \u003Cstrong>diese Faustregel gilt \u003Cq>im Schnitt über viele Benchmarks\u003C\u002Fq>, nicht garantiert für deinen konkreten Anwendungsfall.\u003C\u002Fstrong> Ö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 \u003Cq>ich habe im Benchmark gelesen, dass int4 nur 1 Prozent verliert\u003C\u002Fq> kein Ersatz für eigene Tests.\u003C\u002Fp>\n\n\u003Ch2>Teste selbst, vertraue keinem Benchmark blind\u003C\u002Fh2>\n\n\u003Cp>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. \u003Cstrong>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\u003C\u002Fstrong>, 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 \u003Ca href=\"\u002Fde\u002Fwissen\u002Fllm-selbst-betreiben-kosten\">Kosten des selbst betriebenen LLM-Betriebs\u003C\u002Fa> eine gute Ausgangsbasis für die Rechnung.\u003C\u002Fp>\n\n\u003Cp>Wenn du das nicht selbst durchtesten willst oder deinem Team schlicht die Zeit dafür fehlt: Genau dafür gibt es \u003Ca href=\"\u002Fde\u002Fmanaged-inference\">Managed Inference\u003C\u002Fa> 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.\u003C\u002Fp>\n",[],[],[32,35,38],{"title":33,"href":34},"Preise","\u002Fde\u002Fpreise",{"title":36,"href":37},"Wissen","\u002Fde\u002Fwissen",{"title":39,"href":40},"Über Twentyone","\u002Fde\u002Fueber-uns",[42,56],{"title":43,"links":44},"Leistungen",[45,48,51,53],{"title":46,"href":47},"DGX Spark mieten","\u002Fde\u002Fdgx-spark",{"title":49,"href":50},"Bare Metal GPU","\u002Fde\u002Fbare-metal",{"title":52,"href":21},"Managed Inference",{"title":54,"href":55},"Hermes Agents","\u002Fde\u002Fagents",{"title":57,"links":58},"Unternehmen",[59,60,61,62],{"title":39,"href":40},{"title":36,"href":37},{"title":33,"href":34},{"title":63,"href":64},"Kontakt","\u002Fde\u002Fkontakt",[],[67,77,89,99,106,114,120,127,129,135,141,148,154,160,166,172,178,185],{"path":68,"slug":69,"title":70,"summary":71,"image":72,"publication_date":73,"big5_category":74,"primary_hub":72,"cluster":72,"pillar":72,"hubs":75},"\u002Fde\u002Fwissen\u002Fazure-openai-bedrock-alternative-schweiz","azure-openai-bedrock-alternative-schweiz","Souveräne Inferenz gegen Azure OpenAI und AWS Bedrock: was sich im Alltag ändert","Azure OpenAI und AWS Bedrock gegen einen souverän betriebenen Endpoint: warum der Schweizer Serverstandort der Hyperscaler das Kernproblem nicht löst und was der Unterschied im Betrieb bedeutet.",null,"2026-07-13T00:00:00Z","comparisons",[76],{"slug":20,"title":52},{"path":78,"slug":79,"title":80,"summary":81,"image":72,"publication_date":73,"big5_category":82,"primary_hub":72,"cluster":72,"pillar":72,"hubs":83},"\u002Fde\u002Fwissen\u002Fbeste-gpu-llm-inferenz","beste-gpu-llm-inferenz","Die beste GPU für LLM-Inferenz: DGX Spark, H100, L40S und RTX im Vergleich","Welche GPU für eigene Inferenz? DGX Spark, H100, L40S und RTX 4090 nach dem, was zählt: wie viel Modell hineinpasst, wie viel Durchsatz herauskommt und was der Monat kostet.","bestof",[84,87],{"slug":85,"title":86},"bare-metal","Bare Metal GPU mit Root-Zugriff",{"slug":88,"title":46},"dgx-spark",{"path":90,"slug":91,"title":92,"summary":93,"image":72,"publication_date":73,"big5_category":94,"primary_hub":72,"cluster":72,"pillar":72,"hubs":95},"\u002Fde\u002Fwissen\u002Fhermes-agent-erfahrungsbericht","hermes-agent-erfahrungsbericht","Hermes-Agent im Realbetrieb: was ein souveräner Agent wirklich leistet","Ein Erfahrungsbericht statt Hochglanzprospekt: wie sich ein souverän betriebener Hermes-Agent im täglichen Einsatz verhält, wo er glänzt und wo die Begleitung anfängt.","reviews",[96],{"slug":97,"title":98},"agents","Hermes Agents as a Service",{"path":100,"slug":101,"title":102,"summary":103,"image":72,"publication_date":73,"big5_category":17,"primary_hub":72,"cluster":72,"pillar":72,"hubs":104},"\u002Fde\u002Fwissen\u002Fki-regulierte-daten-schweiz","ki-regulierte-daten-schweiz","KI mit regulierten Daten: LLMs nutzen, ohne dass die Daten die Schweiz verlassen","Für Branchen, in denen Daten das Land nicht verlassen dürfen: was revDSG, Berufsgeheimnis und der CLOUD Act für KI-Projekte bedeuten, und wie souveräne Inferenz den Rahmen einhält.",[105],{"slug":20,"title":52},{"path":107,"slug":108,"title":109,"summary":110,"image":72,"publication_date":73,"big5_category":111,"primary_hub":72,"cluster":72,"pillar":72,"hubs":112},"\u002Fde\u002Fwissen\u002Fopenai-api-kosten-vs-eigener-endpoint","openai-api-kosten-vs-eigener-endpoint","Ab welchem Volumen sich ein eigener Endpoint gegen die API rechnet","Die Pay-per-Token-API ist günstig, bis sie es nicht mehr ist. Wo genau der Break-even zu einem reservierten Endpoint mit fester Monatspauschale liegt, an einem konkreten Beispiel durchgerechnet.","cost",[113],{"slug":20,"title":52},{"path":115,"slug":116,"title":117,"summary":118,"image":72,"publication_date":16,"big5_category":74,"primary_hub":72,"cluster":72,"pillar":72,"hubs":119},"\u002Fde\u002Fwissen\u002Ffine-tuning-rag-prompt","fine-tuning-rag-prompt","Fine-Tuning, RAG oder besserer Prompt? Die klare Entscheidungsregel","Fine-Tuning ist meistens nicht die Antwort auf „das Modell kennt unsere Daten nicht“. Wann Prompting, RAG oder Fine-Tuning wirklich das richtige Werkzeug sind und wie du die Eskalationsleiter korrekt durchläufst.",[],{"path":121,"slug":122,"title":123,"summary":124,"image":72,"publication_date":16,"big5_category":125,"primary_hub":72,"cluster":72,"pillar":72,"hubs":126},"\u002Fde\u002Fwissen\u002Fopenai-api-migration","openai-api-migration","Von der OpenAI-API zu souveräner Inferenz: die Migration in der Praxis","Der Umstieg von OpenAI oder Anthropic auf ein selbst betriebenes offenes Modell in der Schweiz sieht dank OpenAI-kompatibler Endpoints nach einer Ein-Zeilen-Änderung aus, ist aber doch mehr. Wo Prompts, Tool-Calling und Feature-Lücken zur Stolperfalle werden.","how-to",[],{"path":6,"slug":7,"title":14,"summary":15,"image":72,"publication_date":16,"big5_category":17,"primary_hub":72,"cluster":72,"pillar":72,"hubs":128},[],{"path":130,"slug":131,"title":132,"summary":133,"image":72,"publication_date":16,"big5_category":17,"primary_hub":72,"cluster":72,"pillar":72,"hubs":134},"\u002Fde\u002Fwissen\u002Frag-schlechte-antworten","rag-schlechte-antworten","RAG richtig gebaut: warum eure Wissensbasis schlechte Antworten gibt","Die meisten RAG-Systeme scheitern nicht am Sprachmodell, sondern am Retrieval davor. Wir zeigen die häufigsten Fehlerquellen bei Chunking, Embeddings und Retrieval-Strategie sowie, wie du Retrieval- und Generationsfehler sauber auseinanderhältst.",[],{"path":136,"slug":137,"title":138,"summary":139,"image":72,"publication_date":16,"big5_category":125,"primary_hub":72,"cluster":72,"pillar":72,"hubs":140},"\u002Fde\u002Fwissen\u002Fvram-modell-gpu-berechnen","vram-modell-gpu-berechnen","Welches Modell passt auf welche GPU? VRAM richtig berechnen","Bevor du GPUs kaufst oder mietest: die Faustformel für Gewichte, KV-Cache und Overhead, damit du weisst, welches Modell wirklich auf deine Hardware passt.",[],{"path":142,"slug":143,"title":144,"summary":145,"image":72,"publication_date":146,"big5_category":17,"primary_hub":72,"cluster":72,"pillar":72,"hubs":147},"\u002Fde\u002Fwissen\u002Fagent-oder-endpoint","agent-oder-endpoint","Braucht ihr wirklich einen Agent oder reicht ein Endpoint?","Agenten sind im Trend, aber oft die teurere und fragilere Lösung für ein Problem, das ein einfacher Endpoint löst. Wann sich der Aufwand lohnt und wann nicht.","2026-06-30T00:00:00Z",[],{"path":149,"slug":150,"title":151,"summary":152,"image":72,"publication_date":146,"big5_category":17,"primary_hub":72,"cluster":72,"pillar":72,"hubs":153},"\u002Fde\u002Fwissen\u002Fdatenhoheit-was-bedeutet-das","datenhoheit-was-bedeutet-das","Was Datenhoheit konkret heisst und wo deine Prompts wirklich landen","Datenhoheit ist mehr als ein Hosting-Standort. Was rechtlich, technisch und vertraglich dahintersteckt, und welche Fragen du jedem AI-Anbieter stellen solltest.",[],{"path":155,"slug":156,"title":157,"summary":158,"image":72,"publication_date":146,"big5_category":94,"primary_hub":72,"cluster":72,"pillar":72,"hubs":159},"\u002Fde\u002Fwissen\u002Fdgx-spark-erfahrungsbericht","dgx-spark-erfahrungsbericht","DGX Spark im Betrieb: was die Maschine nach drei Monaten wirklich kann","Kein Datenblatt, sondern ein Erfahrungsbericht. Wo die DGX Spark im täglichen Betrieb glänzt, wo ihre Grenzen liegen und für wen sich die Maschine lohnt.",[],{"path":161,"slug":162,"title":163,"summary":164,"image":72,"publication_date":146,"big5_category":125,"primary_hub":72,"cluster":72,"pillar":72,"hubs":165},"\u002Fde\u002Fwissen\u002Fllm-endpoint-aufsetzen","llm-endpoint-aufsetzen","Eigenen LLM Endpoint aufsetzen: von der GPU zum ersten Token","Ein realistischer Weg vom blanken Server zum produktiven Inferenz-Endpoint. Die Schritte, die Reihenfolge und die Stolpersteine, die zwischen „läuft lokal“ und „läuft produktiv“ liegen.",[],{"path":167,"slug":168,"title":169,"summary":170,"image":72,"publication_date":146,"big5_category":82,"primary_hub":72,"cluster":72,"pillar":72,"hubs":171},"\u002Fde\u002Fwissen\u002Foffene-modelle-auswahl","offene-modelle-auswahl","Welches offene Modell für welche Aufgabe? Llama, Qwen, Mistral & Co.","Nicht das grösste Modell gewinnt, sondern das passende. Wie du offene Modelle nach Aufgabe, Speicherbedarf und Lizenz auswählst, statt Benchmarks hinterherzulaufen.",[],{"path":173,"slug":174,"title":175,"summary":176,"image":72,"publication_date":146,"big5_category":74,"primary_hub":72,"cluster":72,"pillar":72,"hubs":177},"\u002Fde\u002Fwissen\u002Fvllm-ollama-tgi-vergleich","vllm-ollama-tgi-vergleich","vLLM, Ollama oder TGI: welche Inference Engine für welchen Fall","Die Engine entscheidet über Durchsatz, Latenz und Betriebsaufwand. Ein nüchterner Vergleich der drei verbreitetsten Optionen, inklusive der Fälle, in denen die einfache Lösung gewinnt.",[],{"path":179,"slug":180,"title":181,"summary":182,"image":72,"publication_date":183,"big5_category":74,"primary_hub":72,"cluster":72,"pillar":72,"hubs":184},"\u002Fde\u002Fwissen\u002Fdgx-spark-vs-cloud-gpu","dgx-spark-vs-cloud-gpu","DGX Spark gegen Cloud-GPU: wann sich eigene Hardware lohnt","Unified Memory gegen rohen Durchsatz, Schweizer Hardware gegen Hyperscaler. Ein nüchterner Vergleich, inklusive der Fälle, in denen die Cloud gewinnt.","2026-06-18T00:00:00Z",[],{"path":186,"slug":187,"title":188,"summary":189,"image":72,"publication_date":183,"big5_category":111,"primary_hub":72,"cluster":72,"pillar":72,"hubs":190},"\u002Fde\u002Fwissen\u002Fllm-selbst-betreiben-kosten","llm-selbst-betreiben-kosten","Was kostet es, ein LLM selbst zu betreiben?","Die nüchterne Rechnung hinter eigenen LLM-Endpoints: Hardware, Betrieb und der Punkt, ab dem sich Selbermachen wirklich lohnt.",[],[192,194,196,198],{"title":46,"href":47,"description":193},"Der NVIDIA-AI-Supercomputer für den Schreibtisch — on-demand aus der Schweiz, bare metal oder gemanagt.",{"title":49,"href":50,"description":195},"DGX Spark & H100 als dedizierte Maschine — volle Kontrolle, Root-Zugriff, Schweizer Rechenzentrum.",{"title":52,"href":21,"description":197},"LLM-Endpoints via vLLM — von uns betrieben, ohne Ops-Aufwand, mit Schweizer Datenhoheit.",{"title":54,"href":55,"description":199},"Agentische Workloads gemanagt — Hermes-Agents auf souveräner Hardware, von uns betrieben."]