多年以来，Python开发者若需要使用GPU，通常只有两条路可走：一是深入学习NVIDIA CUDA C++并搭建完整的构建工具链，二是借助PyTorch、CuPy或RAPIDS等上层库间接调用。第二条路支撑了Python GPU生态的繁荣，但也有其局限——一旦所用库无法满足特定需求，开发者便不得不退回第一条路。
此前，各个库以各自不同的方式访问CUDA，导致库与库之间的数据协作颇为繁琐。例如，若CuPy分配了一块GPU内存，cuDF若要在同一流上对该内存块进行操作，往往需要依赖互操作协议并精细管理内存所有权。
随着CUDA 13.3的发布，NVIDIA推出了CUDA Python 1.0——一套让开发者能够从Python直接访问完整CUDA平台的库与工具集合。至此，Python正式成为CUDA平台的官方支持语言。
此次发布包含以下核心组件：
cuda.core 1.0.0：以Pythonic风格访问CUDA运行时
cuda.compute 1.0.0：可从Python调用的CCCL并行算法库
cuda.bindings 13.3.0：与CUDA C API一一对应的底层绑定，版本与CUDA工具包同步
cuda-pathfinder：用于定位当前环境中已安装的CUDA组件
nvmath-python 1.0：NVIDIA数学库的Python接口，遵循独立的稳定性承诺
需要注意的是，"CUDA Python 1.0"是一个里程碑名称，而非pip安装时使用的版本号，各组件独立版本控制。
其中最具价值的是cuda.core。它将CUDA的基本操作概念（设备、流、缓冲区）封装为普通Python对象，不仅提升了开发便利性，更为Python GPU生态中的各个库提供了统一的底层基础，使它们能够共享资源、协同运作。
稳定性承诺：语义化版本控制
CUDA Python 1.0最重要的变化是正式引入语义化版本控制：
重大API变更仅在主版本号更新时发生
次版本号更新仅新增功能
补丁版本号更新仅修复缺陷
计划废弃的公共API将提前在次版本中标注，并提供明确的迁移路径
对于此前因担忧API稳定性而迟疑不决的开发者而言，这一承诺无疑是此次发布的最大亮点。
统一基础的深远意义
在此之前，从Python访问CUDA意味着要在多个绑定层之间做出选择，每个绑定层由不同项目维护，覆盖不同的API范围，且对流、设备、内存分配各有自己的定义。这一现状在CUDA Python 1.0中得到了根本性改变。
现在，NVIDIA官方提供了唯一一套从Python访问CUDA的标准方式。在CUDA 13.3中，CUDA Python与C++并列为同等地位的一等公民，NVIDIA承诺持续维护两者的功能完整性。
这带来了切实的实践价值：Numba内核与cuda.compute调用可以在同一GPU缓冲区的同一流上运行，因为两者共享同一底层CUDA层，对象可以跨库传递而无需数据拷贝。这也意味着绿色上下文（Green Contexts，将GPU流多处理器分区以隔离延迟敏感型内核）等高级特性，只需在cuda.core中实现一次，所有基于cuda.core构建的库即可直接使用。
CUDA Python生态全貌
CUDA Python涵盖了从底层到高层的完整生态：
运行时系统层（最底层）：提供设备管理、内存分配、流与同步、CUDA图及JIT编译能力。cuda-pathfinder负责定位当前环境中实际加载的CUDA运行时，解决了长期困扰社区的版本混乱问题。
CUDA库层：cuda.compute提供CCCL的并行算法；nvmath-python（同步发布1.0版本）提供数学库接口；NCCL4Py和NVSHMEM4P提供通信库接口。这些库均直接使用cuda.core的缓冲区、设备和流，例如NVSHMEM的对称内存以cuda.core缓冲区的形式返回。
内核编写层（最顶层）：numba-cuda提供SIMT编程模型；cutile-python提供面向块模型的CUDA Tile语言；cuteDSL提供面向Tensor Core的CUTLASS语言。
三类典型使用场景
场景一：调用已有并行算法
cuda.compute将CCCL的并行算法（排序、扫描、归约、变换、去重、直方图、Top-K等）以Python函数调用的形式暴露出来。1.0版本进一步支持使用普通Python函数（包括Lambda）自定义算法行为。适用于：问题可分解为标准并行模式，且希望以最少代码量完成任务。
场景二：用Python编写自定义内核
Numba将Python子集编译为GPU内核，通过装饰器标注函数后自动生成GPU代码。Numba CUDA MLIR是基于MLIR和现代NVVM工具链的新一代内核生成器，可实现更快的JIT编译和更低的内核启动延迟，对多数代码而言迁移只需修改一行导入语句。适用于：计算逻辑不适合现有算法，需要直接控制线程行为。
场景三：直接访问CUDA运行时与驱动
cuda.core提供Pythonic的CUDA运行时接口，资源以Python对象形式呈现，错误通过异常抛出而非返回码处理。1.0版本新增三项重要能力：
绿色上下文：将GPU的SM分区为独立组，使延迟敏感型内核与长时间运行的吞吐型内核互不干扰
进程检查点：对运行中进程的完整CUDA状态进行快照并支持恢复
进程间共享（IPC）：在进程间共享GPU内存，无需经由主机拷贝
cuda.bindings则提供对CUDA主机API的完整1:1覆盖，从驱动和运行时到编译器、链接器及周边系统库，版本与CUDA工具包绑定。适用于：构建GPU库或将CUDA集成至现有工具包。
生态融合已在推进
统一基础的价值已有实际案例印证：NVIDIA自家的通信库和数学库已全面采用cuda.core对象；CuPy的构建流程得到简化，模块导入更快、体积更小；PyTorch的CUDA发行包已将cuda.bindings列为依赖项。
每一个迁移至共享层的库，都意味着依赖图中少了一个私有绑定层，进而减少版本冲突、降低互操作问题出现的概率。
快速上手
一条命令即可安装CUDA Python核心栈：
pip install cuda-python cuda-cccl numba-cuda-mlir[cu13]
nvmath-python单独安装：pip install nvmath-python[cu13]
系统唯一要求是安装最新版NVIDIA驱动，通常无需单独安装CUDA工具包。
入门建议：
数据科学场景：优先考虑RAPIDS库（cuDF加速pandas/Polars/Spark，nx-cugraph支持NetworkX），可能无需直接使用底层接口
需要优化算法：从cuda.compute入手
需要用Python编写自定义内核：从Numba或Numba CUDA MLIR入手
需要访问底层驱动和运行时API：从cuda.core和cuda.bindings入手
Q&A
Q1：CUDA Python 1.0和之前的PyTorch、CuPy这些库有什么区别？
A：PyTorch、CuPy等库是在CUDA之上构建的上层库，各自用自己的方式访问CUDA，导致库之间数据共享复杂。CUDA Python 1.0是NVIDIA官方提供的统一底层接口，让所有Python GPU库都能基于同一套基础（cuda.core）构建，从而实现真正意义上的资源共享和无缝互操作，而不只是依赖数据转换协议凑合协作。
Q2：cuda.core 1.0新增的绿色上下文是什么，有什么用？
A：绿色上下文（Green Contexts）是一种将GPU的流多处理器（SM）划分为多个独立分区的机制。其核心用途是让延迟敏感型内核（如实时推理请求）与长时间运行的吞吐型内核（如批量训练任务）在同一GPU进程中互不干扰。此前这一功能需要每个库单独实现绑定才能使用，现在只需在cuda.core中实现一次，所有基于cuda.core的库均可直接调用。
Q3：CUDA Python 1.0的语义化版本控制对开发者意味着什么？
A：语义化版本控制意味着开发者可以安心将CUDA Python作为生产依赖：主版本号变更才会有不兼容的API改动，次版本号只新增功能，补丁版本只修复Bug。计划废弃的API会提前在次版本中标注并给出替代方案。这解决了此前开发者因担忧API随时变动而不敢深度依赖相关库的顾虑。
