NVIDIA says the setup can serve larger models, route requests between models, and train smaller ones—but the best results depend on the network design.
NVIDIA has announced official support for linking eight DGX Spark systems into one local AI cluster. The company says the arrangement gives developers 1 terabyte of shared memory, enough to run models that would not fit on a single system or a four-node setup.
That changes the role of DGX Spark. Instead of using one machine for experiments, a developer could use several machines together for model serving, request routing, or training. But the gains are not automatic: the right network topology, model, and workload matter.
NVIDIA says support for eight-node clusters in its Sync management software is coming by the end of 2026. The announcement does not establish the system’s purchase cost, power needs, or production reliability.
More memory lets larger models run locally
A single DGX Spark provides 128 gigabytes of unified memory, according to NVIDIA. Four systems provide 512 gigabytes, while eight reach 1 terabyte.
That larger memory pool lets the cluster spread one model across several machines. NVIDIA says the full 753-billion-parameter GLM 5.3 model from Z.ai can run across eight DGX Spark systems.
In one example, NVIDIA ran GLM 5.3 Flash across the eight-node cluster and measured roughly 80 tokens per second during generation. Tokens are the small pieces of text a model processes and produces; this figure describes how quickly the model generated an answer in that test.
The result is useful for local development, but it is not a general speed promise. NVIDIA’s test used a particular model, precision, cluster, and workload. Longer prompts, more simultaneous users, or a different model could produce different results.
The network can matter as much as the machines
When several systems work on one model, they must exchange data constantly. How those systems are connected affects both speed and flexibility.
NVIDIA reports that a dense Qwen3.8-27B model reached about 12 tokens per second on one DGX Spark and about 52 tokens per second on eight. Those tests used specific input and output lengths, a particular model format, and different network arrangements.
For a single model spread across all eight systems, NVIDIA says a physical ring can deliver strong decoding performance. In a ring, each machine passes data to its neighbor, creating a simple chain around the cluster.
A switch becomes important when the cluster must split into independent groups. For example, a business might reserve four systems for one model and four for another. A switch also supports direct connections between every machine, which some communication patterns require.
That creates a practical choice. A ring may offer a simpler and cheaper setup for a single-model deployment, while a switched network provides more room for multi-model serving and specialized workloads.
Routing sends easy requests to smaller models
Eight systems do not need to run one giant model all the time. NVIDIA’s NeMo Switchyard is designed to inspect each request and send it to a suitable model pool.
A lightweight classifier can handle simple requests with a smaller model. Harder requests can go to a larger model. A load balancer then spreads requests across copies of those models.
This matters because many requests do not need the most expensive model available. A small model might answer a formatting question, while a larger model handles a complex tool-use task.
In NVIDIA’s prototype, OpenBMB’s MiniCPM5 2B handled simple tasks, while Qwen3.8 Flash Next handled complex ones. The routed system scored 91 out of 100 on a 92-case tool-use benchmark, matching the score of a setup that used Qwen alone.
NVIDIA also measured higher aggregate throughput when more requests went to the smaller model. Sending half the requests to Qwen produced about 1.5 times the throughput of the Qwen-only arrangement. Sending one-quarter to Qwen and the rest to MiniCPM produced about 3 times the throughput.
Those figures depend heavily on the traffic mix. If most requests are difficult, the larger model remains the bottleneck. The routing policy also needs testing against an organization’s real prompts, because a classifier can send a request to the wrong model.
Switchyard’s split model pools require a switched cluster, according to NVIDIA. A ring cannot divide eight systems into separate groups as cleanly.
Training gains look different from serving gains
Inference means using a trained model to answer requests. Training means changing the model by processing examples. The two workloads communicate between machines in different ways.
For training, NVIDIA says each system can hold a copy of the model and synchronize updates once per step. In a pre-training experiment, it measured an 896.5-million-parameter nanochat model as it scaled from one to eight DGX Spark systems.
The company reports 18,741 tokens per second on one system and 868,079 on eight. That represents a 7.79-times speedup, or 97.4% scaling efficiency.
In plain English, the eight-system run delivered nearly eight times the throughput of the one-system run in that experiment. That makes the cluster potentially useful for training smaller models from scratch, not only serving very large models.
The result is still tied to the tested model and training setup. A different model, batch size, sequence length, or communication pattern could scale less efficiently.
What this changes for local AI teams
The eight-node design offers three distinct paths: fit a larger model, serve several models together, or train a smaller model faster.
The best choice depends on the job. A developer serving one model may favor a simpler ring. A team routing traffic between model pools will likely need a switch. A training team should measure its own model and batch settings before assuming NVIDIA’s near-linear result will carry over.
For now, the practical next step is planning around workload and topology rather than treating eight systems as one guaranteed performance tier. Teams considering the setup should first decide whether their priority is model capacity, request throughput, or training speed—and then validate that workload on the intended network.