NVIDIA splits its own silicon in two: the same GA102 chip that ships in your RTX 3090 runs FP16 and BF16 tensor math at HALF the rate of the professional cards, because a few bits in a config register say so. Not a hardware difference - a policy, enforced by registers the driver is not allowed to touch. As of last Saturday, the policy is gone. GPU Unlock, a Linux kernel module published Oct 18, flips those bits before the NVIDIA driver even loads. In one week: 6.7k stars, 702 forks, 122 compatibility reports and a Hacker News thread at 337 points.
The numbers, third-party reproduced
The headline benchmark is a dense 8192³ GEMM on a 3090 Ti at 450W, five-sample medians with FP32 accumulation: FP16 87.46 to 118.39 TFLOPS, BF16 87.50 to 157.41 TFLOPS, TF32 42.58 to 82.61 TFLOPS. That last line is the quiet one - TF32 doubles too. The user-run compatibility table reports +68-80% BF16 GEMM on the 3090 Ti, +70-73% on the 3080, +25-67% on the 3090 (board-dependent). One OEM variant (3080 Ti 20GB, chip GA102-250) completes the patch but keeps BF16 at half rate - the silicon lottery still applies. And the top HN comment, from someone who ran it on their own card:
“I’ve tested myself and the results are legit, this is incredible, even if a little risky.”
How the lock actually works - and how it broke
The lock is not silicon. It is two “speed selector” registers (SS0/SS1) in the GPU’s feature-override block. Each 4-bit field encodes: bit 3 = override enabled, bits 2:0 = the rate (00 full, 01 half). GeForce Ampere ships with FP/BF16 FMA-into-FP32 at half rate; the professional cards ship the same chip at full rate. The registers are write-protected from the host by a privilege-level mask (PLM) - writes from the driver “just do nothing, that would be too easy after all.”
The break is a textbook exploit chain, documented by the author in docs/How Ampere was unlocked.md:
- NVIDIA’s secure boot runs a signed “booter” firmware on the SEC2 security processor whose job is to decrypt and verify the GSP firmware.
-
That booter has a classic stack buffer overflow. Code execution lands via ROP - stringing together “gadget” code fragments from the firmware itself.
- The catch-22 of exploiting signed firmware: you can’t disassemble what you can’t decrypt. NVIDIA published debug builds of the booter encrypted under its public test-key scheme (key index 37), so researchers decrypted the debug image, disassembled it, and mined it for gadgets - and the debug image turns out to be “remarkably similar” to production.
- The v67 payload (inherited from the CMP-era cmpunlocker, the famous one LTT covered that turns 8GB CMP 170HX cards into 64GB cards) writes one 4-byte word anywhere in protected space. The exploit uses it to write 0xFFFFFFFF to the PLM register - lifting the write protection - and then sets the speed selectors to full rate.
The module runs in the initramfs, before the NVIDIA driver binds the card - the same timing the UEFI unlockers use, without their fragility. Opt-in per card or gpu_unlock.targets=all, unlocking again after suspend, done in about a second per card. The author is explicit that the technique is not theirs: “exploits etc aren’t my ideas by any means, this is just a way to wrap the whole thing up in a much less annoying package than having to patch the nvidia driver.” It survives driver updates because it never patches the driver.
What it means for local AI - and what it doesn’t
Doubling TFLOPS is not doubling tokens. LLM prompt processing (the prefill that eats your first-token latency) improves roughly 14-36% on RTX 3090 reports, while token generation barely moves - it’s memory-bandwidth-bound, and no register flip changes VRAM bandwidth. Image generation benefits more (matrix-multiply-bound). Gaming performance: unaffected - the lock only gates tensor-core instructions games don’t issue.
The honest caveats are thermal and legal. Thermal: the GEMM tests ran a 3090 Ti at 450W, above what stock coolers were designed for; the HN thread’s experienced voices (including someone running 7 different 3090s) note that big gains at stock power limits are board-lottery, and one of them went as far as building a 1500W quad-GPU PCIe backplane to feed the cards. Legal: the technique exploits NVIDIA’s own signed firmware; the kernel module and packaging are GPL-2.0-only while the generated payload derives from the pinned CMP reference and NVIDIA firmware remains under NVIDIA’s terms. The exploit is also temporary - it clears on power loss, which is both a safety valve and a reminder that none of this is sanctioned.
Turing works too - the day-two confirmation
The morning after the HN thread, the researcher behind the first 2080 Ti datapoint published her own reproduction as a full repo (KohakUnlock): the boot-chain port reaches Turing. On a VRAM-modded Leadtek 2080 Ti (22 GB, TU102), same-card A/B in her benchmark harness:
| Test |
Locked |
Unlocked |
Gain |
| mmapeak FP16, FP32 accumulation |
59.9 TFLOPS |
111.0 TFLOPS |
+85.3% |
| FP16, FP16 accumulation (control) |
119.5 TFLOPS |
118.5 TFLOPS |
unchanged |
| MAMF best median (125 shapes) |
57.71 TFLOPS |
88.24 TFLOPS |
+52.9% |
Two things are notable beyond the numbers. First, the honesty: the FP16-to-FP16 control row showing UNCHANGED (0.99x) is the kind of negative control most of these exploit threads never run - it says the harness measures what it claims. Second, the efficiency curve: her tweet claims an unlocked 22 GB 2080 Ti at 250W reaches roughly the speed of a stock 350W 3090 in the same test - the speed-selector bits gate instruction issue, not energy per instruction, so the unlocked card spends wasted headroom efficiently. Her 3090 rerun even recorded the patch running at a slightly LOWER power limit (360W vs 370W stock). The repo is also the most careful one yet: source-first, no firmware blobs, fail-closed boot gate, one-shot-per-boot for Turing, and explicit “not a universal unlocker” scope.
The Korean wave, and the shape of the story
The fastest spread was not the English-speaking press. A Korean creator’s explainer (lucian__03) is at 4.7k likes and counting - his framing translates as “NVIDIA has locked AI performance on RTX, and an open-source project just unlocked it for every RTX model from 20 to 40 series”:
The structural read for our readers: NVIDIA segments the SAME chip with a few register bits priced like an enterprise tier - and the segmentation now has a public, one-command exploit that the driver can’t patch, because the hole is in firmware NVIDIA signed years ago. The company can rotate the booter keys in future drivers (new cards, new firmware), but the 20-through-40-series fleet already in people’s machines is unlocked on published evidence. The used-market question videocardz raised is real too: the cards this helps most (3090, 4090) are the same 24GB cards AI buyers already hunt, so the compute patch doubles your FLOPS and possibly your card’s resale price - good for sellers today, mildly bad for buyers.
The bigger precedent: this is the second time in two weeks that a “hardware policy” protecting tier segmentation was taken apart in public - the refusal-classifier wall two weeks ago, the silicon segmentation wall now. When the enforcement point is bits you control - config registers, model weights, driver files - expect it to be flipped. The only segmentation that survives public scrutiny is one with a physical difference behind it. Everything else is a firmware line you hope nobody crosses.
Sources: Zagitta/gpu-unlock README + docs + issue #1 (benchmarks, created Oct 18 2026), the HN thread #50219700 (337 points), videocardz.com Oct 25 story, lucian__03’s Oct 24 post (4.7k likes), the CMP unlocker lineage (amoghmunikote/cmpunlocker, LTT-covered).
Related on this site: the model catalog shows what these unblocked cards run - K3.1 Pro’s memory math needs 700GB, but Bolt E4B and the NVFP4 quants (Flint, Raon-1 mini) run in the RTX 3090 class this exploit aims squarely at. The OrcaCyber piece covers the weights side of the same unblocking instinct.