{"slug": "cuda-python-1-0-stable-apis-one-foundation-full-platform-access", "title": "CUDA Python 1.0: Stable APIs, One Foundation, Full Platform Access", "summary": "NVIDIA released CUDA Python 1.0 with CUDA 13.3, making Python a supported, first-class way to use the CUDA platform, with components including cuda.core 1.0.0, cuda.compute 1.0.0, cuda.bindings 13.3.0, cuda-pathfinder, and nvmath-python 1.0, all under semantic versioning to ensure stable APIs. This provides a common foundation for GPU libraries in Python, enabling them to compose and share resources more easily.", "body_md": "For years, a Python developer who needed a GPU had two realistic choices: Learn NVIDIA CUDA C++ well enough to write an extension, set up a build toolchain, and maintain bindings back to Python, which most people never did; or move up the stack and let someone else’s library do it, namely PyTorch, CuPy, or RAPIDS.\n\nThe 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.\n\nBecause 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.\n\nWith 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.\n\nHere is what lands together:\n\n`cuda.core`\n\n1.0.0, Pythonic access to the CUDA runtime`cuda.compute`\n\n1.0.0, CCCL’s parallel algorithms, callable from Python`cuda.bindings`\n\n13.3.0, low-level 1:1 bindings to the CUDA C APIs, versioned to the CUDA Toolkit`cuda-pathfinder`\n\n, which locates the CUDA components installed in your environment`nvmath-python`\n\n1.0, NVIDIA’s math libraries in Python, under the same kind of stability commitment on its own release track\n\nCUDA Python 1.0 names a milestone, not a version number you will type into `pip`\n\n; the components are versioned independently, so the mismatched numbers above are deliberate.\n\nThe most consequential entry is `cuda.core`\n\n. 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.\n\n## CUDA 1.0: Semantic versioning\n\nCUDA 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*.\n\nIn practice, that means:\n\n- Breaking API changes happen only in major releases\n- Minor releases add features\n- Patch releases fix bugs\n- Any public API scheduled for removal is deprecated first, in a minor release, with a clear replacement path\n\nIf 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.\n\n## One foundation instead of many\n\nTo see what 1.0 changes, it helps to remember what came before it.\n\nReaching 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.\n\nThere 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.\n\nThe practical payoff is that libraries now compose rather than merely coexist. A Numba kernel and a `cuda.compute`\n\ncall 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.\n\nIt 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`\n\nonce, and everything built on `cuda.core`\n\ncan reach it.\n\nIf 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.\n\n## The mental model: Three tiers on one foundation\n\nCUDA 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.\n\nThe runtime system is the foundation every other box rests on: device management, memory allocation, streams and synchronization, CUDA graphs, and JIT compilation.\n\n`cuda-pathfinder`\n\nsounds mundane until you remember how much time the Python GPU community has spent debugging which CUDA runtime a process really loaded.\n\nAbove that sit the CUDA libraries: Pythonic interfaces to the NVIDIA tuned host and device libraries. `cuda.compute`\n\nbrings CCCL’s host-callable parallel algorithms; `nvmath-python`\n\n, also now at 1.0, brings the math libraries, with host APIs, device APIs, and low-level bindings; and NCCL4Py and NVSHMEM4P bring the communication libraries, NCCL and NVSHMEM.\n\nNone of them reimplements the CUDA layer underneath. They work in the same `cuda.core`\n\nbuffers, devices, and streams you would use directly, so NVSHMEM’s symmetric memory, for instance, comes back to you as a `cuda.core`\n\nbuffer. The shared foundation is not just guidance for the ecosystem; NVIDIA’s own libraries are built on it.\n\nAt the top is kernel authoring, for when you want to write the GPU code yourself. `numba-cuda`\n\nis the SIMT language for Python kernels, and alongside it sit two newer domain-specific languages: `cutile-python`\n\n, a CUDA tile language for the block model, and `cuteDSL`\n\n, a CUTLASS language for Tensor Cores.\n\nTwo things worth clarifying:\n\nFirst, you enter at the tier your problem requires, and you never have to learn the whole thing. Plenty of productive users never leave the library tier. Nothing about the diagram is a curriculum.\n\nSecond, the tiers are not a single versioned product. Each component moves on its own track, and a few pieces, including some of the newer kernel-authoring languages, are still experimental and not yet covered by the 1.0 semantic-versioning guarantees, though the intent is for them to come under the same commitments as they stabilize. That is worth knowing before you pin a production dependency on one.\n\n## Three ways in\n\nAlmost everyone arrives at CUDA Python with one of three questions, and each one points at a different tier of the diagram. Here they are, ordered by how much you take on rather than by where they sit in the diagram.\n\n### I just want optimized algorithms: `cuda.compute`\n\nThe fastest win is usually not writing a kernel at all. It is calling one that already exists and has been tuned by people who do that full time.\n\n`cuda.compute`\n\nbrings the CUDA Core Compute Libraries (CCCL) parallel algorithms to Python as host-callable building blocks: sort, scan, reduce, transform, unique, histogram, top-k, and more. These are the same algorithms that back high-performance C++ CUDA code, and from Python they are ordinary function calls on GPU arrays you already have. A large share of numerical work turns out to be a composition of these patterns. Because `cuda.compute`\n\ncompiles them for the GPU you are actually running on, the same call works unchanged on the next generation of hardware.\n\nVersion 1.0 also makes them more expressive: you can now customize what an algorithm does with ordinary Python functions, including lambdas.\n\n**Reach for this when**: your problem decomposes into well-known parallel patterns and you want results with the least new code.\n\n### I want to write my own kernel in Python: Numba\n\nSometimes your logic does not match a prepackaged algorithm. In that case, you write the kernel yourself, and you can still do it in Python.\n\nNumba compiles a subset of Python into GPU kernels: you mark a function with a decorator, and Numba generates GPU code from it. What you are writing is a kernel in the CUDA SIMT model, expressing the work of a single thread that the GPU then runs across many thousands at once. Making that mental shift is the main thing to learn, and it is a far smaller step than picking up C++ and a build system.\n\nNumba CUDA MLIR is a new Numba-compatible kernel generator built on MLIR and the modern NVVM toolchain. It keeps the programming model you already know and replaces the compiler underneath, delivering faster warm JIT compiles and lower kernel-launch latency; for most code, moving to it is a one-line import change. It is newer than the 1.0 components, and not yet covered by the same semantic-versioning commitment.\n\n**Reach for this when**: your computation does not fit a prepackaged algorithm and you want direct control over what each thread does.\n\n### I need the driver and runtime APIs: `cuda.core`\n\n, `cuda.bindings`\n\nAt the foundation sit two packages that hand you CUDA itself, and `cuda.core`\n\nreaching 1.0 is the centerpiece of this release.\n\n`cuda.core`\n\nis a Pythonic interface to the CUDA runtime, covering devices, streams, programs, linkers, memory resources, and graphs, along with runtime compilation of CUDA C++ so a kernel can go from source to running without a separate build step. The emphasis belongs on *Pythonic*: resources are real Python objects and failures raise exceptions rather than returning error codes. Because it uses a standard CUDA context, it shares devices, streams, and memory with the rest of the Python GPU ecosystem, so your own kernels can run against CuPy arrays or PyTorch tensors without copying data.\n\nVersion 1.0 consolidates APIs that had been stabilizing over previous release cycles into a single supported surface, and adds three capabilities worth calling out:\n\n**Green contexts**: Partition a GPU’s SMs into disjoint groups, as described earlier, so latency-sensitive kernels stay shielded from long-running throughput kernels in the same process.**Process checkpointing**: Snapshot the full CUDA state of a running process and restore it later.** Inter-process sharing (IPC)**: Share GPU memory between processes without copying through the host.\n\nBeneath it, `cuda.bindings`\n\nprovides low-level bindings with full, 1:1 coverage of the CUDA host APIs, from the Driver and Runtime through the compiler, linker, and system libraries around them. It is versioned to the CUDA Toolkit. Where `cuda.core`\n\noptimizes for Python ergonomics, `cuda.bindings`\n\noptimizes for completeness: if it exists in the C API, you can reach it from Python.\n\n**Reach for this when**: you are building a GPU library or integrating CUDA into an existing toolkit. Use`cuda.core`\n\nfor Pythonic productivity and`cuda.bindings`\n\nwhen you need exhaustive access to the C APIs.\n\n## The ecosystem is already converging\n\nThe best evidence that a shared foundation works is who’s already building on it. The NVIDIA communications and math libraries already all speak in `cuda.core`\n\nobjects, as described earlier. The wider ecosystem is converging too. CuPy gets a simpler build and a faster, smaller footprint when importing the module. PyTorch now depends on `cuda.bindings`\n\nin its CUDA wheels.\n\nEach library that moves onto the shared layer takes one more private binding layer out of your dependency graph. That is fewer version conflicts, fewer mysterious interop bugs, and fewer places for two libraries to disagree about which CUDA context they are in.\n\nAnd because each component follows semantic versioning on its own track, taking a dependency on one of them doesn’t mean inheriting churn from the rest.\n\n## Getting started\n\nOne command gets you the CUDA Python stack:\n\n```\npip install cuda-python cuda-cccl numba-cuda-mlir[cu13]\n```\n\nThat covers the CUDA Python components above, plus the MLIR-based Numba backend. Install `nvmath-python`\n\nseparately with `pip install nvmath-python[cu13]`\n\n. The only system requirement is an up-to-date NVIDIA driver; a separate CUDA Toolkit installation is generally not required.\n\nIf you are deciding where to begin:\n\n- If your work is data science, you may not need to reach this low at all. The RAPIDS libraries already cover that ground: cuDF accelerates pandas, Polars, and Apache Spark, and nx-cugraph backs NetworkX\n- For optimized algorithms, start with\n`cuda.compute`\n\n- To write your own kernels in Python, start with Numba or Numba CUDA MLIR\n- To reach the low-level driver and runtime APIs, start with\n`cuda.core`\n\nand`cuda.bindings`\n\nFrom there, the [CUDA Python documentation](https://nvidia.github.io/cuda-python/latest/) and the [NVIDIA/cuda-python repository](https://github.com/NVIDIA/cuda-python) have installation guides, API references, and examples, and the [NVIDIA Accelerated Computing Hub](https://github.com/NVIDIA/accelerated-computing-hub) collects broader GPU-computing learning material.\n\nThe best part of the 1.0 milestone is that this decision is no longer high-stakes. Pick the tier that matches the problem in front of you, and know that the ground under it is stable.\n\n*Acknowledgments*\n\n*CUDA Python 1.0 reflects years of work by the CUDA Python product and engineering teams, who designed and built the libraries described here. Thanks as well to the reviewers across NVIDIA whose feedback sharpened both the release and this post, and to the open source contributors who filed issues, tested prereleases, and helped shape the APIs we are now committing to support.*", "url": "https://wpnews.pro/news/cuda-python-1-0-stable-apis-one-foundation-full-platform-access", "canonical_source": "https://developer.nvidia.com/blog/cuda-python-1-0-stable-apis-one-foundation-full-platform-access/", "published_at": "2026-08-25 15:00:00+00:00", "updated_at": "2026-08-25 15:15:37.769633+00:00", "lang": "en", "topics": ["developer-tools", "ai-infrastructure", "artificial-intelligence"], "entities": ["NVIDIA", "CUDA Python", "cuda.core", "cuda.compute", "cuda.bindings", "cuda-pathfinder", "nvmath-python", "CUDA 13.3"], "alternates": {"html": "https://wpnews.pro/news/cuda-python-1-0-stable-apis-one-foundation-full-platform-access", "markdown": "https://wpnews.pro/news/cuda-python-1-0-stable-apis-one-foundation-full-platform-access.md", "text": "https://wpnews.pro/news/cuda-python-1-0-stable-apis-one-foundation-full-platform-access.txt", "jsonld": "https://wpnews.pro/news/cuda-python-1-0-stable-apis-one-foundation-full-platform-access.jsonld"}}