CUDA Toolkit vs NVIDIA Driver Explained
Understand what the host driver, CUDA toolkit, runtime libraries, and framework packages each do.
By Hostnot GPU ·
Three different version numbers can all be correct on the same GPU machine: the NVIDIA driver version, the installed CUDA compiler version, and the CUDA version used to build your framework. Understanding their boundaries prevents unnecessary reinstalls and makes compatibility failures easier to locate.
Which component owns what?
- NVIDIA host driver: kernel modules and user-space driver components expose the physical GPU. The driver must support the GPU generation and operating system.
- CUDA Toolkit: development tools including
nvcc, headers, libraries, and debugging tools. You usually need it to compile CUDA source or certain custom extensions, not merely to import a prebuilt GPU wheel. - Application runtime: libraries used by a framework, often packaged in a wheel's dependencies or container. They are not necessarily the libraries under
/usr/local/cuda. - NVIDIA Container Toolkit: container integration that exposes allowed devices and driver components. Despite its name, it is not the CUDA compiler toolkit.
Read the versions without changing them
On a Linux NVIDIA environment, run each applicable check in the same environment that runs your application. The Python line requires an existing PyTorch installation.
nvidia-smi
command -v nvcc
nvcc --version
python -c 'import torch; print("torch:", torch.__version__); print("build CUDA:", torch.version.cuda); print("available:", torch.cuda.is_available())'
If nvcc is absent, skip its version command. That alone does not make a runtime-only image broken. The CUDA version displayed by nvidia-smi describes driver-side CUDA support, not an inventory of installed toolkits. torch.version.cuda reports the framework build's CUDA version, while a None value commonly indicates a CPU build. Availability still needs a real device operation to verify execution.
Apply compatibility in the right direction
A newer supported driver generally runs applications built with older CUDA toolkits. The reverse is conditional: NVIDIA's minor-version compatibility rules have minimum driver requirements and feature limitations within a CUDA major family. PTX JIT compilation and features introduced with a newer driver can require more than that minimum. Consult the exact framework wheel or image release notes as well as NVIDIA's compatibility table; comparing only two displayed major numbers is insufficient.
Forward-compatibility packages are a separate, constrained mechanism with supported hardware and deployment requirements. They are not a generic fix for every old driver. Nor can a new driver add machine-code support missing from an old framework build for a new GPU architecture.
Match the symptom to the layer
- Driver/library version mismatch in NVML: host kernel and user-space driver packages may differ after an update. Escalate to the host owner.
- No kernel image available / invalid device function: check GPU compute capability against the framework or extension's compiled architectures.
- Unsupported PTX version: inspect the compiler and driver combination used by the failing extension.
- CUDA unavailable only in a container: check GPU allocation and container runtime setup before changing host packages.
- Undefined symbol on import: investigate incompatible Python/native dependencies or library search-path contamination in a fresh environment.
Choose the smallest correction
Use a framework build supported by the existing host when possible. Install a compiler only for a documented build requirement. Never copy random libcuda.so files into a project or add toolkit stub-library directories to the runtime search path. On managed infrastructure, request a supported image or owner-managed driver update. Version changes are not a guaranteed speedup; compare the same workload after a small smoke test. Record the package lock and image digest so you do not pay to reconstruct the environment on every rental.
Continue with PyTorch verification, Docker setup, or the driver maintenance procedure.