UALink vs NVLink: What Changes in Rack and Facility Planning
A system-level comparison of UALink and NVLink: current specifications, bandwidth arithmetic, workload acceptance and the facility interfaces a buyer must resolve.
By Yuri MilyutinManaging Partner, ModulEdge
Specifications and system status checked 4 November 2026.
UALink (Ultra Accelerator Link) and NVIDIA NVLink address fast communication between accelerators, but they are not interchangeable networking products. UALink is a consortium specification family for an open accelerator interconnect. NVLink is NVIDIA's interconnect technology and system ecosystem, including NVLink Switch and the NVLink Fusion integration programme. Choosing between systems built around them requires a matched workload, a specific topology, a supported software stack and a complete physical installation plan.
For a facility owner, the purchasing question is which assembled system must be powered, cooled, connected and maintained. A standard's maximum endpoint count or a GPU's advertised bandwidth cannot answer it. Our GPU data center planning guide explains the complete facility brief; this comparison focuses on the fabric decisions that must be resolved before that brief is frozen.
TL;DR
- Compare a complete accelerator system with another complete system. A specification ceiling is not a purchasable rack or a measured application result.
- Keep scale-up communication, scale-out networking, CPU connections and storage traffic separate in diagrams and bandwidth tables.
- Normalize bandwidth to the same units, direction, endpoint count and protocol boundary. Per-lane, per-GPU and whole-rack numbers describe different things.
- UALink publication does not establish that every advertised component combination is validated. NVLink Fusion broadens NVIDIA-based integration without making arbitrary devices compatible.
- The facility follows the purchased implementation: switches, network racks, cable routes, service zones, electrical schedules and both liquid and air heat.
- Accept the cluster against application goodput, fabric health and agreed failure cases, rather than a successful power-on or one peak bandwidth test.
Begin with the communication boundary
Scale-up usually describes a tightly connected accelerator domain used for frequent communication during a distributed computation. Scale-out connects systems or domains into a larger cluster. Those labels are useful only when the drawing identifies the devices, protocols and boundaries involved. They do not reliably mean “inside a rack” and “outside a rack.” A domain can span enclosures, and a rack can contain multiple domains.
Consider a model divided across accelerators. Some operations exchange partial results repeatedly while others transfer larger blocks less often. The application can be sensitive to latency, available bandwidth, collective implementation, contention or several of these together. A fabric selected for one communication pattern may not deliver the same benefit for another.
Tensor parallelism splits individual model layers across GPUs; expert parallelism distributes the experts of a mixture-of-experts model. Their communication follows those partitions. Standard distributed data parallelism replicates the model and synchronizes gradients across replicas. Sharded variants change model-state placement and communication. These approaches can be combined, as NVIDIA's parallelism documentation explains. Independent inference replicas can serve separate requests without partitioning each request across the whole fleet. Therefore record which devices cooperate on one request or training step, and which merely increase the number of independent jobs. Those arrangements create different fabric requirements even with the same installed GPU count.
That is why a comparison should start with the parallelism plan: which operations stay within a device, which cross the local accelerator domain, and which cross the cluster network. Record the model, precision, sequence lengths, batch or concurrency, and latency or job-completion objective. Without these, “faster interconnect” does not identify an engineering requirement.
CPU-to-GPU links are another boundary. So are storage and management networks. Do not add their advertised rates to GPU-to-GPU bandwidth to manufacture a larger total. Our GB300 NVL72 guide treats a particular rack-scale platform; its numbers should remain attached to that platform rather than becoming universal NVLink requirements.
What the current UALink specifications establish
The consortium's public specification index describes UALink 200G 1.0 as enabling 200G-per-lane connections and up to 1,024 accelerators within a computing pod. It also lists Common 2.0, 200G Data Link/Physical Layers 2.0, Manageability 1.0 and chiplet specifications. These are specification capabilities, not evidence that a 1,024-accelerator system is available from every supplier. UALink specifications
The April 2026 update adds in-network compute and separates the common specification from the data-link and physical layers. It also introduces management and chiplet work. A procurement specification therefore needs document names and revisions, rather than an undated requirement for “UALink support.” UALink's April 2026 release
Ask suppliers which parts they implement, which functions are exercised by the proposed system and which combinations have been tested. An accelerator, switch, retimer and firmware release can each support a relevant technology while the assembled combination still needs validation. The same applies to management integration and recovery behaviour.
Ethernet-related physical technology does not make a UALink fabric an ordinary Ethernet LAN. Physical signalling, connectors, transaction semantics, switching and management are distinct layers. A familiar cable or port speed does not establish protocol interoperability. The consortium's technical white paper describes memory-semantic communication and the scale-up architecture; actual component and system documentation must establish the supported implementation.
What NVLink and NVLink Fusion establish
NVIDIA's published NVLink table distinguishes generations: Hopper's fourth generation, Blackwell's fifth and Rubin's sixth. The fifth-generation figure is 1,800 GB/s per GPU; the NVL72 aggregate is approximately 130 TB/s. These are interface and endpoint-aggregate figures, not a promise that every pair of GPUs can simultaneously exchange data at the full per-GPU rate. NVIDIA NVLink
The current page lists sixth-generation figures of 3,000 GB/s per GPU and 216 TB/s for NVL72, and labels its specifications preliminary. Earlier NVIDIA material carries different Rubin figures. For an actual purchase, use the approved OEM system revision and its supported topology, rather than selecting the most favourable number from different launch documents.
NVLink Fusion also changes an overly simple “open versus closed” comparison. It provides a route for integrating semi-custom CPUs or accelerators with NVIDIA interconnect and rack-scale infrastructure. It is a designed integration ecosystem, not permission to attach any accelerator to an existing NVLink rack. NVIDIA NVLink Fusion
For the buyer, the evidence remains specific: supported devices, validated system design, firmware and library requirements, supplier accountability and the hardware actually offered. A technology roadmap is useful for capacity planning, but it is not a contractual upgrade path for installed equipment.
A comparison table that keeps the boundaries visible
| Decision | UALink-based proposal | NVLink-based proposal | Evidence to request |
|---|---|---|---|
| Technology definition | Named consortium specifications and implemented functions | Named NVLink generation, switches and system platform | Revision-controlled architecture |
| Domain size | Implemented endpoint count and topology, within relevant specification limits | GPU domain supported by the purchased system | Populated and partial-population diagrams |
| Bandwidth | Lanes, endpoint allocation, direction and usable payload | Per-GPU links, switching and endpoint aggregation | Matched measurement definition |
| Integration | Accelerator, switch, firmware and management combination | Supported GPU or Fusion integration and software stack | System validation and support matrix |
| Cluster connection | Defined NICs, network and storage interfaces | Defined scale-out and storage fabrics | End-to-end cable and port schedule |
| Physical consequence | Actual rack/tray layout and service envelope | Actual rack/tray layout and service envelope | OEM mechanical, electrical and thermal package |
The table intentionally leaves out a universal cost or performance winner. Those outcomes depend on the assembled system and workload. “Open” describes governance or integration possibilities; it does not assign responsibility for a fault. A supplier should still state who owns compatibility testing, issue resolution, replacement parts and the acceptance result.
Do the bandwidth arithmetic before drawing conclusions
Three errors frequently invalidate comparisons: mixing bits and bytes, combining transmit and receive, and comparing a lane with an accelerator or rack. Use decimal units consistently when following vendor GB/s and TB/s specifications, and label any binary-unit conversion separately.
Here is a deliberately hypothetical normalization example. Assume an interface allocates four lanes, each carrying 200 Gb/s in each direction:
4 × 200 Gb/s = 800 Gb/s = 100 GB/s in one direction
If the link supports that rate simultaneously in both directions, its combined transmit-plus-receive figure is 200 GB/s. That does not mean a one-direction transfer receives 200 GB/s. Encoding, protocol and implementation effects can reduce useful payload further. This arithmetic is not the specification of a particular UALink device.
Similarly, a quoted 1,800 GB/s bidirectional endpoint allowance normalizes to 900 GB/s in each direction only when the interface definition is symmetric and supports that interpretation. It is still not application throughput. The number of active peers, routes, message sizes and collective algorithm determine how the allowance is used.
A whole-rack aggregate is usually the sum of endpoint allowances under a stated convention. It is not automatically bisection bandwidth, one flow's bandwidth, or the speed of a model update. Avoid dividing two differently defined headline rates and calling the result a speedup.
| Number in a presentation | What it may describe | What it does not establish |
|---|---|---|
| 200G per lane | A lane-level rate under the named specification | Total bandwidth of a populated accelerator |
| GB/s per GPU | Endpoint link capacity under a vendor convention | Sustained throughput to every peer at once |
| TB/s per rack | Aggregation across multiple endpoints | Bisection or application goodput |
| Collective benchmark | A tested operation, size and topology | Performance of every model or service |
Do not confuse UALink with every link in Helios
AMD's current Helios description identifies UALink over Ethernet, or UALoE, for its scale-up cartridges. It separately describes Pensando networking and UALink connectivity associated with the NIC path. A generic description of the consortium's scale-up standard is therefore insufficient to label every connection in a Helios system. AMD Helios architecture
Request a diagram identifying the actual protocol and endpoint at each segment: accelerator-to-accelerator, accelerator-to-switch, accelerator-to-NIC, and NIC-to-cluster network. Ask where conversion, routing or collective operations occur. A product-family name cannot substitute for this drawing.
Our existing AMD Helios facility guide owns the rack's power, geometry and cooling discussion. This comparison adds the interconnect boundary questions. It does not transfer an entire Helios layout into every UALink system, or imply that a facility qualified for an NVIDIA rack automatically accepts an AMD implementation.
Software and measured goodput decide whether the fabric helps
The application reaches the hardware through frameworks, runtimes and communication libraries. NVIDIA's NCCL supports topology-aware collectives and several communication transports; AMD's RCCL provides multi-GPU and multi-node collective primitives for AMD systems. Their documentation is a starting point, not proof that a particular software release supports every new hardware arrangement. NCCL overview, RCCL documentation.
Build a reproducible acceptance workload. Record the model or scientific job, dataset, precision, framework, compiler, library and firmware versions. For inference, include input/output lengths, concurrency, latency constraints and accuracy or quality acceptance. For training, include batch, parallelism, checkpoint and completion criteria.
Measure fabric operations across representative message sizes, then run the application. A good large-message collective result can coexist with a poor latency-sensitive service. Conversely, a workload that rarely crosses a domain boundary may gain little from a more capable fabric. Procurement should compare the useful output delivered within the required service conditions, including the supporting infrastructure and software effort.
Retain power and error telemetry during tests. A throughput result obtained with throttling, link retries or unrealistic cooling conditions can conceal an operating constraint. Repeat the test after the agreed maintenance or failure case; distinguish reduced performance from loss of service. The operating team needs to know which outcome the design supports.
Memory access does not make capacity automatically interchangeable
A memory-semantic interconnect allows operations against memory associated with another endpoint under the implementation's rules. That does not establish that all installed HBM appears to every process as one unrestricted allocation, or that accessing remote memory costs the same as accessing local memory. Addressability, coherence, software allocation and application placement are separate questions.
Suppose a hypothetical deployment contains 16 accelerators with 100 GB of nominal device memory each. Installed nominal capacity totals 1.6 TB. If a model's weights require 600 GB, that total shows that a partitioned placement may be possible. It does not show which partitioning scheme is supported, how much memory remains for runtime and active requests, or whether inter-device transfers meet the latency target. Four independent model replicas also have a different memory layout from one model spread across all 16 devices.
Request a supported placement example from the system supplier. It should identify the process layout, model partitions, reserved memory, communication groups and tested operating limits. For a multi-tenant service, include resource isolation and the consequences of removing one endpoint. These requirements turn “pooled memory” from a presentation phrase into a configuration the operator can reproduce.
Make the acceptance example match the production service
An illustrative acceptance plan for interactive inference might specify a fixed model and precision, a defined distribution of prompt and response lengths, a concurrency ramp and agreed latency limits. Hold the model, evaluation data and service conditions constant, using each candidate's supported, version-recorded image and runtime. Document necessary software differences and their effect on quality or performance; an identical GPU-enabled container is not a general portability requirement across vendors. AMD's framework integration guidance illustrates the need for matching ROCm builds and tested images. Report accepted output within the limits, not only the maximum obtained after allowing queues to grow.
Test the intended placement as well as a reduced domain. If an application is expected to survive removal of a node or switch component, agree the supported recovery procedure first and observe its consequences: interrupted jobs, restart time, reduced capacity and lost work. A component's serviceability feature does not establish application continuity.
Keep the test duration, warm-up, clock/power policy and thermal conditions visible. Save link counters, error events and system telemetry alongside workload results. The facility and IT teams should use synchronized timestamps so a throughput change can be checked against power limiting, coolant conditions or network events. An unexplained anomaly belongs in the acceptance record even when the average result passes.
Translate the network drawing into a facility requirement
The fabric can affect rack adjacency, cable reach, switch placement, service access and the amount of support equipment outside the compute rack. Resolve those consequences before fixing a building layout. A rack count based solely on compute trays can omit network, storage and management positions needed for the working cluster.
Issue a point-to-point cable schedule with source and destination ports, technology, maximum supported distance, installed route, bend requirements and labelling. Keep liquid pipes, power distribution and lifting/service routes on the coordinated drawing. The shortest straight line between two racks is not necessarily an installable cable path.
Electrical and thermal schedules should include fabric switches and network equipment under the selected operating cases. Liquid-cooled compute does not establish that every switch, cable assembly or support device uses the same cooling interface. Our power-distribution guide and liquid-cooling design guide follow those separate paths.
For liquid-cooled components, define the heat split, supply/return temperatures, flow, pressure and control boundary. Select a CDU from the actual thermal and hydraulic requirements; the CDU sizing guide explains why a kW label alone is insufficient. Network equipment must remain serviceable when adjacent racks are operating and when a cooling component is isolated.
Do not use an annual PUE to turn compute nameplate into a final feeder rating. PUE relates energy boundaries over a defined period; peak input, transient behaviour and failed-path capacity need their own electrical analysis. The PUE measurement guide explains that distinction.
Write the purchasing and acceptance package around the assembled system
A useful request for proposal combines a system bill of materials with evidence against a small number of decisions:
- Supported architecture: topology, endpoint counts, link types, specification revisions and future expansion limits.
- Performance: repeatable fabric tests and representative application results with quality and service constraints.
- Physical integration: rack and tray dimensions, loaded mass, connection locations, service zones and cable schedule.
- Power and heat: complete input and heat-load schedules, operating limits, supported maintenance states and alarm/control ownership.
- Software: validated versions, update procedure, licence/support boundaries and recovery path.
- Accountability: a party responsible for the assembled result, with acceptance criteria, defect resolution and documented exclusions.
A component supplier may answer only part of that package. The project owner must assign the rest explicitly. Our manufacturer, provider and integrator comparison explains why supplier labels alone do not settle design or warranty responsibility.
For a new facility, freeze the OEM system interface schedule with the infrastructure design. ModulEdge's configuration process can use that schedule to assess the building, power, cooling and site interfaces. The MDC2000 product page describes one infrastructure direction, while the product comparison helps distinguish it from smaller workload requirements. None of those routes certifies a fabric or guarantees application performance.
The completed brief should let a buyer explain why a specific assembled system meets the workload and how its physical interfaces will be supported. That is a stronger basis for choosing UALink- or NVLink-based infrastructure than a comparison of two unqualified bandwidth headlines.
Frequently asked questions
What should the support agreement say about a partly populated domain?
Identify permitted populations, disabled or reserved ports, supported software settings and the performance evidence for each offered arrangement. State who approves later additions and whether expansion requires downtime or renewed acceptance. A full-population benchmark is not automatically the acceptance record for a smaller purchase, even when both use the same rack family.
Who should own a firmware rollback across several suppliers?
Name a coordinator and an approved compatibility baseline covering the affected devices and management software. Require a recovery procedure, retained images/settings and escalation contacts before accepting updates. The project must establish whether rollback is supported and which intermediate states are safe; a collection of individual component warranties does not answer those integration questions.
Can a cable or retimer be substituted during delivery?
Treat it as a controlled configuration change. Ask the system supplier to confirm the proposed part against the installed topology, link settings, route and service requirements, and identify the checks that must be repeated. Do not accept matching connector appearance or nominal rate as sufficient evidence. Record the approved replacement in the as-built cable and component schedules.
Which test evidence can be reused between two OEM configurations?
Carry over the workload definition and measurement method, then map every hardware, firmware, software and environmental difference. Ask the accountable supplier which results remain applicable and which require repetition. A component report can support the review, but acceptance of a different assembled topology needs a documented justification rather than a copied pass sheet.
Is changing the interconnect the same as making the application portable?
No. A migration plan also needs supported model operations, precision, kernels, framework/runtime, checkpoint or artifact handling and an equivalent quality test. Separate code changes from configuration changes and retain a reproducible baseline on the original system. Establish what the application must preserve before deciding whether the new fabric's capabilities improve its service.
How should quotations for future expansion be compared?
Separate installed capability, reserved physical interfaces and unpurchased future equipment. Request the expansion bill of materials, supported population, required software changes and interventions on the running installation. Price the work to reach the same accepted endpoint, including repeat tests and service interruption where applicable. A roadmap connection or empty rack position is not installed capacity.
