A NVIDIA anunciou programação nativa de GPU em Rust com duas trilhas distintas de escrita de kernels, cuda-oxide e cutile-rs, fechando uma lacuna onde kernels de GPU precisavam ser escritos em C++ ou Python mesmo quando o resto da pilha era Rust. O movimento expande o ecossistema de linguagens do CUDA conforme mais da camada de sistemas—mecanismos de inferência, infraestrutura de serving, drivers e runtimes de agentes—migra para Rust por suas garantias de segurança em tempo de compilação.
A trilha cuda-oxide segue o modelo SIMT (Single Instruction Multiple Threads) já familiar do CUDA C++ e numba-cuda. É um backend de codegen rustc customizado que intercepta a compilação, roteia funções de kernel através de Rust MIR, do framework Pliron IR, e LLVM até PTX. Um kernel escrito em cuda-oxide usa tipos como DisjointSlice para impor acesso exclusivo em tempo de compilação: cada thread recebe seu próprio elemento de slice mutável, e o compilador rejeita qualquer tentativa de passar o mesmo buffer como entrada e saída. A macro #[launch_contract] declara a forma de indexação do kernel e o tamanho do bloco de thread, e o método prepare valida a configuração de launch contra tanto esse contrato quanto os limites de dispositivo ao vivo antes da execução.
A trilha cutile-rs opera em um nível mais alto, usando o modelo de programação Tile onde o corpo do kernel executa uma vez por tile de dados como uma única thread lógica, e o compilador decide quantas threads GPU reais respaldam cada tile. A macro #[cutile::module] incorpora a AST do kernel no binário do host e JIT-compila através de CUDA Tile IR quando necessário pela primeira vez. Particionamento no host—chamando .partition([128]) em um tensor de 1.024 elementos—faz três trabalhos de uma vez: dá a cada tile propriedade exclusiva de seu chunk de 128 elementos, fixa a grade em 8 tiles, e fornece a largura do tile como uma constante em tempo de compilação sem recompilação.
As duas trilhas diferem em maturidade e requisitos. cuda-oxide é alfa inicial e requer um toolchain nightly fixado (nightly-2026-04-03), CUDA 12.x ou mais novo, clang com headers libclang, e uma GPU com capacidade de computação 8.0 ou posterior. cutile-rs está mais avançado: é publicado em crates.io, executa em Rust estável 1.89 ou mais novo com CUDA 13.3, não requer LLVM customizado, e já é usado no mecanismo de inferência Grout da HuggingFace e em mistral.rs. Ambos impõem segurança de memória em tempo de compilação—cuda-oxide através de DisjointSlice e contratos de launch, cutile-rs através de particionamento de tensor e propriedade—e ambos rejeitam erros de aliasing que causariam corridas em produção.
As garantias de segurança vêm com custos diferentes. Kernels SIMT mantêm indexação de thread e controle de memória compartilhada, mas memória compartilhada atualmente requer código unsafe. Kernels Tile eliminam corridas de thread por construção porque o compilador possui mapeamento de thread e layout de memória, mas isso significa sem memória compartilhada e sem controle por thread. A NVIDIA planeja suportar interoperabilidade entre linguagens entre CUDA Rust, CUDA C++, e CUDA Python para que a escolha de frontend não prenda desenvolvedores a um ecossistema.
Ambos os projetos estão em estágio inicial. cuda-oxide ainda requer um toolchain nightly fixado, o que a NVIDIA reconhece ser exatamente o tipo de atrito que quer remover. A cobertura é incompleta e as APIs mudarão. O ecossistema inclui trabalho anterior de rust-cuda, rust-gpu, e CubeCL, e a NVIDIA tem trabalhado com os mantenedores de rust-cuda conforme ambos os projetos amadurecem.
Para equipes avaliando escolhas de linguagem para kernels CUDA customizados, a decisão depende de se você precisa de controle em nível de thread e memória compartilhada—opte por cuda-oxide em SIMT—ou se você pode aceitar o compilador possuindo esses detalhes em troca de segurança de memória por construção e Rust estável—opte por cutile-rs em Tile.