No single NVIDIA driver is best for AI work on an RTX 3090. The driver is one layer of a stack that also includes the CUDA toolkit, the framework build and the framework’s defaults, and the speed you see belongs to that whole combination. Our rule of thumb: run the lowest-risk driver that meets your CUDA toolkit’s minimum version, pin it, and judge any change by measuring on your own card, not by reading release notes.
That answer disappoints people who want a version number, so it helps to see where the driver sits. NVIDIA’s documentation describes the driver as something like the operating system of the GPU, needed for every use of the card, and the CUDA Toolkit as a separate product with its own versions. A driver choice is therefore made against a toolkit and a framework, never in isolation.
Why the best NVIDIA driver for AI depends on the rest of the stack
LynxBenchAI measures performance at the level of the AI Executor: a device plus the software stack that drives it. Every result is bound to the backend it ran through (cuda on NVIDIA) and to the driver, framework and runtime installed on that machine. We hold that position because real performance depends on how well the software targets the hardware.
The outside evidence points the same way. A 2023 comparative study of deep learning efficiency on an NVIDIA Tesla T4 found that TensorFlow’s kernel fusion gave 15% lower inference latency than PyTorch on the same hardware, and concluded that efficiency is as much a product of software engineering as of hardware design. The xPU-athalon study (2026) found, where immature software held back AI accelerators, that real performance depends on how well compilers, runtimes and kernel libraries target the hardware. MLPerf’s submission rules define a software stack as the components that “substantially determine ML performance”, naming at a minimum the ML framework and the accelerator library, such as cuDNN.
None of this means one framework wins everywhere. The kernel-fusion result compared TensorFlow and PyTorch on Tesla T4 GPUs. What carries over is the method: an RTX 3090 with one driver and framework build is a different executor from the same card with another, and should be measured as one.
Game Ready, Studio, Production Branch or New Feature Branch for AI on a 3090?
The honest answer to the branch question is a stability judgement, not a performance verdict.
On Game Ready versus Studio, a third-party explainer describes the two as sharing the same underlying driver platform and core features, CUDA support included. The difference it describes is in priorities. Game Ready drivers are released quickly for new games, while Studio drivers go through longer validation against creative applications. The same source calls the idea that Game Ready is “faster” and Studio “slower” too simplistic: for the same GPU and application, benchmark differences are often small unless a specific driver carries a targeted fix. Treat that as one publisher’s account, not vendor guidance. The practical reading still holds, though. Neither branch is a speed setting, so test before assuming either one makes your workload faster.
The Production Branch versus New Feature Branch choice is likewise a judgement call. On a machine that trains for days, we would take the more conservative track and move only when a toolkit or framework you need demands a newer driver, because a driver change then has a reason you can test against.
How the installed driver limits your CUDA toolkit and PyTorch build
The driver sets a floor for the CUDA toolkits you can run, and NVIDIA publishes that floor per major version. From CUDA 11 onwards, an application built with any toolkit inside a major release family runs, with a limited feature set, on a driver at or above that family’s minimum.
Minimum driver per CUDA major version
| CUDA toolkit | Minimum driver | Upper range for minor-version compatibility |
|---|---|---|
| CUDA 13.x | 580 or newer | Not applicable; newer drivers covered by backward compatibility |
| CUDA 12.x | 525 or newer | Below 580; newer drivers still supported through backward compatibility |
| CUDA 11.x | 450 or newer | Below 525; newer drivers still supported through backward compatibility |
NVIDIA describes three ways a driver and a CUDA runtime can meet. A driver newer than the runtime works through backward compatibility, with no extra requirements. A driver older than the runtime but from the same major version works through minor-version compatibility, provided there is no PTX (SASS is required) and the target architecture was passed to NVCC. A driver older than the runtime’s major version needs forward compatibility and an extra compatibility package. Forward compatibility only applies to NVIDIA data-centre GPUs, select NGC Server Ready SKUs of RTX cards and Jetson boards. A GeForce RTX 3090 in a workstation should not count on that route.
Two failure modes show up when the layers drift apart. An application relying on a feature that spans a newer toolkit and driver can return cudaErrorCallRequiresNewerDriver on an older driver. Applications that compile device code to PTX will not work on older drivers at all, and the fix NVIDIA gives is to upgrade the driver. Minor-version compatibility also requires the build to name its target architecture, for example nvcc -arch=sm_xx.
For frameworks the logic is the same with one practical twist. CUDA applications typically statically include the libraries they need, such as cudart and cuBLAS, so they should work on newer drivers. A build compiled against CUDA 12.x can run, with a limited feature set and within those conditions, on driver 525 or newer; drivers newer than its runtime are covered by backward compatibility. One packaging change matters if you script installs: starting with CUDA 13.4, the Linux driver is no longer bundled with the CUDA Toolkit and has to be obtained separately. The difference between the two components is covered in more depth in CUDA driver vs CUDA toolkit, and the GPU side of the matrix in CUDA compute capability explained.
Is the newest driver always the right one for AI work?
No, and the opposite assumption is just as wrong. A newer driver is not reliably faster or reliably slower; it is a change to one layer of the executor, and its effect depends on the rest of the stack.
There are real reasons a new driver can help. PTX loaded at runtime is just-in-time compiled by the driver, so applications pick up compiler improvements that ship with each new driver, and NVIDIA invalidates the compute cache on a driver upgrade for that reason. The same mechanism has a visible cost: JIT compilation increases load time, so the first launch after an upgrade can take longer to load, a cost the cache removes on later launches.
There are also real ways for an update to go badly. In a study of performance problems in deep learning systems, Cao et al. (ESEC/FSE 2022) attributed 9 cases (4.0%) to mismatched library versions, because version restrictions must be satisfied for full GPU use. A developer write-up on an RTX 5090 (a Blackwell card, not a 3090) found that building llama.cpp with CUDA Toolkit 13.1 crashed the MMQ kernel and forced a cuBLAS fallback, with prompt processing differing by 5.7 to 6.3x between the two paths. The same author found a stale FORCE_CUBLAS value persisting in the CMake cache and quietly producing the slower figures. That case is a toolkit and build-cache problem on different hardware, so it says nothing about any specific driver on a 3090. Its lesson is narrower and more useful: a single stale layer can dominate a result, and nothing in the version string tells you so.
The Game Ready and Studio explainer notes that on Windows desktops a driver flawless on one machine can cause black screens or app crashes on another, depending on hardware, Windows version and software stack.
Settings that can change AI throughput after a driver update
Some throughput changes come from settings that sit around the driver, not from the driver version itself.
Power limit is one such setting on an RTX 3090. A 2026 guide on power-limiting GPUs for local AI reports that capping a 3090 from 350W to 250W costs under 3% of LLM token-generation speed, because decode is memory-bandwidth-bound. The same guide reports a cliff below 250W, where the core can no longer hold close to base clock and even bandwidth-bound work starves. It cites Puget Systems measuring over 95% of maximum performance on quad-3090 training at 280W per card. It also warns that compute-bound prefill, such as long-context retrieval, suffers more from a deep cap than decode does. We found no source on how specific driver updates treat the default power management mode, so we would simply confirm after every update that the power limit and any management settings you applied are still in place before timing anything.
Framework defaults move both speed and numerics on Ampere cards. TF32 computes float32 GEMMs faster with reduced accuracy, and PyTorch at one point used it by default for matrix multiplications and convolutions on Ampere. PyTorch later changed the default for matmuls to the highest-precision fp32 mode, so users who want the TF32 speed now have to opt in. One user report in that discussion found RTX 3090 results “totally different” from an RTX 3080, a GTX 1080, the CPU and NumPy. cuDNN autotuning behaves similarly: with benchmarking enabled, cuDNN tries several convolution algorithms and may pick different ones on later runs, even on the same machine. A framework upgrade can change these defaults, as PyTorch’s TF32 matmul change did.
Making a workload faster and cheaper on the target hardware is engineering work rather than measurement; that is what TechnoLynx’s GPU performance engineering practice does, and performance tuning for AI inference in practice shows what raising a software ceiling involves.
How do I check whether a driver change actually helped on my RTX 3090?
Measure the same workload before and after the change, under the same conditions, more than once, and write down every version involved. Single timings are noisier than most people expect: Pham et al. (ASE 2020) found that implementation-level factors alone caused training-time differences of up to 145.3% across identical runs. PyTorch’s own documentation says fully reproducible results are not guaranteed across PyTorch releases or platforms.
LynxBenchAI is built to make this check cheap. The Personal Edition installs with pip install lynxbench-ai on Python 3.11 or later, on Linux or on Windows via WSL2. It needs roughly 15 GB of free disk, downloads about 2 GB of model data once, and a full pass takes 15 to 30 minutes, so you can run it, change the driver and run it again in an afternoon. The Personal Edition is free for non-commercial use. The models are prepared once, before any target device is known, and the same prepared artefacts run everywhere, so optimisation effort stays fixed while you change the stack. The same catalogue runs on NVIDIA, AMD, Intel and CPU backends under one set of rules, so a stack difference shows up in the number instead of in whose benchmark was used.
Two limits are worth knowing. LynxBenchAI measures software anyone can obtain: you may run a different driver or a newer runtime than the one it installs, as long as every component is publicly released. That rule is declared, not enforced. The client does not check that a stack is publicly obtainable; the submission record captures driver, framework and runtime versions, so the rule can be audited afterwards. Second, each test is one timed window after a discarded warm-up. The measurement does not capture thermal state or clock behaviour.
Procedure for a before/after driver check
- Record the driver version, CUDA runtime, framework version and power limit before touching anything.
- Warm up before timing: libraries such as cuBLAS load on first call, which is why PyTorch’s benchmark recipe calls for a warm-up run.
- Synchronise CPU and GPU when timing; a plain
timeitmeasures only kernel launch because it does not synchronise CUDA. - Fix settings that vary between runs, such as cuDNN benchmarking and TF32, or at least record them.
- Repeat the measurement several times on each side, and treat a difference smaller than your run-to-run spread as no difference.
- Change only the driver, re-check the step 1 settings, warm up again (the JIT cache was invalidated), and repeat.
Even done carefully, a before/after pair is not a controlled experiment. Each side is one measurement on one machine at one moment, and everything else on that machine moved with it.
Reading the 26Q3 RTX 3090 results against your own run
In the 26Q3 results, the NVIDIA GeForce RTX 3090 on native Linux scores 202.7 GT, 207.6 in training, 294.1 in inference and 87.4 in compute. Those figures describe that executor, meaning the card plus the stack it ran on, and the release did not test alternative drivers, so they are a reference point, not a driver ranking. Compare your own runs only with other 26Q3 runs, since the model catalogue, precisions, correctness thresholds and scoring formula are fixed per release. A GT difference is ordinal: it tells you which result is higher, not what percentage faster a driver made anything.
When should you roll a driver back, and how do you do it cleanly?
Roll back when repeated measurements show a regression larger than your run-to-run spread, or when the new driver brings crashes or hangs you did not have before. Do not roll back because of cudaErrorCallRequiresNewerDriver: that error means the driver is too old for a feature the application uses, so the fix goes the other way.
A clean rollback starts from knowing what you are removing. The display driver and the CUDA Toolkit are separate: the toolkit has its own packages and uninstall path, although purging driver packages can still break CUDA workloads. On Linux, identify the toolkit, runtime, DKMS and compute packages before cleaning anything up. On Windows, the same guide describes Display Driver Uninstaller in Safe Mode, and notes that Wagnardsoft recommends going offline during the cleanup so Windows does not reinstall a driver underneath you. Earlier CUDA Toolkit releases are listed in NVIDIA’s toolkit archive, and NVIDIA points to its driver site for production drivers suited to your hardware.
Once the old driver is back, pin it in your package manager and record the full stack beside your measurements, so the next change is a deliberate experiment rather than an unattended upgrade. Our guide to NVIDIA Linux driver installation for AI workloads covers the install side in order. The judgement that remains is yours: whether a measured difference on your workload is worth the risk of the change.
FAQ
What AI models can run on a 3090?
The RTX 3090 has 24 GB of DRAM. In the 26Q3 results it ran MobileNetV3, Flan-T5 Small, DistilGPT2, DistilBERT and GraphGPS in training and inference, while fp8 inference produced no result on that executor.
