Nvidia RTX SparkノートPC、暗号化された電源ファームウェアによりLinuxでGPU性能が65%低下

TL;DR

RTX SparkノートPCでのLinuxデュアルブートは可能ですが、AC電源接続時にGPUが約780 MHzに制限され、推論スループットが約14 tokens/sまで低下します。
このスロットリングは、Windows専用のファームウェアコンポーネントであるNvidia Platform Controllers and Frameworkが原因です。このコンポーネントの暗号化された電力テーブルは、Windowsドライバでしか復号できません。
ベンチマークによると、WindowsおよびWSLでは120 Bモデルで約65 tokens/sを達成しますが、ネイティブLinuxでは約14 tokens/sにとどまります。
メモリ割り当ても課題の一つで、ノートPCはGPU用に96 GBのユニファイドメモリを予約しますが、これはWindowsからしか調整できません。
現時点では、Windowsドライバスタック上で動作し、GPUブーストを維持できるWSLが実用的な解決策です。
恒久的な修正には、NvidiaがLinuxドライバで同様の電源管理ロジックを公開する必要があります。

Linuxは起動するが、GPUはロックされる

MSI Prestige N16 Flip AI Plus（RTX SparkノートPC）にLinuxをインストールすると、オープンソースのNvidiaカーネルドライバは正しく読み込まれ、手動設定後に4K @ 120 Hzの出力、オーディオ、キーボード、タッチパッドが機能します。しかし、ノートPCを壁コンセントに接続すると、GPUクロックはWindowsで観測される約2.2 GHzではなく、約780 MHzで停滞します。このクロックの低下により、120 Bモデルで約65 tokens/sの性能を持つチップが約14 tokens/sまで低下し、5倍の速度低下を招きます。

「Linuxで電源に接続すると、GPUクロック速度は約780 MHzまで低下します。Windowsでは約2.2 GHzであるのに対し、ファームウェアの電力テーブルが暗号化されており、Windowsドライバでしか復号できないためです。」 – MindStudio blog

この速度低下はサーマルスロットリングによるものではなく、温度は40°Cから47°Cの間に保たれます。これは純粋に電源管理による制限です。

隠されたWindows専用コントローラー

Windowsのデバイスマネージャーには、Nvidia Platform Controllers and Frameworkというコンポーネントが表示されます。このファームウェアとドライバのペアは、ノートPCのCPUとGPU間で共有される電力バジェットを管理します（専用のGPUレールを持つデスクトップ版のDGX Sparkとは異なります）。コントローラーはファームウェアから暗号化された電力テーブルを受け取り、Windowsドライバが復号キーを保持しています。

Windowsでこのコントローラーを無効にすると、Linuxと同様の速度低下が再現されます。トークンスループットは約83 tokens/sから約31 tokens/sに低下し、GPUクロックは約786 MHzまで落ちます。再度有効にすると、即座にフルスピードに戻ります。Linuxにはこれに相当するコンポーネントがないため、GPUはより高い電力割り当てを受け取ることができません。

「原因は、Windowsデバイスマネージャーで確認できるNvidia Platform Controllers and Frameworkというコンポーネントに遡ります。Windowsでそのコントローラーを無効にすると、速度低下が直接再現されました。」 – MindStudio blog

なぜファームウェアが暗号化されているのか

Nvidiaは、独自の電源管理アルゴリズムを保護するために電力テーブルを暗号化しています。Windowsドライバには秘密鍵が含まれていますが、オープンソースのLinuxドライバには含まれていません。鍵を抽出したりドライバにパッチを当てたりする試みは、カーネルパニックを引き起こすか、一時的な回避策にしかならず、適切な修正はNvidiaから提供される必要があることが確認されています。

ベンチマークが示す性能差

環境	GPUクロック (MHz)	Tokens/s (GPT-OSS-120B)
Windows (ネイティブ)	~2 200	65.4
WSL 2 (Linux on Windows)	~2 200	65.1
Nvidia DGX Spark (Linux)	~2 200	61
ネイティブLinux on RTX Spark	~780	13.9

8つのクライアントを同時に実行するvLLMを用いた2回目のテストでは、WSLで127 tokens/s、ネイティブLinuxで39.5 tokens/sという結果が出ました。ノートPCの電源を抜くと、Linuxのクロックは最大約1 800 MHzまで上昇し、トークンレートは61-67 tokens/sまで上昇してWindowsと同等になります。Linuxで電源接続時の方が遅いという異常は、電源コントローラーの動作に直接起因しています。

メモリ分割もLinuxの障害

RTX SparkノートPCは、CPUとGPU間で共有される最大128 GBのユニファイドメモリを公開します。初期状態では、ファームウェアは96 GBをGPU用に予約し、OSには32 GBしか残しません。LinuxではファームウェアのUIがWindowsにしか存在しないため、この分割を変更できません。WindowsからGPUの予約を4 GBに下げることで、再起動後にLinuxで120 GBのRAM全体を認識できるようになります。

「ノートPCはデフォルトで96 GBのユニファイドメモリをGPU用に予約しており、その分割を変更する設定はWindowsでしか公開されていません。LinuxでRAMの大部分を認識させるには、これが必要です。」 – MindStudio blog

WSL：実用的な中間地点

WSLはWindowsドライバスタック上で動作するため、Windowsの電源管理ロジックを継承しており、電源の種類に関係なくGPUブーストを完全に維持します。WSLのメモリ割り当て（デフォルト14 GB）をより大きな値に増やすと、ベンチマーク結果はネイティブWindowsと区別がつかなくなります。

「WSLはWindowsカーネルとドライバスタック上でLinux環境を実行するため、WindowsのGPUクロックブースト動作を維持し、スロットリング問題を回避しつつ、vLLMのようなLinux優先のAIツールをサポートします。」 – MindStudio blog

Linuxツールを必要としながら5倍の速度低下を受け入れられない開発者にとって、WSLは現在、性能と利便性のバランスが最も優れています。

コミュニティの反応と今後の展望

Nvidiaのクローズドソースアプローチ – 多くのコメント投稿者（例：@jleask、@laughing_man）は、重要なファームウェアを暗号化し続け、性能を独占させるNvidiaの習慣を嘆いています。
リバースエンジニアリングへの期待 – @viraptorや@bitbasherのようなユーザーは、コミュニティが最終的に電力テーブルをリバースエンジニアリングできる可能性があると示唆していますが、そのようなハックは脆弱であり、単一のマシンに限定されることを認めています。
アップストリームでの修正への期待 – 適切な解決策は、過去の機能（例：Dynamic Boost）が遅れてLinuxに追加されたのと同様に、NvidiaがLinuxドライバに電源管理ロジックを出荷することであるという点で合意が得られています。
代替ハードウェア – 一部のコメント投稿者（例：@demo4567）は、歴史的にオープンな電源管理インターフェースを備えているAMD GPUへの切り替えを示唆しています。

RTX Spark所有者のための実用チェックリスト

デュアルブート – デスクトップを機能させるために、Nvidiaのオープンソースドライバをバンドルしたディストリビューション（例：Omarchy）を使用してください。
ユニファイドメモリの調整 – Windowsで起動し、Nvidia Platform Controllersの設定を開き、Linuxを起動する前にGPUメモリの予約を減らしてください（例：4 GBへ）。
AC電源でのスロットリングを想定 – フルパフォーマンスが必要な場合は、WSL上でワークロードを実行するか、ノートPCをバッテリー駆動のままにしてください。
GPUクロックの監視 – nvidia-smiを使用して、クロックが2 GHz付近に留まっているか確認してください。約780 MHzのままの場合は、Linuxの制限に抵触しています。
ドライバの更新を待つ – Nvidiaのリリースノートで、Linuxにおける「Platform Controllers」や「Power Table」のサポートに関する言及がないか確認してください。

結論

LinuxはNvidia RTX SparkノートPCで動作しますが、暗号化されたWindows専用の電源管理ファームウェアコンポーネントにより、電源接続時にGPUが約780 MHzに制限され、AI推論速度が約65%低下します。Nvidiaが同等のLinuxドライバを提供しない限り、フルパフォーマンスを維持する唯一の信頼できる方法は、WSLまたはWindows上でワークロードを実行することです。