Two days after NVIDIA announced CUDA Rust, its launch tutorial and the live cuda-oxide repository already describe different toolchains. The announcement tells developers to use CUDA 12.x or newer and pins Rust nightly 2026-04-03. The repository now calls for CUDA 13.x, an R580 or newer driver, and nightly 2026-08-28. That mismatch is a useful status signal: the code is public and runnable, while the setup contract is still moving.
NVIDIA has released two Apache-2.0 projects for writing GPU kernels in Rust. cuda-oxide keeps CUDA's familiar thread-level SIMT model and compiles Rust to PTX through a custom rustc backend. cutile-rs presents a tile-level model and JIT-compiles a captured Rust syntax tree through CUDA Tile IR. NVIDIA says neither project is ready for production, yet both close a boundary that has long forced Rust applications to leave the language for their hottest code: the GPU kernel itself. NVIDIA's launch post calls that boundary the remaining exception in a systems stack where its Nova driver and Dynamo already use Rust.
One language, two programming models
The split is about how developers describe parallel work. In cuda-oxide, a kernel says what one GPU thread should do. The programmer still chooses the grid, block size, indexing scheme, and memory strategy. NVIDIA recommends this SIMT path when a team needs that control or is translating CUDA C++ patterns. The cuda-oxide README describes a single-source build: host and device code can live in one file, and cargo oxide build sends functions marked #[kernel] through Rust MIR, Pliron IR, LLVM IR, and finally PTX.
cutile-rs moves the mapping work into the compiler. A kernel operates on sub-tensors, while CUDA Tile IR decides how those tiles map to hardware threads and memory. The macro below captures the kernel's Rust syntax tree in the host binary; the first use compiles it to a GPU cubin. The cutile-rs repository shows the small surface area:
#[cutile::entry()]
fn add<const B: i32>(
z: &mut Tensor<f32, { [B] }>,
x: &Tensor<f32, { [-1] }>,
y: &Tensor<f32, { [-1] }>,
) {
z.store(x.load_like(z) + y.load_like(z));
}
NVIDIA advises developers to start with Tile because the compiler can adapt the mapping across GPU architectures. SIMT remains the escape hatch for explicit thread and shared-memory control. Language and execution model are separate choices: CUDA C++, CUDA Python, and now CUDA Rust can each expose either style, and NVIDIA says it plans interoperability among those front ends. That promise is directional rather than a compatibility guarantee; the announcement gives no delivery dates or stable interface.
Rust's ownership rules cross the launch boundary
A Rust kernel is only useful if its safety model survives contact with thousands of concurrent GPU threads. cuda-oxide handles mutable output with DisjointSlice, which gives each thread access to its own element instead of sharing one &mut slice across the grid. Its typed thread index can be passed to get_mut, which returns an Option for the out-of-bounds case. A #[launch_contract] can also bind a kernel to a dimensionality and block shape; the generated safe launcher requires a configuration that passes those checks. NVIDIA explains those mechanics in its worked vector-add example.
Tile makes the ownership rule part of the tensor layout. Before launch, the host partitions a mutable tensor into non-overlapping pieces. Each tile receives one piece, and the generated launcher takes ownership of the tensors while work is in flight. Trying to pass the same tensor as both a shared input and mutable output fails at compile time. The project documentation also supports asynchronous pipelines and CUDA graph replay under the same ownership model.
Those checks target aliasing and launch-shape mistakes. They do not make every GPU operation safe. NVIDIA says shared memory on cuda-oxide's SIMT path currently requires unsafe, and kernels without a launch contract expose only raw unsafe launch methods. Tile removes direct thread indexing and shared-memory management from user code, which avoids those particular errors while giving the compiler more control. The launch article says safer shared memory for SIMT is still being developed.
The performance numbers come from the project team
The accompanying Fearless Concurrency on the GPU paper reports that cuTile Rust reached 7 TB/s on element-wise operations and 2 PFlop/s on matrix multiplication on an NVIDIA B200. The authors describe the matrix result as 96 percent of cuBLAS. They also report that the safe Rust implementation stayed within measurement noise of cuTile Python. These are author-run results on high-end NVIDIA hardware, so they establish that the safety abstractions need not impose an obvious penalty in those tests. They are not a substitute for results across more kernels, GPUs, and application shapes.
The paper includes an application test through Grout, a Qwen3 inference engine built with cuTile Rust. It reports 171 generated tokens per second for batch-one Qwen3-4B decoding on an RTX 5090 and 82 tokens per second for Qwen3-32B on a B200. The authors compare those results with vLLM and SGLang and check them against an HBM bandwidth model. The cutile-rs README points to Grout as a reference for real kernel call sites, and NVIDIA says mistral.rs is also using the project. That outside use is more informative than a vector-add demo, though neither example turns an early research release into a settled production dependency.
Setup separates an experiment from a dependency
cuda-oxide currently asks for Linux, a pinned Rust nightly with compiler development components, CUDA 13.x, Clang and libclang, and a recent NVIDIA driver. Its first run fetches and builds the codegen backend. The repository offers a Nix development shell with pinned CUDA and LLVM versions, which may be the least fragile way to reproduce the environment. The exact nightly date has already changed since NVIDIA published the launch tutorial, so developers should follow the repository requirements rather than copy the announcement's install command blindly.
cutile-rs has the shorter path. It uses stable Rust 1.89 or newer and recommends CUDA 13.3 on Linux. Hardware support starts at sm_80; the maintainers explicitly put older sm_70 and sm_75 GPUs out of scope. A project can add the published cutile crate with Cargo, while compilation to CUDA Tile IR happens when a kernel is first needed. The current setup guide says Ubuntu 24.04 is the tested Linux distribution.
Rust itself already has an nvptx64-nvidia-cuda target. The rustc target guide rates it Tier 2 and documents a no_std, nightly-based route to PTX. cuda-oxide builds a larger CUDA-oriented system around that general problem, including generated host APIs, launch contracts, memory management, testing, memcheck, and cuda-gdb commands. cutile-rs goes further from ordinary Rust compilation by using a domain-specific tile model. CUDA Rust is therefore a coordinated set of tools and policies, rather than a new stable Rust target that makes existing crates run on a GPU unchanged.
Why the split may be useful
One compiler would have been simpler to explain, but the two projects expose a real engineering tradeoff. A low-level kernel author needs access to threads, blocks, and shared memory. An inference developer may prefer to express tensor tiles and let the compiler choose a mapping for each architecture. NVIDIA's side-by-side example produces the same 1,024-element vector addition through both paths, making the difference visible in code rather than hiding it behind a single CUDA Rust label.
The release also gives Rust teams a first-party route that acknowledges existing work. NVIDIA names rust-cuda, rust-gpu, and cudarc as predecessors and says it has worked with rust-cuda maintainers. Both new repositories accept issues and contributions under Apache 2.0. For teams already writing inference engines or GPU services in Rust, the practical gain is a chance to keep more ownership information across the CPU-GPU boundary. The present cost is dependence on young APIs and NVIDIA-specific compiler infrastructure, as both project status pages warn.
The next evidence should come from versioned releases, stable setup instructions, and tests outside NVIDIA's chosen kernels. Watch whether cuda-oxide can shed its pinned nightly requirement, whether its shared-memory path becomes safe by default, and whether the promised cross-language interoperability appears in code. cutile-rs has the earlier route to application use, but its sm_80 floor and CUDA 13.3 recommendation narrow the machines that can try it today. Until those constraints ease, NVIDIA's own description is the right one: both projects are experiments that developers can run now, not production dependencies.