Quick Answer: The RTX 4090 tensor unlock in the gpu-unlock-ada project is an open-source Linux kernel module that claims to roughly double FP16 and BF16 tensor throughput with FP32 accumulation. On one tested card, it moved register-level issue rates from about 165 TF/s to about 332 TF/s. Those figures are not end-to-end speedups, and independent reproduction is still pending.
NVIDIA doesn't advertise a switch that doubles RTX 4090 tensor throughput, and the firmware doesn't expose one in any official tool. A GitHub project called gpu-unlock-ada says it found one. Its Linux module changes a speed-select setting before the stock driver loads, and the author reports a roughly 2× jump on a single card. The claim is interesting, but the details matter more than the headline, so here's what the source actually shows and where it stops.
What the project actually changes
The module runs before NVIDIA's driver binds to the card. It runs a payload that the source describes as derived from the AD103_win_unlocker work, writes a speed-select value to the GPU, and then triggers a PCIe Function Level Reset (FLR) so the stock nvidia driver starts from the modified state. The author says it needs no patched NVIDIA driver and no UEFI application.
That sequence is the core of the claim, so it's worth stating plainly. The project isn't adding a feature to the driver. It's changing a firmware-controlled rate limit on the silicon and hoping the driver inherits it. The module also checks for the expected readout before and after the reset. If those checks fail, it's supposed to stop rather than push through.
The source is clear that the payload is essential to the result. It's also clear that the production booter is authenticated and decrypted inside the GPU, so the payload works from published debug-booter analysis rather than vendor documentation. That's a meaningful caveat for anyone trying to judge how stable this will be across driver releases.
The numbers, read carefully
The headline result is on an RTX 4090 (AD102). Here are the measured figures from the source alongside the second card, the experimental RTX 4070 Ti SUPER (AD103):
| Workload | Card | Stock | Unlocked |
|---|---|---|---|
| FP16 → FP32 accumulate | RTX 4090 | 165.6 TF/s | 331.6 TF/s |
| BF16 → FP32 accumulate | RTX 4090 | 165.5 TF/s | 330.6 TF/s |
| FP16 → FP32 accumulate | RTX 4070 Ti SUPER | 95.0 TF/s | 189.9 TF/s |
| BF16 → FP32 accumulate | RTX 4070 Ti SUPER | 95.0 TF/s | 189.7 TF/s |
| E4M3 FP8 → FP32 (CUTLASS GEMM) | RTX 4070 Ti SUPER | 59.326 TF/s | 59.495 TF/s |
| INT8 | RTX 4070 Ti SUPER | 379.5 TOP/s | 379.5 TOP/s |
The 4070 Ti SUPER figures come from a single card under a 240 W power cap. The FP8 row is the most useful one for skepticism, because it shows the gain isn't uniform across precisions. A 0.3% difference on one GEMM is essentially no change.
The pattern is worth noticing. The doubling appears on the tensor paths that feed FP32 accumulation. INT8 and the other paths the author checked stayed near baseline. That's consistent with a limit applied to specific instruction types, not a general throttle lifted across the chip.
Why the doubled number is not a speedup
This is the part most headlines will skip. The benchmarks measure register-resident issue rates. They show how fast the tensor cores can accept and retire instructions when operands sit in registers, with no memory traffic in the way. Real workloads rarely run that way.
A training step or an inference pass spends a large share of its time moving data through the memory hierarchy: loading weights from GDDR6X, staging tiles in shared memory, and waiting on synchronization. When a kernel is memory-bound, a faster tensor core just sits idle more often. The author says so directly: these are not application GEMM or inference speedups.
The FP8 result makes the same point from the other side. If the unlock lifted a hard ceiling in the tensor path, you'd expect every tensor-bound GEMM to benefit. It didn't, at least for the one CUTLASS kernel tested. The author notes that other FP8 kernels remain untested, which is the honest position. You can't generalize from one kernel.
Here's a practical rule. Before you assume a 2× tensor number means 2× faster training, profile your own kernel with Nsight Compute and check whether it's tensor-bound or memory-bound. If it's memory-bound, the unlock won't change your wall-clock time, and you'd have taken on the firmware risk for no gain.
The RTX 4070 Ti SUPER is a separate, weaker claim
The source treats the 4070 Ti SUPER (10de:2705) as a different kind of result. It's an experimental AD103 target validated on one card. The module only selects it when you explicitly enable an experimental flag and name one exact PCI address. Broad selection modes skip it.
The evidence is also thinner. The author ran two cold boots and later warm reboots on that one card, confirmed the driver 580.178.04 handoff, and measured throughput across stock and unlocked boots. That's a real test, but it's a single unit. Silicon varies from card to card, and a result on one 4070 Ti SUPER says little about the next one.
Here's where it gets interesting for buyers. The author explicitly says that sharing firmware across Ada chips does not establish support for untested cards. The same logic applies in reverse: a working 4090 result doesn't prove anything about a 4080 or a workstation card. The source also says professional RTX A-series and data-centre parts are not accepted, so don't read this as a general Ada unlock.
Why cold boots matter (and where it gets risky)
The unlock depends on the card's firmware state. The source says the module expects a card whose firmware state is fresh before NVIDIA loads. A cold power-off is the recommended first attempt. On the 4070 Ti SUPER, a warm reboot worked too, because the pre-firmware WPR2 readback returned to zero. On other boards, the module refuses to rerun the sequence if the state persists.
That design is a safety feature, and it's a useful one to understand. If you see the module refuse to act, that's the designed behavior, not a bug to route around.
The riskier part is the cleanup. The source warns that if firmware doesn't stop cleanly, the module keeps its DMA buffers because firmware may still use them. In that state, the author says to power off before trying again and not to force-unload. That's the kind of failure mode you only learn about from people who've hit it, and it's a reason to treat this as hardware work, not a software toggle.
There's also an operational trap. Loading NVIDIA tools early, such as nvidia-smi or CUDA, can bind the driver before the module gets its chance. The source says ordinary blacklist rules don't stop explicit named loads, which is the kind of detail that burns people who assume a blacklist is enough.
Who should wait
This is not a general-purpose recommendation. Based on the source itself, the project is best suited to people who:
- Own the exact tested hardware (a 4090 at
10de:2684, or the single 4070 Ti SUPER at10de:2705). - Can power-cycle the machine and keep a stock boot entry available for recovery.
- Have a workload they can profile and show is genuinely tensor-bound.
- Are comfortable treating a firmware-level change as an experiment, with no warranty from NVIDIA behind it.
If any of those don't apply, the sensible move is to watch for independent reproduction. The author lists that as pending for the 4090. A second lab confirming the number on a different cold boot would tell you far more than the current single-card result.
The author also lists the display handoff and multi-card operation as outside the 4090 validation. That's one more reason to keep a fallback path ready before you touch anything.
Frequently Asked Questions
what is the RTX 4090 tensor unlock?
The RTX 4090 tensor unlock is an experimental Linux kernel module in the gpu-unlock-ada project. It changes a firmware speed-select setting before NVIDIA's driver loads, and the author reports roughly doubled FP16 and BF16 tensor issue rates with FP32 accumulation on one tested card. It is not an official NVIDIA feature.
does the RTX 4090 tensor unlock speed up real AI workloads?
Not according to the evidence so far. The measured gains are register-resident issue rates, not application speedups. Memory-bound workloads won't benefit much, and the one FP8 GEMM tested showed almost no change. Profile your own kernels before assuming any real-world gain.
why does the GPU unlock need a cold boot?
The module needs the card's firmware state to be fresh before NVIDIA loads. A full power-off usually provides that state. Some boards retain state across warm reboots, and the module refuses to rerun the sequence in that case. The 4070 Ti SUPER unlocked after a warm reboot, but the author recommends a cold start for the first attempt.
is the gpu-unlock-ada module safe to use?
It carries real risk and should be treated as hardware experimentation. The source warns that a failed firmware stop can leave DMA buffers allocated, and that you should power off rather than force-unload. Keep a stock boot entry available, verify the unlock message and GPU health after each boot, and don't assume a single successful test means the setup is stable.
Tensor throughput numbers make good headlines, but the useful question is whether your workload is limited by the tensor cores or by everything around them. The most practical step is to profile one real kernel this week and compare its bottleneck against the register-level figures above. If you have the exact tested hardware, the source's technical notes are the place to start, and sharing your own cold-boot results would help settle the reproduction question for everyone else.