NVIDIA says you can now link eight DGX Spark machines into one supported cluster with 1 TB of unified memory, enough to run the full GLM 5.3 (753B) open model from Z.ai on a desk. In a technical post published October 22, 2026, NVIDIA reports 31 tokens per second for that model at concurrency one, a 4.43x decode speedup from one node to eight on Qwen3.8-27B, and 7.79x faster from-scratch training of a small model. The company announced the support at GTC Berlin; the benchmark detail is in the NVIDIA Technical Blog post.
Everything below is NVIDIA's own measurement. Where a number matters for a buying decision, I flag what it does and does not show. For the price and memory context of the single box, see our post on the DGX Spark price and memory change.
TL;DR
| Item | NVIDIA's claim |
|---|---|
| Cluster size | Official support for up to 8 nodes, 1 TB unified memory (128 GB each) |
| NVIDIA Sync | Eight-node cluster support "coming by the end of the year" |
| Full GLM 5.3 (753B), NVFP4, about 470 GB | 31 tok/s decode at concurrency 1, 67 tok/s total at concurrency 8 |
| GLM 5.3 Flash | About 80 tok/s on eight nodes |
| Qwen3.8-27B NVFP4 decode | 11.86 tok/s on one node, 52.58 on eight (4.43x, switch plus ROCEnante) |
| Multi-model routing (Switchyard) | 91/100 on a tool-use benchmark, up to 3.0x aggregate throughput |
| nanochat pre-training | 7.79x on eight nodes, 97.4% scaling efficiency |
Why the memory number is the story
A single DGX Spark has 128 GB of unified memory, four nodes reach 512 GB, and eight reach 1 TB. Large open mixture-of-experts models are mostly a memory problem: the weights must fit before speed matters. NVIDIA says the full GLM 5.3 checkpoint, which previously would not start on a four-node system, runs on the eight-node cluster, "making it one of the largest open models you can serve locally." For background on the model, see our coverage of the GLM 5.3 coding benchmark release and the smaller GLM 5.3 Flash pricing.
NVIDIA's table for the full model, measured with MTP3 (multi-token prediction) and 8K input sequences:
| Concurrency | Prefill total (tok/s) | Prefill per user | Decode total (tok/s) | Decode per user |
|---|---|---|---|---|
| 1 | 1,600 | 1,600 | 31 | 31 |
| 4 | 1,600 | 750 | 51 | 21 |
| 8 | 1,600 | 473 | 67 | 18 |
Read this realistically. 31 tokens per second for one user is usable for interactive chat, but prefill is flat at 1,600 tokens per second no matter the concurrency, so a long agent prompt takes seconds to ingest, and eight simultaneous users each get 18 tokens per second. It is a private development box for a very large model, not a production serving tier.
Scaling from one node to eight
NVIDIA benchmarked a dense Qwen3.8-27B in NVFP4 without speculative decoding, at 8,192 input tokens and 256 output tokens, concurrency 1:
| Nodes | Topology | Prefill (tok/s) | Decode (tok/s) | Decode scaling |
|---|---|---|---|---|
| 1 | none | 2,635 | 11.86 | 1.00x |
| 2 | Direct connect | 3,285 | 21.71 | 1.84x |
| 4 | Physical ring | 4,446 | 32.82 | 2.77x |
| 4 | Switch (ROCEnante) | 4,556 | 36.34 | 3.06x |
| 8 | Physical ring | 4,962 | 40.11 | 3.38x |
| 8 | Switch (ROCEnante) | 5,105 | 52.58 | 4.43x |
Two takeaways. First, decode scales far better than prefill (4.43x against 1.94x at eight nodes). Second, eight machines buy you under 4.5x the decode speed of one, so if the model fits on one or two nodes, adding more only helps when you need the memory or the concurrency. For single-node tuning on the same hardware, see NVIDIA's Flare local inference server and the Qwen3.8 Flash Next FP4 guide.
ROCEnante: a collective backend for small messages
Tensor-parallel decode spends meaningful time in all-reduce operations. NVIDIA describes ROCEnante as a backend for switch-connected clusters that does an all-to-all exchange followed by a local reduction, coordinated by a single GPU kernel. Each rank sends its full input to every peer and adds the inputs itself. That means fewer communication steps than a ring, which passes data between neighbors over many rounds, at the price of more data moved overall.
NVIDIA's chart shows 3.06x versus 2.56x at four nodes and 4.43x versus 3.05x at eight (switch topology, Qwen3.8-27B NVFP4, speculative decoding off). In text it adds roughly 5% higher prefill and 21% higher decode at four nodes, and about 18% higher decode at eight nodes on the non-quantized model. The caveats are in NVIDIA's own text: the trade-off favors small messages, low concurrency and modest node counts, so with high concurrency, larger clusters or ring topologies NCCL "would perform better." The backend is merged into FlashInfer and falls back to NCCL if its startup test fails. NVIDIA credits the original one-shot all-reduce idea to a community contributor.
Ring or switch?
A switchless ring lowers cost and simplifies setup, and NVIDIA says it performs well for four nodes with NCCL's ring algorithms. You need a switch when you:
- scale to eight nodes and want the best decode,
- split the cluster into groups, such as two groups of four,
- run all-to-all or MPI-style workloads, or
- want the ROCEnante backend, which needs direct connectivity between every pair of nodes.
NVIDIA points to its multi-node networking guide and says the Cluster Assistant in NVIDIA Sync handles setup, though eight-node support in Sync is not shipped yet.
Switchyard: route easy requests to a small model
Not every request needs the biggest model. NVIDIA's NeMo Switchyard prototype uses a lightweight classifier to route each request or session to a model pool, with a load balancer across replicas. In the prototype, OpenBMB's MiniCPM5 2B was the classifier and handled simple tasks, and Qwen3.8 Flash Next handled complex ones. Three Qwen replicas (two Sparks each) and two MiniCPM replicas (one Spark each) filled the eight nodes.
NVIDIA reports the routed agent scored 91/100 on a 92-case tool-use benchmark that includes hard cases, matching the Qwen-only setup, with about 1.5x aggregate throughput when half of requests go to Qwen and about 3.0x when a quarter do. The 3.0x figure assumes most of your traffic is easy enough for a 2B model, which is a property of your workload, not the cluster. The same idea of pairing a small local model with a larger one appears in our coverage of NVIDIA EdgeWise.
Training: close to linear for small models
When every node holds a full model copy, the only cross-node traffic is gradient synchronization once per step. NVIDIA pre-trained a nanochat model (about 896.5M parameters, 20 layers) and measured:
| Nodes | Tokens/s | Speedup | Efficiency |
|---|---|---|---|
| 1 | 8,741 | 1.00x | 100.0% |
| 2 | 17,202 | 1.97x | 98.4% |
| 4 | 33,640 | 3.85x | 96.2% |
| 8 | 68,079 | 7.79x | 97.4% |
The code to reproduce it is on GitHub, per NVIDIA. The caveat is scale: a model under 1B parameters fits on each node, which is the easy case for data-parallel training. Nothing here shows how a larger model that must be sharded across nodes would train.
How the cluster story has developed
The DGX Spark began as a single compact box for developers who want a private, large-memory machine. NVIDIA's post describes two-node direct connection and four-node ring setups as the existing paths, and the eight-node announcement extends that line. It arrives alongside a wave of local-AI hardware from NVIDIA and its partners, including the RTX Spark laptops and desktops covered in our RTX Spark launch ecosystem post. The pitch is consistent: keep sensitive code and data on hardware you own, and run open models whose weights keep growing.
That growth is why memory is the headline. Open-weight frontier models now reach hundreds of billions of parameters, and even at 4-bit precision the weights alone take hundreds of gigabytes. A 1 TB pool lets a team test such a model without renting a multi-GPU server, and the 128 GB per-node figure makes the arithmetic simple: weights, KV cache and runtime overhead must fit in the sum.
How to read NVIDIA's numbers
- Concurrency one dominates the scaling table. Decode scaling at a single request is the best case for tensor parallelism; real agents run several streams.
- Speculative decoding is off in the scaling table, on for GLM 5.3. The full-model table uses MTP3, so the two tables are not comparable with each other.
- Precision matters. The cluster tables use NVFP4, which is NVIDIA's format; other quantizations will give different speed and quality.
- No quality evaluation of GLM 5.3 on the cluster is given, only throughput. The Switchyard result is the only quality figure in the post.
- Vendor-run. NVIDIA wrote the software, picked the models and ran the tests. Independent reproductions, ideally from the community that builds spark-vllm-docker style setups, are what to wait for.
What to weigh before buying eight of them
- Cost. Eight Sparks plus a switch is a large outlay. Compare with a workstation such as the Gigabyte GB300 deskside system or a Mac-based cluster like the one in our Apple MLX over Thunderbolt 5 post.
- Context length. NVIDIA's tests use 8K input. KV cache for long agent sessions eats memory that the weights otherwise use.
- Software maturity. Eight-node support in NVIDIA Sync is not out yet, and the backend depends on FlashInfer and vLLM versions.
- Your goal. If you need the biggest open model privately, memory wins. If you need throughput for many users, rented GPUs are likely more economical.
Related reading
- GTC Berlin 2026: everything Jensen Huang announced
- DGX Spark price and memory change
- NVIDIA Flare local inference server
- Apple MLX over Thunderbolt 5 for local inference
- GLM 5.3 coding benchmark release
- Official: NVIDIA Technical Blog and FlashInfer
Details are accurate as of October 22, 2026. All benchmarks were run by NVIDIA.