NVIDIA 发布 CUDA Rust:通过 SIMT 和 Tile 轨道在 Rust 中实现原生 GPU 内核
TL;DR – NVIDIA 的 CUDA Rust 允许你直接使用 Rust 编写 GPU 内核,提供了两种不同的编程模型(通过 cuda‑oxide 实现的 SIMT 和通过 cutile‑rs 实现的 Tile),它们可以编译为 PTX 并提供编译时安全保证。
为什么原生 Rust GPU 内核很重要
- Rust 的所有权和类型系统可以在编译时捕获整类内存安全错误,这是 CUDA C++ 内核传统上所缺失的特性。
- NVIDIA 的驱动程序栈已经在向 Rust 迁移(Nova Linux 驱动、Dynamo 内核、NVTX 绑定)。将 Rust 扩展到内核层完善了该语言的覆盖范围。
- 开发人员现在可以从 Rust 启动内核,并且直接用 Rust 编写内核代码,从而消除了对外部语言包装器的需求。
两种轨道映射了 CUDA 自身的模型
1. SIMT 轨道 – cuda‑oxide
- 模型:传统的单指令多线程 (SIMT) 编程,与 CUDA C++ 或 numba‑cuda 相同。
- 工具链:自定义的
rustc代码生成后端,将#[kernel]函数通过 Rust MIR → Pliron IR → LLVM IR → PTX 进行路由。 - 要求:Linux,计算能力 ≥ 8.0 的 GPU,CUDA 12.x+,clang,以及固定的 nightly Rust 工具链 (
cargo +nightly‑2026‑04‑03)。 - 入门:
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 # 构建并运行向量加法示例 - 安全亮点:
- 内核参数使用
DisjointSlice为每个线程提供独占的可变访问权限,避免了非法的&mut [T]模式。 #[launch_contract]声明线程块几何结构;prepare_vecadd根据契约和设备限制验证启动配置,生成安全vecadd调用所需的证明对象。- 编译时错误可防止经典的别名错误,例如,尝试将同一个缓冲区同时作为输入和可变输出传递会触发
E0502错误。
- 内核参数使用
2. Tile 轨道 – cutile‑rs
- 模型:Tile 级抽象,其中 tile 是对子张量进行操作的逻辑线程;编译器决定支持每个 tile 的物理 GPU 线程数量。
- 工具链:纯稳定版 Rust (≥ 1.89);无需 nightly,无需自定义 LLVM。需要 CUDA 13.3 和计算能力 ≥ 8.0 的 GPU。
- 入门:
cargo new vecadd_demo cd vecadd_demo cargo add cutile cargo run # 将示例粘贴到 src/main.rs 后运行 - 安全亮点:
- 张量分区 (
api::zeros(...).partition([128])) 授予每个 tile 独占的可变所有权,消除了对特殊DisjointSlice类型的需求。 - 动态维度在类型签名中用
-1表示;实际大小在启动时解析,允许在不重新编译的情况下实现灵活的形状。 - 启动器 (
kernel::add) 消耗张量,将其作为元组返回,并且仅在调用.sync_on(&stream)时执行,使整个程序成为一个原子运行的惰性描述。
- 张量分区 (
编译器自动捕获的内容
- 无别名保证 – 两种轨道都会拒绝在没有适当排他性的情况下读取和写入同一缓冲区的内核,并在编译时浮现错误,例如“无法借用为可变,因为它也被借用为不可变”(SIMT)或“使用了已移动的值”(Tile)。
- 线程索引安全 – 在 SIMT 中,
thread::index_1d()返回一个类型化的索引;越界访问会变成显式的Option分支,而不是未定义的内存读取。 - 启动时验证 –
#[launch_contract]强制要求提供的LaunchConfig与内核声明的几何结构和设备限制相匹配,将常见的运行时崩溃源转化为编译时检查。
项目成熟度和生态系统定位
- cuda‑oxide – 早期 alpha 版本;需要 nightly 工具链且仅限 Linux。提供了一条接近 CUDA 现有 PTX 流水线的底层、基于 MIR 的路径。
- cutile‑rs – 已发布在 crates.io 上,已被 HuggingFace 的 Grout 推理引擎和 mistral.rs 项目使用。被认为更稳定,但仍处于 1.0 之前,API 可能会发生变化。
- 两个项目与其他 Rust‑GPU 工作(rust‑cuda, rust‑gpu, CubeCL)共存。NVIDIA 的博客链接到一个生态系统附录,映射了这些关系。
如何立即尝试
- SIMT 示例 –
cargo oxide new vecadd_demo && cargo oxide run。 - Tile 示例 – 复制基于 Tile 的向量加法代码后,执行
cargo add cutile && cargo run。 - 文档 – cuda‑oxide book 和 cutile‑rs docs。
- 论文 – Fearless Concurrency on the GPU (arXiv 2606.15991)。
- 社区 – 在相应的 GitHub 仓库提交 issue,加入 Discord,或参加 Melih Elibol 在 RustConf 2026 上的演讲。
社区反应(精选 HN 评论)
"启动过程是经过检查的,而不是被信任的。该死,连 Nvidia 都在发布完全由 Claude 编写的文章。" – claiir
"一直期待这样的东西。CUDA C++ 很痛苦;Rust 的内核编程安全性可能会改变游戏规则。" – Driftbench
"既然 NVIDIA 现在拥有 HuggingFace,而 HuggingFace 拥有用于 Rust 推理的出色 Candle crate,这似乎是迈向优秀原生 Rust 内核的好一步。" – dllu
"我非常讨厌 CUDA……编程 GPU 的最好方法是在单独的文件中编写内核并手动启动它们,就像在 Metal、OpenCL 和 D3D12 中一样。" – jacobgorm (指出了另一种哲学选择)。
展望
NVIDIA 的 CUDA Rust 计划标志着一项战略性举措,旨在将 Rust 的安全保证引入 GPU 栈,首先通过两条互补的轨道,分别满足底层控制 (SIMT) 和更高级别抽象 (Tile) 的需求。虽然工具链尚处于早期阶段,但这些项目已被生产级的 Rust 推理引擎采用,这表明了快速成熟的路径。随着 API 的稳定,开发人员可以期待在完全使用 Rust 编写高性能 GPU 内核时获得更流畅、更安全的体验。
Sources
相关
- Dispatch
- Dispatch
- 项目
- 项目
- 项目