NVIDIA anunció programación nativa de GPU en Rust con dos vías distintas de escritura de kernels, cuda-oxide y cutile-rs, cerrando una brecha donde los kernels de GPU tenían que escribirse en C++ o Python incluso cuando el resto del stack era Rust. El movimiento expande el ecosistema de lenguajes de CUDA a medida que más de la capa de sistemas—motores de inferencia, infraestructura de servicio, drivers y runtimes de agentes—se desplaza hacia Rust por sus garantías de seguridad en tiempo de compilación.
La vía cuda-oxide sigue el modelo SIMT (Single Instruction Multiple Threads) ya familiar de CUDA C++ y numba-cuda. Es un backend de codegen rustc personalizado que intercepta la compilación, enruta funciones de kernel a través de Rust MIR, el framework Pliron IR, y LLVM hasta PTX. Un kernel escrito en cuda-oxide usa tipos como DisjointSlice para forzar acceso exclusivo en tiempo de compilación: cada thread obtiene su propio elemento de slice mutable, y el compilador rechaza cualquier intento de pasar el mismo buffer como entrada y salida. La macro #[launch_contract] declara la forma de indexación del kernel y el tamaño del bloque de threads, y el método prepare valida la configuración de lanzamiento contra ese contrato y los límites del dispositivo en vivo antes de la ejecución.
La vía cutile-rs opera a un nivel superior, usando el modelo de programación Tile donde el cuerpo del kernel se ejecuta una vez por tile de datos como un único thread lógico, y el compilador decide cuántos threads reales de GPU respaldan cada tile. La macro #[cutile::module] incrusta el AST del kernel en el binario del host y lo compila JIT a través de CUDA Tile IR cuando se necesita por primera vez. La partición en el host—llamar a .partition([128]) en un tensor de 1,024 elementos—hace tres trabajos a la vez: da a cada tile propiedad exclusiva de su chunk de 128 elementos, fija la grilla en 8 tiles, y suministra el ancho del tile como una constante en tiempo de compilación sin recompilación.
Las dos vías difieren en madurez y requisitos. cuda-oxide es alfa temprana y requiere un toolchain nightly fijado (nightly-2026-04-03), CUDA 12.x o más nuevo, clang con headers de libclang, y una GPU con capacidad de cómputo 8.0 o posterior. cutile-rs está más avanzada: se publica en crates.io, se ejecuta en Rust estable 1.89 o más nuevo con CUDA 13.3, no requiere LLVM personalizado, y ya se usa en el motor de inferencia Grout de HuggingFace y mistral.rs. Ambas fuerzan seguridad de memoria en tiempo de compilación—cuda-oxide mediante DisjointSlice y contratos de lanzamiento, cutile-rs mediante partición de tensores y propiedad—y ambas rechazan errores de aliasing que causarían carreras en producción.
Las garantías de seguridad tienen costos diferentes. Los kernels SIMT mantienen indexación de threads y control de memoria compartida, pero la memoria compartida actualmente requiere código unsafe. Los kernels Tile eliminan carreras de threads por construcción porque el compilador posee el mapeo de threads y el layout de memoria, pero eso significa sin memoria compartida y sin control por thread. NVIDIA planea soportar interoperabilidad entre lenguajes entre CUDA Rust, CUDA C++, y CUDA Python para que la elección del frontend no bloquee a los desarrolladores en un ecosistema.
Ambos proyectos están en etapa temprana. cuda-oxide aún requiere un toolchain nightly fijado, lo que NVIDIA reconoce es exactamente el tipo de fricción que quiere eliminar. La cobertura es incompleta y las APIs cambiarán. El ecosistema incluye trabajo previo de rust-cuda, rust-gpu, y CubeCL, y NVIDIA ha estado trabajando con los mantenedores de rust-cuda a medida que ambos proyectos maduran.
Para equipos evaluando opciones de lenguaje para kernels CUDA personalizados, la decisión depende de si necesitas control a nivel de thread y memoria compartida—opta por cuda-oxide en SIMT—o si puedes aceptar que el compilador posea esos detalles a cambio de seguridad de memoria por construcción y Rust estable—opta por cutile-rs en Tile.