For a lab, the software lag is the cost.
By Keith Townsend · October 18, 2026
A 256 GB Mac Studio holds a model that needs two NVIDIA DGX Sparks clustered together, costs less than the pair, and doubles as a desk machine. The claim tested here is that one serving box can replace two for local agentic work. It holds on capacity, on solves and on list price. It loses on wall time once two agentic sessions share the box. For a lab, the larger cost is that this model reached Apple silicon less complete than it reached NVIDIA.
One Mac Studio (M5 Ultra, 36-core CPU, 80-core GPU, 256 GB unified memory, 4 TB), one serving stack (oMLX v0.7.1rc1 on MLX 0.32.4), one model (DeepSeek V4 Flash 0731, FP8), one pool run. The comparator is the two-Spark venue from Lab 014, measured in August on vLLM with speculative decoding on. The two venues differ in hardware, serving software and speculation together, so the speed comparison is directional. Turn counts and summed task time are not comparable across the two arms, because the model reasoning reached the agent on one path and not the other. Timing is compared per turn, and even that is partly confounded, as stated below. Prices are US list prices as of October 2026, partly from third-party captures of the vendor configurators.
Do Buy the Studio if you want one system for a model this size and can accept slower turns once sessions overlap. It held the 156 GiB model in one box, cleared 22 of 22, and costs $12,299 as tested against $13,900 for two Sparks before the interconnect cable. Plan a separate host or VM for agent code: this lab did not run the harness on the Studio.
Don’t Do not buy it as lab or development infrastructure if you already run NVIDIA. At two concurrent sessions each agentic turn took 35.5 seconds on the Studio against about 18 on the Spark pair, and eleven weeks after the Spark stack served this model with working speculation, the Mac stack still cannot run speculation on it.
Don’t Do not trust the serving defaults on Apple silicon. Speculative decoding was on by default with an open memory bug, reasoning effort defaulted to low rather than the maximum the Spark arm ran (the pool was set to maximum), and the server renamed its own process so restarts failed without an error. None of it raised a warning.
Self-funded editorial. The Mac Studio was bought by the practice, and both DGX Sparks were bought at retail for Lab 014. No vendor commissioned, funded or previewed this lab or had any say in it. Apple and NVIDIA hardware are both under test here and both are criticised by name. Anthropic Claude Code is the agent harness on both arms. No vendor named here is a client of this practice.
Can one Mac Studio replace two clustered NVIDIA DGX Sparks for local agentic work? I tested it on the model that made me buy the second Spark: DeepSeek V4 Flash 0731, a 156 GiB mixture-of-experts checkpoint that doesn't fit in one Spark. The Studio has an M5 Ultra and 256 GB of unified memory, so it holds that checkpoint alone. It cleared the same 22-task repair pool, 22 of 22, and it costs less than the pair. It also took about twice as long per agentic turn once two sessions shared it. For my lab, that isn't the deciding cost. The deciding cost is that this model reached Apple silicon less complete than it reached NVIDIA.
Same files, same pool
The Studio served the original FP8 checkpoint, the exact files the Sparks ran in Lab 014. The server was oMLX, a community-built server on Apple's MLX framework, because stock MLX can't load this architecture yet. Support for it lives in an unmerged pull request, and oMLX ships it as a patch. The pool ran through the same Claude Code harness, the same proxy and the same launcher as the Spark arms, two sessions at a time. It solved all 22 tasks with no timeouts and no session errors. On solves, the two venues tie. That's one Studio run against two Spark runs, so read it as no difference found, not as proof of equal capability.
Faster memory, slower turns
With speculative decoding off on both venues, the Studio decoded a single stream at 40.6 tokens per second against the pair's 27.1. Speculative decoding means the model drafts several tokens ahead with a small prediction head and keeps the ones that check out. That's about 1.5x, most likely from faster memory, though I didn't isolate bandwidth. But the pair doesn't run with speculation off. Its production configuration drafts three tokens ahead and reaches 52.0 tok/s on one stream. Those three figures come from different prompts and settings, so treat the ratios as directional.
The Studio's server has the same feature. On this model it hits an open bug that strands about 63 GB of GPU memory during long tool-calling turns, and the Studio raised the matching error on its very first request. So I ran without it.
Under load the order flipped. At two sessions, with average contexts of 35K to 49K tokens, each turn took 35.5 seconds on the Studio against 17.6 to 18.6 on the pair. Output per turn was about the same on both, roughly 600 tokens. The prefix cache, which reuses the part of the prompt the server has already processed, supplied 91 to 98 percent of every turn's context, so prefill cost the Studio only an estimated 2 seconds a turn. Turn time is mostly decode. The Studio's per-stream decode fell from 40.6 to 29.4 tok/s at two sessions on short prompts, and its server averaged 20.0 tok/s over the pool. The doubling is speculation plus the Studio losing more speed to concurrency and long context. I didn't separate how much each contributes. That loss may not hold for every model. A dense 31B model on the same box barely slowed at two sessions, 44.9 to 43.1 tok/s per stream, though it's also a much smaller 4-bit model, so architecture and size aren't separated.
Who wins on effort and price?
My Studio bring-up was faster, from a warmer start. It took 1 hour 19 minutes from first remote login to a pool task running, with no networking, no cluster and no container. The Sparks took about a day after NVIDIA's own multi-node playbook deadlocked, plus a separate interconnect project. That comparison flatters the Studio, though. The checkpoint was already on its disk, the harness was already running on a Spark, and I already knew this model's quirks.
On list price the Studio is cheaper. It costs $12,299 as tested. Two Sparks now cost $13,900 at $6,950 each, before the cable.
The Studio's problems didn't raise errors. Speculation was on by default with that live bug. Reasoning effort defaulted to low rather than the maximum my Spark arm ran, so I set it by hand for the pool. The server renamed its own process, so restarts failed while the old one kept serving. I only caught the effort default because I had the Spark configuration to diff against.
The Spark side wasn't clean either, and that's worth saying plainly. Its working image is community-built, only one of five candidate models qualified on the pair, and its proxy path quietly dropped the model's reasoning before the agent ever saw it. Every reasoning block on the Spark arm reached the harness empty. On the Studio, 756,398 characters came through, and those sessions took 463 tool calls against 836. That makes turn counts across the two arms a comparison of two setups, not two boxes, which is why I compare speed per turn.
So what's it for?
If you want one system for a model this size and can live with slower turns once sessions overlap, the Studio is a real option. It's one box, it costs less, and it solved everything. You'll still need a separate host or a VM for agent code, because I didn't run the harness on it.
For a lab, the answer changes. A lab exists to test models as they arrive. Basic availability wasn't the problem. An MLX conversion of this model existed within days. Completeness was. Eleven weeks after my Spark stack served it with working speculation, upstream MLX still doesn't support it, and the Mac server's speculation path fails on it. That's one model, and calling it a pattern is my judgment, not a measurement. It's the judgment I'd plan around. I already own two Sparks, so for me the Studio's place in the lab is as the thing being tested. Does a fix for speculation on the Mac close the gap? Maybe, for this model. I'd expect the next model to start the same lag.
The numbers
Where each layer belongs
Read for portability. Could you take this layer elsewhere without rebuilding? How to read this table
| Layer | Mac Studio | 2x DGX Spark |
|---|---|---|
Layer 0 · Compute Compute & Network Fabric Retained on both, because the same checkpoint files, the same harness and an OpenAI-compatible interface moved from NVIDIA hardware to Apple silicon without converting the files, so nothing at this layer tied the workload to one vendor’s silicon. The Studio’s loader maps the weights to its native format at load time. Commodity NVIDIA hardware is Retained by the instrument’s rule. On the Studio the runtime is Apple-only, but it is open source and served the unmodified checkpoint. The software lag on Apple silicon is a cost of the venue, not a cession of authority. | Retained | Retained |
Layer 2C · Reasoning Agentic Infrastructure — The Reasoning Plane Retained on both, because open weights ran on self-operated serving with the configuration written down. Both serving stacks are community-built, a pinned vLLM image on the pair and oMLX on the Studio, so on both venues somebody in the organization has to own the runtime. | Retained | Retained |
Method and disclosure
Self-funded. The Mac Studio was bought by the practice. Both DGX Sparks were bought at retail for Lab 014. No vendor was briefed, reviewed this, or was given advance sight.
The repair pool, the reproduce-or-drop certification and the deterministic gate are the instrument used in Labs 011 to 014, unchanged, run through the same v1 Claude Code harness, the same litellm proxy version (1.93.0) and the same launcher shape as Lab 014. The launcher and serving configuration are recorded with the results.
The Studio serving envelope was diffed against the Spark arm’s run-time configuration file, not reconstructed from the published record. Divergences are declared: speculation off, MLX key-value cache rather than NVFP4, oMLX rather than vLLM.
Pins: oMLX v0.7.1rc1 (commit 7a5a3d7), MLX 0.32.4, mlx-lm git 94cdcae, custom Metal kernels built with Xcode 27.1 and the Metal Toolchain component, macOS 27.0.1. Checkpoint deepseek-ai/DeepSeek-V4-Flash-0731 revision 9e165c30, SHA-verified.
The harness ran on a DGX Spark and reached the Studio through an SSH relay, because bench code is not run on a machine on the author’s personal network. The relay adds a LAN hop the Spark arm did not have. During the pool another lab’s harness sessions also ran on that Spark, and a file copy capped at 60 MB/s wrote to the Studio’s disk for about four minutes in two intervals. The Studio’s GPU wired-memory limit was left at Apple’s default.
Public runbooks were consulted before the pool and are cited in the lab detail, including an independent M5 Ultra against DGX Spark comparison on a 4-bit conversion of the same model.
The harness, the gate and the certification tooling are public. The assessment methodology, the vendor grades and the judgment that turns a score into a placement are not.
The essay on this page was drafted by Claude Opus 5.5, an Anthropic model, from this record under the author’s voice specification, passed the deterministic post gate, and was validated by the author before publication. Anthropic’s Claude Code is the agent harness on both arms of this lab, so the drafting model’s vendor also appears on the bench.
The essay on this page was rendered from the lab’s frozen structured record by a model writing under this practice’s voice specification, with a deterministic gate checking every figure against the record before publication. The record is the canonical surface: where prose and record disagree, the record rules.
Download the raw lab detail (Markdown)