Nvidia RTX Spark laptops suffer 65% GPU slowdown on Linux due to encrypted power firmware

TL;DR

  • Dual‑booting Linux on RTX Spark laptops works, but the GPU is throttled to ~780 MHz on AC power, dropping inference throughput to ~14 tokens / s.
  • The throttling is caused by a Windows‑only firmware component, Nvidia Platform Controllers and Framework, whose encrypted power table can only be decrypted by the Windows driver.
  • Benchmarks show Windows and WSL achieve ~65 tokens / s on a 120 B model, while native Linux manages only ~14 tokens / s.
  • Memory allocation is another hurdle: the laptop reserves 96 GB of unified memory for the GPU, adjustable only from Windows.
  • For now, WSL is the practical solution because it runs on the Windows driver stack and retains full GPU boost.
  • A permanent fix requires Nvidia to expose the same power‑management logic in its Linux driver.

Linux boots, but the GPU is locked down

When the MSI Prestige N16 Flip AI Plus (an RTX Spark laptop) is installed with Linux, the open‑source Nvidia kernel driver loads correctly and the system can output 4K @ 120 Hz, with audio, keyboard, and touchpad functional after manual configuration. However, once the laptop is connected to wall power, the GPU clock stalls at ~780 MHz instead of the ~2.2 GHz observed on Windows. This clock collapse reduces a chip capable of 65 tokens / s on a 120 B model to **14 tokens / s**, a 5× slowdown.

"GPU clock speed collapses to about 780 MHz on Linux when plugged in, compared to roughly 2.2 GHz on Windows, because the firmware’s power table is encrypted and only the Windows driver can decrypt it." – MindStudio blog

The slowdown is not caused by thermal throttling; temperatures stay between 40 °C and 47 °C. It is purely a power‑management restriction.

The hidden Windows‑only controller

Device Manager on Windows reveals a component named Nvidia Platform Controllers and Framework. This firmware‑driver pair governs the shared power budget between CPU and GPU on the laptop (unlike the desktop DGX Spark, which has a dedicated GPU rail). The controller receives an encrypted power‑table from the firmware; the Windows driver holds the decryption key.

Disabling the controller in Windows reproduces the Linux slowdown: token throughput drops from ~83 tokens / s to ~31 tokens / s and the GPU clock falls to ~786 MHz. Re‑enabling it restores full speed instantly. Linux lacks any equivalent component, so the GPU never receives the higher power allocation.

"The cause traces back to a component visible in Windows Device Manager called the Nvidia Platform Controllers and Framework. Disabling that controller in Windows reproduced the slowdown directly." – MindStudio blog

Why the firmware is encrypted

Nvidia encrypts the power‑table to protect proprietary power‑management algorithms. The Windows driver contains the secret key; the open‑source Linux driver does not. Attempts to extract the key or to patch the driver resulted in kernel panics or only temporary work‑arounds, confirming that a proper fix must come from Nvidia.

Benchmarks illustrate the performance gap

Environment GPU clock (MHz) Tokens / s (GPT‑OSS‑120B)
Windows (native) ~2 200 65.4
WSL 2 (Linux on Windows) ~2 200 65.1
Nvidia DGX Spark (Linux) ~2 200 61
Native Linux on RTX Spark ~780 13.9

A second test with vLLM running eight concurrent clients showed 127 tokens / s on WSL versus 39.5 tokens / s on native Linux. When the laptop is unplugged, Linux clocks rise to ~1 800 MHz and token rates climb to 61‑67 tokens / s, matching Windows. The anomaly—plugged‑in Linux being slower—stems directly from the power controller’s behavior.

Memory split is another Linux obstacle

RTX Spark laptops expose up to 128 GB of unified memory, shared between CPU and GPU. Out of the box, the firmware reserves 96 GB for the GPU, leaving only 32 GB for the OS. Linux cannot modify this split because the firmware UI exists only in Windows. By lowering the GPU reservation to 4 GB from Windows, Linux can see the full 120 GB of RAM after reboot.

"The laptop reserves 96 GB of unified memory for the GPU by default and only Windows exposes a setting to change that split, which is required before Linux can see more than a sliver of RAM." – MindStudio blog

WSL: the pragmatic middle ground

Because WSL runs on top of the Windows driver stack, it inherits the Windows power‑management logic and therefore retains the full GPU boost regardless of power source. After increasing WSL’s memory allocation (default 14 GB) to a larger value, benchmark results are indistinguishable from native Windows.

"WSL runs a Linux environment on top of the Windows kernel and driver stack, so it retains Windows’ GPU clock boost behavior and avoids the throttling issue, while still supporting Linux‑first AI tools like vLLM." – MindStudio blog

For developers who need Linux tooling but cannot accept the 5× slowdown, WSL currently offers the best performance‑to‑convenience ratio.

Community reaction and possible paths forward

  • Nvidia’s closed‑source approach – Several commenters (e.g., @jleask, @laughing_man) lament Nvidia’s habit of keeping critical firmware encrypted, forcing a monopoly on performance.
  • Reverse‑engineering hopes – Users like @viraptor and @bitbasher suggest that the community could eventually reverse‑engineer the power table, but acknowledge that such hacks would be fragile and limited to single machines.
  • Expectation of an upstream fix – The consensus is that a proper solution must come from Nvidia shipping the power‑management logic in its Linux driver, similar to how past features (e.g., Dynamic Boost) were added to Linux after a delay.
  • Alternative hardware – Some commenters (e.g., @demo4567) hint at switching to AMD GPUs, which historically have more open power‑management interfaces.

Practical checklist for RTX Spark owners

  1. Dual‑boot – Use a distro that bundles Nvidia’s open driver (e.g., Omarchy) to get a functional desktop.
  2. Adjust unified memory – Boot into Windows, open the Nvidia Platform Controllers settings, and reduce the GPU memory reservation (e.g., to 4 GB) before booting Linux.
  3. Expect throttling on AC – If you need full performance, run workloads under WSL or keep the laptop on battery.
  4. Monitor GPU clocks – Use nvidia-smi to verify the clock stays near 2 GHz; if it stays ~780 MHz, you are hitting the Linux limitation.
  5. Stay tuned for driver updates – Watch Nvidia’s release notes for any mention of “Platform Controllers” or “Power Table” support on Linux.

Conclusion

Linux can run on Nvidia RTX Spark laptops, but an encrypted, Windows‑only power‑management firmware component caps the GPU at ~780 MHz when the machine is plugged in, slashing AI inference speed by roughly 65 %. Until Nvidia provides an equivalent Linux driver, the only reliable way to retain full performance is to run workloads under WSL or on Windows itself.

Sources

Related