Nvidia RTX Spark takes on AMD Strix Halo, and AMD has reason to worry

Strix Halo has spent nearly two years answering a question Nvidia wasn't: how do you run big local AI models on a Windows laptop without a desktop GPU? AMD's Ryzen AI Max+ 395 pairs a strong integrated GPU with up to 128GB of unified memory, enough for a Strix Halo mini PC to generate things locally, and the Asus ROG Flow Z13 has been my portable local AI machine. Then Nvidia launched RTX Spark, with plenty of Blackwell GPU cores and a surprise; Windows on Arm for the OS.

So I put a 64GB RTX Spark laptop up against my 128GB Z13 on the same local AI jobs. The Spark won almost everything. But speed isn't why AMD should be nervous. The reason was sitting in the logs.

Two laptops, the same models, and Smart App Control switched on

Each chip ran its native GPU stack, CUDA on the Spark and ROCm on the Z13

The Nvidia side is a Lenovo Yoga 9n with the RTX Spark N1X and 64GB of memory, at $3,750 as configured. The AMD side is my Asus ROG Flow Z13 with the Ryzen AI Max+ 395 and 128GB, at $3,300. Both ran Windows 11 with Smart App Control on and enforcing, because I wasn't going to switch off a Windows security feature to make AI tools run.

Every LLM test ran through Ollama 0.40.8 with identical model files, a 16K context, and three runs per test. Ollama picked CUDA on the Spark and ROCm on the Z13 by itself, so each chip ran on its native GPU stack. Images came from ComfyUI with the same FLUX.2 Klein 4B files, settings, and seeds on both. Each laptop ran its maker's top power mode: Turbo on the Z13, Performance on the Lenovo.

The RTX Spark won every test that fit on both laptops

It read my documents up to 3.5x faster and wrote answers up to 1.6x faster

Local AI speed comes in two halves. Prompt processing is how fast the model reads what you give it, and token generation is how fast it writes back. I fed three models the first 40,000 characters of The Time Machine, roughly 9,600 tokens, and asked for a summary.

The Spark read that document 2.1x to 3.5x faster, and you feel it. Qwen3.8 27B started answering after 12 seconds on the Spark and 31 seconds on the Z13. The biggest lead came on gpt-oss 20B, at 5,616 tokens per second against 1,589.

Generation was closer, but still a clear win: 1.4x to 1.6x faster across all three models. Qwen3-Coder 30B wrote at 69.7 tokens per second on the Spark against 50.7 on the Z13.

Image generation showed the biggest gap in time to finish

FLUX.2 Klein 4B took 25.8 seconds per 1024x1024 image on the Spark and 66.3 seconds on the Z13. That's a 2.6x gap on identical files, steps, and seeds, and the biggest difference in time to finish of any job I ran. Same image, same 20 steps, and the Z13 spent an extra 40 seconds on every one.

Unplugged, the gap gets wider

On battery, the Spark didn't slow down at all, holding 71.4 tokens per second across eight runs. The Z13 dropped 17% from its plugged-in result to 42 tokens per second, partly because Asus locks out Turbo on battery, leaving Performance mode. Lenovo keeps Performance mode, so the Spark's lead grows from about 1.4x to 1.7x unplugged.

The Spark pulled slightly more from the wall at 137W against 126W, but it finished each summary in half the time. That works out to 0.28Wh per summary against 0.52Wh, so roughly half the energy for the same job. On battery, drawing roughly 99W and 71W, both would last about an hour of nonstop inference, but the Spark, helped by its bigger battery, would get through about twice as many summaries in that hour.

Memory bandwidth doesn't explain the gap, and that points at CUDA

The RTX Spark has 17% more bandwidth on paper but writes up to 61% faster

On chips like these, generation speed depends mostly on memory bandwidth. Nvidia's RTX Spark porting guide lists 300GB/s, and AMD rates the Ryzen AI Max+ 395 at 256GB/s. That's a 1.17x advantage for Nvidia. We've been using the mini PC versions of these chips for a year or more now, and they're great at the types of tasks you'd want lots of unified memory for.

The Spark generated text 1.37x to 1.61x faster, well beyond what that bandwidth gap predicts. The hardware on paper can't account for the difference, which points at the software: CUDA on one side, ROCm on the other. That 300GB/s may even be generous, since Nvidia lists the GB10 chip in its own DGX Spark at 273GB/s, which would leave even more of the gap to software.

Even AMD's own AI stack has to speak CUDA

This is the part that should worry AMD. ROCm works on the Z13: Ollama's log showed it running on the Radeon 8060S with its own bundled ROCm 7.1 libraries. But open ComfyUI's system info on the Z13, and this is how the ROCm build of PyTorch describes the GPU:

PyTorch Version: 2.12.0+rocm7.14.0
cuda:0 AMD Radeon(TM) 8060S Graphics : native (cuda)

That's by design. PyTorch's documentation says its ROCm build "intentionally reuses the existing torch.cuda interfaces," so code written for Nvidia runs on AMD with few changes, if any. It's a smart workaround, but the way I read it, AMD's AI stack works by presenting itself as Nvidia's.

AMD-backed Lemonade fared worse. Its installer is signed, but the llama.cpp ROCm backend it downloads on first use tried to load a CPU library Windows couldn't verify, and Smart App Control blocked it. That's down to me running the release candidate builds, but that's the version you get when you use winget or download the msi from Lemonade, so it's a fair thing to point out.

The model never loaded. Meanwhile, ComfyUI on the Spark turned on its DynamicVRAM memory manager and NVML monitoring, Nvidia's own management library, without being asked, while reporting its AMD backend as "PyTorch ROCm/HIP runtime not available."

Windows on Arm still makes the Spark earn it

None of this was effortless on Nvidia's side. ComfyUI for Windows on Arm is a beta that only supports Nvidia GPUs, and it runs a nightly PyTorch build where the Z13 gets a release version. Getting the template running took about five minutes on each, though, with no workarounds. The bigger caveats for Arm are elsewhere, although Nvidia promises every app will run, without giving a timeline for when.

Strix Halo still wins one round, and it's the one that needs 128GB

The Z13 ran a 120B model the 64GB Spark couldn't even load

OpenAI's gpt-oss 120B needs about 60GB of memory in Ollama. The Z13 loaded it entirely onto the GPU and wrote at 31.7 tokens per second, a genuinely useful speed for a 120B model on a tablet. The Spark, with about 46GB available to CUDA, didn't stand a chance:

llama-server reported out-of-memory during startup:
cudaMalloc failed: out of memory
failed to allocate buffer for kv cache

That's a limit of the 64GB configuration, not the chip. CUDA saw about 46GB at both of the GPU memory splits I tried, so a different split looks unlikely to rescue it. A 128GB RTX Spark exists, but it costs a lot more.

The Z13 gives you twice the memory of the Yoga for $450 less. Matching its 128GB on RTX Spark means the ProArt P14 at $6,500, close to double, though that's also a pricier ProArt-class machine.

AMD's problem isn't Strix Halo, it's everything around it

On every job that fit on both laptops, the RTX Spark finished in 40 to 60% of the time, and in the one job I measured at the wall, it used about half the energy. Image generation was 2.6x faster. And the generation gap was bigger than the bandwidth specs explain, which keeps bringing me back to software. That's an ecosystem problem, not a chip problem.

Sure, Strix Halo still has real advantages. The Z13 runs models the 64GB Spark can't, costs less, and gets release builds where the Spark leans on betas and nightlies. But when the ROCm build of PyTorch introduces itself as cuda:0, it's hard to miss whose platform everyone builds for.