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

Driver branch types: New Feature, Production and Long Term Support

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.

Current driver branches and their end-of-life dates

NVIDIA’s table of supported drivers and CUDA versions (updated 4 November 2026; the R535 row from its version of 9 September 2026), its releases.json list, read on 23 October 2026, and the release notes of each driver, among them those of 620.70.06 of 4 November 2026. 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. Since its update of 4 November 2026 NVIDIA’s table lists only Long Term Support and Production branches, because “New Feature Branches are short-lived and do not have an end-of-life date”, so R610 and R615 no longer appear in it. NVIDIA’s security bulletin of 30 September 2026 fixes R580 in 580.178.04 and R595 in 595.91.07, as well as the New Feature Branches R610 in 610.57.04 and R615 in 615.71.09. It lists no R535 driver, so hosts still on R535 are due for a change. The drivers released from 19 to 22 October 2026 are later versions of these branches, and their release notes add no security section. For a production server the choice is now between three branches: R620, the newest Long Term Support Branch and the one with the longest published life, to September 2029; R580, supported to June 2028; and R595, the Production Branch, supported to March 2027. The October 2026 release notes of R580 and R595 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. Among these cards, the one difference we found is the RTX PRO 4500 Blackwell Server Edition, which appears in the product list of R595 and not in that of R580. The notes of 620.70.06 list every card named here, the RTX PRO 4500 Blackwell Server Edition included, and they are the first data-centre driver notes to list the RTX PRO 5500 Blackwell Workstation Edition; for the RTX PRO 4500 Server Edition, R620 is therefore an alternative to R595 on bare metal, while under vGPU the card still needs vGPU 20 on R595. All three branches are above the driver floors that NVIDIA’s MIG user guide (updated 4 November 2026) sets for MIG: 575.51.03 on the RTX PRO 6000, 575.57.08 on the RTX PRO 5000 and 575.64 on the RTX PRO 4500.

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.

AI servers we build to order can ship with R580 or R595 already installed. Tell us the branch your production hosts run, and the new server arrives on the same one.

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, 13.4 with R615 and 13.5 with R620. CUDA 13.5 (November 2026, driver branch R620; 13.x applications run on R580 or newer through minor version compatibility) is the newest toolkit; its release notes deprecate Debian 12 and openSUSE Leap 15.6, which the next release drops. 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. The guide names no qualifying RTX SKU, so plan the RTX PRO workstation cards without it, and test it on the delivered server before relying on it with the RTX PRO 6000 Server Edition.

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 (updated 4 November 2026); DGX Spark release notes, October 2026 release (updated 21 October 2026). 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. For the cards in this article, the Blackwell rule matters more. 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 as of 5 November 2026 the newest branch NVIDIA lists is the Long Term Support Branch R620, with driver 620.70.06 of 4 November 2026. 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 is installed on the host, and the CUDA runtime comes with 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 containers 26.08 and 26.09 are based on CUDA 13.4.1, newer than the 13.0 and 13.2 that R580 and R595 pair with, so on those hosts they rely on the compatibility mechanisms above. NVIDIA’s compatibility FAQ says both mechanisms 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 Manager 595.91.04 with the Linux guest driver 595.91.07 and the Windows driver 596.86. Both releases fix CVE-2026-47489 from NVIDIA’s security bulletin of 30 September 2026. 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 vGPU release also determines which cards are supported. 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. NVIDIA has no vGPU release on R620 yet (5 November 2026), so a vGPU host stays on R580 or R595.

If you run the cards through vGPU, we supply the vGPU and NVIDIA AI Enterprise licences on the same invoice as the hardware. Describe the hypervisor and the vGPU profiles in the form below, and we tell you which licences the setup needs.

DGX Spark. The Spark does not appear in the data-centre driver release notes we read. DGX OS brings its own stack. Its October 2026 release, in release notes updated on 21 October 2026, brings DGX OS 7.6.0 with driver 580.178.04, the R580 version named in NVIDIA’s security bulletin of 30 September 2026, CUDA 13.0.3 and the Linux 7.0 kernel, and supports both 64 GB and 128 GB systems. NVIDIA states these versions for the Founders Edition and notes that partner systems may update later. NVIDIA calls the DGX Dashboard “the primary and recommended way to perform system updates”, and 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 and NVIDIA’s latest security bulletin. NVIDIA has published its security bulletins on GitHub (NVIDIA/product-security) since 1 October 2026; as of 5 November 2026 its newest GPU display driver bulletin is that of 30 September 2026, updated on 13 October. 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. The drivers of 21 and 22 October 2026, 580.196.07 and 595.112.07, fix a rare driver-side cause of XID 79 on hosts that call nvidia-smi -q at high frequency, and a GPU utilisation reading stuck at 100 per cent after CUDA jobs ended with SIGINT; monitoring that polls nvidia-smi is a reason to install them.

What we supply

We supply the L4, L40S and H200 NVL, the RTX PRO Blackwell workstation cards from the RTX PRO 2000 upwards, and the RTX PRO 6000 in all three editions (Workstation, Max-Q and Server Edition), EU-wide with manufacturer warranty, on one EU contract and invoice. For AI servers built to order, we install the operating system, drivers, CUDA and a container runtime on request, so the server arrives ready for your team.

FAQ