In AI, chips do not work independently. They are tightly coupled, and not just during training. In training operations like All-Reduce, thousands of them have to pause and synchronize at the exact same moment. But inference relies on the network just as heavily. At scale, a single request has to fan out across many chips. Disaggregated inference splits this work even further, separating the prefill and decode stages and moving huge amounts of state, like the KV cache, across the network. Mixture-of-experts models make this even more complex, constantly routing tokens to different nodes where the specific experts live.

This is the exact opposite of what traditional networks were designed for. Those were built for millions of small, independent web requests. AI gives you a small number of massive, synchronized bursts instead. That means your job always runs at the speed of its slowest path. In training, a single congested link does not just slow down one node; it drags down the entire run. In inference, one stalled path delays the entire response, driving up time to first token and tail latency, the exact numbers your users actually feel.

That is why the network makes such a massive difference. Independent benchmarks show a five to ten-times difference in inference performance depending entirely on how the network is set up. The network is not a rounding error. It is the multiplier that decides whether your hardware actually pays off, whether you are training a model or running it.

The network is the layer no one can see into. Traditional monitoring tools only check the state of the network every few seconds. If a link is technically connected, the dashboard turns green. But AI failures move too fast for that. A serious congestion event can start and end in the blank space between those checks. Packets get dropped silently, and links can rapidly fail while still reporting that they are online. These are “gray failures.” They are completely invisible to standard switch monitoring, and by the time your dashboard finally registers that something is wrong, you have already wasted hours of incredibly expensive compute time.

There is also a structural blind spot. About a third of all cluster performance problems do not actually start on the switches. They start on the hosts themselves, in things like drivers, firmware, or configuration drift. If you are only looking at the switches, you are blind to all of this. So when a run slows down, engineers do not spend their time fixing the problem. They spend it just trying to find it, digging by hand through several disconnected tools.

Scaling multiplies problems. You do not need a giant cluster to run into these problems. The same gray failures and microsecond events happen at any size, and they cost you money whether you are running a single rack or ten thousand chips. What changes with scale is simply the math. Every node you add multiplies the number of things that can go wrong and the speed at which you have to find them. The natural instinct is to throw people at the problem, but you cannot hire your way out of this. No one can afford to stand up a thousand-person network operations team. And even if you could, human beings do not look at dashboards fast enough to catch a failure that starts and ends between monitoring samples. At scale, managing the network has to become something the system does for itself, not something a person does by hand.

You cannot solve this problem by just buying a faster box. You need an architecture where every layer is excellent, but they are all designed to work together as a single system. That is what the combination of AMD and Aria actually does. AMD provides the compute and an open, UEC-ready NIC. Aria provides the UEC-compliant, lossless fabric and the intelligence layer to manage it. And all of this runs on standard Ethernet. It is two companies building a single open stack, with no proprietary interconnects in the path.

What AMD brings: leadership compute and an open NIC. AMD handles the heavy lifting on the hardware side. They provide the compute itself through their Instinct MI300-series, MI400-series chips, and the ROCm software stack. To connect those chips to the network, they use the AMD Pollara AI NIC. It is the industry’s first UEC-ready AI NIC. The Pollara is built to be open, which means it can run on any network, lossy or lossless. It lets you program the RDMA transport and the congestion control directly, and it manages packets so your AI jobs finish faster.

What Aria brings: the fabric and the intelligence above it. Aria provides the network layers that AMD’s host connects to. This is where the concept of Deep Networking becomes concrete. In a traditional setup, the network is treated as a dumb, shallow pipe with some basic monitoring software bolted on after the fact. A deep network does the opposite. It builds intelligence directly into every layer, from the silicon up to the software.

The foundation of this system is the physical fabric. Aria builds 800GbE and 1.6Tbps switches using Broadcom Tomahawk 5 and Tomahawk 6 chips, running a highly reliable, hardened version of the open-source SONiC operating system. The fabric itself is lossless by design, using adaptive routing to dynamically bypass congestion on the fly.

But the real difference is the operational intelligence layer running on top of it, which is built on three main pillars.

The first is Fine-Grained Telemetry. To solve performance problems that live in microseconds, you need data that traditional monitoring simply cannot see. Aria captures network signals at 100 to 10,000 times the resolution of legacy tools, looking all the way from the host to the fabric.

The second is Agentic Orchestration. This is the context layer. It correlates what the network sees at the hardware level with what the software job actually knows. Because it understands the workload state, specialized agents can diagnose the root cause of failures and drive them toward resolution through guided workflows, moving the network from a passive dashboard to an active system that resolves issues with the operator in control.

The third is End-to-End Integration. A network is only useful if it can connect the entire stack. Aria is completely accelerator-agnostic and spans any NIC in your cluster. It integrates the switches, the network cards, the chips, and the software jobs onto a single, shared timeline. Because Aria focuses on the fabric and the software rather than the accelerator, it does not compete with AMD’s hardware. It is built to integrate perfectly right behind an AMD host equipped with a Pollara NIC.

Why the combination is more than the sum.

To understand why this combination matters, start with a basic truth about systems engineering: every architecture is a set of trade-offs. In the first wave of AI, the networking trade-off was stark. InfiniBand gave you predictable, lossless performance, but it tied you to a single vendor’s roadmap and pricing. Standard Ethernet was open and economical, but it was not originally designed for the synchronized, bursty traffic that AI generates, and it suffered from tail latency.

Ethernet has worked hard to close that gap, and it has come a long way. RoCEv2 brought RDMA to Ethernet, with Priority Flow Control to prevent packet drops and DCQCN to manage congestion. These are well-understood mechanisms that run at scale in production today. The difficulty is not that they fail. It is that they are demanding to operate. PFC prevents drops by pausing upstream senders, and at scale, those pause signals can propagate and exacerbate congestion if not carefully managed. DCQCN depends on a set of parameters that have to be tuned to the specific fabric, topology, and workload, and a configuration that is right today can drift as traffic patterns change. Historically, that tuning has been a manual, specialist exercise, which is why running RoCEv2 well at scale earned a reputation as difficult work, and why many operators still reached for the proprietary predictability of InfiniBand.

This is one of the places Aria’s intelligence layer earns its keep. Rather than leaving congestion control to a periodic hand-tuning exercise, Aria’s intelligence layer is designed to observe how the fabric behaves and adapt the configuration continuously, so the network stays in tune as conditions shift. The protocols are not the problem. Operating them by hand at scale is a problem that intelligence is well-suited to manage.

The Ultra Ethernet Consortium was formed to address these constraints at the transport layer itself, with an industry-wide effort to bring lossless predictability to open Ethernet while reducing the manual complexity that PFC and DCQCN demand. A key part of the approach is relaxing Ethernet’s traditional requirement that packets arrive in the exact order they were sent. That requirement is what prevents spreading a large flow across multiple paths, so UEC allows packet spraying with out-of-order delivery: break the flow into packets, spray them across every available link, and reassemble them at the destination.

These are promising approaches, and why an open, standards-based foundation matters. It lets you adopt these gains as they mature rather than betting the cluster on a closed stack. This is where the combination of AMD and Aria becomes powerful. Packet spraying and programmable congestion control are complex transport tasks performed at the edge of the server, which is exactly what AMD’s Pensando Pollara NIC is designed for. But a UEC-ready NIC is only half the system. Spray packets into a static switch, and it can be overwhelmed. You also need a fabric built on proven, capable silicon, running a hardened, UEC-compliant operating system, designed to handle that dynamic traffic. Together, the two are designed to deliver much of the lossless predictability that operators value in a proprietary interconnect, on a standards-based Ethernet network.

The real leverage in combining them is that it closes the visibility gap between the server and the network. That blind spot is where modern clusters waste the most compute. AMD instruments the host and the NIC. Aria’s intelligence layer is built to correlate those signals with the fabric and the job on a single timeline, so the system can surface microsecond-scale gray failures before they cascade into the run. By making the compute, the transport, and the fabric work as one open system, the goal is straightforward: you should not have to choose between performance and freedom. Getting both is what it takes to maximize the token efficiency of an AI factory.

Modern AI clusters rely on two distinct network fabrics with fundamentally different jobs. Together, they determine how efficiently your infrastructure converts capital investment into tokens. The frontend (north-south) fabric connects the cluster to users and shared infrastructure. It carries API and application traffic, orchestration, job scheduling, and storage access for datasets and checkpoints. Because it faces the outside world, this fabric must handle multi-tenancy and security while remaining predictable across highly diverse workloads.

The backend (east-west) fabric interconnects the accelerators themselves. It carries the collective communication that synchronizes gradients during training and, in disaggregated inference, transfers KV cache state between prefill and decode nodes. Because any accelerator waiting on data stretches training times and lags inference, this fabric demands extreme bandwidth, low latency, and lossless behavior under congestion.

The integration of AMD Instinct accelerators and Pollara NICs with Aria Deep Networking is engineered specifically to meet the critical demands of AI clusters.

Backend Network Fabric

The Backend fabric is built using one of the following topologies, depending on the expected scale and reach of accelerator collectives. A collective in this context is defined as a collection of accelerators that are intended to operate as a single distributed compute instance.

Fat Tree Topology

A Fat Tree topology connects all NICs from a set of hosts to the same leaf switch. As a result, this approach provides the simplest and most cost-effective interconnect option. It is applicable when the size of a collective is met by the density of a single leaf switch.

Rail Topology

In a Rail topology, NIC connections to leaf switches are organized by rank. Using a host configuration of 8 accelerators and 8 NICs as an example, each NIC within the host is linked to a different leaf switch. This architecture leverages the internal scale-up domain (AMD Infinity Fabric) to interconnect a larger collective of accelerators, all accessible via a single Ethernet switch hop on the backend fabric.

Below is an Aria Network design to support an 8-128 GPU cluster of AMD MI355X Systems.

Below is an Aria Network design to support a 4-Megawatt Design of 259 AMD MI355X Systems, for a total 2072 GPU cluster.

Multi-Plane Topology

A Multi-Plane topology consists of multiple replicas of backend leaf spine topologies. The Host NICs connect to each plane by breaking out their Ethernet ports into their constituent lanes. For example, a 400G NIC can break out its port to 4 lanes of 100G, and therefore connect to 4 different switching planes. This approach provides both increased redundancy and significantly increased collective sizes, at the cost of interconnect complexity.

Frontend Network Fabric

The frontend fabric is where customers, applications, cluster management, and storage converge. While the overall throughput of the frontend fabric is lower than that of the backend fabric, it must deliver consistent performance across a diverse set of traffic loads and cannot impede training execution or inference responsiveness. The recommended frontend connectivity model is to have all hosts (accelerator, storage, etc) dual-connect to separate leaf switches. This approach optimizes both throughput and redundancy.

If you are deploying AI factories and are starting to run into the limits of what standard networking can do, we should talk. We are looking for a few teams who are feeling this pain right now and want to help us prove that there is a better way to build.