Linux GPU throttling on RTX Spark laptops limits local LLM speed

Developers attempting to run native Linux on new Nvidia RTX Spark laptops face a critical performance bottleneck that drastically reduces AI inference speeds. A recent technical review of the MSI Prestige N16 Flip AI Plus reveals that while the operating system installs correctly, GPU clock speeds collapse when the device is connected to wall power. This hardware-specific limitation currently makes Windows Subsystem for Linux (WSL) the only viable option for high-performance local model training and inference on these machines.

What happened

The RTX Spark platform, found in devices like the MSI Prestige, Asus ProArt, and Dell XPS, uses a unified memory architecture designed for heavy AI workloads. These laptops ship with Windows on ARM and support up to 128GB of RAM shared between the CPU and GPU. Because many AI engineering tools are built for Linux first, developers naturally attempt to dual-boot or replace Windows with a native Linux distribution. However, this transition triggers a severe performance regression tied to power management firmware.

When running native Linux, the GPU clock speed drops to approximately 780 MHz once the laptop is plugged into an external power source. In contrast, the same hardware running Windows or WSL maintains clock speeds above 2 GHz under load. This discrepancy is not thermal; temperatures remain low between 40 and 47°C. Instead, the GPU is artificially capped by firmware logic that the Linux driver cannot currently access or override. The result is a five-fold decrease in token generation speed for large language models.

Installing Linux on these devices also requires significant manual configuration. Standard distributions like Debian often fail to recognize essential hardware components such as Wi-Fi, keyboards, or touchpads without specific kernel patches. Successful setups typically rely on distributions like Omarchy, which include Nvidia’s open-source kernel drivers. Even after achieving a stable desktop environment with 4K output at 120Hz, users must adjust memory allocation settings in Windows before booting Linux to ensure the OS can access more than a fraction of the available RAM.

How it works

The root cause of the throttling is a Windows-only firmware component called the Nvidia Platform Controllers and Framework. In a laptop form factor, this controller manages the shared power budget between the CPU and GPU, ensuring neither component exceeds the total power delivery limits of the chassis. Unlike the desktop DGX Spark unit, which has dedicated power lines, the laptop must dynamically balance energy usage. The firmware provides an encrypted table of power settings that the Windows driver can decrypt and apply, allowing the GPU to boost to its maximum frequency.

Linux lacks an equivalent driver capable of decrypting this power table. Without access to these settings, the Linux kernel defaults to a safe, low-power state when the device is plugged in, locking the GPU clock at roughly 780 MHz. Interestingly, this behavior reverses when the laptop runs on battery power, where Linux performance closely matches Windows because the power constraints are handled differently. Attempts to bypass this limitation through software workarounds have failed, with some causing kernel panics, indicating that the encryption key is strictly tied to the Windows driver stack.

Key details

• Native Linux on the MSI Prestige RTX Spark achieves only 13.9 tokens per second on GPT-OSS-120B, compared to 65.4 tokens per second on Windows.
• The GPU clock speed is locked at approximately 780 MHz on Linux when plugged in, versus 2.2 GHz on Windows.
• WSL performs nearly identically to native Windows, hitting 65.1 tokens per second, because it utilizes the Windows driver stack.
• Users must lower the GPU memory reservation in Windows from 96GB to 4GB before installing Linux to allow the OS to see 120GB of RAM.
• The throttling issue is caused by an encrypted power management table accessible only to the Windows Nvidia Platform Controllers driver.
• Disabling the platform controller in Windows reproduces the Linux slowdown, confirming the component is responsible for the performance gap.

Why it matters

For AI engineers and ML practitioners, this finding fundamentally changes the hardware recommendation for portable development stations. The promise of a Linux-native laptop that rivals the desktop DGX Spark performance is currently unfulfilled due to this firmware lock. Developers who purchase these high-end machines expecting to run local LLMs, fine-tune models, or use tools like vLLM in a native Linux environment will encounter a severe bottleneck. The performance drop from 65 to 14 tokens per second makes real-time interaction with large models impractical on native Linux.

This situation highlights the growing complexity of supporting AI hardware across different operating systems. As Nvidia pushes into the ARM-based Windows market with CUDA support, the Linux ecosystem lags in driver maturity for these specific hybrid architectures. Until Nvidia ports the platform controller logic to its Linux driver, developers are forced to choose between the convenience of Linux tools and the raw performance of Windows. This fragmentation adds friction to workflows that ideally should be platform-agnostic.

What you can do

• Use Windows Subsystem for Linux (WSL) for all heavy AI workloads to retain full GPU boost speeds while accessing Linux-compatible tools.
• Increase the WSL memory allocation manually, as the default 14GB limit is insufficient for large models on 128GB unified memory machines.
• If you must use native Linux, perform all intensive inference tasks while running on battery power, where clock throttling does not occur.
• Adjust the GPU memory reservation in Windows settings to 4GB before installing Linux to ensure the operating system can access the majority of system RAM.
• Avoid relying on standard Debian or Ubuntu installers without verifying they include the necessary Nvidia open-source kernel drivers for the RTX Spark chip.
• Monitor Nvidia driver release notes for updates regarding the Platform Controllers and Framework support on Linux, as this is the only path to a permanent fix.