ASUS ProArt P16 RTX Spark N1XでのArch Linux ARM：116 GiBのユニファイドメモリとローカルQwenベンチマーク

Arch Linuxのパッケージメンテナーが、ASUS ProArt P16 H7607BA-SE033W（128 GB RTX Spark N1X構成）でArch Linux ARMを起動しました。OSとCUDAの両方から116.0 GiBのメモリプールが認識され、7-ZipのパフォーマンスはWindowsとほぼ同等であり、ローカルのQwen3.8-Flash-Next-FP4-LocalチェックポイントがvLLMを通じて約30.9トークン/秒で動作すると報告しています。このレポートは、制御されたOS比較ではなく、動作するポートの報告です。著者は、これらの数値はOSの影響を分離したものではなく、2つの動作環境を比較したものであると明言しています。

著者のJosie氏は、Archのスタッフとしてパッケージメンテナーを務めており、Hugging FaceでGGUF量子化モデルを公開し、先月だけで16万回以上のダウンロードを記録しています。動機は単純で、このラップトップの公式サポートがWindowsのみであり、著者がMicrosoftアカウントを所有していないためでした。この投稿の要約として、著者は「Microsoftなんて最低だ」と述べています。

ハードウェアと制約

マシンはASUS ProArt P16 H7607BA-SE033Wで、128 GBのRAM、6,144個のCUDAコア、2 TBのSSDを搭載しています。ASUSはWindowsのみの公式サポートを記載しています。著者がWindowsを避ける理由として、セットアップ時のプライバシー設定、タスクバーの配置オプションを待つ時間の長さ、OS内の広告などが挙げられています。

著者はArchを好んで使用しており、このビルドではArchパッケージをARMに移植する別プロジェクトであるArch Linux ARMを使用し、その上にハードウェアサポートを重ねています。著者は以前にIBMメインフレームでArchを動かした経験があり、今回もArchを出発点としました。

ポートに必要な作業

コンソールと動作するドライバスタックを実現するには、いくつかの特定の修正が必要でした。著者はNVIDIAのUbuntu向けカーネル作業から開始し、コンソールを表示するために必要なACPIオーバーライド割り当てとフレームバッファマッピングを修正し、ラップトップ独自のテーブルからACPIオーバーライドを導き出しました。NVIDIAドライバとASUSスピーカーファームウェアは、著者が「インターネット上の公式な場所」と呼ぶところから入手しました。キーボードサポートにはパッチを当てた hid-asus が必要で、オーディオには専用のマシンドライバが必要でした。

結果は起動可能なUSBとしてパッケージ化されており、アップストリームのArchinstall 4.5を拡張してハードウェアサポートをインストールするようにしています。github.com/pfeifferj/archlinuxarm-proart-p16 のリポジトリには、独自のACPIテーブルをダンプし、ASUSのドライバパッケージからスピーカーファームウェアをローカルで抽出する手順を含む、ビルドスクリプトとパッチが含まれています。著者のマシンはファームウェア H7607BA.300 を実行しています。

ビルド入力はハッシュで固定されています。ハードウェアパッケージは著者のArch Linuxパッケージメンテナーキーで署名されており、ACPIオーバーライドはラップトップ自体から取得したものです。インストーラーはカーネル、NVIDIA、電源管理、ファームウェアパッケージを IgnorePkg で保持し、通常のパッケージはArch Linux ARMから更新され続けます。

ディスプレイは3840 × 2400、120 Hzで動作します。著者はNetworkManager、PipeWire、およびNVIDIA CDIを使用したルートレスPodmanを使用しています。

7-ZipのパフォーマンスとWindowsの比較

CPUの比較には、ネイティブARM64の7-Zip 26.04を使用し、辞書サイズを32 MiBに固定しました。著者は各スレッド数で1回のウォームアップと3回の測定を行い、中央値をとりました。

スレッド数	圧縮 (MiB/s)	解凍 (MiB/s)
1	6.18	118.26
20	141.77	1,629.60

Windowsとの比較のため、著者はStorageReviewによる128 GB HP OmniBook Ultra 16（同じ20コアN1X搭載）のテスト結果を使用しました。StorageReviewは7-Zipの評価をGIPSで報告しているため、著者は生のログのMIPS評価を1,000で割って合わせました。数値が高いほど良好です。

7-Zipワークロード	ProArt, Linux (GIPS)	HP OmniBook, Windows (GIPS)	差
1スレッド圧縮	7.221	7.31	−1.2%
1スレッド解凍	10.779	10.87	−0.8%
20スレッド圧縮	165.754	157.9	+5.0%
20スレッド解凍	148.471	144.5	+2.7%

シングルスレッドのパフォーマンスはほぼ互角です。20スレッドすべてを使用した場合、Linuxセットアップは圧縮で約5%、解凍で約3%上回っています。著者は、HPのレビューでは7-Zipのバージョンや辞書サイズが指定されていないため、これらのパーセンテージはOSの影響を分離したものではなく、2つのラップトップセットアップを比較したものであると指摘しています。

2つ目のデータポイントは、ComputerBaseによる20コアN1X搭載ProArt P16のテストです。GIPSに換算すると、Windowsでの7-Zipスコアは155.774でした。著者の3回の実行における中央値は157.084で、155.759から157.193 GIPSの範囲内に収まっています。ComputerBaseのマシンは64 GB構成で7-Zip 26.00を実行しており、チャートには辞書サイズが記載されていません。

メモリ分割：OSとCUDAの両方に116.0 GiB

メモリ構成はより大きな違いです。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チェックポイントを、ネイティブARM64コンテナ内のB12X CUDAカーネルを使用してvLLMで実行しました。混合量子化とFP8 KVキャッシュを使用しています。実行中、思考（Thinking）はオフにされました。

モデルをロードする前、Linuxは110.9 GiBの利用可能なRAMを報告しました。vLLMはモデルロードに68.2 GiBを記録し、KVキャッシュにさらに21.1 GiBを割り当てました。ラップトップ上でモデルとKVキャッシュに合計約90 GiBが割り当てられたことになります。モデルのロードとコンパイルには、最初の要求までに約16分かかりました。PLE埋め込みテーブルはディスクにバックアップされており、ウォームページキャッシュの恩恵を受けています。他のコンポーネントはCPUオフロードを使用します。CUDAが推論を処理し、モデルの一部はGPUメモリ外にあります。

テストタスクは、レビュー用のバグのあるPythonヘルパー2つ、失敗した操作が1つ含まれる長いインシデントログ、JSONに変換する支払いメモでした。各タスクはウォームアップ後に3回実行され、既知の回答と照合されました。

タスク	入力トークン	最初のトークン, 中央値 (s)	完全な応答, 中央値 (s)	チェック合格
Pythonコードレビュー	208	0.316	4.008	3/3
128レコードのインシデントログから失敗を見つける	9,775	4.532	5.768	3/3
支払いメモの抽出	87	0.256	2.035	3/3

インシデントタスクは10,000トークン近くを読み取り、6秒以内に正しい要求、原因、次のアクションを返しました。回答はわずか39トークンで、リクエスト全体で6.8トークン/秒となります。待ち時間の大部分はプロンプトの処理に費やされたため、著者はそのタスクについてはトークン/秒の数値よりも応答時間の方が有益であると主張しています。

コードレビューについては、著者は生成速度を (出力トークン数 − 1) / (応答時間 − 最初のトークンまでの時間) として推定しました（時間は秒単位、ストリームオーバーヘッドを含む）。

システム	量子化とランタイム	生成 (トークン/秒)
ProArt P16, Linux	FP4-Local, vLLM B12X	30.9 (3回の中央値)
FrandroidのProArt P16, Windows	UD-IQ4_XS, llama.cpp	29.4 および 31.4

どちらのProArtセットアップも約30トークン/秒に達しています。Frandroidは85 GiBの専用予約と262,144トークンのコンテキスト制限を使用し、著者のコンテキスト制限は32,768トークンでした。プロンプト、量子化、ランタイム、タイミング手法が異なるため、著者はこれをOSの影響を分離したものではなく、2つの動作環境の比較として明示的に位置づけています。

バッチ処理と持続負荷

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

その後、著者はマシンを放置し、3つのタスクを1つずつ10分間循環させました。150のリクエスト（各50）を完了し、すべての回答がチェックに合格しました。中央値の応答時間は、コードレビューで4.036秒、ログで5.921秒、抽出で2.046秒でした。各タスクの最初と最後の10回の繰り返しを比較すると、中央値の応答時間は1.6%未満の増加でした。合計で、測定された171の応答すべてがチェックに合格しました。著者はすべての回答と生のイベントストリームを保持し、要約と照合しました。

議論での反論

コメント欄では、投稿の構成に対していくつかの反論が提起されました。そのほとんどはポート自体ではなく、コストとユースケースに関するものでした。

この価格でラップトップというフォームファクタは適切か？

最も強い反対意見は、同じシリコンがより安価またはより便利な形状で入手可能であるというものでした。あるコメント投稿者は次のように書いています：

「6,000ドルのラップトップの強力なユースケースはまだないと思います。AMD Ryzen 495や395を搭載し、96、128、192 GBのメモリを搭載したミニPCが同程度の価格で手に入り、より安価で小さく、バッテリー効率の良いラップトップからリモート接続できることを考えると。」

同じコメント投稿者は、Microsoftが同じチップをラップトップ以外のフォームファクタで出荷していることを指摘し、「飛行機内でのコーディング」というシナリオは、エコノミークラスの電源プラグを飛ばす電源ブリックや、ローカルAI負荷時の短いバッテリー寿命によって損なわれていると主張し、機内接続の改善が完全オフラインのユースケースを侵食するだろうと示唆しました。ゲームについては、Asus Zephyrusのような専用GPU搭載ラップトップを挙げました。

別のコメント投稿者は、128 GBマシンのHPバージョンを3,800ドルで入手したと報告し、これほど多くのRAMに対して見た中で最高の取引だと呼びました。

DGX SparkとプリインストールされたLinuxの代替品

Ubuntuを実行しているDGX Sparkの所有者は、前提を直接疑問視しました：

「なぜDGX Sparkの代わりにそれを手に入れるのか？OSはほとんどの開発者にとって大きな違いを生むし、DGX Sparkのスタックと経験は成熟している。」

関連するコメントでは、すでに複数のOEMがNVIDIAのLinuxディストリビューション（NVIDIA DGX OS）を搭載したRTX SparkミニPCを出荷し、Asusを含むメーカーがサポートしていると主張し、繰り返されるメッセージは「プリインストールされたLinuxデバイスを販売する価値はない」ということだと述べました。

Microsoftアカウントは本当に回避可能だったか？

複数のコメント投稿者は、ログイン問題には回避策があると主張しました。ある投稿者は、Windows Proでは「職場または学校のアカウント」→「ドメインに参加」を使用し、パスワードと復旧用の質問を設定できるが、Homeエディションではアカウントが必要で代替手段がますます制限されていると指摘しました。別の投稿者は完全にスクリプト化されたパスを説明しました：

「ファイルと最新の11 Proダウンロードのコピーが入ったUSBキーを持っていて、新しいマシンをセットアップするときはクリーンインストールを実行します。起動したら、開発者構成を実行します... Microsoftログインなし、Candy Crushなし、WSLがインストールされ、必要なすべてのツールが揃っています。」

その投稿者は autounattend.xml ジェネレーターとMicrosoftのWindowsDeveloperConfigリポジトリを指摘しました。他の人々は同じポイントをより率直に述べました。Microsoftアカウントの作成は無料で、その方が早かっただろうという意見や、Microsoftのログインフロー自体が苦痛であり、壊れたリダイレクト、ループするボタン、CAPTCHAを挙げた人もいました。

パフォーマンスへの懐疑と未回答の質問

あるコメント投稿者は推論の数値に疑問を呈しました：「Qwen 3.8 Flash Nextでたった30トークン/秒？最近は専門的なエンジンのおかげで、RAMオフロード付きの24 GBビデオカードでその約2倍の速度が出る。熱制限だろう...」彼らはまた、高密度モデルでマシンがどのように動作するかを尋ねましたが、投稿では回答されていません。

別のコメント投稿者は、達成の枠組みに異議を唱え、実際に克服された課題は何なのか、興味深い部分はarm64の作業なのか、それとも単なる新しいハードウェアのレビューなのかを尋ねました。3人目は、GPUアクセス可能なメモリが100 GiBを超えるラップトップは、AppleシリコンのM3から約3年前に存在していたと指摘し、投稿がAppleシリコンに全く言及していないことに注目しました。別のコメント投稿者は、このハードウェアでWaylandがどのように動作するかを尋ねましたが、提供された議論には回答がありません。

ベンチマークに関する注意点

投稿のパフォーマンスに関する主張は、ラップトップ構成間の比較であり、制御された実験ではありません。Windowsの7-Zipの数値は、StorageReviewのHP OmniBook Ultra 16とComputerBaseの64 GB ProArt P16というサードパーティのレビューからのものであり、どちらのレビューも関連するすべてのパラメータを指定していません。HPのレビューは7-Zipのバージョンや辞書サイズを述べておらず、ComputerBaseは7-Zip 26.00を実行しましたが、チャートには辞書サイズが記載されていません。Qwenの比較は、LinuxとWindowsの実行間で量子化、ランタイム、コンテキスト制限、プロンプト、タイミング手法が異なります。著者はこれらの制限を直接述べており、結果をOS間のベンチマークとして提示しているわけではありません。