RTX SparkラップトップにLinuxをインストールする理由：Microsoftアカウントがないから

Microsoftアカウントを持たないため、RTX SparkラップトップにLinuxをインストールする

tl;dr - マイクロソフトはダメだ。Arch Linuxは動作し、7-ZipではWindowsと同等の性能を発揮し、OSとCUDAに同じ116.0 GiBのメモリプールを報告する。私の初期ブート可能なセットアップとパッチはこちらにある。これはASUS ProArt P16 H7607BA-SE033W用で、128 GB RAM構成、6,144 CUDAコア、2 TB SSDを搭載している。

［画像: ASUS ProArt P16にNVIDIA N1X GPUを搭載したArch Linux ARMを示すFastfetch］

100 GiB以上のRAMをGPUがアクセスできるラップトップの噂が出始めたとき、私はその上で構築できるすべてのことや、時間をかけすぎてしまう最適化について考え始めた。私はオープンウェイトモデルを強く支持している。ローカルで実行し、ラップトップでRL、量子化、ファインチューニングをいじくり回せるのは素晴らしいことだ。私はすでにHugging Faceで自身のGGUFクアントを公開しており、過去1ヶ月で160,000ダウンロードを超えている。

そのため、Windows限定の公式サポートを知ったときは、あまり嬉しくなかった。Windowsを嫌う理由はたくさんある。私の理由には、セットアップ中のプライバシーに関する譲歩（参考1、参考2、参考3、参考4）、Microsoftがタスクバーを画面の横に置けるようにするのを長年待たされたこと、そして広告が含まれる。最後のリンクは、Pureinfotech提供の実際のWindowsプロモーションのコラージュだ（出典）。ご理解いただけただろう。延々と語れるが、本題に戻ろう。

Archは私の好みのディストリビューションであり、私はArchスタッフとしてパッケージメンテナーを務めている。すでにIBMメインフレームにもインストール済みだ（私のFOSDEMスライド）。だから、ここでも私の出発点になることは明らかだった。このビルドは、ArchパッケージをARMに移植する独立したプロジェクトであるArch Linux ARMを使用し、ハードウェアサポートを追加している。

NVIDIAはUbuntu向けにカーネル作業を行っており、それが私の出発点となった。それを組み込み、コンソールを取得するために必要なACPIオーバーライド割り当てとフレームバッファマッピングを修正し、ラップトップ自身のテーブルからACPIオーバーライドを特定した（ありがとう astra <3）。NVIDIAドライバーとASUSスピーカーファームウェアは、公式なインターネット上の場所から入手した（訴えないでください、コンピューター会社さん）。キーボードサポートにはパッチ適用済みのhid-asusが必要で、オーディオには独自のマシンドライバーが必要だった。

これをブート可能なUSBにまとめ、ハードウェアサポートをインストールするためにupstreamのArchinstall 4.5を拡張した。リポジトリにはビルドスクリプトとパッチがあり、ローカルでACPIテーブルをダンプし、ASUSのドライバーパッケージからスピーカーファームウェアを抽出する手順も含まれている。私の環境はファームウェアH7607BA.300で動作している。

ビルド入力はハッシュピンされている。私が週末にまとめたハードウェアパッケージは、私のArch Linux Package Maintainerキーで署名されており、ACPIオーバーライドはラップトップ自体から取得している。

ディスプレイは3840 × 2400、120 Hzで動作し、NetworkManager、PipeWire、NVIDIA CDIを使用したrootless Podmanを使用している。インストーラーは、IgnorePkgを使用してカーネル、NVIDIA、電源管理、ファームウェアパッケージを保持し、通常のパッケージはArch Linux ARMから更新され続ける。

CPUパフォーマンス

10月19日に、カーネル7.0.0-1022-nvidiaとNVIDIAドライバー615.78.08を使用し、ネイティブArch Linux ARMでベンチマークを実行した。ラップトップは電源に接続され、パフォーマンスプロファイルが選択されていた。CPU比較のために、公開されているWindowsの結果を使用した。

CPUテストはネイティブARM64 7-Zip 26.04で、辞書サイズは32 MiBに固定した。ウォームアップを1回、各スレッド数で3回の測定パスを実行し、中央値を記録した。

StorageReviewは、同じ20コアN1Xを搭載した128 GB HP OmniBook Ultra 16をテストし、ネイティブWindows ARM64バイナリを実行した。彼らは7-ZipのスコアをGIPSで報告しているため、私の生のログのMIPSスコアを1,000で割って合わせた。値が大きいほど良い。

シングルスレッドはほぼ同等だ。20スレッドすべてを使用した場合、私のLinuxセットアップは圧縮で約5%、解凍で約3%上回っている。HPのレビューでは7-Zipのバージョンや辞書サイズが明記されていないため、これらのパーセンテージは2つのラップトップセットアップを比較したものだ。

ComputerBaseも20コアN1Xを搭載したProArt P16をテストしている。GIPSに換算すると、そのWindows 7-Zipスコアは155.774だった。私の3回の実行の中央値は157.084だった。彼らの結果は、私の3回の実行範囲（155.759から157.193 GIPS）内に収まっている。彼らのマシンは64 GB構成で、7-Zip 26.00を実行しており、チャートには辞書サイズが記載されていない。

メモリの分割

メモリはより大きな利点だ。私のLinux実行では、同じ物理プールからシステムRAMとCUDAの合計として116.0 GiBが報告された。WindowsはRAMを専用GPU、共有、CPU専用領域に分割している。CPUワークロードは専用GPU領域を使用できず、GPU割り当てはCPU専用領域を使用できない。

WindowsのNVIDIAアプリでは、専用予約を変更して再起動できる。Frandroidの128 GB ProArt P16は96 GiBに達した。CUDAは、Windowsのメモリ予算の制約下で、共有RAMから割り当てることでそれを超えることができる。

91 GiBの専用予約で、FrandroidのWindowsセットアップは、共有メモリを含めて109.7 GiBのCUDA合計を報告した。私のLinuxセットアップは116.0 GiBを報告し、約6.3 GiB多かった。私が気にかけているのは、ワークロード間で予約スライダーを動かして再起動することなく、CPUワークにも大きなプールが利用可能であることだ。

Qwenをローカルで実行する

NVIDIAのQwen3.8-Flash-Next-FP4-Localチェックポイントを、混合量子化とFP8 KVキャッシュを使用したネイティブARM64コンテナで、B12X CUDAカーネルを搭載したvLLM経由で実行した。この実行では思考をオフにした。

モデルをロードする前に、Linuxは110.9 GiBの利用可能なRAMを報告した。vLLMはモデルロードに68.2 GiBを記録し、KVキャッシュにさらに21.1 GiBを割り当てた。これはラップトップ上でモデルとKVキャッシュにほぼ90 GiBが割り当てられていることになる。

モデルのロードとコンパイルには、最初の要求の前に約16分かかった。以下のタイミングはウォームアップ後から開始する。PLE埋め込みテーブルはディスクにバックアップされており、ウォームなページキャッシュの恩恵を受ける。他のコンポーネントはCPUオフロードを使用する。CUDAが推論を処理し、モデルの一部はGPUメモリの外にある。

Qwenに2つのバグのあるPythonヘルパーをレビューさせ、1つの失敗した操作を見つけるための長いインシデントログを提供し、JSONに変換するための支払いメモを与えた。各タスクはウォームアップ後に3回実行され、確認するための既知の回答があった。どれくらい待つ必要があるか、そして正しいフィールドが返されるかを知りたかった。

インシデントタスクは10,000トークン近くを読み込み、6秒未満で正しい要求、原因、次のアクションを返した。その回答はわずか39トークンで、リクエスト全体で6.8トークン/秒に相当する。待機時間のほとんどはプロンプト処理に費やされたため、このタスクでは応答時間がトークン/秒の数値よりも多くの情報を提供してくれる。

コードレビューでは、生成速度を(出力トークン数 - 1) / (応答時間 - 最初のトークンまでの時間)と推定した。両方の時間は秒単位で、ストリームオーバーヘッドが含まれる。Frandroidは、Windows ProArtでQwen3.8-Flash-Nextのコーディングタスクを実行した。

両方のProArtセットアップは約30トークン/秒だ。推論では、Frandroidは85 GiBの専用予約と262,144トークンのコンテキスト制限を使用した。私のコンテキスト制限は32,768トークンだった。プロンプト、クアント、ランタイム、タイミング方法は異なる。これは2つの動作する構成を比較したものであり、OSの効果を分離するものではない。

一度に4つのコードレビューを送信した。中央値のバッチは5.314秒で完了し、4つのリクエスト全体で合計86.6出力トークン/秒を生成した。このレートにはプロンプト処理と応答オーバーヘッドが含まれる。すべての12の回答は3バッチで合格した。

その後、10分間、3つのタスクを1回のリクエストずつサイクルさせた。50回ずつ、合計150リクエストを完了し、すべての回答がチェックに合格した。中央値の応答時間は、コードレビューで4.036秒、ログで5.921秒、抽出で2.046秒だった。各タスクの最初の10回と最後の10回の繰り返しを比較すると、中央値の応答時間は1.6%未満しか増加しなかった。

測定された171のすべての応答がチェックに合格した。これは決定論的デコーディングで繰り返された3つのプロンプトであり、コードレビューチェックは回帰出力を検証する。すべての回答と生のイベントストリームを保持し、要約と比較した。