NVIDIA acaba de avanzar en uno de los frentes más delicados de la programación de aceleradores: escribir kernels GPU en Rust sin abandonar CUDA. La compañía presentó CUDA Rust como un esfuerzo para tratar Rust como un lenguaje de primera clase en la GPU y, para ello, ha abierto dos proyectos bajo NVlabs: cuda-oxide y cutile-rs. No se trata de una única API nueva, sino de dos rutas distintas hacia el mismo objetivo: mayor seguridad en el desarrollo y acceso a modelos de programación modernos sin perder compatibilidad con el ecosistema NVIDIA.

El primer proyecto, cuda-oxide, se centra en kernels SIMT, el modelo clásico de CUDA en el que miles de hilos ejecutan la misma operación sobre datos distintos. Su propuesta técnica es ambiciosa: tomar el MIR, la representación intermedia de Rust, transformar los kernels mediante Pliron y aprovechar LLVM para generar PTX, el lenguaje intermedio que luego puede integrarse en el flujo de compilación CUDA. La clave no está solo en llegar a PTX, sino en conservar información tipada y comprobable durante el proceso para detectar errores en tiempo de compilación.

La segunda vía es cutile-rs, orientado a CUDA Tile, un modelo más reciente que organiza el cálculo en bloques o tiles y permite expresar de forma más explícita la estructura de las operaciones sobre matrices. A diferencia de cuda-oxide, cutile-rs realiza una compilación JIT: genera el código durante la ejecución, atravesando CUDA Tile IR. Su requisito mínimo es Rust estable 1.89 o superior. Esta aproximación facilita experimentar con abstracciones de alto nivel y optimizaciones dependientes del dispositivo, aunque introduce una fase de preparación que conviene medir antes de llevarla a cargas de producción.

La diferencia entre ambas rutas refleja una realidad del ecosistema CUDA. SIMT ofrece un camino conocido para adaptar código y patrones existentes; Tile apunta a un futuro en el que las operaciones puedan describirse con más semántica y ajustarse mejor a arquitecturas GPU modernas. NVIDIA no elige uno de los dos caminos, sino que mantiene las dos líneas para atraer a comunidades con necesidades distintas y evitar que la migración a Rust dependa de una sola forma de expresar el cómputo paralelo.

Para profesionales de IA y HPC, el atractivo principal es la seguridad. Rust limita muchos fallos asociados al manejo manual de memoria, como accesos fuera de límites o uso de punteros inválidos, y su sistema de tipos permite modelar restricciones que en C o C++ pueden pasar desapercibidas hasta ejecutarse en un clúster. En una GPU, donde un fallo puede afectar a millones de hilos y ser difícil de reproducir, esas garantías pueden reducir costes de depuración. Eso no convierte automáticamente todo kernel en seguro: la corrección de sincronización, la coherencia entre host y dispositivo y las reglas específicas de la GPU siguen exigiendo una ingeniería rigurosa.

También existe una razón estratégica. CUDA domina el mercado de las aceleradoras para entrenamiento e inferencia, pero su modelo de desarrollo sigue dependiendo en gran medida de CUDA C, C++ y herramientas muy vinculadas a NVIDIA. Rust ofrece memoria sin recolector de basura, concurrencia explícita y una comunidad creciente de compiladores y bibliotecas. Si cuda-oxide y cutile-rs maduran, podrían reducir la fricción para equipos que ya usan Rust en inferencia, servicios, compiladores o infraestructura y que hoy deben escribir una segunda versión del núcleo computacional en otro lenguaje.

El impacto todavía está por ver. Los proyectos son de código abierto y avanzan por una ruta compiler-first, pero la adopción dependerá de cobertura de APIs, calidad de diagnósticos, rendimiento frente a CUDA C++ y madurez de las herramientas de perfilado. CUDA Rust no elimina la dependencia de NVIDIA ni promete portabilidad inmediata entre GPU y frameworks. Su importancia radica en abrir una capa de programación más segura y moderna sobre una infraestructura que, mientras tanto, seguirá siendo central para la inteligencia artificial.