GPU Unlock Benchmarks

Published BF16 overview

GPU Unlock changes selected tensor compute paths; it does not make every part of a GPU faster. Start by identifying what a measurement actually times. A synthetic issue-rate loop, a library matrix multiplication and a complete application can report very different gains on the same card.

The main project’s README publishes the following BF16 dense matrix multiplication summary with FP32 accumulation. Values are TFLOPS. Stock power limits apply except for the RTX 3090 Ti entry at 450 W. The RTX 4090 number is explicitly a peak MMA rate. The overview does not supply a complete per-row kernel, driver, CUDA version or run date; those details are not inferred here.

Reported gains are copied from the source rather than recalculated from rounded table values. The GPU names preserve memory-capacity qualifiers where upstream provides them. A 3060 result for the listed 12 GB card is not a measurement of every retail 3060 variant.

Three different measurements

Instruction issue rate

A register-resident tensor loop emphasizes how quickly particular instructions can issue. It minimizes memory traffic inside the timed loop and is useful for detecting a rate limit. Near-doubling in such a test is evidence about that instruction path. It is not a measurement of model loading, data preparation, attention, synchronization or generated tokens per second.

Library GEMM

cuBLAS performs a complete dense matrix multiplication. Matrix dimensions, input type, accumulation type and kernel selection affect the result. Larger matrices can encounter power, clock or memory limits. A useful report therefore identifies the shape and records a matched stock/unlocked pair rather than presenting one large headline.

Applications

A complete inference, training or image-generation task includes work outside the affected matrix operation. Its improvement depends on the time spent in that path. Tokens per second, time to first token, training step duration and image latency are different metrics; do not substitute a TFLOPS percentage for any of them.

Matched RTX 4090 evidence

An independent run in the Ada branch provides a more detailed comparison than the main overview. The reported configuration used an RTX 4090, revision 8855e7b, Linux 7.2.11-arch1-1, NVIDIA 615.78.08, CUDA 13.4.92 and the same 450 W cap. The GNOME desktop stayed active. It is one matched stock/unlocked pair, not a population of cards.

Its instruction probes measured FP16/FP32 at 160.4 → 320.4 TFLOPS and BF16/FP32 at 159.7 → 320.2 TFLOPS. The separate cuBLAS results below used ten warmups, twenty GEMMs per timing and the median of five repetitions. All are FP32-accumulate square GEMMs.

The BF16 4096³ case is deliberately retained: it did not improve. Even in a run with instruction rates near twice baseline, library throughput varied by shape. Seeded numerical cases and the exercised GEMM reference checks passed, but that does not prove correctness for every application or long-term stability.

This is evidence from JustAResearcher/gpu-unlock-ada, not a hardware test of the current Zagitta main branch. The RTX 4090 guide explains the branch, device and power-limit distinctions before installation is considered.

What the workload summaries mean

The main README also summarizes user-reported application results. These ranges describe the stated workloads across their reports; they do not identify a universal expected gain for a selected GPU. Software revisions and exact per-report conditions are not supplied by the summary table.

Prefill processes a prompt, while decode generates subsequent tokens. A setup can improve the first stage and leave the second unchanged. Longer context can change the balance again. Specify which stage was measured before deciding whether a reported inference gain applies to your use.

Quantized files can contain mixed tensor types, and a model’s filename is not proof that the affected accumulation path dominates runtime. The relevant engine and kernels matter. A local Ollama user should measure a representative prompt and decode workload rather than assuming that a synthetic BF16 result predicts both.

Power, precision and unchanged results

GPU Unlock does not raise a GPU’s configured board power limit, change its VRAM capacity or unlock extra gaming clocks. Queries about unlocking a laptop GPU power limit or extending VRAM refer to different hardware and firmware restrictions, not this kernel module. The main project warns that an RTX 4090 can run out of power headroom before it runs out of tensor capability. More available instruction throughput may increase power demand and change sustained clocks under a fixed cap. A small application gain is therefore not automatically evidence that the module failed.

Precision labels need their accumulation mode. FP16 input with FP16 accumulation is different from FP16 input with FP32 accumulation. The detailed Ada record keeps integer and scalar controls near baseline while selected floating-point tensor modes move. Do not generalize one probe to all FP8, INT8, INT4 or mixed-precision kernels based only on the input label.

No gaming uplift is established by these tensor tables. A graphics workload dominated by other execution paths does not become a tensor benchmark. Similarly, unchanged token decode can be consistent with a memory-bound workload. Keep an unchanged result in the comparison rather than silently replacing it with a more favorable test.

Blackwell measurements require another distinction: the RTX 5090 research compares stock accumulation modes. It is not an unlocked before/after result and does not supply a downloadable Blackwell solution.

Plan a useful local comparison

1. Choose a task that reflects your intended use. Record model, input, precision, matrix shape where relevant, and the metric being timed.
2. Record the exact GPU variant, memory capacity, driver, kernel, runtime and project revision. Keep the power policy and software inputs comparable.
3. Warm up the workload and repeat measurements. Preserve individual results, including variation and cases that do not improve.
4. Check output validity separately from speed. A completed timing loop does not establish numerical correctness.
5. After a controlled boot, inspect the per-card log and device state. Installation success alone is not proof of an unlock.

Do not combine a stock run from another machine with your unlocked run. Avoid cross-card rankings where the protocols differ. Background desktop activity, temperature and clock variation can influence a short comparison, so report those limits instead of assigning every change to the unlock.

For a repeat after resume or a warm reboot, verify the state again. A single cold-boot record does not cover every power transition. Keep the same recovery path available throughout testing, and stop if errors or unstable output appear.

Choose the next step

Use Supported GPUs to establish the model’s upstream category, Linux installation for setup and verification, or Troubleshooting when the log and performance disagree. Benchmark evidence informs that decision; it does not remove the risks of changing boot or driver behavior.

Sources & verification

The overview and application ranges come from the main README. The detailed comparison comes from the Ada branch’s matched owner evidence. Both were checked October 29, 2026; this website did not perform these measurements.

• Main benchmark README on GitHub
• Matched RTX 4090 evidence on GitHub