--- title: "NVIDIA lleva CUDA a Rust para escribir kernels de GPU sin salir del lenguaje" description: "NVIDIA ha dado un paso importante para convertir Rust en un lenguaje de primera clase dentro de CUDA . La compañía ha presentado dos proyectos para escribir kernels de GPU directamente en Rust y compi..." url: https://revistacloud.com/nvidia-lleva-cuda-a-rust-para-escribir-kernels-de-gpu-sin-salir-del-lenguaje/ date: 2026-09-13 modified: 2026-09-11 author: "Silvia A. Feliz" image: https://revistacloud.com/wp-content/uploads/2026/09/cuda-rust-nvidia.jpg categories: ["Guías y recursos", "Inteligencia artificial"] tags: ["CUDA", "GPU", "Kernel", "NVIDIA", "Rust"] type: post lang: es --- # NVIDIA lleva CUDA a Rust para escribir kernels de GPU sin salir del lenguaje NVIDIA ha dado un paso importante para convertir **Rust en un lenguaje de primera clase dentro de CUDA**. La compañía ha presentado dos proyectos para escribir kernels de GPU directamente en Rust y compilarlos a PTX: **cuda-oxide**, orientado al modelo tradicional SIMT, y **cutile-rs**, basado en el nuevo enfoque CUDA Tile. Ambos están todavía en desarrollo y NVIDIA advierte de que ninguno está preparado para producción, pero la compañía prevé seguir madurando CUDA Rust durante 2027 y los próximos años. **Las claves de CUDA Rust en 30 segundos** - NVIDIA permite escribir kernels de GPU directamente en Rust y compilarlos a PTX, sin mantener el kernel en CUDA C++. - Hay dos caminos: cuda-oxide para programación SIMT de bajo nivel y cutile-rs para trabajar con bloques o *tiles*. - NVIDIA recomienda comenzar con Tile cuando no sea necesario controlar directamente hilos y memoria. - Rust permite trasladar parte de sus garantías de propiedad y aliasing a la programación paralela en GPU. - Ambos proyectos son experimentales; cuda-oxide está en fase *early alpha*. La novedad resuelve una situación algo extraña para quienes ya estaban construyendo infraestructura de inteligencia artificial en Rust. El lenguaje lleva tiempo ganando espacio en componentes de sistemas, motores de inferencia y herramientas de infraestructura, pero al llegar al kernel que finalmente se ejecuta dentro de la GPU era habitual tener que cambiar de lenguaje. Con CUDA Rust, NVIDIA quiere eliminar esa frontera. El kernel puede escribirse en Rust y terminar convertido directamente en **PTX (Parallel Thread Execution)**, la representación intermedia utilizada por CUDA para el código destinado a las GPU de NVIDIA. Eso no convierte a Rust en sustituto inmediato de CUDA C++. La propia NVIDIA describe CUDA C++ y CUDA Python como herramientas maduras para entornos empresariales, mientras que sus dos alternativas para Rust siguen en una etapa temprana. ## Dos formas diferentes de programar la GPU con Rust NVIDIA está trasladando a Rust los dos modelos de programación que está desarrollando actualmente dentro de CUDA. El primero es **SIMT (Single Instruction, Multiple Threads)**, el modelo clásico asociado a CUDA. El programador describe qué debe hacer un hilo y después ejecuta miles de hilos en paralelo. Para este enfoque llega **cuda-oxide**. La segunda opción es **Tile**, un nivel de abstracción superior en el que el programador describe operaciones sobre bloques de datos y deja que el compilador decida cómo repartir el trabajo entre los hilos físicos de cada arquitectura. Aquí entra **cutile-rs**. | Característica | cuda-oxide | cutile-rs | | --- | --- | --- | | Modelo | SIMT | Tile | | Nivel de control | Bajo nivel | Más abstracto | | Compilación | Rust → MIR → Pliron → LLVM → PTX | Rust → CUDA Tile IR | | Rust | Nightly fijado | Stable 1.89 o superior | | CUDA | 12.x o posterior | CUDA 13.3 | | GPU mínima | Compute Capability 8.0 | Compute Capability 8.0 | | LLVM propio | Sí / entorno asociado | No | | Estado | Early alpha | Más avanzado, pero experimental | | Recomendación de NVIDIA | Cuando hace falta control | Primera opción general | La recomendación de NVIDIA resulta reveladora: **probar primero Tile y bajar a SIMT cuando realmente sea necesario controlar hilos, memoria o detalles de la arquitectura**. Es una filosofía distinta de la programación CUDA tradicional, donde buena parte del rendimiento dependía de comprender cómo distribuir manualmente bloques, hilos y memoria compartida. CUDA Tile intenta trasladar más de esas decisiones al compilador. La ventaja potencial está en la portabilidad entre generaciones de GPU. Si el código expresa una operación sobre un *tile* de datos en lugar de fijar cómo deben trabajar los hilos concretos, el compilador dispone de más margen para adaptar el kernel a una arquitectura diferente. ## cuda-oxide mantiene el modelo clásico de CUDA Para los desarrolladores que necesitan ese control aparece cuda-oxide, un *backend* personalizado para el compilador `rustc`. Cuando encuentra una función marcada como kernel, la conduce a través de las representaciones intermedias de Rust, el framework Pliron y LLVM hasta generar PTX. El resto del programa continúa utilizando el proceso de compilación habitual. Una característica importante es que **el código de host y el código destinado a la GPU pueden convivir en el mismo archivo Rust**. No es necesario mantener un proyecto separado exclusivamente para los kernels. El modelo sigue siendo reconocible para cualquiera que haya trabajado anteriormente con CUDA: ``` #[kernel] #[launch_bounds(256)] pub fn vecadd(...) { let idx = thread::index_1d(); // operación del hilo } ``` Cada hilo calcula su índice y trabaja sobre una parte de los datos. La diferencia está en cómo Rust puede aplicar su sistema de tipos y propiedad sobre determinados errores que en CUDA tradicional podrían terminar manifestándose durante la ejecución. Uno de los ejemplos utilizados por NVIDIA es `DisjointSlice`. Un `&mut [f32]` normal representaría acceso mutable al *slice* completo y no sería adecuado para miles de hilos intentando escribir simultáneamente sobre distintas posiciones. `DisjointSlice` divide conceptualmente ese acceso para que cada hilo pueda obtener permiso exclusivo sobre su propia posición. El índice del hilo tampoco se maneja simplemente como un entero arbitrario. `thread::index_1d()` devuelve un tipo específico que puede utilizarse con `get_mut`, y el resultado se entrega mediante `Option`. Eso permite convertir ciertos accesos fuera de rango en situaciones que el programa debe gestionar explícitamente en lugar de dejarlas como un error de memoria difícil de reproducir. cuda-oxide también introduce **contratos de lanzamiento**. Una anotación puede declarar que el kernel espera bloques de 256 hilos y un dominio unidimensional. Antes de ejecutarlo, la configuración se valida contra ese contrato y contra las capacidades reales del dispositivo. Cuando un kernel no tiene contrato, el lanzamiento queda marcado como `unsafe`. Es un buen ejemplo de hasta dónde quiere llevar NVIDIA las ideas de seguridad de Rust dentro de CUDA sin esconder por completo el hardware. ## cutile-rs deja que el compilador gestione los hilos cutile-rs adopta una filosofía bastante diferente. El programador deja de pensar principalmente en hilos individuales y trabaja sobre **tiles de datos**. Si hay un vector de 1.024 elementos y se divide en bloques de 128, por ejemplo, el sistema obtiene ocho tiles. Cada uno constituye una unidad lógica sobre la que se ejecuta el kernel. Una operación como: ``` let z = api::zeros::(&[1024]).partition([128]); ``` no se limita a dividir una estructura de datos. La partición establece qué región puede modificar cada tile, determina la geometría de ejecución y proporciona información de tamaño al kernel. A partir de ahí el compilador decide cuántos hilos físicos empleará para ejecutar esa operación en la GPU. También cambia la manera de utilizar la memoria mutable. Cada tile recibe una región exclusiva sobre la que escribir. Dos tiles no deberían poder obtener referencias mutables simultáneas sobre el mismo fragmento. NVIDIA quiere aprovechar así uno de los principios centrales de Rust: **si existe una referencia mutable, no debería existir otra referencia incompatible sobre esos mismos datos al mismo tiempo**. Esta idea tiene especial interés en GPU. Los errores de concurrencia pueden resultar extraordinariamente difíciles de reproducir porque miles de hilos ejecutan operaciones en un orden que el programador no controla completamente. Un conflicto sobre una dirección de memoria puede aparecer únicamente bajo determinadas cargas o configuraciones de hardware. El sistema de propiedad de Rust puede detectar algunas de estas situaciones antes de ejecutar el programa. No significa que Rust convierta automáticamente cualquier kernel GPU en seguro. En cuda-oxide, por ejemplo, el uso directo de memoria compartida todavía requiere bloques `unsafe`, precisamente uno de los aspectos en los que NVIDIA reconoce que queda trabajo. ## Rust empieza a entrar también en la parte más cercana a la GPU La apuesta no aparece aislada. NVIDIA recuerda que distintos componentes de su infraestructura ya emplean Rust. **NVIDIA Dynamo**, su plataforma para inferencia distribuida, tiene un núcleo desarrollado en este lenguaje, mientras NVTX dispone de *bindings* para Rust. La compañía también menciona el trabajo alrededor del controlador Nova para Linux. La programación del kernel era una de las piezas que seguía obligando a saltar a otro lenguaje. CUDA Rust intenta conectar ambos mundos: **Aplicación Rust → runtime CUDA → kernel Rust → PTX → GPU NVIDIA** Eso puede resultar especialmente atractivo para motores de inferencia, bases de datos aceleradas, procesamiento científico o aplicaciones de inteligencia artificial que ya hayan elegido Rust para el resto de su infraestructura. También podría reducir parte de la complejidad derivada de mezclar código Rust con kernels mantenidos independientemente en CUDA C++. ## NVIDIA aún no considera CUDA Rust preparado para producción El anuncio tiene una limitación clara: **estos proyectos no sustituyen todavía a CUDA C++ en aplicaciones críticas**. NVIDIA califica cuda-oxide como *early alpha*. Requiere Linux, una GPU con Compute Capability 8.0 o posterior, CUDA 12.x, Clang y una versión concreta de Rust Nightly. La instalación todavía refleja ese estado: ``` cargo +nightly-2026-04-03 install --git https://github.com/NVlabs/cuda-oxide.git cargo-oxide ``` Después puede crearse un proyecto con: ``` cargo oxide new vecadd_demo cargo oxide doctor cargo oxide run ``` cutile-rs está algo más avanzado desde el punto de vista de distribución. Está publicado como paquete y funciona con Rust estable, aunque requiere CUDA 13.3. ``` cargo new vecadd_demo cd vecadd_demo cargo add cutile ``` NVIDIA señala además que cutile-rs ya se está utilizando fuera de la compañía, incluido **Grout, un motor de inferencia de Hugging Face**, y el proyecto mistral.rs. Aun así, la cobertura de CUDA está incompleta y las interfaces pueden cambiar. El trabajo presentado en *Fearless Concurrency on the GPU* ofrece algunas pistas sobre el objetivo de rendimiento. En pruebas publicadas por sus autores, cuTile Rust alcanzó en una NVIDIA B200 alrededor de **7 TB/s en operaciones elemento a elemento y 2 PFLOPS en GEMM, aproximadamente el 96 % del rendimiento de cuBLAS en esa prueba concreta**. Son resultados experimentales sobre cargas determinadas, no una garantía de que cualquier kernel Rust se acerque automáticamente al rendimiento de las bibliotecas CUDA optimizadas. NVIDIA también quiere añadir interoperabilidad entre CUDA Rust, CUDA C++ y CUDA Python. La intención es que elegir Rust para un kernel no obligue a trasladar el resto de la aplicación al mismo lenguaje. La apuesta es, por tanto, más amplia que publicar dos bibliotecas nuevas. NVIDIA está intentando que **Rust pueda recorrer toda la pila, desde la infraestructura del sistema hasta el código que finalmente ejecutan los núcleos de la GPU**. CUDA C++ seguirá siendo durante bastante tiempo la referencia para muchos desarrolladores que necesitan exprimir el hardware. Pero si cuda-oxide y cutile-rs maduran según lo previsto, Rust podría dejar de ser únicamente el lenguaje que prepara y lanza el trabajo hacia la GPU para convertirse también en el lenguaje que escribe el propio kernel. vía: [developer.nvidia](https://developer.nvidia.com/blog/introducing-cuda-rust-two-tracks-for-writing-gpu-kernels/)