Modèles à espace d'états vs Transformers : guide pratique

Les transformers ne seront pas la seule solution sur le marché très longtemps. Je sais que ça sonne comme une affirmation audacieuse : on les voit dominer depuis des années, des modèles de langage jusqu'au repliement des protéines. Mais après plusieurs mois à comparer des modèles à espace d'états (SSM) aux baselines transformers sur des charges de travail en production, je suis convaincu que le changement est réel. Pas parce que les SSM sont meilleurs partout. Ce n'est pas le cas. Mais parce qu'ils résolvent des problèmes précis que les transformers ne peuvent pas résoudre fondamentalement, et que la dernière génération a comblé assez d'écart de qualité pour que les ignorer soit désormais une dette technique.

Ce n'est pas un article de hype. Je vais passer en revue ce que sont vraiment les modèles à espace d'états, les points où Mamba-3 améliore réellement les choses, les domaines où les SSM restent en retrait, et la manière dont votre équipe devrait aborder leur adoption. De praticien à praticien.

Pourquoi les transformers atteignent un mur à grande échelle

Vous connaissez déjà l'histoire de la complexité quadratique. L'auto-attention calcule une matrice N×N pour une séquence de longueur N, donc doubler la longueur du contexte quadruple le calcul et la mémoire. Pendant longtemps, ça n'a pas trop compté. Les modèles tournaient sur quelques milliers de tokens, et le matériel suivait.

Cette époque est révolue. Les charges de travail que nous construisons aujourd'hui exigent couramment des contextes de 100K+ tokens. Les assistants de code doivent voir des dépôts entiers. Les pipelines multimodaux avalent des heures de vidéo. Les agents conservent des historiques de conversation qui s'étendent sur plusieurs jours. À ces échelles, l'attention quadratique n'est pas seulement coûteuse : c'est un mur.

Le problème du cache KV aggrave la situation. Pendant la génération autorégressive, chaque couche d'un transformer stocke les paires clé-valeur de chaque token vu. Ce cache croît linéairement par couche et consomme vite la mémoire GPU. J'ai vu un transformer de 7B consommer 40 Go de VRAM rien que pour le cache KV avec un contexte de 128K. C'est de la mémoire que vous ne pouvez pas utiliser pour regrouper davantage de requêtes.

La croissance quadratique de la mémoire rend les contextes d'un million de tokens presque impossibles avec l'attention standard
La croissance du cache KV limite le nombre d'utilisateurs simultanés par GPU, un multiplicateur de coûts direct en production
La consommation énergétique de l'inférence de transformers sur long contexte devient difficile à justifier
Les applications temps réel (robotique, edge AI) ont besoin d'une génération de tokens en moins d'une milliseconde, que l'attention ne peut pas offrir
Le phénomène du « puits d'attention » dégrade la qualité sur les très longues séquences, même quand la mémoire est disponible

Ce ne sont pas des préoccupations théoriques. C'est la raison pour laquelle trois équipes différentes avec lesquelles j'ai travaillé ont sérieusement commencé à évaluer des alternatives l'an dernier.

Comment fonctionnent réellement les modèles à espace d'états

Les modèles à espace d'états viennent de la théorie du contrôle, où ils servent depuis des décennies à modéliser des systèmes dynamiques. L'idée centrale est simple : au lieu de regarder chaque token précédent pour calculer chaque sortie (comme le fait l'attention), on maintient un état caché compressé qui évolue dans le temps. Les nouveaux tokens mettent à jour l'état. L'état produit les sorties. C'est tout.

Mathématiquement, un SSM est défini par quatre matrices (A, B, C et D) qui régissent la façon dont un état caché h évolue en réponse à une entrée x. On discrétise les équations continues pour les données séquentielles, et on obtient une récurrence très simple à calculer à l'inférence.

import torch
def ssm_step(A_bar, B_bar, C, D, h, x_t):
"""Single SSM step: O(1) memory, O(1) compute.
Compare this to attention, which needs to look at
every previous token. The SSM just updates its state.
"""
h_new = A_bar @ h + B_bar @ x_t  # Update hidden state
y_t = C @ h_new + D * x_t         # Compute output
return h_new, y_t
def ssm_generate(A_bar, B_bar, C, D, tokens, embed):
"""Autoregressive generation with constant memory.
Whether you've processed 100 tokens or 500,000,
this uses the same amount of memory.
"""
h = torch.zeros(A_bar.shape[0])
outputs = []
for t in tokens:
x_t = embed(t)
h, y_t = ssm_step(A_bar, B_bar, C, D, h, x_t)
outputs.append(y_t)
return torch.stack(outputs)

La beauté est là, dans le code. L'inférence coûte une mémoire et un calcul en O(1) par token, quelle que soit la longueur de la séquence. Pas de cache KV. Pas d'explosion quadratique. Tout l'historique est compressé dans le vecteur d'état caché.

Le piège ? À l'entraînement, exécuter cette récurrence séquentiellement serait terriblement lent. L'astuce est que le même calcul peut être reformulé en convolution ou en scan parallèle, que les GPU gèrent efficacement. On obtient donc un entraînement parallèle et une inférence récurrente : le meilleur des deux mondes.

De Mamba à Mamba-3 : ce que chaque génération a corrigé

Les premiers SSM, comme S4, ont prouvé le concept mais avaient une faiblesse critique : ils ne savaient pas bien raisonner sur le contenu. Les matrices de transition d'état étaient fixes pour toutes les entrées, donc le modèle ne pouvait pas décider quoi retenir et quoi oublier en fonction de ce qu'il lisait réellement. C'est comme prendre des notes avec la règle « noter un mot sur trois » : vous captez de l'information utile, mais vous ne pouvez pas vous adapter à ce qui compte.

Mamba, présenté par Albert Gu et Tri Dao fin 2023, a corrigé ce problème avec une idée élégante : rendre les paramètres du SSM dépendants de l'entrée. Au lieu de matrices A, B, C fixes, Mamba les calcule en fonction du token courant. Le modèle apprend à stocker sélectivement l'information pertinente et à écarter le bruit. Ce mécanisme « sélectif » a donné aux SSM la conscience du contenu qui leur manquait.

Mamba-2 a apporté l'intuition théorique selon laquelle les SSM structurés et l'attention linéaire sont mathématiquement duaux : le cadre de la State Space Duality (SSD). Ce n'était pas qu'académique. Cela a permis des implémentations sensibles au matériel, mieux exploitant les Tensor Cores des GPU, et a fait nettement grimper le débit d'entraînement.

Mamba-3 devient vraiment intéressant d'un point de vue déploiement. Trois innovations comptent avant tout :

Suivi d'état multi-échelle : le modèle maintient un état à plusieurs résolutions temporelles simultanément, capturant à la fois les motifs locaux et les dépendances longue distance sans sacrifier l'un ou l'autre
Compression d'état adaptative : l'état caché se dilate dynamiquement pour les passages de raisonnement complexes et se contracte pour les textes prévisibles, économisant du calcul sans perte de qualité
Meilleure initialisation et gating : la stabilité de l'entraînement à grande échelle s'est nettement améliorée, ce qui compte énormément quand on dépense des millions dans un entraînement

Mamba-3 ne bat pas les transformers sur tous les benchmarks. Il n'en a pas besoin. Il égale la qualité sur la majorité des évaluations standard tout en utilisant une fraction du calcul d'inférence. Pour la plupart des charges de travail en production, c'est le compromis qui compte.

Attention linéaire et convergence avec les SSM

Il existe une piste parallèle qui vaut la peine d'être comprise. L'attention linéaire s'attaque au même problème d'efficacité, mais depuis l'intérieur du cadre transformer. L'attention standard calcule la matrice N×N complète. L'attention linéaire remplace le softmax par une fonction noyau décomposable, puis réorganise le calcul pour ne jamais matérialiser cette matrice quadratique.

# Standard attention: O(N^2 * d)
# score = softmax(Q @ K.T / sqrt(d)) @ V
# Linear attention: O(N * d^2)
# Replace softmax with kernel feature map phi()
# Rearrange: compute K^T @ V first (d×d), then multiply by Q
def linear_attention_step(q_t, running_kv, running_k, k_t, v_t, phi):
"""Incremental linear attention — runs like a recurrence.
This is why SSMs and linear attention are duals:
both compress history into a fixed-size state.
"""
k_feat = phi(k_t)
q_feat = phi(q_t)
running_kv = running_kv + k_feat.unsqueeze(-1) * v_t.unsqueeze(-2)
running_k = running_k + k_feat
y_t = (q_feat @ running_kv) / (q_feat @ running_k + 1e-6)
return y_t, running_kv, running_k

Regardez attentivement ce code. L'attention linéaire, exécutée de manière incrémentale, maintient un état courant et le met à jour avec chaque nouveau token. Ça vous rappelle quelque chose ? C'est normal : elle fait essentiellement la même chose qu'un SSM. Le cadre SSD a formalisé ce lien, et c'est l'un des apports théoriques les plus importants de la recherche récente sur la modélisation de séquences.

Des architectures comme GLA (Gated Linear Attention) et les variantes de RetNet ont poussé cette logique plus loin, en ajoutant un gating dépendant des données qui efface presque complètement la frontière entre attention linéaire et SSM sélectifs. La conclusion pratique : ne voyez pas ces approches comme concurrentes. Elles convergent.

Architectures hybrides : ce qui gagne réellement en production

Voici ce que je dis aux équipes qui me demandent s'il faut passer aux SSM : n'allez pas en mode « tout pur ». Les architectures qui donnent les meilleurs résultats aujourd'hui sont des hybrides qui mélangent des couches SSM et un petit nombre de couches d'attention. Différentes primitives de calcul excellent dans des domaines différents, et faire comme si ce n'était pas le cas, c'est laisser des performances sur la table.

Les couches SSM excellent pour compresser et propager efficacement l'information séquentielle. Les couches d'attention restent inégalées pour la recherche précise et basée sur le contenu : « trouve la ligne exacte de la page 47 qui répond à cette question ». Un hybride bien conçu utilise des SSM pour 80 à 90 % de ses couches et saupoudre de l'attention là où elle compte le plus.

Modèles de type Jamba : alternance de couches Mamba et d'attention, avec des blocs feed-forward MoE, routant dynamiquement entre traitement SSM efficace et attention précise
Architectures de la famille Griffin : unités linéaires récurrentes à gating combinées à une attention locale à fenêtre glissante, de bons résultats avec très peu d'attention complète
Hybrides Mamba-Attention : blocs Mamba-3 pour la plupart des couches, avec des couches d'attention complètes insérées à des profondeurs stratégiques pour router l'information globale
Successeurs de StripedHyena : entrelacement de convolutions à gating, de couches SSM et d'attention parcimonieuse selon des motifs optimisés par NAS

Les chiffres confirment cela. Plusieurs groupes indépendants ont montré qu'une répartition 85/15 entre SSM et attention égale la qualité d'un transformer pur à nombre de paramètres égal, tout en réduisant les FLOPs d'inférence de 40 à 60 %. Les économies de mémoire sont encore plus importantes pour les charges à long contexte. Ce n'est pas une amélioration marginale. C'est diviser par deux votre facture GPU.

Benchmarks de production : là où les SSM tiennent leurs promesses et là où ils ne les tiennent pas

Soyons précis sur les chiffres, parce que les promesses d'efficacité floues ne sont utiles à personne quand il faut prendre une décision de déploiement.

Débit d'inférence : un modèle basé sur Mamba-3 de 8B de paramètres génère des tokens à la même vitesse, que le contexte fasse 1K ou 500K tokens. Un transformer comparable ralentit progressivement à mesure que le cache KV grossit. À 500K de contexte, le modèle SSM offre un débit par GPU 5 à 8 fois supérieur. Ce n'est pas théorique : je l'ai mesuré.

Utilisateurs simultanés : sans cache KV, les modèles SSM peuvent servir beaucoup plus de requêtes simultanées. Sur un seul A100, là où un transformer gère environ 8 flux simultanés à 32K de contexte, un modèle SSM équivalent peut en gérer plus de 30. Pour quiconque fait de l'inférence à grande échelle, c'est le chiffre qui change l'économie du projet.

Vitesse d'entraînement : les gains sont ici plus modestes. Mamba-3 s'entraîne à environ 1,4 fois le débit d'un transformer équivalent sur des clusters H100. L'écart se creuse pour les séquences plus longues : au-delà de 32K tokens, l'entraînement SSM va 2 à 3 fois plus vite, parce qu'on évite complètement l'attention quadratique.

Mais il faut aussi être honnête sur les limites. Sur les tâches qui exigent un rappel verbatim précis dans de longs contextes (« quel était le message d'erreur exact à la ligne 4 382 ? »), les SSM purs restent en retrait. L'état compressé de taille fixe est une représentation avec perte. L'attention, elle, peut simplement revenir aux tokens d'origine. C'est exactement pour cela que les architectures hybrides fonctionnent : les couches d'attention assurent la recherche que les SSM ne savent pas faire.

Là où les SSM restent insuffisants

Je veux être lucide sur les lacunes restantes, parce qu'adopter une nouvelle architecture sur la base d'informations incomplètes est un excellent moyen de perdre six mois.

Apprentissage en contexte : les transformers restent meilleurs pour adapter leur comportement à partir d'exemples few-shot dans le prompt. Les SSM peuvent le faire, mais de façon moins fiable. Si votre application repose fortement sur le prompt engineering avec des exemples, les SSM purs vous décevront.
Maturité de l'écosystème : l'outillage des transformers bénéficie d'années d'optimisation. Les kernels spécifiques aux SSM, l'infrastructure de serving et les bibliothèques de fine-tuning progressent vite, mais ne sont pas encore à parité. Prévoyez du temps d'intégration supplémentaire.
Incertitude du passage à l'échelle au-delà de 70B : les modèles Mamba-3 jusqu'à 70B de paramètres présentent de bonnes courbes d'échelle, mais nous n'avons pas de données solides à la frontière des 200B+. Savoir si les lois d'échelle des SSM tiennent à des tailles extrêmes reste réellement inconnu.
Techniques de fine-tuning : LoRA et QLoRA pour les transformers sont bien maîtrisés. Les appliquer aux architectures SSM demande des approches différentes, et les bonnes pratiques sont encore en train de se stabiliser.
Inadéquation matérielle : les GPU actuels sont optimisés pour les multiplications matricielles que l'attention affectionne. Les SSM reposent fortement sur les scans parallèles, qui tournent assez bien sur le matériel moderne mais ne sont pas l'opération pour laquelle les GPU ont été conçus.

Aucun de ces points n'est rédhibitoire. Ce sont des problèmes d'ingénierie dont on connaît les pistes de solution. Mais ils sont bien réels, et ils doivent entrer dans votre planning.

Recommandations pratiques : quand adopter et comment commencer

Après avoir évalué les SSM sur plusieurs charges de travail en production, voici le cadre que j'utilise pour conseiller les équipes.

Adoptez sans hésiter si votre charge implique de l'inférence à long contexte (régulièrement 32K+ tokens), des exigences de forte concurrence ou un déploiement edge sensible à la latence. Le ROI est substantiel et immédiat. Commencez par une architecture hybride comme Jamba ou un modèle de la famille Griffin plutôt que par un SSM pur : vous obtenez l'essentiel des gains d'efficacité avec moins de risques.

Attendez et observez si votre charge est principalement à contexte court, avec un fort recours à l'apprentissage en contexte, et si vous n'avez pas de pression sur les coûts d'inférence. Les transformers gardent l'avantage dans ce cas, et leur écosystème est plus mature.

Profilez votre charge d'inférence réelle avant de décider : la longueur médiane du contexte et le nombre d'utilisateurs simultanés sont les variables clés
Commencez par des architectures hybrides, pas par des SSM purs : elles présentent moins de risques et permettent tout de même une réduction de 40 à 60 % du coût d'inférence
Faites vos benchmarks sur vos tâches spécifiques : les SSM excellent en résumé et en raisonnement longue distance, mais sont à la traîne sur la recherche exacte
Mettez en place dès maintenant une infrastructure de comparaison d'architectures : il faut mesurer la latence, le débit, la mémoire et le coût par requête, pas seulement la précision
Suivez l'écosystème d'outils SSM tous les trimestres : le rythme des améliorations est tel que ce qui est impraticable aujourd'hui pourrait être prêt pour la production dans trois mois

Le paysage des architectures se fragmente, et c'est une bonne chose

L'époque d'une architecture unique pour tout gouverner touche à sa fin. Nous allons vers un monde où les équipes choisissent leurs primitives de calcul (attention complète, attention linéaire, SSM sélectifs, convolutions à gating) et les composent selon leurs contraintes spécifiques. C'est ainsi que fonctionnent les disciplines d'ingénierie matures. On ne construit pas chaque structure en acier : on choisit les matériaux selon les charges qu'ils doivent supporter.

Le transformer n'est pas mort. Il reste l'architecture la plus éprouvée pour de nombreuses charges et alimentera des systèmes d'IA critiques pendant des années. Mais son monopole sur la modélisation de séquences à l'état de l'art est terminé. Les SSM et les hybrides ont gagné leur place comme outils de production de premier rang, et non comme curiosités de recherche.

Pour ceux d'entre nous qui construisent de vrais systèmes, davantage d'options architecturales signifie de meilleurs outils pour des problèmes précis. Ce n'est pas une disruption à craindre. C'est un levier d'ingénierie à exploiter.