Nvidia opens two paths to natively program GPU kernels in Rust

Nvidia announced in September 2026 that it is investing in native GPU programming in Rust, with two projects that let you write GPU kernels in Rust without going through a wrapper written in CUDA C++ or CUDA Python: cuda-oxide compiles directly to PTX (the intermediate language that runs on Nvidia GPUs) via LLVM, while cutile-rs is JIT-compiled through CUDA Tile IR. The announcement was posted on Nvidia's technical blog, authored by Sri Koundinyan, Melih Elibol, and Jonathan Bentz, and one of the authors, Melih Elibol, is presenting the work at RustConf 2026, in Montréal, from September 8 to 11.

Until now, it was possible to call a CUDA kernel from Rust, but the kernel itself had to be written in another language. That's the gap the two projects close, each with a different philosophy.

Two models, two bets

The first is cuda-oxide, which targets the SIMT model (the same one used by traditional CUDA C++, where you write what a single thread does and launch thousands of them). It's a custom codegen backend for rustc: it intercepts compilation, routes functions marked with #[kernel] through Rust MIR, passes through the community IR framework Pliron, and goes down to PTX via LLVM. It requires Linux, a GPU with compute capability 8.0 or higher, CUDA toolkit 12.x+, clang, and a pinned nightly toolchain (nightly-2026-04-03 in Nvidia's example). It's in early alpha.

The second is cutile-rs, which works on the Tile model, which is more recent and also available in C++ and Python. Instead of indexing individual threads, you describe what happens to a tile (a block of data) and the compiler decides how that maps to the GPU architecture via JIT compilation to CUDA Tile IR. It runs on stable Rust 1.89 or higher, with CUDA 13.3, without needing its own LLVM or nightly. It's already published on crates.io and in use outside Nvidia: in the Grout inference engine, from Hugging Face, and in mistral.rs.

Nvidia's own recommendation in the text is direct: start with Tile, because the compiler decides how tiles map to each architecture and your code doesn't get locked into hardware-specific choices. Drop down to SIMT only when you need that fine-grained control or want to manage memory and threads manually.

Where memory safety comes in

Both projects make the same promise (shared inputs, exclusive write output), just at different layers. In cuda-oxide, the type DisjointSlice replaces a common &mut [f32], because parallel threads can't share the same mutable reference, and the #[launch_contract] macro declares the launch geometry (domain, block size) that the prepare_vecadd function validates against the device's actual limits before running. In cutile-rs, exclusivity comes from the API itself: .partition([128]) does three things at once, it guarantees each tile has an exclusive chunk of 128 elements, it fixes the launch grid (1024/128 = 8 tiles), and it provides the tile width to the compiler.

The practical payoff shows up as a compile-time error, not at runtime. Passing the output buffer as an input in cuda-oxide (module.vecadd(&stream, &prepared, &c_dev, &b_dev, &mut c_dev)?) fails to compile, with error[E0502]: cannot borrow c_dev as mutable because it is also borrowed as immutable. In cutile-rs, trying to reuse a tensor that has already been partitioned and moved produces error[E0382]: use of moved value. These are exactly the data-race bugs that pass tests and blow up in production, caught before the binary even exists.

What changes for those already considering Rust for parallel computing

For those maintaining inference pipelines, simulation engines, or any high-performance code currently in CUDA C++, the announcement isn't a production-ready migration, but it is a signal of direction. Nvidia already uses Rust in critical pieces of its own stack: the Nova driver for Linux is written in Rust, NVIDIA Dynamo has a Rust core, and NVTX gained bindings in the language. Bringing this down to the GPU kernel closes the last link in the chain that still forced a language switch at the most sensitive point in the code.

In practice, those who already use Rust in the rest of the system (for orchestration, for an agent's runtime, for the inference server) gain the ability to write the kernel without leaving the language, without FFI to C++, and without giving up what the Rust compiler already guarantees in other parts of the project. It's different from rewriting existing CUDA: Nvidia's material doesn't promise automatic conversion or proven performance parity, it only shows that the native writing path now exists and works for simple cases like vector addition.

What's still missing

Both projects are declared not production-ready. cuda-oxide remains in early alpha, and Nvidia itself lists the nightly toolchain requirement as something it wants to eliminate. Shared memory coverage on the SIMT side, a central piece for fast kernels, still depends on unsafe blocks, because making it safe is active, unfinished work. cutile-rs is more mature and already runs in production outside Nvidia, but by nature covers fewer use cases (there are no individual threads to manage in the Tile model).

Nvidia also promises interoperability between CUDA Rust, CUDA C++, and CUDA Python, so that the choice of frontend doesn't lock the team into a single ecosystem, but that hasn't been delivered yet. And the announcement publicly acknowledges the prior work of the Rust GPU community, citing the projects rust-cuda, rust-gpu, cudarc, and CubeCL, and says it is in talks with the rust-cuda maintainers as both sides move forward. For those who want to follow closely, the code for both projects is open: cuda-oxide on NVlabs' GitHub, with a pinned nightly toolchain, and cutile-rs published directly on crates.io.