Nvidia Gives Rust Two Ways to Write CUDA Kernels

Writing a GPU kernel has meant writing C++, even for teams that moved everything else to Rust. Nvidia's Sept. 8, 2026 developer blog post opens two paths around that: cuda-oxide and cutile-rs, both compiling Rust straight to PTX, the instruction format CUDA kernels run as, instead of wrapping a C++ kernel from the outside.

The two tracks are not one project with two names. They are separate codebases, at different stages of readiness, built by overlapping teams for different jobs.

What CUDA Rust actually replaces

Until now, a Rust program could launch a CUDA kernel, but the kernel itself was written elsewhere. cuda-oxide and cutile-rs let the kernel body itself be Rust, checked by Rust's own compiler rather than trusted to a separate C++ file the build pulls in.

cuda-oxide is the lower-level of the two, aimed at the same territory as hand-written CUDA C++. It works as a custom codegen backend for rustc: functions marked #[kernel] get routed through Rust's MIR, then the Pliron community IR framework, then LLVM IR, down to PTX. Nvidia's post describes the memory-safety mechanism as a DisjointSlice<T> type plus launch contracts, so that "outputs belong to one writer alone" is checked before a kernel ever runs, not discovered after a race condition corrupts a buffer.

That safety costs a stable compiler. cuda-oxide needs a pinned nightly Rust toolchain, nightly-2026-04-03 as of the Sept. 8 post, plus clang with libclang headers and a GPU of compute capability 8.0 or later. Nvidia's post marks it early alpha, not production-ready, and installing it means building from source: cargo +nightly-2026-04-03 install --git https://github.com/NVlabs/cuda-oxide.git cargo-oxide.

Both tracks require compute capability 8.0 or later, a floor that an H100 like the ones above, at compute capability 9.0, clears comfortably; older Turing-generation cards do not.

How cutile-rs skips the nightly requirement

cutile-rs sits a level up. Instead of writing per-thread logic, a developer describes what happens to one tile of data, and the macro captures that module's syntax tree into the host binary; the kernel is JIT-compiled through CUDA Tile IR the first time it is actually launched, not at build time.

Safety comes from tensor partitioning rather than a custom type: each tile owns a 128-element chunk that no other tile can touch, enforced through ordinary Rust ownership rules. The practical difference shows up in the toolchain: cutile-rs runs on stable Rust 1.89 or later, needs CUDA 13.3, and installs with a plain cargo add cutile. No nightly compiler, no custom LLVM build.

Track	Status	Rust toolchain	Minimum CUDA
cuda-oxide	Early alpha	Pinned nightly (nightly-2026-04-03)	CUDA toolkit 12.x
cutile-rs	On crates.io, in production	Stable Rust 1.89+	CUDA 13.3

Who is already running production code on it

Nvidia's post names two users of cutile-rs already in production: HuggingFace's Grout inference engine and the mistral.rs project. Both are exactly the kind of Rust-native inference stack that previously had to drop into C++ or an FFI binding the moment it needed a custom kernel.

cuda-oxide's launch contracts, checked before a kernel runs rather than after, are part of a broader push to catch mistakes at compile time instead of runtime, the same bet Bend 2 is making for AI-written code with formal proof instead of ownership types.

The work is not solely Nvidia's. Author Melih Elibol presented it at RustConf 2026, held Sept. 8 to 11 at the Palais des Congrès in Montreal and organized by the Rust Foundation. A paper posted to arXiv on June 14, 2026, titled Fearless Concurrency on the GPU, lists Elibol alongside Jared Roesch, Isaac Gelado, Eric Buehler and Michael Garland, and claims cutile-rs reaches 7 terabytes per second on element-wise operations and 2 petaflops on GEMM, general matrix multiplication, on an Nvidia B200. That figure comes from the authors' own paper rather than an independent benchmark, and the paper reports it as matching, not beating, existing frameworks within measurement tolerance.

What Nvidia has not shipped yet

Nvidia's post is candid that Rust on GPUs did not start here: it names rust-cuda, rust-gpu and CubeCL as prior projects and says the cuda-oxide team has "been working with the rust-cuda maintainers as both projects mature," rather than claiming to replace them.

What the post promises but has not delivered is interoperability between its own two tracks, plans for what it calls inter-language interop so a project is not locked into whichever one it starts with. Until that ships, a team choosing between cuda-oxide's alpha safety guarantees and cutile-rs's stable toolchain is picking one, not both. The Rust Foundation has separately spent 2026 warning crates.io maintainers about state-sponsored supply-chain attacks, a reminder that a language's growing footprint in systems code cuts both ways. Nvidia has not published a date for when the two tracks converge.