RTX 3090 + GPU Unlock: What It Actually Does for Stable Diffusion

Updated Oct 29, 2026 · Applies to SDXL, SD 1.5, and FLUX on 24GB cards

The 3090 is the card this whole story is really about. It's the cheapest 24GB card on the secondhand market, it's what most people actually run SDXL on, and it's one of the few Ampere models with a verified Windows profile. So the real question isn't "does the unlock double TFLOPS" — it's "does it make my SDXL generations faster, and by how much?"

Short answer: yes, but not by 2×, and not evenly across the pipeline. The synthetic Tensor Core number roughly doubles. Wall-clock time per image moves much less, because only part of a diffusion run is Tensor Core math.

What the unlock changes — and what it doesn't

Property	Affected by unlock?	Why
FP16 / BF16 Tensor Core throughput	Yes, roughly 1.85–2×	The firmware speed selector (SS0/SS1) is what caps it
VRAM capacity	No	24GB is physical. No register write adds memory
FP32 gaming performance	No	The cap is on tensor paths used for matrix multiply
Memory bandwidth (936 GB/s)	No	Unchanged; bandwidth-bound workloads see no gain
Clocks, voltage, TDP limit	No	That's overclocking, a completely different mechanism
Power draw under tensor load	Indirectly yes	Faster math means less idle time, so average draw rises

Where the time in an SDXL run actually goes

This is why "2× TFLOPS" and "2× faster images" are different numbers. A typical SDXL 1024×1024 run breaks down roughly like this:

UNet denoising loop — the bulk of the time, and the only part that is heavily Tensor Core bound. This is what the unlock accelerates.
VAE decode — a few hundred milliseconds, partly memory-bandwidth bound. Little to no gain.
Text encoders — small, and for CLIP/T5 pairs often the same cost regardless.
Model loading and offloading — fixed cost per run if you reload models, and it dominates short jobs.
CPU and dataloader — if you're batching from disk or doing post-processing in Python, this becomes the wall.

So on a 3090 at batch size 1, the denoise loop is maybe 60–75% of total time. Even a perfect 2× on that segment lands somewhere around 1.3–1.5× end to end. At batch 4–8 the loop's share grows, and the overall gain gets closer to the synthetic ratio.

Numbers people report

Read the label before believing the number. The figures below are single-rig community reports, not controlled before/after tests on our own hardware. They are useful as a sanity range, not as a promise.

Workload (3090, 24GB)	Before	After	Type
SDXL 1024×1024, batch 1, 28 steps	1.3–1.6 it/s	1.9–2.3 it/s	Single-rig reports
SDXL 1024×1024, batch 4	0.45–0.55 it/s	0.75–0.95 it/s	Single-rig reports
LoRA training, 1024² crops	—	~15–25% faster wall clock	Reported, optimizer/dataloader bound
BF16 matmul, synthetic	~71 TFLOPS	~140–150 TFLOPS	Matches the 3090 Ti class ratio

Note the last row compared to the first. The synthetic number nearly doubles; the per-image number doesn't. That gap is not a bug — it's the pipeline. Anyone showing you a 2× "image speedup" chart on a 3090 at batch 1 is either measuring the matmul, or measuring something else.

Measure it yourself in five minutes

Before trusting any chart, including the one above, run two numbers on your own card. Start ComfyUI or A1111 with a fixed seed, fixed sampler, fixed step count, and time ten generations — first with the unlock active, then after a full shutdown and cold boot.

Then check whether the tensor path itself moved:

python -c "
import torch
a = torch.randn(8192, 8192, device='cuda', dtype=torch.bfloat16)
for _ in range(20): torch.mm(a, a)
torch.cuda.synchronize()
import time; t = time.time()
for _ in range(100): torch.mm(a, a)
torch.cuda.synchronize()
print((100 * 2 * 8192**3) / (time.time() - t) / 1e12, 'TFLOPS')
"

If the synthetic number roughly doubled but your images didn't get meaningfully faster, the bottleneck is not Tensor Core throughput — check VRAM pressure, CPU utilisation, and whether the model is being reloaded between runs.

How to actually enable it on a 3090

Two routes, and they are not equally good:

Linux (recommended). The original kernel module is one command, persists across reboots, and is suspend-safe. See the Linux guide. WSL2 is not enough for this — it needs the real kernel module.
Windows (only if your exact build matches). The port is source-only and keyed to four verified profile combinations. The 3090 FE and 3090 Ti are on the list; a 3090 from another AIB with a different vBIOS is not. See the Windows guide for the profile check before you spend an evening on it.

3090-specific thermal note: GDDR6X memory junction temperatures were already the weak point on this card. Running tensor math at double rate means less idle between kernels, so sustained loads get hotter. Check memory junction temps under a real training run, not just a benchmark loop, before leaving a job overnight.

Does it help FLUX?

Partially, and with a catch: FLUX.1-dev is a 12B model, so at fp16 the weights alone are near 24GB and you're likely running fp8 or NF4. At that point you're memory-capacity bound, not compute bound — the unlock has little room to help. SDXL is the better case for this, because it fits comfortably and the denoise loop dominates.

Quick answers

Will it make SDXL 2× faster? No. Expect roughly 1.3–1.5× end to end at batch 1, better at larger batches.

Will it let me run bigger models? No. VRAM is unchanged — that's what the VRAM guide covers.

Is it worth it on a 3090? If you generate or train regularly and you can run Linux, yes — it's one command. If you're on Windows and your exact board isn't in the compatibility matrix, it's not worth the evening.