Symptoms
A job can detect GPUs (nvidia-smi succeeds) and still fail when Python or the application loads a toolkit library:
libcudnn, libcublas, or libnccl when those libraries aren’t in the image.
This is a different problem from choosing an image whose CUDA version is newer than the node driver. For details, see Match the CUDA version to your GPU driver.
Confirm what the node injected
Inside the container, list the driver mounts and the CUDA libraries on the library path:libcuda.so are present when the node injected the driver. Missing libcusparseLt, libcudnn, or similar files means the image doesn’t include the toolkit.
GB200, GH200, and GB300 compute nodes are aarch64, because they use NVIDIA Grace CPUs. The login node on those clusters is typically x86_64, so packages installed from the login node can be built for the wrong architecture. Compare uname -m on the login node and inside a compute allocation, then install Python packages from the compute allocation so the wheels match the GPU nodes.
Use an image that includes the toolkit
Replace[TAG] with a tag from the image registry, and replace [GPU-PARTITION] with a GPU partition on your cluster.
ghcr.io#coreweave/ml-containers/torch-extras:[TAG]. For details, see ML container images.
If you install PyTorch and CUDA libraries into a virtual environment on shared storage instead of using a container, create that environment on a GPU compute node:
Related
- ML container images
- How do I run containers with Pyxis and Enroot in Slurm?
- Install software as containers using Pyxis and enroot
Workload Scheduling