NVIDIA DGX Spark and the GB10, explained
What's inside NVIDIA's desktop AI computer: the GB10 Grace Blackwell superchip, 128 GB of LPDDR5x at 273 GB/s, up to 1 PFLOP of FP4, the CUDA software stack, and which models fit.
5 min read
- DGX Spark
- GB10
- CUDA
- Unified Memory
On this page
The NVIDIA DGX Spark is a small, quiet box — about 15 cm square and 5 cm tall — that puts NVIDIA's data-centre software stack on a desk. First shown as "Project DIGITS" at CES in January 2025 and on sale since October 2025, it's built around one chip, the GB10 Grace Blackwell superchip, and one design decision: 128 GB of memory shared by the CPU and the GPU.
This post explains what's in it, what it's good at, and which models fit.
The GB10 superchip
The GB10, designed by NVIDIA with MediaTek, combines two chips in one package:
- A Grace CPU with 20 Arm cores: ten high-performance Cortex-X925 and ten efficient Cortex-A725.
- A Blackwell GPU with fifth-generation Tensor Cores, the same GPU architecture as NVIDIA's data-centre Blackwell systems, scaled down.
The two are joined by NVLink-C2C, a chip-to-chip link with much more bandwidth than PCIe, so the CPU and GPU work as one system rather than a computer with a card plugged in.
128 GB of unified memory
Both chips share 128 GB of LPDDR5x memory on a 256-bit interface, with 273 GB/s of bandwidth. As on Apple silicon, there's no separate VRAM: a model loaded into memory is directly usable by the GPU, and CUDA code can allocate managed memory (cudaMallocManaged) that both sides use without explicit copies.
That capacity is what sets the DGX Spark apart from gaming GPUs. A 24 GB or 32 GB graphics card can't hold a 70-billion-parameter model even at 4 bits (about 40 GB). The DGX Spark holds it with plenty of room left for context. NVIDIA positions it for inference on models of up to around 200 billion parameters with FP4 quantisation, and fine-tuning of models up to about 70 billion.
Up to 1 PFLOP of FP4
NVIDIA rates the GB10 at up to 1 petaFLOP of AI compute at FP4 precision (with sparsity). Blackwell's Tensor Cores support very low-precision formats — FP4 and FP8 among them — which halve and quarter memory use compared with 16-bit, and run faster.
Compute matters most for:
- Prompt processing (prefill): reading a long prompt is a large batch of matrix maths, so a long document starts answering sooner.
- Fine-tuning and training: forward and backward passes are compute-bound.
- Serving several requests at once: batching turns bandwidth-bound work into compute-bound work.
273 GB/s: the other side of the ledger
Generating text one token at a time is limited by memory bandwidth, not compute: every token reads the active weights from memory. The ceiling is:
tokens per second ≤ 273 GB/s ÷ bytes read per token
| Model | Bytes per token | Ceiling |
|---|---|---|
| 8B dense, 4-bit | ~4.5 GB | ~60 tokens/s |
| 32B dense, 4-bit | ~18 GB | ~15 tokens/s |
| 70B dense, 4-bit | ~40 GB | ~7 tokens/s |
| gpt-oss-120b (5.1B active, MXFP4) | ~3 GB | ~90 tokens/s |
Ceilings from the bandwidth arithmetic; real speeds land below them.
For large dense models, then, the DGX Spark's generation speed is modest: a 70B model runs, but slowly. Mixture-of-experts models are its sweet spot. OpenAI's gpt-oss-120b has 117 billion parameters but uses about 5 billion per token, and ships with its weights in the 4-bit MXFP4 format, around 60 GB in total. The whole model fits in memory with room for context, and each token reads only a small slice of it.
Two Sparks together
Each DGX Spark has a ConnectX-7 network interface. Two units can be linked directly to work as one, with 256 GB of memory between them — NVIDIA cites models of up to 405 billion parameters for a pair.
The software stack
A DGX Spark runs DGX OS, NVIDIA's Ubuntu-based Linux, preloaded with:
- the NVIDIA driver and CUDA toolkit (
nvcc, cuBLAS and the other CUDA libraries), - Docker with the NVIDIA Container Toolkit, so containers get the GPU with one flag, and
- access to NVIDIA's NGC catalogue of optimised containers.
This is the practical attraction. The same CUDA code, containers and frameworks that run on a data-centre Blackwell system — PyTorch, vLLM, SGLang, TensorRT-LLM, NVIDIA NIM — run here too. Develop on the Spark, deploy to the cluster, with the same software.
One thing to plan for: the CPU is Arm64. Most major projects publish Arm64 builds and containers, but older or niche packages may be x86-only.
Using the memory well
The GPU shares its memory with the operating system, so leave headroom. With vLLM, for example, keep --gpu-memory-utilization around 0.85 rather than 0.95 or more; pushing it too high can make the whole machine unresponsive. A good rule is to leave 10–15 GB for the system.
What fits in 128 GB
| Model | Precision | Weights | Fits? |
|---|---|---|---|
| Llama 3.1 8B | FP8 | ~8.5 GB | Easily, with many parallel requests |
| Qwen3-32B | FP8 | ~35 GB | Yes, with long contexts |
| Llama 3.3 70B | FP4 / 4-bit | ~40 GB | Yes |
| Llama 3.3 70B | FP8 | ~75 GB | Yes, with moderate context |
| gpt-oss-120b | MXFP4 | ~60 GB | Yes |
| Qwen3-235B-A22B | 4-bit | ~132 GB | No: needs two linked units |
Who it's for
Choose a DGX Spark when you need CUDA: code with custom CUDA kernels, frameworks that only run on NVIDIA GPUs, fine-tuning with NVIDIA's libraries, or developing something that will ultimately run on NVIDIA's data-centre hardware. Its compute makes it strong at prompt processing, batching and fine-tuning.
Look at a Mac Studio when your work is mostly single-user generation with large dense models: the M5 Max's 614 GB/s is more than twice the Spark's bandwidth, so it generates tokens faster. Mac Studio vs DGX Spark compares the two in detail.
On GpuToLease.ai
DGX Spark machines are coming soon to GpuToLease.ai, reserved by the day like our Mac Studios, with SSH access, Docker and the CUDA toolkit ready. They're listed on the pricing page, and the DGX Spark environment docs describe what you'll get.