NVIDIA ha dado un paso que muchos en la comunidad de Rust llevaban años esperando. La compañía ha presentado CUDA Rust, un conjunto de herramientas que permite escribir kernels de GPU directamente en Rust, compilándolos de forma nativa a PTX en lugar de depender de envoltorios sobre código escrito en otros lenguajes.
La noticia, anunciada en septiembre de 2026, no es un experimento aislado, sino la culminación de un esfuerzo sostenido por llevar la seguridad de memoria al corazón de la computación de alto rendimiento.
El movimiento de NVIDIA responde a una realidad incuestionable. La capa de sistemas de la inteligencia artificial —motores de inferencia, infraestructura de servicio, controladores, runtimes de agentes— está escrita cada vez más en Rust. El propio controlador Nova para Linux está escrito en Rust. NVIDIA Dynamo se construyó sobre un núcleo en Rust.
NVTX tiene bindings en Rust. La única pieza que faltaba era el kernel de GPU, ese fragmento de código que se ejecuta en miles de hilos paralelos y que hasta ahora requería C++ o Python. CUDA Rust cierra esa brecha.
Dos caminos para escribir kernels en Rust
NVIDIA ha diseñado dos pistas paralelas para escribir kernels, reflejando los dos modelos que ya existían en CUDA.
La primera es SIMT (Single Instruction, Multiple Threads), el modelo clásico que cualquiera que haya escrito CUDA C++ reconoce. En SIMT, el programador describe lo que hace un solo hilo y lanza miles de ellos. El control es máximo, pero también lo es la responsabilidad de gestionar manualmente la memoria y los índices.
La segunda pista es Tile, un modelo más reciente que también está disponible en C++ y Python. En Tile, el programador describe lo que hace un bloque de datos —una tile— y el compilador decide cómo mapear esas tiles sobre la arquitectura concreta de la GPU.
No hay índices de hilos que gestionar, no hay memoria compartida que administrar. El compilador se encarga de todo.
La recomendación de NVIDIA es clara: empezar por Tile y bajar a SIMT solo cuando se necesita control explícito sobre la gestión de memoria y threads. La elección del modelo no está atada a la elección del lenguaje.
Los dos proyectos que NVIDIA presenta son para quienes ya tienen un stack en Rust, pero la interoperabilidad con C++ y Python está en la hoja de ruta.
Cuda-oxide: el backend que convierte Rust en PTX
La pista SIMT se materializa en cuda-oxide, un backend de generación de código personalizado para rustc. El compilador intercepta la compilación, enruta las funciones marcadas con #[kernel] a través de Rust MIR, el framework de IR Pliron de la comunidad, y LLVM IR hasta llegar a PTX. Todo lo demás se delega al backend estándar.
El resultado es un flujo de trabajo que permite escribir código de host y de dispositivo en el mismo archivo, compilarlo con un solo comando y ejecutarlo sin necesidad de un crate separado para el kernel. La seguridad la proporciona el propio sistema de tipos de Rust. El kernel de ejemplo, una suma elemento a elemento sobre 1.024 floats, utiliza DisjointSlice<f32> para garantizar que cada hilo tiene acceso exclusivo a su propio elemento.
El tipo thread::index_1d() devuelve un índice tipado, no un simple entero, y c.get_mut(idx) solo acepta ese tipo. El resultado es un Option, de modo que el caso fuera de límites es una rama que se maneja, no un error de memoria que se descubre más tarde.
Además, el lanzamiento está verificado, no confiado. El atributo #[launch_contract] declara que el kernel indexa en una dimensión con bloques de 256 hilos. La función prepare_vecadd valida la configuración contra esa declaración y contra los límites reales del dispositivo, y devuelve una prueba que el método seguro vecadd requiere.
Los kernels sin contrato solo exponen métodos de lanzamiento inseguros, porque una configuración sin garantías no dice nada sobre el kernel que se está lanzando.
Cutile-rs: el modelo de tiles sobre Rust estable
La pista Tile se materializa en cutile-rs, que opera un nivel por encima. En lugar de trabajar con escalares, el programador realiza computaciones sobre tiles. Cada bloque de tile ejecuta el cuerpo del kernel una vez como un único hilo lógico sobre un sub-tensor de datos, y el compilador decide cuántos hilos reales de GPU lo respaldan.
El macro #[cutile::module] embebe el AST del kernel en el binario de host y lo compila JIT a través de CUDA Tile IR cuando el kernel se necesita por primera vez.
Los requisitos son más ligeros que en la pista SIMT. Se necesita una GPU con capacidad de cómputo 8.0 o superior, CUDA 13.3, Rust estable 1.89 o superior y Linux. No se requiere toolchain nightly ni LLVM propio.
El ejemplo de suma elemento a elemento escrito para tiles llega al mismo resultado que el de SIMT, pero sin necesidad de DisjointSlice. La partición en el host —api::zeros::<f32>(&[1024]).partition([128])— hace tres cosas a la vez: da a cada tile posesión exclusiva de su propio fragmento de 128 elementos, fija la geometría del lanzamiento en una grid de 8 tiles y proporciona el ancho de tile que el kernel necesita.
Nada se ejecuta hasta que se llama a .sync_on(&stream). Todo lo anterior es una descripción perezosa, registrada en lugar de enviada. El programa entero es una cadena con un único punto de sincronización.
Lo que el compilador atrapa: la seguridad de memoria en la GPU
Ambos kernels hacen la misma afirmación sobre la memoria: sus entradas son compartidas y su salida pertenece a un único escritor. La diferencia está en el nivel al que hacen esa afirmación y en si necesitan un tipo construido a propósito para hacerla.
Esto importa porque miles de hilos acceden a los mismos buffers sin un orden garantizado. Cuando dos de ellos golpean la misma dirección y uno está escribiendo, el orden decide el resultado. Esos bugs rara vez se reproducen bajo demanda, y pasan las pruebas antes de fallar en producción.
Pasar el buffer de salida del kernel SIMT como una de sus propias entradas no compila, independientemente de si ese kernel realmente causaría una condición de carrera. El compilador de Rust lo rechaza con un error de préstamo. Lo mismo ocurre con la versión Tile: usar el mismo tensor como entrada y salida produce un error de valor movido.
Ambos ejemplos atrapan el error clásico de aliasing en tiempo de compilación, y trazan la línea en lugares diferentes. Cuda-oxide verifica cada llamada de lanzamiento. Cutile-rs va más allá: la propiedad de los tensores sigue su curso a través de la frontera del lanzamiento, que es la afirmación más fuerte de las dos.
El estado actual: early alpha, pero con dirección clara
NVIDIA es honesta sobre el estado de ambos proyectos. Cuda-oxide está en early alpha. Cutile-rs está más avanzado, publicado en crates.io y ya utilizado fuera de NVIDIA en el motor de inferencia Grout de HuggingFace y en mistral.rs. La cobertura es incompleta y las APIs cambiarán. Donde se encuentren asperezas, NVIDIA pide que se reporten.
La compañía reconoce que Rust en GPU no es nuevo. Hay trabajo valioso que precede al suyo y que continúa en paralelo.
Lo que es nuevo es la ingeniería que NVIDIA está poniendo detrás y una dirección clara de hacia dónde va. La pista SIMT todavía requiere un toolchain nightly fijado, exactamente el tipo de cosa que NVIDIA quiere dejar de pedir a los desarrolladores.
¿Por qué esto importa?
La computación en GPU ha sido durante décadas un territorio hostil para los programadores.
La gestión manual de memoria, los errores de indexación, las condiciones de carrera no deterministas y la falta de herramientas de seguridad han convertido el desarrollo de kernels en una disciplina reservada a especialistas. CUDA Rust promete cambiar esa ecuación sin sacrificar el rendimiento.
La seguridad de memoria, que Rust garantiza en tiempo de compilación, es precisamente lo que la computación de alto rendimiento necesita para avanzar hacia aplicaciones más complejas y fiables.
Si NVIDIA consigue madurar estas herramientas, el desarrollo de kernels de GPU podría volverse accesible a una nueva generación de programadores que no están dispuestos a aceptar los riesgos de C++.
El camino es largo. Ambos proyectos son embrionarios. Pero la dirección es clara, el respaldo es sólido y la necesidad es real. La GPU del futuro podría hablar Rust. Y si eso ocurre, la seguridad de memoria habrá conquistado su última frontera.
Descubre más desde CIBERED
Suscríbete y recibe las últimas entradas en tu correo electrónico.
