GPU 编程一直有一个绕不开的权衡:想跑得快,就得写 CUDA/HIP 这种厂商绑定的 DSL,或者手动摆弄裸指针;想安全,就得接受一层又一层的抽象,性能随之打折。一篇提交到 arXiv 的论文提出,这条路可能有第三种走法——把 GPU 卸载直接做进 Rust 编译器里。

论文标题就叫《GPU Offload in Rust: Portable, Safe, and Fast》,由 Manuel S. Drehwald、Alán Aspuru-Guzik、Johannes Doerfert 等人撰写。核心思路是在 rustc 和 LLVM 后端里构建一个「零开销、多厂商」的 GPU 编译框架,让开发者直接写 Rust 代码跑在 GPU 上,数据在 CPU/GPU 之间自动搬运,默认安全、方便、够快。
技术上有几个关键点。一是利用 Rust 的类型系统和所有权模型来安全管理数据转移,把 Rust 严格的别名规则(noalias)传给 LLVM 的 Offload 基础设施做内存优化;二是处理跨厂商 ABI 不一致的问题——不同 GPU 厂商的 host 端和 device 端 ABI 对齐方式不一样,这是多厂商支持最麻烦的地方;三是设计了一套两遍编译流水线,能同时安全处理手动和编译器自动生成的内存移动。

性能验证用的是 RAJAPerf 基准套件。结果用论文的话说是「solid」——生成的 GPU kernel 性能能跟手写优化的 CUDA 和 HIP C++ 基线打平,同时不牺牲内存安全,也不要求写 unsafe 代码。
HN 讨论区里,最尖锐的一个问题来自一个老生常谈的质疑:类似的 LLVM offload 方案在 C++ 那边就没成过,凭什么换 Rust 就能成?
回答也分几派。有人指出,Rust 和 C++ 是语义完全不同的语言,这篇论文 100% 押注在 Rust 的子结构类型系统(substructural type system)上,对 CPU/GPU 边界上的代码有非常严格的约束——这恰恰是 C++ 做不到的。也有人引用 Mozilla 当年用 Rust 之前先尝试并行化 Firefox CSS 引擎失败的先例,说「如果 Rust 在正确的地方做得不一样,它未必不能成」;反过来,如果没做对方向,也可能重蹈覆辙。
还有人直接反驳了「C++ offload 没成过」这个前提:「Metal Shading Language 不就是用 LLVM 编译的 C++17 吗?它跑在每一台 Mac 和 iPhone 上,这可不叫『没成』。」这条评论立刻被呛了回来——「你倒是试试把随便一个 C++17 代码库编译到 iPhone 的 GPU 上跑跑看」,楼里又吵了几句 C++ 到底算不算「能上 GPU」。
最有信息量的一条评论来自一个做 LLM 推理引擎的 Rust 开发者。他说自己所有代码都写在 Rust 里,做自定义 LLM 推理项目时最大的痛苦一直是 bindings——要么自己维护绑定,要么等上游更新或 fork 之后自己维护。「能在 GPU 上直接跑 Rust core,我会从第一天就开始用。」
另一条讨论聚焦在实现路径上。有人质疑为什么要走 LLVM offload,而不是让 MIR 直接生成 PTX/HIP 或者干脆通过 Vulkan 绑 SPIR-V。评论区回应说,Shader 和 Vulkan 的语义限制太多、写起来很烦,Rust 形态的 GPU 计算或许能提供更好的抽象。还有人抛出一个反讽:「大家连 Python 形态的 GPU 计算 DSL 都愿意费劲去写,现在换成 Rust 反而问为什么?」
指针是另一个焦点。论文里点名 rust-gpu 项目必须模拟指针(emulate pointers),作者认为这对大多数 HPC 基准是「blocking issue」。有人追问为什么是阻塞性的,回答是:HPC 目标的高性能内存管理绕不开指针,现有设计模式需要它。
这个项目对 NVIDIA 和 AMD 都做了支持,这点被多次提及——OpenMP 和 SYCL 虽然也能跨厂商,但在保持 Rust 安全模型的前提下做到这一点,是它最诱人的地方。当然,也有人冷静地提醒:跨厂商的性能到底有多「可移植」,还要等实际跑起来才知道。
论文作者之一 Johannes Doerfert 是 LLVM OpenMP 团队的成员,长期做 LLVM offload 相关工作,这个背景让论文里对 ABI 和两遍编译的处理显得不那么空中楼阁。不过项目目前还处于「active development」,离上游合并还有距离。
安全和高性能在 GPU 领域长期被认为是鱼与熊掌,这篇论文的野心是用 Rust 的类型系统把这两件事同时拿下。至于能不能成,HN 上那个 C++ 的旧问号,可能要等这个框架真正落地才有答案。
参考来源: