Rust has quietly become the language of the AI systems layer. Inference engines, serving infrastructure, drivers, and agent runtimes — more and more of it is written in Rust. NVIDIA's own Nova Linux driver is Rust. NVIDIA Dynamo is built on a Rust core. NVTX has Rust bindings.
The one holdout has been the GPU kernel itself. You could launch kernels from Rust, but the kernel had to be written in CUDA C++ or numba-cuda. NVIDIA's September 2026 announcement of CUDA Rust closes that gap: GPU kernels can now be written in Rust and compiled natively to PTX, rather than wrapped around code from somewhere else.
Two Projects, Two Programming Models
CUDA Rust ships as two tracks, mirroring the two models CUDA itself has — SIMT and Tile.
cuda-oxide is the SIMT track. It's a custom rustc codegen backend. It intercepts compilation, routes #[kernel] functions through Rust MIR, the community Pliron IR framework, and LLVM IR down to PTX, and hands everything else to the standard backend. The GPU dialects on top of Pliron are NVIDIA's, and every transform stays in Rust until the standard LLVM backend takes over.
Requirements are heavy: Linux, a GPU with compute capability 8.0 or later, a CUDA toolkit (12.x or newer), clang with libclang headers, and a pinned nightly toolchain. Install the Cargo subcommand that drives the build:
cargo +nightly-2026-04-03 install --git https://github.com/NVlabs/cuda-oxide.git cargo-oxide
Then scaffold a project and run it — the template is a complete vector-addition program:
cargo oxide new vecadd_demo
cd vecadd_demo
cargo oxide doctor
cargo oxide run
The first run builds the codegen backend, so expect it to take a while.
cutile-rs is the Tile track. You perform computations on tiles rather than scalars. Each tile block runs the kernel body once as a single logical thread over one sub-tensor of data, and the compiler decides how many real GPU threads back it. The #[cutile::module] macro embeds the kernel's AST in the host binary and JIT-compiles it through CUDA Tile IR when the kernel is first needed.
Requirements are lighter: a GPU with compute capability 8.0 or later, CUDA 13.3, stable Rust 1.89 or newer, and Linux — no nightly toolchain and no LLVM of your own. cutile is published, so getting started is just:
cargo new vecadd_demo
cd vecadd_demo
cargo add cutile
What the Compiler Catches
Both kernels make the same memory-safety claim: inputs are shared, output belongs to one writer alone. They differ in how they enforce it.
In cuda-oxide, the output buffer is a DisjointSlice<f32>, a type that hands each thread exclusive access to its own element and nothing else. Why not &mut [f32]? Because every thread would need the same &mut, which Rust correctly refuses. DisjointSlice splits that one mutable borrow into per-thread pieces. Passing the SIMT kernel's output buffer as one of its own inputs doesn't compile — the compiler emits error[E0502]: cannot borrow c_dev as mutable because it is also borrowed as immutable.
In cutile-rs, safety comes from tensor partitioning. The host-side .partition([128]) does three jobs at once: it gives each tile exclusive ownership of its own 128-element chunk, fixes the grid at 1024/128 = 8 tiles, and supplies the kernel's static dimension B. The same aliasing mistake fails to compile there too, with error[E0382]: use of moved value: z. The article notes this is the stronger of the two claims — ownership follows the tensors across the launch boundary.
Where They Stand and What I'd Do
Both projects are early-stage and neither is production-ready. cuda-oxide is early alpha. cutile-rs is further along, published on crates.io and already used outside NVIDIA in HuggingFace's Grout inference engine and in mistral.rs. Coverage is incomplete and APIs will move. NVIDIA explicitly says it plans to support inter-language interop between CUDA Rust, CUDA C++, and CUDA Python, so the choice of frontend won't lock you out of the others.
My take: if you're picking one to build on, reach for Tile first. The compiler decides how tiles map onto each architecture, so your source doesn't encode architecture-specific choices. Drop to SIMT when you need that control or want to manage memory and threads yourself — though be aware that shared memory there today requires unsafe, and making that path safe is active work.
There's real prior art here — rust-gpu, rust-cuda, and cudarc pioneered Rust on GPUs — and NVIDIA says it has been working with the rust-cuda maintainers as both projects mature. The ecosystem appendix in the cuda-oxide book maps where CUDA Rust sits relative to the rest.
Want to try it? Run the SIMT example with cargo oxide run, or the Tile example with cargo run -p cutile-examples --example hello_world after cloning cutile-rs. Both print PASSED: all 1024 elements correct, so you can read them side by side. Melih Elibol is presenting the underlying paper, Fearless Concurrency on the GPU, at RustConf 2026 in Montréal (Sept. 8-11) — worth watching if you're weighing whether to bet a systems rewrite on this.
The SIMT track still needs that pinned nightly toolchain, which NVIDIA itself flags as "exactly the kind of thing we would like to stop asking you for." For a stable-Rust path today, cutile-rs is the one that works out of the box.
Sources: