NVIDIA's new graphics driver is a game-changer: NVIDIA Studio 621.14 makes local large models 2.2x faster! People generally think of graphics driver updates as fixing bugs and adding support for a few new games—the kind of update that feels pointless even after you install it. But when I looked at the changelog for this NVIDIA Studio driver 621.14, I got a bit excited—this time two new supported features slipped in.

📜 Table of Contents

• Where does this 2.2x come from
• Official benchmark data, straight to the table
• But for these four groups, installing it is pointless
• A quick heads-up to avoid a pitfall
• Final thoughts

NVIDIA's New Driver Is a Cheat Code: NVIDIA Studio 621.14 Makes Local LLMs 2.2x Faster!

Your usual impression of a graphics driver update is bug fixes and support for a few new games—the "updated for nothing" tier.

But when I read the changelog for this NVIDIA Studio driver 621.14, I got a little excited. Two new additions jumped out at me:

One is llama.cpp—the veteran engine for running local LLMs—which now adds GPU caching for MoE expert models, boosting decode speed by up to about 2.2x. The other is PyTorch, where under the Blackwell architecture, NVGEMM makes NVFP4 LLM decoding faster.

In plain terms: do nothing, just install a driver, and your local LLM gets a free speed boost.

Is something this good really possible? I dug into the details of this feature, and the conclusion is: Yes, but there's a catch—not everyone gets that 2.2x.

Where does this 2.2x come from

First, some background. People running local LLMs have been wrestling with one contradiction for the past two years: the model is too big, the VRAM is too small.

MoE (Mixture of Experts) models are the mainstream solution—the model carries a bunch of "experts," and each token only picks a few to do the work. The parameter count is huge but the compute is small. Take some of the popular open-source MoE models right now: they weigh in at 60–90GB, while your GPU has only 24GB of VRAM.

The usual approach is to offload most experts to RAM, keeping only the core in VRAM. The cost: every token generated requires shuttling expert weights across the PCIe bus to and from memory, and speed gets bottlenecked by bandwidth.

The approach in this update is clever: expert hits are uneven—a small number of "hot experts" get used over and over. So you carve out an LRU cache in VRAM and keep the hot experts resident, so hits don't need to be moved again. In practice, using about 10% of the total expert size as cache captures 70%–90% of hits.

This feature originates from llama.cpp's v0.7.0 release in mid-October (the --moe-cache-mib parameter), and this driver update carries it into NVIDIA's official pipeline.

Official benchmark data, straight to the table

The developer's PR includes real measurements: running a 93.7GB Qwen3.8-Flash-Next (Q4 quantized), with 65GB of expert weights fully offloaded to RAM:

The 5090 hits the full 2.2x, and the 4090 gets around 1.6x. For users tight on VRAM, this is the biggest free speedup of the year, bar none.

But for these four groups, installing it is pointless

Here's the key point: the boundaries of that 2.2x are clear—see which one applies to you:

1. Those whose model fits in VRAM. For example, running a 30B-class model on a 4090/3090, with all experts in VRAM—there's no "offloading" happening at all, so the speedup is zero. These users can carry on as usual.

2. Those running Dense models. This cache operates at expert granularity; offloading an ordinary 70B dense model to RAM gets you nothing.

3. Those on older cards. The other feature in the driver changelog—PyTorch accelerating NVFP4 decoding via NVGEMM—is Blackwell-exclusive, meaning RTX 50 series and RTX PRO 6000. The 40 series and earlier are purely spectators. Fortunately, NVFP4 lets 50-series cards run 4-bit models fast and with low VRAM use, so 50-series users get a double win.

4. Heavy users of Agent-based coding. An easy-to-miss pitfall: this cache only accelerates "token-by-token generation," not prefill of long prompts. If you use Agent tools like Cline or Aider, which resend a big chunk of context every round, the real-world improvement will be noticeably smaller than the on-paper numbers. Its sweet spot is long outputs—like having the model write several hundred lines of code in one go.

A quick heads-up to avoid a pitfall

llama.cpp v0.7.0 changed the server's default port from 8080 to 9931. If Open WebUI or your reverse proxy can't connect after upgrading, check this first.

Final thoughts

The real significance of this update isn't the 2.2x on paper—it's that it tips the scales on the "not enough VRAM" balance.

Previously, running a 120B-class MoE model on a 24GB card meant "it runs, but so slowly you question your life choices." Now that hot experts live in the VRAM cache, decode speed reaches workstation levels.

The money saved is very real: the price of a used 4090 is enough to fill every RAM slot you've got.

If you run local LLMs, this driver is a no-brainer update. If you don't—well, maybe this article is your reason to get started.

Data sources: NVIDIA Studio driver 621.14 changelog, llama.cpp v0.7.0 Release Notes, and benchmark data from PR #29887.