金属散热鳍片与铜质基板的微距特写

一条容易被划过去的公告

2026 年 9 月，英伟达技术博客挂出一篇文章，标题朴素得几乎不像大厂出品：Introducing CUDA Rust。业内大多数人扫一眼就过去了——用 Rust 写 GPU 内核这件事，社区里的 rust-cuda、rust-gpu、cudarc 已经折腾了好几年。但这次不一样：过去那些项目是在 CUDA 之外自己搭一套，而这次是英伟达自己在官方工具链里，给 Rust 开了两条正式通道。

两条路线，对应两种编程模型

第一条叫 SIMT，也就是大家在 CUDA C++ 里写惯的那种模式：你描述单个线程做什么，然后启动成千上万个线程。走这条路的是 cuda-oxide，它实现了一个 rustc 的代码生成后端，把 Rust 写的核函数直接编译成 PTX，中间经过 Pliron IR 和 LLVM。代价是必须锁定特定版本的 nightly 工具链，目前还处在很早期的 alpha 阶段。

第二条叫 Tile，是更新的模型：你描述「一块数据」要做什么，由编译器决定线程怎么映射、内存怎么摆放。对应项目是 cutile-rs，跑在 stable Rust 1.89 以上、配合 CUDA 13.3，不需要自带 LLVM，已经发布到 crates.io，并且被 HuggingFace 的推理引擎 Grout 和 mistral.rs 用上了。英伟达的建议很明确：优先考虑 Tile，需要精细控制内存和线程时再退到 SIMT。

值得注意的不是语法，是安全边界

两个项目都在编译期做内存安全：cuda-oxide 用 DisjointSlice 和启动契约来防止别名冲突，cutile-rs 用张量分区和所有权来保证独占访问。对写过核函数的人来说，这句话的分量比「Rust 也能写 CUDA」重得多——GPU 上最难查的 bug 从来不是逻辑写错，而是一个线程越界读了另一个线程正在写的数据。这类问题在 C++ 里靠人盯，在 Rust 里靠编译器拦。

产业层面的三个判断

第一，内核语言的选择正在从「绑定」变成「偏好」。英伟达明确表示要支持 CUDA Rust、CUDA C++、CUDA Python 三者的互操作。这意味着选哪个前端，不再等于押注哪个生态，迁移的心理成本会明显下降。

第二，系统层用 Rust 已经是既成事实。Nova 显卡驱动、Dynamo 的 Rust 核心、NVTX 的 Rust 绑定，都不是试验品。内核是整个 AI 系统层里最后一块没被覆盖的地方，现在补上了。

第三，别急着迁移。nightly 依赖、alpha 状态、文档还在补齐，这些是真实的成本。更合理的节奏是：新写的、逻辑独立的、以安全为痛点的算子先试水，存量 CUDA 代码继续跑，等生态把坑填完再谈规模化。

如果一件事只能靠少数人用 C++ 写好，那它就不算基础设施。Rust 进 CUDA 的意义，大概就在这里。