October 25, 2026 — An open-source project called gpu-unlock-ada is climbing GitHub's trending list (about 2,400 stars, v1.1.1). Its pitch: release the tensor throughput that NVIDIA locks away on gaming cards, before the driver ever touches the hardware. Chinese tech media ran with headlines like "double the performance, no new card needed." We read the project documentation and both generations of test data, and the honest picture is smaller: instruction issue rates do double, real AI workloads gain 12-34%, and most generation-heavy pipelines gain almost nothing.
What the project actually unlocks
NVIDIA has sold the same silicon at two price points for decades. GeForce cards ship cheap, but the issue rate of FP16 and BF16 tensor operations (with FP32 accumulation) is capped in firmware. Quadro and Tesla parts cost far more and run full speed. The module runs inside the Linux kernel, before the stock driver binds: it verifies and runs NVIDIA's own signed firmware, flips two speed-select registers, then triggers a PCIe function-level reset. The driver stays untouched, the vBIOS stays untouched, and the firmware image is generated locally from hash-verified official inputs — the project ships no prebuilt firmware at all.
The README's own measured numbers: an RTX 4090 climbs from 165.6 to 331.6 TFLOPS FP16 — a clean 2.0x — and from 165.5 to 330.6 on BF16. But the README also carries an independent matched run (driver 615.78.08, 450 W) where real cuBLAS matrix multiplications gained 12-34% on FP16 and 16-20% on BF16, with one large shape flat. On the RTX 4070 Ti SUPER, TF32 goes from 47.49 to 94.51 while INT8 and INT4 sit still, and FP8 GEMM edges from 59.33 to 59.50 — which is to say, it does not move.
The previous generation already ran this experiment
The predecessor, Zagitta's gpu-unlock for RTX 30, tells you where the gains end up. An RTX 3080 Ti lifts from 71.59 to 113.98 TFLOPS BF16 and from 35.65 to 65.28 on TF32. ComfyUI image generation throughput rose 56-59%. But vLLM only sped up prompt prefill by 33% — token generation stayed flat, because generation is memory-bandwidth-bound, not compute-bound. INT8 throughput moved about 0.3%. One user with a 3080 Ti 20GB reported a successful unlock and zero performance change. The pattern is consistent: the unlock pays where arithmetic density is high, and pays nothing where the card is already waiting on memory.
What is actually supported
| Card | GPU | Status in the project | Numbers that matter |
|---|---|---|---|
| RTX 4090 | AD102 | Validated | FP16 165.6 → 331.6 TFLOPS |
| RTX 4090 D | AD102 | Experimental (kernel opt-in) | — |
| RTX 4070 Ti SUPER | AD103 | Experimental (one card verified) | FP16 95.0 → 189.9; FP8 unchanged |
| RTX 4060 Ti 16GB | AD106 | Experimental (unlock confirmed, no baseline) | — |
| RTX 4080 / 4080 Super | AD103 | Not on the list | Figures quoted in Chinese coverage do not appear in the README |
On platforms: the mainline project is a GPL-2.0 Linux kernel module. Windows has one experimental port — a UEFI route for the RTX 4070 Ti (AD104) contributed by Latence.app — with a single recorded manual boot, cuBLAS FP16 up 80.1%, and no installer or binaries released. First attempts require a cold boot, and you are told to keep an unpatched boot entry around. This is a research tool, not a toggle.
Three takeaways
- Doubling issue rates is not doubling performance. Bandwidth, scheduling and power ceilings sit between the register and your frame time. The README says so plainly; the warning just keeps falling off as the story travels.
- The wall is a business model, not a law of physics. The GeForce-to-professional delta funds NVIDIA's enterprise margins, and firmware checks are where the line is drawn. A driver or firmware update can close this gap at any time, with no SLA and no support behind the workaround.
- Enterprises have no business here. EULA exposure, voided warranties, zero vendor support and unknown stability — any one of these disqualifies it for production. It is a lens for understanding GPU pricing, not a cost-cutting plan.
Five questions a buyer in Guangzhou should ask
- Is my workload GEMM-heavy (training, embeddings) or bandwidth-heavy (token generation)? The second group will feel nothing.
- What is the real price gap? Does the spread between a 4090 and the professional card it would replace cover the cost of one unsupported outage? Usually not.
- Does my pipeline run FP16/BF16, or INT8/FP8 quantized? The latter two barely benefit.
- Can operations accept "confirm the unlock log after every cold boot" as a routine?
- Does compliance allow firmware-level modification at all? In finance, healthcare and government the answer is generally no.