Co-packaged optics brings an operating-model question to AI networking

Co-packaged optics is entering a more practical phase of the AI-networking discussion. Lightmatter's March 2026 Passage sampling announcement offered a component-level evaluation milestone. NVIDIA's May production announcement placed Spectrum-X Ethernet Photonics within a manufacturing ramp. An earlier NVIDIA–Coherent agreement addressed supply and future capacity.

These announcements do not establish a universal winner among network designs. They make a different question timely: what operating model accompanies a more integrated optical path?

For an infrastructure team, evaluation should cover the path a bit follows, the power needed to deliver it and the work needed when part of that path fails. The following is an engineering analysis of the questions raised by the announcements, not a benchmark performed by this publication.

Locate the optical function in the data path

NVIDIA's product description places photonics in the package with the switching ASIC. The claimed benefits concern network connectivity. This is different from replacing neural-network arithmetic with an optical computing operation.

That boundary should appear at the start of a comparison. A network can help an AI workload by changing how data moves among processors, but the resulting application benefit depends on how much time that workload spends communicating and how the network handles that traffic.

A useful system diagram therefore starts with the electronic source, follows the electrical and optical interfaces, and ends at the destination. It should identify where signals are converted and which components remain necessary around the photonic engine. A component label alone cannot describe that path.

Count bandwidth consistently

Lightmatter's EVK100 specification distinguishes a unidirectional per-fibre rate from aggregate input/output bandwidth. That is the kind of distinction every optical comparison should preserve.

A planning document should state whether a rate applies to one direction, both directions, one fibre, one package or a complete switch. It should also distinguish a link's signalling capability from the payload delivered by a workload.

Otherwise, two valid numbers can create an invalid comparison. A larger aggregate figure may reflect a different number of paths rather than a better individual path. Likewise, a dense component may require surrounding connections that determine how much of its capability the system can use.

The 2026 announcements make density worth investigating, but they do not eliminate the need to define what was counted.

Put a boundary around the energy figure

The EVK100 page explicitly labels its link-efficiency figure as a target. That makes it unsuitable as a stand-alone measured result for a deployed cluster. NVIDIA's product benefits are also vendor claims whose test boundaries must be understood before applying them elsewhere.

Our proposed evaluation would report at least two separate observations: energy for the relevant communication function and energy for the complete workload. The first helps explain the component. The second answers whether the system-level change matters to the user.

The account should say whether laser sources, control electronics, conversion and cooling are included. A test that excludes one of those terms may still be useful, provided the omission is visible and the comparator uses the same boundary.

No new physical law is needed to make this discipline valuable. It is simply the difference between measuring a component and estimating the consequences of installing it.

Ask what gets replaced when something fails

Integration changes the relationships among components. It makes serviceability a question that should be answered for the actual product, not assumed from a generic description of co-packaged optics.

A hypothetical maintenance exercise could begin with a degraded link. The evaluator would ask how the fault is detected, how it is isolated, which part is replaced and what verification returns the system to service. It would also identify whether neighbouring paths remain available during that work.

Those are proposed evaluation steps, not reports of failures in the named products. Their value is to turn an advertised operational benefit into something a customer can examine.

The replacement unit might differ across architectures. So might the division of responsibility between the switch supplier, optical-component supplier and system integrator. A purchasing specification should name that responsibility before a downtime estimate relies on it.

Read supply commitments as supply evidence

The March NVIDIA–Coherent announcement describes a nonexclusive agreement, a purchase commitment and a separate $2 billion investment intended to support research and capacity. It is evidence of an announced supply relationship.

It does not, on its own, establish achieved manufacturing yield, available inventory or the delivery date for a customer's chosen configuration. Those questions need product and fulfilment evidence.

The distinction is especially useful when a supply announcement and a production announcement occur close together. They can reinforce the plausibility of a manufacturing plan without becoming the same milestone. A team should retain the date and scope of each.

Supply planning also needs a configuration identifier. A delivery commitment for one optical engine, package or switch revision may not establish availability of the configuration used in an evaluation. Keeping those identifiers together allows procurement and engineering teams to discuss the same item when a schedule or specification changes.

Design the evaluation around a workload and a failure case

A strong evaluation request would include representative traffic and an explicit reason the current network is limiting the workload. It would also include a maintenance scenario, the complete power boundary and an agreed interpretation of successful delivery.

For example, a team studying communication-heavy training should not assume its result transfers to an inference service with a different traffic pattern. This is a hypothetical scope example, not a claim about the performance of either workload on the named hardware.

The same care belongs in acceptance criteria. A component reaching its specified rate is useful evidence. A network sustaining useful throughput under the intended traffic is another step. A supported installation that can recover from faults is another.

Co-packaged optics deserves attention because integration may change both the data path and the surrounding operation. The 2026 developments supply concrete products and commitments to investigate. The next sound conclusion will come from connecting those developments to measured traffic, complete energy accounting and a maintenance plan that a customer can actually use.