# cuda-python: A Metapackage Split Into cuda.core, cuda.bindings and cuda.pathfinder

> NVIDIA's CUDA Python is being restructured into independently versioned subpackages. This is what the split means for the components you install, what cuda.bindings still covers, and where the documentation goes quiet.

**NVIDIA/cuda-python** — CUDA Python: Performance meets Productivity

- Repository: https://github.com/NVIDIA/cuda-python
- Website: https://nvidia.github.io/cuda-python/
- Stars: 3,389 · Forks: 331
- Language: Cython
- License: Apache-2.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/en/projects/nvidia-cuda-python

## What cuda-python replaces, and who it is written for

The project exists so that CUDA work can be done from Python rather than from C or C++. The README states the goals for cuda.core plainly: provide idiomatic access to the CUDA Driver, Runtime and JIT compiler toolchain, keep end-to-end CUDA development in Python, avoid homegrown abstractions for new Python GPU libraries, reduce the burden of tracking new CUDA features, and flatten the learning curve for current and future CUDA developers.

The audience is therefore not the person writing a first NumPy loop. It is someone who already has CUDA code or CUDA-shaped work and wants the driver, the runtime, the compiler toolchain and the math libraries reachable from a Python process. The README lists the components that make up that surface: cuda.core, cuda.bindings, cuda.pathfinder, cuda.compute, numba-cuda-mlir, numba.cuda, cuda.tile, nvmath-python, nvshmem4py, Nsight Python and CUPTI Python. That is a wide net, and it tells you the project is less one library than a collection of entry points into NVIDIA's stack.

## The metapackage restructuring and what each subpackage covers

The README describes cuda-python as being restructured into a metapackage containing a collection of subpackages, each versioned independently so that a component can be installed as needed. That is the single most consequential fact about the repository right now, because it changes what the name cuda-python refers to. The README also states that all previously available functionality from the cuda-python package will continue to be available, and points to the cuda.bindings documentation for the installation guide and further detail.

The two subpackages with the clearest scope are cuda.core and cuda.bindings. cuda.core is the Pythonic layer over the CUDA Driver, Runtime and JIT compiler toolchain. cuda.bindings is the opposite end: a standard set of low-level interfaces giving full coverage of and access to the CUDA host APIs from Python. The README enumerates them: CUDA Driver, CUDA Runtime, NVRTC, nvJitLink, NVVM, nvFatbin, cuFile and NVML. The third, cuda.pathfinder, is described as utilities for locating CUDA components installed in the user's Python environment. That is a narrow job, and it is the kind of job that is usually done badly by hand.

The practical split is between abstraction and fidelity. If you want to call cudaMalloc-style APIs and match the C documentation line for line, cuda.bindings is the layer. If you want the driver, runtime and JIT toolchain behind a Python-shaped interface, cuda.core is the layer. The README does not present these as interchangeable, and treating them as such is a common source of confusion.

## Installing the subpackages and a first real use

The README does not print an install command. It says the cuda.bindings documentation carries the installation guide and further detail, so the authoritative steps live at https://nvidia.github.io/cuda-python/cuda-bindings/latest rather than in the repository README. Because the project is now a metapackage, the package you install determines which components you get, and the README states that each subpackage is versioned independently.

The repository layout separates the subpackages into their own top-level directories, cuda_bindings/, cuda_core/ and cuda_pathfinder/, each with its own LICENSE file. That layout is the clearest signal of how the project expects to be consumed: as separate distributions rather than one monolithic import.

Before installing anything, check what your environment already resolves to, because the subpackages are versioned independently and the release history shows both a 12.x line and a 13.x line being published. The README does not document a version-selection flag, so confirm the resolved version with the package manager rather than assuming a default.

Once the packages are present, the first thing to verify is not a kernel. It is whether the bindings can find a CUDA installation at all, which is exactly the problem cuda.pathfinder exists to solve. The README describes it as utilities for locating CUDA components installed in the user's Python environment, so a reasonable first check is importing the bindings and confirming the driver and runtime interfaces resolve on your machine. The README does not print a smoke-test snippet, so the concrete call sequence has to come from the cuda.bindings documentation.

## Where the documentation is thin, and the cases where this is the wrong tool

The honest limitation is not performance. It is that the README is a component index, not a manual. It names eleven components and then delegates. Installation lives in the cuda.bindings docs. cuda.compute points at the CCCL documentation. cuda.tile points at docs.nvidia.com. nvmath-python points at its own overview. If you are evaluating cuda-python from the repository alone, you cannot tell from the README which Python versions are supported, which CUDA toolkit versions pair with which release, or what the migration path looks like for code written against the older single-package layout. The README is explicit that an overhaul is in progress and that previously available functionality remains available, but it does not describe a deprecation schedule, and it does not document rollback.

The second limitation is hardware. Everything here is CUDA, which means NVIDIA GPUs. If your target is a different accelerator vendor, or a CPU-only environment, none of these subpackages help you, and cuda.pathfinder's job of locating CUDA components in the Python environment has nothing to find. The README makes no claim of portability.

The third is the abstraction boundary. cuda.bindings is described as low-level and as providing full coverage of the CUDA host APIs. That fidelity is the point, and it is also the cost: code written against it will look like the C API wearing Python syntax. If what you actually wanted was array-level programming with implicit memory movement, cuda.bindings is the wrong layer and cuda.core or a higher-level library is the right one.

## cuda-python compared with CuPy and PyCUDA

The comparison people search for is cuda-python against CuPy and against PyCUDA, and the difference is architectural rather than a matter of speed. CuPy and PyCUDA are array-and-kernel frameworks: you work with device arrays and compiled kernels as the primary objects, and the framework owns memory management and launch. cuda-python's cuda.bindings is a binding layer, and the README is specific about what it binds: CUDA Driver, CUDA Runtime, NVRTC, nvJitLink, NVVM, nvFatbin, cuFile and NVML. That is a wider and lower surface than either array framework exposes, and it includes pieces like nvFatbin and cuFile that are not about arrays at all.

The consequence is that cuda-python does not make a decision for you about how kernels and memory should be modelled. cuda.core is where the project offers an opinion, described in the README as idiomatic access to the CUDA Driver, Runtime and JIT compiler toolchain. Above that, cuda.compute is listed as a module for access to CCCL's parallel algorithms such as sort, scan, reduce and transform, callable on the host. So the project spans three altitudes: bindings at the bottom, core in the middle, algorithm-level modules on top. CuPy and PyCUDA occupy roughly one altitude each. If you want a drop-in array library, cuda-python is not that. If you want the CUDA host API itself, reachable from Python, the bindings layer is the closer match.

## Licence, subpackage licensing and upgrade cost

cuda-python is licensed under Apache-2.0, and the README is unusually precise about how that applies across the split. Each subproject is distributed as its own package and ships a copy of the same licence alongside its sources, so the licence travels with the built wheel. The root LICENSE governs the repository as a whole. The README's table lists cuda.bindings, cuda.core, cuda.pathfinder and cuda-python each as Apache-2.0, with a LICENSE file inside each subdirectory. Third-party attributions for cuda.core are listed separately in cuda_core/NOTICE, which is worth reading if you redistribute the wheel rather than just depend on it. None of this is legal advice; the point is that the per-subpackage licence files exist and are the ones that accompany what you install.

Upgrade cost is the part the README does not settle. The subpackages are versioned independently, and the release history shows both a 12.x line and a 13.x line being published, which means a version bump in one component does not imply a matching bump in another. The README states the project is undergoing an overhaul and that existing functionality remains available, but it does not state how long the old layout stays supported. For a team, that argues for pinning the metapackage or the individual subpackages explicitly and treating a version change as a change to review, not a routine refresh.

## Conclusion

Adopt cuda-python if you are already on an NVIDIA GPU and want CUDA Driver, Runtime, NVRTC, nvJitLink, NVVM, nvFatbin, cuFile or NVML reachable from Python without writing C. Do not adopt it if you have no CUDA-capable hardware, if your target is a non-NVIDIA accelerator, or if you want a promise that the current import paths will not move: the README states the project is undergoing an overhaul, and the component list already spans cuda.core, cuda.bindings, cuda.pathfinder, cuda.compute, numba-cuda-mlir, numba.cuda, cuda.tile, nvmath-python, nvshmem4py, Nsight Python and CUPTI Python. Before committing, read the cuda.bindings documentation for the installation guide, confirm which subpackages your environment already has, and decide whether you are depending on cuda-python as a metapackage or on the individual subpackages directly.

## FAQ

### Is CUDA available in Python with cuda-python?

Yes. cuda-python is described in the README as the home for accessing NVIDIA's CUDA platform from Python, and it includes cuda.bindings, which the README says provides full coverage of and access to the CUDA host APIs from Python.

### How do I install cuda-python?

The README does not print an install command. It directs readers to the cuda.bindings documentation for the installation guide and further detail, and the project is structured as a metapackage whose subpackages can be installed individually.

### What is cuda-python?

It is a metapackage being restructured into independently versioned subpackages, including cuda.core for Pythonic access to the CUDA Driver, Runtime and JIT compiler toolchain, cuda.bindings for low-level host API bindings, and cuda.pathfinder for locating CUDA components in the Python environment.

### Is cuda-python the same as using CUDA from C++?

No. cuda.bindings is described as a set of low-level Python bindings to the CUDA host APIs, so it exposes the same APIs from Python rather than replacing them, while cuda.core offers an idiomatic Python layer over the Driver, Runtime and JIT toolchain.

### How do I use cuda-python?

The README does not show a usage example. It points to the cuda.bindings documentation for the installation guide and further detail, and lists the components that make up the project, from cuda.core and cuda.bindings through to numba.cuda, cuda.tile and nvmath-python.

## Sources

- [License: Apache-2.0](https://github.com/NVIDIA/cuda-python/blob/main/LICENSE)
- [NVIDIA/cuda-python on GitHub](https://github.com/NVIDIA/cuda-python)
- [Project website](https://nvidia.github.io/cuda-python/)
- [README](https://github.com/NVIDIA/cuda-python/blob/main/README.md)
- [Releases](https://github.com/NVIDIA/cuda-python/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/en/projects/nvidia-cuda-python