CUDA Rust Takes Two Experimental Paths Toward Safer GPU Kernels

Two approaches to moving Rust onto the GPU

NVIDIA introduced two experimental paths for writing native GPU kernels in Rust on September 8, 2026. The projects address the same broad problem from different levels of abstraction. cuda-oxide retains CUDA’s familiar single-instruction, multiple-thread model and gives programmers direct responsibility for individual threads. cutile-rs instead presents computation as operations over multidimensional tiles, leaving more decisions about thread assignment and memory layout to the compiler.

That difference is more important than the shared programming language. Rust can prevent certain memory errors when ownership and borrowing rules accurately describe the resources used by a computation. GPU software complicates that model because thousands of threads may operate concurrently, memory is divided into several address spaces, and kernel launches continue after the host initiates them. A safe interface has to represent not only which code may access a buffer, but also how that buffer is partitioned and how long the device may retain access.

Both projects attempt to place those relationships inside Rust’s type and ownership systems. They could make some invalid programs fail during compilation rather than after deployment. NVIDIA nevertheless identifies cuda-oxide as an early alpha and describes cutile-rs as an active research project. Neither is presented as production-ready, and the public evidence does not yet establish their reliability across large applications or varied GPU generations.

cuda-oxide preserves thread-level control

cuda-oxide is a custom backend for the Rust compiler. Device code passes through Rust’s mid-level intermediate representation, then through NVIDIA’s Pliron infrastructure and LLVM before becoming PTX, the virtual instruction format used by CUDA. Host and device code can live in one Rust project, but kernel authors still calculate thread indices, choose launch dimensions and reason about the behavior of individual threads. This makes the project conceptually close to conventional CUDA programming.

The safety work concentrates on how memory is divided and passed into a kernel. A type called DisjointSlice can represent non-overlapping regions of a buffer, allowing the compiler to reject conflicting mutable access in examples such as vector addition. Launch contracts can describe the relationship between the grid configuration and the memory available to each thread. When a caller satisfies that contract, it can obtain a checked prepared launch instead of repeating an unchecked assertion at every call site.

Those protections have boundaries. The repository marks a raw LaunchConfig as unsafe because the compiler cannot independently prove that its dimensions and resource assumptions match the kernel. Shared-memory safety is still under development, although shared memory is central to many high-performance SIMT kernels. Unsafe Rust remains available when programmers need operations the checked interfaces cannot express. Ownership rules also do not prove that an indexing formula, numerical method or synchronization strategy is correct. A kernel can be memory-safe and still calculate the wrong result, wait incorrectly or perform poorly.

cutile-rs moves control to logical tiles

cutile-rs raises the programming unit from individual threads to tiles of data. Code inside its module macro is captured as a Rust syntax tree and stored with the host program. At runtime, the system compiles the kernel through CUDA Tile IR into a GPU binary. The compiler then maps logical tile operations onto physical threads and chooses lower-level layouts. This approach can reduce the amount of indexing and hardware-specific scheduling that application developers write themselves.

Its ownership design partitions mutable tensors into disjoint regions before a launch while allowing immutable tensors to be shared. Generated launchers keep those ownership constraints active while work remains in flight on the GPU. The intended benefit is to exclude overlapping mutable access and related data races from the safe interface. Local escape hatches remain available for lower-level control, so the strength of the guarantee depends on whether an application stays within the checked abstractions.

The tile model trades some explicit control for a larger compiler role. That can improve portability and shorten kernel code when the available operations match the workload. It also makes compiler quality and supported operations critical. cutile-rs requires stable Rust rather than cuda-oxide’s pinned nightly toolchain, but its documented environment still centers on Linux, recent CUDA software and supported NVIDIA architectures. Its APIs are incomplete and expected to change, which creates migration and maintenance risk for teams adopting it before stabilization.

Performance results are promising but developer-reported

A June 2026 preprint associated with cutile-rs reports results on modern NVIDIA hardware. The authors measured about 7 terabytes per second for an element-wise workload and about 2 petaflops per second for matrix multiplication on a B200 GPU. The paper characterizes the matrix result as 96 percent of cuBLAS performance. Repository documentation also reports a persistent matrix-multiplication kernel at 2.07 petaflops for a specific 8,192-by-8,192 configuration, within 0.3 percent of a corresponding lower-level Tile IR implementation.

The same research reports cutile-rs kernels used through the Grout project for language-model inference. Reported batch-one decoding rates include 171 generated tokens per second for Qwen3-4B on an RTX 5090 and 82 tokens per second for Qwen3-32B on a B200. These measurements show that the abstraction can support substantial kernels rather than only teaching examples. They do not establish general performance across models, batch sizes, precisions, GPUs or production serving systems.

The paper is a preprint written by project contributors, and NVIDIA supplied the accompanying maturity and safety claims. No independent benchmark suite or production reliability assessment accompanied the September announcement. Comparisons also depend on compiler versions, kernel shapes, memory behavior and selected baselines. The results should therefore be read as evidence that the design can be competitive under tested conditions, not as proof that Rust kernels will automatically match optimized CUDA libraries.

Production adoption requires more than a safer syntax

For developers, the practical choice is not simply between Rust and CUDA C++. cuda-oxide suits work that needs explicit SIMT control and can tolerate an experimental compiler backend, a pinned nightly Rust toolchain and incomplete safe support for GPU resources. cutile-rs suits algorithms that map naturally onto tile operations and can accept compiler-managed execution. A team could also continue using mature CUDA libraries while testing Rust only in isolated kernels with strong validation coverage.

Evaluation should include incorrect as well as successful programs. Teams need tests showing that aliasing errors are rejected, unsafe boundaries are reviewed, asynchronous lifetimes remain valid and results agree with trusted implementations. Performance work should cover representative shapes, concurrency levels and hardware, not just peak cases. Compiler crashes, diagnostic quality, binary compatibility and the ability to inspect generated PTX or machine code also matter when a tool becomes part of a production build.

NVIDIA says interoperability among CUDA Rust, CUDA C++ and CUDA Python is a goal, but that is a development direction rather than a completed compatibility guarantee. Licensing has similar boundaries. The cuda-oxide and cutile-rs repositories use Apache License 2.0, which permits commercial use subject to its conditions. That repository license does not automatically govern CUDA components, Rust dependencies, drivers or applications assembled with the projects. Each dependency and distributed component retains its own terms.

The immediate achievement is narrower but still useful. NVIDIA has presented two concrete experiments for applying Rust’s ownership model to GPU programming without insisting on a single programming abstraction. cuda-oxide explores safer thread-level CUDA, while cutile-rs explores compiler-managed tiles. Their progress will be demonstrated by broader kernel coverage, stable interfaces, independent evaluation and sustained use, not by the language label alone.