24 horas y 1.000 llamadas a herramientas: lo que demuestra el caso de los kernels
Los benchmarks miden el sprint de un agente. El estudio de optimización de kernels de Meta mide su maratón — y ese es el número más interesante.
El experimento
Meta puso a prueba la capacidad de Muse Spark 1.2 para optimizar kernels de GPU de forma iterativa a lo largo de más de 1.000 llamadas a herramientas, en ejecuciones de hasta 24 horas. Dentro del entorno agéntico de Muse Code, el modelo escribe un kernel, lo compila, lo perfila contra una línea base dada y usa los datos del profiler para intentarlo de nuevo — un ciclo cerrado de escribir-compilar-perfilar-mejorar sostenido durante un día entero. Los objetivos del benchmark eran kernels de atención KDA y MLA sobre GPUs NVIDIA Hopper.
Una regla hizo honesta la prueba: los modelos tenían prohibido importar librerías de kernels de terceros como FLA. Nada de envolver una implementación rápida ya existente y apuntarse el mérito — el agente tenía que aplicar conocimiento real de optimización de kernels e implementar los algoritmos en Triton por su cuenta.
Lo que el agente construyó de verdad
Las soluciones no fueron genéricas. Para KDA — comparado contra la implementación de FLA en Triton — Muse Spark 1.2 combinó un kernel de preparación paralelo por chunks con un scan secuencial entre chunks, mezclando técnicas estándar de fusión y tiling con jugadas específicas de KDA, como recentrar el decaimiento acumulado con gating en el punto medio de cada chunk. Para MLA — contra una referencia en PyTorch con batch size 1, 64 cabezas, longitud de secuencia 8192 y dimensión latente 512 — diseñó un pipeline de dos kernels en Triton que reutiliza el latente KV compartido como K y como V a la vez.
Ese es el tipo de optimización que escribe un especialista después de entender la estructura del algoritmo, no un retoque superficial de bucles. Y el agente siguió encontrando mejoras sustanciales sobre la línea base a medida que avanzaba la ejecución — un progreso que se acumuló a lo largo de cientos de iteraciones en vez de estancarse tras el primer arranque.
Por qué el titular real son las 24 horas
Hay muchos modelos capaces de mejorar un kernel durante veinte minutos. Sostener un progreso con rumbo durante un día entero exige una infraestructura que la mayoría de agentes no tiene. Tres piezas cargan con el peso. El condicionamiento por objetivo mantiene la iteración número 700 apuntando a la misma meta que la iteración uno — el modelo fue entrenado exactamente para esto. La compactación de contexto conserva el conocimiento que importa (qué estrategias fallaron, qué dijo el profiler) sin ahogarse en el historial de un día completo. Y el event log hace que el runtime sobreviva a reinicios — en 24 horas algo va a fallar, y un crash que borrase la hora 23 dejaría todo el ejercicio sin sentido.
Qué significa para el trabajo de cada día
Pocos equipos optimizan kernels para Hopper. Pero la forma de la tarea — iterar contra un objetivo medible, aprender de cada intento, no perder el hilo — encaja con mucha ingeniería poco glamurosa: perseguir una suite de tests inestable, rebajar el tamaño de un bundle a base de insistir, migrar una API con cien puntos de llamada de cada vez. El caso de estudio es la evidencia de Meta de que “lánzalo y revísalo mañana” ya es un flujo de trabajo real. La metodología de evaluación está publicada en el sitio de investigación de Meta; el lado de producto del trabajo de horizonte largo empieza en la documentación.