Ein 27B-Modell auf zwei Bit pro Gewicht komprimiert

Ein 27B-Modell auf zwei Bit pro Gewicht komprimiert

Am 9. Oktober veröffentlichte Underdog AI Saluki 27B, einen komprimierten Build des Modells Qwen 3.8 27B. Die Kompression ist aggressiv: zwei Bit pro Gewicht, was das Ganze in eine Datei von rund 7,89 Gigabyte packt. Underdog zufolge behält das Ergebnis etwa 96 Prozent der Benchmark-Leistung des Originals, und bei Tool-Calling-Aufgaben übertrifft es das Modell in voller Größe sogar. Es erscheint unter der Apache-2.0-Lizenz für lokale Agent-Workflows.

Die Zahlen klingen wie ein Tippfehler. Ein Modell auf ein Viertel seiner Bittiefe zu reduzieren, kostet normalerweise viel Qualität. Salukis Behauptung lautet, dass dies nicht geschah, und dass es bei der einen Aufgabe, die für Agenten am wichtigsten ist, sogar besser wurde.

Warum Quantisierung bei zwei Bit schwer ist

Modellgewichte werden als Zahlen gespeichert, und die Anzahl der Bits pro Gewicht legt fest, wie viel Präzision jedes einzelne behält. Bei 16 Bit kann ein Gewicht einen von mehreren zehntausend Werten annehmen. Bei zwei Bit kann es einen von vier annehmen. Man verlangt von einem Netzwerk, das auf feinen Unterschieden aufbaut, sich mit einem Vokabular aus fast nichts auszudrücken.

Der Grund, warum es meist scheitert, ist, dass sich Fehler aufsummieren. Rundet man jedes Gewicht ein wenig, ist die Schicht leicht daneben. Stapelt man Dutzende leicht daneben liegender Schichten, driftet die Ausgabe weit vom Original ab. Die meisten Quantisierungsarbeiten betrachten vier Bit als praktische Untergrenze und akzeptieren darunter einen gewissen Qualitätsverlust.

Die Verfahren, die tiefer gehen, runden nicht einfach härter. Sie entscheiden, welche Gewichte grob sein dürfen und welche scharf bleiben müssen, und sie optimieren das komprimierte Modell danach oft nach, um die Schäden zu reparieren. Zwei Bit zusammenzuhalten, ist ein sorgfältiger, gezielter Prozess, kein grober.

Das Ergebnis beim Tool Calling ist der interessante Teil

Dass Saluki das Original bei allgemeinen Benchmarks erreicht, ist bemerkenswert. Dass es das Original beim Tool Calling übertrifft, ist seltsamer, und es deutet auf etwas Echtes hin. Tool Calling ist eine strukturierte Aufgabe: Das Modell muss einen korrekten Funktionsnamen und korrekte Argumente ausgeben, und kleine Unstimmigkeiten bringen das Ganze zum Scheitern. Ein Modell, das etwas verrauschter ist, kann etwas vielfältigere Ausgaben erzeugen, was in diesem Fall bedeuten kann, dass es bei Randfällen weniger stolpert.

Es gibt auch eine einfachere Erklärung. Wenn der Kompressionsprozess ein Feintuning auf Tool-Nutzungsdaten einschloss, ist das resultierende Modell nicht nur kleiner, sondern auch in die richtige Richtung verengt. Ein Spezialist kann einen Generalisten in seinem Fach schlagen und verliert bei allem anderen. Die ehrliche Lesart ist, dass Saluki ein komprimiertes Modell ist, das zugleich auf Agentenarbeit ausgerichtet wurde, und beide Veränderungen zusammen erklären das Ergebnis.

Intelligenzdichte ist hier die entscheidende Kennzahl

Underdog rahmt die Verbesserung als Gewinn an Intelligenz pro Gigabyte, etwa das 7,5-Fache des Originals. Diese Rahmung passt genau auf den Fall des lokalen Agenten. Wenn man ein Modell auf der eigenen Maschine laufen lässt, ist die Einschränkung nicht der Benchmark-Wert. Sie ist, ob das Modell in den Speicher passt und Raum für die Anwendungen ringsum lässt.

Ein 27B-Modell in voller Präzision braucht ernsthafte Hardware. Dasselbe Modell bei etwa acht Gigabyte läuft auf einem Laptop, und ein Laptop ist der Ort, an dem ein Großteil der Agentenarbeit tatsächlich stattfindet: Dateien lesen, Befehle ausführen, Ergebnisse prüfen. Der Wert der Kompression ist nicht ästhetisch. Er ist der Unterschied zwischen einem fähigen Modell, das man lokal laufen lassen kann, und einem fähigen Modell, das man nur mieten kann.

Warum lokale Agentenmodelle auf diese Größe zulaufen

Saluki ist eines von mehreren kleinen, offen lizenzierten Modellen, die auftauchen, um die repetitive Arbeit innerhalb größerer Systeme zu erledigen. Das Muster ist beständig: ein Modell mit etwa 7 bis 30 Milliarden Parametern, aggressiv komprimiert, freizügig lizenziert, auf die enge Schleife eines Agenten zugeschnitten.

Die Logik ist jedes Mal dieselbe. Ein Agent ruft sein Modell pro Aufgabe viele Male auf, also bestimmen Kosten und Latenz pro Aufruf das Erlebnis. Ein Modell, das klein genug ist, um lokal zu laufen, beseitigt sowohl den Netzwerk-Roundtrip als auch die Rechnung pro Token, und das verändert, wie offensiv man den Agenten einsetzen kann. Man hört auf, den eigenen Assistenten abzurechnen.

Es gibt einen zweiten, leiseren Grund. Lokal laufende Modelle senden die eigenen Daten nirgendwohin, was für alle zählt, die mit Code oder Dokumenten arbeiten, die sie nicht hochladen dürfen. Für dieses Publikum ist Kompression keine Kostenoptimierung. Sie ist der einzige Weg, überhaupt ein fähiges Modell zu bekommen.

Das Argument für kleine Dateien, in einer Zahl

Es hilft, den Größenunterschied konkret zu machen. Ein Modell mit 27 Milliarden Parametern belegt bei 16 Bit rund 54 Gigabyte, bevor irgendein Laufzeit-Overhead dazukommt. Das passt auf die meisten Laptops nicht, und es passt nicht in den Speicher, der übrig bleibt, nachdem Betriebssystem, Browser und Editor ihren Anteil genommen haben. Bei zwei Bit landet dieselbe Parameterzahl nahe bei 8 Gigabyte, was passt, und zwar neben den Werkzeugen, die der Agent steuern soll.

Das ist das ganze Argument für Kompression mit niedriger Bitbreite im lokalen Agentenfall. Es geht nicht darum, ein Modell laufen zu lassen, das vorher gar nicht lief, auch wenn das dazugehört. Es geht darum, ein Modell so bequem laufen zu lassen, dass der Agent es wiederholt aufrufen kann, ohne dass die Maschine es merkt, denn ein Agent, der das ganze System träge macht, ist ein Agent, den niemand eingeschaltet lässt.

Was man prüfen sollte, bevor man es glaubt

Komprimierte Modelle verdienen eine besondere Art von Skepsis. Der Schlagzeilen-Benchmark kann halten, während das Modell bei den langen, unordentlichen Eingaben nachlässt, die echte Arbeit erzeugt. Quantisierungsschäden zeigen sich oft zuerst bei ungewöhnlichen Formaten, langen Kontexten und seltenen Sprachen, von denen ein kurzer Benchmark nichts erfasst.

Auch wichtig ist, was zwei Bit beschreibt. Bittiefe pro Gewicht, Gruppengrößen und ob einige Schichten in höherer Präzision gehalten werden, verändern alle, was die Zahl bedeutet. Zwei Bit in einem Schema ist nicht dasselbe wie zwei Bit in einem anderen, und der Unterschied ist einer Modellkarte nicht anzusehen.

Was das alles ergibt

Die Frontier-Debatte dreht sich um das größte Modell, das jemand trainieren kann. Eine parallele Debatte, ebenso folgenreich, dreht sich um das kleinste Modell, das auf der eigenen Hardware noch gut genug ist, um nützlich zu sein. Saluki 27B gehört zur zweiten Debatte und macht eine konkrete, überprüfbare Behauptung: dass zwei Bit für die Arbeit reichen, die Agenten tatsächlich tun.

Wenn diese Behauptung außerhalb des Benchmarks standhält, senkt sie die Untergrenze dessen, was eine Person lokal laufen lassen kann, und an einer niedrigeren Untergrenze entsteht gewöhnlich die nächste Produktwelle. Das Modell ist nicht die Geschichte. Das Schrumpfen des Modells ist es.

Es lohnt sich zu bedenken, dass dies ein junges Feld ist. Die Verfahren, die Zwei-Bit-Gewichte funktionieren lassen, werden noch geschrieben, und jede Veröffentlichung ist ebenso sehr eine Demonstration einer Kompressionstechnik wie ein Produkt. Saluki ist weniger interessant für das, was es heute ist, als für das, was es beweist, heute durch ein enges Rohr passt. Das nächste Modell dieser Linie wird kleiner, schärfer oder beides sein, und die Untergrenze wird erneut sinken.