DR4, FR4, LR4 and short copper paths
Application decision brief
AI & Cloud 400G Optical Networks
400G selection is a fabric decision: lane architecture, FEC, breakout, fibre topology, thermal load and migration timing must be approved together.
Breakouts and mixed-generation hosts
Host settings are part of approval
AI fabrics concentrate bandwidth and heat. A module that reaches the receiver may still be unsuitable when cage temperature, power budget, FEC mode or breakout behaviour is outside the approved host envelope.
DR4, FR4 and LR4 are not interchangeable labels. They imply different fibre counts, connectors, reach zones and operational patching. The optical choice must follow the cluster topology and installed fibre plant.
A controlled migration records both ends of every link, the old and new port speeds, breakout mapping, firmware baseline and rollback spares before production quantities are released.
01 / Architecture
Translate the network requirement into an optical path
Separate in-rack, cluster-row, campus and long DCI paths. One 400G part number should not be stretched across every zone.
| Network requirement | Recommended design path | Confirm before approval |
|---|---|---|
| Short GPU/server adjacency | 400G passive DAC where length, airflow and port support are confirmed. | Cable gauge, bend radius, cage temperature and coding. |
| Parallel single-mode fabric | 400G DR4 for up to 500 m and MPO-based parallel fibre. | Fibre count, polarity, breakout plan and receiver type. |
| Duplex-LC cluster or campus | 400G FR4 for up to 2 km where duplex SMF simplifies the plant. | FEC, link budget, patch loss and host support. |
| Longer DCI path | 400G LR4 for up to 10 km after route and thermal review. | Dispersion, loss, connector cleanliness and power. |
| Staged 200G transition | 200G FR4 or approved 400G breakout during phased migration. | Lane mapping, firmware, FEC and rollback design. |
02 / Real catalogue anchors
Product examples for a controlled starting point
Use the five live products below to anchor DR4, FR4, LR4, DAC and 200G transition discussions.
Verified live product page400G QSFP-DD DR4 500m MPO TransceiverParallel-SMF AI fabric and breakout planningVerified live product page400G QSFP-DD FR4 2km LC TransceiverDuplex-LC cluster and campus linksVerified live product page400G QSFP-DD LR4 10km LC TransceiverLonger DCI reach after route reviewVerified live product page400G QSFP-DD Passive DAC CableShort high-density copper adjacencyVerified live product page200G QSFP56 FR4 2km LC TransceiverControlled 200G transition layer
Catalogue examples define a starting configuration, not automatic proof for a different host, revision, reach or fibre plant.
03 / Deployment patterns
Where this application architecture is used
The commercial value is different in each pattern: capacity, migration risk and replacement time must be separated.
GPU cluster east–west traffic
Dense 400G leaf–spine links with strict thermal, FEC and latency control.
Cloud fabric expansion
Add racks while preserving approved host coding and labelled spare identity.
400G DCI
Connect halls or buildings over FR4/LR4 after loss and route review.
Mixed 100G/200G/400G migration
Use controlled breakouts and staged acceptance instead of a one-step replacement.
04 / Validation
Sample, compatibility and release workflow
400G approval must test the system, not merely read the EEPROM.
- 1
Freeze topology and lane map
Record each port role, peer, lane breakout and migration state.
- 2
Confirm host power and thermal envelope
Check cage power, airflow direction and operating temperature.
- 3
Validate FEC and firmware
Use the named switch/NIC release and record counters under traffic.
- 4
Inspect optical path
Confirm fibre type, MPO polarity or LC loss, patch count and cleaning.
- 5
Lock sample-to-lot identity
Tie coding, label, serial format and component-change approval to the order.
05 / Commercial control
MOQ, lead time and pricing factors
400G pricing is not a single speed premium. Optical architecture, host validation and migration staging change both cost and schedule.
| Commercial item | What changes the outcome | Buyer action |
|---|---|---|
| MOQ | Different DR/FR/LR and coding lines split volume. | Send quantities by exact host and link zone. |
| Sample stage | 400G host and thermal validation may require more than one build. | Reserve time for traffic and FEC observation. |
| Lead time | DSP, optics, coding and lot inspection have separate dependencies. | Identify critical cluster links and acceptable alternates. |
| Price | Reach, power, connector, DSP and warranty drive the line price. | Compare like-for-like specifications and evidence scope. |
06 / Evidence
Downloadable buyer evidence pack
Use the redacted templates to define what must be recorded for the exact quoted configuration.
07 / Risk control
Failure modes to remove before shipment
Wrong lane assumption
A breakout that exists electrically may not be supported by the line card or software.
Thermal margin loss
High-density ports can push module temperature beyond the approved operating envelope.
FEC mismatch
The link may flap or accumulate errors when host FEC is not aligned.
Fibre topology mismatch
DR4 MPO and FR4/LR4 duplex LC require different plant design.
08 / Buyer questions
Application-specific questions
DR4 or FR4 for 400G?
Choose from fibre topology and reach: DR4 uses parallel SMF/MPO, while FR4 uses duplex SMF/LC and internal wavelength multiplexing.
Can a 400G module be approved without traffic testing?
Recognition alone is insufficient. Record FEC, errors, stability and temperature under representative traffic.
Is a 400G breakout always available?
No. Confirm line-card lane mapping, firmware, cable/optic implementation and peer-port support.
What belongs in the AI-cluster RFQ?
Host/NIC models, software, topology, port roles, reach, fibre, connector, lane map, quantities, delivery target and spare plan.
Controlled next step
Send the 400G fabric map, not a generic speed request.
We will structure the DR4/FR4/LR4/DAC choice, host-validation boundary, migration stage and evidence plan around the named AI or cloud project.