RTX Spark on Linux: why plugged-in inference runs at a fifth of Windows speed, and what to do

Nvidia's first Arm laptops, the RTX Spark (N1X) machines, run local models at roughly Windows speed under Windows and WSL, and at about a fifth of that under native Linux as soon as you plug in the charger. In MindStudio's tests on an MSI Prestige N16 Flip AI Plus, GPT-OSS-120B produced 65.4 tokens per second on Windows and 13.9 on native Linux on AC power, with the GPU held near 780 MHz. The suspected cause is an encrypted firmware power table that only Nvidia's Windows driver can read.

If you bought, or are about to buy, one of these 128 GB unified-memory laptops to run models on Linux, this article explains what the firmware is doing, how to check whether your machine is affected in a minute with nvidia-smi, how to measure it on your own workload, and the workarounds that exist today, with what each one costs you.

What is the RTX Spark, and why do people run Linux on it?

RTX Spark is Nvidia's N1X system-on-chip: a Grace Arm CPU with 18 or 20 cores and a Blackwell GPU with 5,120 or 6,144 CUDA cores, sharing up to 128 GB of unified memory in the top configuration (Tom's Hardware). It launched in Windows-on-Arm laptops from MSI, Asus, Dell, Lenovo and others this autumn.

The draw for engineers is the memory. A laptop GPU that can address over 100 GB can load a 120B-parameter open-weight model that would otherwise need a workstation, and most of the serving stack people use for that (vLLM, SGLang, CUDA containers) is Linux-first. That is why owners started installing Arch, Omarchy and Debian within weeks of launch, and why Josie's write-up of an ASUS ProArt P16 on Arch Linux ARM and an open hardware-enablement repo already exist.

Why inference is slow on Linux when the laptop is plugged in

Under native Linux on AC power, the GPU does not boost. MindStudio measured about 1,800 MHz under load on battery and about 780 MHz when plugged in, against roughly 2 GHz or more on Windows (MindStudio). Temperatures stayed at 40–47 °C, so this is not thermal throttling: the GPU is being told to run slowly.

The power budget on these laptops is shared between CPU and GPU and managed by a Windows component called the Nvidia Platform Controllers and Framework. MindStudio reports that its power table is encrypted and only the Windows driver can decrypt it. Without that component, Linux falls back to conservative clocks on wall power. The strongest evidence is a control test on Windows: disabling the controller there dropped throughput from about 83 to about 31 tokens per second and clocks to about 786 MHz, and re-enabling it restored full speed.

Whether this is deliberate or simply unfinished is not known. Nvidia has not commented. One fair point raised on Hacker News is that a deliberate restriction would be expected to hit Windows too, and battery-powered Linux already runs at nearly full speed. Until Nvidia says something, treat it as a missing piece of Linux platform support rather than proof of intent.

How big is the slowdown? The measured numbers

Big enough to change which machine you would use. The "35%" in the headlines matches the clock ratio (about 780 MHz against about 2.2 GHz); the throughput gap MindStudio measured on GPT-OSS-120B was larger, closer to one fifth (MindStudio).

How to check whether your RTX Spark is clock-limited on Linux

Watch the graphics clock and the clock event reasons while a model is generating, once on battery and once on AC. nvidia-smi can poll both; the query fields are documented by Nvidia.

# AC adapter state (1 = plugged in); the supply name varies by laptopcat /sys/class/power_supply/*/online # Current and maximum SM clock, power draw and temperaturenvidia-smi --query-gpu=clocks.sm,clocks.max.sm,power.draw,temperature.gpu \  --format=csv -l 1 # Why the clock is where it is ("Clocks Event Reasons"; older drivers say "Clocks Throttle Reasons")nvidia-smi -q -d PERFORMANCE

If the SM clock sits well under its maximum on AC, the temperature is low, and the same run on battery climbs much higher, you are seeing this problem. Do not be surprised by [N/A] in the power column: the ASUS enablement project notes that some NVML power and memory metrics may be unavailable on N1X (johannhartmann/asus-proart-p16-rtx-spark-linux).

Clocks tell you the cause; tokens per second tell you the cost. This script times one completion against any OpenAI-compatible server, which both vLLM and LM Studio expose, using only the Python standard library:

import json, sys, time, urllib.request BASE = sys.argv[1] if len(sys.argv) > 1 else "http://localhost:8000/v1"MODEL = sys.argv[2] if len(sys.argv) > 2 else "openai/gpt-oss-120b" body = json.dumps({    "model": MODEL,    "prompt": "Explain how a B-tree index works, in detail.",    "max_tokens": 512,    "temperature": 0,}).encode()req = urllib.request.Request(BASE + "/completions", body,                             {"Content-Type": "application/json"}) start = time.perf_counter()with urllib.request.urlopen(req, timeout=600) as r:    out = json.load(r)elapsed = time.perf_counter() - start tokens = out["usage"]["completion_tokens"]print(f"{tokens} tokens in {elapsed:.1f}s = {tokens / elapsed:.1f} tok/s")

Run it twice, unplugged and plugged in, with python3 tps.py http://localhost:8000/v1 <model>; vLLM serves on port 8000 by default (vLLM docs), LM Studio on 1234. The figure includes prompt processing, so it reads a little below the pure decode rate, but the AC-versus-battery ratio is what you are after.

Fix the memory split first: Linux may only see 28 GB

Before speed, check how much memory Linux can use. MindStudio reports that the firmware reserves 96 GB for the GPU by default, only Windows can change that setting, and native Linux initially saw just 28 GB. Lowering the reservation to 4 GB in Windows let Linux see about 120 GB as one pool (MindStudio). Josie's ProArt reported 116 GiB visible to both the system and CUDA from a single pool, so expect a figure in that range once it is set.

Practically, keep a Windows install, or at least boot into it once, before you wipe the disk. If you cannot change the reservation, a 120B model will not load at all, which matters more than running it slowly.

Workarounds today: WSL, battery, and community tooling

WSL is the practical answer for now. It uses the Windows driver stack, so the power controller is present and the GPU boosts normally: 65.1 tokens per second single-stream and 127 with eight vLLM clients in MindStudio's runs. The catch is memory. MindStudio found WSL reserved 14 GB by default; raise it in %UserProfile%\.wslconfig, using the keys Microsoft documents:

[wsl2]memory=100GBswap=0

Run wsl --shutdown afterwards so the setting takes effect. Choose the figure from what the firmware leaves you after the GPU reservation, not from the 128 GB on the box.

Native Linux on battery gets close to Windows speed (about 61–67 tokens per second in LM Studio), which is fine for an interactive session but drains the battery and is no way to run a server. Nothing documented so far lets Linux keep battery-level clocks on AC.

Community tooling is moving but does not fix the GPU yet. Omarchy merged NVIDIA's own power-profiles-daemon driver for RTX Spark in October, and the pull request says Nvidia asked Omarchy to carry it until it lands upstream. It tunes CPU energy-performance preference and the scheduler governor per profile; it does not touch the encrypted GPU power table. A commenter on Hacker News suggested LACT for clock and power limits, but nobody has yet reported that it lifts the AC floor on these laptops. Firmware workarounds have also gone badly: MindStudio reports one attempt caused a kernel panic.

Should you buy an RTX Spark laptop for Linux inference?

Only if you are happy to run your models in WSL, or to wait. The hardware is fine; native Linux support for its power management is incomplete. For a dedicated inference box, Nvidia's desktop DGX Spark posted 61 tokens per second on the same model in the same report (MindStudio), and it is sold for Linux. For a laptop that also runs your editor and your meetings, WSL gets you nearly all of the speed today.

If you already own one and live in native Linux, do your heavy runs in WSL or on a remote box, keep a copy of Windows for the memory setting and for firmware updates, and re-test with the script above after every Nvidia driver release. A fix needs Nvidia to ship the platform-controller logic for Linux, and when it arrives it will show up as a clock that climbs on AC.

The one thing to remember: on RTX Spark laptops the GPU's speed under Linux is set by a Windows-only power controller, not by the GPU driver you install, so measure on AC before you plan a workload around it.

Sources and further reading

• MindStudio: Linux on the Nvidia RTX Spark Laptop: What Actually Works, the original measurements
• Tom's Hardware: RTX Spark N1X configurations
• Josie: putting Linux on my RTX Spark laptop, ASUS ProArt P16 on Arch Linux ARM
• johannhartmann/asus-proart-p16-rtx-spark-linux, hardware enablement for the ProArt P16
• omarchy-pkgs #1047: NVIDIA's RTX Spark power-profiles driver
• Hacker News discussion
• nvidia-smi documentation, WSL configuration (.wslconfig), vLLM OpenAI-compatible server