A cable is a cable, until it isn’t. When a bill of materials treats the interconnect between GPU rendering tiers as an interchangeable line item — pick the cheapest part that fits the port — the reasoning has already gone wrong. An active optical cable (AOC) is not a passive wire that happens to be more expensive. It is a small integrated system: a transceiver at each end converts the electrical signal to light, carries it as photons over fiber, and converts it back. That distinction is exactly what determines whether a link holds full rate across a rendering farm or quietly falls back and injects tail latency nobody budgeted for.

The reason this matters is that the interconnect choice sits directly on the critical path of a latency-bound pipeline. For a real-time system such as an AR try-on backend leaning on cloud rendering, an under-specced link does not fail loudly. It negotiates a lower rate, flaps under load, or throws signal-integrity errors — and those show up downstream as intermittent slow frames and failed sessions, not as a cable alarm. Getting the cable class right before the build is the difference between a stable latency floor and a problem you chase for weeks in production.

How does an active optical cable work in practice?

Physically, an AOC looks like any other cabled assembly: a connector on each end, a flexible run of cable in between. The difference is inside the connector housings. Each end integrates an electrical-to-optical transceiver — a laser or VCSEL driver on the transmit side, a photodiode and receiver on the other. The signal travels the middle section as modulated light over glass or polymer fiber rather than as electrical current over copper conductors.

That has two immediate consequences. First, the cable is directional and self-contained: the optics are permanently coupled to the fiber, so an AOC ships as a fixed-length assembly rather than an optical module you plug a separate fiber into. Second, because light over fiber does not suffer the same frequency-dependent attenuation and crosstalk that limit copper, the signal holds its integrity over far longer reach at the same data rate. The transceivers draw power to do the conversion — this is the “active” in active optical cable — which is why an AOC is not passive the way a short copper twinax assembly is.

In practice, you specify an AOC by three things: the connector form factor (QSFP, QSFP-DD, OSFP and so on), the negotiated line rate it supports (100G, 200G, 400G), and the reach. The reach is where the whole decision turns, because that is the number copper cannot match.

What is the difference between an active optical cable (AOC) and a direct attach copper (DAC) cable, and when should each be used?

Direct attach copper (DAC) is the passive counterpart. A DAC is a twinax copper assembly with the same connector form factor but no active transceivers — the electrical signal travels the copper directly. It is cheaper, draws essentially no cable-side power, and for short runs it is the correct choice. The trade-off is reach: copper’s signal-integrity budget shrinks as data rate climbs, so the higher the line rate, the shorter the copper run that still holds full rate.

The clean way to reason about it is that DAC owns the same-rack, sub-3-metre link, and AOC owns everything the copper wall pushes it out of. We treat the crossover as a topology question, not a price question. If you want the copper-side mechanics in depth, our explainer on how direct attach copper cabling behaves in GPU clusters walks through where the twinax budget runs out.

AOC vs DAC: a decision table

Factor	DAC (passive copper)	AOC (active optical)
Signal medium	Electrical over twinax copper	Light over fiber
Active transceivers	None	Integrated at both ends
Typical viable reach	Sub-3 m at high line rates	Roughly 3–100 m
Cable-side power	Negligible	Draws power for optics
Relative unit cost	Lower	Higher per assembly
Best fit	Same-rack, top-of-rack to node	Multi-rack, spine-to-leaf, render tier to render tier
Main failure risk if misused	Marginal reach → link flaps, rate drops	Overkill on a short run (cost/power only)

(General engineering guidance; specific reach limits depend on the line rate, connector standard, and vendor implementation — confirm against the transceiver’s published specification.)

The asymmetry in that last row is worth pausing on. Over-specifying — putting an AOC on a 1-metre same-rack hop — costs you money and a little power, but the link works. Under-specifying — stretching copper past its reach at 400G — costs you a link that appears to work at bring-up and degrades under sustained traffic. One failure is a line-item you can see; the other is a latency ghost.

At what reach and bandwidth does copper stop being viable and AOC become necessary?

There is no single hard threshold, because the copper wall moves with the line rate. The pattern is directional and consistent: as you double the per-lane signaling rate, the reach copper can sustain at full rate roughly halves. At the modest rates of a decade ago, copper stretched comfortably across a row. At 400G and beyond, passive copper is essentially a within-rack medium.

So the practical rule is a two-axis check, not a single number. Ask both how far and how fast. A 2-metre link at 100G is comfortable copper territory. The same 2-metre link at 400G is near the edge and worth validating. Anything crossing racks — spine-to-leaf, or one render tier to another across a row — is AOC territory at any modern rate. Per NVIDIA’s published specifications for its ConnectX-class NICs, high-rate links are designed with both DAC and AOC options precisely because the reach envelope differs; our note on the 800G ConnectX-8 NIC and when interconnect actually matters covers how the NIC side of that budget behaves.

The trap is validating reach at bring-up, when the link is idle. Signal integrity margins are consumed by sustained traffic, temperature, and bit-error accumulation — conditions that only appear once the rendering farm is under real load, not during a quiet install-time link check.

How does AOC power draw and per-port cost compare to long-reach copper equivalents?

This is where the intuition tends to flip. People assume optical is always the power-hungry, expensive option because the transceivers draw power that copper does not. For short runs, that is true. But the comparison that matters is against long-reach copper, not short DAC.

When you try to push copper toward longer reach at high rate, you either move to active copper (which adds signal-conditioning electronics and its own power draw) or accept thicker, heavier, less flexible cable. At the reaches where AOC and long-reach copper actually compete, a correctly specced AOC typically draws less per-port power than the copper equivalent trying to cover the same distance, and the fiber is thinner and lighter, which eases airflow and routing density in a packed rack — an operational consideration that compounds across hundreds of ports (observed engineering pattern; the exact power delta depends on the transceiver and is worth confirming against vendor specifications, not assumed). Per-assembly, short DAC is cheaper than AOC and always will be. The honest framing is: cheaper where copper is viable, and AOC wins on power and handling once you are past copper’s reach envelope.

How does interconnect choice affect the latency floor of a GPU rendering farm behind a latency-bound pipeline?

Here is the part that makes this an engineering decision rather than a procurement one. A GPU rendering farm behind a latency-bound pipeline has a latency floor — the best-case, everything-healthy response time — and a latency tail — the slow sessions that ruin the experience for some fraction of users. The interconnect does not usually move the floor much. It moves the tail.

A link that has negotiated full rate and holds it contributes a stable, low, predictable transit time. A link that flaps, or that fell back to a lower negotiated rate because its reach margin was thin, injects retransmits, renegotiation stalls, and reduced bandwidth exactly when the farm is busiest. That is textbook tail-latency behaviour, and no amount of device-tier logic on the client can recover it — the frame is already late by the time it comes back from the render tier. For an AR try-on backend built around a sub-200 ms end-to-end budget, an interconnect that quietly eats 30–50 ms during load spikes (illustrative figures, not a benchmarked rate — the point is the mechanism, not the magnitude) is invisible in the design doc and painfully visible in the session-failure metrics.

We see this pattern regularly: the device-tiering logic was carefully built to protect a latency budget, and then an under-specced link in the render tier spends that budget before the tiering ever gets to. The interconnect and the tiering are protecting the same number. If one leaks, the other cannot compensate. This is the same class of reasoning we apply to what network fabric means for GPU bottlenecks — the fabric and the cable are both places latency hides that peak-FLOP thinking never looks.

What failure modes does the right cable class prevent?

The value of specifying the cable class correctly is best understood through what it stops from happening. These are the failure modes that trace back to an interconnect specified by port-fit and price rather than reach and rate.

• Link flaps — the link repeatedly drops and re-establishes because its signal-integrity margin is too thin to hold under load, causing periodic bursts of dropped or delayed traffic.
• Negotiated rate drops — the endpoints auto-negotiate down to a lower rate the marginal link can sustain, silently halving or quartering the bandwidth the design assumed.
• Signal-integrity errors — rising bit-error rates trigger retransmits and forward-error-correction overhead, adding latency and eating effective throughput without any hard failure to alarm on.

All three share a signature: they are absent at bring-up and appear under sustained production load. That is what makes them so expensive to diagnose after the fact and so cheap to prevent before the build.

How do you decide the AOC vs copper split for a render-tier topology before the build?

The decision is a pre-build spec exercise against the actual topology, not a reaction to latency spikes. Walk the physical layout link by link. For each link, record its two numbers — reach and line rate — and classify it: comfortable copper, marginal (validate under load or default to optical), or firmly optical. Same-rack short hops at any rate are DAC. Cross-rack and cross-row links at modern rates are AOC. The marginal band in between is where you either measure under representative load or spend a little to remove the risk.

Doing this on paper before procurement is dramatically cheaper than discovering the split empirically through production incidents. This is exactly the kind of assumption a GPU audit validates — the interconnect and reach assumptions behind a device-tier rendering budget are as much a part of the audit as the accelerators themselves. If you want the broader engineering context for how these interconnect choices sit inside a real GPU stack, our [GPU engineering work](GPU engineering) and the main site frame where the cable decision fits the larger build.

FAQ

What’s worth understanding about active optical cable first?

An AOC integrates an electrical-to-optical transceiver at each end: the signal is converted to light, carried over fiber, and converted back at the far end. In practice you spec it by connector form factor, line rate (100/200/400G), and reach — and it ships as a fixed-length assembly because the optics are permanently coupled to the fiber.

What is the difference between an active optical cable (AOC) and a direct attach copper (DAC) cable, and when should each be used?

DAC is a passive twinax copper assembly with no active transceivers — cheaper, negligible cable-side power, and correct for short same-rack runs up to roughly 3 metres at high rates. AOC carries the signal as light over fiber and holds full rate across 3–100 m where copper cannot. Use DAC in-rack; use AOC for multi-rack and render-tier-to-render-tier links.

At what reach and bandwidth does copper stop being viable and AOC become necessary?

There is no single threshold — the copper wall moves with line rate, roughly halving viable reach each time the signaling rate doubles. The practical test is a two-axis check of both distance and speed: short in-rack hops stay copper at any modern rate, anything crossing racks is AOC territory, and the marginal band in between should be validated under sustained load rather than at idle bring-up.

How does AOC power draw and per-port cost compare to long-reach copper equivalents?

Against short DAC, AOC costs more and draws more power. Against long-reach copper trying to cover the same distance, a correctly specced AOC typically draws less per-port power and uses thinner, lighter cable that eases airflow and routing density. The honest framing: copper is cheaper where it is viable, and AOC wins on power and handling once past copper’s reach envelope.

How does interconnect choice affect the latency floor of a GPU rendering farm behind a latency-bound pipeline?

The interconnect mostly moves the latency tail, not the floor. A full-rate link that holds contributes stable, predictable transit; a flapping or rate-dropped link injects retransmits and stalls under load — pure tail-latency that client-side device tiering cannot recover once the frame is already late from the render tier.

What failure modes does the right cable class prevent?

Three main ones: link flaps (repeated drop/re-establish under thin signal margin), negotiated rate drops (endpoints silently auto-negotiate to a lower rate), and signal-integrity errors (rising bit-error rates forcing retransmits and FEC overhead). All three are absent at bring-up and surface under sustained production load, which is what makes them expensive to diagnose and cheap to prevent by specifying reach and rate up front.

How do you decide the AOC vs copper split for a render-tier topology before the build rather than after latency problems appear?

Walk the physical topology link by link before procurement, recording reach and line rate for each and classifying it as comfortable copper, marginal, or firmly optical. Same-rack short hops are DAC; cross-rack and cross-row links at modern rates are AOC; the marginal band is measured under representative load or spec’d to optical to remove risk. A pre-build spec pass — the kind a GPU audit performs — is far cheaper than discovering the split through production incidents.

The uncomfortable truth about interconnect is that the wrong cable never announces itself. It passes bring-up, survives the demo, and only shows its hand when sustained load consumes the signal-integrity margin nobody measured. Spec the reach and rate against the real topology before the build, and the render tier’s latency floor stays a floor — not a moving target you chase through the session-failure logs.