NVIDIA Confirms Official Guide for Linking 2, 3, and 4 DGX Spark Units

NVIDIA has published an official document laying out how to cable together multiple units of DGX Spark, its compact AI computer. The guide clarifies a condition that wasn't previously spelled out: 2 or 3 units need only a cable, but 4 or more require a switch. Each DGX Spark has two QSFP (ConnectX-7) ports on the back capable of up to 200Gb/s, and units connect to each other by plugging cables into these ports.

To give some background, NVIDIA had previously pointed to a multi-unit DGX Spark setup for running AI locally through its official X account. At the time, it was merely reposting a guide created by an account called MiaAI_lab, so it left open questions like how many units could be connected and what cable specs were needed. This new user guide, published directly by NVIDIA, fills in those gaps with specific connection rules by unit count, a list of approved cables, and an automatic configuration tool.

NVIDIA also spells out the purpose behind linking multiple units in the document: splitting workloads too large for a single DGX Spark across several machines. It's a setup aimed at demand for chaining together laptop-sized devices to run larger models without relying on the cloud.

Connection rules by unit count

The wiring method follows a fixed pattern depending on how many units are involved. Mixing direct connections with switch-based connections isn't supported, and each link should use only one cable. The document notes that connecting two units with two cables instead of one won't improve performance.

Configuration	Connection method	Cables needed
2 units	Direct connection or via switch	1 (direct) / 2 (via switch)
3 units	Direct connection (ring topology) or via switch	3 (direct) / 3 (via switch)
4 units	Switch only	4 (one per device)

When three units connect directly, each device links to both of the other two, forming a ring topology. Starting at four units, direct connection isn't supported at all—a switch is mandatory.

Approved cables and port specs

NVIDIA advises using only QSFP cables rated for at least 200Gb/s. Using a faster cable won't help, since the ports themselves are capped at 200Gb/s. The two cables explicitly approved for Ethernet configurations in the document are Amphenol's NJAAKK-N911 (with a 0.5m version called NJAAKK0006) and Luxshare's LMTQF022-SD-R.

While the ports themselves are left/right compatible, NVIDIA's connection playbooks for 2-unit, 3-unit, and switch-based setups are built around specific ports, so it matters which one you plug into. Cables should be inserted with the pull tab facing up, and if a cable doesn't slide in smoothly, you should double-check orientation before pushing further. The document warns that forcing a cable in can damage the port.

Eight interfaces from one cable

Inside DGX Spark, the ConnectX-7 network controller connects the external QSFP port to the Grace Blackwell SoC through two independent PCIe Gen5 x4 links. As a result, a single port shows up in Linux as two separate Ethernet interfaces, and when you add the corresponding RoCE interfaces (used for InfiniBand-style communication), each port produces a total of four network interfaces. Cable up both QSFP ports, and that number doubles to eight.

This structure makes manual IP configuration tricky, since it requires understanding the mapping between PCIe addresses and interface names. NVIDIA's documentation includes a separate mapping table for exactly this reason—an implicit acknowledgment of how tedious this task is to handle by hand.

The tool handles networking; workloads are separate

Cluster Assistant, part of NVIDIA Sync, is designed to take this complexity off users' hands. As long as the cabling is correct, it automatically discovers connected devices, applies ConnectX-7 network settings, checks link performance, and even configures SSH between nodes. The tool's purpose is to let users skip needing any knowledge of networking or PCIe architecture.

That said, its job ends there. The document explicitly states that setting up actual workloads—like inference or fine-tuning—falls outside Cluster Assistant's scope. Once the network is in place, users need to layer workloads on top using separate playbooks for NCCL, vLLM, or PyTorch fine-tuning. Cluster Assistant supports direct connections for up to 3 units and switch-based connections for up to 4.

How to get started

1. Prepare cables: Get Amphenol NJAAKK-N911 or Luxshare LMTQF022-SD-R cables matching the number of units you're connecting.
2. Make the physical connection: Facing the back of each DGX Spark, plug cables into the QSFP ports with the pull tab facing up. If a cable doesn't slide in smoothly, recheck the orientation.
3. Register and update devices: Register each DGX Spark to an account in NVIDIA Sync and update the software to the latest version via DGX Dashboard.
4. Run Cluster Assistant: Launching Cluster Assistant within NVIDIA Sync automatically finds connected devices and completes network setup and SSH configuration.
5. Layer on workloads: Once the network is set up, choose from the NCCL, vLLM, or PyTorch fine-tuning playbooks to run actual workloads.

Editor's take

Back in early August, an X post from the NVIDIA AI account gave us little more than "apparently you can connect multiple units together." How many units, exactly, and what cables were needed—that was all left blank. Seeing how this new document fills that gap tells you something about NVIDIA's strategy: it's positioning DGX Spark not as a data-center supercomputer, but as personal AI infrastructure that scales on your desk. Keeping 2- and 3-unit setups possible with a single cable, while requiring a switch starting at 4 units, reads like a deliberate line—one meant to hold onto small labs and individual developers while nudging anyone scaling further into investing in networking gear.

Around the same time, Perplexity released a portable computer that runs on a single DGX Spark without cloud dependency, which fits the same pattern. With experiments already running orchestrators and sub-agent LLMs on a single piece of local hardware, the next option—once you need bigger models or more concurrent tasks—is exactly the clustering setup that just got documented. The path from starting with one unit to scaling up as needed is now, at least on paper, fully mapped out.

For development teams interested in local AI setups, the practical takeaway from this document is clear: Cluster Assistant does handle network configuration, but running actual distributed inference or training with NCCL or vLLM requires separate expertise. Before deciding to buy into a cluster, it's worth checking whether your team has someone who can work with these playbooks. Getting stuck on workload configuration after the network is already up is likely to be a more common problem than picking the wrong cable and falling short of 200Gb/s.

In the coming weeks, real benchmarks or hands-on reports based on this clustering documentation are likely to emerge. With NCCL and vLLM playbooks already referenced, comparing actual inference speeds across 2-, 3-, and 4-unit configurations feels like a natural next step.