Linux Sees 116 GiB of CUDA Memory on an RTX Spark Laptop, 6.3 GiB More Than Windows

A developer writing at josie.lol put Arch Linux ARM on an ASUS ProArt P16 with Nvidia's RTX Spark chip on Oct. 19 and reported that Linux exposes 116.0 GiB of CUDA-visible memory on the 128 GB model. A Windows ProArt of the same size reached 109.7 GiB in a Frandroid test the post cites, a gap of 6.3 GiB that comes from how each operating system carves up one shared pool.

The write-up covers the ProArt P16 H7607BA-SE033W, firmware H7607BA.300, with the 20-core N1X processor and a GPU of 6,144 CUDA cores. ASUS lists Windows only for the machine, so everything below is a community port, not a supported configuration.

Why the memory numbers differ

RTX Spark is a unified-memory design: the CPU and the integrated GPU share one physical pool. Nvidia's porting guide says Windows divides that pool into three regions. A dedicated carve-out is reserved for the GPU and reported as video memory. Shared system memory is reachable by both processors, and its size is the post-carve-out capacity minus 16 GB, clamped between 50 and 80 percent of that capacity. Whatever is left is CPU-only and cannot back GPU allocations.

Linux has no carve-out. The post reports 116.0 GiB as both system RAM and the CUDA total, with 110.9 GiB available before any model loaded. The number that matters is not the 6.3 GiB gap but the fact that a single allocation can now span almost all of the 128 GB, where Windows caps it by region.

1. Linux (Arch Linux ARM)116 GiB
2. Windows109.7 GiB

Source: josie.lol write-up, Oct. 19, 2026 (Windows figure as cited there from Frandroid, with a 91 GiB reservation)

What worked, and what the author had to patch

The machine runs kernel 7.0.0-1022-nvidia with Nvidia driver 615.78.08, installed through Archinstall 4.5 extended for the hardware. For comparison, Linux 7.3 has already shipped upstream; this laptop depends on a vendor kernel several releases behind it.

Console, display at 3840 by 2400 and 120 Hz, the GPU and CUDA, networking, audio and keyboard work. Getting there took a fix for ACPI override allocation and framebuffer mapping, a patched hid-asus driver for the keyboard, and a separate machine driver plus ASUS speaker firmware for audio. The post says nothing about suspend or battery life, which on a laptop is the part that decides whether the port is usable.

CPU and local-model results

The author ran 7-Zip 26.04 with a 32 MiB dictionary, taking the median of three runs after a warm-up, and compared it with StorageReview's Windows ARM64 numbers for the HP OmniBook Ultra 16, a different laptop with the same chip. The post notes that the HP review does not state its 7-Zip version or dictionary size.

Workload	ProArt, Linux (GIPS)	HP, 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%

For language models, the scale here is far above the 4-billion-parameter Qwen3-4B-Deslop run on an M2 MacBook Air that The Terminal covered. The author served Nvidia's Qwen3.8-Flash-Next-FP4-Local checkpoint through vLLM, with a 32,768-token context limit, 68.2 GiB for weights and 21.1 GiB for the KV cache. Startup took about 16 minutes for loading and compilation. A code-review prompt generated 30.9 tokens a second; the Windows ProArt in the Frandroid test reached 29.4 and 31.4 tokens a second on llama.cpp with a different quantisation, so the post itself says the comparison cannot isolate the operating system.

The 16-minute start-up is a cost paid once per boot of the server, but it also means this setup suits a model left resident for a working day, not one swapped between tasks. The post does not test swapping.

Over a ten-minute run of 150 requests, median response times grew by less than 1.6 percent, and all 171 measured responses passed their checks. A 9,775-token incident-log prompt returned its first token in 4.532 seconds, roughly 2,160 input tokens a second by The Terminal's arithmetic.

The bandwidth ceiling

StorageReview lists the chip's memory as LPDDR5X-9400 on a 256-bit interface, and measured STREAM Triad at about 120 to 122 GB/s on N1X systems. If decoding were limited by bandwidth alone, 122 GB/s divided by 30.9 tokens a second allows at most about 3.9 GB read per token. That mixes a Windows-measured bandwidth with a Linux-measured speed, so treat it as a ceiling on the argument, not a finding. Capacity is the cheaper variable to read off a price list: the soldered 128 GB HP configuration costs $6,229.99 on HP's configurator as of Oct. 14, against $3,199.99 for 32 GB.

What would change this read is a suspend and battery measurement on Linux, or the same model, runtime and quantisation timed on both operating systems on one machine. The author published scripts, patches and the steps for dumping a laptop's own ACPI tables, so a second owner can try to reproduce the memory and 7-Zip numbers.