How to Connect Two or Four DGX Sparks

If you have one DGX Spark and your model is close to its memory limit, buying a second box sounds simple. The hard part is what happens after you connect them. The model runner has to split the work, the high-speed link has to negotiate correctly, and someone has to prove that the result is actually faster or more capable than one machine.

NVIDIA's published examples use 128 GB systems; a 64 GB OEM option also exists. Name the memory tier of every unit in a quote. The two-machine connection comes first below, followed by what changes at four.

Two DGX Spark systems can connect directly through a supported QSFP cable without a network switch. For a guided four-system cluster, each DGX Spark connects to a compatible 200GbE switch using its high-speed ConnectX-7 interface.

NVIDIA Sync Cluster Assistant supports direct connections for two or three systems and switched configurations for up to four. A four-system direct ring is a separate manual configuration and is not supported by the guided Cluster Assistant.

Each DGX Spark has its own GB10 processor, memory, storage and operating system. NVIDIA's 128 GB configuration gives its CPU and GPU coherent unified memory within that single system. The ConnectX-7 network moves data between systems; it does not make their memory one flat pool that an ordinary application can address without modification.

For a larger model, distributed inference software divides model work across nodes and exchanges intermediate results over the network. NVIDIA's multi-node vLLM recipe, for example, runs a tensor-parallel rank on each system, with each rank holding part of the model. A framework that runs only on one node still sees that node's capacity. Operating system use, model overhead and the chosen context length also reduce the memory available for weights and active requests.

There is another way to use extra systems: run separate jobs or model replicas when each fits on one node. That can improve throughput or give researchers independent environments without paying the communication cost of splitting one model. NVIDIA says NYU's Global AI Frontier Lab runs its radiology-report evaluation workflow locally on a single Spark. That example is a useful reminder that node count follows the work, not the ambition of the project.

NVIDIA lists 256 GB of aggregate memory for two 128 GB DGX Spark systems and describes this configuration for larger-model inference and faster fine-tuning. Its product table cites inference on models up to 400 billion parameters. That is a platform example, not a guarantee for every checkpoint, precision, context window or serving framework.

Each Spark has two QSFP ports capped at 200 Gb/s. NVIDIA's current guide lists specific short Amphenol and Luxshare cables. A generic cable with the right connector or a 400G label is not automatically approved. Power and the management LAN remain separate from this high-speed link.

For a direct connection between two DGX Spark systems, NVIDIA lists three supported cable options: **Amphenol NJAAKK-N911 (0.4 m)**, **Amphenol NJAAKK0006 (0.5 m)**, and **Luxshare LMTQF022-SD-R (0.4 m)**. These part numbers are specific to the direct Spark-to-Spark connection. Before purchasing, check NVIDIA's latest compatibility guidance rather than relying on connector type or advertised cable speed alone.

Need to source the cable for your DGX Spark setup? Uniqcli's DGX Spark Cables and QSFP Finder lets you explore available cables by length, rated speed and connector type. For a direct two-system connection, confirm the NVIDIA-listed part number before ordering. For switched configurations, verify the complete cable and switch connection path.

A pair is a sensible first quote when one 128 GB system cannot hold the intended model, when a tested two-rank serving recipe exists, or when a team wants two development nodes that can also be linked. Ask for a pilot with the intended model and prompt length before assuming a two-node design meets a latency target.

NVIDIA lists 512 GB of aggregate memory for four 128 GB Sparks and illustrates inference on models up to 700 billion parameters. Here is the guided connection path, not a promise that every 700B checkpoint will fit or run well.

The Spark-facing switch links need the right port mode, cabling and Layer 2 setup. NVIDIA's listed direct-attach cables are only 0.4–0.5 m; if those do not reach your planned switch placement, have the OEM and switch team validate the full cable or transceiver path before ordering. The ordinary LAN remains necessary for device discovery and management.

Four nodes make sense when the model or workload has a validated distributed path, the team needs more aggregate capacity than a pair provides, or independent jobs can keep four systems busy. More nodes can also increase communication and operational work. Compare performance with the same model, precision, input length, output length, concurrency and serving stack at each size. Check both throughput and the latency a user actually experiences.

NVIDIA's vLLM playbook supports a guided two-to-four-Spark path, though its worked command-line example currently covers a pair. Require a demonstrated four-node launch of your actual model rather than assuming the network test proves the application works.

NVIDIA's newer cabling playbook also documents a four-cable direct ring. Cable Spark 1 port 0 to Spark 2 port 1; Spark 2 port 0 to Spark 3 port 1; Spark 3 port 0 to Spark 4 port 1; and Spark 4 port 0 back to Spark 1 port 1. Each Spark then has both QSFP ports occupied. Opposite nodes have no direct cable.

This ring is not a four-node NVIDIA Sync Cluster Assistant topology. NVIDIA's manual playbook has you list the four management IPs in cable order, dry-run its network helper, apply the plan, then run its doctor check. Use that playbook and an integrator comfortable with network and SSH changes; do not select four directly connected devices in Sync and expect the guided wizard to configure them.

Give the supplier enough information to quote a working configuration and an acceptance test. The following checklist keeps a small cluster purchase from becoming four boxes with unresolved networking and software work.

If the application depends on x86-only software or a specific distributed framework version, say so before ordering. A compatible model checkpoint is only one part of a working deployment. The cable lengths most buyers find in broad network catalogs are not the short lengths NVIDIA currently lists for direct Spark approval. If the machines must sit farther apart, have the fabric and OEM teams validate the proposed topology and cable.

These catalog listings are individual 128 GB DGX Spark systems, not a prevalidated pair. Order the supported interconnect and any switch as part of a reviewed cluster configuration.

Bring the model and workload, node count, software stack, required date and deployment location. Uniqcli can put the systems, fabric, software and integration requirements on one scoped quote, then identify the tests needed to accept the build.