CUDA Python 1.0 establishes a shared Python foundation
NVIDIA released CUDA Python 1.0 alongside CUDA 13.3, making Python an officially supported way to access the full CUDA platform. The release combines NVIDIA-maintained libraries and tools under a shared foundation for GPU applications and libraries.
The release includes cuda.core 1.0.0 for Pythonic CUDA runtime access, cuda.compute 1.0.0 for CCCL parallel algorithms, cuda.bindings 13.3.0 for one-to-one CUDA C API bindings, cuda-pathfinder for locating installed CUDA components, and nvmath-python 1.0 for NVIDIA math libraries. These components are versioned independently; CUDA Python 1.0 is a milestone rather than a single package version.
The centerpiece is cuda.core, which represents devices, streams, buffers, and other CUDA resources as shared Python objects. This allows libraries to cooperate and exchange resources without each maintaining a separate CUDA layer.
Semantic versioning and predictable APIs
CUDA Python 1.0 introduces a semantic-versioning commitment rather than a complete rewrite. Breaking changes are reserved for major releases, minor releases add features, and patch releases fix bugs. Public APIs scheduled for removal must first be deprecated in a minor release with a documented replacement.
NVIDIA says the policy is intended to give application and library developers confidence that their code can continue tracking new CUDA capabilities without unpredictable API churn.
One foundation for CUDA libraries
Previously, Python developers often had to choose between building CUDA C++ extensions or relying on higher-level libraries such as PyTorch, CuPy, or RAPIDS. Different projects used different bindings and resource models, which could make sharing memory and streams difficult.
With CUDA 13.3, NVIDIA describes CUDA Python and CUDA C++ as equal first-class interfaces, with a commitment to feature-complete parity. Libraries can use the same devices, streams, and buffers, allowing combinations such as Numba kernels and cuda.compute algorithms to operate on shared data.
Features such as green contexts, which divide streaming multiprocessors between latency-sensitive and throughput workloads, can now be exposed through cuda.core rather than reimplemented by every library.
Three tiers of the CUDA Python ecosystem
CUDA Python spans runtime access, CUDA libraries, and kernel-authoring tools. The runtime layer provides device management, memory allocation, streams, synchronization, CUDA graphs, and JIT compilation. cuda-pathfinder helps identify which CUDA runtime a Python process loads.
Figure 1. The CUDA Python ecosystem places kernel authoring above CUDA libraries, with the runtime system as the shared foundation.
The library tier includes cuda.compute, nvmath-python, NCCL4Py, and NVSHMEM4P. These libraries use shared cuda.core devices, buffers, and streams instead of rebuilding the underlying CUDA layer. The kernel-authoring tier includes numba-cuda, cutile-python, and cuteDSL.
Users do not need to learn every tier. Some newer kernel-authoring tools remain experimental and are not yet covered by the 1.0 semantic-versioning guarantees.
Choosing an entry point
Optimized algorithms with cuda.compute
cuda.compute exposes CCCL parallel algorithms as Python-callable GPU operations, including sort, scan, reduce, transform, unique, histogram, and top-k. Version 1.0 also supports customizing algorithms with ordinary Python functions, including lambdas.
Writing Python kernels with Numba
Numba compiles a supported subset of Python into CUDA SIMT kernels. Developers describe the work of one thread, which the GPU executes across many threads. Numba CUDA MLIR adds an MLIR- and NVVM-based backend with faster warm JIT compilation and lower kernel-launch latency; it is newer than the 1.0 components and does not yet share their versioning commitment.
Using CUDA APIs with cuda.core and cuda.bindings
cuda.core provides Python objects and exceptions for devices, streams, programs, linkers, memory resources, graphs, and runtime compilation of CUDA C++. CUDA 1.0 adds green contexts, process checkpointing, and inter-process GPU-memory sharing without host copies.
cuda.bindings provides versioned, one-to-one coverage of CUDA host APIs, including the Driver and Runtime APIs, compiler, linker, and related system libraries. Developers can use cuda.core for Pythonic productivity and cuda.bindings when complete C API access is required.
Ecosystem adoption and installation
NVIDIA’s communication and math libraries already use cuda.core objects. CuPy gains a simpler build and smaller import footprint, while PyTorch’s CUDA wheels now depend on cuda.bindings. NVIDIA says this convergence can reduce dependency conflicts and interoperability problems.
The main stack can be installed with:
pip install cuda-python cuda-cccl numba-cuda-mlir[cu13]
Install the math package separately with:
pip install nvmath-python[cu13]
An up-to-date NVIDIA driver is the only system requirement generally needed; a separate CUDA Toolkit installation is typically unnecessary. RAPIDS remains the recommended higher-level option for many data-science workloads, including cuDF for pandas, Polars, and Apache Spark, and nx-cugraph for NetworkX.
Documentation, installation guides, API references, and examples are available through the CUDA Python documentation and the NVIDIA/cuda-python repository. The NVIDIA Accelerated Computing Hub provides additional GPU-computing learning material.
Sri Koundinyan works on NVIDIA’s CUDA platform. He previously supported academic GPU users as a solution architect and researched LLM-based retrieval applications at Microsoft Research. He holds a PhD in Electrical Engineering from Stanford University.
Daniel Rodriguez is a technical product manager on NVIDIA’s CUDA Python and DevTools teams. His work focuses on tools for data scientists and high-performance computing engineers, following earlier roles at Google and enterprise data-science companies.