RTX Spark Benchmarks: Windows vs WSL vs Native Linux for Local LLMs
GPT-OSS-120B benchmarks on RTX Spark show Windows and WSL hit 65 tok/s while plugged-in Linux drops to 14, due to a hidden power controller.
Why does native Linux run so much slower than Windows on the RTX Spark?
Because a Windows-only component called the Nvidia Platform Controller manages how power is split between the CPU and GPU on RTX Spark laptops, and Linux has no driver that can talk to it. When that controller is active, the GPU clocks near 2 GHz under load. Without it, the same chip gets stuck around 780 MHz while plugged into power, which is enough to turn a fast local LLM setup into a slow one, even though the hardware hasn’t changed at all.
TL;DR
- GPT-OSS-120B benchmarks on an MSI Prestige RTX Spark laptop show Windows at 65.4 tokens per second, WSL at 65.1, and native Linux at 13.9 when plugged in, roughly a 5x gap on identical hardware.
- A hidden Windows-only device, labeled Nvidia Platform Controllers and Framework in Device Manager, governs the shared CPU/GPU power budget and has no Linux equivalent yet.
- Disabling that controller on Windows reproduced the slowdown directly, dropping throughput from around 83 tokens per second to 32 and clocks from 2 GHz to 786 MHz, matching the exact numbers seen stuck on Linux.
- Linux actually outperforms Windows on battery power, hitting 61 tokens per second unplugged, but flips to the slowest result of all once the charger goes in.
- Memory allocation differs by OS too: the laptop reserves 96GB for the GPU by default and only Windows exposes a setting to change that split, while native Linux just inherits whatever the firmware decided.
- WSL comes out as the practical middle ground today, since it rides on the Windows GPU driver and keeps the clock boost whether the laptop is plugged in or on battery, though it needs manual memory tuning since it defaults to only 14GB.
- The firmware table controlling GPU power states is encrypted, and only Windows knows how to decrypt it, meaning a real fix has to come from Nvidia’s own Linux driver work, not from community tinkering.
What is the RTX Spark and why does the OS matter so much?
The RTX Spark is Nvidia’s small-form-factor AI chip, built on the same design as the Nvidia DGX Spark desktop box, but shipped inside laptops from vendors like MSI, Asus, and Dell. These machines pair the chip with up to 128GB of unified memory and run Windows on ARM, which is itself a relatively new combination now that CUDA support has landed on that platform.
The OS choice matters because the DGX Spark desktop ships with Nvidia’s own Linux build and never has to negotiate shared resources with a consumer OS. The laptop variants ship with Windows, and all the power management, memory partitioning, and driver work that makes the chip perform well was built for Windows first. Running Linux on this hardware means stepping outside of what Nvidia validated and tuned.
How was the Linux installation actually done?
Getting a working Linux desktop on the RTX Spark laptop wasn’t straightforward. The process included remote-controlling the machine over a JetKVM (a network KVM device) so an AI coding assistant could reboot the system and operate the keyboard and mouse from another computer, and at one point even photographing the screen with a webcam because HDMI output didn’t work during the Linux boot process.
The first distro attempt, Omarchy, produced a flickering display because it had been built for the Asus and Dell variants of the chip, not the MSI model being tested. Switching to Debian solved some issues but introduced new ones: the installer couldn’t join Wi-Fi (requiring a USB Ethernet adapter), and out of the box, Debian had no drivers for the keyboard, touchpad, or GPU. Going back to Omarchy, which already included a kernel with Nvidia’s open driver, got most of the hardware working, but Linux only recognized 28GB of the system’s 128GB of memory. The fix required going back into Windows to lower its own GPU memory reservation from 96GB down to 4GB, which then freed up 120GB for Linux. Only after that round trip did a full Linux desktop come up with working GPU acceleration, keyboard, touchpad, audio, and 4K output at 120Hz.
What do the actual benchmark numbers show?
Running GPT-OSS-120B, a large language model commonly used across vendors because it runs reasonably well on a wide range of hardware, the comparison looked like this:
- Windows (native): 65.4 tokens per second
- WSL (Windows Subsystem for Linux): 65.1 tokens per second
- DGX Spark (desktop, native Linux): 61 tokens per second
- RTX Spark laptop, native Linux, plugged in: 13.9 tokens per second
- RTX Spark laptop, native Linux, unplugged (on battery): 61 tokens per second
Remy.
A separate test using vLLM with eight concurrent clients showed a similar pattern: WSL delivered 127 tokens per second while native Linux managed only 39.5. In a longer full test run, Windows held its GPU clock around 2.2 GHz and finished in about 8 minutes, while Linux sat near 790 MHz and took 37 minutes for the same workload. Temperatures stayed low throughout, around 40 to 47°C, ruling out thermal throttling as the cause.
The strangest result is the power-cable behavior. Unplugged, Linux hit 61 to 67 tokens per second with the GPU boosting to around 1,800 MHz under load. Plugged in, the exact same system dropped to 15 tokens per second with the GPU locked near 780 MHz. That’s backwards from what you’d expect: plugging in a laptop should raise its power ceiling, not lower it.
Why does plugging in the charger make Linux slower?
The cause traces back to a device visible only in Windows Device Manager, listed as Nvidia Platform Controllers and Framework. On this laptop, the CPU and GPU share a single power budget, and this controller is what arbitrates how that budget gets split in real time. It has no Linux driver.
The clearest proof came from disabling that controller directly in Windows. With it enabled, throughput measured around 83 tokens per second and GPU clocks sat near 2 GHz. Disabling it dropped throughput to about 32 tokens per second and clocks to 786 MHz, almost exactly the numbers Linux produces while plugged in. Re-enabling the controller brought performance back up to roughly 78 tokens per second. That match is strong evidence that the missing controller, not a kernel bug or a misconfigured driver, is the root cause.
Digging further, the firmware hands this controller an encrypted table of power states. Windows has the means to decrypt and read that table; Linux currently does not. Attempts to extract or bypass this (including trying to see whether the decryption key could be pulled from the Windows driver) didn’t produce a usable fix and at one point caused a kernel panic. A real solution would need Nvidia to ship controller support in its Linux driver stack, not a one-off workaround for a single machine.
Is WSL a good substitute for native Linux on RTX Spark right now?
For most developers who want Linux-style tooling on this hardware today, WSL is the more practical choice. Because WSL runs on top of the Windows GPU driver, it inherits the same power management and clock boosting Windows gets, whether the laptop is plugged in or running on battery. The benchmarks back this up: WSL’s 65.1 tokens per second on GPT-OSS-120B is nearly identical to native Windows, and its vLLM throughput of 127 tokens per second with eight clients was more than three times what native Linux achieved plugged in.
It isn’t friction-free. WSL defaults to allocating only 14GB of memory, which isn’t enough for large local models, so getting a usable configuration requires manually adjusting that limit upward. Linux-first tools like vLLM and SGLang do run inside WSL, which matters since a lot of AI tooling targets Linux before Windows.
Native Linux also has an unresolved memory quirk of its own: the laptop reserves 96GB of its unified memory for the GPU by default, and only Windows currently exposes a setting to change that split. Boot into Linux and you get whatever the firmware decided ahead of time, with no user-facing control.
Frequently Asked Questions
What causes the slowdown on native Linux specifically when plugged in?
A Windows-only component called the Nvidia Platform Controller manages the shared CPU/GPU power budget on these laptops. Linux has no driver for it, so the GPU defaults to a much lower clock speed (around 780 MHz instead of roughly 2 GHz) whenever the laptop is connected to power.
Does this affect the RTX Spark on battery power too?
No. Unplugged, native Linux actually performed comparably to Windows and WSL, reaching around 61 to 67 tokens per second on GPT-OSS-120B. The slowdown only appears when the charger is connected, which is the opposite of typical laptop power behavior.
Is WSL as fast as native Windows for local LLM inference?
Very close. In testing, GPT-OSS-120B ran at 65.4 tokens per second on native Windows versus 65.1 on WSL, essentially a tie. WSL does require manually raising its default memory allocation, which starts at 14GB, to handle large models.
Can this throttling issue be fixed by the community, or does it require Nvidia?
It requires Nvidia. The firmware’s power state table is encrypted, and only the Windows driver stack can decrypt it. Attempts to extract or bypass the key on the Linux side didn’t produce a working, general fix.
Should someone buy an RTX Spark laptop specifically to run Linux?
Based on current testing, no. Native Linux performance while plugged in is roughly a sixth to a half of Windows speed depending on the workload, and the setup process itself required workarounds for missing drivers, display output issues, and memory allocation. WSL is the more reliable path for Linux-style tooling on this hardware today.
