Require only CUDA wheels (no system CTK) in pip packages

[bdice]

Installing RAPIDS via pip should work with only CUDA wheels, with no requirement for a system CUDA Toolkit (only a driver).

Benefits:

• This would allow us to shrink our citestwheel CI image significantly.
• Users would use a single, consistent CTK source for all libraries adjacent to RAPIDS

Work tracked in #35, #137 added support for using CUDA wheels for math libraries. I think we already statically link the runtime in all our wheel builds, which is discussed in #4.

The action items I know of are primarily in RAPIDS dependencies, including cupy and numba-cuda:

• Allow using CUDA libraries installed from pip wheels cupy/cupy#8013
• [FEA] Support for loading NVRTC from a wheel NVIDIA/numba-cuda#66
• [FEA] Support for loading NVVM from a wheel NVIDIA/numba-cuda#65

This issue should be used to track those items and any other dependencies.

[bdice]

I measured the size of a base Ubuntu image with CUDA wheels installed. It is about 3.7GB (compressed) when installing all CUDA wheels on top of Ubuntu 24.04.

For comparison, nvidia/cuda:12.8.0-devel-ubuntu24.04 is 4.83 GB compressed.

There are minor space savings here (23%). I haven't checked what components are different between the two images.

The longer-term benefit for using only CUDA wheels is for people who just want pip install to work on any image. In that future, we can use a base flavor of nvidia/cuda (tiny! <100 MB!) and get everything else in the CUDA Toolkit via pip. Specifically, we won't have to pay for downloading components that we don't depend on in RAPIDS.

Reproduction commands

Save this as Dockerfile in a directory:

FROM ubuntu:24.04
# Update packages and install Python3, pip, and venv
RUN apt-get update && apt-get install -y python3 python3-pip python3-venv
# Create a virtual environment
RUN python3 -m venv /venv
# Activate the virtual environment by updating PATH
ENV PATH="/venv/bin:$PATH"
# Install the NVIDIA dependencies inside the virtual environment
RUN pip install \
    nvidia-cublas-cu12 \
    nvidia-cuda-cccl-cu12 \
    nvidia-cuda-cupti-cu12 \
    nvidia-cuda-cuxxfilt-cu12 \
    nvidia-cuda-nvcc-cu12 \
    nvidia-cuda-nvrtc-cu12 \
    nvidia-cuda-opencl-cu12 \
    nvidia-cuda-profiler-api-cu12 \
    nvidia-cuda-runtime-cu12 \
    nvidia-cuda-sanitizer-api-cu12 \
    nvidia-cufft-cu12 \
    nvidia-curand-cu12 \
    nvidia-cusolver-cu12 \
    nvidia-cusparse-cu12 \
    nvidia-npp-cu12 \
    nvidia-nvfatbin-cu12 \
    nvidia-nvjitlink-cu12 \
    nvidia-nvjpeg-cu12 \
    nvidia-nvml-dev-cu12 \
    nvidia-nvtx-cu12
CMD ["bash"]

Inside that directory, run the following:

docker build -t ubuntu-cuda-pip .
docker save ubuntu-cuda-pip | gzip > ubuntu-cuda-pip.tar.gz
ls -alh ubuntu-cuda-pip.tar.gz

Total size: 3.7G

[gforsyth]

I tried this out last month -- we're close but also annoyingly far away.

All of our rapids dependencies are easy to pip install -- that part just works (when building locally).

The issue we have using cuda-base in CI is that the nv-gha-runners/get-pr-info action that runs in all our CI jobs requires that git is installed, and it is not installed on cuda-base. And the get-pr-info action runs before we have an opportunity to bootstrap anything else into the image.

So we would need to either:

1. get git installed on cuda-base (easy in practice, possibly difficult administratively)
2. build and maintain an image that is cuda-base + git (easy in practice, a pain in terms of security scans, policy, etc)
3. update get-pr-info so it can bootstrap install git into a given container if it isn't installed (not sure about the viability of this)

edit: I was misremembering what this issue was -- get-pr-info has nothing to do with this, and I don't think the concerns I listed above apply.

One other issue raised by @vyasr (rapidsai/ci-imgs#400 (comment)) is that this switch will preclude us testing with cupy<14 and we need to decide if we're good with that.

[bdice]

#279 is now complete and we now require cupy >=14, so depending on CUDA wheels may be viable now. We should test this again.