Rust 写 GPU 内核终于安全了？cuTile Rust 的 tile-based 方案和它背后的推理引擎

Wed, 17 Jun 2026 10:06:52 +0800

如果你关注 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