TL;DR. AutoEng est un agent autonome qui optimise du code et ne conserve que les accélérations qu’il peut prouver. Nous l’avons appliqué à Pico, notre zkVM, sur l’ensemble de son code GPU et CPU. Sans intervention humaine, il a trouvé un gain de performance d’environ 11% de bout en bout lors du calcul réel de blocs Ethereum, sur un système déjà à l’état de l’art, en moins de trois jours d’exécution autonome. Son fonctionnement : AutoEng profile le prouveur en direct pour identifier où le temps est réellement consommé, vise le goulot d’étranglement à plus forte valeur, et génère une optimisation candidate qu’il ne conserve que si le changement est correctement prouvable et provablement plus rapide. 

Le point de référence était déjà de niveau mondial

Pico est notre zkVM, une machine qui produit des preuves cryptographiques attestant que le calcul s’est déroulé correctement. Aujourd’hui, elle peut prouver des blocs complets du mainnet Ethereum en temps réel, en direct sur ethproofs. Prouver un bloc entier dans le temps d’une “slot” Ethereum, sur du matériel grand public, est l’une des cibles de performance les plus difficiles de l’industrie, et Pico se situe exactement à cette frontière.

Nous y sommes arrivés en public, étape par étape :

• CPU → un seul GPU. Nous avons commencé avec Pico, une zkVM modulaire et performante sur CPU, puis nous avons ajouté l’accélération GPU pour un gain de 10–20× et nous sommes passés en production pour prouver des blocs Ethereum réels sur ethproofs.

• Un seul GPU → cluster. Pico Prism a atteint la preuve en temps réel sur du matériel grand public, puis a réduit le cluster de 64 GPU à 16 RTX 5090 sur deux machines pour un total d’environ 100K$ et un temps de preuve médian inférieur à 7 secondes.

• Pico Prism 2.0 a livré un bond d’efficacité de 5,3×, en prouvant des blocs de 60M-gas avec 99,9% d’entre eux qui finissent à l’intérieur de la slot de 12 secondes d’Ethereum.

En chemin, la Fondation Ethereum, Vitalik Buterin et Justin Drake ont tous mis en avant ce travail. Le système AutoEng sur lequel il s’est mis au travail était donc déjà fortement réglé et déjà à la frontière : tous les gains faciles étaient depuis longtemps passés.

L’optimisation ne s’échelle pas en embauchant

Quand votre produit dépend de la latence, chaque pourcent compte. Et Pico est gigantesque : plus de 200 000 lignes de code, des kernels CUDA bas niveau sur le GPU au code Rust qui orchestre tout côté CPU — le tout évoluant rapidement. Quelque part, le temps se cache toujours.

Le fait de le trouver fait partie des métiers les plus rares et les plus lents de tout l’ingénierie. La boucle a l’air identique à chaque fois : profiler le système pour voir où le temps part réellement, formuler une hypothèse sur la raison pour laquelle une portion est lente, la réécrire, la compiler, confirmer que le résultat produit exactement la bonne réponse, la benchmarker, et le plus souvent constater que rien ne change. Puis recommencer. Le travail exige une expertise profonde et spécialisée, reste lent même pour les meilleurs ingénieurs, et s’étend sur le GPU comme sur le CPU. Vous ne pouvez pas simplement résoudre le problème en embauchant davantage de gens pour en faire plus.

Donc nous avons posé une question différente.

Nous avons parié sur un Ingénieur d’Optimisation Autonome

Un agent IA pourrait-il exécuter toute cette boucle tout seul ?

Pas juste “compléter automatiquement un peu de CUDA”, mais exécuter une vraie boucle d’ingénieur : trouver ce qui vaut la peine d’être optimisé, proposer un changement, prouver qu’il est correct, mesurer s’il est réellement plus rapide, et ne le conserver que lorsqu’il gagne. La partie difficile de l’ingénierie de performance a toujours été de savoir quoi essayer et de le prouver. Saisir le code n’a jamais été le goulot d’étranglement. C’est cette partie que nous avons cherché à automatiser.

Le résultat est AutoEng. Nous l’avons conçu pour être général, puis nous l’avons orienté vers le système le plus difficile que nous avions : Pico.

Ce que fait AutoEng

AutoEng est une boucle fermée qui tourne en continu, en faisant atterrir une amélioration vérifiée à la fois :

1. Profil : construire un graphe d’appels du prouveur en cours d’exécution et identifier les “hotspots” qui dominent vraiment le temps wall-clock.

2. Plan : choisir la chose la plus précieuse à optimiser ensuite, compte tenu de ce qui a déjà été essayé.

3. Refine : générer des optimisations candidates et les tester.

4. Validate : re-mesurer sur la charge de travail réelle et décider : conserver ou annuler.

Puis la boucle revient à l’étape 1, avec le nouveau système, légèrement plus rapide, comme référence. Aucun humain n’approuve chaque étape.

(Les quatre étapes forment une boucle continue. La phase Refine s’exécute en deux voies, GPU et CPU, et chaque candidat doit franchir le verrou Validate avant d’être conservé.)

Le principe central : le modèle propose, la mesure décide

C’est ce qui rend AutoEng digne de confiance, et c’est l’inverse de ce que les gens imaginent habituellement quand ils disent “une IA écrit du code”.

Le modèle de langage ne peut jamais décider si un changement est bon. Il peut proposer, mais il ne juge jamais. Deux verrous stricts séparent une proposition du fait qu’elle soit conservée :

• La correction est vérifiée octet par octet. Chaque kernel candidat s’exécute avec les mêmes entrées que l’original, et sa sortie doit correspondre exactement, bit pour bit. Pas de “c’est presque ça”. Une mauvaise réponse est rejetée, quel que soit le niveau de rapidité.

• La vitesse est décidée par des benchmarks déterministes. Chaque candidat est chronométré de nombreuses fois, face à un niveau de bruit mesuré, de sorte que les variations aléatoires ne peuvent pas passer pour un gain. Un changement ne compte que s’il bat la référence avec une marge statistiquement réelle.

Un changement n’est conservé que s’il est prouvablement correct ET prouvablement plus rapide. Tout le reste est annulé automatiquement. Le système rapporte aussi honnêtement : lorsqu’un tour ne produit aucune amélioration réelle, il le dit et n’invente jamais un gain de vitesse. C’est ce qui lui permet de tourner sans surveillance. Il ne peut pas tromper sa propre perception.

Deux moteurs : GPU et CPU

La version actuelle de Pico contient à la fois du code CPU et du code GPU, et AutoEng optimise sur les deux, donc elle exécute deux moteurs complémentaires.

Optimisation des kernels GPU — largeur. Cela vise des kernels CUDA individuels. Le même résultat mathématique peut être calculé par de nombreux algorithmes différents, donc la recherche est large. AutoEng s’appuie sur une base de connaissances de motifs d’optimisation GPU distillés, accumulant l’expertise CUDA transformée en quelque chose de “recherchable”. Pour un kernel donné, il récupère les motifs pertinents, génère quelques idées candidates classées, puis benchmarke chacune indépendamment pour apprendre exactement quelle idée a produit quel gain de vitesse. Les motifs qui marchent reviennent alimenter la bibliothèque ; le système s’affine au fil du temps.

Optimisation de l’hôte CPU — profondeur. Les kernels GPU ne racontent que la moitié de l’histoire. Une grande partie du temps réside dans le code côté CPU qui pilote l’ensemble du prouveur : synchronisation, batchings, allocation mémoire, ordonnancement. Il n’existe pas de catalogue bien rangé de motifs ici, et la recherche reste ouverte. Ce moteur exécute une boucle plus exploratoire : il propose un changement ciblé à la fois, tout en conservant une mémoire continue de ce qui a fonctionné et de ce qui n’a pas fonctionné, ce qui l’empêche de répéter des impasses.

Pourquoi les deux ? Le moteur GPU change l’algorithme qui calcule un résultat, tandis que le moteur CPU change la manière dont le travail est orchestré autour de lui. Les deux conservent une sortie identique. Et, tout aussi important : le goulot bouge. Accélérer les kernels GPU rend soudainement les surcharges côté CPU dominantes. Corriger le côté CPU, et le prochain kernel devient le mur. Il faut le poursuivre partout où il va.

Résultats

Nous avons mesuré le temps de preuve de bout en bout sur de vrais blocs Ethereum de tailles variées (un seul GPU, cinq exécutions moyennées, entièrement autonome) :

Un gain de vitesse end-to-end constant d’environ 11% sur le prouveur complet, de bout en bout, sur des blocs allant de 11M à 60M de gas (la limite actuelle du mainnet Ethereum), sur un système qui faisait déjà de la preuve en temps réel. Tous ces gains ont été découverts, vérifiés et intégrés par AutoEng sans qu’un humain ne décide qu’ils étaient corrects ou rapides.

Et il a fait tout cela en moins de trois jours de temps d’exécution autonome.

Le mur des rendements décroissants

Le travail de performance a une propriété brutale : les gains deviennent exponentiellement plus difficiles à mesure qu’on s’approche de la frontière. Au début, un système neuf peut vous donner un multiple. Bien loin dans un système mature et fortement réglé comme Pico, déjà passé par des années d’optimisations d’experts, un spécialiste peut passer deux à trois semaines et gagner peut-être une demi-portion de pourcent. La courbe s’aplatit contre un mur.

AutoEng a franchi ~11% par rapport à ce plateau, en moins de trois jours, sans que personne ne le pilote. Sur le même système, à la même frontière, ce rythme représente un ordre de grandeur différent.

La même approche, au-delà de Pico

AutoEng a été conçu pour être général, et Pico n’a été que le premier endroit où nous l’avons pointé. Le même agent guidé par la mesure a concouru sur des benchmarks externes dans des domaines complètement différents :

• ecdsa.fail — un défi public visant à minimiser le coût d’un circuit quantique réversible (la primitive interne d’une attaque de type Shor sur ECDSA, le schéma de signature derrière les comptes Ethereum). Notre agent autonome a brièvement atteint la #1 du classement, avec 44,2% d’avance sur le circuit de Google (selon le site), grâce entièrement à des candidats générés par l’agent et une recherche accélérée par GPU, sans réglage manuel.

• GPU MODE — une tâche kernel CUDA de QR groupé sur NVIDIA B200. Le kernel spécialisé de l’agent s’est classé dans le top 20, tournant ~2,4× plus vite que MAGMA, la bibliothèque GPU la plus solide pour l’algèbre linéaire dense groupée.

Du matériel différent, des maths différentes, la même recette : proposer, mesurer, et ne conserver que ce qui gagne de façon vérifiable.

Pourquoi c’est important

La plupart des histoires “une IA écrit du code” s’arrêtent à la génération : le modèle produit quelque chose de plausible et un humain vérifie. AutoEng va plus loin et automatise lui-même le jugement. La correction et la mesure sont le juge, et on ne peut pas les convaincre d’un mauvais résultat.

C’est un petit aperçu, mais réel, de l’ingénierie de performance autonome : des agents qui exécutent la boucle complète d’ingénierie guidée par la mesure sur un système de production réel, et récoltent chaque gain de vitesse qu’ils revendiquent.

Nous faisons maintenant pointer la même boucle vers des systèmes plus difficiles, et nous lui permettons de continuer à s’affiner au fur et à mesure.

À propos de Brevis ($BREV )

Brevis est une plateforme de calcul vérifiable alimentée par des preuves à connaissance nulle, agissant comme la couche de calcul infinie pour Web3. Les applications peuvent déléguer des calculs coûteux hors chaîne tout en prouvant chaque résultat en chaîne. La pile Brevis inclut Pico zkVM pour le calcul général, le ZK Data Coprocessor pour un accès sans confiance aux données historiques de la blockchain, Pico Prism pour la preuve en temps réel de blocs Ethereum (99,8% de couverture sur 16 GPU, atteignant l’objectif matériel de 100K$ de la Fondation Ethereum), Vera pour l’authenticité des médias prouvée en ZK, et ProverNet, le marché décentralisé de génération de preuves ZK qui tourne désormais sur le mainnet. À ce jour, Brevis a généré 340M+ de preuves sur 50+ protocoles répartis sur 8+ blockchains.