出来事の日付：2026年11月4日。

NvidiaのRTX Sparkプラットフォームを採用したMSI PrestigeノートPCの検証で、本体の電力管理システムに関連する、Linuxネイティブ環境での大きな性能問題が見つかった。検証では、LinuxでノートPCをコンセントの電源に接続するとGPUクロックが約780 MHzに低下したのに対し、Windowsでは2 GHzを超えていた。

実用上の影響は大きかった。GPT-OSS-120Bモデルを動かすと、Windowsは毎秒65.4トークン、Windows Subsystem for Linuxは毎秒65.1トークンを生成した。Nvidiaのデスクトップ機DGX Sparkは毎秒61トークンだった。ノートPC上のLinuxネイティブ環境では、毎秒13.9トークンにとどまった。同時に8クライアントを動かす別のvLLMテストでは、WSLが毎秒127トークンに達したのに対し、Linuxネイティブ環境は毎秒39.5トークンだった。

より長時間のベンチマークでも、この結果が裏付けられた。Windowsは処理を約8分で完了したが、Linuxでは37分かかった。GPU温度は40～47℃の範囲にとどまり、熱が性能を制限しているわけではないことが示された。この異常な挙動は、バッテリー駆動時には逆転した。電源を抜くと、Linuxの性能は毎秒約61～67トークンに上がり、GPUクロックは1,800 MHz近くに達した。

調査では、速度低下とNvidia Platform Controllers and Frameworkとの関連が示された。これはCPUとGPUが共有する電力枠を管理するWindowsのコンポーネントだ。Windowsでこのコントローラーを無効にすると、Linuxと同様の速度低下が再現され、クロックは約786 MHzまで落ちた。再び有効にすると通常の性能に戻った。検証者によると、該当するファームウェアの電力テーブルは暗号化されており、Linuxには現在、それを利用するために必要な対応ロジックがないという。

Linuxのインストール自体は可能だったが、複数の回避策が必要だった。Debianは当初、Wi-Fi、入力機器、GPUへの対応が不足していた一方、Omarchyのインストール環境にはNvidiaのオープンカーネルドライバーが含まれていた。また、128 GBのメモリーの大半をLinuxから認識できるようにするため、統合メモリーの割り当てをWindowsから調整する必要もあった。設定後はディスプレイ、音声、入力、CUDAアクセラレーションが動作した。インストール初期には画面出力にも制約があり、セットアップ中に遭遇した互換性の問題が、性能上の不具合だけではなかったことを示している。

Linuxを主な対象とするvLLMやSGLangなどのツールを必要とする開発者にとって、この検証ではWSLがより実用的な選択肢だった。Windowsのドライバースタックを利用し、GPUのブースト動作を維持できたためだ。ただし、大規模モデルを扱うには、既定のメモリー割り当てを調整する必要があった。この折衷案により、開発者はLinuxのユーザー環境を利用し続けられるものの、本来の速度を出すにはホストOSとNvidiaのWindows向け電力制御が依然として不可欠となる。

今回の結果は、1件の詳細なハードウェア検証に基づくものであり、すべてのRTX Spark搭載ノートPC、ディストリビューション、ファームウェアのバージョンを広く調べたものではない。したがって、あらゆる構成で同じ挙動が起きると立証するものではない。それでも、再現されたコントローラーの挙動は、熱による制限や一般的なアプリケーション設定ではなく、プラットフォームレベルでLinux対応に不足があることを示唆している。持続的な解決には、NvidiaがLinuxにも同等のプラットフォーム電力管理機能へのアクセスを提供する必要がある。