NVIDIA ouvre deux voies pour CUDA en Rust

Ce qui se passe

Lancer un kernel depuis Rust était déjà possible ; écrire le kernel lui-même imposait de repasser par un autre langage. CUDA Rust comble ce trou : le kernel est compilé nativement en PTX, et non enveloppé autour de code venu d'ailleurs.

NVIDIA annonce en septembre 2026 s'engager sur la programmation GPU native en Rust et faire mûrir ces outils « jusqu'en 2027 et au-delà », en gardant CUDA C++ et CUDA Python comme chaînes matures. La motivation est celle de la couche systèmes de l'IA — moteurs d'inférence, infrastructures de service, pilotes, runtimes d'agents — de plus en plus écrite en Rust : le pilote Linux Nova l'est, NVIDIA Dynamo repose sur un cœur Rust.

Deux pistes, parce que CUDA en a deux

SIMT — cuda-oxide. Le modèle habituel : vous décrivez ce que fait un thread, vous en lancez des milliers. Techniquement, c'est un backend de génération de code pour rustc, qui intercepte la compilation, route les fonctions marquées #[kernel] par MIR, le framework d'IR communautaire Pliron puis LLVM IR jusqu'au PTX, et laisse le reste au backend standard.

Tile — cutile-rs. Un cran au-dessus : vous décrivez ce qui arrive à une tuile de données, et le compilateur Tile IR décide comment elle se répartit sur chaque architecture. Le conseil de NVIDIA est explicite : commencer par Tile, et descendre en SIMT quand on a besoin de ce contrôle ou de gérer soi-même mémoire et threads.

# Tile : Rust stable, rien à cloner
cargo new vecadd_demo && cd vecadd_demo
cargo add cutile

# SIMT : nightly épinglée, puis un gabarit complet
cargo +nightly-2026-04-03 install --git https://github.com/NVlabs/cuda-oxide.git cargo-oxide
cargo oxide new vecadd_demo && cd vecadd_demo
cargo oxide doctor && cargo oxide run

Ce que le compilateur refuse

C'est l'argument central, et il ne tient pas à la syntaxe. Des milliers de threads atteignent les mêmes tampons sans ordre garanti ; quand deux d'entre eux visent la même adresse et que l'un écrit, l'ordre décide du résultat. Ces bugs ne se reproduisent pas à la demande et passent les tests avant de casser en production.

Passer le tampon de sortie d'un kernel comme l'une de ses entrées échoue à la compilation, des deux côtés :

• côté cuda-oxide : error[E0502]: cannot borrow `c_dev` as mutable because it is also borrowed as immutable ;
• côté cutile-rs : error[E0382]: use of moved value: `z` .

La ligne est tracée à des endroits différents : cuda-oxide vérifie chaque appel de lancement, tandis que la possession des tenseurs de cutile-rs traverse la frontière du lancement — la revendication la plus forte des deux.

Le reste de l'appareillage va dans le même sens : DisjointSlice<f32> donne à chaque thread un accès exclusif à son seul élément, thread::index_1d() renvoie un type d'index et non un entier nu, et #[launch_contract] est validé contre la configuration de lancement et les limites réelles du GPU avant qu'une méthode sûre n'accepte de partir.

Où en sont les projets

Aucun n'est prêt pour la production, et NVIDIA le dit.

Tile ne laisse ni mémoire partagée ni indexation de threads à mal utiliser, puisque le compilateur possède les deux : un bloc de tuiles est un unique thread logique. C'est ce qui le rend sûr par construction, et c'est aussi ce qu'on abandonne.

cutile-rs est déjà utilisé hors de NVIDIA : le moteur d'inférence Grout de Hugging Face et mistral.rs s'en servent.

À retenir

Pour essayer aujourd'hui, la piste Tile demande trois commandes et pas de nightly. Le papier Fearless Concurrency on the GPU (arXiv 2606.15991) documente l'approche, et Melih Elibol le présente à RustConf 2026, du 8 au 11 septembre à Montréal. NVIDIA prévoit l'interopérabilité entre langages, pour que le choix de Rust n'enferme pas.

Source : Introducing CUDA Rust: Two Tracks for Writing GPU Kernels