gpu-unlock Lifts RTX 30-Series BF16 Matrix Speed Up to 81% via an Nvidia Firmware Bug

TL;DR

gpu-unlock is a Linux kernel module that removes a speed cap Nvidia put on GeForce RTX 30-series cards. On these cards, FP16 and BF16 tensor math with FP32 accumulation, the default mode for PyTorch training and most LLM inference, runs at half the rate of the professional cards built on the same GA102 die. The module exploits a buffer overflow in Nvidia's signed boot firmware to flip that setting before the stock driver loads. In user reports, BF16 GEMM throughput rises 25-81% depending on card and power limit. vLLM prefill on a stock RTX 3090 rose 33%, while decode stayed flat. The repo appeared on October 18, passed 3,100 GitHub stars within a week, and drew 194 points on Hacker News on October 24. It requires Secure Boot off, taints your kernel, and Nvidia did not sign off on any of it.

The cap you paid for

Nvidia documents the cap itself. Its GA102 architecture whitepaper lists the RTX 3090 at 142 dense FP16 tensor TFLOPS with FP16 accumulation, but 71 with FP32 accumulation. BF16 with FP32 accumulation is also 71. The RTX A6000 uses the same GA102 die and is listed at 154.8 TFLOPS in all three modes.

That matters because FP32 accumulation is what you actually use. Mixed-precision training, cuBLAS BF16 GEMMs and almost every BF16 model you serve accumulate in FP32 to keep the numbers stable. On GeForce Ampere, that path ran at half speed by design, and the market segmentation lived in a register.

How the unlock works

The project's write-up, How Ampere was unlocked, walks through the chain. Two registers, FEAT_OVR_SM_SPD (SS0) and FEAT_OVR_SM_SPD_1 (SS1), hold 4-bit speed selectors for instruction families, including FMLA16, the FP16/BF16-into-FP32 path. The goal is to write 0x88888888 to SS0 and 0x8 to SS1, which means "override on, full rate" for every field.

The driver can't write those registers directly. A privilege mask register, FEAT_OVR_PLM, allows writes only from level 3, the heavy-secure context that Nvidia's signed firmware runs in. The way in is the SEC2 Booter, signed firmware that decrypts GSP firmware and verifies its signature. According to the write-up, it has a stack buffer overflow. Nvidia shipped debug Booter images encrypted with a known public test key, so researchers could decrypt one, disassemble it and build a return-oriented programming chain. That chain, the "v67" payload, performs exactly one 4-byte write.

One write is enough when you aim it at the lock instead of the vault: the payload sets FEAT_OVR_PLM to 0xFFFFFFFF, and after that the host can write the speed selectors itself. The firmware has still verified everything it was asked to verify. It just also ran a few instructions of someone else's choosing.

What this repo adds

The exploit isn't new, and the author, Zagitta, says so on HN: "the exploits etc aren't my ideas by any means." The same boot flaw powers cmpunlocker, which unlocks memory on CMP 170HX mining cards, and Zagitta credits CMP unlocks that ran as standalone UEFI modules, chainloading into the OS, as the inspiration. gpu-unlock's contribution is packaging. It combines the CMP unlocker's v67/PLM technique with the pre-driver timing of the UEFI approach, packs it into a DKMS kernel module that loads from the initramfs, runs it before the unmodified Nvidia driver binds, and survives driver updates without re-patching. It builds Arch, Debian and RPM packages, downloads the pinned Nvidia and CachyOS inputs over HTTPS with SHA-256 checks, and does nothing unless you add gpu_unlock.targets=all (or specific PCI addresses) to the kernel command line.

It also re-unlocks after suspend to RAM, which resets the selectors, and it supports up to four cards in one box, the display card and vfio-pci passthrough to a VM, according to user reports.

What actually gets faster

Dense matrix math is where the gains show up, and the reported numbers vary widely because power limits vary. The README's tested-cards table lists BF16 GEMM gains of +68-80% on the RTX 3090 Ti, +25-67% on the RTX 3090, +70-73% on the RTX 3080 10 GB, +73-81% on the RTX 3070 and about +80% on the RTX 3060 12 GB. The low +25% came from cards capped at 225 W. The unlocked chip does twice the work per clock, so at a fixed power cap it runs into the cap at lower clocks.

A stock EVGA RTX 3090 report (issue #33) shows this clearly. At a 350 W cap, BF16 went from 72.0 to 114.8 TFLOPS, only 1.6x, because the SM clock dropped from 1710 to 1425 MHz. Per MHz, the ratio was 1.92x, and INT8, the control, moved 2%.

For LLM serving, the split is the familiar compute-versus-bandwidth divide. Prefill is a big batched matmul over your prompt and benefits. Decode streams weights through memory one token at a time and does not. A stock RTX 3090 running vLLM 0.30.0 with a 27B BF16 model (issue #25) gained 33% in prefill and 1.2% in decode, with time to first token down about 24%. The same tester reports 8+ hours of mixed production load with zero Xid errors. Two modded 3080 20 GB cards at 220 W (issue #15) also measured +33% prefill, with bit-identical outputs.

The skeptics on HN have a point. One commenter running Qwen 27B Int4 across four 3090s in vLLM said the gain was about 25% in TFLOPS at a 200 W cap, but only 7-8% end to end, because decode dominates their workload. Another got about 6% faster nanochat training on a 3060 held at 170 W. If you run chat with short prompts, you'll barely notice. If you run RAG, long-context agents, batch embedding, diffusion or fine-tuning, you will.

What it costs you

• Secure Boot off. The module is unsigned and out of tree, so the kernel is tainted on load.
• Power and heat. The full gain needs headroom. HN commenter jacquesm, who says the unlock is real, warns that on some cards the real payoff needs a 450 W limit, which is "well above what the stock cooler was designed for."
• Boot-order sensitivity. Loading it after nvidia binds does nothing. Issue #23 documents a refactor where the unlock failed on non-cold cards and left GPUs unusable by the driver, and main was reverted to a known-good commit on October 24. The README also says that if a card's firmware never stops, you need a full power-off before trying again.
• Licensing grey zone. The module is GPL-2.0, but the generated firmware payload derives from Nvidia firmware that "remains under its own terms." The README doesn't cover warranty or long-term hardware wear, and no report yet covers weeks of runtime.

Rollback is simple, which helps. Nothing is flashed and the VBIOS is untouched: remove the kernel parameter and reboot.

Why builders should care

The used RTX 3090 is still the default homelab AI card: 24 GB of VRAM at secondhand prices. This doesn't make it faster at decode. It does make prefill, image and video generation, and training noticeably cheaper on hardware you already own, with no new purchase.

Ada owners are next in line. A separate repo, gpu-unlock-ada, claims the same kind of tensor unlock for the RTX 4090 and, experimentally, the 4070 Ti Super. It appeared on October 23, and we have not verified its numbers. The Ampere write-up does not say whether Nvidia can close the hole on cards already in the field.

Key Takeaways

• GeForce Ampere cards run FP16/BF16 tensor math with FP32 accumulation at half the rate of the same-die pro cards: 71 vs 154.8 TFLOPS for the RTX 3090 vs RTX A6000, per Nvidia's own whitepaper.
• gpu-unlock uses a known buffer overflow in Nvidia's signed SEC2 Booter to open a privilege mask, then sets the speed selectors to full rate before the stock driver loads.
• Users report +25-81% BF16 GEMM, depending on card and power cap, and about +33% vLLM prefill on a stock RTX 3090. Decode and INT8 stay roughly flat.
• Real-world end-to-end gains run from single digits to the low 30s; prompt-heavy and training workloads gain the most.
• Costs: Secure Boot off, a tainted kernel, more heat at higher power limits, a recent regression that left cards unusable until power-off, and unclear firmware licensing. Rollback is one kernel parameter.

Sources: gpu-unlock repository and README, How Ampere was unlocked, Nvidia GA102 architecture whitepaper, issue #1 (RTX 3090 Ti), issue #15 (RTX 3080 20 GB), issue #25 (RTX 3090, vLLM), issue #33 (RTX 3090, per-MHz), issue #23 (warm-unlock regression), Hacker News discussion, cmpunlocker