RTX 5090 Tensor Core Unlock: Why the 3090 and 4090 Trick Does Not Work on Blackwell

Every GeForce card since Turing runs tensor math at half speed when it accumulates in FP32 instead of FP16. That is not a smaller chip; it is a switch, set at boot from fuses, and in October 2026 a wave of open-source kernel modules learned to flip it on RTX 20, 30 and 40 cards. VideoCardz ran the story as "up to 2× tensor throughput", and the question every RTX 5090 owner asked within the hour was the one in the title.

We own a 5090, so we measured. Two findings. The throttle is present on Blackwell, to the digit: our card runs FP32-accumulate tensor math at 51% of its FP16-accumulate rate, the same split NVIDIA prints in its own whitepaper. And it cannot be lifted, not because nobody has tried, but because the door the older unlocks walk through does not exist on this generation. Below is what we measured, how the unlocks work at the level a reader needs, what they are worth on the cards that have them, and the narrow list of local workloads where any of this matters.

Test rig. One RTX 5090 (GB202, 170 SMs, driver 610.57.04, CUDA 13.3), measured with our own read-only issue-rate probe built for sm_120 and with the driver's public rate query. Nothing was written to firmware, fuses or registers; nothing in this article is a how-to. The RTX 20, 30 and 40 figures are the unlock projects' own numbers and are marked as such.

The switch

Tensor cores multiply low-precision inputs, FP16, BF16, FP8 or FP4, and add the products into an accumulator. The accumulator can be FP16 or FP32. FP32 accumulate is the numerically safe mode, and it is what almost all training and much of full-precision inference actually uses.

On GeForce cards that path is deliberately held to half the FP16-accumulate rate; the workstation and datacentre parts run both at full rate. This is the product-segmentation knob NVIDIA has kept since the first consumer tensor cores in Turing, and it is printed in plain sight: the RTX Blackwell whitepaper lists the RTX 5090 at 419 dense TFLOPS for FP16 with FP16 accumulate and exactly half, 209.5, with FP32 accumulate.

The throttle is implemented as per-instruction "speed select" values the GPU reads from fuses at boot. Zero means full rate; non-zero divides the issue rate. That is what the unlock projects target.

What we measured on the 5090

Our probe issues raw tensor instructions with no memory traffic, so it reads the ceiling of each path rather than any library's share of it. Best of five runs, card boosting above its reference clock:

Every path lands 5 to 9% above the reference figure, which is the boost clock, so the probe is sound. The decisive ratio is 441.4 ÷ 224.3 = 1.97. FP32 accumulate runs at half the FP16-accumulate rate on this card, the same restriction documented on the 4090, where an independent read-only probe found 49.6% of peak on the same three paths.

The driver agrees. Its public rate query, which reads the selectors without touching anything, returns non-zero values for the FP32-accumulate tensor path and for three integer paths, and zero for everything else. One oddity for the record: the Blackwell selector for that path reads 3 where the 4090's reads 1, yet the measured penalty on both is 2×, not 8×. The encoding changed between generations and the public thread has not settled what it means; the safe statement is that the selectors are non-zero and the hardware penalty is half.

What the unlocks do, and where they came from

It started on mining cards. NVIDIA's CMP 170HX accelerators were memory- and feature-limited in firmware; a community project unlocked them, and the same researchers noticed the limiter was reachable through a flaw in a signed boot-time firmware component that runs on the card's security processor before the normal driver loads. From there it generalised.

The mechanism, at the level a reader needs: a bug in that signed boot blob lets chosen code run early enough, and with enough privilege, to clear a permission gate. Once the gate is open the ordinary driver can write the speed-select registers from the host, and the rate limit disappears until the next power-off. No BIOS flash, no patched driver, and nothing persists: pull power and the card is stock. The projects ship no NVIDIA firmware; they generate what they need locally from pinned driver packages with checksums.

Three projects, one per generation, all GPL-2.0, all Linux kernel modules that run from the initramfs before the NVIDIA driver binds:

The Ampere project is the one the others fork from, and it is the one with the most users: about 4,300 stars at the time of writing. All three carry the same warning, that tensor cores at full rate draw heavy power and the module is used at your own risk. The Ada project adds that the first attempt needs a true power-off, because a warm reboot is not guaranteed to reset the firmware state.

What the unlocks are worth, in the projects' own numbers

The figures in this section are self-reported by the projects, mostly from one card each, and we have not reproduced them. Read the measurement column: issue rate and GEMM are different things, and the gap between them is the point of this section.

The honest number is the 4090 row pair. The instruction issue rate doubles exactly; a real matrix multiply through cuBLAS gains 12 to 34% depending on shape, and at one common shape BF16 gains nothing. An FP8 GEMM, which the spec sheet implies is throttled too, moved by three tenths of a percent. Ampere users report the same pattern on language models: prefill 14 to 36% faster, decode unchanged, outputs bit-identical before and after.

Note what the table also says: an unlocked 4090 issues FP32-accumulate tensor math at 331 TFLOPS, and our stock 5090 issues it at 224. On this one path the older card, unlocked, beats the newer card, locked. A 5090 at full rate would do about 440 and be comfortably ahead. The newer card is faster on paper and loses in practice on this path, purely because it stays locked.

Why the 5090 stays locked

The RTX 20, 30 and 40 unlocks all enter through one specific signed boot firmware blob. On our Blackwell card that blob does not exist: the firmware directory for the GB202 ships a new bootloader, about three times the size of the old one, plus a separately signed firmware-management component the older cards never had, and no copy of the exploited blob is present for any Blackwell chip on the disk. There is no vulnerable door to walk through.

The public research thread on a 5090 port, issue #12 on the Ada project, opened on 25 October and reports the same wall from several contributors, all of whom read the same selector values we did. Host writes to the speed-select registers and to the permission gate are silently dropped on Blackwell. Attempts from UEFI and from the bootloader stage failed. Editing the backing fuses directly stops the card from starting at all: reversible, but a hard failure rather than a quiet no-op. A separate project that tries to unlock virtual-GPU features on Blackwell is blocked the same way, with the card's management firmware crashing when the fused-off registers are touched, a second data point that GB202's fuses are enforced below the driver.

The shared conclusion is that a Blackwell unlock would need a new firmware bug in the new boot chain, not a port of the register trick. The Ampere break only happened because NVIDIA once shipped a debug build of the vulnerable firmware encrypted under a known test key, which gave researchers plaintext to study. Nothing equivalent is public for Blackwell. One contributor has floated voltage glitching; nobody has shown it working. The thread is days old and moving, so "locked" is a dated statement, not a verdict. But as the next section covers, even a clean break would move less than the headline suggests.

What it would change for local inference

The unlock helps a workload only if it clears two bars at once: it has to be compute-bound, so that tensor throughput is the real limit, and it has to run in BF16 or FP16 with FP32 accumulation, the one path the fuse throttles. Miss either bar and the unlock does nothing. Most of local inference misses one.

Token generation, the part you feel while chatting, is limited by memory bandwidth, not tensor throughput: the GPU streams weights out of VRAM while the tensor cores sit partly idle. That is why the Ampere reports show decode unchanged. And most local models are quantised to 4 bits to fit, which puts them on an unthrottled path regardless: INT4 in GGUF, AWQ and GPTQ, and increasingly NVFP4 and MXFP4 on Blackwell, which accumulate in FP32 but run on the dedicated FP4 tensor path the whitepaper lists at full rate. INT8 and FP8-into-FP16 are unthrottled too. A 4-bit model already runs flat out, and an unlock adds nothing to it.

That leaves a real but narrow set of jobs where it helps:

• Prefill of a full-precision model. Prompt processing is compute-bound, and in a BF16 or FP16 model the attention and MLP matmuls hit the throttled path. Long-context summarisation, RAG over large chunks, feeding a repository, long system prompts. The Ada precedent says 12 to 34%, not 2×.
• Batched and offline inference. Several concurrent requests, or grinding a dataset: classification, extraction, evals, synthetic data, embeddings at volume. Throughput-bound and prefill-heavy, usually in FP16 or BF16 for quality. A stronger case than chat.
• Image and video generation. Diffusion models run FP16 with FP32 accumulate and are compute-bound on the denoiser. The Ampere reports called out diffusion gains explicitly, and on a single card this may be the most felt improvement; the language-model coverage keeps forgetting it.
• Vision-language prefill. An image becomes a large block of tokens, and processing them is a compute-bound FP16 prefill.
• Fine-tuning and LoRA. Not inference, but training leans hardest on BF16 with FP32 accumulate and is compute-bound. This is where the switch matters most.

And where it is dead weight: single-user chat decode, which is bandwidth-bound and is what most people actually run; any 4-bit model; and FP8 inference, empirically unchanged on Ada.

There is a tension worth naming for 5090 owners specifically. The unlock rewards running models in full BF16 or FP16, but 32 GB pushes you toward 4-bit to fit anything large, which is exactly the regime the unlock cannot touch. The sweet spot would be models small enough to run in BF16 on the card, the 14B class and a tight 24 to 27B, used in a compute-bound way: batch, long prefill, or image generation, not single-stream chat. On a 3090 or 4090 that sweet spot is real today. On the 5090 it is hypothetical.

The verdict

• The restriction is on the 5090, measured on our card at 51% and matching NVIDIA's own table. It is the same lock as on the 4090.
• No unlock exists for Blackwell, and the reason is structural: the exploited boot firmware is not there, register writes are dropped, and fuse edits stop the card from starting. A new firmware bug would be required, and none is public.
• On the cards that have it, the honest gain is 12 to 34% on BF16 and FP16 prefill and GEMM, roughly nothing on decode, 4-bit models or FP8, and the biggest felt win is probably diffusion, not chat.
• If you bought a 5090 for local chat, you have lost nothing; the models that fit it run on paths that were never throttled. If you bought it to fine-tune or to batch-process in BF16, you are leaving half the tensor rate on the table, and only NVIDIA can give it back.

Related reading

• DeepSeek V4.1 Flash on Nvidia 5090? — what actually fits the card
• AI Workstation Comparison: RTX 5090 vs GB10 (HP ZGX) — memory against bandwidth, which to buy
• Prompt Processing vs Token Generation: the Two Speeds of an LLM — why prefill is compute and decode is bandwidth
• 4-Bit Quantization Decoded: INT4 QAT, MXFP4, and NVFP4 — INT4 QAT, MXFP4, NVFP4, and which tensor path each takes
• Qwen3.8-27B Is 2.3× Faster With One Flag — Do You Need DFlash2? — a speed-up that does exist on the 5090
• RTX 5090 Prices: 3× Launch in the US, 2.4× in Europe, and Still Climbing — what the locked card costs today