GPU Unlock RTX 4090

Experimental Linux support

The desktop RTX 4090 is an Ada Lovelace card listed as experimental by Zagitta/gpu-unlock. Independent work in JustAResearcher/gpu-unlock-ada also records successful firmware transactions, driver handoff and matched measurements on specific RTX 4090 configurations. These are related projects, but their revisions, validation records and instructions must remain separate.

The practical answer is conditional: there is public Linux evidence for the desktop RTX 4090, but a model name is not a guarantee for every board, kernel, driver or boot setup. This website does not test your card or detect whether you have executed an unlock. Use the evidence below to decide whether further investigation is justified, then use the main Linux installation guide for the main project’s workflow.

Confirm the exact RTX 4090 variant

These are PCI vendor/device identifiers, not the full BDF address used to select a card at boot. A BDF such as the location reported by lspci -D identifies where a device is attached on your machine. Verify both the actual card identity and the selected location before applying a target parameter.

A desktop success does not establish laptop behavior. The Ada branch’s laptop notes include one machine that reached an unlocked state without a throughput improvement and another with near-doubled throughput on two cold boots. Power rails, ROM exposure and reset handling differ. A 4090 D also has its own target conditions; do not silently substitute it for a 2684 record.

What approximately doubled

Different baselines are expected because these are separate records. Do not combine one report’s stock value with another report’s unlocked value. The main README explicitly warns that large GEMMs at stock power limits gain less than the RTX 4090 peak MMA figure suggests.

The original Ada experiment reported FP16/FP32 at 165.6 → 331.6 TFLOPS. Its benchmark kept operands and accumulators in registers during timed instruction loops. That design measures issue throughput while reducing memory traffic; it is useful evidence for the rate override, not a measurement of a complete neural network.

Scope of the matched run

The independent owner record used revision 8855e7b, Linux 7.2.11-arch1-1, NVIDIA 615.78.08 and CUDA 13.4.92, with the same 450 W cap and desktop active. It measured a matched stock/unlocked pair on one card with the same benchmark binaries. FP16/FP32 issue rate moved from 160.4 to 320.4 TFLOPS, while integer and scalar controls remained near baseline.

Its real cuBLAS measurements were more varied. FP16 4096³ increased from 153.234 to 205.956 TFLOPS. BF16 8192³ increased from 166.197 to 192.744. BF16 4096³ instead measured 153.418 stock and 152.720 unlocked. Keeping that unchanged case is essential: the result is not “every matrix operation doubles.”

Seeded numerical cases and the exercised matrix reference checks passed. No observed Xid errors in that collection is useful evidence, but neither fact proves every application correct or establishes long-duration electrical and thermal reliability. The benchmark comparison preserves the full set of matrix shapes and its timing method.

An unlocked path can leave inference unchanged

The Ada branch also reports a modified 48 GB RTX 4090 with the same 10de:2684 identity. Its tested environment used Ubuntu 26.04.1, Linux 7.0.0-38-generic, NVIDIA 610.57.04 open modules and a 450 W limit. FP16/FP32 and BF16/FP32 instruction rates approximately doubled on that card.

The associated mixed-quantization mixture-of-experts serving workload did not show a useful gain. The source reports 8K prefill at 0.983× and explains that the affected floating-point tensors represented only a small portion of that workload. Decode variation exceeded any claimed effect. This is an example of workload selection mattering, not evidence that the firmware transaction was imaginary.

It is one modified board and one workload. It does not establish how an ordinary 24 GB card will perform in your engine, and the modified card is not a recommendation to alter memory hardware. For a local model, separate prompt processing from token generation and test the exact precision paths actually used.

Power limits and reset behavior matter

Removing a rate restriction does not increase the board’s configured power budget. When an affected workload demands more compute, the existing power limit can reduce sustained clocks and keep library throughput below the instruction-rate change. Preserve the power conditions when comparing results instead of treating a different cap as part of the same experiment.

The detailed Ada transaction checks the firmware outcome and selector readbacks before and after a Function Level Reset, then hands the card to the unmodified NVIDIA driver. A successful module return alone is insufficient: a card can be skipped or a transaction can fail while module initialization itself completes.

Cold and warm states also differ. The branch advises a full power-off for a first attempt; a warm reboot is not guaranteed to restore fresh firmware state on every board. A recorded warm repeat on one card does not transfer to all cards or validate suspend and hibernation.

Choose a project without mixing instructions

For the main repository, follow Before you start, the automatic installer and the appropriate bootloader method. Confirm the current main README rather than assuming an independent branch’s experimental flags apply. The normal Linux guide does not need a separate universal “4090 installer.”

Searches for GPU Unlock 1.1.1 refer to the separate JustAResearcher/gpu-unlock-ada project’s versioned research, not the main Zagitta/gpu-unlock installer or a universal RTX 40 release. The Ada branch selects its RTX 4090 AD102 assets automatically for 10de:2684, while other Ada IDs can require additional opt-ins and exact targets. Those are branch-specific rules. Its pinned NVIDIA firmware inputs and recorded confirmation-driver versions describe different parts of the test; a firmware input number is not a blanket required driver downgrade.

If you deliberately choose the independent branch, review its own source and recovery documentation. Keep a stock boot entry and the original parameters. Do not copy a low-level register-writing procedure, another card’s BDF or an unrelated branch flag merely because a throughput table looks promising.

Verify the outcome you actually need

After a controlled boot, inspect the per-card log using the verification instructions. Confirm driver handoff and device health, then compare a representative workload. Keep the inputs, precision and software environment matched, and retain errors and unchanged measurements in your report.

If the log indicates a bound card, stale firmware state or a failed transaction, use Troubleshooting before another attempt. If firmware did not stop, follow the documented power-off recovery; do not force-unload buffers the GPU may still use. If the application gain is not useful, removing the opt-in is a valid outcome.

For Windows, read the separate Windows evidence overview. The Linux RTX 4090 reports do not add a supported RTX 4090 machine profile to that independent Windows repository.

Sources & verification

Reviewed October 29, 2026. The main repository supplies the support category and overview. The independent Ada README links the original transaction, matched owner run and modified-card evidence. Results belong to their authors and tested configurations, not this website.

• Main GPU Unlock README on GitHub
• Independent Ada results and evidence on GitHub