CUDA Rust: two native tracks, not a wrapper over C++

Nvidia published an announcement with an ambitious name on its developer blog on September 8, 2026: CUDA Rust. The question I'm interested in isn't whether Rust on GPU sounds good — it does, it always does — but what's actually underneath the announcement. Is it a native frontend that compiles to PTX, as the text claims, or does it end up being a layer over the usual CUDA C++ toolchain? And what about wgpu, rust-gpu and rust-cuda, which were already solving part of this problem?

Hypothesis, scope and status

The hypothesis of this post is specific: "native" in Nvidia's blog means the kernel compiles from Rust down to PTX without going through CUDA C++ as an intermediary, but that doesn't imply the two announced projects replace the existing Rust-GPU ecosystem, nor that they're production-ready.

Status of this note: it's a reading of the primary source, not my own bench test. I didn't run the examples. What follows separates what the blog claims from what still needs verifying with code.

What the primary source says

According to Nvidia's official blog, published September 8, 2026, there are two distinct projects, not one:

cuda-oxide (SIMT track). It's a custom codegen backend for rustc. It intercepts compilation, routes functions marked with #[kernel] through Rust MIR, the Pliron community IR framework, and from there to LLVM IR down to PTX. The rest of the program is handled by the standard Rust backend. It requires Linux, a GPU with compute capability 8.0+, CUDA toolkit 12.x or higher, clang with libclang headers, and a pinned nightly toolchain (nightly-2026-04-03 in the blog's example).

cutile-rs (Tile track). This one works a level higher: instead of programming per thread, you program per tile. The #[cutile::module] macro embeds the kernel's AST in the host binary and JIT-compiles it via CUDA Tile IR when the kernel is first needed. It runs on stable Rust 1.89+, with CUDA 13.3, no nightly and no custom LLVM. It's already published on crates.io, and the blog mentions it's used outside Nvidia in HuggingFace's Grout inference engine and in mistral.rs.

The sentence that answers the first part of the reader's question is right there in the text: "GPU kernels can be written in Rust, compiled natively to PTX, rather than a wrapper around code from somewhere else." That's a claim from the source, not a measurement of mine. Given that, the stated mechanism is native compilation to PTX via MIR/Pliron/LLVM (for cuda-oxide) or via CUDA Tile IR (for cutile-rs), not a bindings layer over already-compiled CUDA C++ binaries.

What the blog doesn't settle about replacement vs. complement

Here's the real limit of the evidence. The blog is explicit that it does not present itself as a replacement:

"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."

And it also names the goal of cross-language coexistence:

"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."

Two things remain unresolved with this single source:

1. How mature the actual interoperability is. The blog says "plans to support," future tense. There's no code example showing that interop working today. Treating it as available would be inflating the claim.
2. Technical relationship with wgpu. The text compares cuda-oxide and cutile-rs against Rust-GPU, rust-cuda and CubeCL (via an appendix in the cuda-oxide book that I didn't read), but doesn't mention wgpu in the available fragment. wgpu targets multi-backend portability (Vulkan, Metal, DX12, WebGPU); CUDA Rust targets Nvidia's stack purely. These are different goals, so "replaces" probably doesn't apply there — but this is my own inference from what I know about wgpu, not something the source explicitly confirms.

Environment and commands to verify the hypothesis (protocol, not execution)

This is a verification plan, not a result. I didn't run these commands.

For cuda-oxide (SIMT track), the blog documents:

# Requires Linux, GPU compute capability 8.0+, CUDA toolkit 12.x+,
# clang with libclang, pinned nightly toolchain
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

The example program does vector addition (1024 floats) and verifies the result with PASSED: all 1024 elements correct. The technical detail that marks the difference from a wrapper: the DisjointSlice<f32> type replaces &mut [f32] for the output buffer, because Rust's borrow checker doesn't allow thousands of threads to share the same &mut. DisjointSlice splits that single borrow into exclusive per-thread fragments, checked at compile time. That's the kind of guarantee a thin wrapper over CUDA C++ couldn't provide, because the Rust compiler needs to see the type to reason about aliasing.

For cutile-rs (Tile track), the blog documents:

# Requires GPU compute capability 8.0+, CUDA 13.3, stable Rust 1.89+, Linux
# No nightly, no custom LLVM
cargo new vecadd_demo
cd vecadd_demo
cargo add cutile

With the hello_world example from the cutile-rs repo running via cargo run -p cutile-examples --example hello_world.

Criterion for accepting or rejecting the hypothesis: if someone runs both examples and confirms that the final binary doesn't depend on nvcc or a CUDA C++ compiler anywhere in the kernel's compilation path, the "native, not wrapper" hypothesis is empirically supported. If a hidden C++ dependency shows up in the build chain, the hypothesis falls.

Limits of this note

• I didn't run cargo oxide run or the cutile-rs example. Everything I describe about compiler behavior comes from the blog text, not from a run of my own.
• The fragment of the source I have is truncated at several points (marked [fragment] in the original), so there may be nuances about cross-language interoperability or about the comparison appendix with Rust-GPU/CubeCL that I didn't get to read in full.
• Both projects explicitly declare themselves unfit for production: cuda-oxide is in early alpha, cutile-rs is "further along" but with incomplete coverage and APIs that will still move, according to the blog's own words.
• There's no performance benchmark in the source or in this note. Any speed comparison between these tracks and traditional CUDA C++ would need a separate experiment, with fixed hardware and versions.

Where this stands

With the evidence I have, I don't take it for granted that "native compilation to PTX" equals "ready to replace CUDA C++ in a real system." The blog is careful not to promise that — it talks about early-stage projects, with heavy requirements (pinned nightly, system LLVM) on the track that most resembles traditional CUDA C++. If I had to decide today whether to adopt this in an inference system, I wouldn't do it without first running the two official examples and comparing the build pipeline against what rust-cuda or CubeCL already offer — both of which have been in the ecosystem longer and don't depend on a freshly published compiler backend preview.

Original source

• Nvidia Developer Blog — Introducing CUDA Rust: Two Tracks for Writing GPU Kernels: https://developer.nvidia.com/blog/introducing-cuda-rust-two-tracks-for-writing-gpu-kernels

---

This article was originally published on juanchi.dev