Quick Answer: Yes, Linux runs on Nvidia RTX Spark laptops like the MSI Prestige N16 Flip AI Plus, with GPU acceleration. But when the laptop is plugged into wall power, the GPU clock drops to about 780 MHz, compared with roughly 2.2 GHz on Windows. The cause is a Windows-only power controller whose encrypted power table Linux can't read. WSL is the practical workaround today.
If you bought an RTX Spark laptop to run local models on Linux, you may have noticed something wrong the first time you ran a benchmark. The same model that produces 65 tokens per second on Windows crawls at 13.9 on native Linux. MindStudio's hands-on write-up documents exactly why, and the answer is more specific than "the drivers aren't ready."
What makes the RTX Spark laptop different
The RTX Spark platform ships in laptops like the MSI Prestige, the Asus ProArt, and the Dell XPS. It uses the same GPU design as Nvidia's DGX Spark desktop. The difference is the operating system. The DGX Spark ships with Nvidia's own Linux build. These laptops ship with Windows on ARM.
That matters because pairing ARM Windows with CUDA is new. ARM-based Windows machines have existed for a few years, but this chip is the first to combine that architecture with the CUDA stack. The laptops also offer unified memory up to 128GB shared between CPU and GPU, which is rare in a laptop and is the main reason they're marketed at AI developers.
Most of the local AI tooling you'd want, including vLLM and SGLang, is built Linux-first. So the buyer's question is natural: can you drop Windows, or at least dual-boot, without losing performance? The short answer is that you can install Linux. You just can't keep the performance yet.
Getting Linux installed is not plug-and-play
Installation is the first hurdle, and it's where many people will give up. The source's experience shows why.
The first attempt used Omarchy, an Arch-based distribution. It supports the chip on Asus and Dell hardware, but on the MSI Prestige it produced a flickering, unstable display during boot. Debian booted more reliably, but needed a lot of help:
- The Debian installer couldn't connect to Wi-Fi, so a USB Ethernet adapter was required.
- A vanilla kernel didn't recognize the keyboard, touchpad, or GPU, because laptop-specific support wasn't in it.
- Early on, the laptop only output video to its internal screen, not HDMI. The tester pointed an external camera at the display just to see what was happening during remote installation.
Going back to Omarchy solved the driver problem, since its kernel already bundled Nvidia's open-source kernel driver. Then came the memory problem. Linux could see only 28GB of the 128GB unified memory. The firmware reserves 96GB for the GPU by default, and that split can only be changed from Windows. Lowering the Windows-side GPU reservation to 4GB freed about 120GB for Linux.
Here's the sequence that worked in the tested setup:
- Install a distribution whose kernel includes Nvidia's open kernel driver, such as Omarchy.
- Get networking and video output working before you go further. Keep a USB Ethernet adapter on hand.
- Boot into Windows and lower the GPU memory reservation to 4GB.
- Return to Linux and confirm it sees the full memory pool.
After that, the laptop ran a full desktop at 4K and 120Hz, with working audio, touchpad, keyboard, and CUDA acceleration. The catch is that the GPU still wasn't running at full speed.
The benchmark gap
Here's the GPT-OSS-120B result that matters most:
| Setup | GPT-OSS-120B tokens/sec | GPU clock behavior |
|---|---|---|
| Windows (native, RTX Spark laptop) | 65.4 | About 2.2 GHz under load |
| WSL on the RTX Spark laptop | 65.1 | Full boost via Windows driver stack |
| Nvidia DGX Spark desktop (native Linux) | 61 | Not reported in source |
| Native Linux on RTX Spark laptop, plugged in | 13.9 | Parked around 780 MHz |
The gap also shows up under concurrency. With vLLM running eight concurrent clients, WSL reached 127 tokens per second and native Linux reached 39.5. A longer run told the same story in time: Windows finished in about 8 minutes while holding the GPU near 2.2 GHz, and Linux took 37 minutes with the GPU stuck near 790 MHz.
Temperatures stayed between 40 and 47°C during the Linux runs. So this isn't thermal throttling. The GPU is being told to run slow.
Why plugging in makes Linux slower
Most people expect a laptop to run faster plugged in, not slower. Here the direction flips. Unplugged, Linux hit roughly 61 to 67 tokens per second on LM Studio, comparable to Windows. Plugged in, the same test dropped to about 15 tokens per second, and clock speed fell from around 1,800 MHz under load to roughly 780 MHz.
The cause is a Windows component called the Nvidia Platform Controllers and Framework. It's visible in Windows Device Manager, and it manages the shared power budget between CPU and GPU. A desktop DGX Spark can feed its GPU on a dedicated power line. A laptop has to split power between both chips, and this controller does that split.
The tester proved the point on Windows. Disabling the controller cut throughput from about 83 tokens per second to about 31, and clock speed fell to the same 786 MHz seen on Linux when plugged in. Re-enabling it restored normal speed immediately. The controller, not the kernel, the distribution, or the Nvidia GPU driver, is the bottleneck.
Here's the deeper problem. The firmware gives this controller a power table, and that table is encrypted. Windows has the key. Linux doesn't. The source says no software fix tried during testing could enable it, and one attempt triggered a kernel panic. Extracting the key from the Windows driver was floated as a workaround, but that's a fragile, single-machine hack, not a fix you should rely on.
Most guides stop at "install the driver and you're done." That advice is wrong for this hardware. The driver is working. It's the power management data that's locked.
WSL vs native Linux: which should you use?
For most developers right now, WSL is the better choice. The trade-off is clear once you see what each one gives you.
Use WSL when:
- You need full GPU boost on battery or plugged in. WSL runs on the Windows driver stack, so it keeps Windows' boost behavior.
- You want Linux-first tools like vLLM and SGLang without the throttling issue.
- You're running sustained workloads and need predictable throughput.
Use native Linux when:
- You're on battery and want the full Linux environment. The source reports that unplugged Linux performance is much closer to Windows.
- You need kernel-level control or a native desktop for other work.
- You accept lower throughput while plugged in until Nvidia fixes the driver.
WSL has one adjustment you have to make. It reserves only 14GB by default, which isn't enough for large models on a 128GB unified memory machine. You'll need to raise that allocation manually. Once you do, the source reports WSL benchmarks landing close to native Windows.
That said, WSL isn't identical to native Linux. It runs a Linux environment on top of the Windows kernel and driver stack. If your workflow depends on a true bare-metal Linux kernel, you'll be giving something up.
What to expect from Nvidia
A real fix depends on Nvidia. The source's conclusion is that Nvidia would need to port the Platform Controllers and Framework's power management logic into its Linux driver. Doing that would effectively turn the laptop into a portable version of the DGX Spark.
Nvidia hasn't committed to that, and the source doesn't say it will. Until it does, treat native Linux on plugged-in RTX Spark laptops as a degraded configuration for sustained GPU work. Don't expect a driver update to close the gap on its own. The fix sits in firmware and driver logic that Linux can't currently see.
Before you commit to this setup, check your power source. If you rely on Linux for sustained inference, test with the laptop plugged in and compare clock speed against the numbers above. If your clocks sit near 780 MHz, you're in the same situation the source documented.
Frequently Asked Questions
Can the Nvidia RTX Spark laptop dual-boot Windows and Linux?
Yes. Dual-booting was demonstrated on the MSI Prestige RTX Spark laptop using Omarchy, which already included Nvidia's open kernel driver for this chip. An earlier attempt with Debian needed manual driver and networking workarounds.
Why is Linux so much slower than Windows on this laptop when plugged in?
A Windows-only component, the Nvidia Platform Controllers and Framework, manages power sharing between CPU and GPU. Its power table is encrypted, and only the Windows driver can decrypt it. Without that, Linux GPU clocks stay near 780 MHz when plugged in, compared with about 2.2 GHz on Windows.
What is the Nvidia Platform Controllers and Framework?
It's a firmware and driver component that splits the laptop's power budget between the CPU and GPU. It appears in Windows Device Manager. It's the root cause of the Linux slowdown, because Linux has no equivalent that can read the encrypted power table.
How do I fix Linux performance on an RTX Spark laptop?
You can't fully fix it yet. The practical option is WSL, which keeps Windows' GPU boost behavior. Raise its memory allocation above the 14GB default. A complete native fix requires Nvidia to add the controller's power management logic to its Linux driver.
Does unplugging the laptop fix the Linux performance problem?
It helps a lot. On battery, the source reports Linux GPU clocks and token throughput come much closer to Windows levels. The severe slowdown appears when the laptop is plugged into wall power.
Most people who buy an RTX Spark laptop for local AI want Linux, and most of them will hit this wall. The most useful takeaway is this: if your workload runs on Linux and your laptop stays plugged in, use WSL for sustained inference until Nvidia ships a Linux power management fix. Try running your own benchmark plugged in and check the GPU clock against the 780 MHz figure, then share the result with anyone else weighing this laptop for Linux-first AI work.