MatMul-Free LM: Ternary-Gewichte statt Matrixmultiplikation im Transformer

Wogegen die Architektur antritt

Der Titel des Projekts benennt das Ziel direkt: Matrixmultiplikation soll aus dem Sprachmodell verschwinden. In einem üblichen Transformer steckt sie fast überall, in den Projektionen der Attention, im Feed-Forward-Teil, in den Ausgabeschichten. Auf Beschleunigern sind diese Multiplikationen der teuerste Teil, auf spezialisierter Hardware mit sehr kleinen Gewichtswerten dagegen schlecht abbildbar. Die Autoren argumentieren in der zugehörigen Arbeit Scalable MatMul-free Language Modeling, dass sich Sprachmodellierung mit ternären Gewichten und elementweisen Operationen formulieren lässt. Adressat ist damit nicht das Team, das morgen ein Chatprodukt ausliefert, sondern die Forschung an energieeffizienten Beschleunigern. Das Repository ist aus flash-linear-attention hervorgegangen und teilt mit diesem Projekt die Konzentration auf rekurrente, lineare Sequenzmodelle statt quadratischer Attention.

HGRNBit: was in einem Block tatsächlich passiert

Die README zeigt die Initialisierung eines Modells über AutoModel.from_config mit einer HGRNBitConfig. Der ausgegebene Baum ist die beste verfügbare Beschreibung der Architektur. Ein HGRNBitBlock besteht aus zwei Teilen. Im Attention-Teil sitzen vier Projektionen, i_proj, f_proj, g_proj und o_proj, alle als FusedBitLinear mit bias=False und jeweils einer eigenen RMSNorm mit eps=1e-08. Der MLP-Teil enthält gate_proj, down_proj und eine SiLU-Aktivierung, ebenfalls als FusedBitLinear. Der Name verrät den Mechanismus: FusedBitLinear bündelt die Normalisierung mit der ternären Projektion in einem Kernel, statt sie als getrennte Operationen auszuführen. Die RMSNorm innerhalb der Projektion ist kein Zufall, denn ternäre Gewichte sind empfindlich gegen Skalen, und eine Normalisierung direkt vor der Quantisierung hält die Aktivierungen im brauchbaren Bereich. Auffällig ist die Form von down_proj: in_features=5632, out_features=2048, während gate_proj von 2048 auf 11264 geht. Der Zwischenschritt ist also nicht symmetrisch, was auf eine Aufteilung des Gate-Pfads hindeutet, die sich aus dem gezeigten Baum nicht vollständig rekonstruieren lässt. Wer das genau wissen will, muss den Modellcode lesen, nicht die README.

Installation und ein Generierungslauf

Die Installation erfolgt direkt aus dem Repository, ein Paket auf PyPI wird nicht genannt: pip install -U git+https://github.com/ridgerchu/matmulfreellm. Vorausgesetzt werden PyTorch ab Version 2.0, Triton ab 2.2 und einops. Triton ist dabei kein Beiwerk, denn die ternären Kernel sind darauf angewiesen, und ohne eine passende Triton-Version schlägt der Import der Operationen fehl. Für die Generierung verweist die README auf generate.py. Das Skript setzt TOKENIZERS_PARALLELISM auf false, importiert mmfreelm, lädt Tokenizer und Modell über AutoTokenizer.from_pretrained und AutoModelForCausalLM.from_pretrained, verschiebt das Modell mit .cuda().half() auf die GPU und ruft generate mit max_length=32, do_sample=True, top_p=0.4 und temperature=0.6 auf. Die Modellvariable name ist im Beispiel leer und muss auf eines der veröffentlichten Modelle zeigen. Bemerkenswert ist der halbe Präzisionstyp: .half() steht in Spannung zu ternären Gewichten, deren Sinn gerade die Vermeidung von Gleitkomma-Multiplikationen ist. Die README erklärt diesen Widerspruch nicht, und das ist eine echte Lücke in der Dokumentation.

Die drei vortrainierten Modelle und ihre Trainingsdaten

Der Model Zoo umfasst drei Größen. Das 370M-Modell hat 24 Schichten, eine Hidden-Dimension von 1024 und wurde auf 15B Token trainiert. Das 1.3B-Modell hat ebenfalls 24 Schichten, aber 2048 Dimensionen und 100B Token. Das 2.7B-Modell hat 32 Schichten, 2560 Dimensionen und ebenfalls 100B Token. Die Skalierung der Trainingsmenge ist also nicht linear zur Parameterzahl, das kleinste Modell bekam deutlich weniger Daten. Die README zeigt eine Skalierungskurve, nach der die Projektion des eigenen Modells steiler abfällt als die von Transformer++, was als Effizienzvorteil bei zusätzlichem Compute gedeutet wird. Diese Aussage stammt aus der Arbeit und ist nicht unabhängig überprüft. Wer die Modelle einsetzen will, findet sie über die Hugging-Face-Kollektion matmulfree-lm. Für Vergleiche mit heutigen offenen Modellen ist die Tokenmenge der entscheidende Vorbehalt: 100B Token sind für ein 1.3B- oder 2.7B-Modell ein schmaler Trainingskorpus, und die README nennt weder Datenquelle noch Mischung.

Wo der Ansatz an seine Grenzen stößt

Der zentrale Vorbehalt betrifft die Hardware. Der Nutzen ternärer Gewichte entsteht auf Beschleunigern, die diese Operationen nativ ausführen. Auf einer gewöhnlichen GPU laufen die Triton-Kernel zwar, aber sie konkurrieren mit hochoptimierten Bibliotheken für dichte Matrixmultiplikation, die dort seit Jahren auf die Hardware abgestimmt sind. Ob FusedBitLinear auf einer H100 oder RTX-Karte schneller ist als eine quantisierte Baseline, lässt sich aus der README nicht ableiten, und das Repository liefert keine Benchmarktabelle. Ein zweiter Punkt ist die Ökosystemreife: Die Bibliothek ist an Transformers gekoppelt, aber die Modellklassen sind eigene Implementierungen. Wer auf neuere Transformers-Versionen aktualisiert, muss damit rechnen, dass Schnittstellen sich verschieben. Drittens die Modellgröße. Mit maximal 2.7B Parametern und 100B Trainings-Token ist das obere Ende des Zoos deutlich unter dem, was aktuelle offene Modelle bieten. Für Aufgaben, die starkes Weltwissen oder langes Reasoning verlangen, ist das der falsche Werkzeugkasten, unabhängig davon, wie elegant die Kernel sind.

Der Unterschied zu flash-linear-attention

Die naheliegendste Alternative ist das Projekt, aus dem dieses Repository hervorgegangen ist: flash-linear-attention, ebenfalls rund um lineare Attention und rekurrente Sequenzmodelle. Der Unterschied liegt in der Gewichtedarstellung. flash-linear-attention sammelt effiziente Kernel für lineare Attention mit gewöhnlichen Gleitkommagewichten, der Schwerpunkt liegt auf dem Sequenzmix. matmulfreellm geht eine Ebene tiefer und ersetzt zusätzlich die Projektionen durch ternäre FusedBitLinear-Schichten, wodurch nicht nur die Attention, sondern auch der Feed-Forward-Teil ohne Matrixmultiplikation auskommt. Das ist ein größerer Eingriff mit höherem Risiko für Genauigkeitsverluste, und die Skalierungskurve in der README ist der Versuch, diesen Verlust zu adressieren. Wer nur lineare Attention will und keine ternären Gewichte, ist bei flash-linear-attention besser aufgehoben. Wer den vollständigen Verzicht auf Multiplikation braucht, kommt an diesem Repository nicht vorbei.

Wartung, Versionierung und Lizenz

Der letzte Push liegt bei September 2026, die Version v0.1.0 wurde am selben Tag veröffentlicht. Die Release-Notes beschreiben v0.1.0 als archivierbare Softwareversion zum Manuskript in Nature Computational Science, basierend auf Commit f24cfe5, ergänzt um Zitations-, Versions- und Lizenzmetadaten. Das ist ein wichtiger Hinweis auf den Charakter des Projekts: Es ist ein Forschungsartefakt, kein Produkt mit Releasezyklus. Die Versionsnummer 0.1.0 signalisiert, dass Schnittstellen sich ändern können, und die Kopplung an einen bestimmten Commit bedeutet, dass spätere Änderungen am master nicht automatisch Teil der zitierten Version sind. Wer reproduzieren will, sollte auf diesen Commit pinnen, nicht auf den Branch. Lizenziert ist unter Apache-2.0, was kommerzielle Nutzung und Modifikation erlaubt, sofern Lizenz- und Änderungshinweise erhalten bleiben. Die Modelle auf Hugging Face haben eigene Modellkarten mit möglicherweise abweichenden Bedingungen, und die README verweist für Zitate ausdrücklich auf CITATION.cff. Wer das Projekt in einem Produkt einsetzt, sollte diese Trennung zwischen Code- und Gewichtelizenz prüfen, bevor er sich auf die Apache-2.0-Angabe im Repository verlässt.

Redaktionelles Fazit

Wer die Architektur selbst nachvollziehen, feintunen oder auf neuromorpher Hardware erproben will, findet hier eine schlanke, Transformers-kompatible Basis mit drei vortrainierten Modellen. Wer dagegen ein produktionsreifes Modell mit belastbaren Latenz- und Durchsatzgarantien sucht, sollte zuerst prüfen, ob die ternären Kernel auf der Zielhardware überhaupt greifen, denn auf einer gewöhnlichen GPU bleibt der Vorteil gegenüber einer quantisierten Transformer-Baseline offen. Vor dem Einsatz lohnt der Blick in die verlinkten Modellkarten und in den Kernel-Code unter mmfreelm/ops, weil dort entschieden wird, ob aus dem Ansatz ein Laufzeitgewinn wird oder nur eine andere Rechenreihenfolge.

Offizielle Quellen

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. ridgerchu/matmulfreellm on GitHub