In Defense of the DGX Spark: A Reality-Grounded Take

Let me start by agreeing with the critics, because they are not wrong. NVIDIA sold the DGX Spark as a "supercomputer on your desk," a lot of local AI enthusiasts took that literally, and then the benchmarks landed. A single Spark decodes a 70B dense model at low single digit tokens per second. People bought one expecting to chat with a big model at a comfortable reading pace, got something closer to watching paint dry, and a fair number of them returned or resold the unit inside the first month. I felt that same disappointment myself when I first powered one on. So this is not a piece that tells you the haters are wrong and the Spark is secretly a rocket ship. It is a piece about what this machine actually is once you stop asking it to be the thing the marketing promised, because underneath the overhype there is a genuinely useful device that fits a niche almost nothing else fills. I say this as someone who runs both sides of this fence: an eight-Spark cluster on one hand, and a workstation with two RTX Pro 6000 Max-Q cards on the other. They do very different jobs, and the point of this piece is to explain which does what. Along the way I will also settle the other comparison people keep making, the one against a Mac Studio, because that verdict is usually only half right.

The Bandwidth Problem Is Real

The core complaint is correct and worth understanding, because it explains everything else. The Spark's unified memory runs at 273 GB/s. That is not a lot. A Mac Studio with an M4 Max roughly doubles it, and an RTX Pro 6000 is at 1,792 GB/s, close to seven times higher. Token generation on a dense model is almost purely a memory bandwidth problem, because the machine has to stream every weight in the model through the chip once for every single token it produces. Load a 70B dense model and each token means reading tens of gigabytes out of that 273 GB/s pipe, and the math just does not leave room for speed. This is why the single stream numbers look bad, and no amount of defending the Spark makes that decode wall disappear. If your dream was fast single user chat with a huge dense model, the Spark is the wrong tool and you should buy something else.

Where the Design Actually Makes Sense

Here is the reframe that changed how I use these boxes. The Spark is not a small dense model machine. It is a large memory machine, and the two are very different things. The 128GB of unified memory exists so you can load models that a normal GPU physically cannot hold at any speed, and the class of model that thrives under this exact constraint is the Mixture of Experts model. An MoE only fires a small slice of its parameters per token. So instead of streaming the whole model for every token, you stream a fraction of it, and your effective bytes per token collapse by a factor of ten or more. The bandwidth ceiling that crushes a dense model barely touches a well built MoE. This is the whole point of the machine and it is exactly the part the single stream dense benchmarks are structured to hide. You are not supposed to run the models that don't fit anywhere else slowly. You are supposed to run the models that don't fit anywhere else at all.

The Clustering Is the Unlock

Now add the part that most reviews skip past entirely, which is the two ConnectX-7 ports on the back. Those are not there for decoration. They let you connect Sparks directly with a single cable, no switch involved for two nodes, and pool their memory into one larger space. This is where the platform stops being a curiosity and starts being a system. Two Sparks give you enough pooled memory to run a model like DeepSeek V4 Flash, a 284B parameter MoE that simply will not load on any single desktop device. Four of them give you enough to run Qwen3.5-397B-A17B at FP8, a genuine near-frontier-class open model, sitting under your desk. That is the actual product here. Not one underwhelming box, but a set of boxes that scale into memory territory that normally requires a rack of server GPUs and the power bill to match.

What Clustering Actually Does to Performance

I want to be precise here because this is where people either overpromise or dismiss it, and both are wrong. Clustering mainly raises the ceiling on model size, and it also gives you real throughput gains, but the gains depend heavily on what you are running. In my own use, two nodes land somewhere around 1.7 to 1.85 times the performance of one, which is near linear and better than the "you lose half of it to overhead" skepticism you often hear. The gains show up most clearly on mid-size MoE models and smaller dense models, and least on small MoE models where there is not enough work per node to hide the communication cost. So clustering is not a magic button that makes one chat response stream twice as fast. It is a way to run bigger models than you otherwise could, serve more at once, and pick up a solid throughput bump on the model shapes that suit it. Frame it around capacity and it delivers. Frame it solely around single stream latency and it will disappoint you.

The Mac Comparison Nobody Frames Correctly

The other machine a Spark buyer is always weighing is a Mac Studio, and the usual verdict is that the Mac wins, full stop. On token generation, that verdict is fair. A Mac Studio M3 Ultra moves memory at roughly 800 GB/s against the Spark's 273 GB/s, and since generation speed is a bandwidth problem, the Mac generates noticeably faster on the same model and can hold enormous models in a single quiet box. If your day is mostly typing a short prompt and watching a long answer stream back, buy the Mac. But that is only half of what inference actually is, and the half everyone quotes.

The other half is prefill, the prompt processing phase, where the machine reads and digests everything you feed it before it writes a single token. Prefill is a compute problem, not a bandwidth problem, and this is where the Spark's Blackwell silicon flips the result. Against an M3 Ultra the Spark chews through long prompts on the order of three to nearly four times faster. In practice that means when you paste a large document, a long conversation history, a preloaded set of skills, or a chunk of a codebase into the context window, the Spark starts answering while the Mac is still reading. Owners who ran the same 397B model on both setups found generation almost tied, with the real, decisive difference being exactly this: the Spark processes big prompts far faster, the Mac struggles with them.

This is why the Spark is quietly well suited to agentic work, and it is the use case I lean on it for most. Agents do not send short prompts. They send enormous ones, packed with tool definitions, retrieved documents, system instructions, and prior context, and they do it turn after turn. A machine that ingests a 30,000-token prompt quickly feels responsive in that loop, and a machine that stalls on prefill feels broken no matter how fast it generates afterward. The generation-speed benchmark that makes the Mac look like the obvious winner is measuring the part of the workload that agents spend the least time on. Match the machine to the shape of your actual work, and for long-context, agentic, skill-and-codebase-heavy use, the Spark's prefill advantage is worth more than the Mac's generation lead.

The NVFP4 Asterisk

There is one more thing worth being honest about, because it gets misreported. Consumer Blackwell, meaning the GB10 in the Spark and the RTX Pro 6000, does have native 4-bit tensor cores, and NVFP4 does deliver roughly a 2x gain when the software path is right. The catch is the software. Right now the stock inference stacks often fall back to a slower dequantization path on consumer Blackwell because the native FP4 kernels for many model shapes are not upstream yet, meaning often you'll find running models at FP8 beats or matches NVFP4 on inference speed, at least for now. Consequently, the promised uplift is real silicon that is partly stranded behind immature software, with the fully lit-up path tending to appear on the server parts first. This is not a permanent hardware limitation, it is a maturity gap that closes over time as the kernels land, but if you buy a Spark today expecting the full NVFP4 story out of the box, you should know that some of it is still on the way.

The Question Everyone Actually Asks: Two Sparks or One RTX Pro 6000?

This is the comparison that fills the forums, so let me answer it with both machines sitting in front of me. Start with the money, because it frames everything. An Asus Ascent, which is a Spark partner unit with a full terabyte of storage, runs $3,999 right now. An RTX Pro 6000 is $13,250 and climbing, and that is for the bare card, before you have bought the workstation to bolt it into, the power delivery, and the cooling. One Pro 6000 costs more than three entire Sparks. So the honest framing is not "which is better," it is "these are essentially two completely different products that happen to both run models."

What the Spark path buys you is memory and reach. For the price of a single Pro 6000 you can have three or four Sparks, cluster them, and address a memory pool that a lone Pro 6000's 96GB cannot touch. You will run larger models, you will pull far less power, and you do not need a chassis, a beefy PSU, or a cooling plan, since each Spark is a self-contained brick that sips from a wall outlet. If your goal is the largest total memory footprint and the ability to load frontier-scale MoE models at home, the Spark cluster wins that contest handily and does it quietly.

But I am not going to pretend the Pro 6000 does not decimate the Spark where it counts for a lot of people. On small and mid-size dense models, the ones most enthusiasts actually run day to day, the Pro 6000 is game changing for token generation. Take a dense model like Qwen 27B at FP8, with multi-token prediction enabled on both machines. On a single Spark I measure it at around 20 tokens per second, which is genuinely usable, roughly reading pace, and honestly fine for a lot of work. On a single Pro 6000 the same model runs at around 110 tokens per second single stream. That is not "a bit faster," it is more than five times the speed, well past how fast you can read, the kind of pace that makes a local model feel like a snappy cloud endpoint rather than a compromise. That gap is that 1,792 GB/s of bandwidth doing exactly what the Spark's 273 GB/s cannot. If your workload is dense models that fit in 96GB and you care how fast the text streams back, the Pro 6000 is not a little better. It is a different experience.

Both, Actually

The reason I own both is that they solve different problems and complement each other cleanly. The Spark cluster is my large-memory, high-total-capacity, low-power tier for the big MoE models and frontier-scale open weights. The dual Pro 6000 workstation is my fast-dense tier for the models I interact with constantly and want instant responses from. They are not rivals on my network, they are two ends of a range, and the "versus" framing online mostly comes from people who can only justify one and want permission to feel good about the choice. Fair enough. So here is the permission, made concrete.

The Honest Recommendation

If your budget comfortably allows it and your focus is running dense models that fit in 96GB with real speed, get the RTX Pro 6000, full stop. It is also the right pick as a complement to a Spark or a Spark cluster you already own, giving you a fast lane alongside your big-memory lane. If instead you are trying local AI for the first time, you are watching what you spend, or your whole objective is the most total memory and the ability to run the largest models at home on a power budget you can live with, the Spark is the smarter entry, and clustering lets it grow with you. Do not buy a single Spark to chat quickly with a giant dense model, because it will let you down. Buy Sparks to build a quiet, power-sipping pool of large private memory, buy Pro 6000s to make dense models fly, and understand that plenty of serious home setups eventually run both. There is no free lunch in AI hardware, or anything else. You are always paying somewhere, in money, in speed, in power, in heat, in noise. The trick is knowing which bill you are choosing to pay, and buying the machine whose bill matches the work you actually do.

There Is No Free Lunch

One last number to sit with, because it is the one that keeps me loyal to the Spark side of the rack. My eight-Spark cluster draws around 900 watts under full inference load. Where else do I get access to roughly a terabyte of pooled memory, running frontier-scale MoE models, on a load I can pull from ordinary wall outlets, in a stack of boxes that fits on a shelf and does not turn the room into a sauna? A comparable cluster of server GPUs would want dedicated 240V circuits, serious cooling, and enough heat and noise to make the space unpleasant to sit in. Not everyone has 240V in their office, and even fewer people want a space heater running next to them all day. The Spark's bill comes due in single stream speed, and what it buys with that payment is memory capacity, clusterability, and an energy footprint you can actually live with at home. Judged as a supercomputer on a desk, it disappoints. Judged as the most energy efficient way to put a large pool of private, clusterable memory in your home, it is close to unmatched, and once you pair it with a fast dense-model card for the jobs that need one, you stop arguing about which machine won and start running both for what each is good at.