Linux installeren op mijn RTX Spark-laptop omdat ik geen Microsoft-account heb

Samenvatting

Kortom: Microsoft is slecht. Arch Linux werkt, blijft in 7-Zip concurrerend met Windows, en rapporteert dezelfde 116,0 GiB geheugenpool aan het besturingssysteem en CUDA. Deze configuratie is bedoeld voor de ASUS ProArt P16 H7607BA-SE033W: de configuratie met 128 GB RAM, 6.144 CUDA-cores en een 2 TB SSD.

---

Motivatie en installatie

Toen er geruchten gingen over een laptop waarbij de GPU toegang had tot meer dan 100 GiB RAM, begon ik na te denken over alles wat ik erop zou kunnen bouwen en alle optimalisaties waar ik veel tijd aan zou kunnen besteden. Ik ben een groot voorstander van open-weight modellen. De mogelijkheid om zaken lokaal te draaien en te experimenteren met RL, kwantisering en fine-tuning op een laptop zou geweldig zijn. Ik publiceer al mijn eigen GGUF-kwantiseringen op Hugging Face, met meer dan 160.000 downloads in de afgelopen maand.

Ik was dan ook minder blij toen ik ontdekte dat er alleen officiële ondersteuning is voor Windows. Er zijn talloze redenen om een hekel te hebben aan Windows. Mijn redenen zijn onder andere de privacy-concessies tijdens de installatie, de jaren van wachten tot Microsoft mensen weer toestond de taakbalk aan de zijkant van het scherm te plaatsen, en de advertenties. Ik kan hier eeuwig over doorgaan, dus laat ik bij het onderwerp blijven.

Arch is mijn voorkeursdistributie en ik maak deel uit van het Arch-staf als pakketbeheerder. Omdat ik het al op IBM-mainframes heb geïnstalleerd, was dit logischerwijs mijn startpunt. Deze build maakt gebruik van Arch Linux ARM, het aparte project dat Arch-pakketten poort naar ARM, waarbij de hardwareondersteuning bovenop is toegevoegd.

NVIDIA heeft kernelwerk verricht voor Ubuntu, wat mij een startpunt gaf. Ik heb dit geïntegreerd, de ACPI-override allocatie en framebuffer-mapping hersteld die nodig zijn voor een console, en de ACPI-overrides uitgewerkt op basis van de tabellen van de laptop zelf (bedankt astra <3). De NVIDIA-driver en de ASUS-speaker-firmware zijn afkomstig van officiële bronnen op internet. Voor de toetsenbordondersteuning was een gepatchte hid-asus nodig, en voor de audio was een eigen machine-driver vereist.

Ik heb dit samengevoegd in een opstartbare USB-stick en archinstall 4.5 uitgebreid om de hardwareondersteuning te installeren. De repository bevat de build-scripts en patches, inclusief de stappen om je eigen ACPI-tabellen te dumpen en de speaker-firmware lokaal uit het driverpakket van ASUS te extraheren. Mijn systeem draait firmware H7607BA.300.

De build-inputs zijn hash pinned. De hardwarepakketten die ik in het weekend heb samengesteld, zijn ondertekend met mijn Arch Linux Package Maintainer-sleutel, en de ACPI-overrides komen van de laptop zelf.

Het scherm draait op 3840 × 2400 en 120 Hz. Ik gebruik NetworkManager, PipeWire en rootless Podman met NVIDIA CDI. De installer houdt de kernel, NVIDIA, energiebeheer- en firmwarepakketten vast met IgnorePkg, terwijl gewone pakketten blijven updaten via Arch Linux ARM.

CPU-prestaties

Op 19 oktober heb ik de testsuite uitgevoerd op native Arch Linux ARM, met kernel 7.0.0-1022-nvidia en NVIDIA-driver 615.78.08. De laptop was aangesloten op de stroom met het prestatieprofiel geselecteerd. Voor de CPU-vergelijking heb ik gepubliceerde Windows-resultaten gebruikt.

De CPU-test is native ARM64 7-Zip 26.04 met een vast dictionary van 32 MiB. Ik heb één warming-up en drie gemeten runs uitgevoerd bij elk aantal threads, waarna ik de medianen heb genomen:

Threads	Compressie (MiB/s)	Decompressie (MiB/s)
1	6,18	118,26
20	141,77	1.629,60

StorageReview testte een 128 GB HP OmniBook Ultra 16 met dezelfde 20-core N1X, draaiend op native Windows ARM64-binaries. Zij rapporteren 7-Zip scores in GIPS; ik heb daarom de MIPS-scores uit mijn ruwe logs gedeeld door 1.000 om deze vergelijkbaar te maken. Hoger is beter.

7-Zip workload

Taak	Mijn ProArt, Linux (GIPS)	HP OmniBook, Windows (GIPS)	Verschil
1-thread compressie	7,221	7,31	−1,2%
1-thread decompressie	10,779	10,87	−0,8%
20-thread compressie	165,754	157,9	+5,0%
20-thread decompressie	148,471	144,5	+2,7%

Single-thread is in feite een gelijkspel. Met alle 20 threads loopt mijn Linux-setup ongeveer 5% voor op compressie en 3% voor op decompressie. De HP-review specificeert niet welke 7-Zip versie of dictionary-grootte is gebruikt, dus deze percentages vergelijken de twee laptop-setups.

ComputerBase testte ook een ProArt P16 met de 20-core N1X. Omgezet naar GIPS was de Windows 7-Zip score 155,774; de mediane totaalscore van mijn drie runs was 157,084. Hun resultaat valt binnen mijn bereik van 155,759 tot 157,193 GIPS. Hun machine was de 64 GB-configuratie en draaide 7-Zip 26.00, waarbij de grafiek de dictionary-grootte niet vermeldt.

De geheugenverdeling

Het geheugen is het meest indrukwekkende onderdeel. Mijn Linux-run rapporteert 116,0 GiB als zowel systeem-RAM als CUDA-totaal, afkomstig uit dezelfde fysieke pool. Windows verdeelt het RAM in een toegewezen GPU-regio, een gedeelde regio en een CPU-only regio. CPU-workloads kunnen de toegewezen GPU-regio niet gebruiken, en GPU-allocaties kunnen de CPU-only regio niet gebruiken.

Via de Windows NVIDIA-app kun je de toegewezen reservering wijzigen en opnieuw opstarten; de 128 GB ProArt P16 van Frandroid bereikte hiermee 96 GiB. CUDA kan verder gaan door te alloceren uit het gedeelde RAM, afhankelijk van het geheugenbudget van Windows.

Met een toegewezen reservering van 91 GiB rapporteerde de Windows-setup van Frandroid een CUDA-totaal van 109,7 GiB, inclusief gedeeld geheugen. Mijn Linux-setup rapporteerde 116,0 GiB, ongeveer 6,3 GiB meer. Wat mij echt interesseert, is dat de grote pool ook beschikbaar is voor CPU-werk, zonder dat ik de reserveringsschuif moet verplaatsen en moet herstarten tussen verschillende workloads.

Qwen lokaal draaien

Ik heb het NVIDIA Qwen3.8-Flash-Next-FP4-Local checkpoint gedraaid via vLLM met B12X CUDA-kernels in een native ARM64-container, gebruikmakend van mixed quantization en FP8 KV-cache. Ik heb voor deze run de "thinking"-functie uitgeschakeld.

Voordat het model werd geladen, rapporteerde Linux 110,9 GiB beschikbaar RAM. vLLM logde 68,2 GiB voor het laden van het model en alloceerde nog eens 21,1 GiB aan de KV-cache. Dat is bijna 90 GiB gealloceerd aan het model en de KV-cache op een laptop.

Het laden en compileren van het model duurde ongeveer 16 minuten voordat het eerste verzoek kon worden verwerkt. De onderstaande tijden starten na de warming-up. PLE-embeddingstabellen worden ondersteund door de schijf en profiteren van een warme page-cache; andere componenten gebruiken CPU-offload. CUDA handelt de inferentie af, waarbij een deel van het model zich buiten het GPU-geheugen bevindt.

Ik heb Qwen drie taken gegeven: twee foutieve Python-helpers reviewen, een lang incidentlogboek doorzoeken naar één mislukte operatie, en een betalingsnotitie omzetten naar JSON. Elke taak werd drie keer uitgevoerd na de warming-up, met bekende antwoorden als controle.

Taak	Input tokens	Eerste token, mediaan (s)	Volledige respons, mediaan (s)	Checks geslaagd
Python code review	208	0,316	4,008	3/3
Fout vinden in incidentlog (128 records)	9.775	4,532	5,768	3/3
Extractie betalingsnotitie	87	0,256	2,035	3/3

De incident-taak las bijna 10.000 tokens en gaf het correcte verzoek, de oorzaak en de volgende actie terug in minder dan 6 seconden. Het antwoord was slechts 39 tokens lang, wat neerkomt op 6,8 tokens/s over het hele verzoek. Het grootste deel van de wachttijd zat in het verwerken van de prompt, dus voor deze taak zegt de responstijd meer dan het aantal tokens/s.

Voor de code-review heb ik de generatiesnelheid geschat als (output tokens − 1) / (responstijd − tijd tot eerste token), waarbij beide tijden in seconden zijn. Dit is inclusief stream-overhead. Frandroid voerde Qwen3.8-Flash-Next coding-taken uit op zijn Windows ProArt:

Systeem	Quant en runtime	Generatie (tokens/s)
Mijn ProArt P16, Linux	FP4-Local, vLLM B12X	30,9 (mediaan van 3)
Frandroid's ProArt P16, Windows	UD-IQ4_XS, llama.cpp	29,4 en 31,4

Beide ProArt-setups zitten rond de 30 tokens/s. Voor inferentie gebruikte Frandroid een toegewezen reservering van 85 GiB en een contextlimiet van 262.144 tokens; mijn contextlimiet was 32.768 tokens. De prompts, quants, runtimes en timingmethoden verschillen. Dit vergelijkt twee werkende configuraties; het isoleert niet het effect van het besturingssysteem.

Daarnaast heb ik vier code-reviews tegelijk verzonden. De mediane batch was klaar in 5,314 s, wat resulteerde in 86,6 output tokens/s over alle vier de verzoeken gecombineerd. Deze snelheid is inclusief prompt-verwerking en respons-overhead. Alle 12 antwoorden waren correct over drie batches.

Ten slotte heb ik het systeem tien minuten lang laten cyclen door de drie taken, één verzoek per keer. Het voltooide 150 verzoeken (50 van elk), en elk antwoord was correct. De mediane responstijden waren 4,036 s voor code-review, 5,921 s voor het logboek en 2,046 s voor de extractie. Bij het vergelijken van de eerste tien en de laatste tien herhalingen van elke taak, groeiden de mediane responstijden met minder dan 1,6%.

Alle 171 gemeten responsen waren correct. Dit betreft drie prompts herhaald met deterministische decoding; de code-review check verifieert de regressie-outputs. Ik heb elk antwoord en elke ruwe event-stream bewaard en gecontroleerd aan de hand van de samenvattingen.