转载说明：本文转载并精译自 VectorWare 于 2026-02-17 发布的博客文章 Async/await on the GPU。StaticFlow 导入日期为 2026-03-12。GPU 上的 Async/Await 作者：VectorWare GPU 代码现在也可以使用 Rust 的 async/await 了。本文会解释背后的原因，以及这将为 GPU 编程解锁什么能力。 在 VectorWare ，我们正在打造第一家 GPU-native software company。 今天，我们很兴奋地宣布：我们已经能够在 GPU 上成功使用 Rust 的 Future trait 和 async/await。这一里程碑朝着我们的愿景迈出了重要一步：让开发者可以借助熟悉的 Rust 抽象， 编写复杂、高性能、并且真正发挥 GPU 全部硬件能力的应用程序。GPU 上的并发编程 传统的 GPU 编程主要围绕数据并行展开。开发者写出一个操作，然后 GPU 会在数据的不同部分上并行运行这个操作。fn conceptual_gpu_kernel(data) { // All threads in all warps do the same thing to different parts of data data[thread_id] = data[thread_id] * 2; } 这种模型非常适合图形渲染、矩阵乘法、图像处理这类独立且统一的任务。 但随着 GPU 程序越来越复杂，开发者会使用 warp specialization 来引入更复杂的控制流和动态行为。 在 warp specialization 里，GPU 的不同部分会并发地执行程序中的不同部分。fn conceptual_gpu_kernel(data) { let communication = ...; if warp == 0 { // Have warp 0 load data from main memory load(data, communication); } else if warp == 1 { // Have warp 1 compute A on loaded data and forward it to B compute_A(communication); } else { // Have warp 2 and 3 compute B on loaded data and store it compute_B(communication, data); } } Warp specialization 让 GPU 逻辑从统一的数据并行，转向显式的任务级并行。这能让程序更加复杂，也能更充分地利用硬件。 例如，一个 warp 可以负责从内存加载数据，而另一个 warp 同时执行计算，从而同时提升计算资源和内存带宽的利用率。 但这种额外的表达能力是有代价的。开发者必须手动管理并发和同步，因为语言和运行时并没有原生支持。 这和 CPU 上的线程与同步问题类似，既容易出错，也很难推理。更好的 GPU 并发编程 已经有很多项目试图在不让开发者手动管理并发与同步细节的前提下，保留 warp specialization 的好处。 JAX 把 GPU 程序建模为计算图，用图中的依赖关系来表达操作之间的先后约束。 JAX 编译器会分析这张图，先决定执行顺序、并行方式以及放置位置，再生成实际运行的程序。 这让 JAX 能在向用户提供 Python DSL 这种高层编程模型的同时，也负责执行管理和优化。 同一套模型还可以支持 CPU、TPU 等多种硬件后端，而不必修改用户代码。 Triton 则以 block 为单位来表达 GPU 计算，每个 block 在 GPU 上独立执行。 和 JAX 一样，Triton 也是用 Python DSL 来描述这些 block 应该如何运行。 Triton 编译器会把 block 定义沿着一个多级 pipeline下降到多个 MLIR dialect，并在这个过程中使用 block 级的数据流分析来管理和优化生成程序。 更近一些，NVIDIA 推出了 CUDA Tile。 它和 Triton 一样，也围绕 block 来组织计算，但进一步把 “tile” 引入为一等数据单元。 这样一来，数据依赖就不再是推断出来的，而是被显式表达出来，从而同时改善性能优化空间与正确性推理。 CUDA Tile 接收 Python 等现有语言写成的代码，将其下降到名为 Tile IR 的 MLIR dialect，再在 GPU 上执行。 我们对这些工作都感到兴奋和受启发，尤其是 CUDA Tile。 我们认为，让 GPU 程序围绕显式的工…