- Los kernels CUDA-C generados por IA muestran un rendimiento similar o superior al de los kernels optimizados por expertos de PyTorch
- Un solo LLM (modelo de lenguaje grande) repite la generación de ideas de optimización en lenguaje natural y múltiples ramificaciones de código, logrando un mejor desempeño en diversidad de optimización y búsqueda en paralelo que los métodos existentes
- En benchmarks representativos, superó ampliamente a PyTorch en Matmul (101%), Conv2D (179.9%), Softmax (111.8%), LayerNorm (484.4%), Conv2D+ReLU+MaxPool (290.1%)
- Para superar los límites del tradicional “mejoramiento secuencial de kernels”, aplica una estructura de razonamiento en lenguaje natural + branching, generando kernels de alto rendimiento a gran velocidad
- También está avanzando en cargas de trabajo modernas de ML como FP16 y Flash Attention, y muestra que en el futuro podría volverse dominante un paradigma donde la IA busque y mejore por sí sola kernels más rápidos
TL;DR logros principales
- El equipo de investigación de Stanford CRFM encontró ejemplos donde kernels CUDA-C de alto rendimiento generados por IA alcanzan velocidades similares o mejores que los kernels diseñados por expertos en PyTorch
- El objetivo original era entrenar un modelo de autogeneración de kernels mejores mediante datos sintéticos, pero observaron que solo el proceso de generación de datos sintéticos ya producía automáticamente kernels sorprendentemente rápidos
- Por ello, publicaron anticipadamente el método, los benchmarks de rendimiento, las estrategias de optimización y la dirección futura
- Benchmark: basado en GPU Nvidia L40S. Rendimiento (%): tiempo de ejecución de PyTorch ÷ tiempo de ejecución del kernel generado
- Matmul (FP32): 101.3% frente a PyTorch (matriz 4096x4096)
- Conv2D: 179.9% (entrada: 100, 3, 224, 224; especificación AlexNet Conv1)
- Softmax: 111.8% (tensor 4096x65536)
- LayerNorm: 484.4% (tensor 16, 64, 256, 256)
- Conv2D + ReLU + MaxPool: 290.1% frente a la referencia de PyTorch, 189.0% frente a
torch.compile()
Motivación y método de la investigación
- El propósito inicial era generar datos sintéticos para entrenar un modelo de generación de kernels, pero durante los experimentos los kernels generados por el propio sistema lograron un rendimiento muy superior al esperado
- Se utilizó KernelBench (benchmark público de Stanford, publicado en diciembre de 2024)
- Dado un código
torch, el LLM reescribe un nuevo kernel con velocidad óptima
- La corrección se verifica comprobando la equivalencia numérica entre entradas y salidas
- Enfoque existente: un bucle de modificación secuencial que va ajustando poco a poco el kernel y mejorándolo por etapas
- Desventajas: poca diversidad de ideas, repetición de las mismas optimizaciones y convergencia a óptimos locales
- Idea de mejora
- Idear y registrar en lenguaje natural ideas de optimización, y luego generar simultáneamente varias ramas de implementación en código para esas ideas
- En cada ronda se ejecutan en paralelo varios intentos de optimización → el kernel con mejor rendimiento se usa como semilla de la siguiente ronda
- Esto permite explorar estrategias de optimización diversas y realizar búsqueda en paralelo dentro de un número limitado de iteraciones
Ejemplos de ideas de optimización
- Optimización de acceso a memoria: mejorar la eficiencia de la jerarquía de memoria global/shared/register
- Procesamiento asíncrono y ocultamiento de latencia: superponer cómputo y movimiento de datos
- Optimización de tipos de datos/precisión: uso de FP16/BF16 y operaciones especializadas por hardware
- Optimización de cómputo e instrucciones: reducir operaciones, número de instrucciones y aprovechar mejor instrucciones especiales del hardware
- Paralelismo y occupancy: maximizar el uso de los SM (Streaming Multiprocessors)
- Optimización de loops/branches/indexación: minimizar loops y eliminar operaciones de indexación innecesarias
Proceso real de optimización del kernel (ejemplo de Conv2D)
- Flujo de ideas de optimización y mejora de rendimiento por ronda
- Inicio (ronda 0): port simple a CUDA (20% de la velocidad de PyTorch)
- Rondas siguientes: → uso de caché de lectura → operaciones FP16 Tensor Core (conversión a GEMM) → doble buffering/pipeline → precálculo de índices/memoria compartida → vectorización → buffering simultáneo del loop K, etc., con uso avanzado de la arquitectura GPU
- Resultado final (ronda 13): 179.9% de rendimiento frente a PyTorch
- El código real hace un uso intensivo de técnicas avanzadas de programación CUDA
- En cada ronda, genera nuevas ideas en lenguaje natural, prueba varias implementaciones en paralelo y elige el mejor código
Takeaways e implicaciones
- La generación de kernels basada en IA puede superar el nivel de expertos humanos gracias a un potente bucle de búsqueda y a la combinación de diversas ideas de optimización en lenguaje natural
- Algunos operadores modernos (FP16 matmul, Flash Attention) todavía rinden menos que PyTorch por ahora
- En hardware reciente, el cómputo FP32 está relativamente menos optimizado que FP16/BF16 → eso puede abrir ventaja de rendimiento en esa área
- Incluso con un presupuesto limitado de búsqueda de tokens (7 millones de tokens entre entrada y salida), se confirmó una mejora continua del rendimiento
- Investigaciones recientes como AlphaEvolve y Gemini 2.5 Pro también sugieren que la búsqueda basada en branching masivo + validación puede lograr mejoras radicales de rendimiento sin reentrenamiento
- En adelante, este enfoque podría generar masivamente datos sintéticos y kernels de alto rendimiento, evolucionando hacia un bucle de IA auto-mejorable (IA con auto-mejora)
Conclusión
- La generación y optimización automática de kernels basada en IA ya llegó al nivel del hand-coding experto, y en un futuro cercano podría hacer posible sistemas de IA auto-mejorables mediante la combinación de modelo + búsqueda con branching + validación
- Surge la posibilidad de que la IA supere por sí misma los límites de rendimiento de frameworks como PyTorch y TensorFlow
Apéndice: código completo del kernel Conv2D
- Se incluye el código fuente completo de la función y del kernel (se omite aquí el detalle del código)
- Características principales dentro del código:
- vectorización de memoria compartida, double-buffering jerárquico en K-dim, CUDA WMMA, warp-level output buffer, etc.
- cálculo dinámico de índices en tiempo real, manejo de bias, carga simultánea de datos diferidos dentro del loop K, etc.
- El código de muestra completo y los kernels de ejemplo pueden consultarse en el repositorio de GitHub
2 comentarios
¿Podría decirse que es una especie de técnica de ensamble? Impresionante.
Comentarios en Hacker News
Me parece bastante interesante cómo los autores de este texto entienden a los "agentes de IA"
La mayoría de la gente tiende a pensar en los agentes como si fueran empleados humanos
Configuran unos pocos agentes en paralelo (muchas veces solo uno), y hacen que cada uno dé vueltas en un bucle procesando solo una tarea a la vez
Siguen atrapados en un mundo con una cantidad fija de personal, trabajadores que solo pueden hacer una cosa a la vez y con cambios de tarea lentos
Pero los LLM no funcionan así
Puedes crear, en la práctica, una cantidad infinita de agentes cuando quieras
No hay diferencia de costo entre procesar solicitudes al LLM en serie o en paralelo
Una vez que entiendes eso, surge de forma natural el patrón donde cada agente se ramifica en varios subagentes según sea necesario
Eso es justo lo que intentaron los autores
Siento que tiene más sentido ver a los agentes como si fueran "tasks" o "jobs", y aplicar lo aprendido de Celery o Sidekiq
"FP32 se usa bastante menos en cargas modernas de ML y, en hardware reciente, también está menos optimizado que FP16 o BF16. Así que esa puede ser una de las razones por las que fue más fácil mejorar el rendimiento de PyTorch en kernels FP32"
Los desarrolladores casi no han invertido tiempo en optimizar kernels de la variante fp32 durante años
Lo realmente interesante, creo, será cuando logren mejorar el rendimiento en kernels que sí se usan de verdad y que han recibido desarrollo intensivo
Creo que estos buenos resultados se explican en parte porque NVIDIA no ofrece documentación lo bastante detallada sobre sus GPU
En procesadores cuya microarquitectura está bien documentada, los programadores o compiladores pueden escribir de manera determinista programas óptimos, así que no es tan fácil lograr mejoras impresionantes aplicando ML/IA más allá de encontrar soluciones ya conocidas
En cambio, en casos menos documentados, como las GPU de NVIDIA, para encontrar el programa óptimo muchas veces hace falta hacer búsqueda aleatoria tomando como referencia ejemplos de programas previamente optimizados, o recurrir a análisis de ingeniería inversa sobre cómo se comporta realmente el hardware en ciertas situaciones
En contextos así, ML/IA sí puede mostrar potencial y, al aprender a partir de buenos programas ya hechos, podría captar comportamientos undocumented que incluso a programadores humanos les costaría descubrir
Me pregunto si las mejoras ya conocidas en kernels fp16/bf16 quizá simplemente se trasladaron a fp32
"¿Están diciendo que la gente no había tocado en absoluto los kernels fp32 durante años?"
Vaya, si de verdad es así, entonces me parece increíble que la IA haya producido un algoritmo nuevo en un área donde no había soluciones previas
Mi conclusión, viendo este artículo, AlphaEvolve de Google (aquí) y la noticia reciente de que o3 encontró un zero day en el kernel de Linux (aquí), es que
especialmente Gemini Pro 2.5 y o3 han llegado a un nuevo nivel de capacidad, donde de repente logran ideas que los modelos anteriores no podían
Yo no lo veo como que de pronto ahora hagan algo que antes no podían
Más bien, ahora pueden iterar y probar a una velocidad muchísimo mayor que la humana
y usar de inmediato enormes cantidades de información
Es decir, hemos llegado a un punto donde la combinación de mucha información, avances y fuerza bruta aplicada con inteligencia está dando resultados en algunas áreas
Creo que sí hay muchas similitudes reales entre los casos que mencionaste y este resultado
En el texto también dicen que "el bucle de iteración en tiempo de prueba se parece menos a un chatbot interactivo que verifica secuencialmente los resultados de modificar código, y más a una búsqueda estructurada que evalúa agresivamente en paralelo según hipótesis de optimización claras"
Mi conclusión es que ahora, basándose en las capacidades de los LLM,
hemos aprendido a reducir de forma drástica el espacio de soluciones cuando existe una función de evaluación clara o patrones similares
Que un modelo supere a otro, o que solo cierto modelo pueda resolver algo... esa comparación entre modelos no me parece el punto principal
Me parece más importante la realidad de que este tipo de aplicación ya se está mostrando con claridad
Gemini Pro 2.5 me dio la impresión de ser la primera IA que una persona realmente puede usar, pero, siendo estrictos, apenas acaba de pasar ese umbral
Todavía hay bastantes casos donde la tasa de éxito cae por debajo de 20%
Cuando salga la 3.0... siento que ya podría empezar a dar un poco de miedo
Espera, ¿qué quieres decir? Esto no tiene nada que ver con el kernel de Linux; aquí "kernel" se refiere a programación de GPU
¿No habrás entendido mal todo el texto?
Suena interesante, pero ¿hay evidencia más sólida? Un solo resultado no basta para convencer
"El código base usa FP32 por defecto, y la tolerancia permitida es 1e-02"
Con un margen de error así, se puede reemplazar fácilmente un kernel "fp32" con operaciones fp16
Pensándolo un paso más, me pregunto si en realidad la esencia de este trabajo no habrá sido cambiar a fp16 tantas operaciones fp32 como fuera posible dentro de ese kernel
Habría que comprobar qué tan difícil es realmente hacer esa migración
pero intuitivamente no me parece tan impresionante
Si estoy equivocado, me gustaría que los autores aclararan bien este punto
Si es así, entonces el resultado pierde sentido
No sé si habrán verificado el error relativo
Sustituir float32 por float16 no significa nada
La precisión es prácticamente la única razón para elegir float32
si pierdes esa característica, ya no hay una diferencia real entre versiones
¿Soy el único que leyó el título y pensó por error que la IA había creado un kernel de sistema operativo?
Una mejora de velocidad del 400% ya es impresionante,
pero lo más interesante es la metodología: en vez de limitarse a optimizar operaciones simples en cada iteración, forzaron una etapa de razonamiento en lenguaje para generar diversidad en la búsqueda
Es muy interesante porque ese enfoque realmente funcionó bien
Me da la impresión de que es solo evolución memética bastante normal
Es un resultado realmente interesante
Parece que esta gente se emocionó tanto que lo publicó en el blog
De hecho, quizá querían recibir retroalimentación antes de publicarlo formalmente
No sé si este será el camino legendario hacia la "self improvement"
pero sí siento que es el tipo de resultado que uno esperaría ver en ese camino
Estos métodos solo funcionan cuando existe una función de evaluación extremadamente clara
Comparto mi experiencia: en intentos de replicación, el kernel de LayerNorm no era numéricamente estable y por eso lo considero no verificable
Solo lo probaron con media 0 y desviación estándar 1, así que el fenómeno de numerical cancellation no se hizo evidente de inmediato
Además, después confirmé que luego hicieron una nueva versión numéricamente estable
Eso me parece excelente
Es un resultado muy bueno
Usaron o3 y Gemini 2.5 Pro,
pero lamentablemente no dicen cuál de los dos produjo mejores kernels
Un punto interesante será observar cómo el código generado por IA maneja áreas más amplias, como un fused kernel
Por ejemplo, cosas como gemm + relu + gemm + normalization
Recorrer todo eso con un tuner o escribirlo a mano sería un trabajo bastante pesado
Lo único seguro es que no se refiere al kernel del sistema operativo