NVIDIA lance CUDA Rust pour programmer les GPU nativement en Rust
En bref
- NVIDIA annonce deux approches pour écrire des kernels GPU en Rust : cuda-oxide (modèle SIMT) via un backend rustc personnalisé, et cutile-rs (modèle Tile) compilé JIT en Rust stable.
- cuda-oxide requiert un nightly toolchain et LLVM personnalisé ; cutile-rs fonctionne sur stable (1.89+) et est déjà utilisé par HuggingFace et mistral.rs.
- Les deux enforcement la sécurité mémoire à la compilation via des mécanismes de contrôle d'aliasing et de partitionnement.
- NVIDIA prévoit l'interopérabilité avec CUDA C++ et CUDA Python pour éviter le verrouillage à une seule approche.
Ce que dit la source
NVIDIA estime que la majorité des systèmes d'inférence et runtime GPU AI sont désormais écrits en Rust, y compris les driver (Nova Linux) et les frameworks critiques (NVIDIA Dynamo). Cependant, les kernels GPU restaient l'exception : il fallait les écrire en C++, CUDA C++ ou Python. CUDA Rust ferme cette brèche en permettant de compiler des kernels directement en PTX natif depuis Rust, sans wrapper ou autre langage intermédiaire. L'annonce couvre deux modèles : SIMT (celui-ci en C++ depuis des années) et Tile (modèle plus récent aussi disponible en C++ et Python), reflétant les deux approches fondamentales de programmation GPU chez NVIDIA.
- cuda-oxide utilise un backend codegen rustc personnalisé qui intercepte la compilation : les fonctions marquées #[kernel] passent par Rust MIR, le framework Pliron IR (communauté), puis LLVM IR jusqu'à PTX ; le reste suit le chemin standard
- Requiert Linux, GPU compute capability 8.0+, CUDA 12.x+, clang avec libclang, et un nightly toolchain pinné (2026-04-03 dans l'exemple)
- cutile-rs fonctionne sur Rust stable 1.89+ sans custom LLVM, compilé via CUDA Tile IR JIT, déjà intégré dans les inference engines HuggingFace (Grout) et mistral.rs
- cuda-oxide en est au stade early alpha ; cutile-rs est publié sur crates.io avec exemples fonctionnels
- Sécurité mémoire : cuda-oxide utilise DisjointSlice et launch contracts pour prévenir les aliasing sur le device ; cutile-rs s'appuie sur la propriété Rust et le partitionnement tensoriel
- NVIDIA planifie l'interopérabilité inter-langage (Rust ↔ C++ ↔ Python) pour que le choix du frontend n'enferme pas le développeur
Dans les commentaires
Débat partagé, avec deux préoccupations dominantes : la saturation de CUDA dans les codebases C++ (risque de verrouillage), et la stabilité/maturité de ces outils (nightly required, alpha status). Quelques commentateurs sceptiques sur le besoin réel en Rust face à des alternatives comme Triton.
- Plusieurs commentateurs rejettent le modèle CUDA propriétaire global, arguant qu'une abstraction complète (OpenCL, Metal, D3D12) ou une DSL neutre (Triton) éviterait le verrouillage fournisseur
- Préoccupation sur la stabilité : cuda-oxide exige un nightly toolchain et reste en alpha ; cutile-rs ajoute une couche de diagnostic (distinguish issues entre cuda-oxide, Rust, CUDA, Tile) sans résoudre les bugs CUDA lui-même
- Critique du ton rédactionnel : plusieurs commentateurs notent que l'annonce ressemble à un texte généré IA ('Claude') plutôt que la voix caractéristique des blogs NVIDIA
- Un commentateur questionne la cohérence des exemples (variables a, b, c vs z, x, y) dès la v0
- Question non résolue sur la portabilité : Rust code écrit pour CUDA Rust peut-il être réutilisé sur AMD/Intel GPUs ?
Alternatives citées : Triton (DSL pour kernels GPU, mentionné comme alternative à CUDA Rust dans les commentaires) ; OpenCL, Metal, D3D12 (abstraction multiplateformes) ; Candle crate HuggingFace (inference en Rust, sans kernels custom dans la plupart des cas)
Notre lecture
NVIDIA répond à une réalité : les systèmes critiques AI/infra basculent en Rust pour la sécurité mémoire, et les kernels GPU étaient le maillon faible. cutile-rs est prêt pour la production (stable, crates.io, usages réels HuggingFace) ; cuda-oxide intéressant techniquement mais encore trop instable pour autre chose que l'expérimentation. L'interopérabilité C++/Python/Rust est la bonne réponse au verrouillage. Attention : le gain réel dépend de la maturité de ces outils en 2027. À surveiller pour les équipes infra AI en Rust, mais pas d'action immédiate si vous n'écrivez pas de kernels GPU custom. Le scepticisme sur CUDA propriétaire reste valide : cutile-rs améliore l'ergonomie, pas la portabilité inter-architecte.