24 heures, 1 000 tool calls : ce que prouve vraiment l'étude de cas sur les kernels
Les benchmarks mesurent le sprint d'un agent. L'étude d'optimisation de kernels de Meta mesure son marathon — et c'est le chiffre le plus intéressant des deux.
Le dispositif
Meta a testé la capacité de Muse Spark 1.2 à optimiser itérativement des kernels GPU sur plus de 1 000 tool calls, dans des runs allant jusqu’à 24 heures. Dans l’environnement agentique de Muse Code, le modèle écrit un kernel, le compile, le profile contre une baseline fournie, puis exploite les données de profiling pour retenter — une boucle serrée écrire-compiler-profiler-améliorer, soutenue pendant une journée entière. Les cibles du benchmark : des kernels d’attention KDA et MLA sur GPU NVIDIA Hopper.
Une règle rendait le test honnête : interdiction d’importer des bibliothèques de kernels tierces comme FLA. Pas question d’emballer une implémentation rapide existante et de s’en attribuer le mérite — l’agent devait mobiliser de vraies connaissances en optimisation de kernels et implémenter lui-même les algorithmes en Triton.
Ce que l’agent a réellement construit
Les solutions n’avaient rien de générique. Pour KDA — benchmarké contre l’implémentation Triton de FLA — Muse Spark 1.2 a couplé un kernel de préparation chunk-parallèle avec un scan séquentiel inter-chunks, en combinant fusion et tiling classiques avec des astuces spécifiques à KDA, comme le recentrage de la décroissance cumulative gated au milieu du chunk. Pour MLA — face à une référence PyTorch en batch size 1, 64 têtes, séquence de 8192, dimension latente 512 — il a conçu un pipeline Triton à deux kernels qui réutilise le latent KV partagé à la fois comme K et comme V.
Ce sont les optimisations qu’un spécialiste écrit après avoir compris la structure de l’algorithme, pas des retouches superficielles de boucles. Et l’agent a continué à trouver des améliorations substantielles par rapport à la baseline tout au long du run — un progrès qui s’est accumulé sur des centaines d’itérations au lieu de plafonner après le premier élan.
Pourquoi les 24 heures sont le vrai titre
Beaucoup de modèles savent améliorer un kernel pendant vingt minutes. Soutenir une progression dirigée pendant une journée exige une infrastructure que la plupart des agents n’ont pas. Trois pièces portent la charge. Le conditionnement sur l’objectif garde l’itération numéro 700 pointée sur le même but que l’itération une — le modèle a été entraîné exactement pour ça. La compaction de contexte retient ce qui compte (quelles stratégies ont échoué, ce que disait le profiler) sans se noyer dans une journée d’historique. Et l’event log rend le runtime résistant aux redémarrages — sur 24 heures, quelque chose va forcément tousser, et un crash qui effacerait la 23e heure rendrait tout l’exercice inutile.
Ce que ça annonce pour le travail ordinaire
Peu d’équipes optimisent des kernels Hopper. Mais la forme de la tâche — itérer contre une cible mesurable, apprendre de chaque tentative, ne pas perdre le fil — colle à beaucoup d’ingénierie sans gloire : traquer une suite de tests flaky, grignoter une taille de bundle, migrer une API sur une centaine de call sites. Cette étude de cas, c’est la preuve avancée par Meta que « lance-le et reviens voir demain » est désormais un vrai workflow. La méthodologie d’évaluation est publiée sur le site de recherche de Meta ; côté produit, le travail long horizon commence dans la doc.