Au cours des derniers mois, nous avons développé un système multi-agent capable de créer, maintenir et déployer de manière autonome des logiciels complexes. Dans le cadre de ce travail, nous avons testé le système dans divers domaines, notamment en lui faisant créer un navigateur à partir de zéro et résoudre un problème mathématique de niveau recherche sur le benchmark First Proof.

Récemment, nous avons commencé à collaborer avec NVIDIA sur un nouveau défi : appliquer l’infrastructure multi-agent à l’optimisation de kernels CUDA. Ce sont des problèmes techniques difficiles, aux conséquences concrètes importantes : les kernels CUDA sont au cœur du logiciel qui prend en charge l’entraînement et l’inférence des modèles d’IA sur les GPU NVIDIA. Des kernels plus rapides permettent une meilleure utilisation des GPU, une consommation d’énergie réduite, une latence plus faible et un coût par token plus bas, ce qui permet aux fournisseurs de proposer à plus d’utilisateurs, simultanément, des modèles plus grands et plus performants.

Notre infrastructure multi-agent a fonctionné de manière autonome pendant trois semaines sur 235 problèmes. Le système a obtenu un gain de vitesse géométrique moyen de 38 % en créant et en optimisant des kernels pour GPU Blackwell à partir de zéro, jusqu’au niveau assembleur.

De tels gains de performance ne sont généralement obtenus qu’au prix de mois, voire d’années, de travail par des ingénieurs kernel très expérimentés. Le système multi-agent y est parvenu en quelques semaines, en s’attaquant à une longue traîne de problèmes de kernels qu’il était peu pratique de traiter avec les approches existantes.

#L’optimisation des kernels comme test des capacités des systèmes multi-agents

L’une des meilleures façons d’évaluer des systèmes multi-agents de longue durée consiste à leur confier des problèmes d’optimisation ouverts, dont même nous ne connaissons pas la bonne réponse. Les problèmes d’optimisation de kernels répondent à ce critère : ils offrent des objectifs mesurables que le système peut optimiser de manière itérative, plutôt que de viser un simple diff connu à l’avance.

Aujourd’hui, les ingénieurs optimisent les kernels en décomposant les modèles en opérations mathématiques individuelles, puis en ajustant chacune séparément. Cela rend le problème gérable, mais laisse des gains de performance inexploités, car une optimisation par morceaux passe à côté des bénéfices potentiels d’une optimisation menée simultanément à l’échelle de l’ensemble du système. À ce jour, les performances des GPU ont été limitées par notre incapacité à explorer l’ensemble de l’espace des solutions au-delà de ces simplifications manuelles.

Avec cette expérience, nous voulions voir si notre système multi-agents pouvait s’affranchir de ces contraintes et explorer un espace de solutions plus vaste afin de produire des kernels plus rapides.

#SOL-ExecBench pour la génération de problèmes et le benchmarking

NVIDIA a utilisé SOL-ExecBench pour générer 235 problèmes d’optimisation à partir de plus de 124 modèles open source utilisés en production, comme Deepseek, Qwen, Gemma, Kimi et Stable Diffusion. Contrairement aux données synthétiques ou aux kernels simplifiés, chaque problème représente une contrainte réelle sur des workloads d’entraînement ou d’inférence couvrant diverses architectures de modèles : LLM, diffusion, vision, audio, vidéo et hybrides multimodaux.

Nous avons également utilisé SOL-ExecBench pour évaluer des solutions de kernels multi-agents sur 27 GPU NVIDIA Blackwell 200. SOL-ExecBench est un outil d’évaluation efficace qui compare les performances des kernels à des références logicielles existantes ainsi qu’aux limites théoriques de performance du matériel. Si des agents utilisent des tactiques de triche comme la mise en cache et affichent des performances supérieures à ce qu’un B200 peut prendre en charge, le pipeline invalide le résultat.

#Comment nous avons mené l’expérience

Le système multi-agent a résolu les 235 problèmes d’optimisation de kernels GPU en une seule exécution en déployant un agent planificateur qui distribuait et rééquilibrait le travail entre des processus autonomes en fonction de métriques de performance.

L’ensemble du protocole de coordination tenait dans un seul fichier markdown qui spécifiait le format de sortie, les règles et les tests. Le système multi-agent a appris de manière autonome à appeler le pipeline de benchmarking pendant ses exécutions, créant une boucle dans laquelle il testait, déboguait et optimisait continuellement les kernels sans la moindre intervention d’un développeur.

Afin de mieux évaluer les capacités du système multi-agent, nous lui avons demandé d’écrire ses solutions dans deux langages au cours de deux exécutions distinctes, à deux extrémités opposées du spectre d’abstraction GPU :

• CUDA C with inline PTX, qui donne aux agents un accès direct aux registres et aux instructions au niveau de l’ISA, afin de tester si le système peut raisonner au niveau matériel le plus bas.
• CuTe DSL, qui fournit des abstractions composables de haut niveau tout en étant très peu présent dans les données d’entraînement publiques, afin de tester si le système peut apprendre de nouvelles API uniquement à partir de la documentation fournie.

#38 % de gain de vitesse, avec 19 % des optimisations offrant plus de 2× de gain

Nous évaluons les performances du système multi-agent de deux façons :

• Gain de vitesse géométrique moyen par rapport à du code PyTorch optimisé par un seul agent, utilisé comme référence.
• Scores Speed-of-Light (SOL), qui indiquent la qualité d’une solution par rapport aux limites théoriques du matériel sur une courbe logarithmique. Un score de 0,5 correspond à la référence PyTorch optimisée, et 1,0 à la limite de performance.

Notre système multi-agent a nettement surpassé les références sur 149 des 235 problèmes (63 %), avec un ratio de moyenne géométrique de 1,38x (soit un gain de vitesse géométrique moyen de 38 %).

Sur 45 des 235 problèmes (19 %), le système multi-agent a obtenu des optimisations supérieures à 2x par rapport aux références. Vous pouvez consulter les solutions finales développées par notre système dans ce dépôt public.

#Différentes stratégies d’optimisation selon les problèmes

Pour illustrer la capacité du système à s’adapter à différents types de problèmes, nous présentons trois cas où il a naturellement adopté des stratégies d’optimisation distinctes.

#Attention à requêtes groupées en BF16 avec prefill paginé

L’attention à requêtes groupées avec prefill paginé est une opération courante au stade du prompt dans les stacks d’inférence LLM modernes. Une implémentation bien optimisée peut prendre en charge des contextes plus longs, une concurrence plus élevée et un meilleur débit avec la même VRAM GPU.

L’agent a utilisé CUDA C++ pour optimiser ce problème d’attention tiré de SGLang pour l’inférence de Llama 3.1 8B. Au fil des itérations sur le kernel, l’agent a exploité avec succès des instructions matérielles spécifiques pour le chargement en mémoire et les calculs, a ajouté un ordonnancement amélioré via des kernels persistants, et a poussé l’optimisation à l’extrême en fonction de la taille d’entrée.

Nous avons comparé le kernel personnalisé du système multi-agent à une référence optimisée par un humain dans la bibliothèque FlashInfer. Nous avons constaté que le système produisait une solution s’approchant des limites matérielles, avec un score SOL de 0.9722, soit un gain de vitesse géométrique moyen de 84 % par rapport à la référence.

Nous avons également remplacé le kernel existant dans SGLang et observé un gain de vitesse de 3 % sur le temps jusqu’au premier token (TTFT) pour Llama 3.1 8B. Étant donné que ce problème d’attention représente 2 à 5 % du processus de prefill selon la configuration de serving, nous considérons qu’il s’agit d’un gain de vitesse de bout en bout non négligeable.

#Linéaire MoE NVFP4 avec gating

Ce problème illustre un pattern courant à deux kernels dans les modèles Mixture-of-Experts comme Qwen3, avec la particularité que le tenseur d’entrée et le résultat intermédiaire de la multiplication sont quantifiés en NVFP4 (virgule flottante sur 4 bits).

L’agent a correctement identifié l’étape de quantification comme principal goulot d’étranglement, puis a fusionné le calcul de l’échelle et l’arrondi. Au lieu d’effectuer une mise à l’échelle puis un arrondi lors de la quantification, il a utilisé des buckets de seuils précalculés pour mapper directement les valeurs FP32 vers des codes FP4, ce qui est possible puisqu’il n’existe que 16 valeurs NVFP4 possibles. Il a ensuite appliqué ces optimisations à des cas de test plus volumineux.

L’agent a finalement dépassé la référence PyTorch optimisée, avec un gain de vitesse géométrique moyen de 39 % et un score SOL de 0,58.

#Multiplication de matrices BF16

La multiplication de matrices est un problème notoirement difficile à optimiser, car elle exige une compréhension approfondie des différentes unités matérielles et de leur ordonnancement. Des kernels de multiplication de matrices (GEMM) réellement performants nécessitent du PTX inline (semblable au langage assembleur), du pipelining et de la mise en tampon au sein d’un kernel. Par conséquent, l’écriture de GEMM rapides a historiquement été l’apanage d’experts kernel très expérimentés.

Le système multi-agent de Cursor a généré de zéro un kernel GEMM CUDA C++ spécialisé, s’approchant de façon remarquable (86 %) d’une référence humaine minutieusement optimisée issue de la bibliothèque NVIDIA cuBLAS. Le système est parvenu à ce résultat en apprenant de manière autonome à utiliser des instructions spécifiques à Blackwell, en optimisant les lectures et écritures mémoire pour le matériel, puis en hyperoptimisant les dimensions exactes.

Et sur les cas de test small-M, particulièrement importants pour la phase de decode de l’inférence des LLM, le kernel du système multi-agent a surpassé la bibliothèque jusqu’à 9 %. Ce résultat laisse penser que les systèmes multi-agents pourraient bientôt dépasser les experts du domaine, même sur les problèmes de kernel les plus difficiles.

#Un système multi-agent pour créer des logiciels

Bien que l’infrastructure multi-agent ait apporté un gain de vitesse géométrique moyen de 38 % par rapport aux références, le score SOL médian n’était encore que de 0,56, ce qui laissait une marge importante pour des optimisations supplémentaires. Nous pensons que les solutions multi-agents peuvent être considérablement améliorées avec plus de puissance de calcul, car nous faisions tourner des centaines de problèmes et d’agents sur seulement 27 GPU. Cela limitait notre capacité à tirer pleinement parti du système multi-agent. Avec plus de GPU, le système pourrait explorer des solutions encore plus poussées et inédites.

Les tâches les plus ambitieuses en développement logiciel sont ouvertes, sans solution clairement définie. Les systèmes à agent unique ont du mal dans ce cas, car les modèles sont plus performants sur des tâches étroitement délimitées qu’ils ont déjà vues pendant l’entraînement. Nous considérons l’expérience d’optimisation du kernel comme une validation supplémentaire du fait que les architectures multi-agents deviendront rapidement l’approche par défaut pour créer des logiciels, car elles peuvent s’attaquer à des problèmes inédits, bien au-delà de la distribution des données d’entraînement.

Les techniques que nous étudions ici viendront bientôt enrichir le cœur du produit Cursor. Si travailler sur des problèmes complexes de coordination multi-agents vous intéresse, l’équipe Cursor serait ravie d’échanger avec vous à l’adresse hiring@cursor.com.