La inteligencia artificial ya participa en la generación de kernels de GPU, pero todavía dentro de un circuito controlado: DeepSeek-R1 propone código, un verificador comprueba el resultado y el sistema refina el prompt cuando no cumple los criterios. En un experimento de NVIDIA, ese proceso alcanzó una corrección numérica del 100 % en KernelBench Level 1 y del 96 % en Level 2. Shengyu Liu, ingeniero de sistemas y kernels de DeepSeek, cree que los kernels escritos por IA podrían igualar o superar su propio trabajo en un plazo de seis meses a un año.
La predicción de Shengyu Liu
Liu describe una evolución rápida en el trabajo con GPU. Según su experiencia, la IA pasó en aproximadamente un año de ayudar con documentación, lectura de código y depuración a analizar CUDA, PTX y SASS, además de estudiar atascos de instrucciones y optimizar operadores.
Ese cambio afecta a una pieza muy especializada del desarrollo de modelos. Liu no plantea una medición general del mercado: formula una previsión personal sobre el nivel que podrían alcanzar los kernels generados por IA frente a su propio trabajo. También contempla un desplazamiento de su función hacia la dirección de agentes, la elección de objetivos y la validación de resultados, en lugar de escribir cada kernel directamente.
Por qué un kernel puede cambiar la velocidad de una IA
Un kernel de GPU es una operación concreta que el modelo ejecuta una y otra vez. Puede encargarse de la atención, una multiplicación de matrices —GEMM—, la cuantización o el enrutamiento de expertos en una arquitectura MoE, siglas de Mixture of Experts.
Su trabajo no consiste solo en calcular el resultado correcto. También debe mover los datos de forma eficiente, repartir el trabajo entre hilos, escoger una estrategia de teselado, gestionar la precisión numérica y coordinar la sincronización. Un cambio en cualquiera de esos puntos puede modificar la latencia y el rendimiento total del entrenamiento o de la inferencia.
La optimización de DeepSeek se mueve precisamente en ese nivel. El trabajo asociado a sus sistemas incluye kernels especializados, planificación de comunicaciones entre GPU y estrategias adaptadas a arquitecturas MoE. La elección del kernel y la forma de organizar los datos importan tanto como la operación matemática que aparece en el código.
El flujo automático que ya está demostrado
El experimento de NVIDIA convierte la generación de kernels en un ciclo de propuesta, comprobación y corrección. DeepSeek-R1 recibe un prompt inicial y genera código CUDA C++; después, un verificador comprueba si el kernel cumple los criterios numéricos y de ejecución. Cuando no los satisface, el sistema modifica el prompt y vuelve a intentarlo.
| Etapa del flujo | Qué ocurre | Resultado o condición documentada |
| Prompt inicial | DeepSeek-R1 recibe la descripción de la operación que debe implementar. | Genera una primera propuesta de kernel en CUDA C++. |
| Verificación | Un comprobador evalúa la salida generada. | El kernel debe superar los criterios numéricos y de ejecución. |
| Refinamiento | El sistema ajusta el prompt cuando la propuesta no cumple los criterios. | El ciclo puede repetir la generación y la evaluación. |
| Optimización | Se conserva una propuesta que supera las comprobaciones. | El flujo produce kernels orientados a GPU Hopper. |
| Prueba de corrección | El proceso se evalúa con KernelBench. | 100 % de corrección numérica en Level 1 y 96 % en Level 2. |
NVIDIA dejó funcionar el bucle durante 15 minutos en el flujo descrito y obtuvo un kernel de atención mejorado. Es un resultado concreto para ese banco de pruebas, ese hardware y ese procedimiento; no equivale a que un sistema autónomo pueda resolver cualquier trabajo de ingeniería de kernels.
La diferencia es importante. Generar una implementación que pasa una comprobación numérica es una capacidad útil, pero optimizar un operador para una carga de producción exige además valorar memoria, latencia, estabilidad, compatibilidad con el resto del sistema y comportamiento en el hardware elegido.
De escribir kernels a dirigir agentes
La predicción de Liu apunta a una transformación del oficio más que a una desaparición inmediata del conocimiento especializado. El ingeniero seguiría definiendo objetivos, seleccionando restricciones, interpretando perfiles de rendimiento y rechazando resultados que solo funcionan en un caso aislado.
En ese modelo, la IA explora variantes y ejecuta ciclos de prueba con mucha rapidez, mientras la persona decide qué merece la pena medir y qué resultado puede incorporarse al sistema. La frontera se desplaza: menos escritura manual de cada instrucción y más diseño del proceso que genera, prueba y selecciona el código.
El repositorio oficial TileKernels muestra el tipo de piezas que están en juego. Incluye implementaciones basadas en TileLang para gating, enrutamiento MoE, cuantización, transposición, Engram y conexiones hiperconectadas de tipo manifold. El proyecto apunta a GPU NVIDIA con arquitecturas SM90 o SM100 y declara como requisitos Python 3.10 o posterior, PyTorch 2.10 o posterior, TileLang 0.1.9 o posterior y CUDA Toolkit 13.1 o posterior.
El ecosistema de optimización de DeepSeek
Los kernels no funcionan aislados del resto de la arquitectura. DeepGEMM está orientado a operaciones GEMM de baja precisión, incluida la optimización FP8, mientras que TileKernels reúne operadores para distintas partes del recorrido de los datos. En modelos con expertos, el enrutamiento y la distribución de las comunicaciones pueden ser tan determinantes como el cálculo de cada matriz.
Por eso conviene separar dos historias que a menudo se mezclan: por un lado, un experimento de NVIDIA demuestra que un modelo puede generar kernels numéricamente correctos dentro de un flujo con verificador; por otro, Shengyu Liu anticipa que esa clase de herramientas podría alcanzar o superar su rendimiento personal en seis a doce meses. El primer punto ya tiene una demostración acotada. El segundo sigue siendo una previsión de Liu.
