Arch Linux maintainer gets full CUDA and 116 GiB unified memory working on ASUS ProArt RTX laptop

A hands-on account from an Arch Linux package maintainer, which surfaced on the Hacker News front page, walks through getting a fully working Arch installation onto the ASUS ProArt P16 H7607BA — an RTX Spark-class laptop with 128 GB of RAM, 6,144 CUDA cores, a 2 TB SSD and a 20-core N1X processor. The stated motivation, per the post on josie.lol, was simple: the author doesn't have a Microsoft account and doesn't want one, citing Windows setup privacy concessions and built-in advertising among other frustrations.

How the port works

The author — who also publishes GGUF quantisations on Hugging Face — started from Arch Linux ARM, the separate project that ports Arch packages to ARM, and layered hardware support on top. NVIDIA's kernel work for Ubuntu provided a base; from there the author fixed the ACPI override allocation and framebuffer mapping needed to get a working console, and derived the ACPI overrides from the laptop's own firmware tables.

Keyboard input required a patched hid-asus driver, audio needed a purpose-built machine driver, and the ASUS speaker firmware was extracted locally from ASUS's own driver package. Everything was assembled into a bootable USB image, and Archinstall 4.5 was extended to install the hardware support automatically. Build inputs are hash-pinned, the hardware packages are signed with the author's Arch Linux Package Maintainer key, and the ACPI overrides come from the laptop itself.

The finished system drives the 3840 x 2400 display at 120 Hz with NetworkManager, PipeWire and rootless Podman with NVIDIA CDI. The kernel, NVIDIA driver, power-management and firmware packages are held back with IgnorePkg while ordinary packages keep updating from Arch Linux ARM.

CPU performance roughly on par with Windows

Benchmarks were run on October 19 with kernel 7.0.0-1022-nvidia and NVIDIA driver 615.78.08, plugged in on the performance profile, using native ARM64 7-Zip 26.04 with a fixed 32 MiB dictionary — one warmup and three measured passes per thread count, medians reported.

Against StorageReview's numbers for an HP OmniBook Ultra 16 with the same 20-core N1X running Windows, single-thread results were effectively a tie, while the Linux setup came out about 5% ahead on compression and 3% ahead on decompression across all 20 threads. The author notes StorageReview didn't specify its 7-Zip version or dictionary size, so this compares two laptop setups rather than the operating systems in isolation.

ComputerBase's Windows-based ProArt P16, converted to GIPS, scored 155.774; the author's median of three runs was 157.084, within a run range of 155.759 to 157.193 — though that machine had the 64 GB configuration and ran 7-Zip 26.00, with no dictionary size given.

One memory pool instead of three

The bigger difference is memory. Under Linux, both the OS and CUDA see 116.0 GiB from the same physical pool. Windows instead divides RAM into dedicated GPU, shared and CPU-only regions, where CPU workloads can't touch the dedicated region and GPU allocations can't use the CPU-only one. Frandroid's 128 GB ProArt, with a 91 GiB dedicated reservation, reported a CUDA total of 109.7 GiB including shared memory — about 6.3 GiB less than Linux — and adjusting the reservation requires a reboot. On Linux the full pool stays available to CPU work too, with no slider and no restarts between workloads.

Local Qwen 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 quantisation and an FP8 KV cache, with thinking disabled. Model loading took 68.2 GiB and the KV cache another 21.1 GiB — nearly 90 GiB committed on a laptop — after roughly 16 minutes of loading and compilation before the first request.

An incident-log task with almost 10,000 input tokens returned the correct request, cause and next action in under 6 seconds, with prompt processing dominating the wait. Code-review generation ran around 30 tokens/s, comparable to Frandroid's Windows run on the same model, though the prompts, quants, runtimes, context limits (262,144 tokens there versus 32,768 here) and timing methods all differed, so it compares two working setups rather than isolating the OS. A batch of four code reviews finished in a median 5.314 s at 86.6 aggregate output tokens/s. A ten-minute soak completed 150 requests — 50 of each task — with every answer passing validation, median response times of 4.036 s for code review, 5.921 s for the log task and 2.046 s for extraction, and less than 1.6% drift between the first and last repetitions. All 171 measured responses passed their checks.

Why it matters

RTX Spark-class laptops are pitched as portable local-AI machines, but official support is Windows-only, and Windows setup effectively pushes users toward a Microsoft account — the exact friction that prompted this project. The port shows the hardware is fully usable from Linux with competitive CPU performance and a memory model arguably better suited to local model work, since one unified pool removes the reboot-between-workloads tax of Windows' GPU memory reservation. Because the patches are signed, hash-pinned and derived from the device's own tables, it offers a reproducible path for developers who want a Linux-only workflow on this class of machine.