Arch Linux Runs on RTX Spark With 116 GiB Shared Memory
A community-built installer brings local Qwen inference to one ASUS laptop, but its measurements do not establish a Linux performance advantage.
Listen
AI narration
12:40
0:00 / 12:40
AI SummaryGenerated from this article
A community-built Arch Linux ARM installer now runs on an ASUS ProArt P16 laptop with an NVIDIA RTX Spark GPU, achieving approximately 30.9 generated tokens per second running Qwen inference through vLLM. The setup accesses 116 GiB of shared memory for both CPU and CUDA workloads and required patched NVIDIA kernel modules, keyboard and audio drivers, and ACPI table overrides. Comparisons with published Windows results show similar inference speeds but differ substantially in quantization, model checkpoint, and configuration, preventing definitive operating-system performance conclusions. The port remains specific to this hardware SKU with firmware version H7607BA.300, and the community release leaves ASUS and NVIDIA's official Windows-only support position unchanged.
An ASUS ProArt P16 running Arch Linux ARM reports 116.0 GiB as both system RAM and CUDA’s total memory, according to Arch Linux package maintainer Josephine Pfeiffer. Both figures describe the same physical pool. On that machine, Pfeiffer also ran a Qwen model at roughly 30.9 generated tokens per second on a short code-review task.
The implementation report, published October 19, 2026, includes build scripts, patches, an installer adapter, and pinned inputs. Beyond demonstrating that Linux can boot, it gives technical readers a documented starting point for reproducing the setup.
This is an independent community port, with no announcement of Linux support from ASUS or NVIDIA. Its scope is specific: one Windows-supported RTX Spark laptop now has a published path to an Arch Linux ARM installation that can run substantial local AI workloads.
The Working Configuration Is Specific
Pfeiffer’s machine is the ASUS ProArt P16 H7607BA-SE033W, configured with 128 GB of RAM, a 2 TB SSD, and an NVIDIA RTX Spark N1X with a 20-core CPU and 6,144 CUDA cores. It runs firmware H7607BA.300.
The ASUS specifications list multiple processor, memory, and display configurations within the H7607 family. A working installation on this SKU does not establish compatibility across every ProArt P16 or other RTX Spark laptop.
Pfeiffer reports a working display at 3840 × 2400 and 120 Hz, along with keyboard and audio support. The setup uses NetworkManager, PipeWire, and rootless Podman with NVIDIA Container Device Interface support. The reported tests ran with kernel 7.0.0-1022-nvidia and NVIDIA driver 615.78.08.
ASUS lists Windows 11 as the operating system and says the product has only been tested for compatibility with Windows 11. Its specifications also warn that some features depend on OS support and driver availability. The community release leaves that official support position unchanged.
The installation uses Arch Linux ARM, the separate project that ports Arch packages to ARM, with additional hardware support layered on top.
The Installer Adds More Than an NVIDIA Driver
The public implementation repository packages a patched NVIDIA kernel, NVIDIA display modules, keyboard and audio drivers, ACPI table overrides, and an adapter for upstream Archinstall.
Work with Zeniteq
Let’s work together
We’re open to thoughtful collaborations with teams building in AI. Explore the ways we can work together.
Pfeiffer built on NVIDIA’s Ubuntu kernel work, then addressed ACPI override allocation and framebuffer mapping needed to obtain a console. Keyboard support required a patched hid-asus driver; audio required a separate machine driver. Getting this platform working required more than installing a graphics driver on an otherwise supported laptop.
The installer extends Archinstall 4.5 while leaving ordinary installation tasks to existing components. Partitioning, package installation, accounts, and services remain with Arch Linux ARM, pacman, mkinitcpio, systemd-boot, and Archinstall.
Several measures help make the setup reproducible:
Build inputs are hash-pinned, making the intended component versions identifiable.
The hardware packages are signed with Pfeiffer’s Arch Linux Package Maintainer key.
Documentation explains how to dump the laptop’s ACPI tables and extract speaker firmware locally from ASUS’s driver package.
The repository says the ACPI tables and Cirrus tuning firmware are not redistributed. Its own scripts and configuration use the MIT license, while third-party components retain their respective licenses. The MIT license does not extend to the entire driver and firmware stack.
The installer also places kernel, NVIDIA, power-management, and firmware packages in IgnorePkg. Ordinary Arch Linux ARM packages continue updating, while those hardware-specific components stay fixed. This helps preserve the tested combination. Users must handle updates to the held components as a separate maintenance task; the whole system does not follow normal rolling updates.
The 116 GiB Result Describes Shared Capacity
The memory result is the most consequential part of the report for local-model experimentation. Linux and CUDA both report 116.0 GiB from the same physical pool, giving CPU workloads access to the large pool without a separate dedicated-GPU reservation.
That does not mean 116 GiB is simultaneously free for a model. Before loading Qwen, Pfeiffer’s Linux installation reported 110.9 GiB available. The operating system, applications, model weights, caches, and other allocations still compete for physical memory.
NVIDIA’s unified-memory documentation explains that RTX Spark’s CPU and integrated GPU share physical memory. Under Windows, that memory is exposed through three logical regions: dedicated GPU memory, shared system memory, and CPU-only system memory.
System DRAM backs the dedicated region; there is no separate graphics-card VRAM. CPU workloads cannot use that reserved region, while GPU allocations cannot use the CPU-only region.
A dedicated-memory figure therefore does not describe the complete CUDA-accessible capacity under Windows. CUDA can also allocate from shared system memory, subject to Windows’ memory budget. Treating a Windows dedicated-GPU reservation as a hard ceiling would exaggerate the Linux difference.
The practical attraction of Pfeiffer’s setup is allocation flexibility: the large pool remains available for CPU work without adjusting a dedicated-memory reservation and rebooting between workloads. Linux does not create additional physical memory.
Qwen Runs With Offload and a Warm Cache
For inference, Pfeiffer used NVIDIA’s Qwen3.8-Flash-Next-FP4-Local checkpoint through vLLM with B12X CUDA kernels in a native ARM64 container. The configuration used mixed quantization and an FP8 KV cache, with thinking disabled.
The published workload measurements report 68.2 GiB for model loading and 21.1 GiB for KV cache, nearly 90 GiB combined. Initial loading and compilation took about 16 minutes before the first request; the reported request timings begin after warmup.
Some model components remained outside GPU memory. PLE embedding tables were disk-backed and benefited from a warm page cache, while other components used CPU offload. CUDA handled inference.
Pfeiffer ran each of three tasks three times after warmup:
All three runs of each task passed the author’s checks.
The roughly 30.9 generated tokens per second figure comes from the code-review task. Pfeiffer estimated generation speed using output tokens after the first token and elapsed time after the first-token arrival, including streaming overhead.
Whole-request throughput is a different metric. The incident-log task returned only 39 tokens after processing nearly 10,000 input tokens. Its complete response took under six seconds, but dividing output tokens by the entire request duration yields just 6.8 tokens per second. Prompt processing accounts for much of the wait.
Four concurrent code reviews produced an aggregate 86.6 output tokens per second, including prompt processing and response overhead. That measures combined throughput across requests, not the generation speed an individual user would receive.
A subsequent ten-minute sequential run completed 150 requests. Across all reported tests, 171 measured responses passed the checks. That is encouraging evidence for this workload, though the tests repeated three prompts with deterministic decoding. They do not establish broad model accuracy or long-term system reliability.
The Windows Results Are Context, Not an OS Verdict
Pfeiffer compares the Linux results with published Windows measurements, but explicitly identifies differences that prevent a controlled operating-system comparison.
For Qwen coding tasks, the post cites Frandroid’s Windows ProArt P16 results of 29.4 and 31.4 tokens per second. Those sit near the Linux code-review result of 30.9 tokens per second, despite substantial configuration differences.
The Windows measurements used UD-IQ4_XS quantization and llama.cpp; Linux used the FP4-Local checkpoint and vLLM. The Windows context limit was 262,144 tokens, versus 32,768 for the Linux setup. Prompts, memory reservations, and timing methods also differed.
Both configurations demonstrated usable inference around that generation rate. The results do not isolate an operating-system effect.
The CPU comparisons carry similar limits. Pfeiffer’s native ARM64 7-Zip 26.04 tests used a fixed 32 MiB dictionary, one warmup, and three measured passes per thread count, with the laptop plugged in and its performance profile selected. Against published Windows results for an HP OmniBook Ultra 16 with the same 20-core N1X, the Linux setup was about 5% ahead in multithreaded compression and 2.7% ahead in decompression. The Windows review did not specify its 7-Zip version or dictionary size, and the laptop itself differed.
For prospective experimenters, the implementation offers stronger evidence than the comparative percentages. The repository documents the firmware-specific preparation, native AArch64 image build, and installation path, and directs readers to review its limits and known issues.
Technically capable owners of the matching hardware have a starting point, with patches, build inputs, and a measured workload available to inspect and reproduce. This release offers neither a general Linux compatibility guarantee nor a turnkey model benchmark. Broader hardware validation and matched cross-OS testing would answer questions it leaves open.
