1.6T OSFP224 Transceivers in Scalable AI Infrastructure: Where They Fit and How to Order Them Right

Jun 17, 2026|

1.6T OSFP224: Where It Fits, and How to Order It Right

If you are speccing optics for a new GPU cluster, the 1.6T OSFP224 transceiver has probably already landed on your bill of materials, most often next to a NVIDIA Quantum-X800 InfiniBand switch or a ConnectX-8 SuperNIC. We build and ship these modules, so this reads the way we actually answer a buyer's questions: which lane belongs where in your fabric, which variant survives both your thermal envelope and your switch cage, and whether the part you ordered will link on the switch you already racked. One distinction matters up front, because it decides which datasheet column you read - the platforms pulling 1.6T volume today are InfiniBand XDR, not Ethernet, even though the module looks identical either way.

Validated on the target platform

EEPROM coding, labelling and link validation on the matching switch family before a batch ships - Quantum-X800 and Q3200 on InfiniBand XDR, Spectrum-6 on Ethernet, ConnectX-8 and ConnectX-9 at the endpoint

Quoted against a configuration

Switch model, chassis cooling method, optical variant, connector and ramp quantity confirmed before the order is cut, not after the optics reach your hall - which is what makes a delivery slot real rather than indicative

Scalable AI infrastructure data center featuring high-speed 1.6T OSFP224 optical interconnects for low-latency InfiniBand XDR clusters

8×200G

PAM4 electrical lanes per module

33.5W

Per twin-port module, NVIDIA spec

500m

2×DR4 over parallel single-mode

2km

2×FR4 over CWDM duplex

 

What is actually forcing the move to 1.6T right now

 

AI back-end networks ran out of headroom at 800G faster than the planning cycles assumed, and 1.6T OSFP224 optics answer that by running 200G PAM4 on each of eight electrical lanes for 1.6Tb/s per port without widening the front panel.

"Demand is not curving up gently. LightCounting's April 2026 forecast has the Ethernet transceiver market growing 93% in 2024, 82% in 2025, and a projected 65% in 2026 - and that deceleration is a supply story, not a demand story."

Orders currently exceed InP EML and laser-chip output by roughly 30%, and the two most-cited forecasts disagree about when that gap closes. LightCounting expects it to clear by the end of 2026 as new indium phosphide capacity qualifies. McKinsey models 1.6T running 30–40% short through 2029. A multi-year program built on the optimistic view and wrong about it will be re-quoting optics mid-build, so budget against both rather than picking the number you prefer.

 

The Ethernet growth figure is only half the picture. The flagship 1.6T deployments, NVIDIA Quantum-X800 paired with ConnectX-8, run InfiniBand XDR - a separate product line from the Ethernet path served by Spectrum-X. That Ethernet path is specified under IEEE P802.3dj, still a draft at D3.0 and targeted for completion in late 2026, which means volume 1.6T parts are shipping ahead of ratification and are built instead against OSFP MSA Rev 5.22 and CMIS 5.2/5.3. That is worth knowing before anyone writes "IEEE 802.3dj compliant" into a specification document. NVIDIA alone is estimated to absorb the large majority of early 1.6T demand, on the order of 80%, almost all of it on the InfiniBand XDR side.

 

The practical takeaway for a buyer is not the headline growth. It is that you are ordering into a market where demand is structurally ahead of supply, and that one fact reshapes how you plan lead times.

 

What "1.6T OSFP224" actually means, and what it does not

 

OSFP stands for Octal Small Form-factor Pluggable: eight electrical lanes in one module. In the 1.6T OSFP224 form factor each lane runs at 200G PAM4 for 1.6Tb/s aggregate, the housing carries an integrated heat sink because nothing at this rate cools passively, and most deployed parts are a twin-port design, effectively two 800G engines, which is why you see them written as 2×DR4 or 2×FR4. The same physical OSFP224 module serves both an InfiniBand XDR fabric and a 1.6T Ethernet fabric; the optics and form factor are identical and only the protocol layer changes, which is exactly why "it's an OSFP224" never tells you which fabric it was coded for.

 

One caveat belongs on the Ethernet side of that sentence. On Spectrum-6 systems a twin-port OSFP cage presents two independent 800GbE links rather than one native 1.6TbE port, and native 1.6TbE ports currently show up mainly on Tomahawk 6-based platforms at 64×1.6TbE. Ask which of the two your switch actually presents before you size port counts, because the module is the same part in both cases and the datasheet will not tell you.

 

8-lane 200G PAM4 electrical architecture technical visualization for 1.6Tb/s aggregate bandwidth in OSFP224 transceiver modules

 

Here is the distinction that trips up procurement more than any spec line: a 1.6T OSFP224 module is not a 1.6T OSFP-XD module, even though both reach 1.6T in an OSFP-style shell. OSFP224 (also written OSFP1600) gets there with eight lanes at 200G and stays mechanically backward-compatible with existing 400G and 800G OSFP cages, while OSFP-XD reaches 1.6T with sixteen lanes at 100G on a different SerDes lineage. They are not interchangeable, and a datasheet that blurs OSFP224 versus OSFP-XD is one to distrust. We walk that variant-and-SerDes minefield through in our companion note on moving an existing fabric from 800G to 1.6T; the point to carry into a purchase order is that "1.6T" on its own is not a specification.

 

Where 1.6T OSFP224 fits in an AI fabric, and where it does not

 

This module does not belong everywhere in a cluster, and treating it as a universal upgrade is how budgets get wasted. The right way to place a 1.6T OSFP224 link is to split the fabric into the layers it actually has and decide per layer.

 

Inside the rack, in the scale-up domain where GPUs talk across the shortest hops, the lowest-power answer is still copper - but not the copper a 400G or 800G buyer is used to specifying. At 200G-PAM4 the passive twinax reach collapses to roughly half a metre to one metre, which is why NVIDIA lists no passive DAC at all in the XDR line and calls the format too short for the rate. What takes its place is linear active copper (LACC), rated 1 to 2.5 m at about 4.3 W on the 1.6T end and under 0.1 W on a splitter end, and active electric cable (AEC) with a DSP in each end, rated to 3 m at roughly 27 W. Multimode variants and AOCs do not exist at this lane rate yet because the lasers are not in production, so anyone quoting you a 1.6T AOC for an XDR fabric is quoting something that has not shipped. Reserve the optical budget for links that actually need light, and specify the copper tier by cable type rather than by the word "DAC" - the distinction between passive, linear active and DSP-based high-speed copper cable assemblies is what decides whether the link comes up at all.

 

Across racks, in the scale-out domain of leaf-to-spine links where all-to-all collective traffic dominates, a 1.6T OSFP224 2×DR4 module earns its place at roughly 500 meters over parallel single-mode fiber, and it is the variant most back-end designs standardize on. In an InfiniBand XDR build that spine is a Quantum-X800; in an Ethernet build it is a Spectrum-X switch. Same DR4 optic, different switch OS and coding. When a deployment stretches into campus distances, the 2×FR4 variant trades the parallel fiber plant for a CWDM duplex link at around two kilometers.

 

The decision between DR4 and FR4 is not about which is "better." It is whether your longest link in that layer is closer to 500 meters or two kilometers, and buying the longer-reach part for a short-reach row is paying for fiber you will never light. That layered split is the part competitors' product pages skip, and it is the same discipline we already apply to the 800G OSFP links running in production GPU fabrics today, which is the tier most clusters are upgrading from. If you want the layer-by-layer mapping against your own rack power and switch radix, that is the detail a generic datasheet cannot give you.

 

Picking the right variant without over-buying reach

 

Once the layer is decided, variant selection comes down to reach, fiber plant, connector, and the housing your switch cage expects:

 

Variant Typical reach Fiber / connector Housing note Where it belongs
1.6T OSFP224 2×DR4 ~500 m Parallel SMF, dual MPO-12/APC IHS for air-cooled switches, RHS for liquid-cooled Scale-out spine, intra-hall row-to-row
1.6T OSFP224 2×FR4 ~2 km Duplex SMF (CWDM), dual LC/duplex IHS for air-cooled switches, RHS for liquid-cooled Campus / inter-hall links
1.6T OSFP224 DR8 ~500 m Parallel SMF, MPO Housing per platform cooling method Ports presenting one 1.6T interface

The housing column matters as much as the optical column, and it is the easiest line to get wrong on a purchase order. The rule that actually governs it is not "twin-port or not" - it is how the chassis is cooled. Integrated heat sink (IHS) parts belong in air-cooled switches, which on the InfiniBand side means the Q3400 and the Q3200. Everything else takes a riding heat sink (RHS) flat top: ConnectX-8 cages in B300 and GB300 systems, ConnectX-8 PCIe cards, and every liquid-cooled switch chassis, the Spectrum-6 SN6600-LD included. The internals are the same part; only the mechanical top differs, and IHS and RHS ends link to each other without issue once each is seated in the right cage.

Two traps sit underneath that rule. IHS ships in two forms - open-top with exposed fins, and closed-top with a plate over the fins for extra conduction - so "finned top" alone is not a complete line item. And because liquid cooling is where 2026 rack designs are heading, the more common error now is ordering IHS for a chassis that wanted RHS, which is the reverse of the mistake most datasheets warn about. Write the chassis model and its cooling method on the purchase order and let those two fields derive the housing; the platform-by-platform housing and SerDes breakdown covers the rest. The judgment stays blunt: pick reach by your longest link in that layer, then let the switch chassis dictate the housing, and never let a sales sheet talk you into the longer-reach variant "to be safe."

1.6T OSFP224 transceiver module with integrated heat sink (IHS) designed for high-density NVIDIA Quantum-X800 and Spectrum-X AI infrastructure

 

OSFP-XD, and why a "1.6T cable" quote may not fit your port at all

 

OSFP-XD is the form factor most often confused with OSFP224, and the confusion runs in a specific direction worth correcting: OSFP-XD is frequently described as the 224G-per-lane format, when its 1.6T implementation is the opposite - sixteen lanes at 100G, riding the 112G SerDes generation. OSFP224 is the eight-lane, 200G-per-lane part. If your switch ASIC already drives 200G electrical lanes, you do not need OSFP-XD to reach 1.6T, and buying into it will not make the port faster.

 

Decision point 1.6T OSFP224 (OSFP1600) 1.6T OSFP-XD
Electrical lanes 8 × 200G PAM4 16 × 100G PAM4
Cage compatibility Mechanically fits 400G/800G OSFP cages Dedicated OSFP-XD cage only; keying blocks cross-insertion
Thermal envelope 33.5 W per twin-port module (NVIDIA spec) Specified to roughly 40 W
Passive copper reach Not offered at 200G-PAM4; use LACC or AEC 0.5–1.0 m passive twinax, 0 W
Governing spec OSFP MSA Rev 5.22 OSFP-XD MSA Rev 1.11
Next-gen headroom Caps at 1.6T on eight lanes Carries 3.2T once lanes run at 200G

 

Where OSFP-XD earns its sixteen lanes is one generation out. The same shell carries 3.2T once those lanes run at 200G, and its thermal ceiling sits above what a current twin-port OSFP224 module draws. That headroom is the argument for it in a spine designed to be re-optic'd rather than re-racked - and the argument against it in a cluster that has to come up this quarter, because the merchant switch ecosystem behind OSFP-XD cages is thin next to the OSFP install base.

 

The two are not swappable, and this is one of the rare compatibility questions with a mechanical answer rather than a firmware one: keying features on the modules physically prevent insertion into the wrong port type. A 1.6T OSFP-XD cable and a 1.6T OSFP224 cable are two different SKUs for two different cages, and the part numbers give you no warning - both read "1.6T" on the label.

 

For the short-reach tier, an OSFP-XD passive twinax assembly draws zero watts and adds no O-E-O latency, at the cost of a reach ceiling around one metre, which makes it a top-of-rack-to-server part rather than a row-to-row part. Confirm the cage type on the switch line card before releasing any bulk order for 1.6T copper; the price difference between the two families is small next to the cost of a pallet that will not seat. Our 1.6T OSFP224 module and cable options are quoted against a named cage type for exactly that reason.

 

DSP, LPO, and the power problem nobody escapes

 

There is a genuine debate about whether the next generation of 1.6T OSFP224 optics should keep the on-board DSP or move to linear-drive pluggable optics that lean on the switch SerDes. The numbers are concrete, not directional: energy-per-bit figures disclosed at OCP EMEA 2025 put a 1.6T 2×DR4 module at about 18.75 pJ/bit on a 5nm DSP, about 16.25 pJ/bit on a 3nm DSP, and around 6.25 pJ/bit for a well-implemented LPO design, roughly a 40–50% power cut once the DSP is removed.

 

Here is the position we will stake out rather than hedge: for most production AI clusters being built through 2026 and into 2027, the DSP-based 1.6T OSFP224 module is still the safe default, and LPO is a conditional optimization, not a drop-in. LPO only behaves when you control both ends, the reach is short, and the switch ASIC natively drives linear PAM4 with the right calibration, conditions that hold inside a tightly engineered single-vendor fabric and fall apart across mixed or longer links. What does not change with either choice is the thermal reality. NVIDIA specifies 33.5 W for a twin-port 2×DR4 or 2×FR4 module and 18 W for the single-port 800G DR4 that pairs with it, and newer OSFP cage designs from the Open Compute Project ecosystem let a cold plate mount directly to the module precisely because air cooling is running out of room. On a 1.6T migration, bandwidth is not the limit, thermals are.

 

Pluggable or co-packaged: what 2026's CPO switches change about a 1.6T order

 

The DSP-versus-LPO argument above assumes the module stays a module. Through 2026 that assumption stopped being safe: co-packaged optics moved into production on both NVIDIA fabrics - Quantum-X Photonics on the InfiniBand side, Spectrum-X Ethernet Photonics on Spectrum-6 - with the optics integrated onto the switch package and the front-panel cage removed from the path. The published deltas are large: roughly 9 W per port against about 30 W for a pluggable, with a claimed 5× optical power efficiency and 1.3× faster time to deployment.

 

Those numbers do not mean a 1.6T pluggable order placed today is a mistake, and the reason is not loyalty to the format. CPO is forecast to reach only about 30% of 800G and 1.6T ports by 2027, with pluggables carrying the remainder for years past that, and NVIDIA has reaffirmed pluggable support through 2027. The operational asymmetry matters more than the share number: a degraded pluggable is a two-minute swap by whoever is on shift, while a degraded co-packaged port is a chassis-level RMA against a switch that may be carrying dozens of live links. That difference is worth pricing before it is worth admiring, and it is the reason a margin-first acceptance playbook matters more on a CPO fabric, not less.

 

The boundary we would draw for a buyer freezing a bill of materials in the second half of 2026: stay pluggable if you need field-serviceable optics, if any part of the fabric spans more than one vendor, if links run past 500 m, or if the build lands before roughly mid-2027. Consider CPO where you are taking a full single-vendor rack, your power envelope is the binding constraint rather than your capex, and your operations model can absorb switch-level replacement. The case CPO does not make is a partial retrofit - mixing a co-packaged spine into a pluggable leaf tier reintroduces every interoperability question the integration was supposed to remove.

 

The compatibility checks that fail silently

 

A fully MSA-compliant 1.6T OSFP224 module can still refuse to link on the switch you already own, and it does so without an obvious error. Three things have to line up, and each fails independently and quietly. The first is lane rate: an 800G module runs 100G PAM4 per lane and a 1.6T module runs 200G PAM4 per lane, so despite near-identical names they cannot interoperate, a 200G-PAM4 part will not downshift to 100G-PAM4 or 50G-PAM4, and a switch built for 100G electrical lanes cannot drive a 200G-lane 1.6T OSFP224 transceiver. The second is the housing-versus-cage match described above. The third is the switch SerDes generation: the host ASIC has to natively speak 200G electrical, and not every platform claiming OSFP support does. Treat those as three separate line items on every order; the full platform-by-platform breakdown lives in our SerDes, variants, and traps walkthrough.

 

One more line belongs beside them on a Q3400 build: that chassis does not support 1:2 splitting of its four-channel MPO-12/APC ports, while the Q3200 does. A breakout plan drawn against the wrong switch model fails at design review rather than at bring-up, which is the cheaper place to find it but only if someone checks.

 

This is also where procurement asks the question that decides the order: is a compatible module as safe as the NVIDIA original, the MMS4A00-XM and its siblings? The honest answer is that a compatible 1.6T OSFP224 transceiver closes the gap through EEPROM coding, correct labeling, and bring-up testing on the exact target platform, not by claiming to be electrically identical to the original. A coded, link-validated compatible module behaves like the original in the slot it was validated for; an uncoded or untested one is where the horror stories come from. The variable most suppliers will not put in writing is which of the three checks above they actually verify before shipping.

Ordering 1.6T OSFP224 at cluster scale

 

The procurement side is where the supply-demand imbalance stops being abstract. Because the market runs ahead of laser-chip capacity, lead times on 1.6T optics are volatile and quantity-sensitive in a way 100G and 400G buyers are not used to, and this part of the cycle rewards ordering against a confirmed configuration rather than a generic part number. A clean 1.6T OSFP224 order specifies, at minimum:

 

1

Target switch and NIC plus firmware, for example a Quantum-X800 Q3400-RA switch (InfiniBand XDR) with a ConnectX-8 SuperNIC, or a Spectrum-6 system with ConnectX-9, so lane rate and platform support are verified, not assumed

2

Optical variant and reach (2×DR4 at 500 m, 2×FR4 at 2 km, or DR8), tied to the fabric layer it serves

3

Chassis cooling method, because it derives the housing: IHS finned top for air-cooled switches such as the Q3400 and Q3200, RHS flat top for liquid-cooled chassis and ConnectX-8 endpoints - and state open-top or closed-top where IHS applies

4

Connector and fiber plant (dual MPO-12/APC for parallel SMF over OS2 9/125 single-mode, duplex LC for CWDM)

5

Quantity and ramp schedule, because batch lead time at thousands of units is a different conversation from a sample

6

An explicit interoperability-test requirement on your target platform before bulk release, plus the compliance documentation set you need on file - RoHS 2.0 under Directive 2011/65/EU, REACH declaration, and TAA certification where the end customer is a public-sector buyer

 

Four things decide whether a 1.6T order lands on schedule, and unit price is not among them.

 

Allocation replaced price as the clearing mechanism. Orders currently exceed InP EML and laser chip output by roughly 30%, and NVIDIA's multi-billion-dollar pre-allocation of capacity at Lumentum and Coherent has pushed unallocated buyers' delivery windows past 2027. A higher bid does not move a queue that was committed a year ago.

 

1.6T is structurally tighter than 800G, not proportionally tighter. A 1.6T module consumes roughly 2.7 to 2.8 times the InP substrate area of an 800G module. Doubling port speed nearly triples upstream demand, which is why 1.6T allocation runs behind 800G allocation even where both are short.

 

The forecasts disagree about when this ends, and that disagreement is the planning input. LightCounting expects shortages to clear by the end of 2026 as new InP capacity qualifies; McKinsey models 1.6T running 30–40% short through 2029. A program that assumes the first view and is wrong will be re-quoting optics mid-build.

 

Quantity tier changes the answer. A sample and a several-thousand-unit batch are different conversations with different chip allocations behind them. Send the quantity and the ramp schedule with the first inquiry; a lead time quoted without them is a guess, and a lead time quoted for a compatible 1.6T OSFP224 module in bulk order volumes should always come with the InP source named. We keep the current allocation and lead-time picture across the supply base updated for exactly this conversation.

 

That last point is the one a checklist alone cannot resolve. Knowing the six items is the easy part; knowing which one will fail silently on your specific switch, and catching it before the optics reach your hall, is what separates a supply partner from a catalog reseller. That is the work we do before a batch ships: code and label to the target platform, link-validate on the matching switch family, and hand back the result rather than a promise. It is the same discipline behind our 800G OSFP modules already in service, and it is backed by RoHS-compliant builds and a service footprint of more than ten regional offices across Southeast Asia and Africa for deployment and after-sales support. If you send your target switch, NIC, and quantity, we will return a compatibility-checked 1.6T OSFP224 configuration and a realistic delivery slot instead of a generic line item.

One procurement note worth internalizing: publicly listed 1.6T OSFP224 pricing now spreads wider than a single range suggests. Compatible 2×DR4 parts sit near the bottom of it, 2×FR4 carries roughly a US$300 premium over DR4 for the same housing, RHS adds around US$100 over IHS, and NVIDIA-branded parts land above the compatible tier. Price also moves in both directions within a cycle - early shortages pull buyers into double-ordering, which holds prices steady, and once capacity catches up the duplicate orders evaporate and prices fall faster. Anchor a multi-year program to a confirmed configuration and a confirmed delivery slot, and treat unit price as the variable it is.

Building a fabric that survives the next jump to 3.2T

 

The clusters being cabled with 1.6T OSFP224 optics today are the same ones that will face 3.2T after 2026 and 2027, and single-mode parallel fiber, MPO discipline, and a cooling plan with thermal headroom are what carry forward. The direction of travel is already on the record: IEEE 802.3 opened consensus-building on 400G-per-lane signalling at its March 2026 plenary, ConnectX-9 delivers 1.6Tb/s per GPU in Vera Rubin compute trays, and Spectrum-6 and Tomahawk 6 have both moved 102.4T switch silicon into systems. If you are mapping a specific build, which variant on which layer, which housing for which switch cage, what InfiniBand XDR versus Ethernet coding each port needs, that is a configuration conversation worth having before the bill of materials is frozen, and one we would rather have with you early than after the first batch is cut.

 

Frequently asked questions

Q: What is a 1.6T OSFP224 transceiver used for?

A: It provides high-bandwidth interconnect in the scale-out layer of AI fabrics, carrying 1.6Tb/s over eight 200G PAM4 lanes for leaf-to-spine and inter-rack links, on either an InfiniBand XDR or a 1.6T Ethernet fabric.

Q: What is the difference between OSFP224 and OSFP-XD?

A: OSFP224 (OSFP1600) reaches 1.6T with eight lanes at 200G and stays backward-compatible with 400G/800G OSFP cages, while OSFP-XD uses sixteen lanes at 100G on a different SerDes lineage; they are not interchangeable, and mechanical keying prevents inserting one into the other's port.

Q: Can a 1.6T OSFP224 module plug into an existing 800G OSFP switch port?

A: The cage may be mechanically compatible, but the switch SerDes must natively support 200G electrical lanes; an 800G platform built for 100G lanes cannot drive a 1.6T module, and a 200G-PAM4 part will not downshift to meet it.

Q: Should I order IHS or RHS housing for my 1.6T OSFP224 modules?

A: Order by how the chassis is cooled, not by what the cage looks like. IHS finned-top modules go into air-cooled switches - Q3400 and Q3200 on the InfiniBand XDR side. RHS flat-top modules go into everything else: liquid-cooled switch chassis such as the Spectrum-6 SN6600-LD, ConnectX-8 cages in B300 and GB300 systems, and ConnectX-8 PCIe cards. IHS itself ships in two versions, open-top with exposed fins and closed-top with a conduction plate, so "finned top" is not a complete specification. The internals are identical across housings and an IHS end links normally to an RHS end, so the failure is purely mechanical - the module either seats or it does not. This rule holds for the NVIDIA XDR line specifically; on merchant-silicon platforms confirm the cage type against the switch vendor's own line-card documentation before release.

Q: Should I choose 2×DR4 or 2×FR4?

A: Choose by your longest link in that fabric layer: 2×DR4 covers roughly 500 m for in-hall spine links, while 2×FR4 covers roughly 2 km for campus and inter-hall reach.

Q: Should I buy 1.6T pluggable optics now or wait for co-packaged optics?

A: Buy pluggable for anything freezing its bill of materials before roughly mid-2027, and treat CPO as a platform decision rather than an optics decision. Co-packaged optics entered production during 2026 on Quantum-X Photonics and Spectrum-X Ethernet Photonics at about 9 W per port against roughly 30 W for a pluggable, but industry forecasts still put CPO at only around 30% of 800G and 1.6T ports by 2027, and NVIDIA has committed to pluggable support through that window. CPO fits a full single-vendor rack where power, not capex, is the binding constraint and operations can absorb switch-level RMA. It does not fit a fabric spanning more than one vendor, links beyond 500 m, or a partial retrofit into an existing pluggable leaf tier - that last case reintroduces every interoperability question the integration was meant to eliminate, while removing the ability to swap a bad port on shift.

Q: Is a compatible 1.6T OSFP224 module as reliable as the NVIDIA original?

A: A correctly coded and link-validated compatible module behaves like the original in the slot it was tested for; the risk lives in uncoded or untested parts, so verify what the supplier validates before shipping.

Send Inquiry