A pricing pipeline misses its end-of-day deadline, and the first instinct is to add GPUs. Often the tensor cores are already there and idle, waiting on data that the interconnect could not deliver in time. In a scaled-out cluster the fabric between nodes — and the physical cabling that carries it — can starve compute that would otherwise be fully utilised. Direct Attach Copper (DAC) cabling is the short-reach, low-latency, low-cost option for in-rack GPU node interconnect, and treating it as a procurement afterthought rather than a measurable factor is where a lot of quant clusters quietly lose throughput.

This is not an argument that cabling is usually the culprit. It is an argument that you cannot know whether it is until you have profiled where the workload actually spends its time. The divergence point between a naive read and an expert one is exactly there: the naive read assumes the GPUs are the bottleneck because that is the component with a price tag attached to performance; the expert read measures whether the pipeline is compute-bound, memory-bound, or fabric-bound before spending a cent on either more GPUs or different cabling — it’s the first check we run before recommending any hardware change to a client.

What should you know about DAC networking in practice?

A DAC cable is a passive (or active) copper assembly with the transceiver connectors fused directly onto both ends of the wire. There is no separate optical module and no light-to-electrical conversion. The signal stays electrical from one switch or NIC port to the next, which is why DAC has both lower latency and lower power draw than an optical link over the same short distance. For in-rack GPU node interconnect — the links tying together servers in a single rack, or between two adjacent racks — this is the natural fit.

The practical meaning is straightforward. When two GPU nodes need to exchange partial results during a distributed calculation, that exchange traverses the NIC, the cable, and the switch. Every microsecond of that round trip is a microsecond the receiving GPU may be idle if it is blocked on the data. Over a full pricing run with thousands of synchronisation points, small per-hop costs compound. DAC removes the transceiver’s serialisation and optical-conversion overhead, so for reaches inside roughly three metres it delivers the lowest-latency path per NVIDIA and switch-vendor published specifications for their cable families.

The catch is reach. Copper attenuates the signal as distance grows. Passive DAC is typically specified for links up to around three metres at high line rates; active DAC extends that somewhat with in-cable signal conditioning, but the physics still favours optical once you are running between rows or across a room. That reach boundary — not brand preference — is the real decision axis.

What is the difference between DAC and optical links for GPU cluster interconnect?

Both carry the same protocol at the same nominal line rate. The difference is the medium and what it costs you in latency, power, reach, and money. An AOC (Active Optical Cable) or a transceiver-plus-fibre run converts the electrical signal to light, sends it down a fibre, and converts it back. That conversion buys you distance and immunity to electrical noise at the cost of added latency, added power per link, and a materially higher per-link price.

The comparison below frames the axes that actually decide the choice for a multi-GPU quant cluster. It is a decision surface, not a verdict — the right answer is whichever row matches your rack topology.

DAC versus optical for in-rack GPU interconnect

Axis	Passive/Active DAC	Optical (AOC / transceiver + fibre)
Typical reach	Up to ~3m (passive), a few metres more (active)	Tens of metres to hundreds
Latency added	Lowest — no optical conversion	Higher — electrical-to-optical-to-electrical
Power per link	Lowest	Higher (active optics draw power)
Per-link cost	Lower for the same short reach	Higher
Best fit	Nodes within one rack / adjacent racks	Cross-row, cross-room, cross-datacentre
Failure mode if misapplied	Signal loss beyond spec reach	Paying latency + cost tax on a short link

(Reach and power figures follow vendor-published cable specifications; treat them as the starting bracket for your own topology, not a benchmark of your workload.)

The misapplication in both directions is real. Stretch DAC past its reach spec and you get intermittent errors or a link that will not train up at the target rate. Use optical for every link including the sub-three-metre ones inside a rack and you pay a latency and cost tax on connections that never needed it. Neither failure shows up as “the GPUs are slow” — which is precisely why they get misdiagnosed as a compute shortfall.

When does the interconnect become the bottleneck rather than the GPUs?

The interconnect becomes the bottleneck when the workload’s communication-to-computation ratio is high enough that nodes spend meaningful time waiting on inter-node transfer. Distributed linear algebra — the sparse and dense matrix work at the heart of most pricing and risk calculations — has exactly this property when it is partitioned across nodes. A dense factorisation or a Monte Carlo aggregation that fans results back to a coordinator hits synchronisation points where the slowest link gates the whole step.

Three conditions push a quant pipeline toward fabric-bound behaviour. First, the partition size per node is small relative to the amount of cross-node communication, so compute finishes fast and then blocks. Second, the workload synchronises frequently — many small exchanges rather than a few large ones, which magnifies per-hop latency. Third, the interconnect is oversubscribed or mismatched to reach, adding avoidable delay to every one of those exchanges. When all three coincide, adding GPUs makes things worse: more nodes means more communication, not more effective throughput.

This is the same profile-first system-level throughput discipline that governs any GPU engineering decision — the interconnect is one component of an end-to-end path, and the component that is limiting the path is an empirical question, not a default. It is closely related to how choosing a GPU architecture shapes a quant compute pipeline: the architecture sets how fast a node computes, and the fabric sets how fast nodes can cooperate. Both matter, and which one binds depends on the workload.

What reach and cost trade-offs decide whether DAC is the right choice?

Two numbers dominate: the physical distance of the link and the number of links. Distance is a hard gate — if a node-to-node run exceeds the DAC reach spec at your line rate, optical is not a preference, it is a requirement. Below that gate, cost and power favour DAC decisively, and the savings scale with link count. A rack with dozens of GPU nodes and a dense east-west fabric has a lot of short links, and choosing copper for all of them that fit within reach compounds into real per-rack savings on both capital cost and power draw.

Quick decision rubric

• Link ≤ ~3m, same rack or adjacent: DAC. Lowest latency, lowest cost, lowest power. Default choice.
• Link a few metres, dense east-west fabric: Active DAC if within its extended reach spec; otherwise optical.
• Link across rows or rooms: Optical. Reach makes copper a non-option.
• Uncertain whether the link is even on the critical path: Profile first — do not buy cabling to fix a bottleneck you have not located.

The trap is optimising the cabling before confirming the fabric is what limits the pipeline. DAC saves cost and power and shaves latency, but if the workload is compute-bound, a lower-latency cable changes nothing measurable. The savings are worth capturing, but they are a cost-and-power optimisation, not a throughput fix, unless profiling shows the fabric is actually in the way.

How do you tell, through profiling, whether a workload is fabric-bound?

You instrument the pipeline and attribute time to the three resource classes: compute, memory, and fabric. In practice this means tracing where the GPUs stall. If tensor cores show high idle time coinciding with outstanding network transfers — visible in a communication trace via NCCL logging or a profiler that captures collective operations — the pipeline is waiting on the fabric. If the stalls coincide with memory-bandwidth saturation instead, the cabling is irrelevant and the fix lives elsewhere. If neither, the workload is compute-bound and more or faster compute is the lever.

A concrete way to read this: overlap the GPU utilisation timeline with the interconnect throughput timeline. When utilisation dips exactly when a collective operation (an all-reduce, a gather) is in flight, and the interconnect is running at or near its ceiling during those dips, the fabric is the constraint on that step. When utilisation dips but the interconnect is nowhere near its ceiling, the delay is coming from somewhere else — synchronisation logic, load imbalance, or the host. This is an observed diagnostic pattern from GPU cluster work rather than a single benchmarked threshold; the exact numbers are workload-specific, but the method of attribution is general.

This measurement discipline is where the portable GPU acceleration model that the OpenCL SDK exposes for finance workloads intersects with cluster design — the compute layer and the fabric layer are separately measurable, and a portable kernel that is fast on one node can still be gated by how nodes talk to each other. Profiling keeps those two questions apart.

How does interconnect choice affect end-of-day deadlines?

End-of-day deadline margin is the slack between when a pricing or risk run finishes and when the result is due. When a fabric-bound pipeline is starving its GPUs, that margin erodes because tensor cores sit idle waiting on transfers instead of retiring work. Matching the interconnect to the topology — DAC for the short in-rack links, optical only where reach demands it — removes the avoidable fabric latency from every synchronisation point, and on a communication-heavy run those savings accumulate into recovered wall-clock time.

The point worth holding onto is that this recovery comes without adding GPUs. When the bottleneck is the fabric, more compute cannot help — the extra nodes just add communication. Feeding the compute you already have, by getting the interconnect and the cabling right, is what lets scheduling reclaim deadline margin. That only works if the diagnosis is correct, which loops back to the profiling step: the cabling decision is downstream of the measurement, never a substitute for it.

FAQ

What does working with DAC networking involve in practice?

A DAC (Direct Attach Copper) cable fuses the connectors directly onto a copper wire, so the signal stays electrical end to end with no optical conversion. That gives it the lowest latency and lowest power draw over short reaches, which is why it is the natural fit for tying GPU nodes together inside a rack. In practice it removes the transceiver overhead from every inter-node exchange, and those small savings compound over a run with many synchronisation points.

What is the difference between DAC and optical (AOC/transceiver) links for GPU cluster interconnect?

Both carry the same protocol at the same line rate, but optical converts the signal to light to gain distance, at the cost of added latency, higher power per link, and higher price. DAC keeps the signal electrical, which is cheaper and lower-latency but limited to roughly three metres for passive cables. The deciding axis is reach: DAC for short in-rack links, optical once you run across rows or rooms.

When does the interconnect become the bottleneck in a multi-GPU quant pipeline rather than the GPUs themselves?

The fabric binds when the communication-to-computation ratio is high — small per-node partitions, frequent synchronisation, or an oversubscribed link. Distributed sparse and dense linear algebra in pricing and risk work has this property, so nodes finish compute quickly and then block on inter-node transfers. When those three conditions coincide, adding GPUs makes it worse because more nodes mean more communication.

What reach and cost trade-offs decide whether DAC is the right choice for in-rack GPU nodes?

Distance is a hard gate: beyond the DAC reach spec at your line rate, optical is required, not preferred. Below that gate, DAC wins on cost and power, and the savings scale with the number of short links in a dense rack. The trap is optimising cabling before confirming the fabric is what limits the pipeline — the savings are real but they are a cost-and-power win, not a throughput fix unless profiling shows the fabric is in the way.

How do you tell, through profiling, whether a distributed workload is fabric-bound before changing cabling or topology?

Instrument the pipeline and attribute stall time to compute, memory, or fabric. If GPU idle time coincides with outstanding collective operations while the interconnect runs near its ceiling, the fabric is the constraint; if the interconnect is idle during the stalls, the delay is elsewhere. This attribution method is general even though the exact thresholds are workload-specific.

How does interconnect choice affect whether multi-GPU scheduling hits end-of-day deadlines without adding hardware?

A fabric-bound pipeline erodes deadline margin because tensor cores idle waiting on transfers. Matching the interconnect to the topology removes avoidable fabric latency at every synchronisation point, and on communication-heavy runs those savings accumulate into recovered wall-clock time — without adding GPUs, which would only add communication. This only works when profiling has confirmed the fabric is the actual bottleneck.

Before deciding whether interconnect is starving your GPUs, a GPU Performance Audit shows whether a multi-GPU quant pipeline is fabric-bound, compute-bound, or memory-bound — so cabling and topology choices are made against measured behaviour rather than the assumption that the component with the biggest price tag must be the one holding you back.