RTX Spark: Entering the Age of Preference

By Max Weinbach

We're in the age of preference. RTX Spark gets Windows close enough to the performance I've liked so much in the M5 Macs that the computer I want to use becomes a much more interesting question. The operating system, the design, and the configuration I prefer can carry a lot more weight now.

Apple has been building chips with this approach for about five years: a powerful CPU and GPU sharing a large pool of memory in a laptop. For the combination of performance and local AI capability I wanted, that meant buying a Mac. RTX Spark is the first Windows competitor that makes this feel like a real choice to me across AI, CPU performance, and gaming.

I know some people don't like seeing every new Windows chip compared directly with a Mac, they are different markets. In this case, I think the comparison is useful. You'll see M5 Max results throughout this review because they show the performance we had available before, alongside what RTX Spark now offers. These machines are really close in what they let me do, even when individual benchmarks have larger gaps. The reason I want to do this is simple, and why I think this preamble is important, a frame of reference to show how close these are and what is now available in the Windows ecosystem.

And there are a lot more options. Six OEMs are building computers with RTX Spark, with different designs and configurations running Windows. Linux could add another option, depending on support. We've gone from looking to one manufacturer's product lineup for this particular combination to having a much broader selection of computers. We'll talk more about those designs later. For now, I want to look at what the chip makes possible, with the benchmarks as one part of deciding which of these computers someone might actually prefer.

The CPU still matters for AI

At one point while testing RTX Spark, I had 14 projects compiling and 15 coding subagents running WHILE playing a game. The fans were spinning, but I could still browse the web without the computer feeling overwhelmed. I really liked that. There was a ridiculous amount of work happening in the background, and I could keep using the machine.

This is increasingly how I use a computer. I have agents writing code, builds running, and applications open so I can see whether any of it actually works. Even when the model is running in the cloud, the computer on my desk has plenty to do. Add a local model, and the GPU and memory become a much bigger part of the experience too.

The coding agents in that busy session were using cloud models. My computer was doing the builds, running the tools, and opening the applications they produced. That distinction matters because it's easy to talk about AI performance as if the only thing happening is a model generating tokens. When an agent writes code, the CPU still has to do the work that follows.

NVIDIA's 20-core N1X configuration has ten Arm Cortex-X925 cores and ten Cortex-A725 cores. In my Geekbench 7.1 results, single-core performance was close to the Core Ultra 9 386H, with a much stronger multicore result. M5 Max was ahead of both.

My test results. Higher is better.

Spark scored about 36% higher than the Intel system in multicore. Against M5 Max, it was about 30% lower in single-core and 32% lower in multicore. I also wanted to see how those scores translated into the development work I use these machines for.

I tested compilation, bundling, and type-checking across Go, Rust, TypeScript, and Python. These are the sorts of jobs that keep happening while a coding agent works through a project.

My average test times. Lower is better.

The Mac finished every one of these tests faster. Kubernetes took about 42 seconds on Spark and 25 on M5 Max. TypeScript type-checking took almost twice as long on Spark. The bundling test also favored the Mac, although we're talking about roughly a third of a second there.

I care more about the longer waits. An agent can build, find a problem, make a change, and build again several times before it's done. Saving time on each pass helps, even if the model itself is running somewhere else.

Spark still felt comfortable to use with all that work going on. I haven't run the same multitasking session side by side with the Mac, so I can't rank them on responsiveness. But I was happy with how much I could leave running without making the rest of the computer unpleasant to use.

A Blackwell GPU with room for local models

The larger N1X configuration has 6,144 CUDA cores. For local AI, what interests me just as much is pairing that Blackwell GPU with up to 128GB of unified memory. Having access to NVIDIA's GPU software with that much system memory opens up more room to experiment with local models.

The memory is shared by the CPU and GPU, so Windows and my other applications need some of it too. The GPU's allocation also matters. A model needs space for its weights, working memory, and the context it keeps as a conversation grows. Fitting the model into memory doesn't mean every possible conversation or workload will fit alongside it.

Memory speed matters as well. NVIDIA specifies up to 300GB/s of memory bandwidth. There's also a 600GB/s bidirectional NVLink C2C connection between the CPU and GPU dies, but that's a different connection. The larger number isn't the bandwidth available for reading model weights from system memory.

CUDA is a big part of why this combination appeals to me. It also doesn't remove the need to check software support. This is a Windows Arm system, and the runtime needs to support the model, precision, and operations I want to use. How well those pieces work together matters a lot more to me than the CUDA core count by itself.

How long am I actually waiting?

When I run a language model locally, there are two parts of the response to think about. First it processes the prompt, which is called prefill. Then it generates the answer, which is called decode. Both can happen on the GPU. The CPU work I described earlier is the work around the model, like compiling code and running applications.

Prefill can process many input tokens in parallel. Decode generates the answer a little at a time and, in many low-concurrency workloads, spends much of its time waiting on memory. Caching, batching, and the model itself can change that balance. NVIDIA has a useful explanation of how this works.

I used AgentPerf to look at decode speed and end-to-end throughput. Both figures below are output tokens per second, but end-to-end throughput includes the time spent waiting before those output tokens arrive.

My initial AgentPerf results, using the 128GB Spark configuration with the larger GPU. I still need to reconcile model precision, runtime settings, and replay configuration across the systems, so these are preliminary comparisons.

If I only looked at decode speed, the Mac would win every test here. With Qwen 3.8 Flash Next, it generated tokens about twice as fast. Include the rest of the request, though, and the two were within about 2% of each other. This is one of the main benefits of RTX Spark, the fp4 CUDA accelerators really helps with prefill performance. While Qwen 3.8 Flash N

The Qwen 3.8 27B run with DFlash 2 went further: Spark recorded 2.61 times the end-to-end throughput despite decoding more slowly. I can't pin that difference on prefill or the GPU from these totals alone. Cache behavior and runtime settings can affect the result too. With Liquid LM, the Mac was ahead on both measures.

This is why I want to see more than decode speed when I'm looking at local AI performance. I care about how quickly the answer arrives, including the time before it starts appearing. A faster stream of text doesn't help as much if I've spent longer waiting for it to begin.

AgentPerf Local replays recorded agent conversations to measure model-serving speed. It doesn't score the quality of the answers, and its default mode doesn't execute the tools. These results cover the model's response; the development tests above cover some of the work that follows.

NVIDIA's AI results

NVIDIA's own testing gives another useful example of that initial wait. In its Qwen3.8-27B AIPerf run on a 64GB ProArt P16, a 64K-token input and 1K-token output took 136.37 seconds to reach the first token and 197.14 seconds overall.

That's more than two minutes before the answer starts, or about 69% of the total time. NVIDIA disabled prompt caching for this test, so an ongoing conversation that reuses cached context can behave differently. It's a useful reminder of how much the prompt and cache settings matter when comparing results.

NVIDIA also supplied image and video generation results from a 128GB ProArt system. These are its measurements; I haven't reproduced them myself.

A roughly 15-second image generation with FLUX2.Klein is the kind of use I'd be interested in trying locally. The settings matter here: all three workloads use NVFP4, and the table includes the steps and output sizes. I'd want to look at the output quality alongside the time before comparing them with another system or a higher-precision run.

Where I land

The big takeaway for me is how close these machines are in the performance they make available for this work. M5 Max finished my development tests faster, and there are meaningful differences between individual results. I still came away thinking Spark is a really good alternative for someone who wants to do this work on Windows.

For the combination of performance, large unified memory, and local AI capability I wanted in a laptop, a Mac had been the obvious choice. Spark gives me another option. I can get NVIDIA GPU acceleration and a large shared memory pool in a Windows machine I can also use to build and test Windows applications.

Operating-system preference matters a lot here. Some people prefer Windows, and having a Mac finish a benchmark faster doesn't change the operating system they want to use. They should have good options for this kind of work too.

With Spark, that choice also extends to different manufacturers and different laptop designs. Someone can pick the size, design, and operating system they prefer while getting performance that's close to what has made the M5 Macs so compelling. It doesn't need to win every test to be a good choice. Having this level of performance available across more Windows laptops is a big deal to me.

Gaming

I also played Control Resonant while two coding agents worked on native Windows applications. One was working on GPU shaders for a UI graphic, and the other was improving an agent workflow. The game felt smooth, and I didn't notice frame drops in that session. I wasn't recording frame times, but I liked being able to play while that work continued.

NVIDIA's supplied gaming results include 135 average FPS in Cyberpunk 2077 on a 64GB ProArt P16. That's at 2560×1440 output with RT Low, DLSS Balanced, and 3× frame generation, so the number includes upscaling and generated frames. It's NVIDIA's measurement; I haven't reproduced it myself.