NVIDIA DGX Spark: two nodes together, and what it does beyond language models

Why anyone links two of them

Our first DGX Spark article ended on the limit that defines the machine: 273 GB/s of memory bandwidth, which caps single-user generation on a dense 70B model at a few tokens per second. The second unit does not raise that ceiling. What it does is double the memory to 256 GB, which changes the question from “how fast” to “whether at all”. Models that do not fit one unit, from a 70B in FP16 to a 235B mixture-of-experts in NVFP4, become loadable. That is what NVIDIA sells the second cable for, and it is the only reason to buy it.

How the link actually works

Each unit has two QSFP ports on its ConnectX-7 controller. The port is rated at 200 Gbit/s, but the controller connects to the GB10 chip through two independent PCIe Gen5 x4 links, and each QSFP port appears in Linux as two Ethernet interfaces, each with its own RoCE device. NVIDIA’s own performance guide measures 92.57 and 97.28 Gbit/s across the two logical links, 189.85 Gbit/s combined. In practice, treat the pair as two 100G links rather than one 200G link; the cluster assistant checks for a lower bound of 184 Gbit/s and flags anything below it.

One approved QSFP112 direct-attach cable between the two units is all the wiring needed; NVIDIA states that full bandwidth is reached with a single cable. Two or three units can be cabled directly; four need a switch with QSFP56-DD ports at 200 Gbit/s or more. The NVIDIA Sync Cluster Assistant supports two to four units, runs the link checks and the speed test, and stops there: it does not set up the workload.

What NVIDIA supports, and what it claims

The playbooks are explicit about the software. For vLLM, a Ray cluster with tensor parallelism across the two units over the QSFP link. For TensorRT-LLM, OpenMPI with a tensor-parallel size of two, using the Qwen3-235B-A22B-FP4 recipe. For training, NVIDIA’s January 2026 update describes distributed fine-tuning of models up to 70B parameters across two units with FSDP and LoRA.

The marketing line has moved with the software. The launch page spoke of two units working with models of up to 405 billion parameters; the current page says up to four units and up to 700 billion. Both are capacity statements about memory, not promises about speed.

Measured two-node numbers

Two lessons sit in that table. First, the two-node link is slow enough that pipeline parallelism, which sends activations across the link once per pipeline stage, beats tensor parallelism, which synchronises at every layer: 555 against 252 tokens per second on the same model. Second, single-stream generation on a 235B or 320B model lands at 12 to 15 tokens per second, which is usable for one engineer and useless for a team. The second unit buys capacity, not speed.

Beyond language models

The GPU is a Blackwell part with fifth-generation Tensor Cores, and for anything that is not bandwidth-bound decoding it performs like one.

Image generation is where the machine surprises people: a 1K FLUX image every 2.6 seconds is a working pace for a design team, and the 128 GB means the FP16 weights of the large diffusion models load without offloading tricks. Video is where it does not: the desktop RTX 5090 with a fraction of the memory finishes the same Hunyuan clip in a third of the time, because video generation is compute-heavy and the GB10 has roughly a quarter to a third of the desktop card’s Tensor throughput, on top of laptop-class memory bandwidth.

Fine-tuning lands between the two. QLoRA on a 70B model at 760 tokens a second is slow by data-centre standards and entirely practical for an overnight run on a few thousand documents, which is what most corporate fine-tuning actually is. Robotics is supported in the sense that Isaac Sim and Isaac Lab build from source for aarch64 and NVIDIA publishes a playbook; it is not a click-to-run environment.

The whole time, the unit idles at about 35 W and draws around 160 W at the wall under GPU load. It is the quietest way we know to run these numbers.

The gaming question

It comes up in every second conversation, so here is the position. DGX OS is Ubuntu on Arm. There is no Windows, and NVIDIA makes no statement supporting games on the product. Enthusiasts have made it work through x86 emulation: Cyberpunk 2077 at around 50 frames per second at 1080p medium through Box64 and Steam, and Canonical’s Steam snap with FEX and Proton reaching 75 frames per second at 1080p low. It is an experiment, not a feature, and the driver stack that makes it possible can change without notice.

NVIDIA’s actual answer to the question is a different product. RTX Spark, shown at Computex 2026 with the same 6,144 CUDA cores, the same 20-core Grace CPU and 128 GB, runs Windows on Arm and is announced for later this year. If the requirement is a desktop that games and also runs local models, wait for that one. If the requirement is a development box for models, the DGX Spark is the right tool, and the question answers itself.

What it is for

NVIDIA’s own framing has not changed: run inference on models up to 200 billion parameters and fine-tune models up to 70 billion, locally, for development and validation. Two units extend the first number and make the second comfortable. Neither replaces a server with a real GPU when the model goes into production in front of users, and the bandwidth figures above are the reason. Our engineering partner Vixen.UNO uses the Spark as a prototyping station and sizes the production system separately; the two questions have different answers.

FAQ