SubQ AI expliqué : que vaut vraiment le LLM à fenêtre de contexte 12 M ?

Le 5 mai 2026, une petite startup basée à Miami, Subquadratic, a lancé un modèle nommé SubQ. L’équipe est réduite, mais elle a levé 29 M$ en amorçage et affirme que le modèle peut traiter jusqu’à 12 millions de tokens en un seul passage.

Elle avance aussi d’autres chiffres impressionnants, comme un modèle jusqu’à 52 fois plus efficace que FlashAttention à 1 million de tokens, et des performances en code proches de Claude Opus pour environ 1/20e du coût.

Ce sont des déclarations ambitieuses, il est donc logique de décortiquer pour comprendre ce qui se joue réellement. Dans cet article, je passe en revue ce qu’est SubQ, comment fonctionne son architecture, et ce que les premiers éléments et retours des développeurs laissent penser de ces promesses.

Qu’est-ce que SubQ ?

SubQ est le LLM de Subquadratic, sorti le 5 mai 2026, construit autour d’un atout phare : une fenêtre de contexte de 12 millions de tokens. C’est le premier modèle commercialisé par l’entreprise, accompagné d’assertions audacieuses en matière d’efficacité et de coût qui suscitent déjà un débat nourri. 

Le modèle n’est pas encore accessible publiquement : l’API, SubQ Code et SubQ Search ne sont disponibles qu’en accès anticipé via une liste d’attente.

Il repose sur une approche appelée SSA, pour Subquadratic Sparse Attention.

Au lieu de comparer chaque token à tous les autres, comme le fait l’attention dense standard, la SSA adopte une sélection. Pour chaque token, le modèle choisit les tokens les plus pertinents et calcule les relations uniquement au sein de ce sous-ensemble.

Cela a deux effets évidents.

• Premièrement, cela réduit le nombre de calculs, ce qui améliore directement l’efficacité et diminue les coûts. 
• Deuxièmement, la sélection dépend du contenu. Le modèle ne se limite donc pas aux tokens voisins : il peut aller chercher des tokens pertinents n’importe où dans la séquence, même s’ils sont éloignés.

Qu’est-ce qui distingue SubQ ?

Concrètement, l’architecture SSA pousse le modèle à se concentrer sur ce qui compte vraiment au lieu de tout traiter uniformément. L’objectif est d’obtenir une précision similaire à l’attention pleine, avec des besoins en calcul et en mémoire nettement inférieurs.

Commençons par regarder de plus près l’attention dense, puis comparons les deux approches.

Le problème de l’échelle quadratique dans les transformers

Les modèles actuels comme GPT, Claude et Gemini reposent sur l’attention dense. En bref, chaque token est comparé à tous les autres tokens de l’entrée. À mesure que l’entrée grandit, le nombre de comparaisons croît de façon quadratique.

Prenez un long document et imaginez que le modèle doive générer le dernier mot. Il remonte tous les tokens du document, établit des relations, puis décide de la suite. C’est ce qui fait la force de l’attention dense : elle tient compte de tout.

Mais cette force a un coût. Lorsque la taille d’entrée augmente, les besoins en calcul et en mémoire explosent, créant des limites de fenêtre de contexte. En termes simples, la complexité est en O(n²), où n est le nombre de tokens.

C’est pourquoi la plupart des modèles restent dans des bornes pratiques. Sur les modèles standard, 128k tokens est la norme, et les modèles les plus puissants comme Claude Opus plafonnent à 1 million de tokens de contexte.

Pour contourner cela, la plupart des systèmes IA évitent d’envoyer des jeux de données complets au modèle. Ils s’appuient plutôt sur des techniques comme :

• RAG (Retrieval-Augmented Generation) : stocker les données en externe, récupérer uniquement les passages pertinents et les injecter dans le modèle.
• Découpage (chunking) : scinder un long texte en morceaux plus petits et n’envoyer que les segments pertinents.
• Stratégies de synthèse : compresser un contenu long et fournir des résumés au modèle plutôt que le texte intégral.

Pour aller plus loin sur les mécanismes d’attention, consultez ce tutoriel sur le mécanisme d’attention dans les LLM. Pour une mise en pratique des briques des LLM modernes, je vous recommande notre cours Transformer Models with PyTorch.

La différenciation de SubQ

L’attention dense croît quadratiquement avec la taille d’entrée, tandis que la SSA est conçue pour évoluer de façon sous-quadratique, plus proche de O(n·k) plutôt que O(n²), où k est le nombre de tokens sélectionnés à chaque étape. Lorsque k reste petit par rapport à n, c’est bien plus efficace que l’attention pleine.

Schéma comparant l’attention quadratique et linéaire, avec des connexions denses tous-à-tous versus des connexions clairsemées et sélectives.

La crainte évidente, c’est la précision. Si le modèle ne regarde qu’une partie de l’entrée, il peut rater des relations importantes. Ce compromis explique en général l’existence de l’attention dense.

SubQ affirme que ce compromis ne se manifeste pas en pratique. Selon Subquadratic, le modèle porte attention à tous les tokens nécessaires, même s’ils sont éloignés du token courant, et maintient une précision comparable aux meilleurs modèles.

Comment fonctionne la Subquadratic Sparse Attention ?

On sait désormais qu’au lieu de comparer chaque token à tous les autres, la SSA sélectionne uniquement les tokens utiles dans la séquence et calcule l’attention sur ces positions. Voyons comment cette sélection s’opère.

La sélection des relations pertinentes par la SSA

La SSA utilise un routage dépendant du contenu. En simplifiant, elle choisit les tokens en fonction de leur pertinence vis-à-vis du token courant. Elle calcule un score de similarité entre tokens, du type similarity(query_i, key_j), et ne conserve pour l’attention que les k meilleurs scores.

Avec l’entraînement, le modèle apprend à prioriser les tokens signifiants et à ignorer le bruit : mots-clés, entités importantes, tokens porteurs de signaux contextuels forts.

La SSA ne dépend pas uniquement du contenu : elle préserve aussi des relations structurelles de la séquence. Par exemple, les tokens proches reçoivent toujours de l’attention via des schémas locaux, tandis que certains tokens « globaux » sont conçus pour couvrir l’ensemble de la séquence.

La SSA intègre également des techniques d’attention hiérarchiques et par regroupement (clustering). Elle regroupe des tokens similaires et calcule l’attention au niveau des groupes les plus pertinents. Le modèle n’a donc pas besoin d’évaluer chaque token individuellement : il peut raisonner d’abord au niveau des groupes, puis zoomer sur les tokens d’un cluster au besoin.

Un entraînement pensé pour le long contexte

Une grande fenêtre de contexte ne fait pas tout. Même avec 12 millions de tokens, le modèle doit apprendre à exploiter efficacement ce contexte. La SSA est entraînée en ce sens :

• Pré-entraînement : le modèle de base est entraîné sur des jeux de données massifs et variés, avec des représentations long-contexte. 
• Ajustement supervisé (fine-tuning) : le modèle est ensuite travaillé sur des tâches structurées, dont le raisonnement et la génération de code. 
• Apprentissage par renforcement : plutôt que de se limiter aux tokens voisins (attention locale), cette étape pousse le modèle à exploiter les tokens pertinents sur l’ensemble du texte (attention globale).

Cette phase par renforcement est particulièrement importante pour les cas d’usage de codage en entreprise. Elle permet au modèle de considérer un contexte plus large d’un coup, l’ensemble d’une base de code dans ce cas, tout en générant la sortie.

Benchmarks et performances de SubQ

Notez que « SubQ 1M-Preview » désigne la version évaluée à 1 million de tokens. La fenêtre complète de 12 millions est accessible via l’API.

Sur les trois benchmarks publiés par Subquadratic, SubQ 1M-Preview rivalise avec Claude Opus 4.7, GPT-5.5 et Gemini 3.1 Pro. 

Mais la sélection est étroite : exactement trois tests, tous centrés sur la récupération en long contexte et le codage, les deux axes sur lesquels SubQ est explicitement optimisé. Aucune évaluation plus large n’a été publiée sur le raisonnement général, les maths, le multilingue ou la sécurité.

La fiche complète du modèle est indiquée comme « à venir » sur le site, nous pouvons donc attendre plus de benchmarks sur des cas d’usage généraux.

Pour l’heure, voici les résultats sur la récupération long-contexte et les cas de codage :

Ce que montrent les chiffres

RULER 128K : SubQ obtient 95 % contre Opus 4.7 à 94,8 %. La différence de précision est négligeable, mais l’enjeu ici, c’est le coût : Subquadratic affirme que cet eval a coûté environ 8 $ sur SubQ, contre quelque 2 600 $ sur Opus à même longueur de contexte.

MRCR v2 (8-needle, 1M) : ce benchmark teste la capacité du modèle à retrouver et suivre 8 faits distincts disséminés dans un contexte d’1 million de tokens. SubQ affiche un résultat de recherche de 83 %, mais le score en production tombe à 65,9 %. Cet écart d’environ 17 points entre labo et déploiement est notable et reste inexpliqué. Malgré cela, SubQ reste compétitif face à GPT-5.5 (74,0 %) et largement devant Claude Opus 4.7 (32,2 %) et Gemini 3.1 Pro (26,3 %).

SWE-Bench Verified : SubQ atteint 81,8 %, devant Opus 4.6 à 80,8 %, mais derrière Opus 4.7 à 87,6 %. Les marges face à Opus 4.6 sont faibles et sensibles au protocole de test. Face à Opus 4.7 et GPT-5.5, SubQ est clairement en retrait.

À 12 millions de tokens : SubQ aurait dépassé 90 % sur des tâches « aiguille dans une botte de foin » à 12 millions de contexte, mais ce chiffre n’a pas été vérifié sur des benchmarks officiels. Aucun autre modèle de pointe n’a été testé à cette longueur, il n’y a donc pas de comparaison directe. C’est le résultat architecturalement le plus intrigant du lancement, mais il nécessite une reproduction indépendante avant toute conclusion.

Conséquences pour le RAG, les agents de code et les coûts de l’IA

Si l’architecture de SubQ tient l’échelle, elle change la façon de construire les systèmes LLM. Un contexte plus long devient praticable, réduisant le besoin de découpage agressif, de récupération et d’optimisation de tokens. Voyons ces changements de plus près.

Quand le RAG devient optionnel

Depuis deux ans, la Retrieval-Augmented Generation (RAG) s’impose comme réponse par défaut à une limite fondamentale des LLM : les modèles ne peuvent pas tout lire d’un coup. Si votre base de connaissances dépasse la fenêtre de contexte, vous segmentez les documents, les encodez, les stockez dans une base vectorielle, récupérez les passages les plus pertinents et n’envoyez au modèle que ces fragments avec l’invite.

Tout cet écosystème existe parce que le contexte est une ressource rare.

Lorsqu’un modèle peut traiter de manière fiable des millions de tokens en un seul passage, bon nombre de couches d’ingénierie construites autour de la récupération deviennent moins nécessaires pour certains flux. Au lieu d’investir dans la sélection des bons segments à récupérer, le système peut ingérer directement la matière brute et raisonner de bout en bout.

Au-delà de la fenêtre de contexte, le RAG reste toutefois clé pour :

• Mémoire inter-session : les LLM n’ont aucun souvenir une fois la session terminée. Si un utilisateur revient, le modèle repart de zéro. Les systèmes de récupération (ou bases de données) conservent les éléments importants (décisions passées, documents, données utilisateur) pour que le modèle s’en serve plus tard.
• Permissions et contrôle d’accès : les systèmes de récupération appliquent des règles comme « cet utilisateur ne voit que les données de son équipe ». Le modèle ne reçoit ainsi que des documents autorisés, évitant les fuites accidentelles.
• Auditabilité : en entreprise, il ne suffit pas de répondre ; il faut justifier. Les systèmes de récupération peuvent pointer vers les documents ou sources utilisés, pour vérifier et diagnostiquer en cas de problème.
• Gestion structurée des connaissances : les entreprises ajoutent, mettent à jour et suppriment sans cesse des documents. Les embeddings et l’indexation organisent ces données pour que le modèle retrouve rapidement l’information la plus récente et pertinente, sans tout retraiter à chaque fois.

Pour une approche intéressante visant à doter les agents d’une mémoire persistante, lisez notre tutoriel Supermemory, dans lequels vous apprenez à créer un coach sportif avec mémoire court et long terme.

Flux de travail de codage en long contexte

Aujourd’hui, la plupart des modèles de code ne voient pas l’ensemble de la base. On ajoute donc des couches par-dessus : recherche de fichiers, découpage, classement, planification multi-étapes, simplement pour garder le bon contexte en fenêtre et tisser des liens entre fichiers.

Avec la fenêtre 12 M de SubQ, la base de code complète est chargée d’un coup. Cela simplifie sensiblement la conception des agents.

• La planification devient globale : le modèle raisonne sur l’architecture, les dépendances et les interactions inter-fichiers sans rater de contexte.
• L’exécution est plus cohérente : les modifications multi-fichiers peuvent être coordonnées en un passage, plutôt qu’en mises à jour incrémentales.
• La revue est plus fiable : le modèle vérifie ses propres changements à l’échelle de toute la base, réduisant les incohérences.

Économie des coûts

Dans les transformers classiques, l’attention croît de façon quadratique avec la longueur de séquence. Doubler le contexte ne double pas le coût : il peut être multiplié par quatre.

SubQ affirme rompre ce compromis.

• Il annonce un coût ~1/20 de celui des modèles de pointe comparables (Claude Opus)
• Et jusqu’à ~1 000× de réduction de calcul à 12 millions de tokens de contexte

Si cela se confirme en production, le traitement long-contexte cesse d’être un cas limite onéreux et devient un usage courant.

Mais une grande fenêtre de contexte, bon marché ou non, doit être exploitée efficacement. D’après les benchmarks, SubQ revendique une précision comparable pour un coût bien inférieur, mais il est trop tôt pour conclure.

Comment accéder à SubQ ?

SubQ n’est pas encore disponible publiquement. Les trois produits — l’API, SubQ Code et SubQ Search — sont en bêta privée, et l’accès nécessite une demande d’early access sur le site de SubQ.

Du point de vue développeur, l’API est conçue pour s’intégrer facilement. Elle prend en charge :

• les réponses en streaming
• l’appel d’outils/fonctions
• des endpoints compatibles OpenAI

Autrement dit, si votre pile exploite déjà des API de type OpenAI, vous n’avez en général pas besoin de réécrire l’intégration.

SubQ Code se positionne comme un agent de codage en ligne de commande, tandis que SubQ Search cible la recherche long-contexte pour des travaux d’investigation poussés. Voyez-les comme les équivalents SubQ de Claude Code et Perplexity. 

La tarification n’est pas non plus transparente à ce stade. Il n’y a pas de tarifs par token publiés, ce qui rend difficile la validation indépendante des promesses de coûts.

Scepticisme et questions ouvertes

Dans les heures qui ont suivi le lancement, les réactions sceptiques et mitigées se sont multipliées sur les réseaux et les forums comme Hacker News. Le débat est partagé : certain·e·s y voient une vraie percée, d’autres parlent d’un « Theranos de l’IA » (référence à la startup d’analyses sanguines ayant fait de fausses promesses technologiques).

Les principaux doutes portent sur :

• Ils revendiquent une fenêtre de 12 millions de tokens, mais tous les benchmarks partagés sont à 1 million.
• Le nom de l’entreprise est Subquadratic, mais certains passages évoquent une échelle proche de O(1). Avec O(1), on s’attendrait à bien plus qu’une fenêtre de 12 millions de tokens. Même O(log n) permettrait des limites plus élevées.

Un récit similaire avait émergé autour de Magic.dev en 2024. L’entreprise avançait de très grandes fenêtres de contexte (jusqu’à 100 millions de tokens) et de forts gains d’efficacité, notamment pour le codage. 

Le pitch était presque identique : charger des bases de code entières, réduire la complexité de la récupération, simplifier la conception des agents. Mais publiquement, l’issue a été plus discrète. Malgré environ 500 M$ levés, on observe encore peu de visibilité ou d’adoption réelle début 2026.

Ce qui a été vérifié

Les affirmations de SubQ ne sont pas purement théoriques. Subquadratic indique que les benchmarks RULER, MRCR v2 et SWE-Bench Verified ont été réalisés par un service tiers, montrant de bonnes performances en récupération long-contexte et des résultats compétitifs en codage. 

Cependant, ces résultats n’ont pas encore été reproduits indépendamment par des chercheurs externes, et le périmètre d’évaluation reste étroit. Les trois benchmarks mettent l’accent précisément sur les domaines pour lesquels SubQ est conçu (extraction de signaux dans un grand contexte et fonctionnement sur du code).

Autre détail important : l’architecture. Le CTO a confirmé que SubQ n’entraîne pas de modèles from scratch, mais s’appuie sur des bases open source (probablement des familles comme DeepSeek ou Kimi). Un choix pragmatique pour une petite équipe : itérer plus vite et réduire les coûts d’entraînement. Cela signifie aussi que l’innovation principale n’est pas le modèle de base lui-même, mais le mécanisme d’attention et l’ingénierie système autour.

Conclusion

SubQ est arrivé avec des promesses très ambitieuses. La direction est claire : lever la contrainte de la fenêtre de contexte et permettre aux modèles de traiter des entrées bien plus vastes. Subquadratic positionne SubQ comme égalant ou dépassant les modèles de pointe en codage et en récupération long-contexte, pour un coût nettement inférieur.

Cela dit, c’est encore le début. Nous attendons toujours la fiche modèle complète pour une visibilité plus large sur ses capacités et ses tests. Les produits construits dessus, SubQ Code et l’API, ne sont pas encore publics. J’ai hâte de les prendre en main et de voir comment ces promesses tiennent en production.