Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

引言 — 没能挤进发布说明标题的一行
nvptx64 目标是什么
到底改了什么 — 精确的数字
为什么要砍 — 三个具体缺陷
为什么分界线偏偏是 CUDA 11
谁会受影响，该怎么办
那么，真的有人在用这个吗 — 2026 年的 Rust-on-GPU 版图
诚实的权衡 — 以及什么时候不该用
结语
参考资料

引言 — 没能挤进发布说明标题的一行

Rust 1.97.0 于 2026 年 7 月 9 日发布。发布说明的标题有三条 — v0 符号修饰晋升为 stable 默认值、Cargo 的 build.warnings 配置、此前一直被隐藏的链接器输出被曝光。这三条我已经在几天前的一篇文章里整理过了。

然而，同一份发布说明的 Platform Support 部分还有一行没能挤进标题。

nvptx64-nvidia-cuda: drop support for old architectures and old ISAs   (PR #152443)

有意思的地方在这儿。三条标题级的变化全都是向后兼容的。符号修饰变了，代码照样能构建；警告配置是选择性开启的；链接器输出只是变得更可见而已。相比之下，这一行是 1.97 中唯一一处真正会破坏东西的改动。只是会被破坏的人非常少。

而这项改动的背后，藏着一个进入 2026 年后突然变得不再安静的故事 — 用 Rust 写 GPU 内核。

nvptx64 目标是什么

nvptx64-nvidia-cuda 是 rustc 用来为 NVIDIA GPU 生成代码的目标。从这里出来的不是机器码，而是PTX — NVIDIA 的虚拟 ISA，由 CUDA 驱动在运行时即时编译成实际 GPU 的 SASS。rustc 通过 LLVM 的 NVPTX 后端生成这份 PTX。

按照 rustc 平台支持文档的说法，这个目标的特点是这样的。

它是 Tier 2 目标，维护者只有 @kjetilkjeka 一人。
它是 no_std 目标。默认链接器是 llvm-bitcode-linker，要拿到 PTX 需要把 crate-type 构建为 cdylib。
内核函数用 extern "ptx-kernel" 声明。
文档里的构建示例用的是 nightly。

$ RUSTFLAGS='-Ctarget-cpu=sm_89' cargo +nightly rustc \
    --target=nvptx64-nvidia-cuda -Zbuild-std=core --crate-type=cdylib

Tier 2 到底保证了什么，目标分级政策写得很明确 — "Rust's continuous integration checks that tier 2 targets will always build, but they may or may not pass tests."。换句话说，只保证能构建，不保证测试能通过。这正是它和 Tier 1(同时保证「能构建 + 测试通过」)的区别所在。记住这句话 — 它是理解下文缺陷为何会累积的关键。

到底改了什么 — 精确的数字

2026 年 5 月 1 日，目标维护者 Kjetil Kjeka 发了一篇预告文章。照文章原话，新的最低要求是这样的。

"The new minimum supported versions will be: PTX ISA 7.0 (requires a CUDA 11 driver or newer) SM 7.0 (GPUs with compute capability below 7.0 are no longer supported)"

对照 rustc 文档里的表格，变化的幅度一目了然。

Rust 版本	最低 SM	最低 PTX ISA
~ 1.96	2.0	3.2
1.97 ~	7.0(Volta+)	7.0(CUDA 11+)

从 SM 2.0 到 7.0。这不是渐进式的调整，而是一次性把整整一代都拿掉了。预告文章的说法是 "Until now, Rust has supported emitting PTX for a wide range of GPU architectures and PTX ISA versions."，如今那个 "wide range" 已经收窄到 Volta 及之后。

计算能力编号和架构名称的对应关系是：5.x 是 Maxwell，6.x 是 Pascal，7.0 是 Volta。也就是说被砍掉的是整个 Maxwell 和 Pascal世代 — 按 NVIDIA 的遗留 GPU 列表，包括 GTX 1080(6.1)、Tesla P100(6.0)、Jetson TX2(6.2)这些。Tesla V100 和 TITAN V 以 7.0 成为第一批幸存下来的一代。

顺便一提，NVIDIA 的当前 GPU 列表本身就已经从 7.5 起算，更低的都被挪到了遗留页面。Rust 划的这条 7.0 线，反而比 NVIDIA 自己称为「当前」的线还要低一档。

为什么要砍 — 三个具体缺陷

这才是这次改动真正的内容。预告文章把理由归纳如下。

"In practice, several defects existed that could cause valid Rust code to trigger compiler crashes or miscompilations."

意思是有效的 Rust 代码会引发编译器崩溃或错误编译。miscompilation 是悄悄吐出错误的代码，比崩溃更糟。

预告文章没有说明「several defects」具体是什么，但是推动这项改动落地的编译器团队 MCP #965里写得很具体。这是一份 2026 年 2 月 1 日提出、被标记为 major-change-accepted 的提案，援引了三个 issue 作为依据。

rust-lang/rust#147672 — 在 PTX ISA 7.0 以下，调试符号的生成存在 LLVM 侧的限制。
rust-lang/rust#150515 — 在比 SM 7.0 更老的架构上，原子操作顺序(atomic ordering)得不到充分支持。
rust-lang/rust#141468 — PTX ISA 的版本体系与 Rust 的 target-feature 机制对不上。

从第三点看起，问题的性质就显露出来了。Rust 的 -C target-feature 是一种「有/没有这个特性」的集合模型。而 PTX ISA 版本不是集合，而是线性的版本号。这两种模型从一开始就是错位的，支持范围越广，这种错位造成的组合爆炸也就越大。

但真正的核心是第二点。照搬 MCP 的说法，在 SM 7.0 以下，原子操作顺序得不到充分支持 — SM 7.0 及以上有官方保证，而在此之前只是尽力而为(best-effort)。这对 Rust 为什么是致命的呢？因为在 Rust 的内存模型里，core::sync::atomic 的 acquire/release 语义不是可选项。换成 C++，大不了说一句「那款 GPU 上别用原子操作」就翻篇了；但在语言层面就承诺了顺序保证的 Rust 里，这就变成了语言自己食言的问题。所谓「产生错误编译」，说的正是这个。(顺带一提，Volta 也正是引入了 warp 内独立线程调度的那一代 — SM 7.0 成为分界线并不是巧合。)

也就是说，这不是「清理老旧硬件」，而是撤下一个守不住的承诺。预告文章的原话也是这个意思 — "Raising the baseline addresses these issues and enables more complete support for the remaining supported hardware."。与其支持范围广而残破，不如支持范围窄而完整。

而这恰好和前面看到的 Tier 2 定义对上了。在一个只由 CI 保证能构建、却不保证测试通过的目标上，那些实际上没人拿硬件跑过的老旧架构的缺陷，已经悄悄积累了好几年。

为什么分界线偏偏是 CUDA 11

MCP 拿来作为版本选择依据的那句话是 — "CUDA versions older than 12 are end-of-life, and PTX ISA 7.0 is supported starting with CUDA 11.0."

细读一下会发现，这两句话指向的其实是两条不同的线。只按 EOL 逻辑，分界线应该是 CUDA 12，但实际定下来的是 CUDA 11(PTX ISA 7.0)。也就是说，这条线比 EOL 逻辑所允许的还要保守一档。看起来是一种「刚好抬到足以消除缺陷，但不多切一分」的选择。

MCP 同时也把 NVIDIA 那边的现状列为依据 — CUDA 13 支持 SM 7.5～12.1，CUDA 12.9 支持 SM 5.0～12.1。有意思的一点是，Rust 定下的 SM 7.0 分界线，其实比最新的 CUDA 13 已经砍掉的那条线(7.5)还要宽松。

谁会受影响，该怎么办

预告文章是这样指引的。

"If you do not specify -C target-cpu, the new default will be sm_70, and your build should continue to work (but will no longer be compatible with pre-Volta GPUs)."

"If you currently specify an older -C target-cpu (for example, sm_60), you will need to either: remove that flag and let it default to sm_70, or update it to sm_70 or a newer architecture."

归纳起来是这样。

不指定 -C target-cpu            -> 默认值变为 sm_70。构建能通过。
                                    但产物在 pre-Volta GPU 上跑不了。
指定 -C target-cpu=sm_60        -> 需要去掉该标志，或升级到 sm_70 及以上。
CUDA 10 及更早的驱动             -> 不再支持。
Maxwell / Pascal GPU            -> 不再支持。没有退出选项。

值得注意的一点是：没有退出选项。预告文章里也没有「恢复旧行为的标志」。如果非要为 Pascal 吐出 PTX，唯一的办法就是把工具链固定在 1.96 及更早版本，而这也就意味着带着缺陷继续用下去。

预告文章对影响范围的判断相当平淡。

"In this case, the most recent affected GPU architectures date back to 2017 and are no longer actively supported by NVIDIA."

"We therefore expect the overall impact of this change to be limited."

要考虑到这是作者本人的估计，但理由是站得住的 — 受影响的 GPU 里最新的一代也是 2017 年的产品，NVIDIA 自己也不再积极支持它们了。

那么，真的有人在用这个吗 — 2026 年的 Rust-on-GPU 版图

到该诚实的时候了。Tier 2、一个维护者、需要 nightly、no_std。直接裸用这个目标的人并不多。那为什么这次改动还有意义呢？

因为进入 2026 年后，用 Rust 处理 GPU 的这个场子突然热闹了起来。看看 Rust CUDA 项目整理的生态地图，各种方案是这样划分的。

cuda-oxide — 作为 rustc 的代码生成后端，直接瞄准 NVIDIA 的 PTX/SASS。设计中心是「把 CUDA 搬到 Rust 里」(写内核、设备内建函数、SIMT 执行模型)。
rust-cuda — 通过 rustc_codegen_nvvm 走 rustc → NVVM IR → PTX 这条路。设计中心是「把 Rust 搬到 GPU 上」— 让 async/.await 这类 Rust 的便利性也能用在设备上。
Rust-GPU — 面向图形学，目标是 SPIR-V。Vulkan/Metal/DirectX。核心是跨厂商可移植性。
CubeCL — 内置 DSL 加 JIT 运行时。一份内核同时跑 CUDA/ROCm/WGPU。是 proc-macro 方案，不是 rustc 后端。
std::offload — nightly 语言特性。通过 LLVM offload 运行时，把 CPU 循环隐式地卸载到加速器上。
cudarc — 安全的 CUDA 驱动绑定。内核在别处写好，只有主机(host)端是 Rust。
wgpu — WebGPU API 的 Rust 实现。属于完全不同的一层技术栈。

这其中最大的新闻是cuda-oxide。这是 NVIDIA Labs 亲自推出的 Rust→CUDA 编译器，仓库描述原话是 "an experimental Rust-to-CUDA compiler that lets you write (SIMT) GPU kernels in safe(ish), idiomatic Rust"。它既不是 DSL 也不是绑定，而是把标准 Rust 直接编译成 PTX。流水线是 Rust → MIR → Pliron IR → LLVM IR → PTX，许可证是 Apache-2.0。

一家 GPU 公司亲自为自家平台推出 Rust 编译器 — 这就是 2026 年的信号。而要让这些工具真正能跑起来，底层的 PTX 生成就必须准确。基线上调正是在夯实那个地基。

地基不稳的证据，就在 Rust CUDA 项目自己的文档里。它这样解释自己存在的理由 — 此前「唯一可用的选择就是用 LLVM PTX 后端」，而那个后端「在许多常见的 Rust 运算上会生成无效的 PTX」。这说明默认路径不可靠到了不得不另挖一条路的地步。1.97 的这次清理，走的是把默认路径收窄、同时让它变得可信的方向。

诚实的权衡 — 以及什么时候不该用

这项改动本身是一笔好交易。对于那些没人再拿真实硬件去验证的老旧架构，与其承诺一个守不住的原子操作保证、悄悄吐出错误的代码，不如收窄支持范围，在剩下的硬件上把事情做对。这是选择了正确性而不是兼容性，而正确性确实是坏的，所以这个选择是站得住脚的。

但这并不意味着你现在就该用 Rust 写 GPU 内核了。诚实地写出来是这样的。

nvptx64 目标是 Tier 2 — 只保证能构建，不保证测试通过。文档里的构建示例本身就要用 nightly。
它是 no_std，还有一些目标特有的限制。比如说，如果 static 初始化表达式构成循环，编译器会拒绝(static A: Foo = Foo(&A); 就是一个错误)。
就连 NVIDIA 推出的 cuda-oxide，也这样给自己定位 — "in an early stage (alpha) and under active development: you should expect bugs, incomplete features, and API breakage."。而且它被固定在一个特定的 nightly(nightly-2026-04-03)上，要求 CUDA 12.x 及以上，还要求 Linux。

所以在大多数情况下，答案是这样的。如果你只是想在 Rust 里用 GPU，那就用 CUDA C++ 写内核，主机端再用 cudarc 这类安全的驱动绑定接上去。这是眼下真正跑在生产环境里的组合。把内核也用 Rust 写，目前还是留给研究、实验，或者单一源代码库中主机和设备共享类型能带来明显收益的场景的选项。

如果 Maxwell 或 Pascal 还在服役 — 判断只有两种。要么把工具链固定在 1.96 及更早版本(带着缺陷继续用)，要么就不用 Rust 写内核。实际上，后者在大多数情况下本来就已经是答案了。

再补充一点，cuda-oxide 本身就要求 CUDA 12.x 及以上，这一点恰好说明了这次改动的性质。生态本来就已经走在 CUDA 11 前面了，编译器的基线更像是姗姗来迟地追上了那个位置。

结语

Rust 1.97 的 nvptx64 基线上调，在发布说明里只是一行改动。实际内容是这样的 — 从 SM 2.0/PTX 3.2 提升到 SM 7.0/PTX 7.0，拿掉 Maxwell 和 Pascal，换来剩余硬件上原子操作顺序和调试符号能正确工作。没有退出选项，而按作者自己的判断，影响是有限的。

之所以值得花时间细读这次不起眼的清理，理由在它的背景。一个多年来没人关注的 Tier 2 目标上，缺陷已经悄悄堆积；而进入 2026 年后，真正的工具 — 包括 NVIDIA 自己推出的编译器 — 开始搭建在这个目标之上，这才让人有理由去正视这个地基。选择收窄支持范围、把它做对，而不是扩大范围，看起来像是那些真的打算在上面搭建东西的人做出的决定。

不过结论依然平淡。Rust-on-GPU 只是从「不可能」走到了「开始被管理」，还谈不上「生产就绪」。写着 alpha 的文档，就该照字面去信。而对大多数人来说，1.97 该做的事依然只有一件 — rustup update stable。