AMD Is Rebuilding the GPU Stack in the Open

The series’ read is that AMD is the closest merchant alternative to NVIDIA because it is rebuilding more than a GPU. Instinct accelerators now sit inside eight-GPU platforms, liquid-cooled racks, Ethernet fabrics, open scale-up standards, and a software stack that reaches from PyTorch kernels to cluster validation.

The architecture is deliberately less vertically owned. AMD supplies critical pieces, but ROCm, UALink, UALoE, Ultra Ethernet, OEM systems, merchant switches, optics, and facility integration cross organizational boundaries. That creates choice at each layer—and makes the operator responsible for proving that those layers work as one system.

TL;DR

• Instinct evolved from a 32 GB accelerator in MI100 to 288 GB of HBM3E in MI355X, while the deployment unit expanded from a PCIe card to eight-GPU platforms and a planned 72-GPU Helios rack.
• AMD’s current shipping scale-up path still centers on Infinity Fabric inside an eight-GPU platform; Helios shifts the rack-scale domain toward the open UALink ecosystem and AMD’s Ethernet-based UALoE fabric.
• ROCm is open and increasingly production-oriented, but openness does not remove qualification work. AMD documents exact operating-system, driver, firmware, container, collective-library, and network requirements.
• AMD has credible evidence: production availability through major cloud and OEM channels, MLPerf submissions, and named deployments. That evidence still does not establish interchangeable performance across models, precisions, software versions, or rack designs.

The accelerator became a memory system

The clearest Instinct trend is not a single compute multiplier. It is the steady expansion of the memory domain surrounding the accelerator.

MI200 made chiplets part of the accelerator design. MI300X pushed the idea further: eight compute dies sit over four I/O dies, connected through Infinity Fabric and surrounded by eight HBM stacks. AMD’s CDNA 3 architecture documentation describes the package as one logical accelerator even though compute, I/O, and memory are physically disaggregated.

MI350 continues that direction with CDNA 4 and denser low-precision formats. The more durable change is 288 GB of HBM3E per accelerator and 2.3 TB across an eight-GPU platform. Large models can retain more weights and key-value cache close to compute, reducing how often capacity pressure forces work across slower boundaries.

Helios changes the boundary again. AMD’s current public design pairs 72 MI455X GPUs with EPYC host processors, Pensando networking, 31 TB of HBM4, and 1.7 PB/s of aggregate HBM bandwidth. Those are announced system specifications, not a claim about generally available production capacity or measured application performance.

Scale-up is moving from a platform to a rack

MI300X, MI325X, and MI355X platforms connect eight GPUs through Infinity Fabric. At that scale, AMD controls the accelerator package and much of the GPU-to-GPU communication path. The OEM still owns the server implementation, firmware bundle, power delivery, cooling, and qualification.

Helios expands the scale-up domain to 72 GPUs. Its architecture uses AMD’s UALoE—an Ethernet-based fabric using UALink-aligned semantics—rather than treating Ethernet only as the network between independent servers. AMD develops this path alongside the broader UALink Consortium effort, where accelerator, switch, CPU, and systems companies define an open scale-up interconnect.

The diagram exposes the trade. An open interface can let multiple switch, accelerator, cable, and system suppliers participate. It does not create one owner for congestion control, firmware compatibility, optics, cabling, collectives, telemetry, or failure recovery.

Scale-out follows the same pattern. AMD is a founding member of the Ultra Ethernet Consortium, while Pensando supplies NIC and DPU technology. The resulting cluster can use familiar Ethernet operations and merchant switching, but the final behavior depends on the complete path: GPU memory, PCIe attachment, NIC firmware, switch configuration, routing, loss management, RCCL, and the model’s communication pattern.

ROCm makes portability possible, not automatic

ROCm is no longer accurately described as a compiler shim around a GPU. It includes the HIP programming model, math and kernel libraries, RCCL collectives, profiling and debugging tools, container images, model recipes, validation utilities, and integrations with major frameworks.

HIP can translate a large amount of CUDA-shaped source code and preserve a familiar kernel programming model. It cannot guarantee that a CUDA extension compiles unchanged, that the same fused kernel exists, or that identical scheduling choices remain optimal. Portability is strongest at the framework and model-contract layers; it weakens around custom kernels, collectives, memory placement, quantization, and compilation.

AMD’s own compatibility matrices make this responsibility explicit. Supported configurations pair specific GPU architectures with operating systems, kernel drivers, firmware, libraries, and framework releases. The Instinct cluster deployment guides add validated NIC, RoCE, topology, and collective requirements. A container freezes user-space dependencies, but it does not freeze host drivers, GPU firmware, NIC firmware, switch behavior, or cooling performance.

That is the operational difference between open source and an integrated product boundary. Source access improves inspection, contribution, and supplier choice. It does not eliminate systems engineering.

Deployment evidence is real but uneven

AMD has moved beyond reference designs. MI300X and later Instinct platforms are available through major server vendors and cloud providers. Microsoft’s Azure ND MI300X v5 virtual machines expose eight MI300X GPUs with 1.5 TB of aggregate HBM. Oracle has published MI355X cluster results and deployment details. Microsoft has separately announced that Azure will deploy Helios for inference, with AMD stating that shipments begin in the second half of 2026.

The evidence ladder still matters:

None of these rows alone proves lower service cost or better application performance. A useful comparison must align model, precision, sequence length, batch policy, software version, system count, networking, power boundary, and availability target. A result from eight MI300X GPUs cannot be casually compared with a rack-scale result, and an announced 72-GPU design is not equivalent to a measured production fleet.

The open stack changes the buying decision

AMD’s advantage is not that every layer is interchangeable. It is that more layers can be selected, inspected, and sourced independently: accelerator, host CPU, NIC, switch, rack integrator, framework build, inference engine, and cloud or on-premises operator.

That changes the evaluation from a GPU comparison into an ownership map:

1. Which party certifies the complete server and rack?
2. Who owns failures that cross GPU, NIC, switch, firmware, and collective-library boundaries?
3. Which model features depend on backend-specific kernels?
4. Can the operator reproduce benchmark results after changing containers or firmware?
5. Does supplier choice reduce cost enough to fund the added integration and qualification work?

The thesis is therefore narrower than “open beats closed.” AMD is building the closest merchant alternative because it now spans credible accelerators, large HBM domains, scale-up and scale-out networking, rack designs, and a usable software ecosystem. Its structure also places more responsibility at the interfaces between those layers.

The unresolved question is whether the UALink and UALoE ecosystem can make a multi-company rack behave like one supported product without converging on a single de facto integrator. If operators still need one company to certify every firmware, fabric, cooling, and software combination, how much of the architectural openness will survive contact with production?

Part of the AI Compute Landscape — an ongoing exploration of accelerator architectures, software stacks, and data-center systems.