如果你关注 GPU 编程和 AI 基础设施，最近应该注意到一个趋势：Rust 正在悄悄渗透进 GPU 开发的每一个角落。NVIDIA Labs 在同一时间开源了两个 Rust GPU 项目——cuda-oxide（2768 stars）和 cuTile Rust（381 stars），前者是把标准 Rust 代码直接编译成 PTX 的 rustc 后端，后者是我们今天要聊的主角：一个基于 tile 抽象的安全 GPU 内核编程系统。
坦白说，第一次看到 cuTile Rust 的 README 时我有点不以为然——又一个 DSL？但读完论文 Fearless Concurrency on the GPU 之后，我的看法变了。这不是简单的语法糖，而是认认真真地把 Rust 的所有权和借用检查搬到了 GPU 内核层面。
问题：GPU 内核编程为什么需要安全？
写 CUDA 内核的人大概都踩过这些坑：线程越界访问 shared memory、race condition 导致结果随机出错、异步 kernel launch 后 host 端提前释放了显存。传统 CUDA C++ 对这类问题基本靠程序员自觉——你犯了错，程序不会告诉你，只会给你一个错误结果或者 segfault。
cuTile Rust 的核心思路是：既然 Rust 在 CPU 端已经用所有权系统解决了数据竞争问题，为什么不能把这个保证延伸到 GPU 端？
具体来说，cuTile Rust 做了三件事：
1. 可变 tensor 在 launch 前被切分成不相交的块（partition）
let z = api::zeros::<f32>(&[1024]).partition([128]);
这行代码把 1024 个元素的 tensor 切成 8 块，每块 128 个元素。每个 GPU 线程块只能访问自己那一块，物理上不可能发生跨块写冲突。
2. 不可变 tensor 被标记为共享只读
函数签名里的 &Tensor 和 &mut Tensor 直接表达了访问权限：
fn add<const B: i32>(
z: &mut Tensor<f32, { [B] }>, // 唯一可写
x: &Tensor<f32, { [-1] }>, // 只读共享
y: &Tensor<f32, { [-1] }>, // 只读共享
)
这不是注释层面的约定，而是编译器强制的。
3. Host 端在 kernel 执行期间保持所有权
launch 一个 kernel 不会把 tensor 的所有权转移走。GPU 在执行时，host 端的 tensor 仍然被"借用"，你没法在这个窗口期意外释放或修改它。这解决了异步执行中最阴险的一类 bug。
性能：安全不是免费的？这次可能是
论文里的数据相当有说服力。在 NVIDIA B200 上：
- 逐元素操作：7 TB/s，达到峰值显存带宽的 91%
- GEMM（矩阵乘法）：2 PFlop/s，达到 B200 dense f16 峰值的 92%，和 cuBLAS 差距在 0.3% 以内
- Persistent GEMM：安全版本跑出 2.07 PFlop/s，和低层 Tile IR 版本差距不到 0.3%
换句话说，安全抽象带来的运行时开销在测量噪声范围内——几乎为零。
这个结论如果经得起复现，意义很大。它意味着你可以用 Rust 写 GPU 内核，获得编译期安全保证，而不用付出传统上"安全语言写 GPU"的那种性能税。
Grout：用 cuTile Rust 写的推理引擎
理论说完了，来看实战。Hugging Face 和 NVIDIA 合作用 cuTile Rust 构建了 Grout，一个纯 Rust 的 Qwen3 推理引擎。
性能数据：
| 模型 | 硬件 | 速度 |
|---|---|---|
| Qwen3-4B | RTX 5090 | 171 tok/s |
| Qwen3-32B | B200 | 82 tok/s |
论文的 HBM roofline 分析显示这些数字和理论带宽上限一致，说明没有明显的效率损失。和 vLLM、SGLang 等成熟的 Python/C++ 推理框架相比，这个性能是 competitive 的。之前我们聊过 KVarN 在 vLLM 上做 KV-cache 量化的吞吐优化，以及 MiMo × TileRT 的模型-系统联合设计如何在推理吞吐上做到极致——Grout 走的是另一条路：用 Rust 重写整个推理栈，从语言层面消除内存安全隐患。
当然，Grout 目前只有 29 stars，还是个研究性质的 testbed，离生产级推理引擎还有距离。但它证明了一件事：用 Rust + cuTile Rust 写高性能推理内核是完全可行的。
cuTile Rust vs cuda-oxide：两条路线
NVIDIA Labs 同时维护着两个 Rust GPU 项目，这让不少人困惑。它们的区别其实很清晰：
| cuTile Rust | cuda-oxide | |
|---|---|---|
| 抽象级别 | 高层 tile DSL | 底层标准 Rust 语法 |
| 编译路径 | Rust → CUDA Tile IR → cubin | Rust → Rust MIR → LLVM IR → PTX |
| 安全保证 | 编译器强制的 tile 分区 + 所有权 | “safe-ish”，部分检查 |
| 适用场景 | tile-based 计算（GEMM、卷积等） | 通用 SIMT 内核 |
| Stars | 381 | 2768 |
cuda-oxide 更像是"让 Rust 成为 CUDA C++ 的替代品"，你写的代码更接近传统 CUDA 内核的风格，只是用了 Rust 语法。cuTile Rust 则是更高层的抽象，让你在 tile 层面思考，编译器帮你处理线程映射和内存安全。
两者不矛盾，更像是同一生态里的不同层次。对于 ML 工程师来说，cuTile Rust 的 tile 抽象更接近日常的 tensor 操作心智模型；对于系统程序员来说，cuda-oxide 的底层控制更灵活。
Rust GPU 编程的全景
把视野拉远一点，2026 年的 Rust GPU 生态已经初具规模：
- Rust-GPU（Embark Studios，3169 stars）：把 Rust 编译成 SPIR-V，面向 Vulkan 生态
- cuda-oxide（NVIDIA Labs，2768 stars）：Rust 直接编译 PTX
- cuTile Rust（NVIDIA Labs，381 stars）：tile-based 安全 GPU 编程
- ZLUDA（14288 stars）：让 CUDA 在 AMD GPU 上跑
有意思的是，NVIDIA 自己在大力推 Rust GPU 方向，这在几年前是不可想象的。背后的原因可能和 AI 推理的工程需求有关——当你的推理引擎要处理越来越大的模型、越来越复杂的调度逻辑时，C++ 的内存安全问题就不再是"偶发 bug"而是"系统性风险"。更根本的问题是，GPU 算力的瓶颈正在从计算转向显存，这意味着推理内核的优化空间越来越依赖于精细的内存管理——而这恰恰是 Rust 类型系统最擅长的领域。
我的判断
cuTile Rust 值得关注，但要分清楚"值得关注"和"现在就该用"的区别。
值得关注的原因：
- 这是 NVIDIA Labs 的研究项目，有论文支撑，不是草根实验
- tile-based 抽象和 Rust 所有权的结合思路非常优雅
- 性能数据（92% cuBLAS，安全零开销）如果可复现，是真正的突破
- Grout 证明了在推理场景的可行性
现在不急着用的原因：
- 项目自己说了"early stage, expect bugs and API breakage"
- 需要 CUDA 13.2，目前主流环境还在 CUDA 12.x
- 生态还很小（381 stars，Grout 29 stars），遇到问题很难找到帮助
- 和现有 CUDA C++ 代码的互操作性还不明确
对于正在做自定义推理内核优化的团队，建议持续跟踪但先不要迁移。对于研究 GPU 编程语言方向的人，这是必读的——论文 Fearless Concurrency on the GPU（arXiv: 2606.15991）写得很清晰，值得花一个下午细读。
如果你手头有 RTX 5090 或者能接触 B200，可以用 Grout 跑个 benchmark 看看实际表现。对于大多数 ML 巘程师来说，vLLM 和 SGLang 仍然是短期内的务实选择——但 Rust GPU 写推理内核这个方向，三到五年内可能会变得非常重要。
信源
- cuTile Rust GitHub — NVIDIA Labs，381 stars，Apache 2.0
- Fearless Concurrency on the GPU (arXiv: 2606.15991) — cuTile Rust 论文
- Grout — Qwen3 Inference Engine — HuggingFace，基于 cuTile Rust
- cuda-oxide — NVIDIA Labs，Rust-to-PTX 编译器，2768 stars
- Rust-GPU — Embark Studios，Rust-to-SPIR-V，3169 stars
- HN 讨论 — cuTile Rust Show HN