Comment l'architecture Babble à 1 million de tokens de Supermaven traite tout le code sans les lenteurs du chunking RAG

Dans le domaine de la complétion de code en ligne (inline completion), la latence est le critère absolu qui conditionne l'adoption d'un outil. Lorsqu'un développeur tape sur son clavier ou marque une pause pour réfléchir, la suggestion de code doit s'afficher en moins de 250 à 300 millisecondes afin de préserver l'état de concentration et de fluidité (flow state). Tout délai approchant 700 à 1 000 millisecondes brise le rythme de travail, transformant l'assistant intelligent en un obstacle pénalisant.

Pour fournir aux modèles le contexte de projets comportant de multiples fichiers, les premiers assistants de programmation se sont massivement appuyés sur la génération augmentée par récupération (RAG, Retrieval-Augmented Generation). Cependant, le RAG traditionnel impose un compromis technique sévère : la recherche vectorielle, le classement sémantique et la recomposition du prompt consomment des centaines de millisecondes supplémentaires ; en parallèle, le découpage arbitraire du code en segments (chunks) rompt fréquemment les définitions de types, les contrats d'interfaces et les fonctions utilitaires dispersées dans le projet.

Supermaven, fondé par Jacob Jackson (le créateur de Tabnine), a résolu ce goulot d'étranglement grâce à Babble, une architecture de réseau neuronal propriétaire capable de gérer une fenêtre de contexte native de 1 million de tokens. Au lieu de découper et d'indexer dynamiquement le code à chaque frappe au clavier, Supermaven charge l'intégralité du dépôt en mémoire, fournissant des complétions enrichies de tout le contexte du projet en environ 250 millisecondes.

Les impasses du RAG classique dans la complétion en temps réel

Pour comprendre pourquoi Supermaven a fait le choix de concevoir son propre modèle, il convient d'analyser les limites physiques d'un pipeline RAG traditionnel face à l'écriture de code en temps réel.

Un moteur de complétion basé sur le RAG conventionnel enchaîne plusieurs étapes séquentielles à chaque frappe :

[Frappe de touche au clavier]
       │
       ▼
1. Extraction du contexte local (position du curseur, début et fin du fichier actif)
       │
       ▼
2. Recherche vectorielle et lexicale (calcul d'embeddings, recherche ANN en base vectorielle)
       │
       ▼
3. Filtrage et classement des segments (sélection des meilleurs morceaux de code indexés)
       │
       ▼
4. Assemblage du prompt (injection des segments dans une fenêtre étroite de 4k à 8k tokens)
       │
       ▼
5. Inférence du modèle de langage (génération des tokens de complétion)

Dans une interface de chat, attendre 500 millisecondes de plus pour récupérer des documents pertinents passe inaperçu. En revanche, lors de la saisie continue de code dans un éditeur, cet enchaînement d'opérations engendre des ralentissements rédhibitoires.

1. La pénalité de latence cumulée

Chaque étape du RAG requiert du temps de calcul réel. Transformer le code entourant le curseur en vecteur, effectuer une recherche par plus proches voisins (ANN) parmi des dizaines de milliers de segments et réordonner les candidats prend entre 100 et 400 millisecondes. Ce n'est qu'une fois cette phase terminée que le modèle peut amorcer la génération de tokens. C'est la raison pour laquelle les copilotes classiques nécessitent généralement 700 à 900 millisecondes (ou davantage) pour proposer une suggestion.

2. Le découpage brise l'arbre de syntaxe abstraite (AST) et les dépendances

Un texte rédigé en langage naturel peut être scindé en blocs de 300 mots sans altération majeure de son sens. Le code source, en revanche, est régi par un arbre de syntaxe abstraite (AST) et un graphe de dépendances interconnectées :

• Une méthode dans service.ts peut s'appuyer sur une interface générique définie dans types.ts.
• La logique d'un gestionnaire dans routes.py est contrainte par un dictionnaire de configuration dans config.py.
• Des macros et des utilitaires transversaux sont souvent logés au fond d'arborescences complexes.

Quand le code est découpé arbitrairement en tranches de taille fixe, ces liens structurels sont détruits. Si le modèle d'embeddings n'identifie pas le rapport sémantique entre la position actuelle du curseur et une déclaration de type située dans un autre sous-dossier, cette définition est exclue du prompt. Dès lors, le modèle hallucine des noms de méthodes, se trompe dans les types d'arguments ou génère du code qui ne compile pas.

Au cœur de Babble : pourquoi les Transformers échouent et comment la nouvelle architecture les remplace

La méthode la plus directe pour éliminer les faiblesses du RAG consisterait à élargir la fenêtre de contexte afin d'englober l'ensemble du dépôt dans le prompt. Cependant, avec l'architecture Transformer standard, cette approche s'avère irréalisable sur les plans technique et financier pour de la complétion en direct.

Le gouffre de l'attention quadratique

Dans le mécanisme classique d'auto-attention (multi-head self-attention), la charge de calcul lors de l'ingestion du prompt croît de façon quadratique ($O(N^2)$) avec la longueur de la séquence, et l'empreinte mémoire du cache clé-valeur (KV Cache) augmente de façon linéaire avec chaque token. Sur une séquence de 1 million de tokens :

• Le KV Cache d'un Transformer standard de 8 milliards de paramètres consommerait plusieurs dizaines de gigaoctets de mémoire vidéo (VRAM) pour chaque session de développeur active.
• Recalculer l'attention complète sur 1 million de tokens à chaque touche saisie ferait bondir le temps de réponse de quelques millisecondes à plusieurs dizaines de secondes, anéantissant l'interactivité.

Les ruptures architecturales de Babble

Babble a été conçu ex nihilo comme une architecture neuronale sur mesure, pensée pour la modélisation séquentielle de code avec une latence ultra-faible :

1. Intégration de contexte sous-quadratique : Babble fait appel à des mécanismes de modélisation séquentielle (s'inspirant des modèles d'espace d'états ou de récurrences efficientes) plutôt qu'à une attention dense intégrale sur l'ensemble du million de tokens. Cela permet d'assimiler le contexte d'un dépôt massif avec un coût computationnel et une latence comparables à ceux d'un Transformer conventionnel traitant à peine 4 000 tokens.
2. Empreinte mémoire extrêmement légère : En s'affranchissant des volumineux KV Caches traditionnels, Babble réduit drastiquement les ressources mémoire requises sur les serveurs, rendant les calculs à chaque frappe économiquement viables.
3. Entraînement sur des séquences d'édition (Edit Sequences) : La majorité des modèles de code sont entraînés sur des instantanés de fichiers achevés. Babble a été entraîné directement sur des flux d'historiques de modifications de développeurs, semblables à des suites de git diff. Le modèle comprend ainsi non seulement l'état final du code, mais également la trajectoire cognitive d'un ingénieur qui refactorise, renomme ou construit de nouvelles abstractions.

Ingestion du dépôt : comment Supermaven délivre des réponses en 250 ms

Supermaven parvient à maintenir une latence inférieure à la seconde sur 1 million de tokens en dissociant totalement l'ingestion globale du projet de l'inférence à la frappe :

[Ouverture du projet] ──► Prétraitement unique de 10 à 20 s ──► État de contexte précalculé en cache serveur
                                                                        │
[Le développeur tape] ──────────────────────────────────────────────────┴──► Inférence incrémentale directe (≤ 250 ms)

La phase de précalcul initial

Lorsqu'un développeur ouvre son projet dans VS Code, JetBrains ou Neovim, le client léger de Supermaven scanne le code localement en arrière-plan. Pendant les 10 à 20 premières secondes, le système transmet jusqu'à 1 000 000 de tokens de code aux serveurs et génère un état de contexte précalculé en cache (Prefix Caching).

Cette opération se déroule de manière totalement asynchrone sans jamais figer l'éditeur. Dès qu'elle est achevée, le modèle possède une maîtrise intégrale de l'ensemble des APIs internes, des structures de données et des conventions du projet.

L'inférence incrémentale par frappe

Dès que le développeur commence à écrire :

1. Aucune recherche dynamique : Génération d'embeddings, requêtes en base de données et tri de fragments sont totalement éliminés.
2. Réutilisation de l'état en cache : Le moteur d'inférence compare directement les modifications du fichier actif avec l'état du dépôt déjà mémorisé, ne traitant que le différentiel des quelques caractères nouvellement saisis.
3. Rendu instantané à l'écran : Dans les tests de cadence d'affichage (frames) évaluant le délai entre la frappe et l'apparition de la suggestion, Supermaven s'est maintenu avec constance à environ 250 millisecondes (15 frames), surclassant nettement les alternatives :

Validation empirique : 1 million de tokens, est-ce réellement efficace ?

Les modèles dotés de contextes gigantesques souffrent fréquemment du syndrome de « perte au milieu » (Lost in the Middle), où le système mémorise le début et la fin de la séquence tout en négligeant les informations centrales. De plus, un contexte trop large risque d'introduire du bruit parasitant la précision des suggestions.

Supermaven a mené des séries de tests rigoureux pour attester des performances réelles de Babble sur 1 million de tokens :

1. Test de l'aiguille dans une botte de foin (Needle in a Haystack)

Dans cette évaluation synthétique, un commentaire contenant une paire clé-valeur de 8 caractères aléatoires (// needle: vhmpphtv => 'oualsoki') a été disséminé à différentes profondeurs au sein de dépôts contenant de 50 000 à 1 000 000 de tokens.

• Résultat : Babble a affiché un taux de rappel (recall) parfait de 100 % sur l'intégralité du million de tokens, que « l'aiguille » se trouve à 10 %, 50 % ou 90 % du contexte.

2. Récupération dense de clés-valeurs (Dense Retrieval)

Bien plus exigeant qu'un simple commentaire isolé, le test de récupération dense a inséré des centaines d'assertions tout au long d'une séquence de 300 000 tokens :

assert obj['tvdiqaac'] == 'm'
assert obj['qacbblfk'] == 'c'
# Milliers de tokens intermédiaires...
assert obj['tvdiqaac'] == 'm'

Invité à compléter la valeur d'une clé récurrente, Babble a préservé une précision comprise entre 75 % et 100 % malgré des écarts de plusieurs dizaines de milliers de tokens, confirmant sa capacité à mémoriser des liaisons de variables complexes dans la durée.

3. Perte de prédiction en fonction de la taille du contexte

Afin de valider l'apport de ce contexte sur du code authentique, Supermaven a évalué Babble sur l'intégralité du dépôt officiel de PyTorch (en moyennant sur 200 ordres de fichiers aléatoires).

• Constat : La perte de prédiction du token suivant (prediction loss) a diminué de manière continue et régulière à mesure que la fenêtre s'étendait vers 1 million de tokens. Loin d'être perturbé par l'abondance de fichiers, Babble a su convertir ce contexte étendu en complétions plus précises.

Tableau comparatif : Contexte natif 1M vs RAG classique

Évolution technologique et impact sur l'écosystème

En novembre 2024, Anysphere (l'éditeur de Cursor) a fait l'acquisition de Supermaven. L'équipe de Cursor a compris que, si les modèles généralistes de pointe excellent dans le raisonnement d'agents multifichiers, les complétions ultrarapides à la touche Tab requièrent des modèles de séquences hyperspécialisés et une pile d'inférence optimisée pour la vitesse pure.

La technologie propriétaire de Supermaven et son savoir-faire du contexte long à latence minimale ont été intégrés directement au sein de Cursor Tab, mariant l'analyse syntaxique de Cursor à l'efficacité d'exécution de Babble. Par la suite, Supermaven a programmé en novembre 2025 l'arrêt progressif (sunsetting) de son service commercial autonome, garantissant la gratuité des inférences pour ses utilisateurs historiques sous Neovim et JetBrains et orientant les utilisateurs de VS Code vers Cursor.

Enseignement pour les développeurs

L'architecture Babble de Supermaven a mis en lumière un principe clé d'ingénierie logicielle : pour les tâches interactives où la latence est critique comme la complétion de code, les architectures séquentielles optimisées dotées d'un contexte natif ultra-long surpassent nettement les pipelines RAG traditionnels. En éliminant le découpage en morceaux et les délais de recherche vectorielle, Babble a prouvé qu'il est possible de conjuguer une vision globale du projet avec une réactivité quasi instantanée de 250 ms.

Références

• Introducing Supermaven, the first code completion tool with a 300,000-token context window
• Benchmarking Supermaven's Long-Context Capabilities
• Announcing Supermaven 1.0
• Supermaven joins Cursor
• Sunsetting Supermaven