gpu-unlock removes the FP16/BF16 limit on RTX 20/30/40 without VBIOS reflashing

⚡ The gist in 5 seconds

• The gpu-unlock kernel module removes the artificial BF16/FP16 tensor core cap on GeForce RTX 20/30/40 — up to +100% TFLOPS on the RTX 4090, per the README.
• It's installed into the initramfs (mkinitcpio, initramfs-tools, dracut) and loads before the NVIDIA driver; the VBIOS is untouched and the driver isn't patched.
• RTX 30 — claimed stable, RTX 20 and 40 — experimental, RTX 50 — not supported.

🔍 What happened

Habr has published a write-up of the gpu-unlock project by a developer going by Zagitta: DmNep's article on Habr. It's about a Linux kernel module that removes the artificial throttling of FP16/BF16/TF32 math with FP32 accumulation on consumer GeForce cards. On professional cards (Tesla, A100, H100), the same tensor cores run at full speed, while on GeForce the same mode is usually cut in half. For gaming it doesn't matter, but for local LLMs, fine-tuning, and image generation, that's exactly the math that runs during prefill and training.

Here's how it works: the module is embedded into the initramfs and loads before the system binds the stock nvidia driver. It then writes speed-selector registers to the card — SS0 = 0x88888888 (full BF16 speed) and a 4-bit SS1 = 0x8 (IMLA4 mode) — performs an FLR (Function-Level Reset), and releases the card. The unmodified stock NVIDIA driver then attaches without issue. The approach combines techniques from the old cmpunlocker (V67/PLM registers) and the idea of intercepting before driver load via UEFI. The driver archive is downloaded only for the firmware the unlock depends on; there's no driver version dependency, according to the author.

The numbers from the README — pure BF16 matmul at stock power limits:

• RTX 3060 12 GB: 27 → 51 TFLOPS (+87%)
• RTX 3080 10 GB: 65 → 113 TFLOPS (+73%)
• RTX 3090: 75 → 125 TFLOPS (+65%)
• RTX 4080: 104 → 193 TFLOPS (+87%)
• RTX 4090: 165 → 329 TFLOPS (+100%)

Per community reports (not an independent benchmark): LLM prefill +25–55%, time to first token down 25–30%, LoRA and full fine-tuning +25–50%, image generation +30–55%, FlashAttention/SDPA +50–60%, video (Wan 2.2, BF16) +15–20%. In llama.cpp and Ollama with GGUF — 0–15%, more noticeable with long context. LLM decode (memory-bound), INT8/FP8/INT4 models, gaming, and FP32 CUDA remain unchanged.

🧠 Our take

My bet is the news blew up not because of the module itself, but because of the timing. Local models on 24–48 GB of VRAM are no longer exotic, and people have hit a ceiling that can't be bypassed by buying another card. They're being sold the same hardware twice — as a GeForce and as a professional card — and now a single registry line stands between those two price tags.

What this changes in practice. If even half the claimed numbers hold up, an RTX 3090 owner gets prefill performance a class above their card without buying anything. For fine-tuning that's hours saved; for inference, seconds off the wait for the first token. But the flip side: decode doesn't speed up at all, since it's entirely memory-bound. So gpu-unlock doesn't "turn a 4090 into an H100" — it only boosts the part of the workload where tensor cores do the computing. Those running INT4 quants through Ollama may not notice any difference at all — and the README says so honestly.

The winners are 30-series owners: their status is stable, the cards are cheap, and the TFLOPS gain is the most predictable. The losers, in our assessment, are those who bought a professional card for the throttled mode — their argument "I need full BF16" has gotten weaker. NVIDIA hasn't said anything yet, and I don't expect them to. There's usually no official response to something like this; the loophole gets quietly closed in the next driver branch, if they even bother.

⚠️ What we don't know

The author of the Habr article himself states outright that he hasn't tested the module, and all the figures are claims from the project author and the community. There are no independent measurements, nor any data on power draw, thermals, or stability under hours-long loads. It's also unclear what this means for the warranty and how the card behaves after FLR on different vendors — the README doesn't cover this. You'll have to verify it yourself, at your own risk — and the link to kernel/gpu_unlock/recipes.c with the exact PCI device IDs is worth reading before, not after.