Arch Linux でマイクロソフトに勝つ：ASUS ProArt P16 の高性能 ARM ノート PC 構築報告

tl;dr: Arch Linuxは Windows と同等の 7-Zip パフォーマンスを実現し、OS と CUDA に合わせて116.0 GBという巨大なメモリモジュールを共有可能にします。本稿では、ASUS ProArt P16 H7607BA-SE033W（128 GB RAM、6,144 コア NVIDIA GPU、2 TB SSD）を対象とした初期起動環境構築とパッチの詳細を紹介します。

背景と動機

GPU がアクセス可能な超大容量メモリのノート PC 登場に伴い、オープン・ウェイトモデルをローカルで動作させる最適化や RL（強化学習）、量子化、ファインチューニングなどの可能性について考察しました。

• 著者はすでに Hugging Face に独自の GGUF 量化モデルを投稿し、過去 1 ヶ月で16 万回以上のダウンロード実績があります。
• 当初は Windows の公式サポート発表に落胆しましたが、以下が主な不満点です。
  • セットアップ時のプライバシーに関する譲歩
  • タスクバー配置変更などでマイクロソフトへの依存と待機時間
  • 広告の存在

※詳細な広告事例については割愛し、本題へ進めます。

Arch Linux は著者が信頼するディストリビューションであり、パッケージ維持チームメンバーでもあります。IBM メインフレームなどでも Arch が導入されており、プロジェクトは当然 Arch から始まりました。今回はハードウェアサポートを追加した Arch Linux ARMを使用しています。

ハードウェア構成とドライバ設定

NVIDIA は Ubuntu 向けのカーネル開発を行っており、それを起点として構築しました。

• ACPI オーバーライド: ノート PC 独自のテーブルから割り当て情報を抽出し、コンソール表示に必要なフレームバッファマッピングを修正しました（astra さんへ感謝）。
• ドライバーソース:
  • NVIDIA ドライバと ASUS スピーカーファームウェアはインターネット上の公式ソースから取得しています。
  • キーボードサポートには

    hid-asus

    のパッチが必要です。
  • オーディオについては専用のマシンドライバを使用しました。
• 環境構築: これらをまとめて起動可能な USB メモリに構築し、upstream の Archinstall 4.5 を拡張してハードウェアサポートをインストールできるようにしました。
  • リポジトリにはビルドスクリプトやパッチ（ACPI テーブルダンプ手順、ASUS ドライバからローカルでスピーカーファームウェアを抽出する手順など）が含まれています。
  • 使用ファームウェア:

    H7607BA.300

構成概要

• ビルド入力: ハッシュ値で固定されており、週末作成のハードウェア用パッケージは Arch Linux パッケージ維持キーにより署名されています。
• ディスプレイ: 解像度3840 × 2400 ピクセル、刷新周波数120 Hz。
• システム運用:

  NetworkManager

  、

  PipeWire

  、rootless

  Podman

  （NVIDIA CDI を使用）を運用しています。
• インストール設定: インストーラーではカーネル、NVIDIA ドライバ、電力管理およびファームウェアパッケージは

  IgnorePkg

  で除外し、通常のパッケージのみが Arch Linux ARM から更新されます。

CPU パフォーマンス評価

10 月 19 日付で、カーネル

7.0.0-1022-nvidia

と NVIDIA ドライバ

615.78.08

を使用したネイティブな Arch Linux ARM 上でテストを行いました。

• テスト条件:
  • ハードウェア: ASUS ProArt P16（NVIDIA N1X CPU、20 コア）
  • バイナリ: ネイティブ ARM64 版 7-Zip 26.04
  • 方法：固定辞書サイズ 32 MiB を設定し、各スレッド数に対してウォームアップ後、3 回測定して中央値を算出。
• 比較基準: 公表されている Windows の結果および StorageReview/ComputerBase のデータを使用（MIPS 値は 1,000 で除して GIPS 換算）。

結果の詳細

• シングルスレッド: アーキテクチャの特性上、ほぼ同程度の性能です。
• マルチスレッド（全 20 コア使用時）:
  • Linux セットアップは圧縮で約5%、展開で約**3%**リードしており、優位性が見られます。
  • (注：HP レビューにはバージョンや辞書サイズが不明確なため、これは厳密なベンチマーク比較ではありません。)

ComputerBase による検証（N1X搭載 ProArt P16）

GIPS 単位での換算結果を比較しました。

• Windows 版 7-Zip: スコア 155.774 GIPS
• Arch Linux 版 (著者): 3 回の実行平均スコア 157.084 GIPS
  • 測定範囲：155.759 ～ 157.193 GIPS
  • Windows の結果は、この測定範囲内に収まっており、Linux が同程度かわずかに上回ることを示しています。

メモリ構成の比較（重要）

メモリの割り当て方において Linux と Windows は根本的な違いがあります。

物理メモリの共有性

• Arch Linux (Linux):
  • 116.0 GBという物理メモリプールから、システム RAM および CUDAへも同じ領域を報告します。
  • OS と GPU がメモリを共有可能であり、ワークロード間でリソースを動的に利用できます。
• Windows:
  • メモリは「GPU 専用」「共有」「CPU 専用」の領域に分割されています。
  • CPU ワークロードは GPU 専用領域を使用できず、逆に GPU アロケーションも CPU 専用領域からは使用できません。

リザーブ設定の影響

• Windows NVIDIA アプリで専用リザーブ容量を変更して再起動可能ですが、Frandroid の検証（128 GB ProArt P16）では最大 96 GBまでしか設定できませんでした。
  • CUDA は制限を超えて共有メモリから割り当てできますが、Windows の予算に従います。
• 比較結果の一例（91 GB リザーブ設定）:
  • Windows (Frandroid): CUDA 全体で 109.7 GB を報告（共有メモリ含む）。
  • Arch Linux (著者): 116.0 GB を報告。
  • 差: Arch Linux は約6.3 GB多い有効メモリ領域を提供します。

重要な点: 著者が重視するのは、ワークロード間をスライド操作や再起動を行うことなく、大きなプールの CPU ワークロードにも常に利用可能な状態です。

ローカルでの Qwen モデル実行評価

vLLM を用い、B12X CUDA カーネルと混合量子化および FP8 KV キャッシュを使用したネイティブ ARM64 コンテナ上で、NVIDIA の

Qwen3.8-Flash-Next-FP4-Local

チェックポイントを動作させました（思考プロセス無効）。

初期設定

• 利用可能 RAM: モデル読み込み前、Linux では110.9 GBが報告されました。
• 割り当て状況 (vLLM ログ):
  • モデル読み込み: 68.2 GB
  • KV キャッシュ: 21.1 GB
  • 合計：ノート PC でモデルと KV キャッシュにほぼ90 GBが割り当てられました。

パフォーマンスベンチマーク

• 初期処理: モデル読み込みとコンパイルには最初のリクエスト以前に約16 分かかりました。
• 推論構成:
  • PLE エンベッディングテーブルはディスク backed で、ウォームページキャッシュの恩恵を受けます（CPU オフロード）。
  • 推論自体は CUDA が担当し、一部モデルは GPU メモリ外に配置されます。

タスク実行結果

Python ヘルパーを使って以下のタスクを 2 つのバグを持って実装しレビューさせました：

1. 長いインシデントログから失敗した操作を検出
2. 支払い注釈を JSON 形式に変換

各タスクはウォームアップ後 3 回実行し、既知の正解と比較しました。

• インシデント処理:

  • 約10,000 トークンを読み込み、リクエスト原因次のアクションを6 秒未満で正しく返しました。
  • 出力は 39 トークンのみであり、全体のリクエストに対するトークン速度は6.8 トークン/秒。
  • 待ち時間の大部分はプロンプト処理にかかっているため、応答時間は「トークン/秒」の指標以上に重要です。

• コードレビュー:

  • Frandroid (Windows) と著者 (Linux) で比較を行いました。
  • 両方の ProArt セットアップは約30 トークン/秒の生成速度でした。
  • 設定の違い: Frandroid は 85 GB リザーブと 262,144 トークンのコンテキスト制限、著者は 32,768 トークンです。

バッチ処理テスト（同時 4 つのコードレビュー）

• 中央値でバッチ処理は5.314 秒で完了。
• すべてのリクエスト合計で86.6 トークン/秒の出力速度となりました（プロンプト処理とオーバーヘッド込み）。
• 12 の答えすべてが3 バッチで正常に通過しました。

継続動作テスト（10 分間）

• 3 つのタスクを交互に、1 リクエストずつ 10 分間動作させ続けました。
• 完了リクエスト数：合計150（各タスク 50）。すべての答えがチェックに合格。
• 中央値応答時間:
  • コードレビュー：4.036 秒
  • ログ処理：5.921 秒
  • 抽出：2.046 秒
• 安定性検証: 各タスクの最初の 10 と最後の 10 の反復を比較すると、中央値応答時間は最大**1.6%**しか増加しませんでした。

結論

計測された171のすべての応答がチェックに合格しました（決定論的なデコードによる再試行）。

• すべての答えと生エベントストリームを保持し、サマリーと比較して確認しています。
• Arch Linux の環境では、Windows と同等かそれ以上のパフォーマンスを発揮しており、超大容量メモリの有効活用が可能であることが実証されました。