DGX Spark in 2026: What Still Works, What Broke, and What I'd Run Today

Plain-English version: the old posts are field notes; this is the current map

The DGX Spark series started as a pile of experiments: "Can this box run the big one?", "Why is this dense model crawling?", "Why did this quantization path look smart and then waste an evening?" That was useful, but it also means the older posts carry launch-week scaffolding that you probably should not copy anymore.

This article is the map I wish sat above the series: what I would run today, what changed since the early Gemma 4 posts, and which lessons are still the floorboards. If you want the full archive, start from the DGX Spark series hub. If you just want a current default, keep reading.

---

Introduction: I no longer read the series as a timeline

Early hardware posts age in a strange way. The measurements stay useful, but the setup steps rot. A Docker image that was correct in April becomes a museum label in July. A bind mount that saved the day becomes something you should delete.

So I do not read my own DGX Spark series chronologically anymore. I read it like a service manual: current recommendation first, then the older posts as receipts. The receipts still matter. The box is still the same GB10 machine, the bandwidth wall is still real, and the bad runtime choice still costs more than the model card admits. But the 2026 answer is cleaner than the April answer.

What I'd run today: vLLM first, then pick by workload

If you bought the machine to run one local model and forget about it, I would not start with the biggest checkpoint. I would start with the most boring path that is currently supported by the runtime.

Workload	What I would try first	Why
Daily chat / local assistant	nvidia/Gemma-4-26B-A4B-NVFP4 on current vLLM	The same class of setup measured about 52 tok/s on GB10, and the official weights remove the old community-quant shim.
Long-context text	26B-A4B NVFP4 first, then test the context shape you actually need	Long context is never free. The old lessons about KV cache and runtime behavior still matter more than the advertised context window.
Long-context multimodal	Gemma 4 12B Unified	It is the new 2026 option: encoder-free multimodal, with 256K context according to its Hugging Face model card. I would test it before forcing multimodal work through a text-first 26B setup.
High-throughput chat / agent serving	vLLM + the MTP path, but only with the matched target/drafter setup	The measured MTP path hit 108 tok/s. It is now native in vLLM, so the old preview-image dance is gone. Pairing still matters.
Diffusion-style language experiments	DiffusionGemma on vLLM, as its own category	It can be fast, but diffusion tok/s is not the same metric as normal autoregressive tok/s. Read the diffusion post before comparing numbers.

For agents specifically, I would keep the default boring: vLLM, official weights, then measure the actual agent loop. A tool-using agent can be slow because the model is slow, but it can also be slow because every turn re-feeds too much context. Swapping models will not fix a bad loop.

What changed since the early posts: fewer shims, fewer preview images

The biggest 2026 change is not that the hardware became faster. The stack caught up.

First, NVIDIA's official nvidia/Gemma-4-26B-A4B-NVFP4 weights shipped on 2026-04-30 and vLLM supports them. That changes the default recommendation from "community quantization plus gemma4_patched.py" to "use the official weights first." The older 52 tok/s article is still the right performance receipt, but not the setup recipe I would blindly copy.

Second, Gemma 4 MTP moved from launch-week preview to normal runtime support. vLLM PR #41745 merged on 2026-05-06 and shipped in vLLM v0.21.0 on 2026-05-15. Current stable is vLLM v0.24.0 from 2026-06-29. The old MTP 108 tok/s post is still the proof that the speedup is real; the preview-image instructions are now history.

Third, Google added Gemma 4 12B Unified on 2026-06-03. That matters because it gives the Spark a new long-context multimodal candidate instead of making 26B-A4B answer every question. I would not call it the new default for everything. I would call it the first model I would test when the job is "large context plus image/audio/video-style inputs" rather than plain chat.

What still holds: GB10 rewards sparse activation and punishes dense decode

The old measurements did not become useless. They became the guardrails.

Old result	Still-useful conclusion
26B-A4B NVFP4 on vLLM: about 52 tok/s	The default chat path is fast enough to feel local, and official weights make it simpler now.
MTP path: 108 tok/s	Speculative decoding is worth testing for high-throughput serving, but only with the right pairing.
E4B NVFP4: about 50 tok/s	Smaller or PLE-style models can be practical when the job does not need the 26B route.
31B dense: about 7 tok/s	Dense decode is still the bad fit on GB10. Bigger is not automatically better when bandwidth is the wall.
vLLM was about 30% faster than Ollama on the same model	Runtime choice is not packaging trivia; it changes the result.

This is the core pattern from the complete Gemma 4 selection guide: on DGX Spark, I care less about total parameter count than about how much weight data moves per generated token. MoE beats dense here because it does less work per token. PLE-style smaller models can still make sense. A dense 31B model can look stronger on paper and still feel worse in the chair.

What still bites: quantization, KV cache, and runtime state

The annoying traps also survived.

The first trap is assuming NVFP4 always wins. It does not. The NVFP4-vs-FP8 post exists because GB10 has hardware-specific paths where the smaller-looking format is not automatically the faster one. My current default is still official 26B-A4B NVFP4 because it is supported and measured well, but I would not generalize that into "NVFP4 beats FP8 everywhere."

The second trap is treating Ollama as a harmless fallback. The vLLM-vs-Ollama article measured vLLM about 30% faster on the same model, and the CPU-split behavior remains the kind of problem that makes a model feel mysteriously broken. I still use Ollama where convenience matters. I do not use it as the performance baseline for this box.

The third trap is pretending context is just a number in the model card. Long context means KV cache pressure, prefill cost, and more ways for an agent loop to pay for the same text again. Gemma 4 12B Unified gives a new 256K-context multimodal option, but it does not repeal the basic cost model. Measure the shape of your workload, not just the maximum window.

Use the series hub as the router, not the article dates

If you are arriving fresh, I would read the series this way:

Question	Start here
"Which Gemma 4 model should I pick?"	Complete Gemma 4 selection guide
"What is the current default text setup?"	26B-A4B NVFP4 at 52 tok/s
"Should I use MTP?"	Gemma 4 MTP at 108 tok/s
"vLLM or Ollama?"	vLLM vs Ollama on the same model
"Why did NVFP4 disappoint in one setup?"	NVFP4 trap: GB10 FP8 wins
"What about diffusion / multimodal-ish work?"	DiffusionGemma NVFP4 on vLLM
"Where is the whole map?"	DGX Spark series hub

Dates are useful for provenance. They are not the reading order anymore.

Takeaways: treat DGX Spark as a capacity-first local serving box

Where the time went: most of the wasted time in this series was not "can the model run?" It was finding the exact place where model format, runtime support, and GB10's hardware path disagree.

Reusable diagnostics: when a setup feels wrong, I check the runtime first, then the active-parameter shape, then quantization format, then context behavior. That catches more real problems than staring at the model size.

The general principle: DGX Spark is useful in 2026 when I treat it as a local serving and capacity machine. It is less useful when I ask it to be a pure speed contest box. Use the current vLLM path, use official weights where they exist, test MTP where throughput matters, and keep the older posts as receipts.

That is the current map. The experiments are still there; start from the series hub, then follow the branch that matches the job in front of you.