A direct-attach copper cable is one of the cheapest ways to connect two GPUs in a rack, and that price tag is exactly why it gets treated as a free decision. It is not free. The interconnect is a variable in the same cost-per-request model you already run on serving configs — and the moment you treat it that way, the DAC-versus-optics question stops being a wiring detail and starts behaving like a batching decision.

Here is the trap most teams walk into. You pick the GPUs, you size the memory, you tune the serving runtime, and then someone hands the rack diagram to a network engineer who quietly specs passive DAC because it is the cheapest link that closes. Cheaper per link, lower power, no transceiver to fail — all true. What the diagram doesn’t show is that passive copper caps you at a few metres, and that reach limit quietly fixes your topology. A fixed topology fixes how you place replicas and how many GPUs sit inside one low-latency collision domain. And that, in turn, sets a floor on the p95 latency you can hit at a given concurrency. The interconnect didn’t just save money on cabling. It reached into your batching sweet spot and changed the shape of your cost-per-token curve.

How do DAC cables actually work, and why does the reach limit matter?

A DAC (direct-attach copper) cable is a fixed assembly: a copper twinax cable with the connector modules permanently attached at both ends. There is no separate optical transceiver, no light, no fibre — the electrical signal travels the copper directly from one switch or NIC port to the next. That is the whole appeal. You are not paying for a laser, a photodetector, and the digital signal processing that comes with optics.

The physics that makes it cheap is also what limits it. Copper attenuates a high-speed serial signal quickly, and the higher the per-lane rate, the shorter the reach. At the 400G and 800G links common in current AI clusters, passive DAC typically tops out around 3–5 metres before the signal integrity degrades past what the link can recover (vendor-published reach figures; treat exact numbers as spec-sheet values that vary by lane rate and cable gauge — claim class: benchmark, source is the manufacturer datasheet). Active DAC adds a small amount of signal conditioning to stretch that a little further; active optical cables (AOC) and pluggable optical transceivers push reach into the tens or hundreds of metres because light does not attenuate the same way over the distances that matter inside a data hall.

So the practical hierarchy is: passive DAC is cheapest and lowest power but shortest reach; active DAC buys a bit more distance at a bit more cost and power; AOC and optics buy long reach at meaningfully higher per-link capital and power draw. None of that is controversial. What matters is the second-order consequence nobody writes on the rack diagram.

What is the difference between passive DAC, active DAC, and active optical cables in a GPU cluster?

The three options are usually presented as a price ladder. They are better understood as a reach-and-power ladder, because reach is what constrains your topology and power is what shows up on the recurring bill.

Interconnect option comparison (rack-scale, AI cluster context)

Dimension	Passive DAC	Active DAC	Active Optical / Optics
Signal medium	Copper twinax, no active components	Copper + signal conditioning	Fibre + optical transceiver
Typical reach	~3–5 m at 400/800G	~5–7 m (lane-rate dependent)	tens to hundreds of metres
Per-link capital cost	Lowest	Low–moderate	Highest
Per-link power draw	Near zero (passive)	Low	Moderate to high (laser + DSP)
Failure surface	Cable only	Cable + conditioning	Cable + transceiver optics
What it constrains	Topology and replica placement	Slightly looser topology	Placement freedom

Reach and power figures are drawn from vendor datasheets (claim class: benchmark, source-named as manufacturer specs); the per-link cost ordering is an observed-pattern across the deployments we have reviewed, not a fixed price ratio.

The column that decides your serving economics is the last one. Passive DAC’s reach limit means every GPU that has to talk to every other GPU on a fast path has to physically sit within a few metres. That works beautifully inside a single rack or a tightly coupled pod. It breaks the moment your topology wants a replica two racks away, because now you either accept an extra network hop or you spend on optics to keep the fast path intact.

When does the reach limit force a topology change that hurts latency?

This is the divergence point. Imagine a serving config that batches concurrent requests across a set of GPUs and hits its lowest cost-per-token at, say, a concurrency where p95 latency stays under your service-level target. That sweet spot depends on how quickly tensors move between the GPUs doing tensor-parallel or pipeline-parallel work. Keep those GPUs inside one low-latency domain and the batching curve is smooth. Push some of them across a reach boundary — because passive DAC couldn’t span the distance and the topology was redrawn to compensate — and you introduce an extra switch hop or a slower link on the critical path.

An extra hop is a few microseconds of switching latency, which sounds trivial. It is not trivial when it lands on the tail. p95 is a tail metric, and tail latency is where batching decisions live. Once the tail creeps past your target at the concurrency you were batching at, you are forced to drop to a lower concurrency to stay inside the SLO — and lower concurrency means fewer requests amortising the same fixed GPU cost, which is precisely the definition of a cost-per-request regression. The config that looked cheaper on the cabling BOM is now more expensive per token served.

We see this pattern regularly: a latency regression that nobody attributes to the interconnect because the interconnect was decided months earlier by a different team, under a cost lens that only counted the link. Quantifying it requires the per-config latency measurement that GPU profiling supplies when you instrument the serving path — you cannot reason about how topology shifts p95 without measuring p95 at the topology you actually deployed.

How does interconnect choice show up in a cost-per-request comparison?

The reframe is simple to state and easy to skip: put the interconnect inside the same cost-per-request model you already use to compare serving configs, instead of parking it in a fixed-overhead line you never revisit.

A cost-per-request comparison has three moving parts that the interconnect touches directly:

• Per-link capital, amortised over the cluster’s life, which passive DAC minimises.
• Per-link power, a recurring cost where passive copper genuinely wins because it draws almost nothing.
• The p95 latency delta at your benchmarked concurrency, which is where optics can win back everything the copper saved by keeping your batching sweet spot intact.

The first two favour DAC and are easy to count. The third is the one that decides the outcome and the one teams routinely omit, because it only appears when you measure latency at the concurrency you actually serve at rather than at a link’s idealised spec. This is the same discipline that governs how machine learning compilers earn their keep by cutting cost-per-request in production: the win is real but only visible once you measure against the deployed serving path, not the datasheet.

Worked example: when the cheaper copper is the wrong choice

Assume — illustratively — a serving cluster where passive DAC saves a modest per-link capital and power amount versus optics, and where the DAC-imposed topology adds one switch hop to the tensor-parallel path for a subset of replicas.

• If that extra hop keeps p95 under the SLO at your target concurrency, DAC wins outright: you banked the capital and power savings for no latency cost.
• If that extra hop pushes p95 over the SLO, you drop concurrency to recover the tail. Suppose you have to serve at, for example, 70% of the concurrency you would have run inside a single low-latency domain. The same GPUs now amortise across ~30% fewer concurrent requests. Cost-per-request rises by roughly that inverse — comfortably more than the cabling saved.

(The numbers here are explicitly illustrative framing, not a benchmarked result; the point is the direction, not the magnitude. Your real crossover depends on the p95 you measure at your concurrency.)

The lesson is not “optics always” or “DAC always.” It is that the crossover is decided by a number you have to measure, not assume. Within a single rack where every fast-path GPU sits inside the reach envelope, passive DAC is frequently the correct, disciplined choice — cheaper capital, lower power, fewer failure points, no latency penalty. The moment the topology wants to cross the reach boundary, you re-run the cost-per-request comparison with the p95 delta included and let the number decide.

How do you fold interconnect cost and latency into a defensible serving-config selection?

Treat the interconnect as one more knob in the config, alongside the runtime, the batch size, and the parallelism strategy. The same rigour that produces a defensible serving choice on the compute side — the kind of measurement discipline behind a cost-per-request serving benchmark walkthrough — extends cleanly to the wiring. Fix your SLO, measure p95 at the concurrencies you care about under each candidate topology, and price the interconnect line item with all three parts (capital, power, latency-driven concurrency change) in the same model.

This is exactly the kind of margin gap our [inference cost-cut engagements](Inference Cost-Cut Pack) look for: the interconnect reach and latency feed the same before/after cost-per-request the sprint measures against a buyer’s deployed serving path. For teams building on the platform side, the broader context lives in our work on AI infrastructure for SaaS, where interconnect topology and serving economics are two views of one bill.

FAQ

What should you know about dac cables in practice?

A DAC (direct-attach copper) cable carries the electrical signal directly over copper twinax with the connectors fixed at both ends — no optical transceiver, no fibre. In practice that means it is the cheapest, lowest-power way to connect two ports over a short distance, which is why it dominates intra-rack GPU wiring. The catch is that copper attenuates fast, so its reach is limited to a few metres.

What is the difference between passive DAC, active DAC, and active optical cables in a GPU cluster?

Passive DAC is plain copper with no active components: cheapest, lowest power, shortest reach (roughly 3–5 m at 400/800G per vendor datasheets). Active DAC adds signal conditioning to stretch reach a little at slightly higher cost and power. Active optical cables and pluggable optics use light to reach tens to hundreds of metres, at meaningfully higher per-link capital and power. The ladder is really about reach and power, not just price.

When does the reach limit of DAC cables force a topology change that affects inference latency?

When a serving topology wants two fast-path GPUs to sit farther apart than passive DAC can span, you either add a switch hop or switch to optics. The extra hop lands on the latency tail, and once p95 creeps past your SLO at your target concurrency, you are forced to drop concurrency — which raises cost-per-request. That is the point where a copper decision made on the cabling BOM starts shaping your serving economics.

How does interconnect choice show up in a cost-per-request comparison rather than as a fixed overhead?

By putting it inside the model with three moving parts: per-link capital (DAC wins), per-link power (DAC wins), and the p95 latency delta at your benchmarked concurrency (where optics can win everything back). The first two are easy to count and favour copper; the third only appears when you measure latency at the concurrency you actually serve at, and it is the one that decides the outcome.

How do DAC vs optical links compare on per-link capital cost and power draw at rack scale?

Passive DAC has the lowest per-link capital and draws close to zero power because it has no active components; optics carry a laser and DSP, so both capital and recurring power are higher. The exact ratios come from vendor datasheets and vary by lane rate and reach, so the ordering is reliable but the magnitude should be priced against your own quotes rather than assumed.

When is the cheaper DAC option the wrong choice because it raises p95 latency below your batching sweet spot?

It is the wrong choice when the reach limit forces a topology that adds a hop or a slower link on the critical path, pushing p95 past your SLO at the concurrency where your cost-per-token bottoms out. Dropping concurrency to recover the tail spreads the same fixed GPU cost over fewer requests, and that cost-per-request rise typically exceeds the cabling savings. If the fast-path GPUs stay inside the reach envelope, none of this applies and DAC is the right call.

How do you fold interconnect cost and latency into a defensible serving-config selection?

Treat the interconnect as a config knob alongside runtime, batch size, and parallelism. Fix the SLO, measure p95 at your real concurrencies under each candidate topology, and price the interconnect with all three parts — capital, power, and latency-driven concurrency change — in the same cost-per-request model you use for the compute side. Let the measured number decide the crossover instead of the cabling BOM.

Interconnect selection is not a place for a default. The honest question to close on is not “copper or optics” but “what p95 do I actually measure at my serving concurrency under each topology, and where does that number move my cost-per-request?” Answer that with a measurement rather than an assumption, and the DAC-versus-optics decision resolves itself the same way every other serving-config knob does.