Short version

The gpu-unlock kernel module works on Unraid. On a water cooled RTX 3090 running 7.3.4 (kernel 6.18.58-Unraid, driver 580.196.07) it raised dense FP16/BF16 GEMM from 70.7 to 123.3 / 116.9 TFLOPS at the card's stock 350 W power limit, no overclock, no vBIOS flash, no patched driver. A real ComfyUI workflow running bf16 went from 28.5 s to 22.5 s per image. Quantized workloads (int8 UNET, Q4 GGUF) did not move, which is expected and worth knowing before you try it.

This is about a third-party plugin, not a Lime Technology product. Upstream is Zagitta/gpu-unlock, the Unraid packaging is tabilzad/gpu-unlock-unraid, and the original Unraid report is issue #55. Everything below is measured on my own hardware.

Setup

• GPU: RTX 3090 24 GB (GA102, 10de:2204, 0b:00.0), water cooled

• Unraid 7.3.4, kernel 6.18.58-Unraid

• NVIDIA driver 580.196.07 (nvidia-driver plugin)

• Module: gpu-unlock plugin 2026.10.26.3, upstream 1.0.0

• Power limit during the unlock tests: 350 W, the card's stock/default limit

Installation is the plugin's documented path: install the plugin, generate the firmware from the settings page, pick the card, reboot. The one non-obvious part is that the first boot has to be a full power cycle, not a warm reboot, because the module refuses a card the driver has already initialised since power-on.

The hook runs from /boot/config/modprobe.d/, which Unraid restores before udev, so the unlock lands before nvidia binds. The driver's boot timing is unchanged, and if anything goes wrong the driver still loads and the card is simply not unlocked.

Boot evidence

[   37.113] gpu-unlock: loading gpu_unlock for 6.18.58-Unraid with targets=0000:0b:00.0 before nvidia
[   37.150] pci 0000:0b:00.0: asset result: gpu-unlock/610.43.03/gsp_ga10x.bin error=0 bytes=84277400
[   37.154] pci 0000:0b:00.0: asset result: gpu-unlock/610.43.03/v67-ga102-610.43.03.bin error=0 bytes=64000
[   63.501] pci 0000:0b:00.0: gpu_unlock: unlocked
[   63.510] gpu-unlock: loaded: gpu_unlock for 6.18.58-Unraid, targets=0000:0b:00.0
[   64.043] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 580.196.07

gpu-unlock-ctl status reports 0000:0b:00.0: unlocked. No Xid errors, no NVRM complaints.

How the numbers were taken

• GEMM: cuBLAS through torch 2.9 in a container, torch.mm on random dense matrices, sizes 4096, 8192 and 16384, 2 warm-up multiplies then 5 timed, median reported. TF32 enabled via allow_tf32.

• ComfyUI: my own saved workflow, replayed through the API with the same seed and the same 896x640 / 20 step / euler / sgm_uniform settings, execution_start to execution_success wall time, one warm-up run discarded, then 5 runs (bf16) or 4 runs (int8).

• Power and clocks: nvidia-smi sampled during sustained GEMM.

Result 1: GEMM at the card's stock 350 W limit

This is the firmware result. Both sides of the table ran at 350 W. The power limit was not touched.

GEMM	locked	unlocked	change
FP16 4096³	61.7	119.6	+94%
FP16 8192³	70.7	123.3	+74%
FP16 16384³	77.2	129.6	+68%
BF16 4096³	71.3	133.6	+87%
BF16 8192³	70.7	116.9	+65%
BF16 16384³	78.7	133.4	+69%
TF32 4096³	35.9	65.2	+82%
TF32 8192³	39.2	64.1	+64%

The telling detail is what the card did while it was doing it. Sustained dense GEMM, same 350 W cap, same workload:

state	power	SM clock
locked	341 to 343 W	1665 to 1725 MHz
unlocked	344 to 346 W	1410 to 1455 MHz

Same watts, clocks dropped by roughly 300 MHz, throughput nearly doubled. That is what an instruction issue rate change looks like. If your card holds its clocks and does not gain throughput, the unlock did not take.

Result 2: a real workload, not a benchmark

My own ComfyUI graph (moss-image, 896x640, 20 steps, fixed seed), same graph both times, only the UNET precision changed:

workload	locked	unlocked	change
int8 UNET (my normal setup)	36.13 s	35.63 s	-1.4%, noise
same graph, bf16 UNET	28.51 s	22.54 s	-20.9% wall clock

The int8 result is not a failure, it is the expected behaviour and the single most useful thing I can tell anyone reading this: the unlock widens the FP16/BF16 tensor path, so anything running quantized matmul is unaffected. int8 diffusion models, Q4/Q5 GGUF LLM inference and integer dp4a kernels see no gain. Before you install this, check what dtype your actual workload uses.

For completeness, Q4 GGUF prefill in Ollama measured 1818 tok/s before and 1832 tok/s after, which is noise. Token generation is memory-bandwidth bound and never had anything to gain.

Second box: a 3060, no benchmarks

The same plugin and the same install path also worked first time on a second Unraid box with an RTX 3060 12 GB (GA104, 10de:2487) at its stock 170 W limit. It unlocked on the first power cycle, and the CUDA workloads on that box (Ollama, a Parakeet ASR container, Kokoro TTS) run normally afterwards. I did not take before/after numbers there, so treat this as confirmation that the procedure transfers to a smaller card, not as a measurement.

Result 3: the power limit, kept separate

This is not part of the unlock result above, and I am listing it separately so nobody reads it as a firmware gain. Same card, same workload:

state	350 W	400 W	change from the power limit alone
locked, FP16 8192³	70.7	72.6	+2.6%
unlocked, FP16 8192³	123.3	128.3	+4.0%
locked, BF16 16384³	78.7	80.6	+2.4%
unlocked, BF16 16384³	133.4	137.9	+3.4%

Before the unlock, 14% more power bought 2 to 7%, because the card was issue-rate limited and had nothing to spend the watts on. After the unlock the same 50 W buys 3 to 16%, because there is finally work to spend it on. If you have the cooling, the power limit is worth raising after the unlock, not instead of it. Overclocking is the wrong lever on this card: at a fixed wattage an overclock only trades clocks against power for no net gain, which the numbers above demonstrate.

The same is true, more modestly, on the real workload: the bf16 ComfyUI graph went from 22.54 s at 350 W to 22.09 s at 400 W, about 2%. Image sampling is not a pure GEMM stream, so most of the extra watts do not land on the tensor cores. Free, but not transformative.

Caveats

• The plugin is 0.x and new. At the time of writing the author had tested it against an emulated host, not real hardware, so treat this post as the hardware confirmation, not as "battle tested for a year". The failure mode is benign: the hook is written so nvidia always loads, and the worst case is a locked card plus a log line explaining why.

• My before and after are not the same kernel. The locked baseline was taken on 7.3.3 / 6.18.54 / driver 580.178.04. Powering off to apply the unlock also applied the staged 7.3.4 update, so the unlocked numbers are on 6.18.58 / 580.196.07. A kernel and driver change does not produce +65 to +94%, and the int8 null result shows the harness itself is stable, but I am flagging it rather than pretending it is a clean A/B.

• Cold boot, not warm reboot. The module refuses a card the driver has already initialised since power-on. In my case the first power cycle was enough. If the page says "power off required", shut down and start again.

• Display cards blank briefly. The module removes the firmware framebuffer before the FLR and nvidia-drm takes over afterwards. On Unraid with no X this mostly means the local console can go dark.

• Kernel updates need a matching module. The plugin fetches per-kernel builds and checks /boot/bzimage for a staged update, so it stays ahead of Unraid releases. If a kernel has no build yet you boot locked and get a notification.

Verify it yourself

gpu-unlock-ctl status                 # per-card verdict for this boot
dmesg | grep gpu_unlock               # unlock line, should precede NVRM: loading
nvidia-smi --query-gpu=power.draw,clocks.sm --format=csv -l 1   # during a load

Rollback: uninstall the plugin, or boot Safe Mode, or delete config/modprobe.d/gpu-unlock.conf from the flash drive on another machine. Clearing the targets boots the card stock. Nothing is written to the card itself, a power cycle returns it to stock regardless.

Credit

The module and firmware generators are Zagitta/gpu-unlock, built on the CMP-unlocker V67/PLM technique. The Unraid packaging is tabilzad/gpu-unlock-unraid. The modprobe-hook approach was first reported on Unraid in gpu-unlock issue #55. I am just the person who measured it on a 3090 at stock power and wrote it up.

Edited 22 hours ago22 hr by mtietje
ran on two systems with different cards.

As far as I can see, the gpu-unlock author added official Unraid support: https://github.com/Zagitta/gpu-unlock/commit/1fc6d628c49c7fba34ef3a2e7f758700d35ce890

I can already see a first release of the packages: https://github.com/Zagitta/gpu-unlock/releases/tag/unraid

Maybe worth to try out and see if tabilzad/gpu-unlock-unraid is not needed anymore because of this 🙂