How I Boosted RTX PRO 4000 Blackwell AI Inference Performance by 67%

The software said 106 watts. The GPU was still drawing about 70.

That was my first useful result from trying to unlock an RTX PRO 4000 Blackwell SFF. A number had changed on screen. Under load, the card was behaving much as it had before.

Eventually, that same 24 GB card took Qwen3.8 27B with DFlash2 from 35.04 to 58.53 tokens per second. That is a 67.05% increase in generation throughput, achieved with a 120 W power cap, faster GDDR7 and a core-clock offset.

I did not buy a replacement GPU. The card has no auxiliary power connector, and 120 W exceeds the standard 75 W PCIe slot budget. That cost matters as much as the percentage.

The part I did not expect was what happened to the second Qwen model. It passed 115 tokens per second, but wanted a different tuning profile. After 158 benchmark requests, I had a better headline number and a much less convenient answer to “which setting is fastest?”

Loading a VBIOS into memory

The card was an NVIDIA RTX PRO 4000 Blackwell SFF Edition, with 24 GB of GDDR7 and a factory 70 W power specification. It kept its original blower cooler and automatic fan control. There was no extra power cable hiding outside the frame.

I started after reading reports about GPU unlocking tools, but the method I used was Panchovix's Linux VBIOS Vix Loader: a modified VBIOS loaded into memory through patched NVIDIA open kernel modules.

The EEPROM was not flashed. There was no soldering or shunt modification. I did not modify the motherboard BIOS.

The loader's code shows why that distinction holds. The patch uses NV_VBIOS_OVERRIDE_MODE_KEY for RmLinuxVbiosOverride, reads the image through RmLinuxVbiosOverrideImage, and passes its address and size to the GPU System Processor through vbiosOverrideArgs. The driver stages the image in system memory rather than permanently replacing the EEPROM contents.

Even the backup fought back. An NVFlash save reported success but left a zero-byte file. A sysfs read returned only 4,096 bytes. During a maintenance window, I captured the buffers read by NVFlash through GDB before they were freed. Two independent reads yielded identical 4 MiB images, checked with SHA-256.

A success message was useful only after checking what it had actually produced. The power slider was about to teach the same lesson.

A power limit with more than one lock

This is why 106 W on screen could still mean 70 W under load. The visible power ceiling was only one of the policies involved. The final modified image changed seven decoded fields:

power_max_w and board_fixed_rated_w: 70 → 120 W.
slot_power_max_w and slot_power_rated_w: 66 → 120 W.
input_current_max_ma, input_current_rated_ma and input_current_policy7_limit_ma: 6,600 → 10,200 mA.

These are parser names for GPU VBIOS policy fields. They do not identify an isolated physical protection threshold on the motherboard. Changing a policy in an image does not improve the connector, the traces or the power-delivery hardware.

Voltage fields were not raised. The decoded REL ceiling remained 850 mV, which is not the same as measuring the GPU operating at 850 mV. This series did not have the core-voltage telemetry to make that claim.

Once the higher limit took effect, the next question was whether the extra power bought useful inference work.

The first Qwen model kept gaining. The second flattened out early

I used two existing local configurations: Qwen3.8 27B in NVFP4 with DFlash2 speculative decoding, generating 512 output tokens per request, and Qwen3.6 35B A3B in Q4_K_S, a mixture-of-experts configuration without a speculative drafter in this series, generating 640 tokens.

They differ in model, quantization and decoding path. Their token rates are not a quality ranking or a controlled dense-versus-MoE comparison. The useful comparison is how each responds relative to its own baseline.

At 8,000 input tokens, GPU ECC OFF and zero clock offsets, the power-only sweep produced these generation rates:

27B + DFlash2: 35.04 tok/s at 70 W; 47.05 at 90 W; 52.05 at 106 W; 54.18 at 120 W.
35B A3B: 84.97 tok/s at 70 W; 93.63 at 90 W; 96.21 at 106 W; 96.43 at 120 W.

For the 27B, power alone delivered about 55% more generation throughput. For the 35B, the gain was about 13.5%, and almost all of it had arrived before 120 W.

The headline's 67% therefore cannot be attributed to the power cap alone. It came from combined power and clock tuning. One more condition belongs next to it: the 70 W baseline also ran on the same modified VBIOS, with zero offsets. This was not a clean factory-firmware-versus-modified-firmware A/B test.

Faster GDDR7 exposed a different trade-off

The helper applied offsets to both P0 and P2 performance states through nvmlDeviceGetClockOffsets() and nvmlDeviceSetClockOffsets(), then checked the readback.

With the power cap fixed at 120 W and core offset at zero, I increased memory frequency by roughly 10%, 20% and 33.3%.

On the 27B configuration, those steps improved generation by 4.4%, 6.5% and 5.0%. On the 35B, the gains were 7.3%, 14.0% and 19.8%. These percentages start from 120 W with zero offsets, not from the 70 W headline baseline.

At 120 W with zero core offset, the 27B Qwen peaks at +20% memory frequency while the 35B Qwen keeps gaining up to the tested +33.3% boundary.

8,000 input tokens; GPU ECC OFF; 120 W cap; zero core offset. Individual cells contain 1–3 requests. Lines connect measurements, not predictions.

The 27B generated 57.70 tok/s at memory +20%, then slipped to 56.91 at +33.3%. The higher memory setting coincided with a lower actual SM clock during generation. Memory and compute competing within a shared power budget is a plausible explanation. The sweep did not isolate that mechanism, and the small regression needs more repetitions.

The 35B kept gaining and reached 115.56 tok/s at the highest memory setting, about 36% above its own 70 W baseline. A best result at the tested boundary does not tell me where its true optimum lies.

Adding a +180 MHz core offset to the +20% memory profile produced the 27B's best observed generation cell: 58.53 tok/s. Core +360 MHz produced 58.49 tok/s, effectively tied at the precision this experiment supports, while processing the input faster.

That was the point where “pick the biggest number” stopped working as a rule.

The faster generator could still mean a longer wait

The 67% headline also needs the reciprocal: 67% more tokens per second means roughly 40% less generation time for a fixed output length. It does not mean a complete request finishes 67% sooner.

An LLM response has at least two phases worth measuring. Prefill processes the input. Decode generates the output. Long prompts give prefill more influence over elapsed time; caching changes that balance again.

At 32,000 input tokens, the 35B's balanced profile of 120 W, memory +20% and core +360 MHz measured 2,121.56 prefill tok/s and 82.07 generation tok/s.

The memory-heavy profile, memory +33.3% and zero core offset, measured 1,972.45 prefill tok/s and 82.28 generation tok/s. It generated slightly faster but processed the input more slowly.

Using input_tokens / prefill_rate + output_tokens / decode_rate, an estimated 500-token answer came to 21.18 seconds for the balanced profile and 22.30 seconds for the memory-heavy one. The balanced profile's estimated total was about 5% lower.

Those are calculations from phase rates, extrapolating from runs that generated 640 tokens. They are not direct measurements of complete 500-token responses. Model loading, network time, scheduling and tools are outside the calculation. It is a way to shortlist profiles before measuring the real application.

What the last 14 watts bought

To inspect 106 versus 120 W more closely, I used an ABBA sequence: 106 → 120 → 120 → 106 W, inside one loaded instance of each model. Memory stayed at +20%, the core offset at zero, with two requests per power-and-input-length combination.

That differs from both the zero-offset power sweep and the +180 MHz core setting behind the headline. Alternating the settings helps balance approximately linear drift; it does not eliminate every source of variance.

The 27B gained about 8.6% in generation throughput. The 35B gained 2.2–3.0%, depending on input length. Generation throughput per measured GPU watt fell in all four comparisons, by 2.47–7.30%.

In paired ABBA runs, moving from 106 to 120 W raises generation throughput about 8.6% on 27B and 2.2–3.0% on 35B, while generation throughput per GPU watt falls.

GPU power came from telemetry sampled at approximately 1 Hz. This compares the measured GPU phases, not whole-server power or energy per completed application task.

If the priority is a shorter wait in this workload, accepting lower GPU efficiency may be a reasonable trade-off. The performance data still cannot settle the electrical question.

The upgrade had a cost, even without a new card

This GPU takes its power through the PCIe slot. A 120 W cap exceeds the standard 75 W slot budget. So do the 90 and 106 W settings. Loading a modified image into memory does not add an auxiliary connector or increase the motherboard's physical current-handling capability.

The grid's highest recorded GPU temperature was 92 °C. I did not directly measure VRAM, VRM or slot-contact temperatures. A successful benchmark and a GPU sensor reading do not establish long-term electrical safety or stability. These settings are not a recommendation for someone else's machine.

There were 158 benchmark requests in total: 79 with GPU ECC OFF and 79 with it ON. The performance results discussed here use ECC OFF. Individual aggregate cells contain only 1–3 requests. The 27B baseline has one request and its best tuned cell two; the 35B baseline and best generation cell have two each. This was an exploratory grid on one card, not 158 repetitions of the headline result.

The host used a Ryzen 7 7700, ASRock B650M Pro RS, 32 GB DDR5-6000 CL30 and a Lexar NM790 2 TB SSD. It ran Debian 13.7, kernel 6.12.38+deb13-amd64 and NVIDIA Open 615.71.10. An unoverclocked RTX 2000 Ada 16 GB was also present. The measurements were collected on 24–25 October 2026.

I would repeat the shortlisted profiles, add a factory-firmware baseline, measure wall power and the power path directly, and time real application requests before treating a profile as a durable choice.

I got 67% more generation throughput without buying another GPU. Making that number mean something took more work: separating requested limits from actual behavior, testing two inference phases, and accepting that the second model wanted something different.

The GPU stayed the same. The answer to “fastest” depended on the job.

This article is adapted from my original experiment, 67% more tokens per second from a tiny Blackwell, first published on piszczek.pl. It is based on my own measurements of the RTX PRO 4000 Blackwell SFF. Reports of GPU unlocking tools prompted the experiment; the in-memory VBIOS method used Panchovix's Linux VBIOS Vix Loader, as described above. The methods, measured results and limitations are included here. The CSV files below provide supplementary data for independent checks.