AMD announced Helios at its Advancing AI 2026 event this week at the Moscone Center in San Francisco. The rack-scale system combines 72 Instinct MI455X accelerators with sixth-generation EPYC Venice CPUs and Pensando networking. Engineering samples are scheduled for the second half of 2026, with mass production starting in Q2 2027.
Lisa Su presented the system on Tuesday morning. Sam Altman also appeared on stage as AMD and OpenAI announced a 6-gigawatt supply agreement beginning in H2 2026. Oracle has committed to 50,000 MI450-series units in Q3 2026.
Those commitments give AMD's hardware plans more weight than specifications alone would carry. Helios also offers a different approach to connecting a rack of GPUs: open interconnect standards rather than Nvidia's proprietary NVLink. For operators considering infrastructure that may remain in service through 2032, that choice affects upgrade options, supplier dependence and operating costs.
The MI455X's memory advantage
The announced MI455X design uses AMD's CDNA 5 architecture and TSMC's N2 (2nm) process. It combines 12 compute chiplets with 3nm base dies, for a total of 320 billion transistors. Each accelerator carries 432GB of HBM4 memory, with 19.6 TB/s of memory bandwidth and approximately 40 petaflops of FP4 inference performance at a 900W TDP, its thermal design power rating.
FP4 is a low-precision number format used for some AI inference workloads. Its peak performance figure is useful for comparing hardware capabilities, but it doesn't establish how quickly a particular model will run.
The reported memory capacity for Nvidia's Vera Rubin GPU is 288GB. That gives the MI455X roughly 50% more HBM capacity per accelerator. Model weights alone can exceed 100GB in mid-sized deployments, so the additional memory could make a practical difference. More capacity can allow a model to stay in GPU memory rather than offloading data to slower memory, which can sharply reduce throughput.
The chiplet design brings a manufacturing tradeoff. Building 12 smaller compute tiles gives AMD more flexibility to manage manufacturing yield, the share of usable chips produced, than a single large compute die would. That can help control costs and reduce sensitivity to defects as a manufacturing process matures. It also creates a more complex package to connect and cool, especially at 900W per accelerator.
Inside the Helios rack
Helios contains 18 compute trays, each with four MI455X accelerators and one EPYC Venice CPU. The full rack therefore holds 72 GPUs, 18 CPUs and approximately 31 terabytes of HBM4. The reported design is described as having more high-bandwidth memory than any previous single-rack system.
The rack's claimed aggregate performance is 2.9 exaflops of FP4 inference and 1.4 exaflops of FP8. Reported pricing ranges from $5 million to $5.5 million per rack, with $5.25 million as the midpoint.
The networking design separates communication inside a rack from communication between racks:
- Scale-up: GPU-to-GPU communication within the rack is described as UALink over Ethernet, with 260 TB/s of bandwidth.
- Scale-out: Pensando networking connects racks, with 43 TB/s of bandwidth and support for the Ultra Ethernet Consortium specification.
- Physical design: The rack follows OCP Open Rack Wide.
These distinctions matter because a large AI workload needs more than fast individual GPUs. Accelerators must exchange data, and communication limits can leave compute capacity underused. The announced bandwidth figures describe that part of the design, though application-level results will still depend on the workload and software.
Open standards and supplier dependence
Nvidia's NVL72 uses NVLink for its scale-up interconnect. NVLink is proprietary, leaving Nvidia in control of its implementation and upgrade path. Buying into it at scale ties an operator's plans closely to Nvidia's hardware roadmap and pricing.
That dependence extends beyond the equipment purchase. Automation, monitoring, staff expertise and vendor relationships develop around the chosen stack. Replacing it later can be expensive even when competing hardware looks attractive. The incumbent supplier gains negotiating power from those switching costs.
AMD's open-standards approach could give operators more choice in networking suppliers and greater reuse of Ethernet tools, cabling practices and operational knowledge. Across a large deployment of racks costing about $5 million each, those choices can affect both purchasing and maintenance.
The extent of that flexibility depends on what the finished implementation supports. An open specification alone doesn't establish that existing commodity switches, monitoring tools or cables will meet the requirements of a particular scale-up fabric.
Nvidia also has a substantial practical advantage: NVLink is established at hyperscale, and CUDA has a mature software ecosystem. Open networking standards don't remove the work needed to move applications away from that stack. Operators have to weigh supplier flexibility against the cost and risk of migration.
ROCm still has work to do
ROCm 7.14, released alongside the event, adds support for PyTorch 2.12, JAX 0.10.0 and vLLM 0.23. Its new modular build system, TheRock, is intended to simplify packaging and deployment. The profiling infrastructure has also changed: rocprofiler-SDK now backs the PyTorch Profiler directly, replacing the legacy profiling stack.
These are useful improvements because deploying accelerators requires more than installing a driver. Framework compatibility, packaging and profiling tools affect how easily engineers can get a workload running and diagnose poor performance.
CUDA still has roughly two decades of optimization, a broad library ecosystem covering machine-learning operations and a large base of experienced engineers. ROCm's portability features don't make every CUDA application easy to migrate. Custom kernels, vendor-specific attention implementations and inference stacks tuned for H100s can require substantial engineering work.
The OpenAI agreement is relevant to that gap. OpenAI has operated CUDA-native workflows at hyperscale for years. A commitment of this size suggests confidence that AMD's software can meet its needs, or a willingness to fund the work needed to get there. Possible approaches include adapting existing workloads or developing new systems around CDNA 5.
The agreement doesn't reveal how much of that work is complete. It also doesn't establish that a smaller team, without OpenAI's engineering resources, would face the same migration costs. It does give AMD a major customer with a strong reason to help improve the stack.
What operators can evaluate before production
Helios isn't yet a production option for most infrastructure teams. As of July 23, 2026, engineering samples are expected in H2 2026 and mass production is scheduled for Q2 2027. A separate report says Helios is coming to Azure in H2 2026. That earlier cloud timeline should be treated separately from broad production availability.
Most analyst estimates still put Nvidia's share of AI training accelerators above 80%. AMD's announcements don't erase that lead. They do present a more substantial alternative for purchases that will support workloads through 2028 and beyond: a rack-scale design with more memory per GPU, open interconnect standards and large customer commitments.
Two practical steps follow for teams evaluating an expansion:
- Test real workloads on MI450 hardware where available. Testing before the MI455X ships can expose ROCm compatibility problems, custom-kernel requirements and deployment work. Oracle's commitment to put 50,000 MI450-series units into production in Q3 should also create a larger operating base. Reports from open-source projects and engineering forums over the following months may help identify recurring problems.
- Include AMD in renewal planning. Teams facing a Nvidia contract renewal within the next 12 months have another option to evaluate. Helios's reported $5 million to $5.5 million rack price provides a reference point, but negotiating strength will depend on whether the workloads can move and whether hardware will be available when needed.
The purchasing comparison needs to account for software migration, cooling requirements and delivery timing alongside rack price and memory capacity. Helios's specifications justify serious testing. Sustained performance on the intended models will determine whether the system is a workable alternative for a particular deployment.
