Glonce

Arch Linux ARM runs on ASUS ProArt P16, shows 116 GiB to CUDA

infrastructureThe Glonce editorsHacker News🔥64Glonce rating64Impact40Novelty45Relevance65Surprise45Players35Credibility80

The author of the josie.lol blog, who says they are on the Arch staff as a package maintainer, has put Arch Linux on the ASUS ProArt P16 H7607BA-SE033W: the 128 GB RAM configuration with 6,144 CUDA cores, a 20-core N1X and a 2 TB SSD. Official support for the laptop is Windows-only. The author wanted to run open-weight models locally and experiment with RL, quantisation and fine-tuning on it, and already publishes their own GGUF quants on Hugging Face, with over 160,000 downloads in the past month.

The build uses Arch Linux ARM, the separate project that ports Arch packages to ARM, with hardware support added on top. NVIDIA's kernel work for Ubuntu gave the author a starting point. They incorporated it, fixed the ACPI override allocation and framebuffer mapping needed to get a console, and worked out the ACPI overrides from the laptop's own tables, with thanks to astra. The NVIDIA driver and ASUS speaker firmware come from official sources. Keyboard support needed a patched hid-asus, and audio needed its own machine driver. The result is a bootable USB image, plus an extension of upstream Archinstall 4.5 that installs the hardware support. The repo holds the build scripts and patches, including steps to dump your own ACPI tables and extract the speaker firmware from ASUS's driver package locally. The author's unit runs firmware H7607BA.300. Build inputs are hash pinned, and the hardware packages are signed with the author's Arch Linux Package Maintainer key. The display runs at 3840 × 2400 and 120 Hz; the desktop stack uses NetworkManager, PipeWire and rootless Podman with NVIDIA CDI. The installer holds the kernel, NVIDIA, power-management and firmware packages with IgnorePkg, while ordinary packages keep updating from Arch Linux ARM.

CPU results. The author ran the suite on October 19 on native Arch Linux ARM, kernel 7.0.0-1022-nvidia, NVIDIA driver 615.78.08, plugged in with the performance profile. The test is native ARM64 7-Zip 26.04 with a fixed 32 MiB dictionary: one warmup and three measured passes at each thread count, medians taken. For comparison the author used published Windows results. StorageReview tested a 128 GB HP OmniBook Ultra 16 with the same 20-core N1X on native Windows ARM64 binaries. Single-thread is basically a tie; at all 20 threads the Linux setup is about 5% ahead on compression and 3% ahead on decompression. The HP review does not specify its 7-Zip version or dictionary size, so the percentages compare the two laptop setups. ComputerBase tested a 64 GB ProArt P16 on Windows with 7-Zip 26.00 and no dictionary size given in its chart; its score converted to GIPS was 155.774, inside the author's three-run range of 155.759 to 157.193 GIPS (median total 157.084).

Memory. The Linux run reports 116.0 GiB as both system RAM and CUDA's total, from the same physical pool. Windows divides RAM into dedicated GPU, shared and CPU-only regions; CPU workloads cannot use the dedicated GPU region and GPU allocations cannot use the CPU-only region. The Windows NVIDIA app lets users change the dedicated reservation and reboot; Frandroid's 128 GB ProArt P16 reached 96 GiB. CUDA can go beyond that by allocating from shared RAM, subject to Windows' memory budget. With a 91 GiB dedicated reservation, Frandroid's Windows setup reported a CUDA total of 109.7 GiB including shared memory, against 116.0 GiB on the author's Linux setup, about 6.3 GiB more. The author says what matters to them is having the large pool available for CPU work too, without moving the reservation slider and rebooting between workloads.

Local inference. The author ran NVIDIA's Qwen3.8-Flash-Next-FP4-Local checkpoint through vLLM with B12X CUDA kernels in a native ARM64 container, using mixed quantization and FP8 KV cache, with thinking turned off. Linux showed 110.9 GiB of available RAM before loading. vLLM logged 68.2 GiB for model loading and allocated another 21.1 GiB to the KV cache, nearly 90 GiB on a laptop. Loading and compilation took about 16 minutes before the first request. PLE embedding tables are backed by disk and benefit from a warm page cache, other components use CPU offload, and CUDA handles inference with some of the model outside GPU memory.

The tasks were two buggy Python helpers to review, a long incident log with one failed operation to find, and a payment note to turn into JSON, each run three times after warmup against known answers. The incident task read nearly 10,000 tokens and returned the correct request, cause and next action in under 6 s; the answer was 39 tokens, which works out to 6.8 tokens/s over the whole request, and most of the wait went into processing the prompt. On code review, both the author's setup and Frandroid's Windows ProArt generate around 30 tokens/s. Frandroid used an 85 GiB dedicated reservation and a 262,144-token context limit; the author's limit was 32,768 tokens. Prompts, quants, runtimes and timing methods differ, so this compares two working configurations and does not isolate the effect of the OS.

Four code reviews sent at once finished in a median of 5.314 s, at 86.6 output tokens/s across all four requests combined (including prompt processing and response overhead); all 12 answers passed over three batches. In a ten-minute sequential run the machine finished 150 requests, 50 of each task, and every answer passed. Median response times were 4.036 s for code review, 5.921 s for the log and 2.046 s for extraction, and grew by less than 1.6% comparing the first ten and last ten repetitions of each task. All 171 measured responses passed the checks, from three prompts repeated with deterministic decoding. The author kept every answer and raw event stream and checked them against the summaries.

Key facts

  • A self-described Arch Linux package maintainer built a bootable Arch Linux ARM setup with patches and an extended Archinstall 4.5 for the 128 GB ASUS ProArt P16 H7607BA-SE033W, whose official support is Windows-only.
  • In 7-Zip on the 20-core N1X, single-thread is basically a tie with a Windows HP result; at 20 threads Linux is about 5% ahead on compression and 3% on decompression. The author's median total was 157.084 GIPS against ComputerBase's Windows 155.774.
  • Linux reports one 116.0 GiB pool as both system RAM and CUDA total; Frandroid's Windows setup reported a CUDA total of 109.7 GiB with a 91 GiB dedicated reservation, about 6.3 GiB less.
  • Qwen3.8-Flash-Next-FP4-Local on vLLM took about 16 minutes to load, used 68.2 GiB for the model and 21.1 GiB for KV cache, and generated around 30 tokens/s on code review, like Frandroid's Windows run.
  • All 171 measured responses passed checks, including 150 requests in a ten-minute run where median response times grew by less than 1.6%.

Why it matters

The laptop's headline feature is a large memory pool the GPU can reach, and its official support is Windows-only. This post shows a working Linux alternative on the 128 GB configuration, with one 116.0 GiB pool visible to both the OS and CUDA. On Windows the RAM is split into dedicated GPU, shared and CPU-only regions, and changing the dedicated reservation means moving a slider in the NVIDIA app and rebooting. The author's point is that the large pool is usable for CPU work too, without that reboot between workloads.

Who it affects

Mainly owners or prospective buyers of the 128 GB ASUS ProArt P16 H7607BA-SE033W who would rather not run Windows, and people who want to run open-weight models, quantisation or fine-tuning locally on a laptop. Arch users interested in ARM hardware are the other audience. The repo targets this specific model; the author's unit runs firmware H7607BA.300.

How to use it

The author published a bootable USB setup and an extension of upstream Archinstall 4.5 that installs the hardware support, along with build scripts and patches. The repo includes steps to dump your own ACPI tables and extract the speaker firmware from ASUS's driver package locally. The installer holds the kernel, NVIDIA, power-management and firmware packages with IgnorePkg, while ordinary packages keep updating from Arch Linux ARM. For the model test the author used NVIDIA's Qwen3.8-Flash-Next-FP4-Local checkpoint through vLLM with B12X CUDA kernels in a native ARM64 container, mixed quantization and FP8 KV cache.

How solid is it

The numbers are the author's own runs: three measured passes per thread count in 7-Zip 26.04 with a 32 MiB dictionary, and 171 measured inference responses checked against known answers, with every answer and raw event stream kept. The ComputerBase Windows score sits inside the author's three-run range of 155.759 to 157.193 GIPS. The Windows comparisons come from other reviewers' published results, not from the author running Windows on the same unit. The author is a single individual with a verifiable role (Arch staff package maintainer, by their own statement), and build inputs are hash pinned.

Risks and caveats

The author states the limits themselves. The HP review does not specify its 7-Zip version or dictionary size, so the 5% and 3% figures compare two laptop setups only. ComputerBase's machine was the 64 GB configuration on 7-Zip 26.00 with no dictionary size given. The inference comparison with Frandroid does not isolate the effect of the OS: prompts, quants, runtimes and timing methods differ, and the context limits differ too (32,768 tokens against 262,144). Loading took about 16 minutes before the first request, and part of the model sits outside GPU memory. The test set is only three prompts repeated with deterministic decoding. The setup depends on firmware and drivers obtained from the vendors and on user-extracted ACPI tables and speaker firmware.

“What I care about is having the large pool available for CPU work too, without moving the reservation slider and rebooting between workloads.”

— Author of the josie.lol post