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

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

能在Nvidia RTX Spark笔记本电脑上运行Linux吗？ 可以，但有一个严重的限制。Linux可以在MSI Prestige N16 Flip AI Plus等RTX Spark笔记本电脑上安装并运行，包括通过Nvidia的开源内核驱动实现GPU加速。问题在于时钟频率：一旦笔记本接通电源，GPU在Linux下就会被锁定在约780 MHz，而Windows下则能跑到2 GHz以上。这使得一颗在1200亿参数模型上本可达到约65 tokens/s的芯片，变成了艰难突破14 tokens/s的状态，原因与Linux目前无法读取的电源管理固件有关。

RTX Spark平台搭载于MSI Prestige、Asus ProArt和Dell XPS等机型，其GPU设计与Nvidia的DGX Spark桌面主机相同。但DGX Spark出厂预装的是Nvidia自家的Linux版本，而这些笔记本 variants 则全部预装Windows on ARM。

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

由于AI工具生态的很大一部分（包括vLLM和SGLang）都是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/s。WSL（在Windows内运行Linux环境）达到65.1 tokens/s，几乎相同。DGX Spark桌面主机运行Nvidia原生Linux版本，成绩为61 tokens/s。然而，笔记本上的原生Linux降至13.9 tokens/s，慢了大约五倍。

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

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

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

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

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

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