xlstm : la pile LSTM étendue de NX-AI, du bloc de recherche au modèle 7B

Deux architectures dans un même dépôt

Le dépôt ne contient pas une seule implémentation mais deux, séparées par un an d'écart. La première vient de l'article NeurIPS 2405.04517 : elle expose xLSTMBlockStack pour un usage hors langage et xLSTMLMModel pour les applications à base de tokens. La seconde, décrite dans l'article 2503.13427, vit dans xlstm/xlstm_large et correspond à l'architecture optimisée du modèle 7B, entraîné sur 2.3T tokens selon le README. Le README précise que cette seconde implémentation, regroupée dans un fichier unique xlstm/xlstm_large/model.py, n'a aucune dépendance sur l'implémentation NeurIPS. C'est un point pratique : vous pouvez lire l'architecture 7B sans traverser le reste du paquet. En revanche, cette séparation signifie aussi que les correctifs ne circulent pas forcément d'une branche à l'autre, et que la documentation de l'une ne s'applique pas à l'autre. Le public visé est double : chercheur qui veut un bloc récurrent à insérer dans un modèle existant, et ingénieur qui veut charger les poids 7B depuis Hugging Face.

Ce que le mécanisme change par rapport au LSTM d'origine

Le README résume la proposition en une phrase : un portail exponentiel avec normalisation et stabilisation, plus une nouvelle mémoire matricielle, ce qui permet de dépasser les limites du LSTM classique. La formulation reste au niveau de l'intention, pas du détail algorithmique, et le dépôt ne fournit pas de description mathématique complète dans le texte cité. Ce qui est observable, c'est la signature de configuration du modèle large. xLSTMLargeConfig prend embedding_dim, num_heads, num_blocks, vocab_size, return_last_states et mode. Trois clés séparées désignent les noyaux : chunkwise_kernel, sequence_kernel et step_kernel. Cette séparation trahit le compromis central de l'architecture : un chemin pour traiter une séquence entière en parallèle pendant l'entraînement, un chemin pour avancer pas à pas pendant la génération. Le README associe chunkwise--triton_xl_chunk aux noyaux TFLA, et indique que le mode inference est celui utilisé dans l'exemple. La conséquence pratique est qu'un même modèle peut emprunter des implémentations différentes selon la phase, et que le comportement numérique dépend donc du noyau choisi.

Installation : deux chemins, deux niveaux de dépendance

L'installation minimale tient en deux commandes. Pour le paquet seul : pip install xlstm. Pour le modèle 7B, le README impose une étape préalable, pip install mlstm_kernels, présenté comme le paquet fournissant les noyaux rapides. Sans lui, l'architecture large ne fonctionne pas. Le dépôt propose aussi une installation depuis les sources avec git clone puis pip install -e . à la racine. Pour un environnement reproductible, la documentation recommande de créer un environnement conda depuis environment_pt240cu124.yaml, avec conda env create -n xlstm -f environment_pt240cu124.yaml puis conda activate xlstm. Le nom du fichier encode la version de PyTorch et de CUDA attendues, ce qui donne une indication sur ce qui a été testé. Le README indique par ailleurs que le paquet est basé sur PyTorch et testé pour des versions supérieures ou égales à 1.8. Cette borne basse est probablement optimiste pour les noyaux Triton, qui dépendent d'un écosystème plus récent. Je ne peux pas le confirmer à partir du matériel fourni.

Le choix des noyaux décide de votre matériel

C'est la contrainte la plus concrète du dépôt. Le README indique que les noyaux Triton ont été testés principalement sur GPU NVIDIA, qu'ils devraient aussi fonctionner sur GPU AMD, et que pour les autres plateformes, Apple Metal en particulier, il faut basculer sur les implémentations PyTorch natives. Le changement se fait dans la configuration, pas dans le code appelant : chunkwise_kernel passe à chunkwise--native_autograd, sequence_kernel à native_sequence__native, step_kernel à native. Le README oriente aussi vers le port communautaire xLSTM-metal, décrit comme une implémentation MLX native pour Apple Silicon, mais ce projet est externe au dépôt et n'engage pas ses mainteneurs. Pour le sLSTM en CUDA, la barre est explicite : Compute Capability supérieure ou égale à 8.0. Si la compilation échoue, le README suggère d'exporter TORCH_CUDA_ARCH_LIST avec la valeur 8.0;8.6;9.0, et mentionne XLSTM_EXTRA_INCLUDE_PATHS pour injecter des chemins d'inclusion CUDA, soit par variable d'environnement, soit via os.environ en Python. Ces deux variables existent parce que la compilation est fragile, pas parce qu'elle est configurable par goût.

L'exemple de forward pass et ce qu'il ne dit pas

Le notebook notebooks/xlstm_large/demo.ipynb sert de point d'entrée. Le README en reproduit le cœur : on importe xLSTMLargeConfig et xLSTMLarge depuis xlstm.xlstm_large.model, on instancie une configuration à 512 dimensions d'embedding, 4 têtes, 6 blocs et un vocabulaire de 2048, on déplace le modèle sur cuda, on génère un tenseur d'entiers de forme (3, 256), et on vérifie que out.shape[1:] vaut (256, 2048). Tout est en mode aléatoire. Aucun poids n'est chargé, aucune tokenisation n'apparaît, aucune étape de génération n'est montrée. Le notebook valide donc que la pile s'exécute, pas qu'elle produit du texte. Pour le modèle 7B réel, le README renvoie vers la page Hugging Face NX-AI/xLSTM-7b sans détailler la procédure de chargement des poids. C'est la lacune la plus gênante du document : le passage de la démonstration aléatoire au modèle entraîné n'est pas décrit dans le texte fourni.

Licence du code et licence du modèle ne coïncident pas

Le paquet est publié sous Apache-2.0, mention répétée dans le badge et dans les métadonnées du dépôt. Mais le badge de licence du modèle 7B pointe vers une licence nxai_community, avec un lien vers un fichier LICENSE situé dans un autre dépôt, NX-AI/tirex-internal. Autrement dit, les poids ne relèvent pas d'Apache-2.0. Le README ne reproduit pas les termes de cette licence communautaire et ne dit rien des restrictions qu'elle pourrait poser pour un usage commercial. C'est un point à trancher avant d'intégrer le modèle dans un produit, et le dépôt seul ne permet pas de le faire. Sur la maintenance, deux versions sont listées : v2.0.4 en mai 2025 et v2.0.6 en septembre 2026, avec un dernier push à la même date. L'écart entre les deux versions suggère un rythme irrégulier, mais je ne peux pas en déduire davantage sans l'historique des commits.

Face à un Transformer, l'argument est l'inférence

Le second article s'intitule explicitement Recurrent LLM for Fast and Efficient Inference. La différence d'approche avec un Transformer tient à la structure, pas à un réglage : un modèle récurrent conserve un état entre les pas, là où l'attention recalcule des correspondances sur toute la séquence. C'est ce qui motive une architecture récurrente pour la génération, et c'est aussi ce qui explique la présence de trois noyaux distincts dans la configuration. Le README affirme une performance prometteuse en modélisation de langage comparée aux Transformers ou aux modèles d'espace d'état, mais ne fournit aucune mesure dans le texte cité. Pour un lecteur qui doit décider, la vraie question n'est pas laquelle des deux familles est meilleure, mais si son cas d'usage tolère l'écosystème restreint de xLSTM : noyaux Triton, dépendance à mlstm_kernels, licence de poids séparée. Un Transformer reste plus simple à déployer sur du matériel varié, et c'est un critère qui pèse plus lourd que quelques points de perplexité.

Conclusion éditoriale

Adoptez xlstm si vous voulez expérimenter une architecture récurrente avec portage mémoire constant à l'inférence, ou reproduire le modèle 7B sur GPU NVIDIA. Ne l'adoptez pas si vous cherchez un pipeline de fine-tuning clé en main : la documentation ne décrit que l'inférence et l'initialisation de modèles. Avant tout, vérifiez que votre GPU atteint la Compute Capability 8.0 requise pour les noyaux CUDA du sLSTM, et lisez la licence du modèle 7B, qui n'est pas Apache-2.0 comme le code.

Sources officielles

1. License: Apache-2.0
2. NX-AI/xlstm on GitHub
3. Project website
4. README
5. Releases