RTX Spark laptops: encrypted power table locks native Linux to a fifth of Windows inference speed

Nvidia’s RTX Spark laptops — the Windows-first notebook take on the GB10 chip — cannot use their rated performance under native Linux. A dual-boot experiment published by MindStudio on November 1 measured an MSI Prestige N16 Flip AI Plus with its GPU pinned near 780 MHz while plugged in: GPT-OSS-120B inference ran at 13.9 tokens per second, against 65.4 tok/s for the same model on the same machine in Windows. The writeup reached the Hacker News front page on November 4, collecting 555 points and 253 comments by late UTC; Nvidia has not responded publicly.

Key points

• MindStudio’s dual-boot numbers for GPT-OSS-120B on one laptop: 65.4 tok/s on Windows, 65.1 under WSL, 13.9 on native Linux while plugged in — and 61 on the DGX Spark desktop, measured as a comparison point.
• The control experiment: disabling Nvidia Platform Controllers and Framework in Windows dropped throughput from about 83 to 31 tok/s and reproduced the exact 786 MHz clock seen on Linux; re-enabling it restored speed instantly.
• The blog’s stated root cause: “the firmware’s power table is encrypted and only the Windows driver can decrypt it.” Per the article, no software-level fix on Linux worked — one attempt triggered a kernel panic.

Background

RTX Spark and DGX Spark share the GB10 chip line but ship on different tracks: the desktop DGX Spark runs DGX OS, a Linux, out of the box, while the laptop form factor is Windows-first. We covered both desktop milestones in October — the 64GB DGX Spark launch at $4,999 with the 128GB model rising to $6,950, and n8n’s tutorial keeping seven local models resident on one DGX Spark. That desktop machine’s Linux inference ran without friction, because the desktop has always been a Linux machine. The lock in this story sits at the firmware-driver boundary on the laptop side — same silicon, different problem from the October launch and pricing news. An earlier laptop install log (an ASUS ProArt P16, posted to Hacker News on October 19 where it gathered 288 points) struggled with the install itself but never hit the power-table wall.

The facts

MindStudio tested an MSI Prestige N16 Flip AI Plus (RTX Spark, 128 GB unified memory), running the same model on the same hardware in four environments:

Environment	GPT-OSS-120B GPU throughput	GPU clock (plugged in)
Windows	65.4 tok/s	~2.2 GHz
WSL	65.1 tok/s	—
Native Linux	13.9 tok/s	~780–790 MHz
DGX Spark desktop	61 tok/s	—

Further data points, all from the MindStudio post:

• The problem follows the power socket: on Linux the laptop did about 61–67 tok/s on battery and dropped to about 15 tok/s plugged in, the opposite of expectations; clocks were roughly 1.8 GHz on battery versus 780 MHz plugged in.
• Concurrency shows the same gap: vLLM with eight clients reached 127 tok/s under WSL versus 39.5 on native Linux.
• A long-running job took about 8 minutes in Windows and 37 minutes in Linux, its clock never leaving roughly 790 MHz; temperatures held at 40–47°C, ruling out thermal throttling.
• The memory reservation is also gated behind Windows: the firmware reserves 96 GB of the 128 GB unified memory for the GPU by default, adjustable only from Windows; lowering it to 4 GB frees 120 GB for Linux. WSL defaults to 14 GB and needs a manual bump for large models.
• The Hacker News submission title says inference “slows to 35%,” but the article’s own numbers work out to about 21% (13.9 vs 65.4) or, on the vLLM benchmark, 31% (39.5 vs 127); no table in the article yields 35%.

What others say

Hacker News commenters split into two camps. The bug camp makes the stronger case so far: kllrnohj called it “all but certainly a bug in their linux driver and nothing else” — regular people are not buying a $4,500 laptop, so anti-abuse throttling makes little sense; jasomill’s observation is the most concrete — Linux runs at full speed on battery and downclocks on wall power, the opposite of Windows, and if the same firmware conditioning also hits Windows while plugged in, “then the nerf is buggy.” The other camp reads intent: rich_sasha asked whether this is “allegedly/hopefully a bug” or a future revenue stream; K0balt worried about “a push towards being 100 percent dependent on the cloud” and urged people to “build and maintain sovereign AI while you still can,” reading the crackdown on game reverse engineering as a rehearsal for “universal computing lockdown”; submitter novaRom dug up Microsoft’s July patent for “DRM-style locking of AI models to verified devices”; iamnothere quoted Nvidia’s stated plans to introduce licensing and subscriptions for server farms; prcrstntr defended Nvidia — the firmware is likely encrypted “to protect IP rather than to block Linux users,” and maintaining open drivers across platforms is expensive; advael shot back that “protecting IP is an excuse given for all manner of computer-aided fuckery,” wrote that “we encrypted the power firmware and only gave microsoft the keys” reads as “colluding to keep people on windows artificially,” and counted the ways Nvidia has resisted Linux compatibility over the years; Matl added the “NVIDIA way or the highway” complaint that open kernel modules merely shim giant binary blobs.

The most practical comments came from barrkel — keep inference on a home box (he suggests a DGX Spark) and reach it from a light laptop over Tailscale — and KeplerBoy, who pointed out that the RTX Spark line also ships in a Mac mini-style box “pretty well suited for home inference.”

Two outside reference points complicate the picture. Nvidia’s own open-gpu-kernel-modules tracker still carries an open GB10 issue — filed September 13, describing a silent whole-host wedge under sustained unified-memory pressure that only a power cycle clears. And Josephine Pfeiffer’s October 19 install log on an ASUS ProArt P16 RTX Spark machine measured vLLM at 30.9 tok/s on Linux, matching Windows at 29.4–31.4, with no power-table problem in sight. Same chip line, two machines, two outcomes. A meta-note: some commenters flagged the article’s AI-flavored prose; the criticism concerns style, while the control experiment stands independent of it.

Our take

For anyone who already bought an RTX Spark laptop, the short answer is WSL: 65.1 against 65.4 is within noise, and it is the only current path that keeps full throughput. The cost is that “native Linux” becomes “Linux inside Windows,” dependent on a Windows license staying around. For anyone still weighing the $4,999–6,950 outlay, the laptop’s selling points currently hold only on the Windows/WSL side; if the reason you would buy one is resident Linux inference, wait for Nvidia to answer first.

Two caveats keep this story honest. First, “the power table is encrypted and only the Windows driver can decrypt it” is the author’s explanation: the replication is hard evidence — disable the controller and the lock reappears, re-enable and it vanishes — but the encryption step itself is unconfirmed by Nvidia. Second, the ASUS data point suggests behavior varies by OEM firmware, so one MSI laptop’s result cannot be projected onto the whole line.

What to watch: an Nvidia response, a Linux driver that gains access to the power table, and reproductions on other OEM units. If the lock holds across machines, the GB10 line splits into a desktop half that runs Linux freely and a laptop half held back by firmware — which pairs with what we argued when the line launched: on this product line, the software maturity is the product.

How to try it

If your machine already runs Linux, check two things. Run nvidia-smi while plugged in: a clock pinned at 780–790 MHz means you are affected. Then rerun a quick benchmark on battery — if the clock jumps to roughly 1.8 GHz and throughput returns to the 60 tok/s range, the fault sits in the power path, not the driver itself. To keep full throughput today you have two options: boot Windows, or use WSL (raise its default 14 GB allocation before loading a large model). A real fix requires Nvidia to port the platform controller’s power management into its Linux driver, as the blog itself concludes. One install note from the same experiment: the first Omarchy attempt failed with a flickering, unstable boot screen; Debian’s installer then needed a USB Ethernet adapter and its kernel did not recognize the keyboard, touchpad or GPU; only a return to Omarchy, whose kernel bundles Nvidia’s open-source driver, made the install stick.