gpu unlock not working: it unlocked and nothing got faster
The log says unlocked and the benchmark returns the number it returned before. That is the gpu-unlock not working report, and most of the time nothing is broken: the workload is sitting on a lane the unlock never touches.
First, confirm gpu unlock actually ran
A module that loaded is not a card that unlocked. The two are separate events in the log, and only one of them changes a number.
journalctl -k -b | grep gpu_unlockThe line to find is gpu_unlock: unlocked. A successful run also prints a chain — claim, layout, dma, gfw, fwsec, publish, pass, host, flr — that ends at handoff ret=0, which is the point where the module hands the card back to the driver with the write in place.
issue #258 pasted that full sequence. [issue #258]
If the module reports unlocked and the benchmark is still flat, you are on this page rather than on the install page. If the log has no unlocked line at all, this is not a no-speedup problem, and the gpu unlock install page is the right place to start.
One reading trap belongs here. On some cards nvidia-smi reports an SM clock frozen near 210 MHz while benchmarks run at the full unlocked rate. That is a telemetry artefact, and issue #258 is where it shows up. [issue #258]
A frozen readout is not evidence that the unlock failed, and it is worth checking the benchmark before the sensor.
Three reasons gpu unlock is not working
The unlock restores a compute path. It does not make a bandwidth-bound job wider and it does not beat a power limit. Those two facts, plus the workload you chose, account for nearly every flat result.
most common
The workload never used the path that changed
Token generation, INT8/FP8/INT4 inference, game frames and plain FP32 CUDA work do not use the FP16/BF16 rate path the unlock restores. Quantized GGUF models can still benefit where prefill runs through a repaired 16-bit GEMM, but the gain is usually small; the lane table below separates those cases.common
The card hits its power limit first
A card that is out of power cannot spend more of it. The same 3090 measured at 250 W gains 25% on prefill and 50% at 375 W.depends on setup
The stack is not running a 16-bit GEMM
GGUF quantization reduces precision and often shifts the bottleneck to memory traffic or quantized kernels. How much the restored FP16/BF16 path helps depends on the backend and on how much of the run is prefill, which is why the published range is 0–15% rather than a full-path gain.
The order matters because it maps to effort. The first one costs nothing to check: your workload either uses 16-bit GEMM or it does not. The second costs a power measurement. The third costs a different server configuration.
The gpu unlock lane table
The project publishes a benefit table with nine rows, and the flat rows are as informative as the rising ones. Reported ranges below are the project's, with an issue that measured a point inside them where one exists.
- Reported gain by workload, with one measured point per row where a report exists.
LLM prefill / prompt processing
- Reported
- +25–55%
- Why, and what measured it
- FP16 or BF16 GEMM on the repaired path. #107 measured +25% at 250 W.
Time to first token
- Reported
- −25–30%
- Why, and what measured it
- The same prefill gain, read as latency rather than throughput.
LoRA and BF16 fine-tuning
- Reported
- +25–50%
- Why, and what measured it
- Training steps are GEMMs, so the restored path is used directly.
Image generation (SDXL, SD 1.5)
- Reported
- +30–55%
- Why, and what measured it
- #234 measured SDXL +44% and SD 1.5 +32% on a 3060.
Video generation
- Reported
- +15–20%
- Why, and what measured it
- #218 measured +14% at 340 W and +1.5% at 180 W on a 4090.
FlashAttention / SDPA kernels
- Reported
- +50–60%
- Why, and what measured it
- Attention kernels are GEMM-dominated at these widths.
llama.cpp / Ollama, quantized GGUF
- Reported
- 0–15%
- Why, and what measured it
- Mostly long context, where prefill is a visible share of the work.
LLM decode / token generation
- Reported
- none
- Why, and what measured it
- Bandwidth-bound. #107 measured 76.4 → 76.2 tok/s on a 3090.
INT8, FP8, INT4 models
- Reported
- none
- Why, and what measured it
- Those paths never used the half that was switched off.
Games and plain FP32 CUDA
- Reported
- none
- Why, and what measured it
- No tensor-path work to restore.
[official README] covers every reported range in the second column; the issue numbers in the third are the measured points.
Read the table as two halves. The top six rows are workloads that spend their time in 16-bit matrix multiplies, and they are where the money is. The bottom four are neither broken nor slower; they are simply unaffected. That is why a chat session with a quantized model accounts for most gpu-unlock not working reports.
There is a caveat on the image row that the benchmark alone will not show. Outputs are usually bit-identical at a fixed seed and a deterministic stack, and issue #234 checked that with SHA-256 over 18 images.
It is not a guarantee: issue #71 reports the opposite across boots, and continuous batching makes exact equality unlikely. Judge speed, not hashes.
How power limits change what gpu unlock gives you
This is the row that turns a disappointing result into a predictable one. On the same 3090 running a 4-bit W4A16 model, the prefill gain rises with the power ceiling set for the card.
- Prefill gain against power limit, 3090, W4A16 (issue #107).
250 W
- Prefill gain
- +25%
- Reading
- The lowest measured cap in issue #107 — not the stock 3090 rating.
275 W
- Prefill gain
- +35%
- Reading
- The next step up costs heat, not correctness.
300 W
- Prefill gain
- +42%
- Reading
- Roughly two thirds of the headline range.
350 W
- Prefill gain
- +48%
- Reading
- Diminishing returns start to show.
375 W
- Prefill gain
- +50%
- Reading
- Close to the ceiling the card will sustain.
The same report measured 20–35% less energy per prefill token, which is the more useful number on a fixed power budget: the card does more work for the same wall draw.
The 40-series behaves the way the README warns it will. On a 4090 the matrix throughput doubles from 164.9 to 329.6 TFLOPS, and a plain PyTorch matmul at 4096 or 8192 moves by 0 to 5% at the same time, because the board runs out of power before it runs out of tensor cores. [issue #218]
76.4 → 76.2tok/s
Decode before and after, 3090
Inside run-to-run noise. This is what an unaffected lane looks like.
+100%MMA
4090 peak, with +0–5% on a real matmul
Paper peak and end-to-end result are not the same measurement.
Measure gpu unlock on the lane you care about
The most common gpu-unlock not working report is a correct install measured on a lane that never changed. On token decoding, that flat result is therefore expected, not evidence of a bad install. A single run of an unpinned benchmark will produce a number, and the number will be noise. Three things make the comparison readable.
setup
Fix everything except the unlock
Same seed, same batch size, same model file, same driver and same flags. A changed batch size moves throughput more than the unlock does.runs
Run each side three times and take the median
One run measures the machine, not the change. The decode figures above move by less than a percent between runs, and that is the scale you are reading at.metric
Read the metric that matches the lane
tok/s for decode, tokens/s and time to first token for prefill, wall time at a fixed seed for images. A prefill gain hides inside a decode average.
If the prefill number moves and the decode number does not, that is the expected outcome for a working install, not a partial failure. The converse is the case worth investigating, because it suggests the workload never reached the restored path.
Is gpu unlock worth chasing
If your main workload is token generation, quantized inference or games, a gpu-unlock not working result is expected; the honest answer is no. Nothing is misconfigured, and the fix is a different card rather than a better install.
If it is prefill, fine-tuning, image or video generation, the answer depends on the power ceiling more than on anything else. A card locked to a low limit will deliver a result inside the range on the table and still look disappointing next to a headline that assumed a raised one.
Between those two, the cheap experiment is to measure one prefill run at the current limit and one at the highest limit the card will accept. That single pair tells you whether the remaining gain is available on your hardware or was never there.
Your next gpu unlock step
Confirm the card is in the supported set through the gpu unlock compatibility table before tuning anything; an unsupported card is skipped at boot and never reaches this page's question. The load order that decides whether the write happens at all is on the gpu unlock install page.
If the log shows no unlock line rather than a flat benchmark, the troubleshooting index routes you to the install-stage failures, and if the card went quiet instead of slow, the -110 page is the one that applies.
Checked VERSION 2.0.0commit fd56c1d