Por Canuto  

NVIDIA presentó CUDA Rust, una iniciativa que lleva el lenguaje de programación Rust al desarrollo de kernels de GPU mediante cuda-oxide y cutile-rs. Las herramientas buscan aprovechar el sistema de propiedad de Rust para detectar ciertos errores de aliasing y conflictos de memoria durante la compilación, aunque ambas continúan en fase experimental y no cuentan con confirmación para entornos de producción.
***

  • cuda-oxide traduce kernels SIMT desde el ecosistema de Rust hacia PTX mediante una ruta que incluye Pliron y LLVM, y exige una configuración experimental con CUDA 12.x o posterior.
  • cutile-rs utiliza el modelo Tile y está orientado a escribir kernels seguros y libres de determinadas condiciones de carrera en Rust.
  • Las dos herramientas buscan bloquear accesos conflictivos a buffers antes de ejecutar el código, aunque sus niveles de madurez siguen siendo experimentales.

 

NVIDIA anunció CUDA Rust, una iniciativa para convertir a Rust en un lenguaje de primera clase para escribir kernels de GPU. Hasta ahora, el código Rust podía lanzar kernels de CUDA, pero normalmente el cuerpo de esas funciones debía escribirse en otro lenguaje, una separación que limitaba la continuidad del desarrollo. La propuesta busca cerrar esa brecha con dos proyectos de código abierto alojados por NVlabs: cuda-oxide, enfocado en el modelo SIMT, y cutile-rs, basado en el modelo Tile.

El atractivo central no es solamente cambiar la sintaxis con la que se programa una GPU, sino trasladar al dispositivo las garantías de seguridad que distinguen a Rust. En particular, ambas herramientas buscan utilizar las reglas de propiedad y préstamo del lenguaje para rechazar ciertos conflictos de aliasing durante la compilación, antes de que un kernel llegue a ejecutarse. NVIDIA, sin embargo, mantiene una advertencia relevante para los desarrolladores: los dos proyectos son experimentales y no están confirmados para entornos de producción, infora Markthepost.

La iniciativa llega en un momento en que varias capas de la infraestructura de inteligencia artificial incorporan Rust, desde runtimes y motores de inferencia hasta controladores. NVIDIA ya utiliza este lenguaje en el controlador Nova para Linux, en el núcleo de NVIDIA Dynamo y en los bindings de NVTX, pero el kernel de GPU había quedado como una de las excepciones más visibles. CUDA Rust intenta completar ese recorrido sin obligar a los equipos a abandonar la interoperabilidad con C++ o Python.

Dos modelos para programar la GPU

CUDA Rust refleja los dos modelos de programación que CUDA ofrece actualmente para construir kernels. SIMT, utilizado también por CUDA C++ y numba-cuda, describe el trabajo de un hilo individual y luego lo ejecuta de manera masiva sobre miles de hilos; Tile, en cambio, permite describir la operación de un bloque de datos mientras el compilador decide cómo distribuirla entre los hilos reales y cómo organizar la memoria.

La diferencia tiene consecuencias prácticas para quienes diseñan software de inteligencia artificial. El modelo SIMT ofrece control explícito sobre los hilos, los índices y la memoria compartida, pero también expone a los programadores a una mayor cantidad de errores de coordinación. Tile opera en un nivel más alto, porque el compilador Tile IR se encarga de buena parte del mapeo de hilos y de la disposición de los datos.

La documentación de estos proyectos plantea comenzar con Tile cuando el problema pueda expresarse dentro de ese modelo, mientras reserva SIMT para los casos que requieran un control más preciso de los hilos o de la memoria. Esta diferencia no elimina la utilidad de cuda-oxide, ya que algunos kernels necesitan gestionar detalles que Tile no expone. La interoperabilidad entre lenguajes prevista por NVIDIA también pretende que adoptar Rust no aísle a los desarrolladores que ya trabajan con C++ o Python.

Para los equipos de infraestructura, esa compatibilidad puede resultar tan importante como la seguridad del código. Un motor de inferencia podría incorporar un kernel escrito en Rust sin renunciar a componentes existentes en C++ o Python, aunque el nivel real de integración dependerá de la evolución de cada proyecto. Por ahora, CUDA Rust representa una nueva ruta experimental dentro del ecosistema, no un reemplazo inmediato para las herramientas consolidadas.

cuda-oxide lleva Rust al modelo SIMT

cuda-oxide funciona como un backend de generación de código personalizado para rustc. Las funciones marcadas con #[kernel] pasan por el MIR de Rust, el framework de representación intermedia Pliron y LLVM IR antes de convertirse en PTX, mientras que el resto del programa continúa utilizando el backend estándar del compilador. NVIDIA desarrolló los dialectos relacionados con GPU sobre Pliron para conectar las estructuras del lenguaje con las instrucciones destinadas al dispositivo.

La configuración exige Linux, una GPU con compute capability 8.0 o superior, CUDA 12.x o una versión más reciente, clang con libclang y una toolchain nightly fijada en nightly-2026-04-03. El comando cargo oxide doctor revisa el entorno instalado, mientras que cargo oxide new genera un programa de suma de vectores que reúne el código de host y el del dispositivo en un solo archivo. Esa integración simplifica el ejemplo inicial, aunque no elimina las exigencias técnicas del backend.

La seguridad aparece con claridad en la firma del kernel. Las entradas a y b son slices compartidos ordinarios, pero la salida c utiliza un tipo DisjointSlice<f32> que entrega a cada hilo acceso exclusivo a su propio elemento. Un &mut [f32] convencional obligaría a mantener el mismo préstamo mutable entre hilos, una situación que el compilador de Rust rechaza por potencialmente insegura.

El acceso a la salida tampoco queda abierto a índices arbitrarios, porque c.get_mut(idx) devuelve una opción y convierte el caso fuera de límites en una rama que el programa debe manejar. Además, el atributo #[launch_contract] declara la forma esperada del bloque, mientras el método generado prepare_vecadd comprueba la configuración del lanzamiento antes de ejecutarlo. En conjunto, cuda-oxide intenta aplicar controles del lenguaje tanto a la memoria como a la propia llamada de ejecución.

cutile-rs simplifica el modelo Tile

cutile-rs trabaja en un nivel de abstracción superior al de cuda-oxide. Cada bloque Tile ejecuta el cuerpo del kernel una vez como un hilo lógico sobre un sub-tensor, y el compilador decide cuántos hilos físicos de la GPU respaldarán esa operación. La macro #[cutile::module] incorpora el árbol sintáctico del kernel dentro del binario del host y lo compila mediante CUDA Tile IR justo cuando el kernel se lanza por primera vez.

Sus requisitos son más ligeros en varios aspectos. El proyecto necesita Linux, una GPU con compute capability 8.0 o superior, CUDA 13.3 y Rust estable 1.89 o posterior, sin exigir una toolchain nightly ni un LLVM personalizado. La instalación comienza con un proyecto creado mediante cargo new y la incorporación de la dependencia con cargo add cutile, una ruta que puede resultar más accesible para equipos que desean probar el modelo Tile.

En el lado del host, una llamada como partition([128]) cumple varias funciones al mismo tiempo. Asigna a cada tile la propiedad exclusiva de un fragmento de 128 elementos, establece una cuadrícula de 1.024 elementos dividida en ocho tiles y entrega al kernel el ancho constante B. Los tensores de entrada pueden utilizar -1 como dimensión dinámica, que se resuelve cuando se produce el lanzamiento.

El launcher generado toma la propiedad de los tensores y la devuelve cuando termina el trabajo de la GPU, mientras que la ejecución no comienza hasta invocar .sync_on(&stream). Todo lo anterior forma una descripción perezosa registrada en una única cadena, una característica que separa la preparación del cálculo de su sincronización efectiva. Ese diseño reduce la exposición a detalles de hilos y memoria, aunque también limita el control fino disponible en el modelo SIMT.

Qué errores detecta el compilador

La principal promesa de CUDA Rust se observa cuando un programa intenta reutilizar un buffer de manera incompatible. En un kernel SIMT, pasar el buffer de salida como una de sus propias entradas genera el error E0502, porque Rust no permite tomar c_dev como mutable mientras permanece prestado de forma inmutable. La comprobación ocurre antes de la ejecución y evita que el desarrollador dependa únicamente de pruebas posteriores para encontrar el conflicto.

El modelo Tile aplica una protección equivalente mediante la propiedad de los tensores. Si el código intenta usar un valor después de haber transferido su propiedad, el compilador produce el error E0382, identificado como use of moved value: z. La diferencia conceptual es importante: mientras SIMT comprueba las relaciones de préstamo en un entorno con control explícito de hilos, Tile sigue el movimiento de los tensores a través del límite del lanzamiento.

La documentación de cutile-rs presenta el modelo Tile como una vía orientada a kernels seguros y libres de determinadas condiciones de carrera, porque no expone directamente memoria compartida ni indexación de hilos que puedan utilizarse de forma incorrecta. cuda-oxide conserva esas capacidades para los casos que las necesitan, pero su acceso actual a la memoria compartida requiere unsafe. La flexibilidad adicional de SIMT, por tanto, viene acompañada de una superficie mayor para errores y de responsabilidades que el programador debe gestionar.

La adopción temprana de cutile-rs ofrece una señal de interés dentro de la infraestructura de modelos. El proyecto aparece como base de Grout, un banco de pruebas de Hugging Face para inferencia de modelos de lenguaje, aunque esa presencia no equivale a una declaración de madurez general ni a una recomendación para todos los sistemas. No hay confirmación suficiente para afirmar aquí una integración equivalente con mistral.rs. Los equipos interesados deberán considerar cambios de API, limitaciones de compatibilidad y la ausencia de confirmación para producción.

El siguiente paso dependerá de la capacidad de NVIDIA y de la comunidad para estabilizar los compiladores, ampliar la documentación y mantener la interoperabilidad prometida con C++ y Python. cuda-oxide podría atraer a quienes necesiten control de bajo nivel, mientras cutile-rs puede resultar más conveniente para operaciones sobre tensores que encajen en el modelo Tile. La apuesta es significativa, pero su resultado todavía estará condicionado por el rendimiento real, la cobertura de hardware y la evolución de sus herramientas.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados