gpu-unlock: an SEC2-booter exploit doubles RTX 30 tensor throughput — prefill +10–33%, decode flat, outputs bit-identical

Consumer RTX 30-series cards run FP32-accumulate tensor math at half rate by default. The open-source Linux kernel module gpu-unlock restores full rate before the NVIDIA driver binds; community measurements show BF16 GEMM up ~1.8× (87.5 → 157.4 TFLOPS on a 3090 Ti) with bit-identical outputs. The real inference gains are narrower than the headline: prefill up 10–33%, decode flat, int8 untouched.

What shipped

gpu-unlock v1.0.0 is a GPL-2.0 kernel module by GitHub user Zagitta, first pushed on 2026-10-18. It loads from the initramfs and runs the unlock before the unmodified NVIDIA driver binds the card — neither a UEFI application nor a patched driver, and it needs no re-patching when NVIDIA ships a new driver README. It targets GA102, GA103, GA104 and GA106 (the RTX 30 family), strictly opt-in via the gpu_unlock.targets=all (or per-PCI-address) kernel command line.

Per the project's technical writeup, the module exploits a buffer overflow in the SEC2 "booter" firmware — the same flaw used to unlock CMP mining cards — to run a V67 ROP payload that raises the Privilege Level Mask, making the GPU's speed selectors host-writable. It then writes 0x88888888 to FEAT_OVR_SM_SPD (SS0) and 0x8 to FEAT_OVR_SM_SPD_1 (SS1), then performs a function-level reset before the stock driver takes over.

Those selectors encode the throttle. SS0's eight 4-bit fields govern the FMA instruction classes (DP, FFMA, FMLA16, FMLA32, IMLA0–3); bit 3 enables the override and bits 2:0 select the rate, where 00 = full and 01 = half writeup.

Stock SS0 values are per-die — the writeup lists a GA102 reference default of 0x00000001 (half-rate encoding), while a real 3090 Ti reads 0x30634122 issue #1. Per-MHz-normalized measurements put the stock FP32-accumulate rate at about half the unlocked rate, and the writeup flags the 1/4 and 1/8 encodings as unconfirmed, so the register semantics are partly inference. The README's summary is stark: the module "doubles the instruction issuing speed of FP/BF16 FMA into FP32 operations" README.

The headline numbers come from a pinned X thread by Alexey Fateev, quoted in the r/LocalLLaMA post that surfaced the story: BF16 "tensor pipe" 82 → 155 TFLOPS, cuBLAS BF16 GEMM (8192) 64 → 99 TFLOPS, and TF32 41 → 79 TFLOPS on his 3090s thread mirror. The README reproduces a community five-sample-median GEMM run on a 3090 Ti at 450 W with FP32 accumulation issue #1:

Input	Before	After
FP16	87.46 TFLOPS	118.39 TFLOPS
BF16	87.50 TFLOPS	157.41 TFLOPS
TF32	42.58 TFLOPS	82.61 TFLOPS

Raw GEMM numbers vary with card and power cap — the README table shows a 1.80× BF16 ratio, while a two-3090 box in issue #27 measured 70 → 109 TFLOPS at 350 W issue #27. The cleanest figure is per-MHz-normalized: 0.043 → 0.083 TFLOPS/MHz (~1.93×) in a community measurement in issue #1.

Where those extra FLOPS land in a real serving workload matters more than the peak. The poster's prefill runs on Strata (Qwen3.8 Flash-Next across two cards) were +12% at 4K and 10K context and 3205 → 3536 tok/s (+10%) at 90K, with GEMM phases 23% shorter r/LocalLLaMA. A breakdown in issue #27 shows why the gains concentrate there: FFN-shaped BF16 GEMM +58%, FlashAttention 2 +53–54%, INT8 −0.6%.

A separate Strata A/B on a single 3090 found prefill up 12.9% (BF16 tier) with decode unchanged at every context ("no significant change… all p > 0.15") Strata #3858. Other community runs report +33% vLLM prefill issue #25, +10% prefill on a 4×3090 box at 240 W issue #2, and +47–59% on ComfyUI image gen with a 3090 Ti Notebookcheck.

Numerics are unchanged by design: the module changes instruction issue rate, not arithmetic. The poster reports a 1,996-position teacher-forced log-prob dump matching byte for byte before and after r/LocalLLaMA, and several issue reporters independently confirmed identical output hashes for fixed inputs issue #27, issue #15, issue #14, issue #12.

Why it matters

This is an exploit, not a driver flag — and it lands on a six-year-old question. In October 2020, on an HN thread about AMD's RX 6000 launch, a commenter noted the 3090 was "critically, capped to half-rate tensor operations with FP32 accumulate," citing an NVIDIA AMA that seemed to leave the limit software-controllable HN. The module's own framing — that it unlocks consumer GA10x cards "to their professional equivalents" README — is the first concrete claim of a software-controllable segmentation on this die.

For engineers, three practical consequences follow:

1. The gains are workload-shaped, not model-shaped. MoE decode is CPU/DRAM-bound, so doubling tensor FLOPS buys ~0 tok/s there — the Strata A/B makes this point. The winners are long-prompt prefill, GEMM-heavy diffusion workloads, and big dense FP32-accumulate matmuls.
2. The throttle only ever bit the FP32-accumulate path. In a community per-MHz measurement, FP16-with-FP16-accumulate GEMM ran at 0.081–0.083 TFLOPS/MHz before and after unlock, while FP32-accumulate GEMM went 0.043 → 0.083. That is why int8 stays flat, and why hand-tuned fp16-accumulate kernels that existed because FP32 accumulate ran half-rate now lose to FlashAttention 2 issue #27.
3. The numerics story is a genuine convenience. No published report compares an end-to-end serving stack byte for byte, but kernel-level outputs are bit-identical across repeated community tests and the mechanism is rate-only — deployed pipelines should not need retuning.

Caveats

• It is a firmware exploit: a ROP payload on the SEC2 booter, with EULA implications — Metaratings notes NVIDIA's EULA prohibits circumventing software restrictions — and the project does not claim redistribution rights for the NVIDIA firmware it extracts NOTICE. NVIDIA has not commented in any of the coverage, and Notebookcheck flags that results are not independently verified.
• It is not turnkey. Secure Boot must be off or the module signed issue #25; there are documented initramfs-ordering and packaging bugs (#11, #14, #29); one commit regression broke unlocking on 2×3090 boards until fixed (#20); one GA102-250 (3080 Ti 20 GB OEM) unlocks but stays at half rate anyway issue #28; and one LHR card fails mid-procedure issue #21. The longest reliability datapoint published so far is an 8-hour mixed-workload run (vLLM plus diffusion) issue #25. An experimental Windows UEFI port exists but boots only one reported system repo.
• "Every 3090 ships at half rate" is a claim about the default factory configuration, backed by the module's register model and the before/after spread across ~8 independent reports — not a mass survey.
• The Reddit thread's title asks about RTX 40; the answer is currently no. Ada appears to reject the writes — a probe of three RTX 4060 Ti (AD106) cards found the selector writes read back stock values — and the maintainer says he will add AD102 support only on concrete evidence with boot logs and benchmarks issue #4.
• Treat all the numbers as community-reported: "tensor pipe" TFLOPS is never defined, gains vary by power cap and quant tier, and the 10–33% prefill range is the spread across workloads, not a guarantee.

Sources

• r/LocalLLaMA: "Anyone checked gpu unlock for rtx 30-40 cards?"
• Zagitta/gpu-unlock repository and README
• How Ampere was unlocked (technical doc)
• Firmware provenance / licensing NOTICE
• Alexey Fateev's original X thread (mirror)
• gpu-unlock issue #1 — 3090 Ti GEMM data and per-MHz measurements
• gpu-unlock issues: #2, #4 (Ada probe), #11, #12, #14, #15, #20, #21, #25, #27, #28, #29
• Strata issue #3858 — prefill/GEMM/decode A/B
• Notebookcheck: "Nvidia RTX 3090 performance nearly doubles with free GPU unlock, but there's a catch"
• Metaratings: "Энтузиасты сняли ограничение NVIDIA RTX 30 — GPU Unlock"
• HN 2020: "The 3090 … is capped to half-rate tensor operations with FP32 accumulate"
• impacifist/Windows-GPU-UNLOCK (experimental Windows port)