Open-source developers have published Linux kernel modules that remove a long-standing throttle on Nvidia's GeForce cards: the half-rate limit on tensor math that accumulates in FP32. On an RTX 4090, the project gpu-unlock-ada reports FP16 throughput rising from 165.6 to 331.6 TFLOPS in a synthetic benchmark. That is the number going around on X, and it is accurate as far as it goes. The catch is what it measures, which this post spells out along with who benefits, what the risks are, and what remains unverified.
Quick answers
| Question | Answer |
|---|---|
| What is throttled? | FP16 and BF16 tensor math with FP32 accumulation runs at half rate on GeForce cards |
| Headline result | RTX 4090: FP16 165.6 to 331.6 TFLOPS; BF16 165.5 to 330.6 TFLOPS |
| Real application gain | One owner run: cuBLAS FP16 GEMM +12 to 34%, BF16 +16 to 20% at two shapes, none at 4096 cubed |
| Who benefits | BF16 diffusion, fine-tuning, training, prompt prefill |
| Who does not | Gamers, and LLM token generation (memory-bound) |
| OS | Linux (Windows only as a one-board experiment) |
| License | GPL-2.0-only module; Nvidia firmware generated locally, not shipped |
| Maturity | Experimental, few tested cards, independent reproduction limited |
What exactly is the cap?
Nvidia has never hidden that GeForce cards run some tensor operations at half speed. As Hardware Busters summarizes, Nvidia's own Ada Lovelace whitepaper lists the RTX 4090 at roughly 165 TFLOPS for FP16 matrix math with FP32 accumulation, half of what the same AD102 die manages when it accumulates in FP16. Workstation cards built on the same silicon do not carry the penalty. In other words, the hardware is the same and the limit lives in firmware, which is a product-segmentation lever separating a consumer card from a workstation card on one die.
That matters for AI because training and fine-tuning typically use FP32 accumulation for numerical stability. It is why 24 GB GeForce cards are popular for cheap local training, and why the cap bites exactly there. We cover the broader economics in our posts on Nvidia's dominance in AI compute and Nvidia's AI home hardware plans.
How does gpu-unlock-ada work?
According to the repository README, the Linux module enables the SM speed-select override before the stock Nvidia driver starts. The RTX 4090 path runs signed firmware, checks a completion marker and required permissions, writes the speed-select registers, then performs a PCIe function-level reset before the unmodified Nvidia driver binds. There is no VBIOS flash, no patched driver and no UEFI application.
The firmware is generated on your own machine from pinned Nvidia inputs verified by SHA-256 hashes; the repository ships no Nvidia binaries. It is GPL-2.0-only. The AD102 payload derives from a published Windows unlocker project, and the Linux module derives from an earlier Ampere project by Zagitta. The README credits those projects, along with Nouveau and envytools, in its acknowledgements.
What is verified, and what is not
This is the part the viral posts skip.
| Claim | Evidence in the README |
|---|---|
| RTX 4090 FP16 165.6 to 331.6 TFLOPS | Author's measurement; instruction-throughput benchmark |
| Independent confirmation | An owner run at a 450 W cap: 160.4 to 320.4 TFLOPS FP16, 159.7 to 320.2 BF16; numerical checks passed |
| Real matrix multiply gains | cuBLAS median: FP16 +12 to 34%, BF16 +16 to 20% at two shapes, unchanged at 4096 cubed |
| INT8, dp4a, scalar FP32 | Stayed near baseline |
| FP8 | One CUTLASS E4M3 GEMM on a 4070 Ti SUPER: 59.326 to 59.495 TFLOPS (0.3%); other kernels untested |
| Stability | "One matched run pair with the desktop active", not an extended stability test |
The README states that the figures are "register-resident issue rates, not application GEMM or inference speedups." The README adds that results come from single-card tests. So: the unlock is real on the tested cards, the synthetic doubling is reproduced once, and whole-application gains are smaller and shape-dependent.
Which cards are supported?
- RTX 4090 (AD102, 10de:2684): validated; selected automatically when enabled.
- RTX 4090 D: experimental opt-in flag.
- RTX 4070 Ti SUPER (AD103): experimental, validated on one card. FP16 issue rate 95.0 to 189.9 TFLOPS at a 240 W cap; TF32 47.49 to 94.51.
- RTX 4060 Ti 16GB (AD106): experimental, validated on one card; no same-card stock throughput run yet.
- Ampere (GA102, GA103, GA104, GA106): handled by the older Zagitta project. Hardware Busters cites RTX 3090 Ti BF16 rising from 87.5 to 157.4 TFLOPS (+79.9%) and FP16 by 35% in 8192-cube matrix multiplies, and a ComfyUI BF16 job on a 3090 Ti dropping from 72 to 45 seconds, as reported by The PC Enthusiast. We have not verified that run.
- Professional RTX A-series and data-center parts: refused.
What does it mean for local AI?
If you fine-tune or train in BF16 on a GeForce card, the cap is what limits you, and gains of 12 to 34 percent in real GEMMs, with more in some pipelines, are meaningful for free. If you run chat models locally, expect little change: token generation is bound by memory bandwidth, not tensor math, though prompt prefill reportedly gains 14 to 36 percent. Gamers see nothing.
This sits alongside other ways builders are squeezing local hardware: Perplexity's RTX Linux portable computer, Nvidia's Hermes desktop on RTX Spark, and runtime-level work such as GGUF and llama.cpp parity. Software-side kernel work, like Nvidia's CUDA Rust kernels, is the sanctioned path to speed; this is the unsanctioned one.
Why does a 2x instruction rate give only 12 to 34 percent in practice?
A tensor core can only run as fast as it is fed. A synthetic instruction benchmark keeps operands in registers, so nothing waits on memory and the doubled issue rate shows up in full. A real matrix multiply must pull tiles from global memory, stage them in shared memory, and write results back. Once the math units are twice as fast, many shapes become limited by bandwidth or by kernel scheduling, and the gain shrinks. The README's own cuBLAS numbers show this: gains varied by shape, and BF16 at 4096 cubed was essentially unchanged.
For training the picture is murkier still. A full step also includes elementwise operations, normalization, optimizer updates, data loading and communication, none of which benefit. Amdahl's law applies: if matrix multiplies are, say, half of your step time and they speed up by a third, the whole step improves by well under that. This is why the right test is your own workload, run end to end, rather than a TFLOPS headline.
It also explains the Ampere reports. Larger, more compute-bound shapes and BF16 pipelines such as diffusion benefit most, which fits the reported ComfyUI improvement, while small-batch inference sees little.
A simple way to evaluate it safely
- Record a baseline on stock firmware: your real training or diffusion job, wall-clock time per step, plus the repo's instruction benchmark for a sanity check.
- Confirm your card is on the supported list and read the repo's QUICKSTART and testing notes first.
- Test on a machine you can power-cycle and recover without the GPU's display output.
- After the unlock, confirm the kernel log shows the module's unlocked message for the exact card, rather than assuming a successful load means success.
- Re-run the same job, and check numerical results match, since the README reports deterministic outputs matching in its tests.
- Keep the stock boot entry, and watch temperatures and power draw, as higher tensor utilization raises load.
Risks and the fine print
- Experimental firmware-level change. The module runs a firmware transaction on your GPU. If it fails, the README tells you to power off before retrying and not to force-unload the module.
- Cold boot required. The first attempt needs a full power-off. Warm reboots are not guaranteed to work. Avoid
nvidia-smi, CUDA and NVML before the unlock, because they can load the Nvidia driver first. - Display and multi-GPU. Display handoff and multi-card operation were not part of the RTX 4090 validation; the display stays blank until the Nvidia DRM driver takes over.
- Upgrades. Boot entries tied to a kernel version must be regenerated and revalidated after kernel updates. Keep an unmodified stock boot entry.
- Terms and warranty. Bypassing a vendor's segmentation throttle may conflict with Nvidia's terms or warranty. We have not seen an Nvidia statement. Hardware Busters expects a firmware or driver revision could close the gap, so do not build a production workflow on it.
- Supply chain. You are loading third-party kernel code before your GPU driver. Read the source, pin the commit, and do not run it on a machine you cannot afford to lose access to.
Should you try it?
Only if you run Linux, own a supported card, accept the risk, and your workload is BF16 training or diffusion. Start by benchmarking your own job on stock firmware, then compare after the unlock using the matched benchmark commands in the repo's diagnostics/bench folder. If your job is bandwidth-bound, skip it.
What to watch next
- More independent reproductions on additional cards, especially extended-stability and multi-GPU runs.
- Whether Nvidia responds with firmware or driver changes.
- Application-level numbers from training frameworks, not just GEMM shapes.
- Whether the Windows port generalizes beyond one captured board profile.
Details are from the project READMEs and press coverage as of October 25, 2026, and the projects are changing quickly. Check the repositories before acting.