A two-node DGX Spark cluster: what it really gives and who needs only one

The question usually arrives like this: «we bought one DGX Spark, we hit a wall, should we buy a second?». The answer depends not on the wish to scale but on which wall you hit. If it is memory capacity, a second node helps. If it is generation speed, it will not help at all. Below are figures from official specifications, measurements from open testing, and the place where NVIDIA's own sources contradict each other.

What a single machine does

DGX Spark is built on the GB10 Grace Blackwell superchip: a Blackwell GPU with fifth generation Tensor Cores plus 20 Arm cores, ten Cortex-X925 and ten Cortex-A725. Memory is shared, 128 GB of LPDDR5x, coherent: the CPU and the GPU see the same array without copying back and forth. The compute claim is 1 petaFLOP at FP4. Storage is 4 TB of self-encrypting NVMe. All of it sits in a box measuring 150 by 150 by 50.5 mm and weighing 1.2 kg, on a 240 W power supply, while the GB10 itself draws 140 W.

The official ceiling for one machine: fine-tuning models up to 70 billion parameters and inference up to 200 billion. That is not marketing, it is what physically fits into 128 GB under aggressive quantisation.

Capacity is the real advantage here. A model that will not fit into the 96 GB of a professional card does fit into a Spark, and it needs no rack, no three-phase supply and no dedicated cooling loop. The price is honest and known in advance: LPDDR5x instead of HBM, meaning capacity was bought with bandwidth. Here is how that feels in practice.

Where it runs out

At 273 GB/s. This is the number that matters, and it explains every review saying «the model loaded but answers slowly». Token generation is a sequential read of model weights from memory for every single token. However much compute you have, it will not outrun the memory.

Open llama.cpp measurements show the gap clearly. GPT-OSS 120B in MXFP4: prompt processing at 1,956 tokens per second, answer generation at 60.6 tokens per second. At a 32,000 token context both figures drop to 1,027 and 40.6. So the machine reads your prompt instantly, then types the answer at roughly the pace of a person reading aloud. Measurements by the LMSYS team on the SGLang stack land in the same range: around 70 tokens per second on the 20B model and around 50 on the 120B.

How two nodes are stitched together

Each Spark carries a ConnectX-7 with two QSFP ports at 200 Gb/s. Two nodes connect directly, cable from port to port, and no switch is required. The official NVIDIA «Connect Two Sparks» playbook describes exactly that: the physical link, network interface configuration through netplan, passwordless SSH between the nodes. The whole route is budgeted at about an hour.

The cable has to be a specific one: a passive QSFP112 DAC, 0.5 m long. NVIDIA lists two validated models, the Amphenol NJAAKK-N911 and the Luxshare LMTQF022-SD-R. The bundled PNY QSFP to QSFP 112G cable at 0.5 m is made to the same specification, so there is no need to hunt for anything longer or active. Half a metre is not a design slip: the two boxes sit side by side on a desk.

What 200 Gb/s actually delivers

This is where the marketing material stops helping. In ServeTheHome testing the full 185 to 190 Gb/s appeared only once the interfaces had been bound to the correct 100-gigabit MACs on one of the QSFP cages. While the binding was left arbitrary, both links ran through a single PCIe Gen5 x4 channel and delivered 92 to 95 Gb/s. Half the rated figure, with no visible configuration error: it simply runs twice as slow.

The practical conclusion is simple. Budget a day for network configuration and verify the result with RDMA measurements, not with the fact that the link came up.

How many nodes can be linked: the sources disagree

The NVIDIA product page says the networking allows up to four DGX Spark systems to be connected and to work with models of up to 700 billion parameters. The user guide for the same product, in its section on stacking, says something else: up to three systems connected directly by cables, four only through a switch. Both documents are official.

A separate word about the figure circulating through reviews: «two Sparks run a 405 billion parameter model». That statement is absent from NVIDIA's documents. Neither the product page, nor the user guide, nor the official playbook for connecting two machines names such models. If that configuration is critical to your project, test it on real hardware before buying rather than taking it on trust.

Who will be fine with one

One is enough if your model fits into 128 GB and you are developing rather than serving a stream of users. A prototype, fine-tuning a model up to 70 billion, a local assistant for the team, work with sensitive data that cannot go to the cloud: all of it is covered by a single box under the desk, with no rack, no industrial socket and no dedicated air conditioning.

A second node makes sense in two situations. First: the model does not fit into 128 GB and memory is exactly what you need. Second: you are learning distributed training as an engineering practice and need a genuine second node with genuine NCCL rather than a simulation. In every other case doubling the nodes doubles the memory and adds nothing to response speed, because each node is still held to its own 273 GB/s.

If generation speed is the wall you hit, the answer is not a second Spark but cards with HBM, where bandwidth is measured in thousands of gigabytes per second.