Encrypted Nvidia firmware caps RTX Spark laptop GPUs at 780 MHz on Linux, cutting inference to a fifth

Linux works, until you plug it in

A hands-on report from MindStudio, which surfaced on Hacker News's front page, finds that Linux installs and runs on Nvidia's new RTX Spark laptops — the testing used an MSI Prestige N16 Flip AI Plus — with GPU acceleration via Nvidia's open kernel driver, a 4K desktop at 120Hz, and working audio, keyboard, and touchpad once configured. The serious catch appears when the power adapter is connected: the GPU gets locked to roughly 780 MHz instead of the 2.2 GHz it reaches on Windows.

The laptops in question, including the MSI Prestige, Asus ProArt, and Dell XPS variants, use the same GPU design as Nvidia's DGX Spark desktop and ship with Windows on ARM, with unified memory configurations up to 128GB. Because much of the AI tooling ecosystem, including vLLM and SGLang, is built Linux-first, buyers want to know whether they can run Linux natively without losing performance.

What the benchmarks show

According to the report, running GPT-OSS-120B produced 65.4 tokens per second on Windows and 65.1 under WSL, while the DGX Spark desktop — running Nvidia's own Linux build — reached 61. Native Linux on the same laptop managed only 13.9, roughly five times slower.

The gap repeated elsewhere: with vLLM serving eight concurrent clients, WSL hit 127 tokens per second against 39.5 for native Linux. A longer run that Windows finished in about eight minutes near 2.2 GHz took Linux 37 minutes with the GPU parked around 790 MHz throughout. Temperatures stayed between 40 and 47°C, ruling out thermal throttling — the GPU simply is not permitted to boost.

Strangely, the problem inverts with the power source. Unplugged, Linux reached 61 to 67 tokens per second in LM Studio with clocks around 1,800 MHz; connected to wall power, the same test fell to about 15 tokens per second and roughly 780 MHz.

An encrypted power table is the root cause

The report traces the behaviour to a Windows-only component called the Nvidia Platform Controllers and Framework, which manages the shared power budget between CPU and GPU — something a laptop must balance, unlike the desktop DGX Spark. Disabling that controller in Windows reproduced the Linux slowdown almost exactly: tokens per second fell from around 83 to about 31, and clocks dropped from roughly 2 GHz to 786 MHz. Re-enabling it restored full speed immediately, confirming the controller rather than the kernel, distribution, or GPU driver is responsible.

The deeper issue is that the firmware hands the controller a table of power settings that is encrypted. The Windows driver can decrypt it; Linux currently cannot, and no software workaround succeeded during testing — one attempt triggered a kernel panic. Extracting the key from the Windows driver was floated only as a fragile, single-machine hack. A real fix, the report concludes, requires Nvidia to port the platform controller's power-management logic into its Linux driver.

Installation and memory quirks

Getting Linux onto the machine was not plug-and-play. An Arch-based distribution called Omarchy initially produced a flickering, unstable display on the MSI unit, and Debian required a USB Ethernet adapter because the installer lacked Wi-Fi support, while a vanilla kernel recognised neither keyboard, touchpad, nor GPU. Returning to Omarchy, whose kernel bundled Nvidia's open driver, solved that.

A separate headache was memory: the firmware reserves 96GB of the 128GB unified memory for the GPU by default, and only Windows exposes a setting to change that split. Linux initially saw just 28GB; lowering the Windows-side reservation to 4GB freed 120GB.

WSL as the practical workaround

For now, WSL is the sensible middle ground: it rides on the Windows driver stack and keeps full GPU boost on AC or battery while still running Linux-first tools like vLLM and SGLang. Its default 14GB memory reservation needs raising for large model workloads on a 128GB machine.

Why it matters

This is a quantified hardware limitation for anyone running local AI on Nvidia's newest ARM-based laptops. An open GPU driver is not enough when critical platform firmware is encrypted and readable only by Windows — so a machine marketed at AI developers cannot reach a fifth of its Windows inference speed on native Linux until Nvidia ships a proper fix. Until then, teams relying on Linux-first tooling should plan around WSL rather than a bare-metal install.