RTX Spark Encrypted Firmware: Linux Inference Stuck Near 35%

nvidia-smi under load is the whole story. If Graphics/SM clocks sit near 780 MHz while the brick is plugged in, you are in the encrypted-firmware trap. On a 120B-class model that looks like ~14 t/s instead of the ~65 t/s Windows and WSL both clear. Unplug the same native Linux box and clocks climb again – so this is not “Linux is slow.” It is “Linux on AC missing a Windows-only power path.”

Hands-on write-ups hit in early November 2026 and spread fast. Below is the workflow that actually returns near-full tokens/sec today, then the cause, then the traps people burn afternoons on.

Three checks that restore WSL speed

What you want: vLLM, llama.cpp, or similar inside WSL2, riding the Windows driver stack so clocks stay in the ~2 GHz band on AC.

1. GPU memory carve-out (Windows only). Open the NVIDIA App → System → Advanced. Default on 128 GB unified systems often reserves ~96 GB for the GPU. Move the slider for the split you need, restart when asked. Native Linux and WSL both inherit whatever Windows last wrote. Official control surface: Nvidia’s RTX Spark memory / drivers / power page.
2. Raise WSL RAM. Create or edit %UserProfile%.wslconfig:

   [wsl2]
   memory=64GB
   processors=16
   swap=16GB

   Leave headroom for Windows. PowerShell: wsl --shutdown, then start the distro again. Out of the box, WSL memory is often cited around ~14 GB or half the host – fine for toys, brutal for 120B-class weights.

3. Prove clocks before you blame the model.

   nvidia-smi -q -d CLOCK | grep -E "Graphics|SM"
   nvidia-smi dmon -s u

   You want ~2 GHz-class numbers under inference, not ~780 MHz. Same machine, eight-client vLLM: about 127 t/s in WSL versus 39.5 t/s on throttled native Linux (MindStudio). Longer single runs told the same story – Windows held ~2.2 GHz for minutes while plugged Linux sat near 790 MHz for a much longer wall clock.

Sanity check: keep a tiny native Windows llama.cpp or LM Studio build. Fast Windows + slow WSL means your .wslconfig or CUDA-on-WSL setup, not the firmware.

That pairing – Windows power path, Linux tooling – is the practical daily driver until a real Linux platform-controller port exists.

Why AC power tanks native Linux only

~65.4 t/s Windows, ~65.1 WSL, ~61 on DGX Spark, ~13.9 native Linux on AC for GPT-OSS-120B on an MSI Prestige RTX Spark unit. Unplugged native Linux? Back near ~61 t/s. Those figures come from MindStudio’s side-by-side; Alex Ziskind’s LM Studio pass landed in the same band (~15 t/s plugged, ~61 unplugged), summarized at NeoTeo (31 Oct 2026).

Temperatures stayed 40-47°C in the slow runs. Not thermals. Clocks simply would not rise.

The smoking gun is a device named Nvidia Platform Controllers and Framework. Firmware hands it an encrypted power-state table. The Windows stack can decrypt that table and arbitrate the shared CPU/GPU budget. Linux has no matching path. Disable the same device in Windows Device Manager and you reproduce the Linux shape on purpose: roughly 2 GHz / ~83 t/s down to 786 MHz / ~31-32 t/s; turn it back on and speed returns. Community attempts to pull the key or bypass the table went nowhere – one path ended in a kernel panic.

It feels backwards. The charger should raise the ceiling. Without the controller logic, plugged-in Linux is the gear that never shifts up.

Common pitfalls

Chasing decryption is a dead end. As of early November 2026 there was no public Nvidia timeline for shipping platform-controller support to Linux drivers – watch driver branches and Spark forums, but do not block on them.

Memory is a double gate. If the Windows slider still parks ~96 GB on the GPU, native Linux may only see a thin remainder of the 128 GB pool (reports around ~28 GB usable until you lower the carve-out from Windows). WSL adds its own cap via .wslconfig. Fix both or large models OOM while clocks look “fine.”

Battery-only native Linux does hit near-full clocks on the tested MSI hardware. Usable for short sessions. Awkward as a daily AC workflow.

Practical paths compared

After this sticks: KV-cache tuning on unified memory, or bandwidth checks against Strix Halo / Mac Studio on the same weights.

FAQ

Does unplugging really fix native Linux?

On the tested MSI Prestige unit, yes. AC is the slow path; battery returns Windows/DGX-class clocks and tokens/sec.

Can I dual-boot and skip WSL?

You can boot native Linux after setting the Windows memory slider first. Then every AC inference session still crawls. Example: you want a long vLLM overnight job at the desk – charger in – and you are back near 780 MHz. Keep a Windows partition for the driver stack and live in WSL for that work.

Will Nvidia fix encrypted firmware on Linux?

A real fix means Linux drivers that understand the same encrypted power table the platform controller expects. People already tried key extraction; it did not yield a general workaround. No public ship date sat on the table when the first detailed posts landed in early November 2026 – this may have changed, so check current Nvidia Linux branches. Until something lands, run WSL for real work and treat native Linux on AC as experimental.

How long until that controller logic shows up on Linux in a form mere mortals can install? Nobody outside Nvidia can answer that cleanly yet.

Set memory= in .wslconfig, shut down WSL, load a model, and re-check clocks. If you still see ~780 MHz inside WSL, stop tuning the model – fix CUDA-on-WSL and the Windows carve-out first.