Same advertised bandwidth, different question
Our MI455X versus Rubin comparison began with memory: 432 GB of HBM4 at AMD, 288 GB at NVIDIA, then the same advertised 3.6 TB/s of scale-up bandwidth on both sides. This analysis starts where that one stopped. Once the GPUs have links with the same peak rate, what does the fabric do with the data moving through it?
The question became concrete on April 7, 2026, when the UALink Consortium released Common 2.0 with an in-network compute facility. A switch can participate in selected reductions, aggregations and synchronization operations instead of carrying every operand to an accelerator that completes the work. NVLink already implements the principle under the SHARP name; NVLink 6 brings it inside a Vera Rubin rack with a published FP8 compute rate.
This change does not turn a network into a GPU. A switch executes a bounded instruction set over flows it already forwards. It runs neither an attention layer nor a general matrix multiplication. That specialization is the point: adding values as they pass through the ports requires fewer data movements than delivering them intact to an endpoint, waiting for that endpoint to compute, then sending the result back.
The comparison therefore has three layers: the semantics that describe an operation, the switch silicon that executes it and the collective library that decides to use it. A specification without an implementation removes no latency; a reduction engine without a software path sits idle.
What the switch actually removes from all-reduce
An all-reduce combines a value held by every GPU, a gradient sum for example, then returns the complete result to all participants. Without in-network compute, the GPUs or their controllers read buffers, send fragments, add received values and propagate the result through a ring or tree. The fabric transports; the endpoints reduce.
With in-network compute, a switch receives fragments for the same position, produces a partial sum and forwards only that aggregate to the next stage. The path resembles an addition tree wired into the interconnect. Some arithmetic and synchronization leave the GPUs and move to the place where the data already travels.
The gain is not the disappearance of traffic. Every GPU still has to inject its contribution and receive the final result. A mature software ring already distributes the arithmetic across participants and approaches link bandwidth on large messages. Compute in the switch primarily attacks redundant copies, HBM round trips and endpoint barriers. Its value therefore depends on message size, rank count, topology and how much communication the runtime can overlap with useful compute.
That limit separates two workload regimes. A large training all-reduce contains enough data to fill the links, so sustained bandwidth dominates. An all-reduce repeated at every layer of tensor parallelism Splitting one neural-network layer across several accelerators. Each GPU computes a partial output, then a collective operation merges the fragments before the next layer. The wider the split, the more interconnect latency and bandwidth contribute to the time per token. inserts shorter rendezvous on the critical path, making launch latency, packet rate and offload more important. In-network compute cannot have one universal speedup because it removes different costs in those two regimes.
UALink 2.0: semantics before a product
UALink Ultra Accelerator Link. An open scale-up communication standard for accelerators. It exposes reads, writes and atomic operations across a distributed address space, with coherency managed in software. AMD carries it over Ethernet in Helios under the name UALoE. 200G 1.0 defines a memory-semantic scale-up fabric. An accelerator can issue reads, writes and atomic operations against a peer’s memory. The white paper promises the same address-ordering model for local and remote memory, but it does not describe hardware cache coherence across the pod. The protocol gives a runtime more direct primitives than a conventional network stack without turning distributed HBM into one physical memory pool.
Each lane operates at 200 GT/s. Four lanes form a station that can transmit 800 Gbit/s and receive 800 Gbit/s. UALink supports 64, 128, 192 and 256-byte requests; the consortium ties the 256-byte ceiling to accelerator HBM interleaving. Its white paper also sets an architectural target below one microsecond for a request-response round trip in a pod of up to 1,024 accelerators. That is a design target, not a measured Helios latency.
Common 2.0 layers in-network compute over that transport. The consortium cites reductions, aggregations, synchronization, collective primitives, selected data transformations and scheduling optimizations. Its freely accessible presentations provide neither an operation rate nor a collective result from a commercial implementation. The standard says how a capability can be exposed. It does not prove how much silicon a vendor dedicates to it.
UALink 2.0 also separates the Common layer from the 200G link and physical layers. Collective semantics can evolve without changing electrical signaling every time. A separate manageability specification describes centralized control built on gNMI, YANG, SAI and Redfish. This separation is UALink’s wager: different vendors can evolve the PHY, switch, accelerator and management plane behind shared interfaces.
The word open still needs a boundary. The specification is publicly available under an evaluation license, but publishing a document does not create interoperability. In April 2026 the consortium still said its compliance and interoperability programs would be introduced later. Until two independent implementations pass the same suite, “multi-vendor standard” describes an ecosystem objective, not a rack whose components are already interchangeable.
UALoE in Helios: reconstructing the number
Helios does not use a fabric built directly on the UALink 200G link and physical layers. AMD’s UALink over Ethernet, or UALoE, carries UALink over an Ethernet network; AMD and Broadcom present the joint design with Tomahawk switches and the eSUN framework. UALoE is an AMD product architecture here, not another revision published by the UALink Consortium. The 72 MI455X GPUs connect to twelve switching ASICs across six trays. The topology is multi-plane and single-hop: traffic between two GPUs crosses one switch, with multiple paths available.
Each GPU has eighteen UALoE stations. AMD does not publish their individual rate on the Helios page. If station keeps the x4 width defined by UALink 200G 1.0, each station carries 800 Gbit/s per direction, or 100 GB/s. Eighteen stations then yield 1.8 TB/s transmit plus 1.8 TB/s receive, or 3.6 TB/s when both directions are added. The result matches AMD’s total, making the reconstruction credible; it is not a substitute for an electrical UALoE specification or an application measurement.
The rack total follows the same arithmetic. Seventy-two GPUs times 3.6 TB/s gives 259.2 TB/s, rounded to 260 TB/s aggregate. That figure counts endpoint interfaces in both directions. It states neither bisection bandwidth, useful all-reduce throughput nor the traffic one path can sustain when several planes are loaded together.
AMD documents resilience: the eighteen stations are distributed across trays, and a link, cable or switch failure triggers rerouting over the remaining paths. AMD Fabric Manager and AMD Fabric OS handle provisioning, telemetry and recovery. vPods partition the 72 GPUs into isolated domains for concurrent workloads.
Those functions make UALoE an operational rack fabric. They do not establish in-network compute. HPE identifies the Helios scale-up ASICs as Broadcom Tomahawk 6. Broadcom documents in-network collectives on a different family, Tomahawk Ultra BCM78920. The Helios pages and AMD technical documents reviewed for this article do not identify the exposed Common revision, claim that engine in the UALoE switches or document RCCL activating it. Automatically assigning the Common 2.0 functions to Helios would therefore be incorrect.
NVLink 6: SHARP already has a software path
NVLink NVIDIA's proprietary GPU-to-GPU interconnect. NVLink 5 (Blackwell) reaches 1.8 TB/s bidirectional per GPU; NVLink 6 (Rubin) doubles that to 3.6 TB/s. With NVSwitch, it accelerates GPU-to-GPU transfers and collectives; memory remains physically distributed, and remote access does not have the cost of local HBM. 6 connects 72 Rubin GPUs to 36 NVLink Switch ASICs in a single-hop, all-to-all topology. NVIDIA also advertises 3.6 TB/s bidirectional per GPU and 260 TB/s aggregate for NVL72. One switch tray contains four ASICs, provides 28.8 TB/s of advertised bandwidth and 14.4 FP8 TFLOPS of in-network compute. The rack total rounds to 130 FP8 TFLOPS.
That compute runs SHARP, NVIDIA’s hierarchical aggregation and reduction protocol. The switches participate in all-reduce, reduce-scatter and all-gather. NCCL already exposes NVLink SHARP as NVLS; NVIDIA’s NVLink-system documentation lets operators enable or disable it with NCCL_NVLS_ENABLE. The route from framework to collective library to switch is documented, even though public measurements still cover earlier generations or NVIDIA’s own results.
NVIDIA credits SHARP in NVLink 6 with up to 50% less all-reduce traffic and up to 20% less tensor-parallel time. These remain vendor results. The technical page does not provide a complete model, message sizes, precise participant count or NCCL configuration that would reproduce them on Rubin. It also says the result depends on model architecture, parallelism strategy, participant count and NCCL configuration.
The same restraint applies to latency. NVIDIA claims three times lower end-to-end latency and ten times higher packet throughput than “off-the-shelf Ethernet.” The comparator is not Helios, and no absolute figure is given. UALoE uses specialized ASICs and protocols, not an enterprise Ethernet setup. Treating those ratios as an NVLink 6 versus UALoE measurement would be an unsupported extrapolation.
What the data sheets actually compare
| Criterion | UALink 2.0 / Helios UALoE | NVLink 6 / Vera Rubin | What it establishes |
|---|---|---|---|
| Per-GPU bandwidth | 3.6 TB/s bidirectional | 3.6 TB/s bidirectional | Same sum of endpoint rates |
| Advertised domain | 72-GPU Helios, single-hop, multi-plane | 72-GPU NVL72, single-hop, all-to-all | Same rack size, different fabrics |
| Rack bandwidth | 260 TB/s aggregate | 260 TB/s aggregate | 72 × 3.6 TB/s, not an all-reduce |
| In-network compute | Defined by Common 2.0; Helios rate unpublished | SHARP; advertised 130 FP8 TFLOPS | NVIDIA integration is better documented |
| Collective gain | No public Helios result identified | Up to 50% less traffic and 20% less TP time, per NVIDIA | No reproducible comparison |
| Latency | UALink 1.0 target below 1 µs; no Helios measurement | 3× ratio against off-the-shelf Ethernet; no absolute value | The figures are not comparable |
| Public software | RCCL runs collectives; UALoE INC path undocumented | NCCL documents NVLink SHARP / NVLS | Visibility advantage for NVIDIA |
| Interoperability | Open specification; compliance program pending | Integrated NVIDIA stack | Intended openness versus delivered integration |
The only robust equality is the advertised bidirectional bandwidth at the GPU endpoints. Every other row contains different kinds of evidence. UALink publishes interfaces and protocol targets; AMD publishes a product topology without collective metrics; NVIDIA publishes more integration detail alongside gains it measured itself.
That asymmetry blocks two shortcuts. SHARP having a TFLOPS figure does not prove that NVLink wins; 130 TFLOPS of reduction compute does not give the duration of a collective without a shared workload. Common 2.0 containing the same category of function does not prove that UALink has caught up; an operation in a standard says nothing about silicon area, clock rate or runtime support.
The benchmark that is still missing
Ranking the fabrics requires fewer marketing columns and more curves. The first axis is message size, from a few kilobytes to several gigabytes, with latency and useful throughput for all-reduce, reduce-scatter, all-gather and all-to-all. The second is participant count: 4, 8, 18, 36 and 72 GPUs. The third is concurrency: one isolated collective reveals neither congestion from several models nor isolation between vPods or NVLink partitions.
The test must then restore application compute. all_reduce_perf measures the collective library and fabric, but not whether the runtime overlaps the collective with a kernel. The same model, format and parallelism should therefore report GPU time spent in communication, time per output token and throughput under a latency bound. For a MoE, all-to-all must remain separate: reducing values inside a switch does not automatically accelerate the routing of distinct activations to different experts.
Failure behavior belongs in the protocol. Load the fabric, remove a link or switch tray, then measure convergence time, lost requests and post-reroute throughput. A multi-plane architecture can preserve service while losing a fraction of capacity; a tightly integrated topology may isolate the fault faster. Both vendors claim continuity, but neither publishes the same experiment.
In our view, the 2026 winner will not be the platform that prints 260 TB/s. It will be the first to publish a complete matrix of message size, collective, participant count, concurrency, failures and energy, with the software configuration required to reproduce it.
Openness will have to be measured in the switch
UALink 2.0 changes the nature of the contest. The consortium is no longer proposing only another fast link; it is standardizing the point where the network participates in computation. That is the right boundary because collectives have become part of the distributed program, not merely a transfer between two kernels.
NVLink 6 begins with a visible lead: SHARP has quantified silicon and a documented NCCL path. UALink’s strength is different, the possibility of separating GPU, switch, PHY and software vendors. It will remain theoretical until an interoperable UALink 2.0 product publishes supported operations, throughput and collective results.
The next contest will not be 3.6 versus 3.6 TB/s. It will begin when two switches receive the same buffer, execute the same reduction and expose the same timing counter. At that point, openness and integration will stop being promised architectures and become observable performance.
Sources and method
UALink specifications, verified facts. The official UALink specifications page establishes the availability of Common 2.0, 200G 2.0 link/physical layers and Manageability 1.0. The April 7, 2026 ratification announcement defines the in-network compute scope, layer separation and future status of compliance programs. The UALink 200G 1.0 white paper supports 200 Gbit/s per lane, the x4 station at 800 Gbit/s per direction, the sub-microsecond target and a domain of up to 1,024 accelerators. The consortium’s technical Q&A supports request sizes, port-to-port latency targets and the lack of normative latency and bandwidth bounds per interface.
UALink in-network compute, verified facts and documentary limit. The consortium’s technical presentation lists reductions, aggregations, synchronization, collective primitives, transformations and scheduling. The absence of product throughput and a Helios benchmark is limited to freely accessible official sources reviewed on August 30, 2026; it does not prove that no private implementation exists.
AMD Helios and UALoE, vendor facts. AMD’s official Helios page gives 72 GPUs, 260 TB/s aggregate, two ASICs per switch tray and a multi-plane UALoE topology. The July 2026 Helios blueprint and ROCm technical description document six switch trays and twelve switches. AMD’s network-stack description provides eighteen stations per GPU, the single-hop path, rerouting, Fabric Manager, Fabric OS and vPods. The AMD and Broadcom technical session connects Helios to Tomahawk switches and eSUN; the official HPE announcement identifies Tomahawk 6. Broadcom’s Tomahawk Ultra BCM78920 page assigns in-network collectives to that separate family. These are vendor sources; no AMD performance gain is treated as an independent measurement.
NVIDIA NVLink 6 and SHARP, vendor facts. NVIDIA’s NVLink and NVLink Switch page supports 3.6 TB/s per GPU, 260 TB/s per NVL72, up to 36 links and SHARP support. The NVLink 6 technical description supports 36 switch ASICs, four ASICs and 14.4 FP8 TFLOPS per tray, 130 TFLOPS per rack and resilience functions. The Vera Rubin architecture article supplies the claimed 50% all-reduce traffic reduction and 20% tensor-parallel time reduction. Both gains are attributed to NVIDIA rather than presented as independent results.
Software path, verified facts. NVIDIA’s multi-node NVLink systems guide documents NVLink SHARP activation with NCCL_NVLS_ENABLE. The official RCCL repository documents supported collectives and ring or tree algorithms. The public RCCL documentation reviewed for this article does not describe a switch that activates UALoE in-network compute on Helios.
Derived calculations. Deriving 3.6 TB/s from eighteen UALoE stations assumes that a UALoE station keeps the x4 width of UALink 200G 1.0: 800 Gbit/s per direction equals 100 GB/s, so eighteen stations yield 1.8 TB/s in each direction. It matches AMD’s published total but remains a documented estimate because no per-station UALoE rate is published. The rack total is arithmetic: 72 interfaces at 3.6 TB/s give 259.2 TB/s, rounded to 260. Neither calculation predicts useful throughput.
Claims excluded. This article names no performance winner. No shared public measurement of absolute latency, collective throughput, energy or failure behavior for Helios UALoE and Vera Rubin NVLink 6 had been identified by August 30, 2026. NVIDIA’s 3× latency and 10× packet-throughput ratios compare NVLink 6 with unspecified off-the-shelf Ethernet, not directly with UALoE, so they are not used to rank the fabrics.
