NVIDIA announced native GPU programming in Rust with two distinct kernel-writing tracks, cuda-oxide and cutile-rs, closing a gap where GPU kernels had to be written in C++ or Python even when the surrounding stack was Rust. The move expands CUDA's language ecosystem as more of the systems layer—inference engines, serving infrastructure, drivers, and agent runtimes—shifts toward Rust for its compile-time safety guarantees.
The cuda-oxide track follows the SIMT (Single Instruction Multiple Threads) model already familiar from CUDA C++ and numba-cuda. It is a custom rustc codegen backend that intercepts compilation, routes kernel functions through Rust MIR, the Pliron IR framework, and LLVM down to PTX. A kernel written in cuda-oxide uses types like DisjointSlice to enforce exclusive access at compile time: each thread gets its own mutable slice element, and the compiler rejects any attempt to pass the same buffer as both input and output. The #[launch_contract] macro declares the kernel's indexing shape and thread block size, and the prepare method validates the launch configuration against both that contract and live device limits before execution.
The cutile-rs track operates at a higher level, using the Tile programming model where the kernel body runs once per tile of data as a single logical thread, and the compiler decides how many real GPU threads back each tile. The #[cutile::module] macro embeds the kernel's AST in the host binary and JIT-compiles it through CUDA Tile IR when first needed. Partitioning on the host—calling .partition([128]) on a 1,024-element tensor—does three jobs at once: it gives each tile exclusive ownership of its 128-element chunk, fixes the grid at 8 tiles, and supplies the tile width as a compile-time constant without recompilation.
The two tracks differ in maturity and requirements. cuda-oxide is early alpha and requires a pinned nightly toolchain (nightly-2026-04-03), CUDA 12.x or newer, clang with libclang headers, and a GPU with compute capability 8.0 or later. cutile-rs is further along: it is published on crates.io, runs on stable Rust 1.89 or newer with CUDA 13.3, requires no custom LLVM, and is already used in HuggingFace's Grout inference engine and mistral.rs. Both enforce memory safety at compile time—cuda-oxide through DisjointSlice and launch contracts, cutile-rs through tensor partitioning and ownership—and both reject aliasing mistakes that would race in production.
The safety guarantees come at different costs. SIMT kernels keep thread indexing and shared memory control, but shared memory currently requires unsafe code. Tile kernels eliminate thread races by construction because the compiler owns thread mapping and memory layout, but that means no shared memory and no per-thread control. NVIDIA plans to support inter-language interoperability between CUDA Rust, CUDA C++, and CUDA Python so the choice of frontend does not lock developers into one ecosystem.
Both projects are early-stage. cuda-oxide still requires a pinned nightly toolchain, which NVIDIA acknowledges is exactly the kind of friction it wants to remove. Coverage is incomplete and APIs will move. The ecosystem includes prior work from rust-cuda, rust-gpu, and CubeCL, and NVIDIA has been working with the rust-cuda maintainers as both projects mature.
For teams evaluating language choices for custom CUDA kernels, the decision hinges on whether you need thread-level control and shared memory—reach for cuda-oxide on SIMT—or whether you can accept the compiler owning those details in exchange for memory safety by construction and stable Rust—reach for cutile-rs on Tile.