by Chris DePuy, 650 Group / October 29, 2026
An open-source Linux kernel module restores the full FP16/BF16 tensor rate on NVIDIA’s consumer RTX 30-series cards. The first complete benchmark suite in the lane, published this week by an independent operator, measured the matrix-side gain at 50 to 60 percent, and every report in the lane agrees on its limit: decode, the rate that governs token generation in serving, stayed flat.
The project is Zagitta’s gpu-unlock, a C kernel module whose repository was created on October 18, 2026 and last pushed on October 29, per the GitHub API. Rather than touch firmware or the driver, the module programs the cards’ speed-selector registers and performs a function-level reset ahead of the stock driver’s bind step. The README is blunt about the method: “No patched driver, no VBIOS flash, nothing to redo when NVIDIA releases a new driver.” For an installed base of GeForce 30-series cards that launched in 2020, an uplift delivered through a boot hook, with no new hardware and no capital expenditure, is the kind of number that revalues used equipment.
How much faster does an unlocked RTX 3090 actually get?
It depends on which phase of inference is measured. The phases that issue FP16/BF16 matrix instructions, matrix kernels and long-prompt prefill, accelerated in every report the lane has collected. The phase that streams weights out of memory, decode, did not move, and the quantized INT4 and INT8 paths, which many local stacks run by default, were unchanged. An operator reading the headline percentage is sizing prefill capacity on cards already owned; an operator sizing a serving tier on tokens per second should read the decode columns, which are flat.
The origin post: half the instruction rate, by policy
An engineering account published on October 24 that “NVIDIA software-locks the FP16/BF16 instruction rate on consumer cards,” and its table leads with 87.5 to 157 TFLOPS BF16 on the 3090 Ti (origin post); the matching full-card ladder is the README’s, which takes the 3080 from 65 to 113 TFLOPS. The project’s own GEMM table puts the plain 3090 at 75 to 125 TFLOPS, a gain of 65 percent, and the 3090 Ti at stock 450 W power limits at 88 to 157 TFLOPS, a gain of 80 percent. The README frames the spread as a workload question: the result “depends on how much of your workload is FP16/BF16/TF32 matrix math, and on whether the card has the power headroom to run it.”
A fleet operator’s before-and-after
The first measured receipt in the lane arrived more than three days ahead of the origin post. An operator running a four-card 3090 fleet reported his cards at 1.9 times their BF16 tensor throughput after the module loaded: the bf16 tensor pipe from 82 to 155 TFLOPS, a cuBLAS BF16 GEMM at 8192 from 64 to 99 TFLOPS, and TF32 from 41 to 79 TFLOPS, on the same cards, the same driver and the same 300 W. The driver itself exposes the cap, and the post records the register read “FMLA32 = 1/2” before the unlock and full after a cold boot.
The real-world reading was smaller than the bench number, and the operator published his own miss along with the result: “Before installing I said +14 to 19% at 90K, so I was wrong.” On Strata running Qwen3.8 Flash-Next across two cards, he measured prefill 12 percent faster at 4K and at 10K tokens, and at 90K tokens 3,205 to 3,536 tokens per second, some 10 percent. He accounts for the gap himself: the matrix phases shortened by 23 percent, but they amount to only about 40 percent of the prefill path, while the int8 experts, the copies and the CUDA-core kernels gained nothing at all. On correctness his receipts are unusually clean: a log-prob dump over 1,996 teacher-forced positions “is the same file byte for byte as the stock run before the module.”
The same thread doubles as an installation guide, and it warns where the method fails. The module is written for kernel 6.16 and later; on Ubuntu 22.04 with kernel 5.15 it needs two fixes, a stub for the aperture header and a D0 transition for the card ahead of the check (setup notes). Stock initramfs ordering on that distribution runs udev before the modules load, so the NVIDIA driver claims the cards first and the unlock does nothing; the operator loads the module from an init-top script instead. And, in his words, “sudo reboot is not enough, the cards keep power. power off, then power on.”
The benchmark suite lands, with its error bars
On October 28 the lane got its first full suite: a completed 3090 unlock bench reporting 50 to 60 percent math unlock, image generation 40 percent faster, vLLM prefill 50 percent faster, vLLM at 64 concurrent streams 36 percent faster, and llama.cpp prefill 5 percent. The decode line reads 1 to 3 percent, and the operator enters that figure with an open question mark, which is the right hedge: decoding is bound by memory bandwidth, not by the instruction rate the selectors govern. The project README’s workload table brackets each of those readings on its own: LLM prefill on FP16/BF16 or AWQ/GPTQ stacks at plus 25 to 55 percent, time to first token 25 to 30 percent lower, image generation plus 30 to 55 percent, and quantized GGUF engines 0 to 15 percent, mostly at long context. The operator’s vLLM prefill figure sits at the top of the README’s band, not outside it, and his llama.cpp figure inside the quantized row — the spread is the error bar a buyer should keep in view, and each number is a single team’s single run, published with its method.
The framing that carried the lane to a wider audience arrived on October 27, attributing the effect to DeepSeek’s stack rather than to the kernel module: “Imagine how many other GPUs/computers are artificially capped.” (viral post) The post carries one figure and a link, and no measurement behind the figure; the receipts above tie the gain to the unlock module and the cards’ own speed selectors, not to a model change. The useful result of the week is the separation itself: the mechanism is settled enough to bank on, and the attribution is noisy enough to hedge.
What the measurements support, and what they do not
Three readings follow from the data. Prefill capacity rises materially on the affected cards, which is the phase that eats long documents. Concurrency scales with it, on the strength of the 64-stream result. Decode, by contrast, held its stock rate, and the README’s own table is explicit about the boundary: under “LLM decode / token generation (memory bound)” the change column reads “No change,” and the “INT8, FP8 and INT4 models” row likewise (README). The same table records “Outputs are bit-identical before and after; only the speed changes,” which matches the fleet operator’s byte-for-byte log-prob dump above — two independent parties, the project and an operator, arriving at the same correctness claim by different routes. The installed-base reading is the one to bank: the uplift arrives at the boot hook, on cards shipped with a capped rate by policy rather than by silicon, and no new equipment purchase is involved.
The risks are published as plainly as the gains. The register writes are volatile: the README states that “Suspend to RAM powers the cards off, which resets the speed selectors,” and in the boot flow the module must ride in the initramfs, loaded there before the driver binds a card, because “Loading the module by hand after boot does nothing to a card that nvidia has bound.” Issue #23 reported an in-place boot, with cards not fully cold, failing the unlock with a timeout and leaving the GPUs unusable by the driver until a full recovery reboot; the maintainer closed it within the hour, pointing to a fix commit, and a field report logs clean cold-boot-only runs since. Issue #28 files a compatibility report on a GA102-based OEM SKU: “unlock completes, selector verified held at runtime, but BF16 rate stays at half speed.” Per-card validation is therefore a precondition, not a suggestion; the reading varies by board, by power cap and by kernel version. The project’s own support table scores Ampere “Stable” on more than 100 user reports, Ada and Turing “Experimental,” and Blackwell “Not supported,” so the lane’s evidence stops where the 30-series ends.
Every suite in this lane remains a single-operator measurement, published with its method and not yet replicated across a second fleet at a second site. The numbers a purchase decision should be sized on are the ones a second operator confirms on the same card, and until then the picture stays a report of one. As firms such as 650 Group have been tracking in their AI infrastructure research, the distance between a vendor’s datasheet and its shipping configuration is where an installed base gets revalued.