Is the DGX Spark worth it for local LLM work? A measured answer

Ask the web whether the DGX Spark is worth buying for local LLM work and you get spec sheets: 128 GB unified, a petaflop of sparse FP4, ConnectX-7. What you almost never get is what the box did for anyone under a real workload. We own a pair, we published the raw runs, and this page answers the buyer question only from what we measured — with the limits stated, because our DGX lane is bring-up work (lab_single_run), not our three-repeat methodology.

What a pair of Sparks actually did

Everything below is quoted from our public run repositories and is reproducible from the recipes in them.

It served a 284B-parameter MoE at home. DeepSeek-V4-Flash-0731 (284B total, ~13B active), tensor-parallel across two nodes over 200G RoCE

67.6 tok/s on a card-like short-output profile, 43.7 tok/s on a heavy 4K-context prose profile . That profile spread — not the hardware — is the main reason published Spark numbers disagree with each other; the full reconciliation is its own page.

It aggregated for a group. At 12 concurrent streams the same configuration produced 260.4 tok/s aggregate on the code profile ; in the earlier 1M-context build, 8 streams held ~99 tok/s aggregate and 12 streams 141–146 tok/s . Aggregate is a serving number, not a feel number: divide by your concurrency before imagining a chat session.

It walked a context curve to a million tokens — and told the truth about it. Decode ran 42.7 tok/s at 16K depth, 17.6 at 512K, 17.2 at 1.03M — a plateau past the half-million mark, which is genuinely remarkable. The bill arrives elsewhere: the first fill of a 1M-token context cost 642 seconds cold, 4 seconds warm . A million-token window you can afford to fill once is a different product from one you can afford to fill per request.

One flag mattered more than any tuning. The runtime ships a MoE kernel built for this model’s MXFP4 experts and excludes it from auto-selection: --moe-backend flashinfer_b12x moved single-stream decode from 59.7 to 67.6 tok/s client-side , a 9–12% step-rate gain measured engine-side . The backend report covers it; the recipe page shows how to verify the flag actually took effect.

Who the pair is for

• You want the biggest open MoE class running under your own roof. Two Sparks did that, stably enough to publish the runs. Nothing else at this power and desk footprint did, in our fleet.
• You serve a small group, not one impatient person. The aggregate numbers are real; the per-stream numbers at high concurrency are modest.
• You do long-context research. The depth plateau is a finding worth owning hardware for — if your sessions reuse the prefix, so the 642-second cold fill amortizes.

Who should not buy it

• Single-user, latency-sensitive work on heavy prompts. 43.7 tok/s on the heavy profile is workable but not snappy, and every fresh long document pays prefill in full.
• Anyone expecting datacenter Blackwell behavior. Our testbed page states the limit plainly: GB10 results do not generalize upward.
• Anyone unwilling to operate it. Bring-up was real work — a one-line port bug ate days (the saga), and standard GPU monitoring half-works: on GB10 unified memory, dcgm-exporter does not function and NVML returns N/A on a large share of queries; we ended up parsing nvidia-smi into a custom textfile collector (write-up, in Russian).

Limits of this answer

One pair of units, one model family at the center, single passes with warmups rather than our three-repeat discipline — lab_single_run is the evidence level and the label means it. No price advice: hardware prices move and this lab does not publish them. When our methodology-v1 lane reaches the Sparks, the numbers on this page will be superseded by claims with confidence intervals — subscribe on /subscribe/ if you want that event, not this snapshot.

Raw runs, manifests and the serving recipe: botAGI/dspark-0731-gb10 and the 1M-context repository.