Nvidia RTX Spark encrypted firmware slows inference speed to 35% on Linux

本文为原文前 6,000 字符的节选翻译，完整内容请查看原文。

Yes, but it comes with a serious catch. Linux installs and runs on RTX Spark laptops like the MSI Prestige N16 Flip AI Plus, including GPU acceleration through Nvidia’s open kernel driver. The problem is clock speed: once the laptop is plugged into wall power, the GPU gets locked to roughly 780 MHz on Linux instead of the 2 GHz-plus it hits on Windows. That turns a chip capable of around 65 tokens per second on a 120 billion parameter model into one struggling to break 14 tokens per second, for reasons tied to power management firmware that Linux currently can’t read.

然而，这伴随着一个严重的隐患。Linux 可以安装并在 MSI Prestige N16 Flip AI Plus 等 RTX Spark 笔记本电脑上运行，包括通过 Nvidia 的开源内核驱动程序实现 GPU 加速。问题在于时钟频率：一旦笔记本电脑接通电源，Linux 下的 GPU 频率会被锁定在约 780 MHz，而 Windows 下则能达到 2 GHz 以上。这使得原本在 1200 亿参数模型上每秒能处理约 65 个 token 的芯片，在 Linux 下难以突破每秒 14 个 token，原因在于 Linux 目前无法读取电源管理固件。

The RTX Spark platform, which ships in machines like the MSI Prestige, the Asus ProArt, and the Dell XPS, uses the same GPU design as Nvidia’s DGX Spark desktop unit. But where the DGX Spark ships with Nvidia’s own Linux build out of the box, every one of these laptop variants ships with Windows on ARM.

RTX Spark 平台搭载于 MSI Prestige、Asus ProArt 和 Dell XPS 等设备中，其 GPU 设计与 Nvidia 的 DGX Spark 台式机单元相同。但与出厂即预装 Nvidia 自家 Linux 系统的 DGX Spark 不同，所有这些笔记本电脑变体均预装 Windows on ARM 系统。

That distinction matters because Windows on ARM with CUDA support is new. ARM-based Windows machines have existed for a few years, but pairing that architecture with Nvidia’s CUDA stack only became possible with this chip. The laptops also support unified memory configurations up to 128GB, shared between CPU and GPU, which is unusual for a laptop and central to why they’re being marketed at AI developers in the first place.

这一区别至关重要，因为支持 CUDA 的 Windows on ARM 是一个新事物。基于 ARM 的 Windows 机器已经存在几年了，但将该架构与 Nvidia 的 CUDA 堆栈结合使用，直到这款芯片出现才成为可能。这些笔记本电脑还支持高达 128GB 的统一内存配置，由 CPU 和 GPU 共享，这在笔记本电脑中并不常见，也是它们最初被推向 AI 开发者的核心原因。

Because so much of the AI tooling ecosystem, including vLLM and SGLang, is built Linux-first, developers who buy these machines naturally want to know whether they can ditch Windows, or at least dual-boot, without losing performance.

由于包括 vLLM 和 SGLang 在内的大量 AI 工具生态系统都是以 Linux 为优先构建的，购买这些机器的开发者自然想知道，他们是否可以在不损失性能的情况下放弃 Windows，或者至少进行双系统启动。

The process is not plug-and-play. A first attempt using Omarchy (a Linux distribution with Arch roots) failed because, while it already supported the chip on Asus and Dell hardware, the MSI Prestige behaved differently, producing a flickering, unstable display during boot.

这个过程并非即插即用。首次尝试使用 Omarchy（一个基于 Arch 的 Linux 发行版）失败了，因为虽然它已经在 Asus 和 Dell 硬件上支持该芯片，但 MSI Prestige 的表现不同，在启动过程中出现了闪烁且不稳定的显示画面。

Switching to Debian worked more reliably, but still needed workarounds. The installer couldn’t connect to Wi-Fi, so installation required a USB Ethernet adapter. Out of the box, Debian also didn’t recognize the keyboard, touchpad, or GPU, because none of the laptop-specific hardware support was present in a vanilla kernel.

改用 Debian 后运行更可靠，但仍需要变通方法。安装程序无法连接 Wi-Fi，因此安装需要 USB 以太网适配器。开箱即用的 Debian 也没有识别出键盘、触摸板或 GPU，因为原生内核中不存在任何针对该笔记本电脑的硬件支持。

Going back to Omarchy solved the driver problem, since its kernel already bundled Nvidia’s open-source driver. At that point Linux booted properly, but could only see 28GB of the laptop’s 128GB of unified memory. That’s because the laptop’s firmware reserves 96GB for GPU use, and that split is only adjustable from Windows. Dropping the Windows-side GPU memory reservation down to 4GB freed up 120GB for Linux to see once booted. After that adjustment, the laptop ran a full desktop at 4K and 120Hz, with working audio, touchpad, keyboard, and CUDA acceleration.

回到 Omarchy 解决了驱动程序问题，因为其内核已经捆绑了 Nvidia 的开源驱动程序。此时 Linux 可以正常启动，但只能识别出笔记本电脑 128GB 统一内存中的 28GB。这是因为笔记本电脑的固件为 GPU 保留了 96GB，而这种分配只能在 Windows 中调整。将 Windows 端的 GPU 内存预留降至 4GB 后，Linux 在启动后即可识别出 120GB 内存。调整后，笔记本电脑以 4K 和 120Hz 运行完整桌面，音频、触摸板、键盘和 CUDA 加速均可正常工作。

Getting video output over HDMI during the install process was its own obstacle. Early in the process, the laptop would only display video on its own internal screen, not over HDMI, which required pointing an external camera at the laptop’s screen just to see what was happening during remote-controlled installation steps.

在安装过程中通过 HDMI 获取视频输出是另一个障碍。在过程初期，笔记本电脑仅在内置屏幕上显示视频，而不通过 HDMI 输出，这需要将外部摄像头对准笔记本电脑屏幕，才能在远程控制安装步骤时看到正在发生的情况。

This is where the story turns. With GPT-OSS-120B running on the GPU, Windows produced 65.4 tokens per second. WSL, which runs a Linux environment inside Windows, hit 65.1 tokens per second, nearly identical. The DGX Spark desktop unit, running Nvidia’s native Linux build, came in at 61 tokens per second. Native Linux on the laptop, however, dropped to 13.9 tokens per second, roughly five times slower.

故事在这里发生了转折。当在 GPU 上运行 GPT-OSS-120B 时，Windows 的处理速度为每秒 65.4 个 token。在 Windows 内运行 Linux 环境的 WSL 达到了每秒 65.1 个 token，几乎相同。运行 Nvidia 原生 Linux 系统的 DGX Spark 台式机为每秒 61 个 token。然而，笔记本电脑上的原生 Linux 却降至每秒 13.9 个 token，速度慢了大约五倍。

The gap showed up again with vLLM running eight concurrent clients: WSL reached 127 tokens per second while native Linux reached 39.5. A longer benchmark run told the same story in time rather than throughput. Windows finished in about 8 minutes while holding the GPU near 2.2 GHz. Linux took 37 minutes, with the GPU parked around 790 MHz the entire time. Temperatures stayed low, between 40 and 47°C, so this isn’t a thermal throttling issue. The GPU simply isn’t being allowed to run at full speed.

在使用 vLLM 运行八个并发客户端时，这种差距再次显现：WSL 达到了每秒 127 个 token，而原生 Linux 仅为 39.5 个。更长时间的基准测试在时间而非吞吐量上说明了同样的问题。Windows 在 GPU 保持在 2.2 GHz 附近的情况下，大约 8 分钟完成任务。Linux 则耗时 37 分钟，期间 GPU 一直停留在 790 MHz 左右。温度保持在 40 到 47°C 之间的低位，因此这不是热节流问题。GPU 只是没有被允许以全速运行。

Oddly, the direction of the problem flips depending on power source. Unplugged, Linux hit around 61 to 67 tokens per second on LM Studio, comparable to Windows. Plugged in, that same test dropped to about 15 tokens per second. Clock speed told the same story: around 1,800 MHz unplugged under load, and down to roughly 780 MHz when connected to wall power.

奇怪的是，问题的方向会根据电源而改变。在不插电的情况下，Linux 在 LM Studio 上每秒可达到约 61 到 67 个 token，与 Windows 相当。接通电源后，同样的测试降至每秒约 15 个 token。时钟频率也反映了同样的情况：负载下不插电时约为 1,800 MHz，连接电源后降至约 780 MHz。

The cause traces back to a component visible in Windows Device Manager called the Nvidia Platform Controllers and Framework. This piece of firmware and driver logic manages the shared power budget between CPU and GPU, since a laptop (unlike the desktop DGX Spark) has to balance power delivery between both chips rather than feeding the GPU on its own line.

原因可以追溯到 Windows 设备管理器中可见的一个组件，即 Nvidia 平台控制器和框架（Nvidia Platform Controllers and Framework）。这部分固件和驱动逻辑管理着 CPU 和 GPU 之间的共享功耗预算，因为笔记本电脑（与台式机 DGX Spark 不同）必须在两个芯片之间平衡供电，而不是为 GPU 提供独立的供电线。

Disabling that controller in Windows reproduced the slowdown directly: tokens per second dropped from around 83 to about 31, and clock speed fell from roughly 2 GHz down to the same 786 MHz seen on Linux when plugged in. Re-enabling the controller restored normal speed immediately. That confirms the controller, not the kernel, the distribution, or the Nvidia GPU driver itself, is what’s holding Linux back.

在 Windows 中禁用该控制器直接重现了减速现象：每秒 token 数从约 83 个降至约 31 个，时钟频率从约 2 GHz 降至与 Linux 插电时相同的 786 MHz。重新启用控制器后，速度立即恢复正常。这证实了是该控制器，而不是内核、发行版或 Nvidia GPU 驱动程序本身，在阻碍 Linux 的性能。

The deeper issue is that the firmware hands this controller a table of power settings that is encrypted. Windows has the key to decrypt it. Linux currently does not, and no software fix attempted during testing could enable it, including one attempt that triggered a kernel panic. Extracting the decryption key from the Windows driver was floated as a theoretical workaround, but that would amount to a fragile, single-machine hack rather than something that works broadly. A real fix needs to come from Nvidia shipping equivalent power management logic in its Linux driver.

更深层的问题在于，固件向该控制器提供了一张加密的电源设置表。Windows 拥有解密密钥，而 Linux 目前没有。测试期间尝试的任何软件修复都无法启用它，包括一次触发了内核崩溃的尝试。从 Windows 驱动程序中提取解密密钥被视为一种理论上的变通方法，但这将是一种脆弱的、针对单机的黑客手段，而不是一种广泛适用的方案。真正的修复需要 Nvidia 在其 Linux 驱动程序中提供相应的电源管理逻辑。

For most developers, yes, at least for now. WSL runs on top of the Windows driver stack, so it inherits Windows’ full GPU boost behavior whether the laptop is plugged in or running on battery. It also runs Linux-first AI tools like vLLM and SGLang without the clock throttling problem that affects native Linux installs.

对于大多数开发者来说，是的，至少目前如此。WSL 运行在 Windows 驱动堆栈之上，因此无论笔记本电脑是插电还是使用电池，它都能继承 Windows 的完整 GPU 加速行为。它还可以运行 vLLM 和 SGLang 等以 Linux 为优先的 AI 工具，而不会出现影响原生 Linux 安装的时钟节流问题。

The one adjustment needed is

唯一需要的调整是