· 4 Min. Lesezeit · Gaia Lab

Quantisierte LLMs messen: Was beim Komprimieren eines offenen Modells verloren geht

Fast 300 GGUF-Dateien aus Dutzenden Familien, mit llama.cpp bereitgestellt und in Funktionsaufrufen, Code und langem Kontext bewertet, mit Geschwindigkeit und Energie je Karte. Die Linie, die die meisten GPU-Stunden reserviert, trainiert nichts: Sie misst, was jede Quantisierungsstufe kostet.

Acht horizontale Balken abnehmender Länge, beschriftet mit Quantisierungsstufen von BF16 bis IQ1_S
Für die Serie generierte Illustration: die Treppe der Quantisierungen.

Dritte Folge von Cluster-Röntgenbild. Sie ist das beste Beispiel für das, was der Überblicksbeitrag sagte: Der Cluster ist heute vor allem ein Messlabor. Hier wird kein einziger Parameter trainiert.

Die Frage #

Offene Modelle werden quantisiert verteilt: dieselben Gewichte, komprimiert auf 8, 6, 5, 4, 3 oder 2 Bit, damit sie auf eine kleine Karte oder ein Notebook passen. Die Community veröffentlicht Hunderte Varianten, aber selten mit einer vergleichbaren Messung dessen, was verloren geht. Die Linie fragt, wie viel jede Quantisierungsstufe jeder Familie in Aufgaben wirklich leistet, die für den Einsatz des Modells als Werkzeug zählen, und mit welcher Geschwindigkeit und welchen Energiekosten sie das auf jeder Karte tut.

Wie man vorgeht #

Fast 300 verschiedene GGUF-Dateien aus Familien wie Qwen (2.5 bis 3.8), Gemma 3 und 4, GLM, DeepSeek, Mixtral, Llama 3, Mistral, gpt-oss, Nemotron, Granite, SmolLM oder Phi-3, dazu experimentelle ternäre Modelle, und die komplette Treppe: BF16, Q8_0, Q6_K, Q5_K_M, Q4_K_M (die häufigste), Q3, Q2, die UD-Serie von Unsloth mit ihren IQ1 bis IQ4, MXFP4 und NVFP4. Für mehrere Familien werden Kurven mit sieben oder acht Stufen desselben Modells erzeugt.

Drei Prüfungen, ausgewählt, weil sie das Modell als Werkzeug messen und nicht als Gesprächspartner:

  • BFCL, Funktionsaufrufe: ob das Modell den richtigen Aufruf mit den richtigen Argumenten erzeugt.
  • BigCodeBench, 148 Programmierprobleme mit echten Bibliotheken.
  • RULER, Retrieval in Kontexten von 4K bis 128K Tokens.

Hinzu kommen Tokens pro Sekunde je Karte, der tatsächliche Speicherbedarf jeder Datei, die Perplexität auf wikitext-2 in den Quantisierungs-Sweeps und die Energie: Der Leerlaufverbrauch jedes Knotens wird gemessen und vom Verbrauch während der Generierung abgezogen.

Die Methode hat zwei Regeln, die sie vergleichbar machen. Jeder Messpunkt trägt ein Manifest mit Datei, Quantisierung, KV-Cache, Kontext, Binary samt Prüfsumme und Karte. Und bevor irgendetwas gemessen wird, wird die veröffentlichte Punktzahl eines Ankermodells reproduziert: Liegt die Abweichung über fünf Punkten, liegt der Fehler beim Harness, nicht beim Modell.

Was man lernt #

Mehrere Erkenntnisse wurden in den Skripten selbst festgehalten, mit Datum:

  • Den KV-Cache zu quantisieren ist nicht kostenlos und gehört nicht zum Protokoll. Bei Gemma 4 bricht es: degenerierte Schleifen in 101 von 148 Problemen, gegenüber einem sauberen Ergebnis mit dem Cache in f16.
  • Die Karte zu wechseln verändert die Ausgabe. Nur 21 von 148 Antworten waren zwischen einer L4 und einer H200 bei gleicher Konfiguration identisch. Vergleiche werden immer auf derselben Karte durchgeführt.
  • Gemessen wird das Modell, nicht das Gerüst. BFCL wird über die rohe Completion-API angegangen: „über den nativen Weg würden wir das Modell plus das Gerüst messen“.
  • Ein Anker, den man nicht herunterladen kann, ist kein Anker: Als Llama 3.1 8B hinter einer Zustimmungsmauer landete, wurde Phi-3 mini zum Anker für langen Kontext.

Und eine Sicherheitsregel, die Teil der Methode ist: Der Cluster erzeugt Text, er führt den vom Modell geschriebenen Code niemals aus. Die Korrektur von BigCodeBench, die diesen Code tatsächlich ausführt, findet in einem isolierten Container auf einer separaten Maschine statt. Die Multi-Turn-Phase von BFCL, die während der Generierung Aufrufe ausführt, läuft in einer Sandbox ohne Netz und mit verborgenen richtigen Antworten. Ein Kommentar, der sich selbst korrigiert, hält fest, dass ein Fehllesen des Harness-Codes „die Isolation an die falsche Stelle gesetzt hätte“.

Auf dem Cluster #

3.941Jobs1.104 hreservierte GPU-Stunden7.328 hreservierte CPU-Stunden10 Jun – 21 SepZeitraum (2026)
Kennzahlen der Linie. Zwei Personen teilen sich denselben Harness; die zweite startete 1.184 Jobs an sechs Septembertagen und veröffentlicht ihre Ergebnisse auf Yardstick .

Kurze Jobs mit einer GPU, vier Kernen und abgesenkter Priorität, die Hälfte auf der bescheidenen L4 mit 24 GB. Die ersten 593 scheiterten an einem SSH-Tunnel zwischen Notebook und Knoten; seitdem laufen Client und Server auf demselben Knoten. Fünf Septemberjobs blieben rund 18 Stunden über ihr Limit hinaus hängen, bis Slurm sie gleichzeitig schloss; in den Zahlen der Serie werden sie nur bis zum angeforderten Limit gezählt.

Jobs nach TypBFCL (Funktionsaufrufe)BFCL (Funktionsaufrufe): 1.105 · 28 %1.105 · 28 %BigCodeBench (Generierung)BigCodeBench (Generierung): 779 · 20 %779 · 20 %SonstigeSonstige: 777 · 20 %777 · 20 %Bereitstellung per SSH-Tunnel (gescheitert)Bereitstellung per SSH-Tunnel (gescheitert): 593 · 15 %593 · 15 %RULER (langer Kontext)RULER (langer Kontext): 426 · 11 %426 · 11 %Geschwindigkeit und EnergieGeschwindigkeit und Energie: 192 · 5 %192 · 5 %Download, Quantisierung, BuildDownload, Quantisierung, Build: 69 · 2 %69 · 2 %
Jobs nach Typ: die drei Prüfungen, Geschwindigkeit und Energie sowie die Vorbereitung der Dateien.

In der vierten Folge wechseln wir das Thema komplett: Proteine falten.


Zahlen aus dem Slurm-Accounting (reservierte Kapazität, nicht gemessene Nutzung) und den archivierten sbatch-Dateien. Anonymisierter Beitrag: ohne identifizierbare Nutzer, Pfade, E-Mails oder Projektnamen. Die Zitate stammen aus den Kommentaren der Skripte.