Ask five people in optical networking to define scale-across and you will receive five different answers. Most will mention distance. Some will mention power. A few will say scale-across is not simply data center interconnect and then stop, because that is where the available vocabulary runs out.

The term has moved quickly from vendor product category towards a recognized layer in AI infrastructure design, without agreement on meaning. Whereas infrastructure is built to definitions, scale-across is still being poured. The mistake is to define scale-across by how far a signal travels, or by crossed physical boundaries. The organizing principle is the point at which one scale-out communication regime ends and another architectural layer must begin.

The distance definition

The common formulation runs like this:

• Scale-up joins accelerators within a node
• Scale-out joins nodes within a data center
• Scale-across joins data centers (across a campus, metro, or continent)

Clean, memorable, and architecturally incomplete in three ways.

First, the distance definition dates quickly. A definition anchored to geography confuses today's physical constraints with architecture. What constitutes a practical site boundary changes with power distribution, campus design, network technology, and optical reach, and that envelope keeps moving. An architectural term should survive those changes.

Second, the distance definition cannot classify the interesting cases. Two compute buildings four hundred meters apart can form one scale-out fabric (they have crossed a building boundary but not an architectural one). Conversely, two independently bounded AI fabrics in one building can participate in the same distributed workload (they have crossed no meaningful distance, yet the architectural boundary is real). A building wall is not a network architecture.

Third, the distance definition gives you nothing to design to. A definition that supplies only ‘further’ cannot tell you what changes at the boundary, what traffic should cross that boundary, or how the layer should be sized.

The boundary definition

Scale-across is the network layer that joins independently bounded scale-out domains so that they can participate in a distributed AI workload. A scale-out domain is the bounded fabric that provides the system's normal, tightly coupled accelerator communication regime. Scale-across begins where that regime ends. Distance still matters, affecting latency, optical design, cost, power and resilience. But those effects describe the implementation of scale-across, not the reason the layer exists.

Two scale-out domains on one campus and two domains in different cities present the same class of architectural problem, however different the implementations. This also separates scale-across from ordinary DCI. A link between two data centers carrying storage replication, checkpoint movement, management traffic, or access to a remote service is DCI.

The same physical infrastructure can become part of a scale-across network when joining two bounded AI fabrics participating in the same distributed workload. The classification depends on what the network is participating in, not what the link is made of or how far it runs.

What changes at the boundary

Scale-across deserves its own name because the communication regime changes at the boundary. Inside a scale-out domain, the network is engineered for tightly coupled accelerator communication: very high bandwidth per accelerator, low and predictable latency, strong congestion control, and limited tolerance for stragglers.

Across domains, the workload must accommodate lower bandwidth per accelerator, greater latency, and different congestion or failure behaviors. That freedom allows the inter-domain network to be engineered differently. Oversubscription, routing, coherent optics, and long reach may all follow from this distinction, but none of them define it.

The workload architecture must respect the boundary. Tensor and other tightly coupled model-parallel traffic will generally remain within the domain. Data parallelism can become hierarchical, with local collective operations within each domain and a coarser reduction across domains. Pipeline stages can also cross the boundary where latency permits.

The hierarchy of the workload should mirror the hierarchy of the network. A useful test is to consider that if the workload architecture does not recognize and exploit the boundary, the network is probably DCI carrying AI traffic, not scale-across. In practice, a scale-across layer shows four further signatures:

• Scale-across connects independently bounded scale-out domains
• The workload recognizes the boundary and is designed around it
• Traffic crossing the boundary is typically coarser, more aggregated or more latency-tolerant than in-domain traffic
• The boundary influences placement, sizing, routing, or scheduling decisions

Scale-across need not be a separate network

Scale-across is sometimes drawn as a new network alongside scale-out, but a separate network is not required. Scale-across may appear as another tier above a scale-out fabric, use dedicated inter-site switches and coherent optics, or traverse shared transport infrastructure. Future systems will likely combine all three. Scale-across is a role in the system architecture, not necessarily a physically separate fabric. Without this distinction, every sufficiently long AI link becomes 'scale-across', and the term loses architectural meaning.

Why this is not pedantry

Three practical consequences follow from the boundary definition, and none follows from the distance definition.

Sizing. A small amount of traffic per accelerator becomes enormous when summed across tens or hundreds of thousands of accelerators. Scale-across can therefore be bandwidth-hungry in aggregate while carrying much less traffic per accelerator than the scale-out fabric, a different design problem from either conventional DCI or an in-domain AI fabric.

Boundary placement. Under the boundary definition, deciding where the handoff occurs becomes part of system design, and should normally fall where the workload communication graph is sparse: where the least latency-sensitive traffic crosses and where communication can be aggregated most efficiently.

Under a geographic definition, the boundary falls wherever the building, campus, or power system happens to end. The workload is then forced to accommodate somebody else's real-estate decision.

Domain sizing. Scale-out domains have a practical upper range. That limit is not a fixed number and will move with technology, but communication economics eventually make further enlargement unattractive. Beyond that point, growth comes from joining bounded domains at a higher level, and scale-across is the architecture that makes that possible.

A more durable hierarchy

The three scaling terms can then be defined without reference to racks, buildings, or kilometers.

Scale-up expands the most tightly coupled accelerator domain – using a specialized, very high-bandwidth, low-latency fabric within a node or closely integrated group of systems.

Scale-out expands the accelerator fabric within a bounded communication domain.

Scale-across joins bounded scale-out domains while preserving a distributed AI workload across them.

Vendor definitions often begin with geography because that is where scale-across is deployed today. But geography describes where the problem appears, not the architecture that solves it. A rack can contain scale-up and scale-out. A campus can contain one scale-out domain or many. A scale-across boundary can lie between buildings, within a building or across hundreds of kilometers. The topology and the workload decide.

The test worth keeping

Terms that describe constraints outlive terms that describe measurements. Edge computing is most usefully understood by what prevents centralization, not by an arbitrary number of kilometers from a user. Scale-across should be treated the same way. It is not the network that starts when the fiber gets long. It is the network that starts when the scale-out domain ends.

The industry will settle on a definition, and should choose one that still works in 2030.