xLSTM: rekurrente Sprachmodelle statt Transformer, mit zwei getrennten Architekturen im Repo
Official repository of the xLSTM.
Auf einen Blick
- Was ist das?
- Das offizielle xLSTM-Repository enthält zwei Modelllinien: die NeurIPS-Architektur mit sLSTM und mLSTM sowie die überarbeitete xLSTM-Large-Architektur, auf der das 7B-Modell basiert. Wer das Paket einbindet, muss wissen, welche der beiden er braucht, denn sie teilen sich nur das Repository, nicht den Code.
- Für wen ist es gedacht?
- Wer eine rekurrente Architektur mit linearem Speicher- und Rechenaufwand pro Token sucht und bereit ist, die Kernel-Abhängigkeiten selbst zu prüfen, findet in xlstm ein Paket mit klarer Struktur. Wer dagegen ein vortrainiertes Modell mit dokumentierter Inferenz-API ohne GPU-Treiberarbeit sucht, sollte zuerst die Modellkarte auf Hugging Face lesen und erst dann entscheiden, ob das Repository der richtige Einstieg ist.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 8 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem xLSTM adressiert und für wen das Repository gedacht ist
Transformer skalieren im Training gut, zahlen aber bei der Inferenz einen Preis: Der KV-Cache wächst mit der Kontextlänge, jeder neue Token liest Speicher, dessen Umfang von der Sequenzlänge abhängt. xLSTM setzt an dieser Stelle an. Die README beschreibt die Architektur als rekurrent, aufgebaut auf Ideen des ursprünglichen LSTM, erweitert um exponentielles Gating mit Normalisierung und Stabilisierung sowie einen neuen Matrix-Speicher. Der Anspruch im Text: bessere Ergebnisse bei der Sprachmodellierung als Transformer oder State-Space-Modelle, wobei die Formulierung dort bewusst als "promising performance" auftritt, nicht als gesicherter Messwert.
Adressat ist damit kein Anwendungsentwickler, der eine fertige Text-API sucht, sondern jemand, der Modelle trainiert oder Architekturen in eigene Systeme einbaut. Das zeigt schon die Struktur des Repositories: Es gibt einen Block-Stack für Nicht-Sprach-Anwendungen oder zum Einbetten in andere Architekturen, und es gibt ein Sprachmodell. Die beiden Zielgruppen bekommen unterschiedliche Einstiegsklassen, nicht eine gemeinsame Fassade.
Bemerkenswert ist die Zweiteilung, die sich durch das ganze Repository zieht. Der Abschnitt zur NeurIPS-Arbeit beschreibt sLSTM und mLSTM, der Abschnitt zu xLSTM Large beschreibt eine überarbeitete Architektur, deren Code laut README unter xlstm/xlstm_large liegt und die, abgesehen von mlstm_kernels, keine Abhängigkeit zur NeurIPS-Implementierung hat. Wer das Repository zum ersten Mal öffnet, muss diese Trennung zuerst verstehen, sonst importiert er Klassen aus dem falschen Modul.
sLSTM, mLSTM und der Matrix-Speicher als eigentlicher Mechanismus
Der Kern der NeurIPS-Variante sind zwei Zelltypen. sLSTM steht für eine skalare Speicherzelle, die über exponentielles Gating stabilisiert wird. mLSTM steht für eine Matrix-Speicherzelle, die als assoziatives Gedächtnis arbeitet: Schlüssel und Werte werden in einer Matrix abgelegt, statt in einem Vektor. Genau dieser Matrix-Speicher ist der Grund, warum die Architektur überhaupt mit Aufmerksamkeitsmechanismen verglichen wird, denn er erlaubt das Wiederfinden von Information über eine gewisse Distanz, ohne dass ein KV-Cache mitwächst.
Die README nennt für die sLSTM-CUDA-Kernel eine harte Voraussetzung: Compute Capability >= 8.0. Das schließt ältere Karten aus, unabhängig davon, ob der Rest des Codes läuft. Für Kompilierprobleme gibt das Repository zwei Umgebungsvariablen an die Hand. TORCH_CUDA_ARCH_LIST lässt sich auf eine Liste gesetzter Architekturen beschränken, im Beispiel "8.0;8.6;9.0". XLSTM_EXTRA_INCLUDE_PATHS injiziert zusätzliche Include-Pfade, entweder als Shell-Variable oder aus Python heraus über os.environ. Beide Variablen sind ein Eingeständnis: Der Build ist fragil, sobald die CUDA-Toolchain vom getesteten Pfad abweicht.
Für den Fall, dass die eigenen Kernel schneller sein sollen, verweist die README auf das separate Projekt FlashRNN. Das ist ein Auslagerungshinweis, kein Teil dieses Repositories. Wer ihn befolgt, verlässt den hier beschriebenen Code.
xLSTM Large: eine zweite Architektur mit eigenem Einstiegspunkt
Für das 7B-Modell wurde die Architektur nach eigener Aussage auf Trainingsdurchsatz und Stabilität optimiert. Der Code liegt in xlstm/xlstm_large, und die README bezeichnet die Implementierung in xlstm/xlstm_large/model.py als eigenständige Einzeldatei. Das ist praktisch relevant: Man kann diese Datei lesen, ohne den Rest des Pakets zu durchdringen.
Die Konfiguration erfolgt über xLSTMLargeConfig und xLSTMLarge. Das Beispiel im README setzt embedding_dim=512, num_heads=4, num_blocks=6, vocab_size=2048, return_last_states=True und mode="inference". Entscheidend sind die drei Kernel-Schlüssel. chunkwise_kernel="chunkwise--triton_xl_chunk" wählt die TFLA-Kernel, sequence_kernel="native_sequence__triton" und step_kernel="triton" ergänzen sie. Der Kommentar im Codebeispiel stellt klar: xl_chunk bedeutet TFLA-Kernel.
Der Datenfluss im Beispiel ist knapp: Der Konfiguration wird ein Modell erzeugt, mit .to("cuda") auf die GPU geschoben, ein Integer-Tensor der Form (3, 256) als Eingabe erzeugt, ein Forward-Pass ausgeführt. Die README notiert als erwartete Ausgabe, dass out.shape[1:] gleich (256, 2048) ist, also Sequenzlänge mal Vokabulargröße. Das ist der einzige im Material genannte Ausgabewert, und er bezieht sich auf ein zufällig initialisiertes Modell, nicht auf trainierte Gewichte.
Die Gewichte des 7B-Modells liegen laut README auf Hugging Face unter NX-AI/xLSTM-7b. Das Repository selbst enthält sie nicht.
Installation: zwei Wege, zwei Abhängigkeitsketten
Der minimale Weg für das Modellcode-Paket führt über pip install xlstm. Wer aus dem Quelltext arbeiten will, klont das Repository, wechselt hinein und installiert mit pip install -e .
Für xLSTM Large kommt eine zusätzliche Abhängigkeit hinzu: pip install mlstm_kernels. Die README formuliert das als Voraussetzung für das 7B-Modell, nicht als Option. Ohne dieses Paket fehlen die schnellen Kernel, und die Konfigurationsschlüssel für Triton zeigen ins Leere.
Für eine getestete Umgebung empfiehlt die README eine Conda-Umgebung aus environment_pt240cu124.yaml. Die Befehle lauten conda env create -n xlstm -f environment_pt240cu124.yaml und anschließend conda activate xlstm. Der Dateiname kodiert die Versionen: PyTorch 2.4.0, CUDA 12.4. Das Paket selbst gibt als Basis PyTorch an und nennt als getesteten Bereich >=1.8, was deutlich weiter ist als das, was die Umgebungsdatei festschreibt.
Diese Diskrepanz ist kein Detail. Ein Nutzer, der auf PyTorch 2.4 mit CUDA 12.4 bleibt, folgt dem getesteten Pfad. Wer eine andere Kombination fährt, ist auf die Umgebungsvariablen für Include-Pfade und Architekturlisten angewiesen. Die README sagt selbst, dass bei eigenen Torch- und CUDA-Setups die Versionen zusammenpassen müssen.
Hardware-Grenzen und der Fall, in dem xLSTM das falsche Werkzeug ist
Die README ist hier offener als viele Projektbeschreibungen. Getestet wurde überwiegend auf NVIDIA-GPUs. Für Triton-Kernel wird vermutet, dass sie auch auf AMD-GPUs laufen, was als Erwartung formuliert ist und nicht als geprüfte Aussage. Für andere Plattformen, ausdrücklich Apple Metal genannt, empfiehlt die README die nativen PyTorch-Implementierungen. Konkret bedeutet das: chunkwise_kernel="chunkwise--native_autograd", sequence_kernel="native_sequence__native", step_kernel="native".
Wer auf Apple Silicon arbeitet, wird also auf die langsameren Pfade verwiesen. Die README nennt dafür einen Ausweg außerhalb des Repositories: den community-getriebenen Port xLSTM-metal im MLX-Ökosystem. Das ist eine Fremdimplementierung, gepflegt von anderer Seite, mit eigenem Risiko.
Der Fall, in dem xLSTM das falsche Werkzeug ist, lässt sich daraus ableiten. Wenn die Zielumgebung keine NVIDIA-GPU mit Compute Capability >= 8.0 hat und die Inferenzgeschwindigkeit der Grund für die Wahl war, dann fällt der Hauptvorteil weg und es bleibt eine rekurrente Architektur, die man ohne die schnellen Kernel betreibt. Ebenso ungeeignet ist es für Teams, die ein Modell mit dokumentierter, stabiler Serving-Schnittstelle brauchen: Das Repository liefert Modellcode und Gewichtshinweise, keine Inferenzserver-Schicht.
Abgrenzung zu State-Space-Modellen und Transformern
Die README vergleicht xLSTM selbst mit Transformers und State Space Models. Der Unterschied im Ansatz ist struktureller Natur. Ein Transformer hält für jeden Token einen Schlüssel und einen Wert im Cache, der Speicherbedarf wächst linear mit der Kontextlänge und die Inferenz liest bei jedem Schritt den gesamten Cache. Ein State-Space-Modell komprimiert den Verlauf in einen Zustand fester Größe, verliert dabei aber die explizite Wiederauffindbarkeit einzelner früherer Positionen.
xLSTM nimmt eine Mittelposition ein. Der Matrix-Speicher der mLSTM-Zelle hat eine feste Form, wächst also nicht mit der Sequenzlänge, erlaubt aber über die Matrixstruktur das gezielte Wiederfinden von Information. Das ist der eigentliche Unterschied zu einem reinen Zustandsmodell. Gegenüber einem Transformer tauscht man die exakte, positionsweise Attention gegen einen komprimierten Speicher, dessen Kapazität durch die Matrixdimension begrenzt ist.
Diese Grenze ist real und wird in der README nicht quantifiziert. Wer wissen will, ab welcher Kontextlänge oder bei welcher Aufgabe der Matrix-Speicher anfängt, Information zu verlieren, findet im Repository keine Antwort. Das gehört in die Evaluierung, nicht in die Annahme.
Wartung, Versionen und Lizenzlage
Die Release-Historie im Material zeigt v2.0.6 vom September 2026 und davor v2.0.4 vom Mai 2025. Zwischen diesen beiden Marken liegt eine Lücke von über einem Jahr, gefolgt von einem Sprung auf 2.0.6. Ob dazwischen kleinere Veröffentlichungen existierten, geht aus den gelieferten Angaben nicht hervor. Wer Versionsnummern für reproduzierbare Builds pinnt, sollte diesen Abstand kennen.
Der Code steht unter Apache-2.0. Das erlaubt kommerzielle Nutzung und Modifikation unter den Bedingungen dieser Lizenz, üblicherweise mit Beibehaltung von Copyright- und Lizenzhinweisen. Wichtiger für die Praxis: Die Apache-2.0-Lizenz des Repositories gilt für den Code, nicht automatisch für die Modellgewichte. Die README zeigt für xLSTM 7B ein eigenes Lizenzbadge, das auf eine nxai-community-Lizenz verweist. Code und Gewichte haben damit unterschiedliche Bedingungen, und wer das Modell einsetzt, muss beide prüfen. Eine rechtliche Bewertung ist hier nicht möglich und auch nicht beabsichtigt.
Als Wartungskosten bleiben drei Posten: die Bindung an mlstm_kernels als separates Paket mit eigener Versionsentwicklung, die CUDA-Toolchain, deren Versionen laut README zusammenpassen müssen, und die Tatsache, dass die schnellen Pfade auf Triton-Kernel setzen, deren Verhalten sich mit Triton-Versionen ändern kann. Das sind Abhängigkeiten außerhalb dieses Repositories, die dessen Stabilität mitbestimmen.
Redaktionelles Fazit
Wer eine rekurrente Architektur mit linearem Speicher- und Rechenaufwand pro Token sucht und bereit ist, die Kernel-Abhängigkeiten selbst zu prüfen, findet in xlstm ein Paket mit klarer Struktur. Wer dagegen ein vortrainiertes Modell mit dokumentierter Inferenz-API ohne GPU-Treiberarbeit sucht, sollte zuerst die Modellkarte auf Hugging Face lesen und erst dann entscheiden, ob das Repository der richtige Einstieg ist. Vor dem ersten produktiven Einsatz zu klären: welche PyTorch- und CUDA-Version die Umgebungsdatei vorschreibt, ob mlstm_kernels für die eigene GPU-Compute-Capability baut, und ob die Lizenz des 7B-Modellgewichts mit der Apache-2.0-Lizenz des Codes übereinstimmt. Diese drei Punkte lassen sich anhand des Repositories beantworten, ohne ein Modell zu trainieren.
Community-Notizen