gpu-unlock in 2026: Is Your GeForce Running AI at Half Speed? How to Remove the Limit on Linux
Hello HaWkers, a repository created on October 18 passed 13,000 stars on GitHub in under two weeks with a provocative line: "Your GeForce runs AI at half speed". gpu-unlock, by developer Zagitta, is a Linux kernel module that removes a factory limit from GeForce RTX 20, 30 and 40 cards and promises up to double the throughput on the floating-point math used in AI.
Has your graphics card been running with the handbrake on this whole time? In this article you will learn what this limit is, which workloads actually show a gain, how to test it in a way you can undo, and why I would not install it on my work machine without thinking twice.
What the Tensor Core Limit Is
Since the Turing architecture, NVIDIA RTX cards have had units dedicated to multiplying matrices: the Tensor Cores. Most training and a good share of floating-point inference runs on them.
According to the project, GeForce cards ship with these cores limited to half rate when the math uses FP16, BF16 or TF32 with FP32 accumulation, which is exactly the most common combination in non-quantized AI. The same silicon sold as the RTX A series, the professional line, runs at full rate. The author's explanation is blunt: market segmentation, so that companies buy the more expensive cards.
A few terms matter here:
- FP16: 16-bit floating point, with less range and a small size.
- BF16: 16 bits with more range, widely used in training.
- TF32: an NVIDIA format that accepts FP32 inputs but multiplies with the 10-bit precision of FP16.
- FP32 accumulation: the result is summed in 32 bits, which avoids precision loss across the long sums of a matrix multiplication.
The limit sits in the instruction issue rate. The card does not get smarter or gain memory: it simply starts issuing these instructions at the frequency the hardware already supported. That is why the project claims the output is bit-for-bit identical. The speed changes, not the result.
How gpu-unlock Removes the Limit
The work happens before the NVIDIA driver loads. According to the project documentation, the sequence is:
- The
gpu_unlockmodule goes into the initramfs and loads beforenvidia. - It runs the firmware step that gives access to the protected registers.
- It writes the speed selectors (SS0 and SS1) with the full-rate values.
- It performs a PCIe function reset (FLR).
- The official driver, with no changes at all, takes over the card as usual.
This explains three things that stand out in the README: no VBIOS is flashed, no driver is modified, and nothing has to be redone when a new driver comes out.
The most delicate point is step 2. The technique comes from earlier research on CMP mining cards, such as the CMP 170HX, and uses a stack overflow bug in the Booter, the signed firmware that runs on the GPU's security processor. In other words, this is not a tweak NVIDIA planned for: it is a security flaw used in favor of the card's owner. The author himself said on Hacker News that the exploit ideas are not his and that the unlock "simply flips 2 bits".
Which Cards Are Covered
Linux is the only official platform. The table below summarizes the state of the project at version 2.0, released on October 27:
| Generation | Examples | Status |
|---|---|---|
| RTX 30 (Ampere) | 3050 to 3090 Ti, laptop 3070 and 3080 | Stable, with more than 100 reports |
| RTX 40 (Ada Lovelace) | 4050 to 4090 D | Experimental |
| RTX 20 (Turing) | 2060 to 2080 Ti, Titan RTX | Experimental |
| RTX 50 (Blackwell) | Entire lineup | Not supported |
RTX 50 owners are left out, and the author considers it unlikely that this will change. On laptops the situation is uneven: many models power off the dedicated GPU when it goes idle, and that silently wipes the unlock.
Before anything else, find out your card and its PCI address:
# Card name, PCI address, driver version and power limit
nvidia-smi --query-gpu=name,pci.bus_id,driver_version,power.limit --format=csv
# Full address in the format gpu-unlock accepts (e.g. 0000:21:00.0)
lspci -Dnn | grep -i nvidiaWhere the Gain Really Shows Up
This is the part the catchy headline hides. "2x" is the peak instruction rate, not the time your task will take. The README itself separates the two worlds.
Dense matrix multiplication in BF16, with the original power limit:
| Card | Before | After | Gain |
|---|---|---|---|
| RTX 3060 12 GB | 27 TFLOPS | 51 TFLOPS | +87% |
| RTX 3070 | 40 TFLOPS | 72 TFLOPS | +81% |
| RTX 3090 | 75 TFLOPS | 125 TFLOPS | +65% |
| RTX 4080 | 104 TFLOPS | 193 TFLOPS | +87% |
| RTX 4090 | 165 TFLOPS | 329 TFLOPS | +100% at peak |
Now the real workloads, always according to the reports collected by the project:
| Workload | Typical gain |
|---|---|
| LLM prefill in FP16/BF16 (vLLM, PyTorch, Transformers) | +25% to +55% |
| Image generation (SDXL, ComfyUI) | +30% to +55% |
| LoRA and fine-tuning in BF16 | +25% to +50% |
| Video generation (Wan 2.2) | +15% to +20% |
| llama.cpp and Ollama with quantized GGUF | 0% to +15% |
| LLM token generation (limited by memory) | None |
| INT8, FP8 and INT4 models | None |
| Games and CUDA in FP32 | None |
Look at the Ollama row. If you run a quantized model at home, as most people do, the gain tends to be small or zero. Anyone who has already set up local AI on the GPU with Strata knows that response speed usually runs into memory, and this limit has nothing to do with memory.
Outside tests back up the caution. Notebookcheck reported that a user with an RTX 3090 went from 77.5 to 129.6 TFLOPS in BF16 but saw only a 16% gain in prompt processing with long context, and token generation stayed practically the same. On the RTX 4090 the bottleneck becomes power: the fork for the 40 series records that the instruction rate doubles, while real matrix multiplications gained 12% to 34% in FP16 at some sizes and nothing on a 4096³ matrix in BF16. The same record shows 346 W versus 313 W in a comparison with the stock card.
It is also worth remembering that almost all of these numbers are self-reported, on few cards and few runs. They are not independent lab benchmarks.
Measure Before You Install
Without a baseline you will not know whether you gained anything. The script below measures a matrix multiplication in BF16 and in FP32 with PyTorch. FP32 works as a control group: if BF16 goes up and FP32 stays flat, the unlock is doing what it promises.
import time
import torch
# Matrix size: use a value that fits comfortably in your VRAM
N = 4096
RODADAS = 20
def medir(dtype):
a = torch.rand(N, N, device="cuda", dtype=dtype)
b = torch.rand(N, N, device="cuda", dtype=dtype)
# Warm-up so the initial allocation does not skew the measurement
for _ in range(3):
torch.matmul(a, b)
torch.cuda.synchronize()
inicio = time.perf_counter()
for _ in range(RODADAS):
torch.matmul(a, b)
# Without synchronizing, the clock would only measure command submission
torch.cuda.synchronize()
duracao = time.perf_counter() - inicio
# A dense multiplication performs about 2 * N^3 operations
return (2 * N**3 * RODADAS) / duracao / 1e12
print(torch.cuda.get_device_name(0))
for nome, dtype in [("BF16", torch.bfloat16), ("FP32", torch.float32)]:
print(f"{nome}: {medir(dtype):.1f} TFLOPS")Run it three times, save the results and repeat everything after the unlock. The absolute number may not match the README table, and that is fine: what matters here is the comparison on the same machine, at the same temperature and with the same power limit.
After that, measure the task you actually use. Timing real work tells you more than any TFLOPS figure:
# Records the total time of your real workload before and after the unlock
/usr/bin/time -v python meu_treino.py 2>&1 | tee resultado-antes.log
# In another terminal, tracks power, temperature and clock during the test
nvidia-smi --query-gpu=power.draw,temperature.gpu,clocks.sm --format=csv -l 2An open issue on the project reports clock telemetry stuck at 210 MHz after the unlock on an RTX 3090, with normal performance. So trust the execution time more than a single monitor reading.
How to Install on Linux
If the measurement showed your workload can benefit, installation follows the official README. Use only the original repository. The FAQ warns that the project has no website, coin or installer, and it urges great care with the Windows installers going around.
git clone https://github.com/Zagitta/gpu-unlock
cd gpu-unlock
# Read what will run with sudo before executing it
less Makefile
# Detects Arch, Debian/Ubuntu or Fedora/RHEL, builds and installs the packages
make installmake install downloads the NVIDIA inputs and generates the firmware locally. Installing, however, does not activate anything: the module only acts when the kernel command line asks for it.
# Debian, Ubuntu and Mint: edit the file and add the parameter,
# keeping the options that already exist
sudo nano /etc/default/grub
# GRUB_CMDLINE_LINUX_DEFAULT="quiet splash gpu_unlock.targets=all"
sudo update-grub
# Fedora and RHEL
sudo grubby --update-kernel=ALL --args="gpu_unlock.targets=all"With more than one GPU, prefer targeting the card by its PCI address (gpu_unlock.targets=0000:21:00.0). That way you test one at a time. After rebooting, check the result:
# Shows what the module did on this boot
journalctl -k -b | grep gpu_unlock
# Confirms the nvidia driver took over the card normally
lspci -nnk -s 0000:21:00.0To roll back, remove gpu_unlock.targets= from the kernel command line. For a single boot, you can delete the parameter on the bootloader's edit screen, which saves you if the machine does not come up. Removing the packages takes out the module and the initramfs changes.
The Risks You Are Taking On
There is no free lunch here, and the project's optimistic FAQ does not tell the whole story.
Hardware. The author considers damage very unlikely, because thermal throttling and power control keep working. Other projects in the same family are less relaxed: the turing-unlock README warns that using it may damage the hardware. An old card, with a tired fan or a power supply at its limit, is the worst-case scenario for pulling more load out of the chip.
Stability. There are reports of real failures. One issue describes five RTX 3090 cards behind a PCIe switch where the entire switch went down with Xid 79 error after a successful unlock. Another reports that, in ESXi passthrough, the original state did not return after removing the parameter and rebooting the guest machine. A machine serving production is no place for this test.
License and warranty. The module is GPL-2.0, but NVIDIA's firmware remains under its own terms, and the project itself says it does not claim redistribution approval. I found no public position from NVIDIA and no information about warranty. Treat it as your own risk, especially on a new card.
How long the trick lasts. NVIDIA may change this in the future. The RTX 50 line is already out of reach, and new firmware or changes in the loading process could end the fun without warning.
So who does this make sense for? I would sum it up like this:
- Worth testing: RTX 30 on a dedicated machine, training LoRA, generating images or running prefill in FP16/BF16.
- Think it through: experimental RTX 40 and RTX 20, laptops and multi-GPU machines.
- Not worth it: people who only game, people who only use quantized GGUF, and any server someone depends on.
What This Says About the GPU Market
The bigger story is segmentation. Making a single chip and locking features in software is an old practice and, for the seller, it makes perfect sense: the manufacturing cost is the same and the price follows what each customer will pay. With local AI, that line started to bother a lot of people, because an enthusiast with a used 3090 now does work that used to be exclusive to professional cards.
The 13,000 stars show how strong that desire is. The speed at which forks for Ada and Turing appeared, plus an experimental Windows port, suggests a whole community was waiting for this. And there is a technical irony in the middle: a project that increases performance relies on a security flaw in the firmware that was supposed to protect the card.
For developers, the practical lesson is a different one. Before buying new hardware or installing a hack, find out where the real bottleneck of your workload is. In many cases memory is what rules, and no core unlock changes that.
Outlook
The things to watch now are NVIDIA's response, which has not yet appeared in the sources I consulted, and the arrival of more rigorous independent benchmarks. If the prefill and image gains are confirmed in the lab, used RTX 30 cards could get an interesting second life for people doing local AI. Until then, treat the project's numbers as a promise and the ones from your machine as the truth.
Let's go! 🦅
📚 Want to Keep Up With What Is Coming?
This article covered gpu-unlock and the Tensor Core limit on GeForce cards, but the ecosystem changes every week and not everything becomes an article here.
On X I share what I am testing, behind the scenes of my projects, and news that shows up before it becomes a post.
Follow Me There
💡 Daily content about development, career and the tools I actually use