What 16-, 32-, and 36-node DGX Spark clusters actually prove

A large DGX Spark cluster makes an impressive video, but a purchase decision needs more detail. Which machines ran the workload? How was the model distributed, how long did users wait, and could another owner reproduce the result?

A community project by ciprianveg brought together 16 ASUS GX10 systems in a GB10 cluster. The build uses a 100Gbps network switch, with the exact topology and software configuration documented across the project's updates. A later NVIDIA Developer Forum update describes a working two-switch arrangement; the topology needs to be associated with the specific run being discussed.

The linked Cloud Codes video highlights ciprianveg’s GB10 cluster project. The original build used sixteen ASUS GX10 systems, a MikroTik CRS804-4DDQ switch, and four 400G-to-four-100G breakout cables. That arrangement connected each machine at 100Gb/s. The switch-side cable rating did not turn each endpoint into a 400Gb/s device. A later update describes a working two-switch arrangement; the topology needs to be associated with the specific run being discussed.

The build runs Kimi-K3, which Moonshot lists as a mixture-of-experts model with 2.8 trillion total parameters and 104 billion activated parameters. The total parameter count matters when planning storage and memory; the activated count describes how much of the model participates in processing each token.

The project’s v5-prd configuration distributes the model across 16 systems and uses speculative decoding. The setup uses different numerical formats and network optimizations to run the model across multiple systems. These details matter because performance can change depending on the software version, network configuration and how the model is launched. The maintainer lists approximately 1.56 TB of model weights stored on NFS, a network file system.

The following results are reported by the project maintainer for its v5 configuration. They are not Uniqcli measurements or performance guarantees for other installations.

These figures come from the same v5 snapshot, but measure different workloads. Combined throughput across eight streams is not the speed experienced by each user. Keep each result attached to its workload, concurrency and software configuration.

Earlier numbers need particular care. The builder subsequently explained that repetitive output had inflated speculative-decoding acceptance in the first results. Corrected coding performance was lower. That correction belongs beside any discussion of the original headline.

A separate owner, DropTheBeat, reported a change from 1.3 to 8.9 tokens/s after resolving a TCP fallback and exposing RDMA, without speculation. This was a different sixteen-node installation using v4-prd. These results came from different installations and software versions, so they cannot show the improvement achieved by upgrading one system.

Read the generated output when checking performance. Repeated text, failed tool calls and incorrect answers can make a fast response unusable. Save complete outputs, including failed runs, alongside the timing logs so you can judge speed and usefulness together.

The All Spark project is a separate deployment. Its owner describes expanding to 36 systems to run several models and supporting services at once, rather than one model across all 36. That distinction matters: a larger installation can increase the number of workloads running simultaneously without demonstrating faster inference for a single model.

A claim about single-model inference across 32 or 36 systems needs more than an equipment list. Look for the participating machines, network layout, launch configuration, workload, complete outputs and repeatable timing results.

Start by writing the job in one sentence: for example, “Four engineers need cited answers from our manuals during working hours.” Then specify what counts as an acceptable answer and an acceptable wait. These requirements give you something concrete to test before buying.

Evaluate one system first when the target model fits. Consider two independent replicas when simultaneous requests are the constraint. Consider a sharded pair when a matching recipe offers a relevant capacity or latency benefit.

For teams considering a multi-node deployment, start with a tested two- or four-system configuration and verify networking, software compatibility and workload performance before planning a larger cluster.

NVIDIA’s current setup assistance covers up to three directly connected systems or four through a switch, while its vLLM serving walkthrough uses two. These documents cover different tasks: setting up the network and running a specific two-system serving configuration.

Before moving beyond four nodes, require evidence that a smaller configuration misses the target. Budget operator time, restart behavior, model-loading storage, measured wall power, and room cooling alongside the machines. Assign an owner for software updates and failed runs. Decide whether downtime can wait until morning or needs an immediate response.

Use community builds to understand what your own configuration needs to demonstrate. For an introduction to the hardware, explore our desktop AI overview.