Subquadratic vs LLM classiques : quels modèles gagnent en 2026 ?

Des LLM capables de gérer 1 million de tokens de contexte en restant temps réel, avec des coûts mémoire divisés par 3 à 10 : ce n’est plus un slide de conférence, c’est la promesse des approches dites subquadratic. Depuis 2024, les papiers sur l’attention linéaire, les architectures “state-space” et les KV-caches optimisés se multiplient.

En 2026, la vraie question n’est plus “est-ce que ça marche ?”, mais “est-ce que ces modèles rivalisent vraiment avec les architectures traditionnelles de type Transformer quadratique sur la qualité, le coût et la production ?”.

Ce comparatif fait le point sur ce que l’on sait factuellement en 2025-2026 : architectures, benchmarks publiés, coûts, limites, et où en sont les premiers modèles réellement déployés à grande échelle.

Subquadratic en 2026 : de la théorie à des modèles vraiment déployés

Les modèles subquadratic cherchent à faire sauter le verrou fondamental des Transformers : la complexité en O(n²) de l’attention en fonction de la longueur de séquence n.

💡 À retenir : depuis 2023, une partie significative de la recherche LLM de pointe vise à réduire la complexité de l’attention ou à la remplacer complètement.

En 2025-2026, plusieurs familles d’approches sont devenues centrales :

• Attention approximative / factorisée : FlashAttention, Longformer, BigBird, Performer, etc., qui réduisent la complexité effective via sparsification ou projections.
• Architectures state-space (SSM) : Mamba, Mamba-2, Hyena, Mixture-of-SSM, qui remplacent tout ou partie de l’attention par des blocs séquentiels sous-quadratiques.
• Hybrides Transformer + SSM : modèles combinant blocs d’attention locaux ou globales et couches SSM pour profiter des deux mondes.
• KV-cache et variantes de decoding subquadratic : optimisations pour l’inférence auto-régressive à long contexte.

Quelques jalons clés (2023-2025)

• 2023 : Google présente FlashAttention-2, avec des gains de vitesse d’un facteur 2-4 selon les séquences, utilisé ensuite dans de nombreux LLM open source.
• Décembre 2023 : la première version de Mamba (modèle SSM) est introduite par des chercheurs de Carnegie Mellon et de Princeton, avec une complexité linéaire en la longueur de séquence.
• 2024 : plusieurs travaux montrent que des modèles Mamba ou hybrides peuvent atteindre des performances proches de Transformers sur des benchmarks de langage, tout en supportant des contextes plus longs avec moins de mémoire GPU.
• 2024-2025 : premiers LLM commerciaux/industriels exploitant des blocs SSM ou des variantes subquadratic pour l’allongement de contexte et l’inférence plus efficiente (chez de grands acteurs cloud et quelques startups spécialisées).

Ces travaux ne remplacent pas les Transformers partout, mais ils redéfinissent le paysage pour des cas d’usage comme la recherche dans de très grands documents, les agents “mémoire longue” ou les workloads de génération à fort volume.

Transformer quadratique vs subquadratic : ce que ça change mathématiquement

Les Transformers classiques reposent sur une self-attention dont le coût mémoire et calcul est proportionnel à n² pour une séquence de longueur n. Sur un contexte de 128k tokens, ce terme n² devient exponentiellement contraignant pour les GPU actuels.

💡 À retenir : le passage à des modèles subquadratic ne consiste pas seulement à “accélérer un peu l’inférence”, mais à changer le scaling fondamental avec la longueur de contexte.

Complexité : Transformer vs subquadratic

En simplifiant :

• Transformer standard :
• Complexité attention ≈ O(n² · d) où d est la dimension.
• Mémoire pour la matrice attention ≈ O(n²).
• Approches subquadratic :
• Attention sparse / locale : O(n · k · d), k ≪ n (k voisinage local ou quelques tokens globaux).
• Attention linéaire (Performer, etc.) : O(n · d²) ou O(n · d · r) avec r dimension de projection.
• State-space models (Mamba & co) : O(n · d²) ou parfois O(n · d) selon l’implémentation.

En pratique, sur des séquences très longues (plusieurs centaines de milliers de tokens), ces architectures permettent de :

• maintenir le temps d’inférence quasi linéaire avec la longueur de séquence ;
• réduire drastiquement la consommation mémoire par séquence, donc accueillir plus de requêtes en parallèle sur une même carte GPU ;
• limiter le coût d’extension du contexte (passer de 128k à 1M de tokens) sans multiplier le budget GPU par 10.

Benchmarks qualité : les subquadratic tiennent-ils la route ?

La grande question côté entreprises n’est pas seulement “est-ce que c’est plus rapide ?”, mais “est-ce que c’est aussi bon (ou meilleur) sur les tâches de langage complexes ?”.

💡 À retenir : sur les benchmarks standard type MMLU, BIG-Bench ou GSM8K, les meilleurs Transformers restent la référence, mais les architectures subquadratic comblent progressivement l’écart.

Qualité sur les benchmarks de langage

Les travaux académiques récents sur les SSM (dont Mamba et ses successeurs) montrent généralement :

• des scores proches mais souvent légèrement inférieurs aux meilleurs Transformers de taille comparable sur des benchmarks globaux de compréhension de langage ;
• en revanche, des gains marqués sur les tâches nécessitant des contextes très longs (résumé de documents massifs, QA multi-documents, codebase entière) où les Transformers classiques doivent tronquer ou chunker agressivement.

Les tendances observées dans les papiers :

• Sur des benchmarks type MMLU (évaluation multi-domaines), les modèles SSM ou hybrides atteignent des scores très proches des Transformers quand la taille de modèle est la même et les données d’entraînement comparables.
• Sur des tâches de long context retrieval (par exemple, retrouver une information précise dans un document de 256k tokens ou plus), les modèles subquadratic avec mémoire séquentielle montrent une meilleure robustesse à l’augmentation du contexte.

💡 À retenir : sur des tâches “classiques” à court ou moyen contexte (chat, code sur petits fichiers, rédaction), les Transformers haut de gamme gardent une légère avance ; sur les contextes extrêmes, les architectures subquadratic deviennent souvent préférables.

Coûts et efficacité : GPU, dollars et latence

L’intérêt principal des modèles subquadratic en production, ce n’est pas la beauté mathématique, c’est l’économie d’infrastructure.

💡 À retenir : sur des contextes très longs (≥128k tokens), les approches subquadratic peuvent réduire la consommation mémoire par requête d’un facteur 3 à 10 par rapport à une attention dense naïve, ce qui se traduit directement en coûts GPU plus bas.

Capex et Opex GPU

Côté matériel, l’inférence LLM repose massivement sur des GPU haut de gamme :

• NVIDIA H100 : largement déployés en 2024-2025, avec un prix de marché qui a souvent dépassé 30 000 $ la carte sur le marché secondaire lors des pics de demande.
• NVIDIA B100 / B200 : prévus ou attendus pour des déploiements de plus en plus larges à partir de 2025, avec des promesses d’efficacité encore accrue pour les workloads Transformer.

Les architectures subquadratic permettent de :

• héberger plus de requêtes simultanées par GPU (grâce à la réduction mémoire) ;
• diminuer la taille de cluster nécessaire pour servir un volume donné de requêtes longue séquence ;
• permettre à des acteurs plus petits de proposer des contextes longs sans aligner des dizaines de millions de dollars d’infrastructure.

Coût par requête : ordre de grandeur

Les coûts par requête varient suivant : taille du modèle, longueur de contexte, fournisseur cloud, optimisations logicielles, etc. Mais les études d’optimisation LLM indiquent souvent :

• pour des Transformers classiques avec contexte long (128k+), le coût d’une requête peut être multiplié par 3 à 5 par rapport à une requête 8k-16k, simplement à cause de la complexité quadratique ;
• des architectures subquadratic (attention sparse, SSM, hybrides) réduisent cet “explosion cost” et ramènent souvent le surcoût à un facteur ≈1,5 à 2 pour passer de 16k à 128k+.

Pour un fournisseur facturant l’accès à son API en $/million de tokens, cela se traduit par la possibilité :

• soit de garder un prix stable tout en augmentant fortement le contexte ;
• soit de baisser les prix sur les usages à long contexte tout en conservant des marges acceptables.

Comparatif structuré : subquadratic vs modèles traditionnels

Le tableau suivant synthétise les grandes différences entre LLM basés sur Transformers classiques et LLM intégrant des architectures subquadratic (SSM, attention linéaire ou sparse, hybrides), dans une configuration typique de déploiement en 2025-2026.

Mise en production : où les entreprises adoptent déjà le subquadratic

Sur le terrain, l’adoption ne se fait pas via un “switch” complet vers une nouvelle famille d’architectures, mais par des composants subquadratic intégrés dans des pipelines existants.

💡 À retenir : en 2026, beaucoup de cas d’usage en prod utilisent déjà des briques subquadratic… parfois sans que les équipes métier le sachent explicitement.

Allongement de contexte dans les LLM commerciaux

Les principales familles de produits où ces approches trouvent leur place :

• Modèles spécialisés long contexte : LLM dédiés à la recherche documentaire ou à l’analytics sur de très gros volumes (logs, documents juridiques, data techniques) exploitent des architectures plus efficaces que l’attention dense classique.
• Moteurs RAG avancés : certains moteurs de recherche augmentée par génération intègrent des blocs SSM ou des schémas d’attention sparsifiée pour gérer des contextes agrégés très volumineux.
• Outils développeurs : assistants de codage capables d’absorber des repositories entiers ou des monorepos volumineux tirent profit de modèles subquadratic pour garder la latence acceptable.

Pattern d’architecture typique

Plutôt que de tout réécrire en “Mamba from scratch”, les équipes d’ingénierie font souvent :

• des modèles hybrides : quelques couches d’attention globale ou locale en haut/bas du réseau, et des blocs subquadratic au milieu ;
• du routing : modèles Transformers classiques pour les requêtes courte/moyen contexte, et modèles subquadratic réservés aux requêtes nécessitant un contexte ultra-long ;
• de l’offloading / compression de contexte via SSM : utiliser un composant subquadratic pour compacter ou “résumer” dynamiquement le contexte, qui est ensuite passé à un Transformer classique.

Avantages concrets pour devs, data teams et ops

Les bénéfices des architectures subquadratic sont très concrets pour les équipes qui exploitent des LLM en production.

💡 À retenir : le principal gain n’est pas uniquement “plus de tokens”, mais plus de flexibilité de design produit sans exploser les coûts.

Pour les développeurs

• Possibilité de concevoir des fonctionnalités qui utilisent des historiques très profonds (sessions multi-jours, threads complexes, contextes partagés entre agents) sans être forcé de tronquer agressivement.
• Meilleure gestion des gros fichiers (PDF techniques, docs juridiques, codebases), avec moins de hacks côté client (chunking manuel, prompts très complexes).
• Plus de marge pour expérimenter des prompts riches, des instructions structurées et des contexts “out-of-the-box”.

Pour les data/ML engineers

• Réduction de la pression sur les GPU : possibilité d’augmenter le nombre de requêtes simultanées par machine pour les workloads long contexte.
• Plus de flexibilité pour :
• ajuster la fenêtre de contexte par cas d’usage sans recalculer tout le budget infra ;
• intégrer des tâches nouvelles (analyse de logs, reasoning sur historique complet, etc.) dans le même cluster.
• Intégration progressive dans des pipelines existants, via des modèles hybrides ou des routes spécialisées.

Pour les équipes Ops / FinOps

• Meilleure prévisibilité du coût par requête : quand la complexité est quasi-linéaire en la longueur de séquence, il est plus simple d’établir un pricing interne ou externe cohérent.
• Possibilité de proposer des plans tarifaires différenciés basés sur des niveaux de contexte (par exemple : 16k, 128k, 1M) sans multiplication exagérée du coût.
• Optimisation des SLA de latence : moins de variance extrême sur les requêtes très longues, donc plus simple à industrialiser.

Limites, risques et zones d’ombre en 2026

Les approches subquadratic ne sont pas magiques, et plusieurs limites restent importantes en 2026.

💡 À retenir : on gagne en efficacité, mais pas sans compromis : maturité moindre, tooling incomplet, comportement parfois moins bien compris que les Transformers.

Maturité et tooling

• Les Transformers bénéficient de près de 7 ans de maturité industrielle (depuis 2017), avec un écosystème extrêmement robuste.
• Les architectures SSM et certaines variantes d’attention subquadratic récentes ont beaucoup moins de recul :
• moins de frameworks de fine-tuning prêt-à-l’emploi ;
• tooling MLOps parfois incomplet (monitoring, debugging, explainability) ;
• moins de retours d’expérience publiés sur des déploiements massifs et critiques.

Qualité et comportement

• Sur des tâches standard (chat généraliste, reasoning complexe, génération créative), les meilleurs modèles Transformer restent souvent une référence de facto.
• Certains travaux signalent que :
• les modèles SSM peuvent avoir des dynamiques d’apprentissage différentes, parfois plus sensibles à certains hyperparamètres ;
• le “reasoning long terme” dans une séquence très longue reste difficile à évaluer systématiquement, y compris pour les architectures subquadratic.

Intégration et portabilité

• Portage de modèles : on ne peut pas simplement “convertir” un Transformer existant en SSM ou en attention linéaire sans réentraînement massif.
• Compatibilité : les pipelines conçus autour de Transformers (prompting, RAG, outils spécifiques) demandent parfois des ajustements non triviaux.

💡 À retenir : pour la plupart des entreprises, le passage au subquadratic ne ressemble pas à une migration brute, mais à une cohabitation durable de plusieurs architectures.

Notre avis : qui doit basculer vers le subquadratic en 2026 ?

En 2026, la fracture n’est pas entre “ceux qui ont des LLM Transformers” et “ceux qui ont des LLM subquadratic”, mais entre :

• les acteurs qui continuent de traiter le long contexte comme un cas extrême marginal,
• et ceux qui en font un élément central de leurs produits.

💡 À retenir : si votre valeur métier dépend de la capacité à exploiter des contextes massifs (documents, code, historiques, logs), ignorer le subquadratic devient un vrai handicap compétitif.

Pour Brief IA, la position est la suivante :

• Vous devriez explorer sérieusement les modèles subquadratic si :

• vos cas d’usage impliquent régulièrement des contextes ≥128k tokens (analyse documentaire, legaltech, observabilité, outils dev de nouvelle génération) ;

• vous investissez déjà des budgets significatifs dans des clusters GPU pour des tâches de long contexte ;

• votre roadmap produit repose sur des agents ou des workflows à mémoire longue.

• Vous pouvez rester majoritairement sur des Transformers classiques si :

• vos usages sont principalement du chat généraliste, du support client, de la génération de texte marketing ou du code sur petits fichiers ;

• votre contrainte principale est la qualité de génération sur des contextes courts à moyens plutôt que la profondeur de mémoire ;

• vous bénéficiez d’un écosystème existant très solide autour d’un modèle Transformer précis (stack outillée, fine-tuning, RAG, gouvernance).

À horizon 6-12 mois, il est raisonnable d’anticiper :

• une multiplication des modèles hybrides mêlant attention classique, attention sparse et SSM dans un même backbone ;
• une intégration plus large de backends subquadratic dans les principaux frameworks open source (fine-tuning, RAG, orchestration d’agents) ;
• une bascule progressive où les architectures quadratiques pures deviennent minoritaires sur les cas d’usage long contexte haute valeur.

La vraie question stratégique pour les équipes tech n’est donc plus “Transformer ou subquadratic ?”, mais :

Comment adapter vos produits et votre stack pour profiter de la flexibilité de contexte que ces nouvelles architectures rendent possible, sans sacrifier la qualité et la robustesse que vous offrent les Transformers ?