CUDA Python 1.0: Stable APIs, One Foundation, Full Platform Access

The second option is why the Python GPU ecosystem thrives. But it has limits. The moment you need something the library above you doesn’t expose, you’re back to the first choice.

Because each library reached CUDA in its own way, getting two of them to cooperate on the same data took care. If CuPy allocated a block of GPU memory, what did it take for cuDF to work on that block, on the same stream, without copying it? The answer ran through interchange protocols and close attention to who owned what.

With CUDA 13.3, we released CUDA Python 1.0, the libraries and tools that give you the full CUDA platform from Python. Python is now a supported way to use the CUDA platform.

Here is what lands together:

• cuda.core 1.0.0, Pythonic access to the CUDA runtime

• cuda.compute 1.0.0, CCCL’s parallel algorithms, callable from Python

• cuda.bindings 13.3.0, low-level 1:1 bindings to the CUDA C APIs, versioned to the CUDA Toolkit

• cuda-pathfinder, which locates the CUDA components installed in your environment

• nvmath-python 1.0, NVIDIA’s math libraries in Python, under the same kind of stability commitment on its own release track

CUDA Python 1.0 names a milestone, not a version number you will type into pip; the components are versioned independently, so the mismatched numbers above are deliberate.

The most consequential entry is cuda.core. It is where CUDA’s basic vocabulary (devices, streams, buffers) becomes a set of ordinary Python objects, and that matters well beyond convenience: it gives every GPU library in Python a common foundation to build on, collaborate through, and share resources across. That idea is the thread running through the rest of this post.

CUDA 1.0: Semantic versioning[](#cuda_10_semantic_versioning)

CUDA Python 1.0 is not a rewrite and not a new product. Most of these libraries have been available and improving for a while. What changes with 1.0 is a commitment: semantic versioning.

In practice, that means:

• Breaking API changes happen only in major releases

• Minor releases add features

• Patch releases fix bugs

• Any public API scheduled for removal is deprecated first, in a minor release, with a clear replacement path

If you’ve hesitated to build on a library because you weren’t sure the API would survive the next upgrade, that guarantee is the headline. CUDA Python will keep tracking new CUDA capabilities as they ship, now under predictable versioning and deprecation rules.

One foundation instead of many[](#one_foundation_instead_of_many)

To see what 1.0 changes, it helps to remember what came before it.

Reaching CUDA from Python used to mean choosing a binding layer, and there were several. Each was maintained by a different project, each covered a different slice of the API, and each had its own idea of what a stream or a device or an allocation was. If you wrote applications, you inherited whichever layer your dependencies happened to use. If you wrote libraries, you either adopted someone else’s or built your own, and the ecosystem accumulated one more. That is the thing that changed.

There is now one official, NVIDIA-maintained way to reach CUDA from Python. As of CUDA 13.3, CUDA Python and C++ stand as equal first-class citizens, with NVIDIA committing to maintain feature-complete parity going forward. Python is a supported way to use the CUDA platform.

The practical payoff is that libraries now compose rather than merely coexist. A Numba kernel and a cuda.compute call can operate on the same GPU buffer in the same stream, because neither one brought a private CUDA layer along. Objects cross library boundaries because, underneath, they are the same objects. That is a shorter answer to the sharing question than any interchange protocol.

It also changes who gets to use advanced platform capabilities. A feature like green contexts, which partitions a GPU’s streaming multiprocessors so latency-sensitive kernels are shielded from throughput kernels, would previously have needed every interested library to bind and expose it independently. Now it lands in cuda.core once, and everything built on cuda.core can reach it.

If you build libraries that target CUDA, this is what changes your day-to-day: your effort goes into what makes your library distinctive rather than into a low-level layer someone else has already written. If you write applications, the benefit reaches you one level removed, as your dependencies converge on the same plumbing.

The mental model: Three tiers on one foundation[](#the_mental_model_three_tiers_on_one_foundation)

CUDA Python is a collection of libraries that together cover the CUDA ecosystem from Python: low-level driver and runtime bindings, parallel algorithms, math libraries, communication libraries, and kernel-authoring tools. Figure 1, below, shows how they stack up. The clearest way to read the image is from the bottom up.

Figure 1. The CUDA Python ecosystem: Kernel authoring sits on top, the CUDA libraries sit in the middle, and the runtime system is the shared foundation underneath both