Nvidia RTX Spark笔记本Linux下GPU被锁频，推理速度降至35%

在Nvidia RTX Spark笔记本上双启动Linux的实测体验，发现的GPU时钟节流bug，以及为什么WSL仍然是更好的选择。

RSS

能在Nvidia RTX Spark笔记本上运行Linux吗？

可以，但有个严重的附加条件。Linux可以在RTX Spark笔记本上安装并运行，比如MSI Prestige N16 Flip AI Plus，包括通过Nvidia的开源内核驱动实现GPU加速。问题出在时钟速度上：一旦笔记本接通墙电，GPU在Linux上就会被锁定在约780 MHz，而在Windows上则能跑到2 GHz以上。这让一颗原本在1200亿参数模型上能跑出约65 tokens每秒的芯片，变成了勉强突破14 tokens每秒的水平，原因与Linux目前无法读取的电源管理固件有关。

RTX Spark平台出现在MSI Prestige、Asus ProArt和Dell XPS等机型中，采用与Nvidia DGX Spark桌面单元相同的GPU设计。但DGX Spark出厂即搭载Nvidia自家的Linux构建，而这些笔记本变体无一例外都预装Windows on ARM。

这一区别很重要，因为支持CUDA的Windows on ARM是新生事物。基于ARM的Windows机器已经存在几年了，但将这一架构与Nvidia的CUDA栈配对，直到这颗芯片才成为可能。这些笔记本还支持最高128GB的统一内存配置，由CPU和GPU共享，这在笔记本中并不常见，也正是它们最初面向AI开发者营销的核心原因。

由于包括vLLM和SGLang在内的AI工具生态大部分是Linux优先构建的，购买这些机器的开发者自然想知道能否抛弃Windows，或者至少双启动，而不损失性能。

这个过程并非即插即用。第一次尝试使用Omarchy（一个源于Arch的Linux发行版）失败了，因为它虽然已经支持Asus和Dell硬件上的这颗芯片，但MSI Prestige的表现不同，启动时产生了闪烁、不稳定的显示。

换用Debian更可靠一些，但仍需要变通方案。安装程序无法连接Wi-Fi，所以安装需要一个USB以太网适配器。开箱即用的Debian也无法识别键盘、触摸板或GPU，因为原版内核中不包含任何针对该笔记本的硬件支持。

回到Omarchy解决了驱动问题，因为它的内核已经捆绑了Nvidia的开源驱动。此时Linux能正常启动，但只能看到笔记本128GB统一内存中的28GB。这是因为笔记本固件为GPU使用预留了96GB，而这个划分只能在Windows中调整。将Windows侧的GPU内存预留降至4GB后，Linux启动时就能看到120GB。调整之后，笔记本能以4K 120Hz运行完整桌面，音频、触摸板、键盘和CUDA加速均正常工作。

安装过程中通过HDMI获取视频输出本身就是个障碍。在过程的早期，笔记本只能在内部屏幕上显示视频，无法通过HDMI输出，这导致在远程控制的安装步骤中，需要用外部摄像头对准笔记本屏幕才能看到发生了什么。

故事从这里开始转折。在GPU上运行GPT-OSS-120B时，Windows产出65.4 tokens每秒。WSL——在Windows内部运行Linux环境——达到65.1 tokens每秒，几乎相同。DGX Spark桌面单元运行Nvidia原生Linux构建，成绩为61 tokens每秒。然而笔记本上的原生Linux降至13.9 tokens每秒，慢了大约五倍。

差距在vLLM运行八个并发客户端时再次显现：WSL达到127 tokens每秒，而原生Linux只有39.5。更长的基准测试运行以时间而非吞吐量讲述了同样的故事。Windows大约8分钟完成，同时GPU保持在接近2.2 GHz。Linux花了37分钟，GPU全程停留在约790 MHz。温度保持在40至47°C之间，所以这不是热节流问题。GPU只是不被允许全速运行。

奇怪的是，问题的方向会随电源来源而翻转。不插电时，Linux在LM Studio上达到约61至67 tokens每秒，与Windows相当。插电后，同样的测试降至约15 tokens每秒。时钟速度也印证了这一点：不插电负载下约1,800 MHz，接通墙电后降至约780 MHz。

原因可追溯到Windows设备管理器中一个名为Nvidia Platform Controllers and Framework的组件。这个固件和驱动逻辑负责管理CPU和GPU之间的共享功耗预算，因为笔记本（不同于桌面DGX Spark）必须在两颗芯片之间平衡功耗分配，而不是让GPU独占一条供电线路。

在Windows中禁用该控制器直接复现了降速：tokens每秒从约83降至约31，时钟速度从约2 GHz降至与Linux插电时相同的786 MHz。重新启用控制器立即恢复正常速度。这证实了是控制器——而非内核、发行版或Nvidia GPU驱动本身——在拖累Linux。

更深层的问题在于，固件交给该控制器的是一张加密的功耗设置表。Windows有解密密钥。Linux目前没有，测试期间尝试的任何软件修复都无法启用它，其中一次尝试还触发了内核恐慌。从Windows驱动中提取解密密钥被提为一种理论上的变通方案，但这充其量只是一个脆弱的、单机hack，而非广泛适用的方案。真正的修复需要Nvidia在其Linux驱动中提供等效的电源管理逻辑。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）