# Nvidia RTX Spark Linux Firmware Throttling Limits AI Inference Performance Encrypted power management firmware restricts GPU clock speeds on Linux, severely impacting AI model inference. - **Source:** [Hacker News](https://news.ycombinator.com) - **Published:** 2026-11-04 - **Topic:** [Software & Engineering](https://brifing.si/c/engineering) - **Original article:** - **On Brifing:** https://brifing.si/s/36decbd2-b64f-49e7-8531-593772be294a ## Performance Bottleneck on Linux Nvidia RTX Spark laptops face a severe performance drop when running native Linux. While Windows achieves 65 tokens per second on 120B parameter models, native Linux performance plummets to 14 tokens per second. This discrepancy occurs because the GPU clock speed is locked at 780 MHz instead of the expected 2 GHz. ## The Power Management Mechanism The issue stems from the Nvidia Platform Controllers and Framework, a firmware component that balances power between the CPU and GPU. This controller relies on an encrypted power settings table. Windows possesses the decryption key to manage these power states, whereas Linux currently lacks the necessary access to unlock full GPU performance. ## Counterintuitive Battery Behavior Interestingly, the performance throttling is most severe when the laptop is plugged into wall power. On battery power, the system behaves differently, allowing the GPU to reach 1,800 MHz and achieving token throughput comparable to Windows. This inverted behavior confirms that the firmware logic is specifically mismanaging power delivery during AC operation. ## WSL as a Practical Workaround Developers currently find that WSL is the most viable solution for running Linux-first AI tools like vLLM or SGLang. Because WSL operates on top of the Windows driver stack, it inherits the correct power management behavior. Users only need to manually increase the default 14GB memory reservation to support large model workloads. ## Hardware Installation Challenges Installing native Linux on RTX Spark hardware is not a plug-and-play experience. Early attempts with Debian required external USB Ethernet adapters for connectivity and manual configuration for keyboard and touchpad support. Distributions like Omarchy offer better driver bundling, but users must still manually adjust Windows-side GPU memory reservations to reclaim usable system RAM. ## Firmware Encryption Barriers The core problem is the inability of the Linux kernel to decrypt the power management table provided by the firmware. While extracting keys from Windows drivers is theoretically possible, it remains a fragile, single-machine hack. A sustainable solution requires Nvidia to officially port the platform controller logic into their open-source Linux driver stack. ## Memory Allocation Constraints The RTX Spark platform supports up to 128GB of unified memory, but Linux visibility is restricted by Windows-side reservations. By default, the firmware reserves 96GB for the GPU. Users must reduce this to 4GB within Windows to allow Linux to access the full 120GB of memory, which is essential for large-scale AI model inference. ## Future Outlook for Developers Until Nvidia updates its Linux drivers to include the necessary power management logic, native Linux remains suboptimal for RTX Spark hardware. Developers should prioritize WSL for production-like AI workflows to avoid the 35% performance penalty. Future firmware updates or driver releases are the only path to restoring native performance parity on these machines. ## Sources covering this story - https://www.mindstudio.ai/blog/linux-nvidia-rtx-spark-laptop — --- _Summary written by Brifing from the original reporting. Copyright in the original article belongs to its publisher; read the full piece at the link above._