24 horas e 1.000 tool calls: o que o estudo de caso dos kernels realmente prova
Benchmarks medem o sprint de um agente. O estudo de otimização de kernels da Meta mede a maratona — e esse é o número mais interessante.
O experimento
A Meta testou a capacidade do Muse Spark 1.2 de otimizar kernels de GPU iterativamente ao longo de mais de 1.000 tool calls, em execuções de até 24 horas. Dentro do ambiente agêntico do Muse Code, o modelo escreve um kernel, compila, faz o profiling contra uma baseline fornecida e usa os dados do profiler para tentar de novo — um ciclo apertado de escrever-compilar-medir-melhorar sustentado por um dia inteiro. Os alvos do benchmark eram kernels de atenção KDA e MLA em GPUs NVIDIA Hopper.
Uma regra deixou o teste honesto: os modelos foram proibidos de importar bibliotecas de kernel de terceiros, como a FLA. Nada de embrulhar uma implementação rápida já existente e levar o crédito — o agente tinha que aplicar conhecimento genuíno de otimização de kernel e implementar os algoritmos em Triton por conta própria.
O que o agente construiu de fato
As soluções não foram genéricas. Para o KDA — comparado com a implementação Triton da FLA — o Muse Spark 1.2 combinou um kernel de preparação paralelo por chunk com uma varredura sequencial entre chunks, misturando fusão e tiling padrão com jogadas específicas de KDA, como recentrar o decaimento cumulativo com gate no ponto médio do chunk. Para o MLA — contra uma referência em PyTorch com batch size 1, 64 heads, sequência de 8192 e dimensão latente 512 — ele projetou um pipeline Triton de dois kernels que reutiliza o latente KV compartilhado como K e como V ao mesmo tempo.
São otimizações do tipo que um especialista escreve depois de entender a estrutura do algoritmo, não ajustes superficiais de loop. E o agente continuou encontrando melhorias substanciais sobre a baseline conforme a execução avançava — um progresso que se acumulou ao longo de centenas de iterações, em vez de estagnar depois do primeiro arranque.
Por que as 24 horas são a verdadeira manchete
Muito modelo por aí consegue melhorar um kernel por vinte minutos. Sustentar progresso direcionado por um dia inteiro exige uma infraestrutura que a maioria dos agentes não tem. Três peças carregam esse peso. O condicionamento de objetivo mantém a iteração de número 700 mirando o mesmo alvo da iteração um — o modelo foi treinado exatamente para isso. A compactação de contexto retém o conhecimento que importa (quais estratégias falharam, o que o profiler disse) sem afogar o modelo em um dia inteiro de histórico. E o event log torna o runtime seguro contra reinícios — em 24 horas, alguma coisa vai engasgar, e um crash que apagasse a hora 23 tornaria o exercício inteiro inútil.
O que isso sinaliza para o trabalho do dia a dia
Pouca gente otimiza kernels para Hopper. Mas o formato da tarefa — iterar contra um alvo mensurável, aprender com cada tentativa, não perder o fio — bate com muita engenharia sem glamour: caçar uma suíte de testes instável, espremer o tamanho de um bundle, migrar uma API cem call sites por vez. O estudo de caso é a evidência da Meta de que “dispara e confere amanhã” agora é um fluxo de trabalho real. A metodologia de avaliação está publicada no site de pesquisa da Meta; o lado de produto do trabalho de longo horizonte começa na documentação.