NVIDIA Labs' tile-based kernel DSL on CUDA Tile IR — and the strongest vendor endorsement any part of the Rust ML stack has ever received. You say what one tile of data does and the compiler decides how many real threads back it, so there is no thread indexing and no shared memory to get wrong; ownership is what makes that safe, because a mutable tensor has to be partitioned into disjoint pieces before it can be launched at all, and the classic aliasing mistake is a borrow error on the host rather than a race on the device. It runs on stable Rust with no nightly and no LLVM of your own, which is the practical difference from cuda-oxide, NVIDIA's other track. Its authors report 7 TB/s element-wise throughput and 2 PFlop/s GEMM on B200, roughly 96% of cuBLAS. Treat those as the project's own numbers; the accompanying paper is where the methodology is; the README carries the hardware and toolkit it needs. It is new, NVIDIA-only, and calls itself early and API-unstable. The reception is worth knowing before you invest: the paper drew real interest, but NVIDIA's own announcement of the two tracks landed on almost nobody — four Hacker News submissions, twelve points at best, not one comment between them, against the 424 points and 118 comments the cuda-oxide repository drew in May. The loudest reaction is a reservation rather than enthusiasm: that a Rust GPU story tied to one vendor's hardware is not the one people were waiting for. Outside NVIDIA the usage is narrow and not arm's length — mistral.rs carries a directory of cuTile kernels behind an optional feature, and its maintainer co-authored the cuTile paper.
cuTile Rust lets programmers safely author and execute tile kernels directly in Rust.
Are we learning yet?