by Chris DePuy, 650 Group / November 2, 2026
NVIDIA has announced official support for eight-node DGX Spark clusters. The configuration scales unified memory from 128 GB on one machine to 1 TB across eight. As a result, frontier-class models fit on the desk. The company detailed the configuration, the benchmark data, and the supporting software on October 22. The details landed in an NVIDIA Technical Blog post published during GTC Berlin. I am impressed by how much software weight NVIDIA is putting behind advanced Spark use. I think the memory headline is the least of it. Notably, a Spark-optimized collective, multi-model routing in NeMo Switchyard, and cluster management in NVIDIA Sync all arrived in one announcement. A near-linear training recipe arrived with them. Together, they treat eight-node DGX Spark clusters as a supported platform rather than a wiring experiment.
Eight-node DGX Spark clusters: 1 TB of unified memory
Which configuration fits which operator depends on workload size and traffic pattern, as of November 2026. A single Spark covers 27B-class serving. Next, a switchless four-node ring is the lowest-cost path to tensor-parallel inference. Finally, an eight-node DGX Spark cluster handles frontier-class checkpoints, split model pools, and any-to-any traffic. NVIDIA’s setup guidance covers each layout.
A single DGX Spark carries 128 GB of unified memory. Four nodes reach 512 GB, and eight reach 1 TB. However, the gain shows up in which checkpoints load. Z.ai’s GLM 5.3, 753B parameters in total, is the marquee model a four-node system cannot hold. Its NVFP4 checkpoint weighs about 470 GB, among the largest open models that run on a desk. I benchmarked the four-node ceiling in my own testing. Meanwhile, NVIDIA’s early measurements put GLM 5.3 Flash at roughly 80 tokens per second across the eight nodes. The full checkpoint manages 31 decode tokens per second for a single user. That configuration uses multi-token prediction and an 8K input. Then, at four concurrent users, totals reach 51 with 21 per user. At eight, totals reach 67 with 18 per user. Finally, prefill holds near 1,600 tokens per second aggregate.
RoCEnante: a collective tuned for tensor-parallel decode
In tensor-parallel decode, collectives such as all-reduce consume a real share of the clock. Per NVIDIA’s post, the company is evaluating a Spark-optimized backend called RoCEnante for that pattern. The target workload uses small messages, low concurrency, and a modest rank count. The backend performs an all-to-all exchange followed by a local reduction inside a single GPU kernel. That skips the multi-round forwarding chain of ring all-reduce, at the cost of extra data movement. On an eight-node DGX Spark cluster serving Qwen3.8-27B in NVFP4, RoCEnante delivered a 4.43x decode speedup. The runs disabled speculative decoding, and the baseline without the backend reached 3.05x. Overall, that is a 45% improvement in scaling efficiency. Gains reach about 5% on prefill and 21% on decode at four nodes.
NVIDIA has landed the code in FlashInfer, where it reverts to NCCL automatically when its startup self-check fails. However, it applies only to switch-connected topologies. The company is explicit that NCCL remains the supported default, the better choice once clusters and concurrency get larger. For the one-shot all-reduce at the backend’s core, credit goes to community contributor Jason Cook. My caveat: these are NVIDIA’s own benchmarks, and independent replication is pending.
Ring or switch: how eight-node DGX Spark clusters scale
Tensors move between Spark nodes over RDMA on Converged Ethernet, carried by low-latency ConnectX-7 network adapters. Specifically, the benchmark table below shows how topology choice plays out on a dense Qwen3.8-27B (NVFP4) workload. The runs used llama-benchy at an 8,192-token input and a 256-token output at concurrency one.
| Nodes | Topology | Prefill (TPS) | Decode (TPS) |
|---|---|---|---|
| 1 | Standalone | 2,635 | 11.86 |
| 2 | Direct connect | 3,285 | 21.71 |
| 4 | Physical ring | 4,446 | 32.82 |
| 4 | Switch (RoCEnante) | 4,556 | 36.34 |
| 8 | Physical ring | 4,962 | 40.11 |
| 8 | Switch (RoCEnante) | 5,105 | 52.58 |
Decode on the dense 27B workload climbs from about 12 to 52.58 tokens per second across the eight-node DGX Spark cluster. First, a switchless ring aligns with the ring algorithms NCCL defaults to in a four-node deployment. That makes the least expensive four-node inference box. Next, the switch earns its place once the cluster splits into independent groups or runs all-to-all traffic. MPI-style jobs and RoCEnante also need the switch. RoCEnante depends on every node talking directly to every peer. Finally, NVIDIA’s networking guide walks through setup starting from two nodes.
NeMo Switchyard: routing requests across model pools
Not every request needs the largest model. NVIDIA’s NeMo Switchyard makes the split practical on a shared eight-node DGX Spark cluster. First, its design puts a small classifier in front. The classifier reads each incoming request or session and sends it to a matching model pool. Then, a load balancer spreads traffic over the replicas. The layout requires switch connectivity, because requests move between pools on any-to-any paths.
In NVIDIA’s prototype, OpenBMB’s MiniCPM5 2B both classified requests and executed the simple ones. Qwen3.8 Flash Next handled the rest. The pair scored 91 out of 100 on a 92-case tool-use benchmark with hard cases. That matches a Qwen-only configuration. Also, a single MiniCPM replica absorbs roughly ten times the request rate of a Qwen replica. Handing part of the load to MiniCPM lifts what the full cluster can deliver. The test put three Qwen replicas on two nodes each and two MiniCPM replicas on one node each. Aggregate throughput reached about 1.5 times a Qwen-only baseline at a 50/50 split. The gain grew to about 3.0 times when only a quarter of requests stayed with Qwen. Finally, the routing policy is a YAML file, with a sample policy provided.
Pre-training from scratch: near-linear scaling on eight-node DGX Spark clusters
Training behaves differently from inference, because every node carries the entire model. So, cross-node traffic collapses to one gradient synchronization per step. NVIDIA pre-trained a nanochat model from scratch, about 896.5M parameters, and measured throughput while adding nodes. Throughput ran 8,741 tokens per second on one node, 17,202 on two, 33,640 on four, and 68,079 on eight. Overall, that is 7.79 times one-node throughput at 97.4% scaling efficiency, run with 524,288-token global batches per step.
The full training code is on GitHub. NVIDIA’s October 22 post documents the run. As I read it, the intended on-ramp runs in that order. Work out a prototype and its first training runs at the desk. Reach for more hardware only when the model demands it.
What the announcement adds up to
The four pieces, official eight-node support, a purpose-tuned collective, an orchestration layer, and a training recipe, amount to sustained investment. NVIDIA is funding the software that makes eight-node DGX Spark clusters behave like one machine. Indeed, I think that investment matters more than any single benchmark number in the post. The company’s own hedges point at what comes next. Also, NVIDIA Sync gains eight-node support by the end of the year. RoCEnante’s latency-for-bandwidth trade means NCCL stays the default as concurrency and cluster size grow. As firms such as 650 Group have tracked in their AI infrastructure research, inference is spreading across more form factors. An officially supported eight-node desk cluster extends that track from the data center onto the desk.