Nvidia RTX Sparkプラットフォームは、ローカルAI開発向けに設計された特殊なハードウェア構成です。このプラットフォームは、CPUとGPUの間で最大128GBのメモリを共有する独自のユニファイドメモリアーキテクチャを備えており、NvidiaのDGX Sparkデスクトップユニットと同じGPU設計を採用しています。これらのノートPCは、vLLMやSGLangといったLinux優先のAIツールを好む開発者向けに販売されていますが、ハードウェア自体は現在、NvidiaのCUDAスタックに対する特定のドライバサポートを含むWindows on ARMに最適化されています。
テストの結果、ノートPCを電源に接続している際、オペレーティングシステム間で顕著なパフォーマンスの差があることが明らかになりました。GPT-OSS-120Bモデルを実行したマシンでは、ネイティブWindowsとWindows Subsystem for Linux (WSL) の両方が毎秒約65トークンを達成しました。対照的に、同じハードウェア上のネイティブLinuxインストールでは、速度は毎秒13.9トークンまで低下しました。この減速は熱によるスロットリングの結果ではなく、温度は低く保たれていた（40〜47°C）ため、クロック速度の崩壊が原因です。WindowsではGPUが約2.2 GHzのブーストを維持するのに対し、Linuxでは電源接続時に約780 MHzにロックされてしまいます。
このパフォーマンス格差は、Nvidia Platform Controllers and Frameworkと呼ばれるWindows専用コンポーネントに起因します。このファームウェアおよびドライバロジックは、2つのチップが電源ラインを共有するノートPCにおいて不可欠な、CPUとGPU間の共有電力予算を管理します。このファームウェアは暗号化された電力設定テーブルを提供しており、Windowsはこれを復号するための鍵を保持していますが、Linuxは現在それを保持していません。興味深いことに、ノートPCの電源を外すとこの問題は逆転します。バッテリー駆動時、Linuxのパフォーマンスは約61〜67トークン/秒まで向上し、Windowsのレベルにほぼ匹敵します。Nvidiaがプラットフォームコントローラの電力管理ロジックをLinuxドライバに移植するまでは、WindowsドライバスタックのフルGPUブースト維持能力を引き継ぎつつLinux互換環境を提供できるWSLが、最も実用的な中間地点となります。
このセットアップにおける顕著な制限の一つはメモリ管理です。このノートPCのファームウェアは、デフォルトでGPU用に96GBのユニファイドメモリを予約しており、この分割は現在Windowsを通じてのみ調整可能です。ネイティブLinuxを実行しようとするユーザーは、Linux環境で全容量のわずかな割合以上のメモリを確保するために、まずWindowsでこの予約量を調整する必要があります。ソース資料は、この問題がハードウェアの欠陥ではなくファームウェアとドライバのギャップであることを確認していますが、Nvidiaがこれらのユニット向けにLinux互換の電力管理ドライバをいつリリースするかについての確定したタイムラインは現在ありません。
8つの同時クライアントを使用したvLLMの特定のベンチマークは、この格差をさらに浮き彫りにしています。WSLは毎秒127トークンに達したのに対し、ネイティブLinuxはわずか39.5トークンでした。より長いテストでは、Windowsは2.2 GHzのクロック速度を維持しながら約8分でワークロードを完了しましたが、LinuxはGPUが790 MHzに固定された状態で37分を要しました。これらの数値は、欠落している電力管理ロジックが高スループットのAIワークロードに与える影響を強調しています。
この画像は、ベンチマークで説明されたパフォーマンス格差を例証しており、ネイティブLinuxがWindowsやWSLと比較して深刻なスロットリングを経験していることを示しています。
最終的に、現在のRTX SparkノートPCの状態は、開発者にとってトレードオフを生み出しています。ネイティブLinuxは純粋な環境を提供しますが、暗号化された電力管理テーブルへのアクセスができないため、電源接続時のハードウェアパフォーマンスは事実上損なわれます。当面の間、Linuxネイティブのツールとフルハードウェアパフォーマンスの最適なバランスを求める開発者は、より大きなモデルに対応するためにデフォルトの14GBメモリ割り当てを手動で増加することを条件に、WSLの使用を推奨されます。