GPU-unlock: compatibility and the cost of a faster workload

GPU-unlock is a Linux kernel module for selected NVIDIA Ampere GeForce cards. It changes FP16/BF16 instruction issue-rate selectors before the normal NVIDIA driver takes control. It is relevant when a workload spends time on matrix computation; it adds no VRAM and does not replace an LLM serving runtime.

The project’s version 1.0.0 targets GA102, GA103, GA104 and GA106 devices. Check your exact PCI ID and a matching report before treating your card as compatible. A successful unlock log alone does not establish a speed gain.

What GPU-unlock changes

The module runs during early boot, performs the unlock and resets the selected card before the unmodified NVIDIA driver binds it. Its packages integrate with the initramfs. Loading it after NVIDIA already owns the card does not apply the same boot flow.

More FP/BF16 compute can help matrix-heavy work, including some LLM prompt processing. Token-by-token decode often waits on memory bandwidth instead. Quantized kernels, CPU offload, transfers and tool calls introduce other limits. Measure each part of your workload before estimating savings.

Check the card, PCI ID and reported outcome

The source accepts a list of GeForce PCI IDs. Acceptance by the module and successful acceleration are separate checks. The following is a selection from the project’s tested-card table as read on October 25, 2026:

Do not extend these rows to every RTX 30 board, laptop or OEM revision. The 20GB OEM card above differs from a retail 12GB 3080 Ti, and two cards with similar names can behave differently. Read the current source device list and tested-card reports together.

What the community measured

In issue 9, robertoetcheverryr reports a Zotac RTX 3090 on Debian 13, kernel 7.2.9 and NVIDIA open driver 615.71.10, with a 350W cap and an undervolt. The Strata test uses IQ3_S weights and INT8 KV cache, but the report does not name the model. Its baseline and unlocked runs were recorded on consecutive days.

At 16K, reported prompt processing rises from 2,594 to 3,009 tokens/s and time to first token falls from 6.35 to 5.48 seconds. Decode at that length stays near 97 tokens/s. The 4K prompt result is almost unchanged. The benefit depends on prompt length, and the unnamed model limits comparison with other setups.

In issue 12, simonezpx3 reports an ASUS Dual RTX 3070 OC (10de:2484) on Arch Linux, kernel 7.2.11 and NVIDIA proprietary driver 615.78.08. Its 8192×8192 dense BF16 GEMM rises from 39.74 to 71.99 TFLOPS at the stock 240W cap, or 69.56 TFLOPS with a 200W cap. The author also checks numerical errors against an FP64 CPU reference and reports no NaNs or infinities in those tests. These are matrix tests; the thread provides no LLM decoding measurement or complete-task cost.

In issue 28, an AI-assisted report filed for a hardware owner describes a GA102-250 RTX 3080 Ti 20GB OEM on CachyOS with NVIDIA 615.78.08. The selectors remain set after driver initialization, but BF16 stays near the half-rate ceiling. The October 25 follow-up corrects an earlier diagnosis and still reports no full-rate uplift. It also records hangs during experimental selector changes. Those experiments are failure evidence, not a tuning recipe.

Plan boot recovery before evaluating it

GPU-unlock changes the early GPU initialization path and uses an out-of-tree kernel module. A display card can blank during reset; a failed boot can interrupt access to the machine. Keep a known-good boot entry and a way to recover without that GPU. On a rented machine, kernel and bootloader access may be unavailable.

The project requires explicit boot-time opt-in. Removing the target option disables unlocking for the next boot; package removal also removes its module integration. Read the project’s boot flow and opt-in documentation for the installed revision. Plan how to reach the bootloader and restore the original image before changing it. The repository notes that a firmware failure may require a full power-off, and hibernation is outside its covered resume path.

In the October 23 report above, the RTX 3070 resumes from S3 but loses the higher compute rate. Zagitta initially reports that a different machine fails to wake, then asks the reporter to retry updated master later that day. The current README describes automatic re-unlocking on resume; test it on your installed revision because the thread has no successful retest for either earlier configuration.

Module signing and Secure Boot depend on the host. Issue 9 used Secure Boot off and an unsigned module. Keep your host’s existing security policy and check its signing and recovery process. The module and packaging are GPL-2.0-only; generated payload and NVIDIA firmware retain their separate notices.

Price the completed workload

Use matched before-and-after runs on the same model, quantization, context, batch, runtime and power settings. Record loading time, prefill, decode, full task time, errors and whole-system energy. Check output quality and successful completion along with speed. GEMM TFLOPS alone cannot establish an LLM token rate or a diffusion image time.

For example, a hypothetical task with 10 seconds of prefill and 90 seconds of decode takes 100 seconds. Even a 20% increase in prefill throughput changes that to about 98.3 seconds if decode is unchanged. That is roughly 1.7% less task time, before tool calls and other overhead.

For hourly rental, compare total allocated time at the actual node rate, including setup and failed trials. On an owned machine, compare measured energy per accepted task, since higher power can offset a shorter run. Use the cost assumptions guide for what belongs in that budget, and the local inference directory to choose the serving runtime separately.

Reviewed October 26, 2026. Start with the GPU-unlock repository, then check a report for your exact board. Keep a measured result for your own workload before changing any cost or throughput estimate.