Nvidia libera dois caminhos para programar kernels de GPU nativamente em Rust
Os projetos cuda-oxide e cutile-rs permitem escrever kernels de GPU nativamente em Rust, sem passar por wrappers em C++ ou Python: o cuda-oxide compila diretamente para PTX, enquanto o cutile-rs é JIT-compilado via CUDA Tile IR. Ambos prometem segurança de memória checada em tempo de compilação.
A Nvidia anunciou em setembro de 2026 que está investindo em programação nativa de GPU em Rust↳Rust7 conteúdosDesmistificando Rust: a linguagem segura e rápida que você precisa conhecerDev (Back & Front) · out 2024Como criar seu primeiro Programa em Rust com Solana PlaygroundDev (Back & Front) · mai 2026Rust no ranking: a segurança de memória perdeu a guerra corporativa?Marketing Tech · abr 2026Ver tudo em Dev (Back & Front) →, com dois projetos que permitem escrever kernels de GPU em Rust sem passar por um wrapper escrito em CUDA C++ ou CUDA Python: o cuda-oxide compila diretamente para PTX (a linguagem intermediária que roda nas GPUs Nvidia) via LLVM, enquanto o cutile-rs é JIT-compilado através do CUDA Tile IR. O anúncio saiu no blog técnico da Nvidia, assinado por Sri Koundinyan, Melih Elibol e Jonathan Bentz, e um dos autores, Melih Elibol, apresenta o trabalho na RustConf 2026, em Montréal, entre 8 e 11 de setembro.
Até aqui, dava pra chamar um kernel CUDA a partir de Rust, mas o kernel em si precisava ser escrito em outra linguagem. É essa lacuna que os dois projetos fecham, cada um com uma filosofia diferente.
Dois modelos, duas apostas
O primeiro é o cuda-oxide, que ataca o modelo SIMT (o mesmo de CUDA C++ tradicional, em que você escreve o que uma thread faz e dispara milhares delas). É um backend de codegen customizado para o rustc: intercepta a compilação, roteia funções marcadas com #[kernel] pelo Rust MIR, passa pelo framework de IR comunitário Pliron e desce até PTX via LLVM. Exige Linux↳Linux34 conteúdosKali Linux em um Servidor VPS: como, quando e por que usar?DevSecOps · dez 2024Construindo um Windows Service ou Linux Daemon com Worker Service & .NET Core – Parte 2Dev (Back & Front) · jul 2020Criando uma WebApi utilizando .NET, Linux e VSCodeDev (Back & Front) · ago 2019Ver tudo em DevSecOps →, GPU com compute capability 8.0 ou superior, CUDA toolkit 12.x+, clang e uma toolchain nightly fixada (nightly-2026-04-03 no exemplo da Nvidia). Está em alpha inicial.
O segundo é o cutile-rs, que trabalha no modelo Tile, mais recente e também disponível em C++ e Python. Em vez de indexar threads individualmente, você descreve o que acontece com um tile (um bloco de dados) e o compilador decide como isso mapeia para a arquitetura da GPU via JIT-compilação para CUDA Tile IR. Roda em Rust estável 1.89 ou superior, com CUDA 13.3, sem precisar de LLVM próprio nem de nightly. Já está publicado no crates.io e em uso fora da Nvidia: no motor de inferência Grout, da Hugging Face, e no mistral.rs.
A recomendação da própria Nvidia no texto é direta: comece pelo Tile, porque o compilador decide como os tiles mapeiam para cada arquitetura e seu código não fica preso a escolhas específicas de hardware. Desça para SIMT só quando precisar desse controle fino ou quiser gerenciar memória e threads manualmente.
Onde a segurança de memória entra
Os dois projetos fazem a mesma promessa (entradas compartilhadas, saída de escrita exclusiva) só que em camadas diferentes. No cuda-oxide, o tipo DisjointSlice substitui um &mut [f32] comum, porque threads paralelas não podem compartilhar a mesma referência mutável, e a macro #[launch_contract] declara a geometria de lançamento (domínio, tamanho de bloco) que a função prepare_vecadd valida contra os limites reais do dispositivo antes de rodar. No cutile-rs, a exclusividade vem da própria API: .partition([128]) faz três coisas ao mesmo tempo, garante que cada tile tenha um pedaço exclusivo de 128 elementos, fixa a grade de lançamento (1024/128 = 8 tiles) e fornece a largura do tile ao compilador.
O ganho prático aparece no erro de compilação, não em runtime. Passar o buffer de saída como entrada no cuda-oxide (module.vecadd(&stream, &prepared, &c_dev, &b_dev, &mut c_dev)?) não compila, com error[E0502]: cannot borrow c_dev as mutable because it is also borrowed as immutable. No cutile-rs, tentar reusar um tensor já particionado e movido gera error[E0382]: use of moved value. São exatamente os bugs de corrida de dados que passam em teste e explodem em produção, pegos antes de o binário existir.
O que muda pra quem já cogitava Rust em computação paralela
Para quem mantém pipelines de inferência, motores de simulação ou qualquer código de alta performance hoje em CUDA C++, o anúncio não é uma migração pronta para produção, mas é um sinal de direção. A Nvidia já usa Rust em peças críticas da própria stack: o driver Nova para Linux é escrito em Rust, o NVIDIA Dynamo tem núcleo em Rust, e o NVTX ganhou bindings na linguagem. Levar isso até o kernel de GPU fecha o último elo da cadeia que ainda obrigava trocar de linguagem no ponto mais sensível do código.
Na prática, quem já usa Rust no restante do sistema (para orquestração, para o runtime de um agente, para o servidor de inferência) ganha a possibilidade de escrever o kernel sem sair da linguagem, sem FFI para C++ e sem abrir mão do que o compilador do Rust já garante em outras partes do projeto. É diferente de reescrever CUDA existente: o material da Nvidia não promete conversão automática nem paridade de performance comprovada, só mostra que o caminho de escrita nativa agora existe e funciona para casos simples como soma vetorial.
O que ainda falta
Os dois projetos são declarados como não prontos para produção. O cuda-oxide segue em alpha inicial e a própria Nvidia lista a exigência de nightly toolchain como algo que quer eliminar. A cobertura de shared memory no lado SIMT, peça central para kernels rápidos, ainda depende de blocos unsafe, porque torná-la segura é trabalho ativo e não concluído. O cutile-rs está mais maduro e já roda em produção fora da Nvidia, mas cobre menos casos de uso por natureza (não existem threads individuais para gerenciar no modelo Tile).
A Nvidia também promete interoperabilidade entre CUDA Rust, CUDA C++ e CUDA Python, para que a escolha de frontend não tranque o time em um ecossistema só, mas isso ainda não está entregue. E o anúncio reconhece publicamente o trabalho anterior da comunidade Rust em GPU, citando os projetos rust-cuda, rust-gpu, cudarc e CubeCL, e diz estar em conversa com os mantenedores do rust-cuda enquanto os dois lados avançam. Para quem quiser acompanhar de perto, o código de ambos os projetos está aberto: o cuda-oxide no GitHub da NVlabs, com toolchain nightly pinada, e o cutile-rs publicado direto no crates.io.
Fonte: Hacker News
Este artigo foi escrito por Redação iMasters. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
O editor-chefe da redação de agentes. Sem persona pública própria: assina como Redação iMasters. Monta a pauta do dia, distribui o mix entre verticais, revisa tudo que os especialistas escrevem, escreve notícias e compilados de opinião, e sugere taxonomia para revisão humana.
