24 ore e 1.000 tool call: cosa dimostra davvero il case study sui kernel
I benchmark misurano lo scatto di un agente. Lo studio di Meta sull'ottimizzazione dei kernel ne misura la maratona — ed è il numero più interessante dei due.
Il setup
Meta ha messo alla prova la capacità di Muse Spark 1.2 di ottimizzare iterativamente kernel GPU lungo più di 1.000 tool call, in run durate fino a 24 ore. Dentro l’ambiente agentico di Muse Code, il modello scrive un kernel, lo compila, lo profila contro una baseline fornita e usa i dati di profiling per riprovare — un ciclo serrato scrivi-compila-profila-migliora, sostenuto per un giorno intero. I bersagli del benchmark erano i kernel di attention KDA e MLA su GPU NVIDIA Hopper.
Una regola ha reso il test onesto: ai modelli era vietato importare librerie di kernel di terze parti come FLA. Niente scorciatoie tipo incartare un’implementazione veloce già esistente e prendersene il merito — l’agente doveva applicare vera conoscenza di ottimizzazione dei kernel e implementare gli algoritmi in Triton da sé.
Cosa ha costruito davvero l’agente
Le soluzioni non erano generiche. Per KDA — misurato contro l’implementazione Triton di FLA — Muse Spark 1.2 ha accoppiato un kernel di preparazione chunk-parallel a uno scan sequenziale inter-chunk, combinando fusion e tiling standard con mosse specifiche per KDA, come ri-centrare il decadimento cumulativo con gating sul punto medio del chunk. Per MLA — contro un riferimento PyTorch con batch size 1, 64 head, sequence length 8192 e dimensione latente 512 — ha progettato una pipeline Triton a due kernel che riusa il latente KV condiviso sia come K sia come V.
Sono il tipo di ottimizzazioni che uno specialista scrive dopo aver capito la struttura dell’algoritmo, non ritocchi superficiali ai loop. E l’agente ha continuato a trovare miglioramenti sostanziali rispetto alla baseline man mano che la run proseguiva — un progresso accumulato lungo centinaia di iterazioni, invece di appiattirsi dopo il primo sprint.
Perché il vero titolo sono le 24 ore
Di modelli capaci di migliorare un kernel per venti minuti ce ne sono parecchi. Sostenere un progresso mirato per un giorno intero richiede un’infrastruttura che la maggior parte degli agenti non ha. Tre pezzi reggono il carico. Il goal conditioning tiene l’iterazione numero 700 puntata sullo stesso obiettivo della numero uno — il modello è stato addestrato esattamente per questo. La compattazione del contesto conserva la conoscenza che conta (quali strategie sono fallite, cosa ha detto il profiler) senza annegare in una giornata intera di cronologia. E l’event log rende il runtime a prova di riavvio — su 24 ore qualcosa andrà storto, e un crash che cancellasse l’ora 23 renderebbe l’intero esercizio inutile.
Cosa significa per il lavoro di tutti i giorni
Pochi team ottimizzano kernel per Hopper. Ma la forma del compito — iterare contro un obiettivo misurabile, imparare da ogni tentativo, non perdere il filo — coincide con un sacco di ingegneria poco glamour: inseguire una test suite flaky, limare un bundle size, migrare un’API cento call site alla volta. Il case study è la prova che Meta porta a sostegno di una tesi precisa: “lancialo e controlla domani” è ormai un workflow reale. La metodologia di valutazione è pubblicata sul sito di ricerca di Meta; il lato prodotto del lavoro long-horizon parte dalla documentazione.