GPU Unlock: 2X Tensor Speed, but What Do LLMs Get?

What is the GPU unlock, and which graphics cards does it speed up?

The GPU unlock is an open-source Linux kernel module that switches the half-rate tensor math of a GeForce card back to full rate. It comes from Zagitta, covers the RTX 30 series chips GA102, GA103, GA104 and GA106, and a fork from JustAResearcher carries the same unlock to the RTX 4090, 4070 Ti SUPER and 4060 Ti 16GB. The module writes the card's speed selectors and resets it before the NVIDIA driver loads, so the stock driver runs afterwards.

On the raw tensor pipe the doubling is real. @superalesha measured BF16 tensor math with FP32 accumulate on one RTX 3090 going from 82 to 155 TFLOPS, and the Zagitta README shows an RTX 3090 Ti going from 87.50 to 157.41 TFLOPS in a BF16 matrix multiply at 450 W. wccftech's post of 24 October said RTX 30 cards get up to 2X faster AI compute with real-world gains of up to 60%, and it had 102,098 views when we read it on 25 October.

What a local LLM gets is smaller, and it depends on the engine. In Strata, prompts were read 10 to 12% faster on @superalesha's two RTX 3090s and 9.9% faster on @StanislawWeston's one, while answers came out at 97.2 and 96.7 tok/s. The README of 25 October sums up four LLM reports as prefill up 14 to 36%, with decode and INT8 work about the same. The sections below show why the gain is that size, which cards have reported, and where @superalesha says the doubled rate should matter more.

The limits sit in the READMEs themselves: the doubling is an instruction issue rate, not application speed. We did not run the module. Every figure here belongs to the person who measured it, and you can size your own machine in our Strata calculator.

Which GPUs the unlock works on

The README of 25 October says the unlock doubles the instruction issuing speed of FP/BF16 FMA into FP32 operations on GA102, GA103, GA104 and GA106 cards. It lists the cards below as reported by users, each with the gain from that report's own dense matrix-multiply benchmark. It warns that the gains are not directly comparable, and that the lowest figure, +25%, is from cards capped at 225 W.

For the 3090 Ti, the poster (applepines) measured an 8192 cubed GEMM at 450 W: FP16 from 87.46 to 118.39 TFLOPS, BF16 from 87.50 to 157.41 and TF32 from 42.58 to 82.61. Those tests used Ubuntu kernel 7.0.0-38-generic, a modified NVIDIA 610.43.02 driver and a custom pre-udev initramfs hook, and the poster writes that other boards and packaged boot integration remain unvalidated.

Not every board gains. A report on an OEM RTX 3080 Ti 20 GB (GA102-250, 10de:2205) found the unlock completing and the selector holding with the driver bound, yet BF16 ran no faster than FP16, a ratio of 1.004 under a fixed 1200 MHz clock.

What a card gains depends on the path the software takes. On the 3060, jesvs measured BF16 matrix multiplies going from 25.8 to 26.9 TFLOPS before to 47.6 to 49.0 after, on driver 615.78.08, median of 7, in the pull request that added it. In llama-bench with a gemma-4-12B Q4_K_XL model he measured no change, 1460.5 to 1467.1 tok/s for prompts and 43.63 to 43.65 for generation. He attributes that to llama.cpp's INT8 tensor path, which that card never throttled, while the module flips the FP16 and BF16 selectors. Strata's prefill gain, by @superalesha's account further down, sits in the BF16 matrix multiplications and not in its int8 experts.

The same GPU unlock on the RTX 40 series

On 24 October @superalesha posted that the RTX 4090 goes from 165 to 331 TFLOPS in BF16 math and the RTX 4070 Ti SUPER from 95 to 190, an exact 2x jump on register-resident tensor issue rate. The post had 71,717 views when we read it on 25 October. The numbers come from a fork, JustAResearcher's gpu-unlock-ada, whose README (version 1.1.1) says the AD102 payload and its debug-booter analysis come from TOTORONG's AD103_win_unlocker, integrated into Zagitta's Linux module, and calls the payload essential to the result.

The README's headline for the RTX 4090 is FP16 with FP32 accumulate going from 165.6 to 331.6 TF/s and BF16 from 165.5 to 330.6, on NVIDIA driver 615.78.08. An independent owner then published a matched stock-and-unlocked pair on a 4090 at its 450 W cap (Linux 7.2.11, driver 615.78.08, desktop active), with the raw files:

The issue rate doubles on the modes that were halved and stays put on the others. Real matrix multiplies gained less and unevenly: FP16 12 to 34%, BF16 16 to 20% at two sizes and nothing at 4096 cubed. The README gives no cause. By our reading it was not the power cap here: among samples at 50% utilization or more, the largest power reading was 308.59 W unlocked against 307.67 W stock, well under the 450 W cap, and the SM clock stayed between 2610 and 2670 MHz. After an ordinary warm reboot the card unlocked again; five of six GEMM medians were faster than the first stock run and the 4096 cubed BF16 median was 8.2% slower.

The README states the limits itself. The 4090 figures are one matched run pair with the desktop active, not whole-application speedups or an extended stability test, and the run had no representative inference or training workload. Display handoff and multi-card operation were not part of the 4090 validation. For the 4070 Ti SUPER the README calls its figures register-resident issue rates, not application GEMM or inference speedups. The table below mixes both kinds of test, and each row says which:

The README's own caveats for these cards: the one FP8 GEMM showed no meaningful gain and other FP8 kernels remain untested. The 4070 Ti SUPER and 4060 Ti 16GB are experimental targets validated on one card each. Each needs its own opt-in flag and one exact PCI address, and gpu_unlock.targets=all never selects them. The 4060 Ti 16GB run saw its rate readouts flip to full, but no stock throughput run exists, so no speedup is claimed for it. A first attempt needs a full power-off. The 4070 Ti SUPER unlocked again on warm reboots, and the README says other boards may not. The Windows port is tied to one captured MSI Z490 profile and does not add AD104 to the Linux module.

The only LLM figure we have for an Ada card is sankerXD's, on the Inno3D 4070 Ti: in a two-card Strata pipeline whose other card, an unchanged RTX 2080 Ti 22 GB, bounds the speed, prefill went from about 600 to 800 tok/s to about 2,900 to 3,000, and decode did not move. That is far above the card's 83% matrix-multiply gain and he does not describe the stock run's conditions, so treat it as a lead.

How the GPU unlock works, and when it runs

The module comes from Zagitta. Its README describes a Linux kernel module that combines the CMP unlocker's V67/PLM technique with the pre-driver timing of the UEFI approach. It is neither a UEFI application nor a patched NVIDIA driver: the stock driver loads afterwards and binds the card as usual.

The sequence explains every limit. The module writes the speed selectors (SS0 0x88888888, which selects the full BF16 rate) and performs a function-level reset before the NVIDIA driver binds the card. The packages put it in the initramfs, ahead of nvidia. It does nothing unless the kernel command line opts in: gpu_unlock.targets=all for every unbound GA102, GA104 or GA106 card, or a list of PCI addresses for only those cards.

Why RTX 30 cards ship with a half-rate mode

NVIDIA's own GA102 whitepaper lists the card's tensor rates, and the table already shows the split. The RTX 3090 Founders Edition column reads 142 TFLOPS for FP16 tensor math with FP16 accumulate, and 71 for FP16 and BF16 tensor math with FP32 accumulate. TF32 is listed at 35.6. Each figure comes with a second, doubled number for the sparsity feature, and all of them are peak rates at the 1695 MHz boost clock.

Take the first pair. 142 is twice 71. That is the half rate @superalesha means when he says every 3090 ships with FP32-accumulate tensor math at half speed, and that the driver reports it as FMLA32 = 1/2. After a cold boot with the module, all four of his cards reported FMLA32 = full.

One caution before comparing numbers across sources. The whitepaper's 71 is a peak at NVIDIA's 1695 MHz boost clock, and the 82 below is a measurement on a real card that may boost higher, so the two are not one number and the stock measurement sits above NVIDIA's peak.

What @superalesha measured

His post on 21 October 2026 opens with the headline: his 3090s got 1.9x faster at BF16 tensor math, with one Linux kernel module, at 300W. The image under it separates three layers of that claim.

His chart of one card before and after the module. Measured by @superalesha, from their post.

The registers-only rows are the raw pipe. The cuBLAS row is a real matrix multiply moving real data, and it lands at 1.54x. The gap between 1.90x and 1.54x is the first sign that the full speed-up does not survive contact with a real workload.

His image also lists what the module did not touch, measured in cuBLAS: FP16 with FP16 accumulate went from 103.5 to 104.1, int8 from 205.7 to 208.0 TOPS, and FP32 on the CUDA cores from 23.1 to 23.2. His rig ran NVIDIA driver 610.43.02.

Why 1.9x became 10% in Strata

@superalesha ran Strata with Qwen 3.8 Flash Next on two cards and measured prefill. It rose 12% at a 4K prompt, 12% at 10K, and 10% at 90K, from 3205 to 3536 tok/s.

He had predicted more. In his words he had said +14 to 19% at 90K, and he was wrong: the GEMM phases got 23% shorter, but they are only about 40% of Strata prefill, and the int8 experts, copies and CUDA core kernels did not get any faster.

His numbers reproduce the result. If 40% of the time gets 23% shorter, total time falls by about 9.2% (0.23 times 0.40). A run that takes 0.908 of the time is 1.10 times as fast, about 10% faster, which is what he measured at 90K. That arithmetic is ours, over his figures.

The pipe doubled. The matrix multiplications got 23% shorter. The prompt got about a tenth faster, because most of what a prompt waits on is not matrix multiplication. A workload that spends more of its prefill in large BF16 matrix multiplications would see more, and one that spends less would see less. His own log-prob dump over 1996 teacher-forced positions was the same file byte for byte as the stock run, with the same expert cache size.

What @StanislawWeston measured on his own card

A reader replied on 22 October to the X post that carried these numbers: prefill is 10% faster on his own RTX 3090 with GPU unlock on. His screenshot is labelled Qwen3.8 Flash Next (Strata 1024K), and he writes of his RTX 3090 in the singular.

His Strata screenshot, as posted. Measured by @StanislawWeston, from their post.

His own summary is +9.9% prefill speed, and about a 10% prompt-processing gain with no clear generation-speed gain. The division checks out: 703,923 over 341.5 is 2,061.3, and 698,062 over 372.1 is 1,876.0. The faster run took 30.6 s less while reading 5,861 more tokens, so the two prompts are not identical and the comparison is of speeds.

His result lands where @superalesha's did, on a different machine and at a far longer prompt.

What happened to generation speed

Decode was 97.2 tok/s with the unlock and 96.7 without, a difference of 0.5% from a single run each, so it sits within what run-to-run noise could produce. @superalesha's post does not report decode speed.

Decode did not move in @StanislawWeston's two runs. On a GPU, writing a token usually waits on how fast the weights can be read from memory, and NVIDIA's whitepaper gives the 3090's as 936 GB/sec, from 24 GB of GDDR6X at 19.5 Gbps on a 384-bit bus. The module, per its README, is about the tensor-math speed selector, which is a different part of the card. @superalesha writes that decode waits on memory and that his engine runs its experts in int8. We do not know where Strata's decode limit sits ourselves, because it also moves data between RAM and SSD.

What LLM runs show across engines and cards

After the first reports, owners with a stock boot and an unlocked boot began running LLMs on other engines. The README of 25 October sums it up as LLM prefill up 14 to 36% in four reports, with decode and INT8 work about the same. These are the runs we found. Each row is one person's setup, and engines, models, power caps and prompt lengths differ, so read each row on its own and do not rank them.

Three things show in the rows.

Generation did not move, with two exceptions that carry a caveat. In every report that compared both halves, decode stayed within its own spread or close to it. One Strata run shows +10% in a single cell at 4K, and the 100,000-token Strata run shows +5.9%, where its reporter notes that the two boots generated different text, so that figure compares different token sequences.

The prefill gain depends on the engine, and short prompts can see nothing. noon-at-cgn ran vLLM and Strata on the same two cards. vLLM gained about 33% at every length, while Strata showed no change at 8K and about 12 to 13% at 32K and 128K. He concludes that the benefit depends heavily on the engine and its kernels. The llama.cpp rows gained 2% to 7% at every prompt length they tested, which is in line with the INT8 explanation given for the 3060 in the cards section above. None of these reporters tested that explanation. Where the model's weights sit may matter as well: chflame163 saw no change at about 32K and says expert streaming from RAM dominates there, while noon-at-cgn's Strata run kept its experts resident on the cards and gained 13% at 32K. Those are different setups, so this is a lead and not a result.

The power cap changes the size of the gain. galvani swept one 3090 from 250 to 375 W and the prompt gain grew from 25% to 50%. The README says the same of matrix multiplies: its lowest gain, +25%, comes from cards capped at 225 W.

We did not run any of this. The reporters list their own caveats, for example noon-at-cgn's one boot per arm and an arm order that differed between workloads.

Beyond the 3090: an RTX 3080 Ti

@MarcJSchmidt quoted our X post on 23 October 2026 with a result from another card. On his RTX 3080 Ti he got about 1.6x on raw TF32 performance and about 1.4x on his robotics training. His image gives the detail, all at a 300 W power limit with NVIDIA driver 595. He writes that the module was only tested on the 3090 and ran cleanly on his 3080 Ti, and that outputs match stock bit for bit.

His results for the RTX 3080 Ti, as posted. Measured by @MarcJSchmidt, from their post.

His MLP training test (4 layers, steps per second, unlocked over stock) rises with size. At width 256 and batch 256 it is 1.06x for TF32, 1.02x for BF16 and 1.01x for FP16. At width 4096 and batch 32k it is 1.47x, 1.42x and 1.41x. FP32 stays at 1.00x throughout the largest runs. He writes that power draw did not rise, staying capped near 300 W, and that energy per step drops 25 to 33% on large MLPs.

He explains the gap between the GEMM ratios and the pipe's doubling as the power cap, not heat (71 C at most): per clock the unlock gives about 1.9x, but the clock falls from about 1690 to about 1350 MHz, which leaves about 1.5x. On games he writes that there is no gain, since they run on the FP32 cores, which fits the FP32 control row.

This is one owner, one card and one driver. It is his measurement of his own test, and the training result is for an MLP, not an LLM or a LoRA.

Where full BF16 speed should matter more

@superalesha reads his own Strata result as the small one: decode waits on memory, and his engine runs its experts in int8, which the module did not touch (his image lists int8 at 205.7 to 208.0 TOPS, unchanged). Writing a token on a GPU is usually limited by memory, not by tensor math, which fits how little decode moved.

The higher rate could show in a workload that is bound by BF16 tensor math instead. The one he names is training: in his words, every LoRA anyone ever trained on a 3090 went through exactly the path that was cut. Measuring such workloads is, he writes, what he does next.

Three measurements of this kind now exist, each from a different card and workload. @MarcJSchmidt's MLP training rose up to about 1.4x on an RTX 3080 Ti (see the section above). foureight84, on four 3090s, measured LoRA fine-tuning of a 1.7B backbone in BF16: step time fell from 10.80 s stock to 9.00 s unlocked at 240 W (+20%), and one card raised to 350 W reached 7.24 s a step (1.49x). Eunho-J, on two 3090s at 420 W, measured Krea 2 Turbo image generation falling from 16.536 s to 10.552 s per image (1.567x), with output pixels that were not identical across the two boots because strict determinism was off. These are measurements of those tests, not predictions for yours. For a real matrix multiply on a 3090, the number to use is @superalesha's cuBLAS BF16 GEMM: 64.4 to 99.1 TFLOPS, 1.54x, against 1.90x for the raw pipe.

What a faster prompt is worth in Strata

An answer from a local model has two waits. First the engine reads your prompt, which is prefill. Then it writes the reply token by token, which is decode. On a 3090 running Strata, which splits the 180B Qwen 3.8 Flash Next across GPU, RAM and SSD, the first wait is the one that grows with your context.

By our arithmetic, @StanislawWeston's two speeds would read a 100,000-token prompt in 53.3 s without the unlock and 48.5 s with it, 4.8 s less. He measured them on prompts of about 700,000 tokens, so the figure at 100,000 is a projection, not a measurement. A workflow that sends long prompts again and again pays that saving each time.

Before the unlock: Strata speeds on an RTX 3090

Before any unlock, here is the baseline: the single-card RTX 3090 runs in our Strata calculator, as the testers reported them (our run set, read 21 October 2026). Every row is one person's setup, with the conditions they gave. Builds, RAM, engine versions and prompt lengths differ, so read each row on its own and do not rank them.

Across those nine rows, decode runs from 52.6 to 112.2 tok/s and prefill from 128 to 1,900 tok/s. The rows differ in build, RAM, context and prompt length, so the range is a spread of setups, not of one setup.

Two 3090s sit higher. @geldeki posted four runs, three of them on engines 0.1.42 to 0.2.0-beta, with decode peaks from 117.3 to 204.6 tok/s and prefill figures from 2,844 to 3,149 tok/s. Where he states the prompt, it is 167K to 191K tokens, and his two latest runs carry a 280 W cap per card.

@StanislawWeston's 1875.9 tok/s stock and 2061.1 with the module come from one 3090 at 1024K on prompts of about 700,000 tokens. The nearest row in prompt length is @needmorevram's 898 tok/s over 839,061 tokens, on a different build and different settings, so the two do not show what the module adds. They only show the range of prefill speeds one 3090 is reported at. The Strata calculator lets you set your own RAM and see the rows that match it.

Check what your GPU can run

A faster prompt does not change what fits. For that, the Strata calculator sizes Qwen 3.8 Flash Next against your GPU, RAM and SSD, and the GPU checker does the same for every other model we carry. For measured decode speeds across cards, see Qwen 3.8 27B speed and the speed checker.

FAQ

What is the GPU unlock for RTX 30 cards?

A Linux kernel module that restores the full instruction issue rate for FP16 and BF16 tensor math with FP32 accumulate on GA102, GA103, GA104 and GA106 cards, according to its README. It runs before the NVIDIA driver loads and changes no driver. For an RTX 3090 Ti the README shows a BF16 matrix multiply going from 87.50 to 157.41 TFLOPS at 450 W, and the doubling applies to the instruction issue rate, not to application speed.

How much faster does the GPU unlock make a local LLM read prompts?

It depends on the engine. In Strata, @superalesha measured +12% at 4K and 10K and +10% at 90K on two 3090s, @StanislawWeston +9.9% on a 703,923-token prompt, and robertoetcheverryr +16% at 16K. In vLLM the reports run from +9.3% on four cards to +33%, and +50% at a 375 W cap. In llama.cpp, @ItsmeAjayKV measured +3.8% to +6.8%. Short prompts can see nothing, as at 8K in noon-at-cgn's Strata run.

Does the GPU unlock make text generation faster?

Not in the reports that measured it. In @StanislawWeston's run, decode was 97.2 tok/s with the unlock and 96.7 without, and the later reports above also show decode inside its own spread. The module changes tensor-math speed, and generation on a GPU is usually limited by memory bandwidth instead.

Why is the GPU unlock gain 10% in Strata when the tensor pipe doubled?

Because the matrix multiplications are only part of prefill. @superalesha found the GEMM phases got 23% shorter and make up about 40% of Strata prefill, and that the int8 experts, copies and CUDA core kernels did not speed up. Combined, that is about 10% faster.

Which cards does the GPU unlock accept?

The README of 25 October says it covers GA102, GA103, GA104 and GA106 cards, and anything else is logged and ignored. It lists reports on the RTX 3090 Ti, 3090, 3080, 3070 and 3060, and one OEM RTX 3080 Ti 20 GB where the unlock completes but BF16 stays at half rate. The separate Ada fork lists the RTX 4090 and, as experimental single-card targets, the 4070 Ti SUPER and 4060 Ti 16GB.

Does the GPU unlock need a full power-off?

The Ada fork's README asks for a full power-off before the first attempt, and says a warm reboot is not guaranteed to give a fresh card, though it did on the tested RTX 4070 Ti SUPER. For the Zagitta module, the README of 22 October said yes: the unlock needed a cold card, warm reboots were not supported, and a warm reboot was expected to fail and leave the card as it was. The README of 23 October no longer states that. It says a card some driver already initialised is still refused, and that if a card's firmware never stops you should power off before trying again.

Does the GPU unlock change what the model outputs?

@superalesha compared a log-prob dump over 1996 teacher-forced positions against the stock run, with the same expert cache size, and found the same file byte for byte.

Does the GPU unlock work on an RTX 4090?

According to the fork's README, yes, and an independent owner's run agrees. That run, on a 4090 at 450 W, measured FP16 issue rate with FP32 accumulate going from 160.4 to 320.4 TF/s and BF16 from 159.7 to 320.2, while real cuBLAS matrix multiplies gained 12 to 34% for FP16 and 16 to 20% for BF16 at two sizes, with no change at 4096 cubed. The README says these are not whole-application speedups, and the run did not include a model.

Does the GPU unlock run on Windows?

gpu-unlock itself is a Linux kernel module. An experimental port for Windows by impacifist, Windows-GPU-UNLOCK, builds on it: a UEFI program run from a FAT32 USB stick before Windows boots, which continues into Windows Boot Manager without a reset. Its author measured a 4096 by 4096 matrix multiply on Windows 11 with NVIDIA driver 617.14 and reports BF16 tensor math with FP32 accumulate going from 70.5 to 128.7 TFLOPS (+82.48%, median of 3 runs) on one specific PC, and notes that the earlier figure was not a separately controlled cold boot without the unlock. The README calls the code a port locked to that machine, not a general program for every 3090, and its figures are matrix-multiply TFLOPS from a CUDA and cuBLAS test. For the RTX 4070 Ti there is a separate Windows UEFI port by Latence.app, tied to one captured MSI Z490 profile, with one machine measured at 84.08 to 151.43 TFLOP/s for FP16 and 84.03 to 148.25 for BF16.

How fast is Qwen 3.8 Flash Next on an RTX 3090 in Strata?

On @StanislawWeston's 3090, in a session labelled Strata 1024K, Strata read prompts at 1875.9 tok/s stock and 2061.1 tok/s with gpu-unlock, and generated at 96.7 and 97.2 tok/s. On two 3090s, @superalesha measured prefill at 3205 tok/s stock and 3536 with the module at a 90K prompt.