CUDA Rust: dos tracks nativos, no un wrapper sobre C++

Nvidia publicó el 8 de septiembre de 2026 en su blog de desarrolladores un anuncio con nombre ambicioso: CUDA Rust. La pregunta que me interesa no es si Rust en GPU suena bien —suena bien, siempre suena bien— sino qué hay debajo del anuncio. ¿Es un frontend nativo que compila a PTX, como dice el texto, o termina siendo una capa sobre el toolchain de CUDA C++ de siempre? ¿Y qué pasa con wgpu, rust-gpu y rust-cuda, que ya venían resolviendo parte de este problema?

Hipótesis, alcance y estado

La hipótesis de este post es específica: "nativo" en el blog de Nvidia significa que el kernel se compila desde Rust hasta PTX sin pasar por CUDA C++ como intermediario, pero eso no implica que los dos proyectos anunciados reemplacen el ecosistema Rust-GPU existente ni que estén listos para producción.

Estado de esta nota: es una lectura de la fuente primaria, no una prueba de banco propia. No corrí los ejemplos. Lo que sigue separa lo que el blog afirma de lo que falta verificar con código.

Qué dice la fuente primaria

Según el blog oficial de Nvidia, publicado el 8 de septiembre de 2026, hay dos proyectos distintos, no uno:

cuda-oxide (track SIMT). Es un codegen backend custom para rustc. Intercepta la compilación, enruta las funciones marcadas con #[kernel] a través de Rust MIR, el framework de IR de la comunidad Pliron, y de ahí a LLVM IR hasta PTX. El resto del programa lo maneja el backend estándar de Rust. Requiere Linux, GPU con compute capability 8.0+, CUDA toolkit 12.x o superior, clang con headers de libclang, y un toolchain nightly pinned (nightly-2026-04-03 en el ejemplo del blog).

cutile-rs (track Tile). Trabaja un nivel más arriba: en vez de programar por thread, programás por tile. El macro #[cutile::module] embebe el AST del kernel en el binario del host y lo compila JIT vía CUDA Tile IR cuando el kernel se necesita por primera vez. Corre en Rust estable 1.89+, con CUDA 13.3, sin nightly y sin LLVM propio. Ya está publicado en crates.io y el blog menciona que se usa fuera de Nvidia en el motor de inferencia Grout de HuggingFace y en mistral.rs.

La frase que responde la primera parte de la pregunta del lector está en el propio texto: "GPU kernels can be written in Rust, compiled natively to PTX, rather than a wrapper around code from somewhere else." Es una afirmación de la fuente, no una medición mía. Con eso, el mecanismo declarado es compilación nativa a PTX vía MIR/Pliron/LLVM (para cuda-oxide) o vía CUDA Tile IR (para cutile-rs), no una capa de bindings sobre binarios de CUDA C++ ya compilados.

Lo que el blog no resuelve sobre reemplazo vs. complemento

Acá está el límite real de la evidencia. El blog es explícito en que no se presenta como reemplazo:

"Rust on GPUs is not new. There is good work in this space that predates ours and continues alongside it. [...] we have been working with the rust-cuda maintainers as both projects mature."

Y también nombra el objetivo de convivencia entre lenguajes:

"NVIDIA plans to support inter-language interoperability between CUDA Rust, CUDA C++, and CUDA Python so the choice of frontend does not lock developers out of other ecosystems."

Dos cosas quedan sin resolver con esta única fuente:

Estado de madurez real de la interoperabilidad. El blog dice "plans to support", tiempo futuro. No hay ejemplo de código mostrando esa interop funcionando hoy. Tratarlo como disponible sería inflar el claim.
Relación técnica con wgpu. El texto compara cuda-oxide y cutile-rs contra Rust-GPU, rust-cuda y CubeCL (via un apéndice del libro de cuda-oxide que no leí), pero no menciona wgpu en el fragmento disponible. wgpu apunta a portabilidad multi-backend (Vulkan, Metal, DX12, WebGPU); CUDA Rust apunta puramente al stack de Nvidia. Son objetivos distintos, así que "reemplaza" probablemente no aplica ahí — pero esto es una inferencia mía a partir de lo que sé de wgpu, no algo que la fuente confirme explícitamente.

Entorno y comandos para verificar la hipótesis (protocolo, no ejecución)

Esto es un plan de verificación, no un resultado. No corrí estos comandos.

Para cuda-oxide (track SIMT), el blog documenta:

# Requiere Linux, GPU compute capability 8.0+, CUDA toolkit 12.x+,
# clang con libclang, toolchain nightly pinned
cargo +nightly-2026-04-03 install --git https://github.com/NVlabs/cuda-oxide.git cargo-oxide

cargo oxide new vecadd_demo
cd vecadd_demo
cargo oxide doctor
cargo oxide run

El programa de ejemplo hace suma de vectores (1024 floats) y verifica el resultado con PASSED: all 1024 elements correct. El detalle técnico que marca la diferencia frente a un wrapper: el tipo DisjointSlice<f32> reemplaza &mut [f32] para el buffer de salida, porque el borrow checker de Rust no permite que miles de threads compartan el mismo &mut. DisjointSlice divide ese borrow único en fragmentos exclusivos por thread, verificados en compile time. Esa es la clase de garantía que un wrapper delgado sobre CUDA C++ no podría dar, porque el compilador de Rust necesita ver el tipo para razonar sobre aliasing.

Para cutile-rs (track Tile), el blog documenta:

# Requiere GPU compute capability 8.0+, CUDA 13.3, Rust estable 1.89+, Linux
# Sin nightly, sin LLVM propio
cargo new vecadd_demo
cd vecadd_demo
cargo add cutile

Con el ejemplo hello_world del repo cutile-rs corriendo vía cargo run -p cutile-examples --example hello_world.

Criterio para aceptar o descartar la hipótesis: si alguien corre ambos ejemplos y confirma que el binario final no depende de nvcc ni de un compilador de CUDA C++ en el camino de compilación del kernel, la hipótesis de "nativo, no wrapper" queda soportada empíricamente. Si aparece una dependencia oculta de C++ en la cadena de build, la hipótesis cae.

Límites de esta nota

No ejecuté cargo oxide run ni el ejemplo de cutile-rs. Todo lo que describo sobre comportamiento del compilador viene del texto del blog, no de una corrida propia.
El fragmento de la fuente que tengo está truncado en varios puntos (marcado [fragment] en el original), así que puede haber matices sobre la interoperabilidad entre lenguajes o sobre el apéndice de comparación con Rust-GPU/CubeCL que no llegué a leer completos.
Ambos proyectos se declaran explícitamente no aptos para producción: cuda-oxide está en alpha temprana, cutile-rs "está más avanzado" pero con cobertura incompleta y APIs que van a moverse, según palabras del propio blog.
No hay benchmark de performance en la fuente ni en esta nota. Cualquier comparación de velocidad entre estos tracks y CUDA C++ tradicional necesitaría un experimento aparte, con hardware y versiones fijadas.

Postura

Con la evidencia que tengo, no doy por sentado que "compilación nativa a PTX" equivalga a "listo para reemplazar CUDA C++ en un sistema real". El blog es cuidadoso en no prometer eso — habla de proyectos tempranos, con requisitos pesados (nightly pinned, LLVM del sistema) en el track que más se parece al CUDA C++ tradicional. Si tuviera que decidir hoy si adoptar esto en un sistema de inferencia, no lo haría sin antes correr los dos ejemplos oficiales y comparar el pipeline de build contra lo que ya usa rust-cuda o CubeCL, que llevan más tiempo en el ecosistema y no dependen de una preview de compiler backend recién publicada.