feat(deps): raise `cupy` lower bound to `>=14`

[gforsyth]

The current lower bound for cupy across RAPIDS projects is 13.6.0. What is the appetite for us bumping that lower-bound to >=14?

In 14.0.0, cupy added a ctk install extra, that handles installing all the required cuda-toolkit packages from PyPI. If we bump the lower-bound, it becomes (more) possible for users to have a single install command that leaves them with a fully-formed installation (not missing required cuda-toolkit shared objects).

For wheel-based ci tests, raising the lower-bound of cupy would also allow us to swap the base image for our citestwheel from cuda-devel-* to cuda-base-*. We currently use the devel as the base image because we need to bundle the shared objects that can now be installed using the ctk extra in cupy.

If we can swap the base image, it would help with CI spin-up times -- currently, the citestwheel images are on the order of around 11GB. Switching to base reduces the image size to ~420MB . This saving in image size IS slightly offset by the size of the ctk extra downloads, but it is still a smaller amount of data to transfer, and not every RAPIDS project will end up pulling cupy[ctk].

The downsides I can think of are:

1. For users who already have a local CTK installed, if cupy-cuda12x[ctk] is a dependency of, say, cudf, they'll download an additional copy of some pretty hefty libraries.
2. If there are users who are constrained to cupy<14 for some reason, they won't be able to use newer versions of RAPIDS

I believe the current projects with direct cupy runtime dependencies (so the projects that might incur the "extra CTK download" penalty) are:

• cucim
• cudf
• cugraph-pyg
• cugraph
• cuml
• cuopt
• cuxfilter
• kvikio
• nvforest
• nx-cugraph
• rapidsmpf

Libraries that depend directly on cupy for tests:

• cuvs
• raft
• rmm
• ucxx

[bdice]

I have no concerns other than potentially needing to check on NumPy 1.x support:

• whether NumPy 1.x support is changing if we bump the minimum CuPy
• whether that still matters or not

See also: https://medium.com/cupy-team/announcing-cupy-v14-numpy-v2-semantics-bfloat16-cuda-pip-wheels-support-and-more-e8515ec05fca

[jakirkham]

@jameslamb would be interested in your take on this as you have been involved both with recent CuPy pinnings updates and the CTK wheels. In particular does the change seem reasonable? And is this something we could pick up in RAPIDS 26.08?

[vyasr]

We discussed this on a few threads on Slack. To the extent that it matters, none of the cloud platforms that we support has moved to cupy 14 yet.

[jakirkham]

We should recheck that. AFAICT most if not all are on CuPy 14. Added you to a thread.

[bdice]

I discussed this today with @ncclementi and @jayavenkatesh19 and got input from library PICs. It sounds like we should be clear to move forward, there are no clear blockers on the cloud platform side.

@caryr35 is going to draft an RSN. Here is what I recommend using for that RSN:

Title: RAPIDS 26.08 will require CuPy 14 and NumPy 2

Overview:

RAPIDS will require CuPy version 14.0.1 or newer in the 26.08 release.

This simplifies RAPIDS installation, because CuPy 14 can now be used without installing a system-wide CUDA Toolkit. Users can rely on CUDA components provided via PyPI. Only the CUDA driver needs to be pre-installed. See the CuPy 14 release blog for more information.

This requirement also means that RAPIDS will require NumPy 2, because of CuPy 14's requirements.

Impact:

User environments will need to be compatible with NumPy 2 and CuPy 14 for RAPIDS 26.08 and later.