Clustering Doesn't Scale Token Generation — Why a Single Mac Studio Out-Runs Four Networked GPUs

Apple announced the Mac Studio with M5 Ultra on August 25, 2026 — general release September 22, with the 512GB configuration specifically landing in late October. A side-by-side comparison circulating this week (chart via magnitude.dev, analysis via a tweet from Tom Greenwald) puts it against two other ways of reaching 512GB of memory for running large models locally: four networked NVIDIA DGX Spark units, and four networked AMD Ryzen AI Halo units. All three land in roughly the same price band — worth stating precisely, since it's easy to round past: the fully configured 512GB Mac Studio in the comparison runs around $15,000, well above the M5 Ultra Mac Studio's actual starting price of $5,499 for a lower-memory configuration. The $15,000 figure is what a maxed-out unit costs, not what the line starts at.

The three configurations

The Mac Studio reaches 512GB as a single chip with everything on one unified-memory bus. The other two reach it by clustering four separate boxes, each with its own smaller memory pool, networked together to act as one larger system.

Compute and bandwidth scale differently under clustering — and that's the real finding

Greenwald's tweet draws a distinction worth naming directly, because it explains why the same clustering strategy produces opposite results on the two things that matter for local inference.

Prompt processing (compute) can be combined across networked boxes, if the interconnect is fast enough. The DGX Spark units link over 200GbE — fast enough to actually pool their compute, and native FP4 support gives it a further edge on quantized models. That's why four networked Sparks come out fastest of the three on prompt processing despite each individual unit having less raw compute than the Mac Studio. The AMD Halo units link over a much slower 10GbE — too slow to meaningfully combine compute — so four networked Halos end up close to the single Mac Studio's prompt-processing speed, "somewhat worse," per Greenwald, despite four physical chips involved.

Token generation (bandwidth) cannot be combined across networked boxes, regardless of interconnect speed. This is the counterintuitive part. When a model is split across multiple networked boxes, tokens are generated by passing sequentially through each box's layers in turn — not in parallel — so four boxes generate tokens at the speed ceiling of one box, not four times it. That's true for the DGX Spark cluster and the AMD Halo cluster alike, for the same structural reason, independent of how good either interconnect is. The single Mac Studio, with the entire 512GB on one 1.2TB/s bus, has no such ceiling to hit — Greenwald puts it at roughly 4x the tokens/sec of either networked cluster.

Put together: clustering hardware to reach a target memory capacity does not proportionally scale the token-generation speed that capacity exists to serve. It does scale prompt-processing compute, given a fast enough interconnect. Those are two different resources with two different scaling behaviors under the same architectural choice, and it's easy to conflate them by looking only at aggregate specs like total TFLOPS or total memory.

Power tells the same efficiency story from a different angle

The Mac Studio draws roughly 270W — "less than a gaming PC," per Greenwald, and silent. The four-Spark cluster draws roughly 960W, "nearly maxes out a wall circuit" and runs hot. The four-Halo cluster sits at roughly 560W, about half the Spark cluster's draw but still described as "somewhat hot." A single, purpose-built chip handling the full memory pool directly avoids the overhead of running and cooling four separate systems — the same structural advantage that produces its bandwidth lead shows up again here.

What this doesn't settle

Greenwald frames "the real gap" as bandwidth, and the numbers support that framing for token generation specifically — but it's worth being precise that prompt processing and token generation aren't interchangeable measures of a system's usefulness, and which one dominates a given workload depends on what's actually being run. A workload dominated by long prompts against a comparatively short output (heavy document analysis, large-context retrieval) leans toward compute being the bottleneck, where the DGX Spark cluster's interconnect advantage matters most. A workload dominated by long generation against a short prompt (extended reasoning, long-form writing) leans toward bandwidth being the bottleneck, where the single Mac Studio's unified bus wins outright. Greenwald's own post is explicit that this is his analysis of a third-party chart, not a benchmark he ran himself — worth treating the qualitative ordering as credible and independently corroborated by public specs, while treating the framing of which gap is "the real" one as his interpretation of what matters most for typical local-inference use.

What to expect next

• Spark 2 is reportedly coming, per Greenwald, but he's explicit that a next generation won't change this dynamic unless per-unit memory bandwidth actually increases — more compute or a faster interconnect doesn't fix a bandwidth ceiling.
• The same logic applies to AMD's next Halo generation, plus any improvement to its comparatively slow 10GbE interconnect — worth watching whether AMD closes the compute-clustering gap with Spark even if the bandwidth ceiling stays put.
• Watch for real workload benchmarks, not just spec-sheet comparisons — the compute/bandwidth split described here is a structural property of clustering, but how much it matters depends on the actual ratio of prompt length to generation length in whatever's being run locally.

References: Tom Greenwald — hardware comparison thread · comparison chart via magnitude.dev, provided directly rather than fetched (this environment could not independently retrieve the source page) · Mac Studio M5 Ultra specs and pricing independently confirmed via Apple's own announcement · related coverage: FreeToken Serves a 753B-Parameter Model on One Workstation GPU · Open Weights You Can't Actually Run · NVIDIA Didn't Just Open the Model — It Opened One of the Teachers