Arch Linux ARM on the ASUS ProArt P16 RTX Spark N1X: 116 GiB Unified Memory and Local Qwen Benchmarks

An Arch Linux package maintainer has booted Arch Linux ARM on an ASUS ProArt P16 H7607BA-SE033W — the 128 GB RTX Spark N1X configuration — and reports that the OS and CUDA both see the same 116.0 GiB memory pool, that 7-Zip performance is roughly on par with Windows, and that a local Qwen3.8-Flash-Next-FP4-Local checkpoint runs at about 30.9 tokens/s through vLLM. The write-up is a working port, not a controlled OS comparison: the author states plainly that the numbers compare two working configurations rather than isolating the effect of the operating system.

The author, Josie, is on the Arch staff as a package maintainer and publishes GGUF quants on Hugging Face, with over 160,000 downloads in the past month. The motivation was simple: the laptop's official support is Windows-only, and the author does not have a Microsoft account. The self-described summary of the post is "boo hoo microsoft bad."

The hardware and the constraint

The machine is an ASUS ProArt P16 H7607BA-SE033W: 128 GB of RAM, 6,144 CUDA cores, and a 2 TB SSD. ASUS lists official support for Windows only. The author's stated reasons for avoiding Windows include privacy concessions during setup, the long wait for taskbar placement options, and in-OS advertising.

Arch is the author's preferred distribution, and the build uses Arch Linux ARM — the separate project that ports Arch packages to ARM — with hardware support layered on top. The author had already put Arch on IBM mainframes, so Arch was the starting point here as well.

What the port required

Getting a console and a working driver stack required several specific fixes. The author started from NVIDIA's kernel work for Ubuntu, then 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. The NVIDIA driver and ASUS speaker firmware were obtained from what the author calls "official places on the internet." Keyboard support needed a patched hid-asus, and audio needed its own machine driver.

The result is packaged as a bootable USB, with upstream Archinstall 4.5 extended to install the hardware support. The repository at github.com/pfeifferj/archlinuxarm-proart-p16 contains 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 machine runs firmware H7607BA.300.

Build inputs are hash pinned. The hardware packages were signed with the author's Arch Linux Package Maintainer key, and the ACPI overrides come from the laptop itself. The installer holds the kernel, NVIDIA, power-management and firmware packages with IgnorePkg, while ordinary packages keep updating from Arch Linux ARM.

The display runs at 3840 × 2400 and 120 Hz. The author uses NetworkManager, PipeWire, and rootless Podman with NVIDIA CDI.

7-Zip performance versus Windows

The CPU comparison uses native ARM64 7-Zip 26.04 with a fixed 32 MiB dictionary. The author ran one warmup and three measured passes at each thread count and took the medians.

Threads	Compression (MiB/s)	Decompression (MiB/s)
1	6.18	118.26
20	141.77	1,629.60

For the Windows comparison, the author used published results from StorageReview's test of a 128 GB HP OmniBook Ultra 16 with the same 20-core N1X, running native Windows ARM64 binaries. StorageReview reports 7-Zip ratings in GIPS, so the author divided the MIPS ratings in the raw logs by 1,000 to match. Higher is better.

7-Zip workload	ProArt, Linux (GIPS)	HP OmniBook, Windows (GIPS)	Difference
1-thread compression	7.221	7.31	−1.2%
1-thread decompression	10.779	10.87	−0.8%
20-thread compression	165.754	157.9	+5.0%
20-thread decompression	148.471	144.5	+2.7%

Single-thread performance is essentially a tie. With all 20 threads, the Linux setup is about 5% ahead on compression and 3% ahead on decompression. The author notes that the HP review does not specify its 7-Zip version or dictionary size, so these percentages compare the two laptop setups rather than isolating the OS.

A second data point comes from ComputerBase's test of a ProArt P16 with the 20-core N1X. Converted to GIPS, its Windows 7-Zip score was 155.774; the author's median total across three runs was 157.084, inside the three-run range of 155.759 to 157.193 GIPS. ComputerBase's machine was the 64 GB configuration running 7-Zip 26.00, and its chart does not give the dictionary size.

The memory split: 116.0 GiB to both the OS and CUDA

The memory configuration is the more significant difference. The Linux run reports 116.0 GiB as both system RAM and CUDA's total, drawn from the same physical pool. Windows divides the 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. The Linux setup reported 116.0 GiB — about 6.3 GiB more.

The author's stated priority is having the large pool available for CPU work as well, without moving the reservation slider and rebooting between workloads.

Running Qwen locally

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 an FP8 KV cache. Thinking was turned off for the run.

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 — nearly 90 GiB allocated to the model and KV cache on a laptop. Model 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. CUDA handles inference, with some of the model outside GPU memory.

The test 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 task ran three times after warmup, with known answers to check against.

Task	Input tokens	First token, median (s)	Complete response, median (s)	Checks passed
Python code review	208	0.316	4.008	3/3
Find the failure in a 128-record incident log	9,775	4.532	5.768	3/3
Payment-note extraction	87	0.256	2.035	3/3

The incident task read nearly 10,000 tokens and returned the correct request, cause, and next action in under 6 seconds. Its answer was only 39 tokens long, which comes to 6.8 tokens/s over the whole request. Most of the wait went into processing the prompt, so the author argues the response time is more informative than the tokens/s figure for that task.

For code review, the author estimated generation speed as (output tokens − 1) / (response time − time to first token), with both times in seconds, including stream overhead.

System	Quant and runtime	Generation (tokens/s)
ProArt P16, Linux	FP4-Local, vLLM B12X	30.9 (median of 3)
Frandroid's ProArt P16, Windows	UD-IQ4_XS, llama.cpp	29.4 and 31.4

Both ProArt setups land around 30 tokens/s. Frandroid used an 85 GiB dedicated reservation and a context limit of 262,144 tokens; the author's context limit was 32,768 tokens. The prompts, quants, runtimes, and timing methods differ, so the author explicitly frames this as a comparison of two working configurations, not an isolation of the OS effect.

Batching and sustained load

Sending four code reviews at once produced a median batch time of 5.314 seconds and 86.6 output tokens/s across all four requests combined, a rate that includes prompt processing and response overhead. All 12 answers passed over three batches.

The author then left the machine cycling through the three tasks, one request at a time, for ten minutes. It finished 150 requests — 50 of each — and every answer passed the checks. Median response times were 4.036 s for code review, 5.921 s for the log, and 2.046 s for extraction. Comparing the first ten and last ten repetitions of each task, median response times grew by less than 1.6%. In total, all 171 measured responses passed the checks; the author kept every answer and raw event stream and checked them against the summaries.

What the discussion pushed back on

Commenters raised several counterpoints to the framing of the post, most of them about cost and use case rather than the port itself.

Is a laptop the right form factor at this price?

The strongest objection was that the same silicon is available in cheaper or more convenient shapes. One commenter wrote:

"Not sure there's a strong use case for one of these $6K laptops yet, considering you can get a mini PC running AMD Ryzen 495 or 395 with 96, 128 and 192 GB of memory for similar amount of money and connect remotely from a cheaper/smaller/more battery-efficient laptop."

The same commenter noted Microsoft ships the same chip in a non-laptop form factor, argued that the "coding while flying" scenario is undermined by power bricks that trip plane power plugs in coach and by short battery life under local AI load, and suggested that better in-flight connectivity will erode the fully-offline use case. For gaming, they pointed to laptops with dedicated GPUs such as the Asus Zephyrus.

Another commenter reported getting the HP version of the 128 GB machine for $3.8K, calling it the best deal they had seen for that much RAM.

DGX Spark and pre-installed Linux alternatives

A DGX Spark owner running Ubuntu questioned the premise directly:

"Why would I get that instead of the DGX Spark? The OS makes a big difference for most developers, and the DGX Spark stack and experience is mature."

A related comment argued that several OEMs already ship RTX Spark mini PCs with NVIDIA's Linux distribution (NVIDIA DGX OS) and support them, including Asus — and that the recurring message is that there is "no value in selling pre-installed Linux devices."

Was the Microsoft account actually avoidable?

Several commenters argued the login problem has workarounds. One noted that on Windows Pro you can use Work or School Account → Join a Domain instead, then set a password and recovery questions, but that Home edition requires the account with increasingly limited alternatives. Another described a fully scripted path:

"I have a USB Key with the file and the latest copy of the 11 Pro download, and when setting up a new machine, i run a fresh install. Then once booted, i run the developer config ... No Microsoft Login, no Candy Crush, WSL installed and all the tools i need."

That commenter pointed to an autounattend.xml generator and Microsoft's WindowsDeveloperConfig repository. Others made the blunter version of the same point — that creating a Microsoft account is free and would have been quicker — and one noted that Microsoft's login flow itself is painful, citing broken redirects, looping buttons, and CAPTCHAs.

Performance skepticism and unanswered questions

One commenter questioned the inference numbers: "Only 30 tok/s on Qwen 3.8 Flash Next? These days thanks to those specialized engines out there I can get ~2x that speed on a 24 GB video card with RAM offload. Thermal limits, I assume..." They also asked how the machine performs on dense models — a question the post does not answer.

Another commenter challenged the framing of the achievement, asking what challenge was actually overcome and whether the interesting part is the arm64 work or simply a review of new hardware. A third pointed out that laptops with over 100 GiB of GPU-accessible memory have existed since Apple silicon's M3 roughly three years earlier, and noted the post does not mention Apple silicon at all. A separate commenter asked how Wayland performs on this hardware; no answer appears in the provided discussion.

Caveats on the benchmarks

The performance claims in the post are comparisons between two laptop configurations, not controlled experiments. The Windows 7-Zip figures come from third-party reviews — StorageReview's HP OmniBook Ultra 16 and ComputerBase's 64 GB ProArt P16 — and neither review specifies all relevant parameters. The HP review does not state its 7-Zip version or dictionary size; ComputerBase ran 7-Zip 26.00 but its chart omits the dictionary size. The Qwen comparison differs in quantization, runtime, context limit, prompts, and timing methodology between the Linux and Windows runs. The author states these limitations directly rather than presenting the results as an OS-to-OS benchmark.