The Spectrum Dispatch News

technology

Linux Runs on ASUS ProArt P16 Laptop with Full GPU Memory Access

An Arch Linux ARM build matches Windows CPU performance and reports the same 116 GiB memory pool to CUDA, allowing large local model workloads on a single laptop.

Linux Runs on ASUS ProArt P16 Laptop with Full GPU Memory Access

The author installed Arch Linux ARM on an ASUS ProArt P16 H7607BA-SE033W laptop, which features 128 GB of RAM, a GPU with 6,144 CUDA cores, a 2 TB SSD and a 3840×2400 display at 120 Hz. The build uses kernel 7.0.0-1022-nvidia and NVIDIA driver 615.78.08, with custom ACPI overrides, a patched hid-asus for keyboard support and a dedicated machine driver for audio. A bootable USB was created and the installer extended upstream Archinstall 4.5 to include the hardware support, with all build inputs hash‑pinned and signed by the author’s Arch Linux Package Maintainer key.

Linux Runs on ASUS ProArt P16 Laptop with Full GPU Memory Access

CPU performance was measured using native ARM64 7‑Zip 26.04 with a 32 MiB dictionary. One warm‑up and three measured passes were run at each thread count, taking the median. Results show: 1‑thread compression 6.18 MiB/s (Linux) vs 7.31 GIPS on a Windows HP OmniBook Ultra 16 (‑1.2 %); 1‑thread decompression 118.26 MiB/s vs 10.87 GIPS (‑0.8 %); 20‑thread compression 141.77 MiB/s vs 157.9 GIPS (+5.0 %); 20‑thread decompression 1,629.60 MiB/s vs 144.5 GIPS (+2.7 %). The author notes that single‑thread performance is essentially tied, while the Linux setup is about 5 % ahead on compression and 3 % ahead on decompression when all 20 threads are used.

Memory reporting differs between the two operating systems. Under Linux, the OS and CUDA both see 116.0 GiB of memory from the same physical pool. Windows divides RAM into dedicated GPU, shared and CPU‑only regions, preventing CPU workloads from accessing the dedicated GPU region without changing a reservation and rebooting. With a 91 GiB dedicated reservation, a Windows setup reported a CUDA total of 109.7 GiB (including shared memory), whereas the Linux setup reported 116.0 GiB, about 6.3 GiB more.

To test large model inference, the author ran NVIDIA’s Qwen3.8‑Flash‑Next‑FP4‑Local checkpoint through vLLM with B12X CUDA kernels in a native ARM64 container. Before loading the model, Linux reported 110.9 GiB of available RAM. vLLM logged 68.2 GiB for model loading and allocated another 21.1 GiB to the KV cache, totalling nearly 90 GiB used for the model and cache. Model loading and compilation took about 16 minutes before the first request. After warmup, median timings were: Python code review – first token 0.316 s, complete response 4.008 s (3/3 checks passed); failure search in a 128‑record incident log – first token 4.532 s, complete response 5.768 s (3/3 checks passed); payment‑note extraction – first token 0.256 s, complete response 2.035 s (3/3 checks passed). The incident task processed nearly 10,000 input tokens and returned a 39‑token answer, corresponding to roughly 6.8 tokens per second over the whole request. Generation speed for the code‑review task was estimated at 30.9 tokens per second (median of three runs).

All performance figures are drawn directly from the author’s benchmarks and logs as described in the source blog post.

Key facts

  • Model: ASUS ProArt P16 H7607BA-SE033W
  • RAM: 128 GB
  • GPU CUDA cores: 6,144
  • Storage: 2 TB SSD
  • Display: 3840×2400 @ 120 Hz
  • Linux kernel: 7.0.0-1022-nvidia
  • NVIDIA driver: 615.78.08
  • 7‑Zip 20‑thread compression: Linux 141.77 MiB/s vs Windows 157.9 GIPS (+5.0 %)
  • Memory reported to CUDA: Linux 116.0 GiB, Windows with 91 GiB reservation 109.7 GiB
  • Qwen3.8‑Flash‑Next‑FP4‑Local inference: model load 68.2 GiB, KV cache 21.1 GiB, available RAM 110.9 GiB
  • Code‑review generation speed: 30.9 tokens/s

Sources

← All posts