GPU Unlock on the RTX 4060 Ti & 4070 — What Actually Happens
If you searched "gpu unlock 4060 ti", you're probably asking one of two things: does this even work on a mid-range card, or is it worth the hassle on a card that only has 8GB of VRAM.
Short answer: on Linux, probably; on Windows, not at all. Which one applies to you depends entirely on your OS, and most posts online blur that line. Let me separate them.
Windows: there is no route for these cards
Be blunt about this, because it saves you an evening: the Windows port has no Ada profile. Its compatibility matrix covers RTX 3090 FE, 3090 Ti, 3070 Ti and 3060 12GB — all Ampere, one exact motherboard and BIOS each. There is no 4060, 4060 Ti or 4070 build.
Worse, the current Windows port doesn't ship prebuilt binaries at all. The latest tag is a source-only pre-release, and you'd need to compile it against a verified hardware profile. Even if you compiled it, the profile checks would reject an Ada card by design.
So if you're on Windows 11 with a 4060 Ti: there is nothing to install right now. Not a hidden download, not a Discord build. The Windows guide explains the situation in full.
Linux: experimental, with one measured card
The gpu-unlock-ada kernel module is where Ada support actually lives. It carries the NVIDIA driver's SM speed-select override before the stock driver initialises.
What's actually measured: RTX 4090 (AD102), roughly 2× FP16 and BF16 tensor throughput with FP32 accumulation — 165.6 → 331.6 TF/s. That survived PCIe FLR and a stock driver init, with INT8 and scalar FP32 staying near baseline.
What's not measured: the 4060, 4060 Ti and 4070. The fork describes those as experimental Ada GPUs — support exists, precision doesn't. AD106 and AD104 have different SM counts and different firmware tables, and I haven't seen a controlled before/after from an owner that I'd stake the article on.
How much would you gain?
If it works on your card, the mechanism is identical to the 4090's, so the ceiling is similar: the throttle removes roughly half the tensor throughput. Realistically, expect somewhere between +60% and +100% on tensor-bound work — but treat that as an engineering expectation, not a measured number for your card.
That's also why the workload matters more than the percentage:
| Workload | Likely effect |
|---|---|
| SDXL 1024×1024, batch 1 | Real step-time drop, most visible on the 16GB card |
| LoRA training, small dataset | Faster epochs — this is the workload the unlock is actually built for |
| 7B–13B LLM inference (quantized) | Modest gain. These are memory-bandwidth bound, not tensor bound |
| Gaming | Essentially unchanged. FP32 and RT cores aren't throttled |
For the verified numbers on the cards that have been properly tested, see the benchmarks page.
The 8GB problem nobody talks about
This is the part I'd want someone to tell me before I spent an evening on it.
The unlock gives you compute throughput. It does not give you VRAM. If your 4060 Ti is the 8GB model, you will still hit out-of-memory errors at exactly the same model sizes, batch sizes and resolutions as before — you'll just hit them faster.
So where does that leave you?
| Your card | Is the unlock worth it? |
|---|---|
| 4060 Ti 16GB | Yes. Enough VRAM to actually run the workloads that benefit from more compute. |
| 4060 Ti 8GB | Only if your bottleneck is genuinely compute, not memory. Check your task manager first — if VRAM is pegged at 100%, this won't help you. |
| 4070 / 4070 SUPER 12GB | Yes, with caveats. Fine for SDXL and small LoRAs; still tight for 13B+ models at full precision. |
| 4060 8GB | Marginal. The card is power-limited and memory-limited before it's tensor-limited. |
What the Linux route looks like
If you dual-boot or have a Linux box, this is the only path that exists today for a 4060 Ti. It's a kernel module, so the risk profile is "reboot and it's gone", not "reflash your BIOS":
Step 1 — Clone the Ada fork
Use JustAResearcher/gpu-unlock-ada, not the original Ampere module. Read its README first — the 4090 results are documented, and the other Ada cards are explicitly marked experimental.
Step 2 — Build and install the module
Standard kernel module build against your running headers. Reboot once so the module lands in initramfs.
Step 3 — Enable the override at boot
Add gpu_unlock.targets=all to your kernel command line. Exact commands per distro are in the Linux guide.
Step 4 — Confirm it loaded, then measure
Check journalctl -k -b | grep gpu_unlock for a successful override, then run your own workload twice — once with the flag, once without. On a 4060 Ti you're in unverified territory, so your own before/after is the only number that means anything.
Things that will trip you up
| Problem | What's actually happening |
|---|---|
| You're on Windows and can't find a download | Correct — no Ada build exists. Don't follow guides that tell you to grab an "Ada .efi" from Releases. |
| Module loads but nothing changes | Card not in the fork's supported ID list, or the kernel parameter didn't apply. Check the journal line, not the benchmark. |
| No performance change despite a "success" log | You were memory-bound, not compute-bound. See the 8GB section above. |
| Driver crash on boot after enabling | Remove gpu_unlock.targets= from the kernel command line and reboot — the module idles without it. |
| Laptop GPU | Mobile Ada parts aren't covered. Assume it won't work and have a recovery USB ready. |
Should you bother?
My take, being straight with you:
On Windows: there's nothing to decide. Wait for an Ada profile to be validated, or move your AI workloads to Linux/WSL2.
On Linux with a 16GB card: yes, if you're compute-bound and train or generate regularly. The module is reversible and the 4090 result is real.
On Linux with an 8GB card: check the bottleneck first. If VRAM is pegged, the unlock makes your out-of-memory errors arrive faster, which is not a win.
If you're still weighing the risk side — warranty, bans, bricking — that's covered in the safety FAQ. Short version: no permanent change, no BIOS flash, nothing left behind after a power cycle.