Sometime this week, a GitHub user named Zagitta published nine pages of README and a Linux kernel module that quietly contradicts NVIDIA's product segmentation. GPU Unlock raises the FP16 and BF16 Tensor Core instruction-issue rate on RTX 30-series cards to the level NVIDIA reserves for its professional GPUs, and it does so without flashing the vBIOS, patching the driver, or touching hardware. On an RTX 3090 Ti, dense BF16 matrix throughput goes from 87.50 to 157.41 TFLOPS. That is not an overclock. It is a lock NVIDIA put on silicon that was always capable of the faster rate.
The benchmarks landed on October 23 and 24, spread through r/LocalLLaMA and X within hours, and coverage followed fast at Wccftech and ThePCEnthusiast. The used-GPU market reacted before most readers finished the thread: Wccftech reports RTX 3090 prices climbing from around $1,000 to past $2,000, with 3090 Ti units approaching $3,000.
Context: where this unlock came from
GPU Unlock is a descendant of two older projects, and its README is unusually candid about the lineage. The first is the CMP unlocker work: NVIDIA's CMP 170HX and its siblings are cryptocurrency mining cards built from GeForce silicon with firmware locks on video outputs and reduced compute rates. Community research found that a vendor-style firmware payload (the V67/PLM technique) could lift those restrictions. The second is an earlier UEFI-based unlock that ran at boot, before any operating system driver, to set Ampere speed selectors.
Zagitta's contribution is timing and packaging. The module is a Linux kernel module that loads from the initramfs, before the stock nvidia driver binds the card. It writes two speed selectors documented in the README: SS0 set to 0x88888888, which selects the full BF16 rate, and a 4-bit SS1 set to 0x8 (IMLA4). It then performs a Function Level Reset and steps aside so the unmodified NVIDIA driver initializes the GPU normally.
Three engineering consequences follow from that design choice, and they are the reason this tool is practical rather than a party trick:
- No patched driver. Because the unlock happens before
nvidia.koloads, every future driver update works without re-patching. Previous unlock methods required re-applying patches on each driver release. - No permanent firmware flash. The speed selectors are volatile. Suspend-to-RAM powers the card off and resets them, so the module registers a suspend notifier and re-unlocks on resume, at a cost of about one second.
- Opt-in via kernel command line. Nothing happens unless
gpu_unlock.targets=all(or a list of PCI addresses) is present. Remove the flag, and the card behaves exactly as stock. The module refuses cards another driver already bound.
Supported chips are GA102, GA103, GA104, and GA106, which covers most of the RTX 30 lineup. The kernel module is GPL-2.0-only; the generated payload derives from the pinned CMP reference, and NVIDIA firmware stays under its own terms.
The numbers, and what they actually measure
The headline table comes from the repository itself: a dense 8192³ GEMM with FP32 accumulation on an RTX 3090 Ti at a 450W power limit, five-sample medians.
| Precision | Stock | Unlocked | Gain |
|---|---|---|---|
| FP16 | 87.46 TFLOPS | 118.39 TFLOPS | +35% |
| BF16 | 87.50 TFLOPS | 157.41 TFLOPS | +80% |
| TF32 | 42.58 TFLOPS | 82.61 TFLOPS | +94% |
Two details in that table deserve more attention than they got in coverage. First, FP16 gains 35% while BF16 gains 80% on the same card at the same clocks. The lock being removed is specifically on FP/BF16 FMA into FP32 accumulation, so the remaining FP16 gap is bound by something else, most plausibly the added power and clock pressure once the issue rate doubles (the README's own RTX 3080 report shows clocks sagging from 1384 MHz at stock to 1208 MHz post-unlock at a higher power limit). Second, these are dense GEMM peaks, not sustained application throughput. The README itself warns that per-card gains "are not directly comparable" across reports.
Community compatibility reports, all linked from the repository's issue tracker, fill in the rest of the lineup:
| Card | BF16 GEMM gain | Notes |
|---|---|---|
| RTX 3090 Ti | +68 to 80% | 450W limit |
| RTX 3090 | +25 to 67% | Low end is 225W-capped cards |
| RTX 3080 10 GB | +70 to 73% | FP16 65 to 110-113 TFLOPS at stock 320W |
| RTX 3070 | +73 to 81% | GA104 |
| RTX 3060 12 GB | about +80% | At 170W: FP16 +78%, BF16 +84%, TF32 +80% |
| RTX 3080 Ti 20 GB (OEM, GA102-250) | none | Unlock completes, BF16 stays at half rate |
The power-limit pattern is consistent across reports: a 3090 pinned at 225W gains 25%, the same chip at full power gains up to 67%. Doubling the instruction-issue rate is only useful if the power budget can feed the extra switching activity. The OEM 3080 Ti 20 GB result matters too: it proves the unlock is not a universal skeleton key, and any buyer hoping to unlock a farm of OEM cards should read that issue thread first.
Real workloads, from the same reports: in ComfyUI on a 3090 Ti (EVGA FTW3, Ubuntu, driver 615.71.09), MOSS-Image SFT in BF16 dropped from 71.98 to 45.40 seconds per image, a 58.6% throughput gain. Qwen-Image 2.1 Turbo gained 57.2%, Z-Image Turbo 56.1%, and MiniMax H3 video generation 60.2%. In vLLM, RTX 3090 owners measured 33 to 36% faster prompt processing and about 25% lower time-to-first-token. Token generation speed, the decode phase, was unchanged. INT8 image generation gained 0.3%, effectively nothing. And the testers who checked found the outputs bit-identical before and after.
That last fact is the most important sentence in the whole story for anyone running production inference: this changes how fast the matrix units issue instructions, not how they round. There is no silent numerical drift hiding in the speedup.
What This Means: a roofline reading of the unlock
Read as a data scientist, the benchmark table is a nearly textbook demonstration of the roofline model, and it predicts exactly which numbers should move before you ever run the tool.
Every GPU kernel lives under two ceilings: a compute roof (peak FLOPS) and a memory-bandwidth roof (peak bytes/s), joined at a crossover arithmetic intensity of compute-peak divided by bandwidth. Take the RTX 3090's published 936 GB/s of GDDR6X bandwidth as a labeled assumption; the arithmetic below is only as good as that spec, but it is uncontroversial.
- Stock, BF16: 87.5 TFLOPS / 936 GB/s puts the crossover at roughly 93 FLOP per byte.
- Unlocked, BF16: 157.4 TFLOPS / 936 GB/s pushes the crossover to roughly 168 FLOP per byte.
The unlock raises the compute roof and leaves the bandwidth roof untouched. So gains appear only for kernels whose arithmetic intensity sits above ~93 FLOP/byte, and they shrink for kernels between 93 and 168, because those now hit the unchanged bandwidth wall sooner.
That single inequality explains every row of the reported results:
- Dense GEMM (the benchmark): arithmetic intensity scales with tile size and reaches hundreds of FLOP/byte. Deeply compute-bound. Gains: up to +80%, as predicted.
- LLM prefill: each token processes the full weight matrices, intensity is high, and the reported +33 to 36% tracks the compute roof. But it lands well under +80% because prefill at realistic batch sizes mixes in attention, layer norm, and softmax kernels that never saturate Tensor Cores. A 54 GFLOP/token estimate for a 27B dense model at 40% of the unlocked BF16 peak would suggest roughly 1,160 prefill tokens/s versus 790 stock (+47%); the measured 33 to 36% is what a real serving stack actually gets, and the gap is the non-GEMM fraction. Honest roofline analysis should predict the direction and rough size, not the exact number.
- LLM decode: each generated token reads nearly every weight byte once, arithmetic intensity near 1 to 2 FLOP/byte for small batches. Far below either crossover. Bandwidth-bound. Predicted gain: zero. Measured gain: zero.
- INT8: unchanged, because the lock being removed sits on the FP/BF16-into-FP32 issue path. Different pipe, different rate limiter.
- Diffusion and FlashAttention: GEMM-heavy inner loops in BF16. Predicted large gains. Measured: +56 to 60%.
For the software engineer, the interesting artifact is not the speedup but the mechanism. A volatile, pre-driver, opt-in kernel module that re-applies itself across suspend is a fundamentally different class of hack than a vBIOS flash. It is reversible by deleting a GRUB flag, it survives driver updates, and it is auditable: the README pins its inputs by SHA-256 and generates firmware only in the build directory. Whatever NVIDIA thinks of this, the community just wrote the template for the next decade of rate-limit protests.
Why the market reacted before the reviewers did
The economics explain the eBay spike. In my DeepSeek DeepInfer piece, the number that mattered was $38 of revenue per GPU-hour at frontier scale. Local inference competes on a different axis: an owned GPU has no hourly rate, only watts and amortization. A 3090 at 450W under load costs roughly $0.05 per hour at $0.12/kWh, and a card that renders BF16 80% faster finishes 80% more jobs for that same hour.
The prefill-versus-decode split also redraws who should care. If your workload is chat-style decode of a large quantized model, the unlock buys you nothing; memory bandwidth is your ceiling, which is why the 24GB 3090's price was set by VRAM, not flops. If your workload is fine-tuning, batch prefill, long-context RAG ingestion, or image and video diffusion in BF16, a $2,000 unlocked 3090 now approaches A6000-class matrix throughput per dollar without the ECC, the drivers-for-VMs polish, or the four-figure price tag. Wccftech's price data shows the market pricing exactly that: 3080 10-12GB cards, which lack the VRAM to matter for model serving, sit at $900 to $1,100 while 24GB cards run away.
Compare against the alternatives in our GPU comparison: the unlock does not make an RTX 30 competitive with a new RTX 5090 or datacenter part on any absolute metric. It moves the value proposition, which is a different lever, and a cheaper one.
Outlook: what NVIDIA can and cannot do
NVIDIA's realistic responses are narrow. The selectors are reset by power cycling and set before the driver loads, so driver-side detection would have to reject a GPU whose reported speed selectors disagree with the fuse values, at the cost of bricking legitimate configurations. Fusing the limit permanently would require a firmware change NVIDIA has deliberately avoided, since the same GA102 silicon ships across three market segments and the rate limiter is the segmentation. A crackdown on the repository is possible in principle, but the payload derives from published CMP research and the technique now exists in at least two independent implementations, including an experimental Windows UEFI port that reported a +82.5% BF16 gain on a 3090.
Watch three signals. First, whether NVIDIA touches the CMP or GeForce firmware path in a future VBIOS update, which is the only clean kill switch. Second, whether the RTX 40-series experiments referenced in the repository and on Wccftech's follow-up mature beyond individual confirmations, because Ada cards have far more installed base among local-AI builders. Third, whether used 3090 prices hold above $2,000 once the unlock hype cools; if they do, the market has decided that prefill and diffusion throughput, not gaming frames, sets the floor price for 24GB Ampere.
For owners of an RTX 30 card on Linux who run BF16 training, prefill, or diffusion: this is the rare performance "upgrade" that costs a GRUB edit and a reboot, and the reports say outputs stay bit-identical. For everyone planning to buy one used: the $1,000 window closed the day the README went public, and per our Qwen3.8-27B architecture study, the decode-bound majority of local inference workloads were never the beneficiary anyway.