Four NVIDIA DGX Spark Systems Versus Two: Is a Bigger Local AI Cluster Worth Buying? Doubling a home AI cluster from two NVIDIA GB10-based systems to four did not halve reply latency, according to a hands-on comparison by hwbusters using one ASUS Ascent GX10 and three NVIDIA DGX Spark machines linked by a MikroTik CRS812 DDQ switch at 200Gb/s per link. The audited four-node run was slower to start every reply than the published two-node results, largely because each request waited on the gateway's per-request check of all four nodes and the Windows SSH agent stalled a third or more of connections for one to two seconds; after removing both on 22 October, the author re-measured the same four profiles. Each machine carries 128GB of unified memory and a nominal 4TB Samsung MZALC4T0HBL1-00B07 NVMe drive (4,096,805,658,624 bytes measured), but the author notes that software must explicitly divide models and working state across nodes rather than treating the pool as one GPU address space. I expanded my home AI cluster from two NVIDIA DGX Spark-class machines to four to find out what the second pair actually buys: quicker replies, more simultaneous work, or access to models that are awkward to run on two boxes. The answer depends on the model and how it is distributed. My earlier two-machine comparison https://hwbusters.com/systems/local-ai-vs-frontier-six-models-two-gb10-systems/ covered six local models and four frontier services. This follow-up asks a more practical buying question: should you pay for another two machines and a fast switch, or keep the pair you already have? A word on the jargon: GB10 is the NVIDIA chip inside the DGX Spark, a small desktop computer built to run AI models, and inside look-alikes from ASUS, GIGABYTE and MSI. My cluster is one ASUS Ascent GX10 and three NVIDIA DGX Spark systems, so “GB10 system” below means one of those machines. I kept the published two-node results and repeated the short speed and quality workloads on the commissioned four-node installation. The results describe these installed systems. Where the serving layout changed, I identify that change beside the result. Doubling the number of machines does not automatically halve the wait for a reply. How to read the numbers. I measured each model twice. The first set, the audited run, went through the cluster’s model gateway as I had built it, and it found the four-node cluster slower to start every reply than the published pair and slower to finish several replies. A large share of that was not the models: every request waited for the gateway’s per-request check of all four nodes, and the Windows SSH agent made a third or more of the connections stall for one to two seconds. I removed both on 22 October no recipe, checkpoint, context or layout changed and measured the same four profiles again. Both sets are shown: the audited numbers appear in every section, and the re-measured numbers sit beside them in “After the Gateway Fix”, labelled supplementary. Later the same day I also installed CUDA graphs for GLM Flash and for DeepSeek 1017 Heretic; each has its own section below. Related GB10 and local AI articles: The Equipment The cluster contains one ASUS GX10 and three NVIDIA DGX Spark systems, all using GB10. Each has the 128GB unified-memory capacity class and a nominal 4TB Samsung MZALC4T0HBL1-00B07 NVMe drive. The measured drive capacity is 4,096,805,658,624 bytes per machine. Four boxes give the cluster more aggregate memory and storage, but software must explicitly divide the model and its working state. This memory is not a single GPU address space that applications can use without distribution overhead. The fast fabric uses a MikroTik CRS812 DDQ switch. Two NADDOD Q2Q56-400G-CU1 passive copper breakout assemblies each connect one 400G QSFP-DD end at the switch to two 200G QSFP56 ends at the computers. The manufacturer’s nominal length for this part is one metre. Ordinary Ethernet remains connected for management. All four compute links reported 200Gb/s with RS-FEC, and the isolated fabric used a 9,000-byte MTU. Those are link and configuration observations. They are not a claim that an application moves data at 200Gb/s or that every computer has a 400Gb/s link. The tested switch board identifies itself as CRS812-8DS-2DQ-2DDQ; the manufacturer’s retail family adds an RM suffix that has not been independently confirmed from the sample label. The Windows control workstation has an RTX 4090 with 24GB VRAM and 64GiB system RAM. It handles Windows-compatible editing and encoding work separately. Its VRAM doesn’t count toward the GB10 model pool. The separate 5090/5080 Rendering PC is outside this inference comparison. That Windows machine also runs a separate 27B Q4 local text model. Its practical profile is 65,536 tokens with a Q4 attention cache: an uncached 62,248-token input recovered three separated canaries and completed the tool-return control while all 66 model layers stayed on the GPU. The bounded context test retained at least 4,083MiB free VRAM. The earlier 122,880-token profile passed its context and tool controls, but a later resident run reached 1,935MiB free VRAM, below the unchanged 2,048MiB floor, and stopped. I therefore keep 64K as the practical desktop profile and 120K as conditional historical capacity, rather than presenting the advertised ceiling as a stable desktop setting. API/tool controls and a bounded Muse turn passed on that workstation. The separate OpenCode coding controls could read and rewrite the fixture, but did not execute its required test, including the declared 16-step control. They remain failed. The accepted role is chat, tools and bounded drafts checked by the primary assistant; autonomous read/edit/test coding is not established. None of these workstation controls supplies a new GB10 speed or quality result. What Four Machines Can Change Tensor parallelism splits a layer’s calculations across devices. Pipeline parallelism puts groups of layers on different devices. Independent replicas keep complete copies and serve separate requests. These arrangements answer different needs, even though they all use the cluster. A model distributed across more boxes can gain room for weights, context and concurrent sequences. It also needs communication between those boxes. Replicas avoid that communication within an individual reply, but extra replicas help only when separate requests overlap. A single user cannot consume four independent replies as if they were one reply generated four times faster. The new Coder configuration uses four independent replicas, each with a 262,144-token context. The earlier pair split Coder across two nodes. This is a useful comparison of installed configurations, but it does not isolate the effect of adding two computers. I have not run the equivalent full normal-gateway campaign with two tensor-parallel pairs, so I do not claim that the chosen layout is the fastest possible arrangement for every load. DeepSeek 1017 is another case. Its checkpoint is roughly 510GB, and this installation uses an NVMe-backed memory-table arrangement to leave operating headroom. Loading and using that arrangement on four boxes demonstrates a capability. It does not prove that two boxes could never run an offloaded version, or that fitting a larger model makes it the best interactive choice. The earlier article’s DeepSeek Flash-0731 and the new 1017 Heretic checkpoint must retain separate results. The four GB10s also share their GPUs between model serving and rendering. This installation admits those workloads in separate modes: a Blender or WAN job does not run alongside a four-node model campaign. I therefore do not add their separate benchmark rates together or treat the same four devices as two independent clusters. The Windows RTX 4090 and the separate Rendering PC are different resources.