CUDA Rust closes the gap between Rust and the GPU kernel

Rust has been moving deeper into the systems layer of AI, but GPU kernels have remained an awkward boundary.

NVIDIA is now trying to remove that boundary.

On September 8, the company introduced CUDA Rust as two native paths for writing GPU kernels in Rust. The key word is native: the kernel itself can be written in Rust and compiled into PTX instead of using Rust only as host code around a kernel written somewhere else.

NVIDIA is starting with two programming models. `cuda-oxide` follows the familiar SIMT style used by CUDA C++, where the programmer thinks in threads and blocks. `cutile-rs` works at a higher level, where the programmer describes operations over tiles of data and the compiler decides how those tiles map onto the GPU.

Both end up inside the CUDA ecosystem. They simply give Rust developers two different levels of control.

cuda-oxide brings Rust into the SIMT model

The lower-level track is `cuda-oxide`, a custom Rust compiler backend from NVIDIA’s NVLabs.

A function marked as a GPU kernel moves through Rust MIR, NVIDIA’s Rust-based Pliron IR framework, LLVM IR, and finally into PTX. The rest of the program can continue through the standard Rust backend.

That gives developers a programming model that feels close to CUDA C++: define what one thread does, choose the launch geometry, and let thousands of threads execute the same kernel across the data.

NVIDIA’s example is a vector-add kernel over 1,024 floating-point values. The device code is written in Rust, compiled to PTX, launched through a Rust host API, and checked against the expected output.

The interesting part is that the function signature is doing real safety work before the kernel ever reaches the GPU.

Rust’s ownership model reaches into kernel safety

GPU code has always had to care about aliasing, indexing, and which thread is allowed to write to which part of memory.

CUDA Rust turns some of those rules into types.

In the `cuda-oxide` example, shared input slices are ordinary Rust references. The writable output uses `DisjointSlice`, a type that gives each thread exclusive access to its own element instead of pretending every thread owns the same mutable slice.

Thread indexing is typed as well. The kernel receives an index value designed for the launch domain, and an out-of-bounds access comes back as an `Option` that the program has to handle.

Launch geometry also becomes part of the contract. A `#[launch_contract]` declaration describes how the kernel is expected to be launched, and the generated host-side API checks the requested launch configuration before exposing the safe path.

That is a very Rust-like way to approach GPU programming: move assumptions out of comments and into things the compiler and runtime can validate.

cutile-rs takes the tile route instead

The second track, `cutile-rs`, starts from a different abstraction.

Instead of writing what one GPU thread should do, the kernel operates on a tile — a chunk of a tensor. CUDA Tile IR then decides how that work maps onto the actual GPU threads and memory layout.

The Rust code stays compact because the programmer does not manually manage thread indexing for the tile.

NVIDIA’s example performs the same elementwise addition as the SIMT version, but the inputs and outputs are expressed as tensors. The output is partitioned into non-overlapping writable chunks, and each tile receives one exclusive region.

The compiler owns the mapping from that logical tile to the hardware.

NVIDIA recommends reaching for the Tile path first when that abstraction fits the workload, then dropping to SIMT when an application needs direct control over threads, memory, or architecture-specific behavior.

Stable Rust can now reach CUDA Tile IR

One of the cleanest parts of the Tile path is the toolchain.

`cutile-rs` works with stable Rust 1.89 or newer and JIT-compiles kernels through CUDA Tile IR when they are first needed. The kernel’s abstract syntax tree is embedded in the host binary, then compiled for the GPU at runtime.

For developers already living in Cargo and crates.io, that gives CUDA programming a much more familiar entry point.

The library is published as a Rust crate, and NVIDIA’s examples can be built with standard Cargo commands. The current toolchain targets NVIDIA GPUs with compute capability 8.0 or later and uses modern CUDA Tile IR support.

That means a Rust project can keep its host code, kernel code, package management, and ownership model inside one language ecosystem while still producing code for NVIDIA GPUs.

The Tile and SIMT paths can work in the same pipeline

The two tracks are not meant to live in separate worlds.

NVIDIA has already published an interoperability example where a `cutile-rs` Tile kernel performs a row-wise softmax and a `cuda-oxide` SIMT kernel applies a custom threshold-and-scale step afterward.

Both kernels run in one host process, on the same CUDA stream, over shared device allocations.

The Tile stage handles the tensor-shaped operation. The SIMT stage handles a thread-oriented post-processing step where direct control is useful.

That is a strong example of why NVIDIA is treating the programming model and the programming language as separate choices. A Rust application can use the high-level Tile model where the compiler can take over more of the mapping, then use SIMT where the kernel needs a lower-level shape.

The result is one Rust GPU pipeline rather than a forced choice between two isolated toolchains.

NVIDIA is building CUDA Rust into the wider CUDA ecosystem

NVIDIA says this is part of a longer CUDA Rust push extending into 2027 and beyond.

The company also plans interoperability across CUDA Rust, CUDA C++, and CUDA Python so choosing Rust at one layer does not isolate a project from the rest of the CUDA stack.

That direction fits what is already happening elsewhere in NVIDIA’s software.

The Nova Linux driver is written in Rust. NVIDIA Dynamo uses a Rust core. NVTX has Rust bindings. Rust has become increasingly common in the infrastructure around AI systems because it combines systems-level control with compile-time memory guarantees.

CUDA Rust brings that same language closer to the place where the parallel compute actually runs.

For developers building inference engines, runtimes, compilers, or performance-sensitive AI infrastructure, that closes a meaningful gap in the stack.

The Upgrade Feeling

The headline is not that Rust can call CUDA. Rust could already sit on the host side of GPU applications.

The change is that Rust can now own the kernel too.

`cuda-oxide` gives developers a native SIMT path to PTX. `cutile-rs` gives them a stable-Rust path into CUDA Tile IR. Ownership and type design are being used to make launch geometry, writable memory, and tensor partitioning more explicit before the program reaches the GPU.

That is a much bigger shift than another language binding.

NVIDIA is trying to make Rust a first-class way to express GPU work — from the system around the model all the way down to the kernel that runs on the accelerator.