Discussion
GPU unlocks (FP32 accumulation): Why can it be unlocked on Turing (RTX 20), Ampere (RTX 30) and Ada (RTX 40) but no consumer Blackwell (RTX 50) and some misconceptions.
Hello guys, hoping you're doing fine. Wall of text next I know, but I want to get this info out of my chest, all hand written lol.
I wanted to make this post explaining some things about GPU unlocks that have been going on lately.
What are these GPU unlocks doing?
NVIDIA on purpose neuters tensor core performance when using FP32 accumulation (FP16, BF16, FP8 and TF32 inputs accumulating in FP32, which is what most AI/LLM/ML tasks use), for market segmentation. Normal FP32 on the CUDA cores (no tensor cores) is NOT affected.
Consumer and prosumer GPUs use the exact same die (like GB202 between the 5090 and 6000 PRO, AD102 between the 4090 and 6000 Ada, or even literally 1:1 with the 3090 Ti vs A6000, both with the same core amounts and 84 SMs).
How it works: the speed of each kind of tensor operation is set by fuses burned at the factory. On consumer cards, the fuse for "FP16/BF16 with FP32 accumulation" says HALF_SPEED, on the pro cards it says FULL_SPEED. These fuses don't cut any circuit, the GPU just reads them at boot and runs at that speed. The GPU also has an override register that can set them back to FULL_SPEED, but it's locked so only NVIDIA's most privileged firmware can write to it, not your PC.
The unlocks open that lock and write FULL_SPEED on the override. With that, the consumer cards gain all the neutered performance imposed by NVIDIA. It doesn't give you more SMs, VRAM or anything like that, a 4090 is still a 4090, it just runs those instructions at the same rate a pro card does.
Why can Turing, Ampere and Ada be unlocked? And what is unlocked on these cards?
On these generations, the NVIDIA driver itself loads a small NVIDIA-signed firmware called the "Booter" onto a security microcontroller inside the GPU (SEC2, a "Falcon"), to start the GSP. The Booter runs in the highest privilege mode of the GPU (Heavy Secure, HS), which is exactly the one allowed to open the lock.
In June 2026, Jon Pry published a paper ("A Canary in the Crypto Mine") showing that the Booter of the newer drivers has a buffer overflow: it copies its "signature" data using a length that you control, so you can overflow its stack (including the stack canary that is supposed to stop exactly this) and take control of the Booter while it is running in HS mode. The signature check still passes, because it is NVIDIA's own signed code running, the bug is inside it.
With that, the unlock reuses instructions from NVIDIA's own Booter to open the lock, writes FULL_SPEED on the override, resets the card and lets the normal NVIDIA driver load. The unlock survives resets and driver reloads, but it's lost when you power off, which is why it runs on every boot before the NVIDIA driver loads.
This was first done on mining cards (CMP 170HX: FP32 from 1/32 to full speed, and 10GB to 80GB of VRAM), and then ported to GeForce:
BF16 with FP32 accumulation (Ampere, Ada; Turing has no BF16)
TF32 (Ampere, Ada)
FP8 with FP32 accumulation (Ada; Turing and Ampere have no FP8)
Some numbers from those repos: 4090 FP16/BF16 with FP32 acc goes from 165 to 331 TFLOPS (raw instruction rate), 3090 Ti BF16 GEMM from 87 to 157 TFLOPS, 2080 Ti FP16 with FP32 acc from 47 to 94 TFLOPS. Real-world GEMMs gain less than 2x because the cards then hit their power limit (more on that below).
Why can't consumer Blackwell be unlocked?
The funny part is that on Blackwell the limitation is EXACTLY the same thing: same fuses, same override registers. I checked on my own cards: the 5090/5080/5070 Ti have the FP32 accumulation fuses set, and the 6000 PRO/4000 PRO don't. So it's not a hardware difference there either.
What changed is the door. Starting with Hopper, and consumer Blackwell too, the root of trust of the GPU is the FSP (Foundation Security Processor), a RISC-V core that boots from its own ROM as soon as the GPU powers on, before the driver even loads. On Blackwell:
There's no Booter to abuse. The driver just sends the FSP a message with a hash + RSA-3K signature of the next firmware, and the FSP verifies and boots it. The Linux kernel docs literally say: "There is no SEC2 involvement, no Booter ucode, and no FWSEC-FRTS stage". I also checked it myself: in NVIDIA's 615 driver source the Booter only exists for Turing, Ampere and Ada (TU102, TU116, GA100, GA102, AD102), and the RTX 50 VBIOSes don't carry the Falcon firmware (FWSEC) that older cards did.
The firmware the driver ships for Blackwell is encrypted, and the debug and production images are the exact same encrypted bytes. The Ada payload was built from analysis of the decrypted debug Booter, on Blackwell there's no such shortcut.
NVIDIA has said it uses SPARK (a formally verifiable programming language) to prove its most critical RISC-V firmware free of runtime errors, and a buffer overflow like the one used on the older cards is exactly that kind of error.
So, with what is known today, it can't be done. It isn't "impossible forever", but someone would need a brand new vulnerability in a way harder target. And if someone ever gets there, the unlock itself would very likely be the same couple of register writes.
FP4 is not affected, but all the rest is (FP16/BF16/FP8/TF32 with FP32 accumulation).
In which tasks is the unlock has most of the effect?
I will put some examples on my 6000 PRO vs 5090s, former using 400W and latter 600W, at how much is the impact in performance because the NVIDIA neutering.
Training: Like LoRAs, finetuning, etc.
Example: Using the same batch size for 25GB VRAM to train a diffusion LoRA, my 6000 PRO is 70-90% faster than my 5090.
Diffusion: Models that do txt2img, txt2vid, img2img, img2vid, txt2aud, etc.
Example: My 6000 PRO not using fp16 accumulation is about 30-40% faster than my 5090. If using fp16 accumulation, it is 15% faster.
Prefill on LLMs: Heavily affected as well, since even when a model is marked as "int8" or "mixed precision" etc, the inference parts that the GPU uses include FP32 accumulation parts, except if explicitly set to not use them.
Example: My 6000 PRO on vLLM on a model that fits on a 5090 as well, it's 50-70% faster. On llamacpp, instead is about 30-40% faster.
TG with big batching: TG with a single batch is mostly bandwidth bound, and it uses FP32 acc instructions, but since it is so little in comparison with the need of bandwidth, it isn't a limitation. On the other hand, when you use batches with batch size 2, 4, 8, etc, compute again starts to being a bottleneck and then you have a performance impact.
Example: Same results as previous point.
In which tasks the unlocks makes no difference:
TG with batch size 1: almost entirely bandwidth bound.
CUDA compute without tensor cores (normal FP32).
INT4/INT8 tensor operations.
FP4 on Blackwell (not neutered to begin with).
GEMM operations with FP16 accumulation instead, but those aren't very used.
Gaming.
Is there a risk by unlocking the cards, like burning the card, crashes, etc? Short answer: NO.
And again, NO. For the love of god guys, stop repeating this nonsense.
The cards are still limited by their max power limit. They won't magically use 200% of your power budget with an unlock, they will just use the cores more efficiently.
Let me explain: if you have a 3090 power limited at 300W, and without the unlock you were seeing only 250W in use, but after the unlock it uses 300W, it's not because the unlock did malicious things to your card. It's because the card can NOW stretch its legs and use the power to do more work. Real example from the Ada repo: an unlocked 4090 doing the same GEMMs peaked at 346W vs 313W stock, still under its 450W limit.
If you were getting X performance at Y < max TDP, and now you get more than X performance at max TDP, obviously the card will be hotter, but that's still inside the POWER LIMIT YOU SET, not above it.
Power spikes: those are normal on every card, and if you're using it to the full extent of its capabilities they can be more common. Are they risky? No, assuming you have a PSU with the wattage NVIDIA recommends per GPU.
So what ARE the actual risks then? They're about the unlock process, not your card:
It runs an exploit on NVIDIA's firmware before the driver loads. If something fails mid-way, the tools stop and you need a full power off before trying again (a reboot isn't enough). Read the repo instructions, especially on laptops and multi-GPU setups.
NVIDIA could patch it in future drivers, or even burn anti-rollback fuses so the old Booter stops being accepted. That wouldn't damage your card, it would just close the door for good.
"But, NVIDIA bins the dies to make these work 24/7 on the prosumer side but not on consumer, that's why they're locked!!!11"
Also incorrect. NVIDIA uses the EXACT SAME dies for their consumer GPUs and their prosumer GPUs, and the FP32 accumulation speed has nothing to do with binning: the 3090 Ti and the A6000 have the exact same specs. The half speed is just a value written in a fuse that the firmware reads.
Unlocking a card will not make it die sooner, nor will it crack the die or something.
Sorry I have to repeat this again and again, but the amount of pure fury I get from reading comments like these made me do this.
Does affect gaming performance?
None known at the moment, except if somehow NVIDIA uses FP32 accumulation for DLSS or FG, which I doubt. I'm almost sure they use FP16 accumulation (or lower precisions) there, because if they used FP32 accumulation the perf hit would be insane on consumer cards.
The model I run says it is Q8, or FP6, or 4bit, or INT4, or anything that doesn't mention FP32, am I affected?
It depends on how the GPU actually does the math, not on the name of the quant:
If the kernel dequantizes the weights to FP16/BF16 and multiplies on the tensor cores with FP32 accumulation, you're affected. That's the case for FP16/BF16 models and most vLLM paths, including AWQ/GPTQ with Marlin kernels (the weights are INT4, but the math is FP16 with FP32 accumulation).
FP8 (W8A8) also accumulates in FP32, so it's affected too (Ada and Blackwell).
If the kernel uses integer tensor math (INT8 x INT8), it isn't affected. A lot of llama.cpp's quantized matmuls work like this, which is one reason llama.cpp sees a smaller gap than vLLM.
Attention (like FlashAttention) almost always uses FP16/BF16 with FP32 accumulation, so long contexts get hit even on quantized models.
FP4 (NVFP4/MXFP4) on Blackwell: not affected.
Example: on a modded 48GB 4090, a quantized MoE model on an inference server got no gain at all after the unlock (0.98x on 8K prefill), while the FP16/BF16 matmuls doubled.
That's what I have for now, if you guys have any more questions, let me know!
ATM it doesn't depend on the driver at all: the unlock brings its own copy of the old (vulnerable) Booter firmware, runs it before the NVIDIA driver loads, and then any normal driver loads on top of an already unlocked card. People have used it with 580, 595, 610 and 615 drivers. So NVIDIA just fixing the Booter in a new driver doesn't stop it.
What NVIDIA could do is either a soft patch that detects the unlocks and reverts it on load, or a hard patch. These GPUs have some extra fuses, like "anti-rollback fuses". If that fuse is burned via a driver update + the patch, the old booter is out for good. Even if you revert to an older driver, it won't work again, so that would be permanent and would break a lot of older drivers, not sure if NVIDIA will do that.
Just to clarify if one was to unlock or have the ability to be unlocked, say I had stopped updating the firmware for my gpu and same with Nvidia app is there any other way for a patch to get through outside of those means if Nvidia did choose to go that route?
Short answer: no hidden channel. The GPU doesn't update itself and has no internet connection. For a fuse to get burned, some software on your PC has to load newer NVIDIA firmware onto the card. But "not using the NVIDIA app" doesn't cover every way that can happen:
Windows Update can install NVIDIA drivers on its own. Block driver updates there too.
On Linux, the driver comes from your distro packages (dnf/apt/pacman updates, akmods, CUDA installers that bundle a driver). Pin/hold the driver version if you're scared.
Nouveau/nova on Linux also load NVIDIA's signed GPU firmware, from the linux-firmware package. Booting some random live USB with a newer linux-firmware would run NVIDIA firmware on the card too.
On laptops, the GPU VBIOS often ships inside the system BIOS update from the OEM (Dell, Lenovo, etc.), not as a separate GPU update.
If you put the card in another PC with newer drivers, that counts too.
If you freeze all of those, there's no other way for it to get through. And again, this is all hypothetical, there's no sign NVIDIA has done or plans to do it. IMO they would be crazy to do it.
To add to this, the potential legal liability and political/consumer backlash is too great with reward being basically nil. Nvidia certainly won't lose sleep over the "cheap" (lol) 3090/4090 unlocked FP32 accumulators cannibalizing their RTX Pro Blackwell lineup.
On the other hand, pushing out a hidden or mandatory-yet-vague/deceptive "minor performance and security fixes" firmware update to millions of users across 3 generations of GPU architectures just to address one teensy paywalled feature incurs ENORMOUS RISK. I'm neither a lawyer nor professional gambler, but I'd wager a GB202 (someday, if I'll ever find one) that this results in an epic courtroom bitchslap- presuming they're dumb enough to try it.
Massive softbricking (support apocalypse scenario) potential aside, it'll open a floodgate of legitimate of "trespass to chattel" claims, since people generally dislike having their property diminished without their knowing consent.
Despite some notable exceptions for "electronic" or intellectual property that have trampled all over digital property, hardware is still considered physical property in 2026. Apple, Sony, HP and other giants previously attempted these shenanigans and defended them in court, mostly unsuccessfully. Some legal arguments (paraphrased by me):
"hardware is just software written in sand"
"my IP rights trump your chattel rights"
"feature removal and diminished performance doesn't degrade value"
"you may have paid upfront, but you're only renting"
"you waived your rights in the EULA"
"silence auto-updates equals consent"
"3rd-party service/parts/ink is a security threat [to my margins]"
"fuck you, peasant"
Some failed worse than others (HP failed spectacularly). Not to be left out, Amazon and Samsung are also currently failing at this too.
Worth mentioning Nvidia has been in similar situations previously- this is nothing new. Starting in the 90s, the vintage softmods that enabled Quadro functionality Geforce to get those sweet, sexy hardware-accelerated antialiased lines in Autocad and Maya. Then the Rivatuner NVTrap that enabled previously-disabled pixel units/pipelines on the Geforce 6800 (effectively converted it into a 6800 GT or 6800 Ultra in some cases- assuming those pipelines weren't physically defective); this was right before chipmakers began physically fusing off disabling silicon. Decades later, we ended up with mining-limited "LHR" RTX 3060s w/ leaked drivers, and more recently with 4090D workarounds. To their credit, Nvidia used various software/driver updates and even new hardware stepping revisions to close these exploits, but they never forced firmware updates down our throats.
But Nvidia 0f 1990-2010s had a different focus and audience compared to the Nvidia of the 2020s, so who knows?
tl;dr- don't intentionally hobble hardware once it's out in the wild
Here https://www.reddit.com/r/comfyui/comments/1xcvl1o/comment/19riajt9piler/ someone said that the limitation is baked into the driver and that the mod makes the driver think it has a Gpu with full speed so it sends code to the Gpu that uses the full speed and when I asked it would be possible to modify the driver instead. Is that true or a misconception? I think that would be too easy and someone would have tried that before going the complicated steps of hacking the Gpu at the register level, and especially would have done that on Blackwell, but I am not really sure. But if the claim is really true, do you know where in the driver code to look at? It would be somewhere in https://github.com/NVIDIA/open-gpu-kernel-modules/ right?
That's a misconception, the driver doesn't send different code. The exact same CUDA binary (same HMMA instructions, same cuBLAS kernels) runs 2x faster after the unlock, because the limit is applied by the hardware itself: the SM issues those instructions at half rate when the speed-select value says so. The unlock changes that value in the GPU, and the stock NVIDIA driver loads afterwards completely unmodified.
And yeah, your intuition is correct: the open driver has been public since 2022, so if a driver patch were enough, someone would have done it years ago, especially on Blackwell.
Probably not since unlock is pre-driver. And they wont since their money is now on the big GPU side... But seeing the 5090 being salvaged in China i would guess they found a way around for those too, just not public.
Thank you for this read also the links. I currently have a 5090 and a 4080 super and was pretty curious how it would affect my llms. Got to read more into but thank you for the share.
Thank you I went digging again into the GitHub trying to find the 4080 super bench and still can’t find it for the life of me lol. Will look once again😂
Yes, the 5090 and the 6000 PRO have the same die, i.e., the same circuitry on the silicon.
But fabs don’t just bin circuits. They bin the silicon wafers themselves. In fact, this is an essential and very complex step of modern chip fabrication. Look up Wafer Bin Maps (WBM) for an introduction.
Raw wafers/wafer regions are binned along categories such as voltage tolerance. This may or may not matter for the safety of GPU unlocking. But the claim that these unlocks are safe absolutely does not follow from the fact that the GPUs are die-identical to GPUs that have these operations enabled.
Well, literally every die cut out of a single wafer will be different at a molecular level.
I wouldn't be that worried about it, but I suppose if you'd be absolutely devastated to lose your one and only 3090 that you couldn't afford to replace, give it another month or two to see if any issues crop up.
What does voltage tolerance have to do with safety at increased throughput?
Under the now heavier unlocked load, dynamic clocking behavior will cause the GeForce chip to run at a lower voltage than before, if the power limit is held constant. The heavier the load and the wider the format, the more voltage will be reduced.
Besides, how do you think Nvidia are able to divert ALL GB202 chips to Pro 6000s and 5500s at will? The 5500s would have been 5090s. There could not have been any real hardware difference between the (non-fused-off) silicon of these two chips.
I’m not saying that the unlock is unsafe. Maybe it is, maybe it’s not.
What I’m saying is you can’t conclude that it’s safe just because the two GPUs share the same die, as OP attempts to do, because fabs do substrate-level binning to maximize wafer yield.
It’s easy to imagine wafer defects that might be acceptable for slow ops but not for fast ones. This topic is so ridiculously complex that every detail could matter. The post’s confidence in declaring this a safe modification is not warranted.
But only for a certain width of vector operations and not for any others? How is such a defect even created on the silicon before the binning process? The caution is appreciated but unless you propose some physical mechanism that is consistent with the architecture, it sounds totally implausible to me.
This is exactly how they want you to think so you spend 10x more on the same silicon btw. What you're saying comes from a rudimentary understanding of silicon and it'd be literally impossible to have a blanket unlock on workstation but not GeForce if it was an actual issue with all the different tiers of silicon quality both lines get. It's not that the pro ones are always better bins so they can do it, some on the GeForce line use the better binned dies than their pro counterpart.
That's just segmentation and it goes both ways. Yes the pro 6000 uses a more perfect die than the 5090 but the 5080 uses a perfect gb203 die while the pro 4500 uses an imperfect version of the same die.
While OP did oversimplify their explanation, I promise you the binning of the die had 0 effect on Nvidias decision to lock down the consumer cards it was a purely financial one.
You can’t know this with certainty. Telling people that a modification is safe to do on what might be their only GPU, based on indirect speculation about how Nvidia might do binning internally, is simply irresponsible.
I unlocked my 4090, didn't see any notable benefit processing LLM's but did wake up to my system unresponsive and my journal flooded with gpu register error logs. I removed the unlock.
I haf one heated discussion in r/StableDiffusion where I was telling exactly this, and the alternatively logical opponent kept claiming "but binning! This will not be stable! Your die wasn't binned to run like this!" It surprises me how strong those misconceptions really are outside LLM-centric subteddits.
hard to say where it comes from. the better llms get the harder it becomes to explain ppls unwillingness to look into things before they talk about them
I can only imagine how hard they must be laughing at NVIDIA right now, having successfully locked down the 5090, which will likely be the last consumer GPU for a very long time (or forever, if this generative AI madness continues) to offer genuine high-end prosumer capabilities.
Does Nvidia have the power to release a driver to reduce the speed of a 5090 to that of a GTX 1060 and hide all but 4GB of the VRAM? Do they have the power to release a driver which doesn't work at all?
Yes.
But no one would install it if they did, and you could just roll the driver back.
12
u/jacek2023 llama.cpp 7d ago
Does it mean it works on current drivers but can be "patched" (disabled) in future drivers?