# NVIDIA DGX Spark Eight-Node Clusters: Memory, Benchmarks and Setup Limits

NVIDIA has published results for a 1 TB desktop cluster, but fitting a larger model and making it faster are different engineering problems.

By Paras Madan | 2026-10-22


NVIDIA has announced support for eight-node DGX Spark clusters and published new benchmarks on October 22. Eight 128 GB machines provide 1 TB of aggregate unified memory. That makes larger local models possible, although the easier NVIDIA Sync setup for eight nodes is still due by year-end.

The useful question is what happens after the model fits. More memory helps you load a checkpoint. It does not remove the communication between machines while that checkpoint generates an answer.

## What the DGX Spark benchmarks show

In [NVIDIA's results](https://developer.nvidia.com/blog/running-frontier-class-ai-models-across-8-nvidia-dgx-spark-nodes/), Qwen3.8-27B in NVFP4 produces 11.86 output tokens per second on one node and 52.58 on eight switched nodes. That is a 4.43x decode speedup, not eightfold. The test uses one concurrent request, 8,192 input tokens, 256 output tokens and no speculative decoding.

The eight-node test uses RoCEnante, a collective-communication backend optimized for small messages. It requires switch-connected nodes. NVIDIA says NCCL remains the default and is better suited to larger clusters or higher concurrency.

Those conditions matter more than the headline speedup. A coding assistant with one active user has a different workload from a shared inference service handling many requests. A result from the first workload should not become the capacity plan for the second.

## Eight nodes still need a real network

The [existing NVIDIA setup playbook](https://build.nvidia.com/spark/connect-multiple-sparks) describes two-to-four-node configurations. It uses high-speed QSFP cabling and ConnectX-7 networking, with RDMA allowing transfers directly between device memory. It explicitly rules out treating ordinary wireless connectivity as a substitute.

This is useful context for the new announcement. A group of desktop-sized computers is still a distributed system. Network setup, communication tests and the topology of the physical connections become part of operating the model.

The [networking guide linked by NVIDIA](https://github.com/eugr/spark-vllm-docker/blob/main/docs/NETWORKING.md) supports direct, ring and switch arrangements. With two QSFP ports per Spark, a full mesh beyond three machines is not possible. The guide also separates configuring the nodes from configuring the switch itself.

For a team evaluating this, the first decision should be whether it needs one large model spread across the machines or several smaller serving groups. That decision changes which connections are useful. Buying enough aggregate memory before deciding the serving layout risks solving only the easiest part of the problem.

## A cluster can serve more than one model

There is another way to use a pool of local machines: keep different models available and select one for each task. NVIDIA's [Switchyard project](https://github.com/NVIDIA-NeMo/Switchyard) supports routing based on the request or an agent's recent tool activity. Some routing methods make an additional model call to judge the task.

That creates a different measurement problem. A cheaper or faster individual call can still lead to more retries, extra routing calls or a failed task. Switchyard's own documentation recommends evaluating the complete agent against a single-model baseline, rather than treating a lower per-call cost as the result.

For local hardware, I would apply the same discipline to throughput. Measure completed tasks at an acceptable quality level, alongside response speed. Otherwise a cluster can look busy without becoming more useful.

## What to check before adopting eight-node Spark

**Treat the published numbers as workload-specific vendor measurements.** They are useful starting points, not a promise for a different model, precision or concurrency level. The current introductory clustering guide also remains narrower than the newly announced support, and the eight-node Sync workflow is not yet available.

The interesting shift is that local AI planning now includes choices usually associated with a small server fleet: model placement, network topology and routing. The better purchase decision will come from a representative workload and a working deployment plan, rather than the largest checkpoint that can be loaded.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders turn infrastructure launches and engineering decisions into clear stories developers can understand and share.

[Book a 30-minute call](https://cal.com/paras-madan/30min).