主要生态系统库如PyTorch和CuPy现在基于共享的cuda.core构建，减少了开发者面临的版本冲突和互操作问题。

随着CUDA 13.3的发布，@nvidia推出了CUDA Python 1.0，这套库和工具能让你通过Python获得完整的CUDA平台体验。使用标准的CUDA上下文、设备、流和内存，可与Python GPU生态系统的其他部分共享，因此你自己的内核可以针对CuPy数组或PyTorch张量运行，无需复制数据。

阅读完整博文：https://bit.ly/4hcSu2C

CUDA Python 1.0：稳定API，统一基础，完整平台访问

来源：https://developer.nvidia.com/blog/cuda-python-1-0-stable-apis-one-foundation-full-platform-access/ 多年来，需要使用GPU的Python开发者只有两个现实选择：深入学习NVIDIA CUDA C++以编写扩展、搭建构建工具链并维护与Python的绑定（大多数人从未这样做过）；或者转向更高层，使用他人的库来处理，即PyTorch、CuPy或RAPIDS。

第二种选择是Python GPU生态系统繁荣的原因。但它有局限。一旦你需要上层库未暴露的功能，你就回到了第一个选择。

由于每个库以自己的方式对接CUDA，让两个库在同一数据上协作需要特别小心。如果CuPy分配了一块GPU内存，cuDF要在相同流上操作这块内存而无需复制，需要什么？答案涉及交换协议，并密切注意谁拥有所有权。

随着CUDA 13.3的发布，我们推出了CUDA Python 1.0，这套库和工具让你通过Python获得完整的CUDA平台。Python现在是使用CUDA平台的受支持方式。

以下是同步推出的内容：

• cuda.core 1.0.0：Pythonic的CUDA运行时访问方式
• cuda.compute 1.0.0：CCCL的并行算法，可从Python调用
• cuda.bindings 13.3.0：对CUDA C API的低级1:1绑定，版本与CUDA工具包对应
• cuda-pathfinder：定位你环境中安装的CUDA组件
• nvmath-python 1.0：NVIDIA的数学库Python版本，以自己的发布轨道提供类似的稳定性承诺

CUDA Python 1.0标志着一个里程碑，而非一个你会在pip中输入的版本号；这些组件独立版本化，因此上述不匹配的数字是刻意的。

最关键的条目是cuda.core。它是CUDA基本术语（设备、流、缓冲区）转变为普通Python对象的地方，其重要性远不止于便利：它为Python中的每个GPU库提供了一个共同基础来构建、协作和跨库共享资源。这个理念贯穿了本文的其余部分。

CUDA 1.0：语义化版本控制 https://developer.nvidia.com/blog/cuda-python-1-0-stable-apis-one-foundation-full-platform-access/#cuda_10_semantic_versioning

CUDA Python 1.0不是重写，也不是新产品。这些库中的大多数已经可用并改进了一段时间。随着1.0版变化的是一个承诺：语义化版本控制。

实践中，这意味着：

• 破坏性API更改仅在主版本中发生
• 次要版本添加功能
• 补丁版本修复错误
• 任何计划移除的公共API首先在次要版本中弃用，并提供明确的替换路径

如果你曾因不确定API是否能在下一次升级中保留而在构建时犹豫，那么这个保证就是亮点。CUDA Python将继续跟踪新推出的CUDA功能，现在遵循可预测的版本控制和弃用规则。

统一基础取代各自为政 https://developer.nvidia.com/blog/cuda-python-1-0-stable-apis-one-foundation-full-platform-access/#one_foundation_instead_of_many

要理解1.0版的变化，回顾之前的情况会有所帮助。

从Python访问CUDA过去意味着选择一个绑定层，而且有好几个。每个由不同的项目维护，每个覆盖API的不同部分，每个对流、设备或分配都有自己的一套理解。如果你编写应用程序，你继承了依赖项碰巧使用的那一层。如果你编写库，你要么采用别人的，要么自己构建，生态系统又多了一个。这就是改变的地方。

现在有了一个官方的、NVIDIA维护的从Python访问CUDA的方式。从CUDA 13.3开始，CUDA Python和C++平等地成为一等公民，NVIDIA承诺未来保持功能完全对等。Python是使用CUDA平台的受支持方式。

实际的好处是库现在可以组合而不仅仅是共存。Numba内核和cuda.compute调用可以在同一个流上操作同一个GPU缓冲区，因为两者都没有携带私有的CUDA层。对象跨越库边界是因为在底层它们是同一个对象。这比任何交换协议都更简洁地回答了共享问题。

这也改变了谁能使用高级平台功能。像绿上下文这样的功能，它将GPU的流多处理器划分成独立的组，使对延迟敏感的内核与高吞吐量内核隔离，以前需要每个感兴趣的库单独绑定和暴露。现在它只需在cuda.core中实现一次，所有基于cuda.core构建的库都可以访问它。

如果你构建针对CUDA的库，这就是改变你日常工作的东西：你的精力投入到让你的库独特的地方，而不是别人已经写好的底层层。如果你编写应用程序，好处会间接传递给你，因为你的依赖项收敛到了相同的底层。

心智模型：统一基础上的三个层次 https://developer.nvidia.com/blog/cuda-python-1-0-stable-apis-one-foundation-full-platform-access/#the_mental_model_three_tiers_on_one_foundation

CUDA Python是一组库的集合，它们共同覆盖了从Python访问CUDA生态系统的方方面面：底层驱动和运行时绑定、并行算法、数学库、通信库和内核创作工具。下面的图1展示了它们如何分层。解读图像最清晰的方式是从下往上。

CUDA Python生态系统三个堆叠层次：底部是运行时系统基础，中间是CUDA库，顶部是内核创作工具。底层跨越全部宽度，表示两个上层都建立在它之上。 图1. CUDA Python生态系统：内核创作在顶部，CUDA库在中间，运行时系统是两者共享的底层基础 运行时系统是其他所有模块所依赖的基础：设备管理、内存分配、流与同步、CUDA图以及JIT编译。

cuda-pathfinder听起来平淡无奇，直到你想起Python GPU社区花了多少时间来调试一个进程实际加载了哪个CUDA运行时。

在其上是CUDA库：NVIDIA优化的主机和设备库的Python接口。cuda.compute带来了CCCL的主机可调用并行算法；nvmath-python（现在也达到1.0版）带来了数学库，包括主机API、设备API和底层绑定；NCCL4Py和NVSHMEM4P带来了通信库NCCL和NVSHMEM。

它们都没有重新实现底层的CUDA层。它们在你直接使用的相同cuda.core缓冲区、设备和流上工作，因此例如NVSHMEM的对称内存会作为cuda.core缓冲区返回给你。这个共享基础不仅仅是生态系统的指导方针；NVIDIA自己的库也是建立在它之上的。

顶部是内核创作，当你想自己编写GPU代码时使用。numba-cuda是用于Python内核的SIMT语言，与其并列的是两种更新的领域特定语言：cutile-python，一种用于块模型的CUDA瓦片语言；以及cuteDSL，一种用于Tensor Cores的CUTLASS语言。

有两点值得澄清：

首先，你进入的层次取决于你的问题需要，你永远不需要学习整个体系。许多多产的用户从未离开库层次。该图中的任何内容都不是课程。

其次，这些层次不是单个版本化的产品。每个组件在自己的轨道上推进，其中一些组件，包括一些较新的内核创作语言，仍然是实验性的，尚未包含在1.0语义化版本控制保证中，尽管意图是随着它们的稳定将加入同样的承诺。在将生产依赖固定在其中一个之前，值得了解这一点。

三种入门方式 https://developer.nvidia.com/blog/cuda-python-1-0-stable-apis-one-foundation-full-platform-access/#three_ways_in

几乎每个人都带着以下三个问题之一来到CUDA Python，每个问题都指向图表中的不同层次。下面按你承担多少（而非在图表中的位置）排序。

我只想要优化好的算法：cuda.compute https://developer.nvidia.com/blog/cuda-python-1-0-stable-apis-one-foundation-full-platform-access/#i_just_want_optimized_algorithms_cudacompute

最快的收获通常不是自己编写内核。而是调用一个已存在并由全职专家调优过的内核。

cuda.compute将CUDA核心计算库（CCCL）并行算法作为主机可调用的构建块带到Python：排序、扫描、归约、变换、去重、直方图、top-k等等。这些与支持高性能C++ CUDA代码的算法相同，从Python调用它们是对已有的GPU数组的普通函数调用。大量的数值工作实际上就是这些模式的组合。因为cuda.compute会为你实际运行的GPU编译它们，所以相同的调用在下一代硬件上无需更改即可工作。

1.0版还使它们更具表现力：你现在可以使用普通Python函数（包括lambda）来自定义算法的操作。

• 适用场景：你的问题可以分解为已知的并行模式，并且你希望用最少的新代码获得结果。

我想用Python编写自己的内核：Numba https://developer.nvidia.com/blog/cuda-python-1-0-stable-apis-one-foundation-full-platform-access/#i_want_to_write_my_own_kernel_in_python_numba

有时你的逻辑与打包好的算法不匹配。在这种情况下，你必须自己编写内核，而你仍然可以用Python来做。

Numba将Python的一个子集编译成GPU内核：你用装饰器标记一个函数，Numba从中生成GPU代码。你编写的是CUDA SIMT模型中的内核，表达一个线程的工作，然后GPU会在成千上万的线程上并行运行它。做出这个心智转变是需要学习的主要内容，这比学习C++和构建系统要小得多。

Numba CUDA MLIR是一个基于MLIR和现代NVVM工具链构建的新Numba兼容内核生成器。它保留了你已知的编程模型，替换了底层的编译器，提供更快的预热JIT编译和更低的内核启动延迟；对于大多数代码，迁移到它只需更改一行导入语句。它比1.0组件更新，尚未包含在同样的语义化版本控制承诺中。

• 适用场景：你的计算不符合打包好的算法，并且你想直接控制每个线程的操作。

我需要驱动和运行时API：cuda.core, cuda.bindings https://developer.nvidia.com/blog/cuda-python-1-0-stable-apis-one-foundation-full-platform-access/#i_need_the_driver_and_runtime_apis_cudacore_cudabindings

在底层有两个包直接提供CUDA本身，cuda.core达到1.0是本次发布的重点。

cuda.core是CUDA运行时的Pythonic接口，覆盖设备、流、程序、链接器、内存资源和图，以及CUDA C++的运行时编译，使内核可以从源代码运行而无需单独的构建步骤。重点在于Pythonic：资源是真正的Python对象，失败时引发异常而非返回错误代码。因为它使用标准CUDA上下文，所以它与Python GPU生态系统的其他部分共享设备、流和内存，因此你自己的内核可以针对CuPy数组或PyTorch张量运行，无需复制数据。

1.0版将之前发布周期中逐步稳定的API整合到一个统一的受支持接口中，并增加了三项值得关注的功能：

• 绿上下文：如前所述，将GPU的SM划分为独立的组，使对延迟敏感的内核在同一进程中与长时间运行的吞吐量内核隔离。
• 进程检查点：快照正在运行的进程的完整CUDA状态，以便稍后恢复。
• 进程间共享（IPC）：在进程间共享GPU内存，无需通过主机复制。

在其下，cuda.bindings提供底层绑定，提供CUDA主机API的完整1:1覆盖，从驱动和运行时到编译器、链接器以及周围的系统库。它的版本与CUDA工具包对应。cuda.core优化Python易用性，而cuda.bindings优化完整性：如果它存在于C API中，你就可以从Python访问它。

• 适用场景：你正在构建GPU库或将CUDA集成到现有工具包中。使用cuda.core获得Python化的生产力，当你需要全面访问C API时使用cuda.bindings。

生态系统已经在收敛 https://developer.nvidia.com/blog/cuda-python-1-0-stable-apis-one-foundation-full-platform-access/#the_ecosystem_is_already_converging

共享基础有效的最佳证据是已经有人在它之上构建。NVIDIA的通信和数学库如前所述，都已经使用cuda.core对象。更广泛的生态系统也在收敛。CuPy在导入模块时获得更简单的构建和更快、更小的占用空间。PyTorch现在在其CUDA轮子文件中依赖cuda.bindings。

每个迁移到共享层的库都会从你的依赖图中移除一个私有绑定层。这意味着更少的版本冲突、更少的神秘互操作问题，以及更少的地方让两个库对它们处于哪个CUDA上下文产生分歧。

而且因为每个组件都遵循自己轨道的语义化版本控制，依赖其中一个并不意味着从其余部分继承变动。

入门 https://developer.nvidia.com/blog/cuda-python-1-0-stable-apis-one-foundation-full-platform-access/#getting_started

一条命令即可获取CUDA Python栈：

pip install cuda-python cuda-cccl numba-cuda-mlir[cu13]

这涵盖了上述CUDA Python组件，以及基于MLIR的Numba后端。通过pip install nvmath-python[cu13]单独安装nvmath-python。唯一的系统要求是更新的NVIDIA驱动程序；通常不需要单独的CUDA工具包安装。

如果你正在决定从哪里开始：

• 如果你的工作是数据科学，你可能根本不需要触及这么低的层次。RAPIDS库已经覆盖了那个领域：cuDF加速pandas、Polars和Apache Spark，nx-cugraph支持NetworkX
• 对于优化的算法，从cuda.compute开始
• 要用Python编写自己的内核，从Numba或Numba CUDA MLIR开始
• 要访问底层驱动和运行时API，从cuda.core和cuda.bindings开始

从那里，CUDA Python文档 (https://nvidia.github.io/cuda-python/latest/) 和NVIDIA/cuda-python仓库 (https://github.com/NVIDIA/cuda-python) 提供了安装指南、API参考和示例，NVIDIA加速计算中心 (https://github.com/NVIDIA/accelerated-computing-hub) 汇集了更广泛的GPU计算学习材料。