Best Models for NVIDIA DGX Spark (2026): What to Run on 128 GB

Why memory bandwidth shapes your choice

Generating each token means reading the active model weights from memory. With roughly 273 GB/s, a dense 70B model at 4-bit (~40 GB) is limited to single-digit tokens per second, while an MoE model with only a few billion active parameters can run many times faster. That is why MoE models are the headline workloads for DGX Spark.

Top picks by use case

Speeds vary with runtime, context length and quantization; treat these as starting points and see our benchmark pages for measured numbers.

Recommended runtimes

DGX OS supports the main local runtimes. Pick based on how you work.

• Ollama — easiest start; one command to pull and run models.
• llama.cpp — most control over GGUF quantization and offload.
• vLLM or SGLang — best for serving several agents at once.
• TensorRT-LLM / NIM — highest performance on NVIDIA-optimised formats.

Running several models at once

A practical agent setup keeps a large planner and a small worker resident together, for example gpt-oss-120b plus a 7–20B model, with memory left for context caches. Leave 10–15 GB free for the operating system and context so the system does not swap under load.

What not to run

Very large dense models (100B+ dense) technically fit at low bit-widths but run too slowly for interactive work. Two linked DGX Sparks can hold models up to roughly 400B parameters, but expect batch-style rather than chat-style speed.

Best model by task (quick picker)

Pick by job first, then by size. With 128 GB of unified memory, DGX Spark can hold far bigger models than most laptops, but memory bandwidth (~273 GB/s) — not capacity — decides how fast tokens come out. Smaller, well-quantized models usually feel better in day-to-day use.

Rough speed expectations

Token generation on memory-bound hardware scales roughly with bandwidth ÷ model size in memory. These are order-of-magnitude estimates, not measured results — actual speed depends on runtime (llama.cpp, Ollama, vLLM, TensorRT-LLM), quantization and context length.

Runtime recommendations

Ollama is the easiest start. llama.cpp gives the most control over quantization and context. vLLM and TensorRT-LLM are better for serving several users or agents in parallel. NVIDIA's DGX OS ships with container tooling that makes vLLM and NIM-style deployments straightforward.

• Start: Ollama with an 8B and a 32B model to calibrate expectations.
• Tune: llama.cpp with Q4_K_M / Q5_K_M quants and a set context size.
• Serve: vLLM for multi-agent or team access over the network.

How RTXsparks sources and checks these numbers

RTXsparks is independent and not affiliated with NVIDIA or any OEM. Prices come from manufacturer launch announcements and retailer listings (US MSRP before tax unless stated). Specs come from official product pages. Performance figures are either our own lab runs, labelled community submissions, or clearly marked estimates derived from memory bandwidth. Anything a vendor has not publicly confirmed is labelled 'unconfirmed'. See the methodology page for the full SCS, ARS and TLS scoring rules.

• Prices re-checked weekly during the launch window.
• Estimates are always labelled as estimates — never presented as measured results.
• Corrections are welcome via the benchmark submission page.

Picking a quantization level

Quantization shrinks a model so it fits in memory and runs faster, at some cost in quality. On 128 GB, the right level depends on model size.

Models to avoid on a single unit

Very large dense models above about 200B parameters will not fit with useful context on one 128 GB machine, even at 4-bit. Use a two-unit cluster or a smaller mixture-of-experts model instead.