GPU Unlock vs Overclock: Same Result? No, Not At All
Half the questions in the upstream issue trackers look the same: "isn't this just overclocking?" It isn't, and the difference matters if you're about to run one of them on a card you paid for.
Overclocking asks the hardware to run faster than its rated clock. Unlock doesn't touch clocks at all — it changes how much work each clock does.
The mechanisms, side by side
| GPU unlock | Overclock / undervolt | |
|---|---|---|
| What changes | Firmware speed selectors (SS0/SS1) that cap tensor throughput | Clock offsets, power limit, voltage curve |
| Where it happens | Registers written before the driver loads | Driver-level, via Afterburner / nvidia-smi / NVML |
| Effect on FP16/BF16 tensor math | Roughly 1.85–2× | A few percent, if not power-limited |
| Effect on FP32 gaming | None | Typically 3–10% |
| Heat | Indirect (denser kernel execution) | Direct and usually the limiting factor |
| Stability risk | Low, but no support path | Moderate; manageable with testing |
| Persists after reboot | Linux: yes. Windows: no | Depends on tool settings |
| Reversible | Linux: remove boot flag. Windows: cold boot | Yes, reset offsets |
Why the unlock is not "free clocks"
NVIDIA ships two different tensor throughput ratios on the same silicon: one for GeForce cards, one for the professional lineup. It's not a clock limit — the card runs at its normal clocks either way. The cap is imposed by a value in firmware that the driver reads at init.
That's why writing those registers before the driver loads changes throughput without changing the clock, the voltage, or the TDP ceiling. The power limiter still enforces the same 350W (on a 4090) or 350W (on a 3090) — the card just spends more of that budget doing math instead of waiting.
Practical consequence: the unlock does raise power draw under AI workloads, because there's less dead time between kernels. It's not because voltage went up. You'll see this clearly on a 3090, where sustained training runs go from around 300W to closer to the TDP clamp.
Can you run both?
Yes, and they don't conflict, but they compete for the same power budget. Order matters:
- Unlock first. Measure the gain at stock clocks.
- Then undervolt, if you're thermally limited. This is usually the better move than adding clocks, because the unlocked tensor path already saturates the power limiter on some loads.
- Only add clocks last, and only if the power limit isn't already the constraint. If your card is pinned at the TDP clamp during matmul, more clock offset just causes throttling.
The thing overclockers get wrong about this
Raising clocks by 5% gets you 5% more of a throttled number. Unlock removes the throttle. That's why the two aren't interchangeable: no amount of clock offset closes a 2× gap rooted in a firmware ratio.
Conversely, the reason overclocking still exists as advice: on cards where the unlock isn't supported (most RTX 40 series on Windows, every card outside the four verified Ampere profiles), overclocking and undervolting are the only levers you have. A 5% gain and lower temperatures beats nothing.
Does any of this affect gaming?
No. The unlock is invisible to FP32 rasterisation and to DLSS. A tested 4090 showed framerate within a couple of percent of stock — the variance you'd see between two runs anyway. If a guide tells you the unlock improves game performance, it's confusing it with overclocking.
Which one should you do first
Depends on what you actually run:
| Your workload | Best first move |
|---|---|
| SDXL, LoRA training, LLM inference | Unlock, if your card is supported |
| Gaming only | Overclock/undervolt — the unlock does nothing |
| Unsupported card (most Ada, all Windows 40 series) | Undervolt, then mild clock tuning |
| Thermally limited 3090 | Unlock + undervolt; repaste before adding clocks |
If your card is on the supported list and you run Linux, the unlock is the single largest gain available to you — far bigger than any clock tuning. Start with the Linux guide. If you're on Windows, check the exact profile requirements before assuming anything.