DGX Spark Interconnect Reference: NJAAKK-N911, NJAAKK-0006 and LMTQF022-SD-R

What the approved DGX Spark stacking cables are, what they actually deliver, and what to buy at two, three and four or more nodes.

Maintained by Resilient Tec · last verified 13 October 2026 · see also our NVIDIA DGX Spark Interconnect Compatibility Matrix · troubleshooting

Short answer

NVIDIA names two manufacturers for the DGX Spark direct-connect cable, across two lengths. All of them are the same specification — QSFP112 passive copper — and any of them works:

  • Amphenol NJAAKK-N911 — QSFP to QSFP112, 32AWG, 400 mm, LSZH.
  • Amphenol NJAAKK-0006 (also written NJAAKK0006) — the 0.5 m version of the same cable.
  • Luxshare LMTQF022-SD-R — QSFP112 400G DAC, 400 mm, 30AWG.

If you have seen several of these numbers and wondered which you need: you need one cable. The part numbers differ by manufacturer and by length, not by quality or capability. Length is the only thing that actually separates them — see the decoder below.

Because the Spark's ports run at 200 Gb/s, a 200G QSFP56 passive DAC from NVIDIA's MCP1650-V family also works in practice, and it comes in more lengths: 0.5 m, 1 m, 1.5 m, 2 m and 3 m.

Identification

Amphenol part number NJAAKK-N911 (400 mm) · NJAAKK-0006 / NJAAKK0006 / SF-NJAAKK0006-000.5M (0.5 m)
Luxshare part number LMTQF022-SD-R (400 mm)
Compatible-market numbers NJAAKKR-0006 and similar variants — compatible builds rather than OEM parts. See the decoder.
Also sold as PNY DGX Spark Stacking Cable · "NVIDIA DGX Spark Connect Cable" · "Spark stacking / cluster cable" · DGX Spark Founders Edition kit 940-54242-0000-000
Connector QSFP112, both ends
Cable type Passive direct attach copper (DAC). No transceivers, no power, no firmware.
Rated 400G (4 × 100G lanes)
Delivered on DGX Spark Up to 200 Gb/s per port — see throughput
Conductor gauge 32AWG (Amphenol) · 30AWG (Luxshare)
Jacket LSZH (Amphenol)
Host port ConnectX-7, QSFP, on GB10-based systems
Port mode Ethernet only. The QSFP ports do not run native InfiniBand.

Part number decoder

This is the single most common point of confusion on this cable, and it costs people returns. Several numbers circulate, they are not interchangeable, and the thing that separates them is length.

Part number Length Source What it is
NJAAKK-N911 400 mm (1.3 ft) Amphenol NVIDIA-listed approved cable — the short version
NJAAKK-0006 · NJAAKK0006 · SF-NJAAKK0006-000.5M 0.5 m (1.6 ft) Amphenol NVIDIA-listed approved cable — the 0.5 m version
LMTQF022-SD-R 400 mm (1.3 ft) Luxshare NVIDIA-listed approved cable — Luxshare equivalent
NJAAKKR-0006 0.5 m (1.6 ft) compatible market A compatible-market spelling of the 0.5 m part

Compatible builds vs OEM parts

Alongside the genuine Amphenol and Luxshare parts, the market carries compatible QSFP112 passive DACs — often under lightly modified spellings of the same numbers. From a reputable source these meet the same electrical specification and work normally in DGX Spark and GB10 systems, but they are not the OEM part, and any vendor blurring that line is one to avoid.

What Resilient Tec stocks: a compatible NJAAKK-N911 build at 0.5 m, matching the specification of the Amphenol NJAAKK-0006. See the listing. If you need a genuine OEM part number for procurement reasons, ask us to source it rather than substitute.

Note also that compatible suppliers frequently apply the N911 family number to a 0.5 m cable, even though Amphenol's own N911 is the 400 mm part. Always buy on stated length, not on the part number alone.

Compatibility

Any GB10-based system exposing the ConnectX-7 QSFP ports takes the same cable. The DGX Spark design is licensed to several OEMs, and the interconnect does not change between them.

System Ports Cable
NVIDIA DGX Spark 2 × QSFP (ConnectX-7) Yes
ASUS Ascent GX10 2 × QSFP (ConnectX-7) Yes
Dell Pro Max with GB10 2 × QSFP (ConnectX-7) Yes
HP ZGX Nano AI Station 2 × QSFP (ConnectX-7) Yes
Standard QSFP-DD switch port QSFP-DD Yes — QSFP-DD cages accept QSFP plugs. Pin the port to 200G. The 0.5 m stacking cable is usually too short to reach a switch, so use a 1–3 m Ethernet-coded 200G DAC: MCP1650-V001E30, 1 m ($97), MCP1650-V01AE30, 1.5 m ($104), MCP1650-V002E26, 2 m ($115) or MCP1650-V003E26, 3 m ($145).

Throughput: what you actually get

The cable is rated 400G. A DGX Spark port tops out at 200 Gb/s. NVIDIA's own guidance is simply to use cables known to deliver at least 200 Gb/s — a faster cable buys you nothing here.

The more useful detail, which is not obvious from any spec sheet: GB10 connects to the ConnectX-7 over two PCIe Gen5 x4 links rather than one wider link, because the GB10 silicon cannot present a wider-than-x4 interface per device. Each x4 link is roughly 100 Gbps, and the NIC runs in multi-host mode to aggregate them. The operating system sees four network interfaces behind two physical ports.

Plan for it as 2 × 100G, not 2 × 200G. Independent testing with RoCE and parallel streams measured 185–190 Gbps in practice. Bind your interfaces carelessly and the same hardware delivers 80–100 Gbps — not a cable fault, and no cable will fix it.

What to buy, by cluster size

Spark 1 Spark 2 1 × DAC, port 0 to port 0 2 nodes — no switch

Two nodes. One cable, port 0 on each unit. This is the case the approved cable list exists for. Buy one NJAAKK-N911, NJAAKK-0006 or LMTQF022-SD-R and you are done — or the lower-cost 200G MCP1650-V00AE30 ($79), with 1 m and longer versions if the units are not side by side.

Spark 1 Spark 2 Spark 3 3 nodes — ring, 3 cables, both ports per unit, still no switch

Three nodes. Three cables in a ring, using both QSFP ports on every unit. Still no switch. This is the configuration most people do not realise is supported, and it is the last one that is. Three MCP1650-V00AE30 cables ($237) work too; if the units are spread across a shelf, the 1 m MCP1650-V001E30 gives slack.

Four nodes, switchless (unsupported). Owners have run four units as a ring: four of the same cable, each unit's two ports wired to its two neighbors. It needs a custom NCCL build and topology plan, and NVIDIA does not support it. In a rack, cable it folded — 1→2→4→3→1 — so no hop spans more than two units and 0.5 m cables still reach; on separate shelves, 1 m cables are the safer buy. Details and measured numbers →

400G managed switch Spark 1 Spark 2 Spark 3 Spark 4 4+ nodes — QSFP-DD to 2 × QSFP56 breakout, switch ports pinned to 200G

Four or more nodes, supported. A managed switch is the supported route at four nodes and the only route past four — and the 0.5 m stacking cable stops being the answer. Switch ports are usually QSFP-DD, which accepts QSFP plugs, so you have two options: one straight Ethernet-coded 200G QSFP56 DAC per Spark (1 m, 1.5 m, 2 m or 3 m), or QSFP-DD to dual-QSFP56 breakout cables (1 m, 1.5 m, 2 m or 3 m) when the switch has fewer 400G ports than you have nodes. Each breakout uses one switch port and feeds two Sparks: two breakouts serve four nodes, and four fill a four-port switch for eight.

The mistake that costs 75% of your bandwidth

After cabling a switch, set each connected port to 200 Gbps manually. Left on auto-negotiate, these links commonly settle at 50 Gbps. The cluster works, nothing errors, and you quietly lose three quarters of your fabric. Check it before you benchmark anything.

Troubleshooting: link errors and low throughput

Most "bad cable" reports on GB10 systems turn out not to be the cable. Work through these before you send anything back.

Symptom Likely cause Fix
pcieport 0004:00:00.0: AER: Correctable error ... RxErr in dmesg after plugging in a cable, on one unit only Host side, not the cable. These are correctable errors on the internal PCIe link between GB10 and the ConnectX-7, not on the QSFP link. If they stay on the same unit when you swap cable ends, the cable is not the cause. Let any pending firmware update finish completely (a first boot after an update can take 30+ minutes). Make sure both units run the same software version, then cold boot. A few correctable errors during link bring-up are generally harmless; a steady stream after a cold boot on current firmware is worth a support ticket with the system vendor.
Link comes up at ~25 Gbps instead of ~185–200 Gbps The ConnectX-7 interfaces did not initialize correctly after a warm reboot or a hot-plug. Cold boot both units: a full shutdown and power-on, not a restart. Then confirm with ethtool <interface> | grep Speed, which should report 200000Mb/s.
Driver errors or the interface disappears after plugging a cable into a running system Hot-plugging the QSFP ports. Owners report the driver can crash when a cable is inserted while the system is running. Connect cables with both units powered off, or reboot (cold) after cabling.
Link is up, but only 80–100 Gbps Only one of the two PCIe x4 paths behind the port is in use. Configure all the interfaces the OS shows for that port. See throughput.
Behind a switch, links sit at 50 Gbps with no errors Switch port left on auto-negotiate. Pin each Spark-facing switch port to 200G.
Link won't come up, or ethtool -m <interface> can't read the module Possibly the cable: a damaged unit or a third-party cable with bad EEPROM programming. Reseat both ends, then test with a known-good cable. Only at this point is a cable swap the right fix.

Do I need QSFP112, or will a QSFP56 cable do?

Either works. A Spark port runs at 200 Gb/s, so a 200G QSFP56 DAC (Ethernet-coded MCP1650-V00AE30) and the 400G QSFP112 stacking cable reach the same ~185–200 Gbps once the units are cold-booted and configured. If switching to a different cable seemed to fix your link, check whether the reboot that came with the swap was the actual fix.

Selection summary

Nodes Switch What you need
2 No 1 × NJAAKK-N911 (400 mm), NJAAKK-0006 (0.5 m) or LMTQF022-SD-R (400 mm) — or 1 × MCP1650-V00AE30 (0.5 m, 200G)
3 No 3 × the same cable, ring topology
4 No — unsupported 4 × the same cable, folded ring, custom NCCL topology
4–8 Yes 400G managed switch + one MCP1650-V 200G DAC per node (1–3 m), or QSFP-DD to 2 × QSFP56 breakout DACs (2 for 4 nodes, 4 for 8), ports pinned to 200G
Citing this page. If you sell or support GB10 systems and want to reference this compatibility data on your own product pages, you are welcome to — a link back to this page is all we ask. If you find something here that is wrong or out of date, tell us and we will correct it.

Sources