NVIDIA driver branches and CUDA versions for GPU servers: which driver to run, and why

Three kinds of driver branch

Since 2019 NVIDIA has run its data-centre GPU driver on an enterprise lifecycle with three kinds of branch, and the choice between them decides how often a server needs a new driver. A New Feature Branch is, in NVIDIA’s words, “targeted towards early adopters who want to evaluate new features (for example, new CUDA APIs)”: a new one arrives at least every three months, and NVIDIA’s lifecycle table promises it no fixed support period. A Production Branch is “qualified for use in production for enterprise/data center GPUs”: two arrive each year, and each receives bug and security releases quarterly, or as needed, for one year. A Long Term Support Branch is a production branch maintained for three years, and NVIDIA starts one at least once per hardware architecture.

These are not the software branches of NVIDIA AI Enterprise, which follow their own calendar with their own end dates; our licensing guide covers those.

Which branches are current

NVIDIA’s table of supported drivers and CUDA versions (updated 9 September 2026), its releases.json list and the release notes of each driver. R535 tops out at CUDA 12; the other listed branches reach CUDA 13 without a compatibility package.

R535 reached its end of life in June 2026, so hosts still on it are due for a change, and the same table shows R610 at end of life in August 2026. For a production server the choice is between R580, with the longest published life, and R595, which is newer and supported to March 2027. The release notes of both list the RTX PRO 6000 in all three editions, the RTX PRO 5000 in 48 and 72 GB, the RTX PRO 4500, 4000, 4000 SFF and 2000, the L40S, the L4 and the H200 NVL; the RTX PRO 5500 is not in either list yet. One difference we found: the RTX PRO 4500 Blackwell Server Edition appears in the product list of R595 and not in that of R580. Both branches are above driver 575.51.03, the floor NVIDIA’s MIG guide sets for MIG on the RTX PRO 6000 and 5000.

A New Feature Branch belongs on a test machine that needs a CUDA feature before it reaches a production branch. NVIDIA publishes no support period for it, and it is not a supported target for CUDA forward compatibility.

How CUDA compatibility works

Two parts meet at run time. The driver package contains the kernel modules and the user-mode CUDA driver, libcuda.so; the CUDA runtime and libraries come with the toolkit, and therefore with the application or its container. In NVIDIA’s words, new drivers “will always work with (applications compiled with) an older CUDA toolkit”, provided the application carries code the GPU can run. The CUDA number that nvidia-smi prints belongs to the driver: NVIDIA’s documentation now calls it the CUDA UMD Version, “the latest CUDA version supported by the driver”, usually but not always the same as the installed toolkit. Each CUDA minor release pairs with one driver branch: 13.0 with R580, 13.1 with R590, 13.2 with R595, 13.3 with R610 and 13.4 with R615. Since CUDA 13.4 the Linux driver is no longer bundled with the toolkit.

Minor version compatibility lets an application built with any 13.x toolkit run on driver 580 or newer, and a 12.x application on drivers from 525 to below 580, “with limited feature-set”; where the driver is newer than the toolkit, ordinary backward compatibility applies and these limits do not. NVIDIA names the limits: applications that compile device code to PTX “will not work on older drivers”, features that need the newer driver return cudaErrorCallRequiresNewerDriver, and the build has to name the real architecture, for example with nvcc -arch=sm_xx. A CUDA 13.4 application can therefore run on an R580 host if it carries compiled code for the GPU and avoids features that need the newer driver.

Forward compatibility goes further. The package, for example apt install cuda-compat-13-4, puts the newer driver libraries in a versioned directory, /usr/local/cuda-13.4/compat, which applications find through LD_LIBRARY_PATH. NVIDIA documents it only for “NVIDIA Data Center GPUs”, “Select NGC Server Ready SKUs of RTX cards” and Jetson boards, states that New Feature Branches are not supported targets, and CUDA returns error 804 on hardware that cannot use it. The H200 NVL, L40S and L4 qualify. For the RTX PRO workstation cards the guide names no qualifying SKU, so plan without it.

Compute capability and the first CUDA release for it

NVIDIA’s list of CUDA GPUs and its CUDA toolkit, driver and architecture matrix; release notes of CUDA 11.8 (Ada and Hopper), 12.8 (SM_120) and 12.9 (sm_121); NVIDIA product briefs; the MIG user guide; DGX Spark release notes, July 2026 release. NVIDIA released no CUDA 12.7 toolkit: its archive goes from 12.6 to 12.8, and its Xid catalog pairs CUDA 12.7 with driver R565. For Hopper the architecture matrix gives two entries, CUDA 11.8 and CUDA 12.0.

CUDA 13.0 removed offline compilation and library support for Maxwell, Pascal and Volta and, in NVIDIA’s words, “supports all NVIDIA architectures from Turing through Grace Blackwell”. None of the cards above is affected; a fleet that still runs Volta cards keeps a 12.x toolkit for them, and NVIDIA’s architecture matrix names R580 as the last driver branch for Maxwell, Pascal and Volta. The Blackwell rule matters more in practice. NVIDIA’s compatibility guide says binaries that include PTX “should work as-is on the Blackwell GPUs”, while binaries that carry only cubins for older architectures “need to be rebuilt”; PTX built for an architecture-specific target such as compute_90a is not supported on Blackwell either. Its test is to run the application with CUDA_FORCE_PTX_JIT=1, which ignores the embedded binary code and compiles the PTX instead: if the application runs properly that way, it is Blackwell compatible. Unset the variable afterwards.

Open kernel modules, and pinning the branch

NVIDIA has been explicit since July 2024: “For cutting-edge platforms such as NVIDIA Grace Hopper or NVIDIA Blackwell, you must use the open-source GPU kernel modules. The proprietary drivers are unsupported on these platforms.” The open modules work on any Turing or later GPU, NVIDIA recommended them for Ada and Hopper at the same time, and from R560 its installation methods in general install them by default. R615 completed the move for package installs: its release notes say “Package installation of the proprietary kernel module flavor is deprecated and starting in 615 is no longer provided”, and the installation guide of 23 September 2026 calls the open modules “the only kernel module flavor provided”.

On Ubuntu with NVIDIA’s repository the driver is apt install nvidia-open. Branch 590 changed the packaging: package names no longer carry the branch, and in NVIDIA’s words “the default experience will be to upgrade the system to the latest drivers”, with branch tracking an opt-in. An unpinned server on the renamed packages therefore moves to the newest branch in NVIDIA’s repository at its next upgrade, and in September 2026 the newest driver NVIDIA lists is 615.71.09, from a New Feature Branch. Install the pinning package for the branch before the driver, as NVIDIA suggests, for example nvidia-driver-pinning-580 for R580. NVIDIA adds that on Ubuntu, up to and including branch 580, the packages “still have the branch reference in the package name”, and that switching branches by installing, upgrading or downgrading driver packages is supported only on 590 and later.

Containers, vGPU and the DGX Spark

Containers. The driver lives on the host and the CUDA runtime in the image. The NVIDIA Container Toolkit expects the NVIDIA driver on the host, its runtime hook injects the GPU devices into each container, and NVIDIA’s own test runs nvidia-smi inside a plain Ubuntu image. The image therefore decides the CUDA version. NVIDIA’s PyTorch container 26.08 is based on CUDA 13.4.1, newer than the 13.0 and 13.2 that R580 and R595 pair with, so on those hosts it relies on the compatibility mechanisms above; NVIDIA’s compatibility FAQ says both work with its framework containers and with images built on its official CUDA base images.

vGPU. On a virtualisation host the driver comes from the vGPU software release instead, and each release pairs a vGPU Manager for the host with guest drivers: vGPU 19.6, on R580, pairs Manager 580.178.05 with the Linux guest driver 580.178.04 and the Windows driver 582.78; vGPU 20.2, on R595, pairs 595.91.04 with 595.91.07 and 596.86. A Manager from a later branch accepts guest drivers from the previous branch, but with a guest driver from a later branch than its own “the NVIDIA vGPU fails to load”, so the host goes first. The release also decides the cards: vGPU starts with 19.0 on the RTX PRO 6000 Server Edition, 20.0 on the RTX PRO 4500 Server Edition and 20.2 on the RTX PRO 5000 72 GB, which NVIDIA supports on Red Hat Enterprise Linux with KVM 9.6 only.

DGX Spark. The Spark does not appear in the data-centre driver release notes we read. DGX OS brings its own stack, in the July 2026 release driver 580.159.03 with CUDA 13.0.2, and NVIDIA calls the DGX Dashboard “the primary and recommended way to perform system updates”. Our DGX Spark day-one guide shows where to find it.

A checklist for the next driver update

Read the notes of the exact version. Confirm that every card in the server is in its product list, and read the known issues.

Check the images against the driver. List the CUDA version of every container image and compare it with the CUDA UMD version the new driver reports. An image newer than the driver relies on minor version compatibility or, on data-centre GPUs, on forward compatibility.

Pin before you install. On Ubuntu, install the pinning package for the branch before the driver, so that a routine upgrade cannot move the server to another branch.

Keep the open modules. On Blackwell they are the only supported choice, and from R615 they are the only flavour NVIDIA packages.

Update vGPU hosts first. Take the vGPU Manager and the guest drivers from the same vGPU release, and install the host before the guests.

Re-apply what a driver reload clears. NVIDIA’s H200 NVL brief says a power cap set with nvidia-smi “must be reestablished after each new driver load”; only the out-of-band SMBPBI setting persists. On RTX PRO cards in MIG mode, confirm the instance layout before the GPUs go back into service, as our MIG guide describes.

Watch the first days. Check that DCGM still sees every GPU and that no new XID messages appear in the kernel log; our monitoring guide lists the ones that matter.

What we supply

Eurokommerz supplies RTX PRO Blackwell cards from the RTX PRO 2000 to the RTX PRO 6000 Workstation Edition and Max-Q, as well as the L4, L40S and H200 NVL, EU-wide with manufacturer warranty. AI servers built to order can arrive with the operating system, the driver branch, CUDA and the container runtime of your choice installed on request. Tell us the cards and the containers, and we will name the branch before the order.

FAQ