RTX SparkノートPCでのLinux GPUスロットリングにより、ローカルLLMの速度が制限される

新しいNvidia RTX SparkノートPCでネイティブLinuxを実行しようとする開発者は、AI推論速度を大幅に低下させる重大な性能ボトルネックに直面しています。MSI Prestige N16 Flip AI Plusに関する最近の技術レビューによると、オペレーティングシステムは正しくインストールされますが、デバイスがコンセントに接続されるとGPUクロック速度が急激に低下します。このハードウェア固有の制限により、現時点ではこれらのマシンでの高性能なローカルモデルのトレーニングと推論には、Windows Subsystem for Linux（WSL）のみが現実的な選択肢となっています。

何が起きたか

MSI Prestige、Asus ProArt、Dell XPSなどのデバイスに見られるRTX Sparkプラットフォームは、重いAIワークロード向けに設計された統合メモリアーキテクチャを採用しています。これらのノートPCはARMベースのWindowsを搭載して出荷され、CPUとGPU間で共有される最大128GBのRAMをサポートしています。多くのAIエンジニアリングツールはまずLinux向けに構築されているため、開発者は自然とデュアルブートやWindowsからネイティブLinuxディストリビューションへの置き換えを試みます。しかし、この移行は電力管理ファームウェアに関連する深刻な性能低下を引き起こします。

ネイティブLinuxを実行する場合、ノートPCが外部電源に接続されるとGPUクロック速度は約780 MHzまで低下します。対照的に、同じハードウェアでWindowsまたはWSLを実行している場合、負荷下でも2 GHz以上のクロック速度を維持します。この差異は熱によるものではありません。温度は40〜47°Cの間で低く保たれています。実際には、GPUはLinuxドライバが現在アクセスまたは上書きできないファームウェアロジックによって人工的に上限が設定されています。その結果、大規模言語モデルにおけるトークン生成速度が5分の1に減少します。

これらのデバイスにLinuxをインストールするには、重要な手動設定も必要です。Debianなどの標準的なディストリビューションは、特定のカーネルパッチなしではWi-Fi、キーボード、タッチパッドなどの必須ハードウェアコンポーネントを認識しないことがよくあります。成功したセットアップは通常、Nvidiaのオープンソースカーネルドライバを含むOmarchyなどのディストリビューションに依存しています。120Hzでの4K出力を持つ安定したデスクトップ環境を達成した後でも、OSが利用可能なRAMの一部以上にアクセスできるように、Linuxを起動する前にWindowsでメモリ割り当て設定を調整する必要があります。

仕組み

スロットリングの原因は、Nvidia Platform Controllers and Frameworkと呼ばれるWindows専用のファームウェアコンポーネントにあります。ノートPCフォームファクターでは、このコントローラがCPUとGPU間の共有電力予算を管理し、どちらのコンポーネントもシャーシの総電力供給制限を超えないようにします。専用電源ラインを持つデスクトップDGX Sparkユニットとは異なり、ノートPCはエネルギー使用量を動的にバランスさせる必要があります。ファームウェアは、Windowsドライバが復号化して適用できる暗号化された電力設定テーブルを提供し、GPUが最大周波数までブーストできるようにします。

Linuxには、この電力テーブルを復号化できる同等のドライバがありません。これらの設定にアクセスできないため、Linuxカーネルはデバイスが接続されているときに安全な低電力状態をデフォルトとし、GPUクロックを約780 MHzに固定します。興味深いことに、この動作はノートPCがバッテリー電力で実行されている場合には逆転し、Linuxのパフォーマンスは電力制約が異なる方法で処理されるため、Windowsとほぼ一致します。ソフトウェア回避策を通じてこの制限をバイパスしようとする試みは失敗しており、一部はカーネルパニックを引き起こすことから、暗号化キーがWindowsドライバスタックに厳密に紐付けられていることが示唆されています。

主要な詳細

• MSI Prestige RTX Spark上のネイティブLinuxは、GPT-OSS-120Bで毎秒13.9トークンを達成するだけで、Windowsでは毎秒65.4トークンです。
• Linuxでは電源接続時にGPUクロック速度が約780 MHzにロックされますが、Windowsでは2.2 GHzです。
• WSLはWindowsドライバスタックを利用するため、毎秒65.1トークンを記録し、ネイティブWindowsとほぼ同一のパフォーマンスを発揮します。
• OSが120GBのRAMを認識できるように、Linuxをインストールする前にWindowsでGPUメモリ予約を96GBから4GBに下げなければなりません。
• スロットリング問題は、Windows Nvidia Platform Controllersドライバのみがアクセスできる暗号化された電力管理テーブルによって引き起こされます。
• Windowsでプラットフォームコントローラを無効にするとLinuxのスローダウンが再現され、このコンポーネントが性能差の原因であることが確認されました。

なぜ重要なのか

AIエンジニアやML実務者にとって、この発見はポータブル開発ステーション向けのハードウェア推奨を根本的に変えます。デスクトップDGX Sparkのパフォーマンスに匹敵するLinuxネイティブノートPCという約束は、このファームウェアロックにより現在実現されていません。ローカルLLMの実行、モデルのファインチューニング、またはネイティブLinux環境でのvLLMなどのツールの使用を期待してこれらのハイエンドマシンを購入する開発者は、深刻なボトルネックに遭遇します。毎秒65トークンから14トークンへのパフォーマンス低下は、ネイティブLinuxで大規模モデルとのリアルタイムインタラクションを実用的なものにしません。

この状況は、異なるオペレーティングシステム間でのAIハードウェアサポートの複雑さが増していることを浮き彫りにします。NvidiaがCUDAサポートでARMベースのWindows市場に進出する中、Linuxエコシステムはこれらの特定のハイブリッドアーキテクチャに対するドライバ成熟度で遅れを取っています。NvidiaがプラットフォームコントローラのロジックをLinuxドライバに移植するまで、開発者はLinuxツールの利便性とWindowsの生パフォーマンスの間で選択を迫られます。この断片化は、本来プラットフォーム非依存であるべきワークフローに摩擦を加えます。

できること

• 重いAIワークロードにはすべてWindows Subsystem for Linux（WSL）を使用し、完全なGPUブースト速度を維持しながらLinux互換ツールにアクセスしてください。
• 128GBの統合メモリマシン上の大規模モデルにはデフォルトの14GB制限が不十分なため、WSLメモリ割り当てを手動で増やしてください。
• ネイティブLinuxを使用しなければならない場合は、クロックスロットリングが発生しないバッテリー電力で実行中にすべての集中的な推論タスクを実行してください。
• オペレーティングシステムがシステムRAMの大部分にアクセスできるように、Linuxをインストールする前にWindows設定でGPUメモリ予約を4GBに調整してください。
• RTX Sparkチップに必要なNvidiaオープンソースカーネルドライバが含まれているかを確認せずに、標準的なDebianまたはUbuntuインストーラーに頼らないでください。
• LinuxでのPlatform Controllers and Frameworkサポートに関する更新については、Nvidiaドライバリリースノートを確認してください。これが永久的な修正への唯一の道だからです。