Nvidia took the chip from the DGX Spark, put it in a Windows laptop, and called it the RTX Spark. On paper, it’s the domestic AI laptop I’ve wanted for years: up to 128GB of unified memory, CUDA, and a chip that already existed under a different name. I spent the last week running models on the 64GB Lenovo Yoga 9n 2-in-1, as well as gaming and other tasks.
It’s a seriously capable machine. But some things only became apparent when I started loading the models and hitting the memory settings, and none of them were obvious on the spec sheet. You certainly don’t need an expensive GPU to run a local LLM, but if you’re spending $3,000 or more on one of these, most of them will be figured out the moment you hit checkout.
Your memory selection determines which models you can run
Forever, because the RAM is soldered
The RTX Spark’s memory is soldered to the board, so whatever you choose at checkout is what you live with. The chip also comes in two tiers, the cheapest, with an 18-core CPU and 5120 GPU cores, going up to 64GB, while the full 20-core version goes up to 128GB.
The laptop is as important as the chip. The My Yoga 9n 2-in-1 has a full 20-core, 64GB, 1TB chip for about $3,750. Microsoft’s Surface Laptop Ultra with the same chip, memory and storage costs $4,300, but offers 128GB for $5,900. Sure, the Yoga is cheaper and takes a stylus to its screen and touchpad, which the Surface doesn’t, but it can never exceed 64GB.
This ceiling is true to the models. On my unit, the largest total of GPU memory reported in Windows was 55.4GB, with 48GB partitioned (48GB dedicated plus 7.4GB shared), which is enough for a 32GB model but nowhere near the nearly 65GB that gpt-oss-120b needs for its weights alone. Buy the models you want in a couple of years, not the ones you use today.
The memory partitioning in the Nvidia application is not the limit it appears
Maybe for gaming use, but local LLMs work differently
Nvidia’s implementation lets you split the RTX Spark’s unified memory between the GPU and CPU, the obvious assumption being that the GPU number is your VRAM. It’s not quite like that. With the GPU split at 16GB, Ollama loaded a 28GB Qwen3 32B and reported 100% GPU, and the task manager showed 15.8GB in dedicated GPU memory plus 12.9GB in shared memory.
This is in line with Nvidia porting guidewhich describes a dedicated chip as well as shared system memory that the GPU can also use. So I moved the partition to 48GB, rebooted, and ran the same prompt again.
|
16GB partitioned GPU |
48GB partitioned GPU |
|
|---|---|---|
|
Dedicated GPU memory used |
15.8 GB out of 16 GB |
29.8 GB out of 48 GB |
|
Shared GPU memory is used |
12.9 GB 30.8 GB |
0.7 GB out of 7.4 GB |
|
Windows memory is in use |
26.0 GB out of 46.8 GB |
12.7 GB out of 14.8 GB |
|
Generation speed |
11.8 tokens/sec |
12.1 tokens/sec |
The catch is that a larger GPU chip leaves Windows with less. At 48GB, Windows had 14.8GB to work with and was already 86% full with the model loaded, all about 3% faster during warm booting. Partitioning only changes what suits the edges, with Windows reporting a total GPU memory of 46.7GB at a 16GB partition and 55.4GB at a 48GB partition. I keep the 16GB GPU, and unless the model only fits the larger quota, I lean toward Windows as well.
Only signed applications, by default
A new Windows 11 installation can come with Intelligent App Control turned on, and apps are only allowed to run if they are signed or deemed safe by Microsoft’s cloud service. This is embarrassing for native AI, as a lot of tools are shipped as zip files on GitHub. While testing the RTX Spark against the Strix Halo, it blocked existing Lemonade builds and unsigned llama.cpp versions on both laptops, and Ollama was the only tool that worked on both.
The strangest thing is that the older version of Lemonade worked fine, while the current version did not. In my case, updating an already working tool was the thing that was stuck. The Yoga’s Intelligent App Control is turned on in Windows Security, and the option to return to evaluation mode is greyed out, so there’s no easy compromise once it’s forced.
You can check Windows Security -> App & Browser Control -> Smart App Control, and this is also where you turn off Smart App Control. Microsoft says Recent updates allow you to turn it back on without a clean install, so it’s no longer a one-way decision. I’ll leave my tools running, but decide before you build your own toolchain.
CUDA on Windows on Arm is still version 1
CUDA works, your stack may not
Nvidia brought CUDA to Windows on Arm only this year Coda 13.4and arrived on RTX Spark hardware as a developer preview. My Yoga’s driver now reports CUDA 13.5, and the fundamentals are solid, since Ollama ran the 28GB model on the GPU without any fuss.
The problem starts at the bottom of the stack. During the preview, Nvidia warned that some PyTorch development workflows could make this happen Turn on GPU timeoutsand vLLM has no native Windows support at all (via lecompute). Nvidia interview is that 97% of the top 15,000 Python packages are supported, which sounds great until your project depends on the other 3%.
So, before you buy, list every part of your stack, from custom ComfyUI nodes to bundled extensions and training tools, and check each for the Arm64 version. Adding the Build column in the Details tab of Task Manager will show which of your applications are actually running locally and which ones are running under simulation. And if something refuses to work on Windows, WSL2 is Microsoft’s answer, which brings me to Linux.
Linux works, but Nvidia isn’t the one making it work
Same chip, different support
This is the part that stings. The GB10 chip behind the RTX Spark runs Nvidia’s Ubuntu-based DGX OS in Nvidia’s DGX Spark, but the RTX Spark laptops only come with Windows, and Nvidia has not announced Linux support for them at the time of writing. When Computerforgeeks checked, Nvidia’s generic Linux driver version (615.71.09) listed GB10 but not the laptop chip device IDs (via com.computingforgeeks).
This did not stop people. Josephine Pfeiffer ran Arch Linux ARM On a 128GB Asus ProArt P16, it took Nvidia’s Ubuntu kernel work, ACPI overrides built from the laptop’s own tables, a patched keyboard driver, and a custom audio driver. CUDA saw about 116GB, and vLLM ran the Qwen model at about 31 tokens per second. It’s impressive, but it’s one person on one laptop, so treat it as a proof of concept.
WSL2 is the real way to go, and it worked well on my Yoga. Ubuntu 24.04 runs natively on Arm, the GPU appears inside WSL2, and WSL2 sees exactly the GPU memory you set in the Nvidia app as 16GB and 48GB. The problem is RAM, because WSL2 only takes half of what Windows has by default, so max it out in the .wslconfig file in your user folder. This example assumes a 16GB GPU partition, where Windows has about 47GB:
The RTX Spark platform is great, if you know what you’re getting into
Nothing here is a deal breaker. The RTX Spark is still the most capable Windows laptop I’ve used for native AI, and having CUDA on a laptop with this much memory is a big deal. But most of these are decided at checkout or on day one, so they’re worth thinking about before the box arrives.
Choose your memory for the models you want in a couple of years, give the GPU only a larger share if the model isn’t otherwise suitable, and check your Python build for Arm64 versions. Decide what to do about Intelligent Application Control before you install anything, recheck it after you update your tools, and treat Linux as a nice surprise rather than a plan. What would you like to see worked on one of these? Let me know in the comments.
