Un agente que escribe kernels CUDA y se queda con el más rápido
El repositorio monta un bucle de agente sobre LangGraph que genera kernels CUDA, valida su salida, los mide y conserva el candidato más rápido. No hay comparación con cuBLAS.
Hay un proyecto nuevo en GitHub que convierte la descripción de un workload en un kernel CUDA. Monta un bucle de agente sobre LangGraph: propone una implementación, la compila, compara su salida con NumPy, mide latencia y vuelve a intentarlo con lo aprendido. De cada sesión guarda el candidato más rápido que haya pasado todas las validaciones.
El modelo puede tocar dos cosas a la vez: el código del kernel y la configuración de lanzamiento de cada caso. La pieza en C++ compila con NVRTC y lanza el kernel a través de la CUDA Driver API; Python se encarga de comparar resultados y elegir candidato.
El ciclo y cómo puntúa
Cada caso tiene que pasar validación. Si un candidato no cuadra con la referencia, el agente lo repara mientras le quede presupuesto de iteraciones. El ranking usa la media geométrica de la latencia sobre los casos de rendimiento, y los casos pequeños de correctitud no entran en la nota. Por defecto son 10 lanzamientos de calentamiento y 100 medidos con CUDA events. El tiempo de compilación y el replay del profiler quedan fuera de la comparación.
El agente puede consultar las propiedades de la GPU, buscar documentación de NVIDIA antes de generar (--nvidia-research) e inspeccionar contadores de Nsight Compute (--use-nsight), algo que exige tener el profiler instalado y permiso para leer los contadores de rendimiento del dispositivo.
Para ejecutarlo hace falta Python 3.12 o superior, una GPU NVIDIA con su toolkit y driver, CMake 3.24, un compilador de C++17 y una clave de OpenAI: el modelo por defecto es gpt-5-mini con esfuerzo de razonamiento medio, y el consumo de la API se factura a la cuenta de quien lo use. El desarrollo se hizo en Windows con una RTX 3060 de portátil, y el ejemplo que acompaña al repositorio es un GEMM en float32 sobre esa misma GPU.
Los límites, contados por el propio proyecto
Es un optimizador experimental para kernels sueltos, no una herramienta de producción. Pasar los casos que le das no demuestra corrección general, y la referencia que genera el propio modelo no vale como oráculo independiente de correctitud. La mejora depende del workload, y no hay ninguna comparación contra cuBLAS ni contra otras librerías de fabricante. Al medir tiempos conviene tener la GPU ociosa. Dos avisos de seguridad: los scripts de entrada que genera se ejecutan como subprocesos de Python en local sin sandbox, y los kernels que produce corren en la GPU de la máquina.
Lo interesante del repositorio es dónde pone el listón. La optimización de kernels es justo el tipo de tarea donde un bucle de agente con acceso al profiler y a la documentación del fabricante puede aportar algo, pero el proyecto no presenta ni un solo número frente a cuBLAS, que es la referencia obvia. La documentación lo admite en lugar de maquillarlo, y ahí sigue la pregunta: cuánto de ese mejor candidato es mérito del agente y cuánto es lo que ya hacía el compilador.
