Vultr AMD Helios Order Gives HPE a $1.2B Opening Against Nvidia

Vultr placed a $1.2 billion order for HPE’s AMD Helios systems, giving the 72-GPU platform its first HPE customer. The Vultr AMD Helios order moves the architecture from a public roadmap into a commercial deployment at United States data centers.

This deal is not simply another purchase of AI accelerators. HPE will supply an integrated rack that combines AMD compute, open software, Ethernet-based scale-up networking, liquid cooling, and deployment services. The arrangement tests whether an alternative supplier group can compete with Nvidia at the complete-system level.

Nvidia remains the reference point because Vera Rubin NVL72 also connects 72 GPUs as one rack-scale computing domain. However, Nvidia controls more of its stack through proprietary technologies such as NVLink. AMD, HPE, Juniper, and Broadcom are presenting standards-based Ethernet as a more open path.

That distinction matters more than any isolated peak-performance claim. A rack-scale AI system must deliver consistent results across accelerators, memory, networking, cooling, orchestration, and software. Vultr is now committing substantial capital to prove that the open approach can work in a production cloud.

The Vultr AMD Helios Order Moves HPE Into Production

The order gives HPE its first commercial validation for a system that was previously defined mostly by specifications and partnership announcements.

HPE announced the agreement on September 30, 2026. According to its order announcement, Vultr will deploy AMD Helios AI Rack by HPE systems across its United States cloud data centers.

The company described the transaction as its first order for the integrated Helios platform. HPE also reported the development through a September 30 SEC filing, placing the announcement within its formal investor disclosures.

Each rack will contain 72 AMD Instinct MI455X GPUs. It also includes AMD EPYC processors, code-named Venice, and AMD Pensando Vulcano AI network interface cards.

ROCm, AMD’s open software platform for GPU computing, supplies the programming environment. HPE contributes rack engineering, direct liquid cooling, deployment services, and six Juniper QFX5252 scale-up switch trays per rack.

Scale-up networking links accelerators inside one computing domain. It must move data quickly enough for many GPUs to operate on a shared model without spending excessive time waiting for one another.

The HPE switches use UALink over Ethernet, commonly shortened to UALoE. This architecture carries UALink traffic through Ethernet-based networking rather than relying on a vertically controlled interconnect.

HPE says the six switch trays connect every GPU with high-bandwidth, low-latency links. That claim will require production evidence because networking performance changes with workload structure, communication patterns, and software configuration.

The companies did not disclose how many racks Vultr ordered. They also did not provide a complete delivery schedule or separate the order’s compute, networking, cooling, software, and service components.

Those omissions limit simple calculations about cost per GPU or rack. They also prevent outside observers from estimating how much of the contract represents hardware versus long-term operational support.

Still, the deal establishes a real customer and a meaningful deployment target. That is the essential change. HPE no longer needs to argue that Helios will eventually attract a buyer.

Vultr already operates cloud infrastructure for enterprise and AI workloads. It can expose the system to customers that care about model training, fine-tuning, and high-volume inference without owning a specialized data center.

HPE also gains a customer that understands AMD accelerators. Vultr previously adopted AMD Instinct systems, reducing the organizational friction involved in adding another AMD generation.

The order therefore carries more weight than a laboratory benchmark or reference design. It places Helios inside a commercial cloud where utilization, uptime, and customer demand will determine whether the platform succeeds.

Why HPE Needs More Than a GPU Sale

HPE is using the AMD Helios AI rack to compete for the infrastructure surrounding the accelerator, not merely the server chassis.

The AI infrastructure market increasingly rewards suppliers that deliver a functioning rack rather than a collection of components. Dense accelerator clusters require coordinated power, cooling, networking, firmware, software, monitoring, and maintenance.

A customer can purchase high-performance chips and still encounter poor cluster utilization. Delays often emerge from network congestion, unstable software, thermal limits, or failures that take too long to diagnose.

HPE’s role is to package those elements into a system that Vultr can deploy repeatedly. This gives the company an opportunity to capture spending that would otherwise flow to separate server, switch, cooling, and integration vendors.

The networking component is especially important. HPE completed its acquisition of Juniper Networks in 2025, adding switching technology and engineering talent to its infrastructure portfolio.

Helios provides an early test of the combined strategy. Six Juniper switch trays sit inside each HPE system, making networking part of the rack’s core design.

Reporting from HPE’s investor event described the deal as an example of standards-based Ethernet entering the scale-up layer. The same networking analysis noted that HPE did not disclose the networking share of the contract.

HPE told investors that it sees more than $1 billion in Helios-related networking opportunity during the next two years. It also said networking tray orders had already exceeded $200 million.

Those figures are company forecasts, not evidence of completed customer deployments. Even so, they clarify why HPE treats Helios as more than an additional server product.

The company wants its networking equipment to handle accelerator-to-accelerator traffic inside the rack. That is a demanding workload because distributed AI jobs exchange large tensors across many devices.

Latency or congestion at this layer can leave expensive accelerators idle. A weak fabric can erase advantages promised by faster GPUs or larger memory pools.

The Vultr deployment will therefore test HPE’s integration capabilities as much as AMD’s silicon. HPE must demonstrate that its switches, cooling system, services, and rack design function as one dependable product.

It must also make that system manageable across multiple cloud facilities. Repeating a configuration at scale requires consistent installation, telemetry, failure handling, and spare-parts procedures.

Direct liquid cooling adds another operational requirement. The technology transfers heat through coolant near high-power components, enabling densities that conventional air cooling struggles to support.

However, liquid cooling also affects facility design and maintenance. Operators need compatible plumbing, heat rejection, leak management, trained technicians, and procedures for replacing components.

HPE says its services organization will reduce those deployment and operating risks. Vultr’s actual rollout will show whether that promise survives contact with different facilities and production schedules.

For HPE, success would validate the logic behind combining compute and Juniper networking. Failure would suggest that acquiring network assets does not automatically create a competitive rack-scale AI platform.

Open Ethernet Is the Real Bet Against Nvidia

The primary contest is an open, multi-vendor Ethernet stack against Nvidia’s tightly integrated rack-scale architecture.

Nvidia built its AI infrastructure position through more than accelerator performance. CUDA software, NVLink interconnects, networking products, reference designs, and developer familiarity reinforce one another.

Vera Rubin NVL72 extends that model to a 72-GPU rack. Nvidia’s published NVL72 specifications combine 72 Rubin GPUs with 36 Vera CPUs and sixth-generation NVLink.

AMD Helios targets the same rack-scale category with a different supplier structure. AMD provides accelerators, host processors, network interface technology, and ROCm. HPE supplies integration, services, cooling, and Juniper switching.

Broadcom contributes switch technology used in HPE’s scale-up design. Open Compute Project rack specifications, UALink, and Ethernet standards create interfaces that additional vendors can adopt.

The resulting argument is not that Helios lacks integration. It is that integration does not require one vendor to control every critical layer.

AMD’s published Helios specifications list 72 MI455X GPUs, 31 terabytes of HBM4 memory, and 260 terabytes per second of aggregate scale-up bandwidth. HBM4 is high-bandwidth memory positioned close to the GPU for rapid model-data access.

AMD also lists 2.9 exaflops of peak FP4 compute and 1.4 exaflops at FP8. FP4 and FP8 are low-precision number formats designed to increase AI throughput while using less memory and energy.

Peak figures do not translate directly into application performance. Different vendors may use distinct data formats, sparsity assumptions, software settings, and workload conditions.

That makes MI455X versus Vera Rubin comparisons less straightforward than matching two numbers. Buyers need results from actual models, batch sizes, context lengths, networking patterns, and service-level requirements.

Memory capacity gives AMD a clear marketing angle. Helios is designed with 31 terabytes of rack-level HBM4, supporting large models and long-context inference without dividing data as aggressively.

Nvidia counters with its software maturity and integrated networking. Its CUDA ecosystem remains deeply embedded in AI frameworks, optimized libraries, deployment systems, and engineering practices.

ROCm has improved substantially, but adoption involves more than compiling a model. Production teams need stable kernels, monitoring, orchestration, security controls, and predictable performance across frequent framework updates.

This is where Vultr becomes strategically useful. A cloud provider can absorb some integration complexity and present customers with managed infrastructure rather than raw components.

Customers may care less about the underlying fabric if Vultr delivers dependable instances or reserved clusters. That approach can make AMD hardware accessible to teams that lack specialists in ROCm and distributed systems.

However, cloud availability alone will not neutralize software differences. Customers will still compare model compatibility, developer effort, performance per dollar, and time required to reach stable production.

The Vultr AMD Helios order gives the open approach a serious venue for that evaluation. It does not establish a winner before systems are deployed and measured.

The Specifications Do Not Settle MI455X Versus Vera Rubin

Both vendors publish impressive peak numbers, but cloud buyers ultimately pay for completed workloads, usable capacity, and predictable operations.

AMD says Helios supports trillion-parameter training and high-volume inference. Its design emphasizes memory capacity, open standards, and Ethernet-based connectivity within and between racks.

Nvidia positions Vera Rubin around agentic inference, training efficiency, and token throughput. The company says its platform combines CPUs, GPUs, DPUs, network interfaces, and switching as one co-designed system.

These claims use vendor-selected workloads and methodologies. They are useful for understanding product priorities, but they do not replace independent benchmarking.

An independent technical review described MI455X as AMD’s most credible rack-scale response to Nvidia. It also emphasized the importance of Helios joining 72 GPUs into one coherent domain.

The comparison still includes major unknowns. One is achieved utilization, which measures how consistently applications use the system’s theoretical computing capacity.

Another is collective communication performance. Training jobs frequently exchange partial results among GPUs, and slow synchronization can reduce output across an entire cluster.

Inference creates different pressures. Long contexts, large mixture-of-experts models, and many simultaneous requests stress memory capacity, memory bandwidth, routing, and scheduling.

A third unknown is software conversion effort. Models developed on Nvidia systems may depend on CUDA-specific libraries, kernels, or operational tools.

ROCm supports major frameworks, including PyTorch, TensorFlow, and JAX. Compatibility at the framework level does not guarantee identical behavior for every optimized production pipeline.

Developers may need to modify kernels, tune communication settings, or replace dependencies. Those costs can outweigh hardware savings when a team faces a tight deployment deadline.

Vultr can reduce the burden by publishing validated configurations, optimized containers, model recipes, and measured performance. It can also provide technical support based on operating the racks directly.

The cloud provider has an incentive to do that work. Expanding the viable accelerator supply can reduce dependence on one vendor and give customers additional capacity choices.

Yet capacity must arrive on schedule. HPE and Vultr did not disclose a detailed deployment calendar, while AMD has described Helios shipments as ramping through late 2026 and 2027.

A large order can span purchase commitments, delivery windows, services, and future capacity. The headline value does not prove that all hardware is already installed or available to customers.

Manufacturing and deployment risks remain significant. MI455X accelerators require advanced packaging and HBM4. Helios racks also depend on new CPUs, networking components, switch trays, cooling equipment, and facility preparation.

A delay in any critical component can slow the complete system. Rack-scale products concentrate dependencies because the buyer needs the integrated configuration, not a substitute part.

Power availability presents another constraint. High-density AI racks require substantial electrical and cooling infrastructure, which cannot always be added quickly to an existing data center.

The real MI455X versus Vera Rubin result will therefore emerge from deployments, not launch slides. Useful comparisons must report uptime, power use, model throughput, latency, and total operating cost under equivalent conditions.

Vultr Is Buying Leverage as Well as Capacity

Vultr’s commitment gives it another accelerator platform while strengthening its position between chip vendors and enterprise AI customers.

Cloud providers face a difficult balance. They must secure scarce hardware early, but they also risk tying capital to systems before customer demand becomes predictable.

Vultr’s order indicates confidence that customers will use AMD capacity for training and inference. The company says demand for high-performance AI infrastructure continues to exceed available supply.

That statement reflects Vultr’s commercial view and has not been independently validated through disclosed utilization data. The company does not publish enough detail to measure future Helios demand by customer or workload.

Still, the strategic logic is clear. Supporting Nvidia and AMD allows Vultr to offer more choices than a cloud built around one accelerator family.

That flexibility can appeal to enterprises concerned about hardware availability, supplier concentration, or software portability. It can also attract teams whose workloads benefit from larger memory pools.

Vultr gains negotiating leverage when multiple accelerator platforms can serve customer needs. The company becomes less exposed to the production schedule and commercial terms of any single supplier.

AMD gains a visible cloud channel for MI455X. HPE gains its first integrated Helios customer. Juniper equipment gains a place inside an accelerator-scale network.

The arrangement also gives Vultr a differentiated product. Larger hyperscalers offer broad portfolios, but independent AI clouds can compete through early hardware access, focused support, and geographic options.

That opportunity comes with concentration risk. The order is large relative to many private cloud infrastructure transactions, and Vultr must turn installed hardware into sustained customer usage.

Reserved-capacity commitments would strengthen the case. So would public examples showing customers moving substantial models from Nvidia systems to Helios without extended redevelopment.

Low utilization would create the opposite outcome. Expensive racks consume capital even when customer jobs do not keep them occupied.

Vultr must also manage customer expectations around performance portability. A model that runs correctly on both platforms may still produce different throughput, latency, and cost characteristics.

The cloud provider can help by presenting workload-specific evidence. Generic accelerator comparisons are less useful than measurements for model training, long-context inference, fine-tuning, and agentic workloads.

Customers should also watch service availability. A few specialized clusters in selected facilities would carry less competitive weight than standardized Helios capacity across Vultr’s cloud.

Geographic deployment matters because enterprise buyers consider latency, data residency, disaster recovery, and proximity to stored datasets. HPE only said the systems would enter United States locations.

The announcement also leaves contract structure unclear. Neither company disclosed delivery milestones, cancellation provisions, minimum purchases, or the portion linked to services.

Those details affect how much risk each party carries. A firm hardware purchase differs from a multi-year framework that depends on future capacity requirements.

The Vultr AMD Helios order is therefore a strong demand signal, but it is not the same as completed deployment. The distinction should remain visible until customers can access the systems at scale.

Three Signals Will Show Whether Helios Can Break Through

Delivery timing, production workload results, and broader customer adoption will determine whether this order changes the competitive market.

The first signal is physical deployment. HPE and Vultr need to identify when Helios capacity becomes operational and where customers can access it.

A confirmed production rollout would strengthen the claim that AMD and HPE can manufacture, integrate, and install a new rack-scale platform on schedule. Repeated delays would weaken it.

Availability should include more than a press release. Vultr should publish service regions, reservation options, configuration details, and expected capacity for qualified customers.

The second signal is workload evidence. Independent or customer-verified benchmarks should compare Helios with relevant Nvidia systems under matched conditions.

Useful results would include tokens per second, training completion time, power consumption, model size, context length, batch size, and software versions. They should also report tuning effort.

This evidence needs to cover both training and inference. A platform can perform well in one category while struggling with communication, latency, or software support in another.

Operational data matters too. Customers need information about uptime, recovery from component failures, cluster scheduling, and the performance impact of maintenance.

Strong results would support AMD’s position that open standards can deliver competitive rack-scale performance. Weak or narrowly selected results would preserve Nvidia’s integration advantage.

The third signal is follow-on adoption. HPE needs additional Helios customers, while AMD needs deployments that extend beyond previously committed partners.

Orders from other cloud providers, enterprises, research organizations, or national computing programs would show that the architecture appeals to multiple buyer types.

Repeat purchases from Vultr would be even more revealing. A second expansion after production use would suggest that customer demand and operating economics met expectations.

Nvidia’s response also deserves attention. The company can defend its position through faster Rubin deployments, improved software, aggressive cloud partnerships, and stronger Ethernet offerings.

HPE and AMD do not need to displace Nvidia across the market to validate Helios. They need to establish a dependable alternative for workloads where openness, memory, availability, or supplier diversity carries enough value.

For developers and enterprise buyers, the immediate action is to avoid treating peak specifications as purchasing conclusions. Ask providers for measurements that match the intended model and operating environment.

Request details about software migration, validated frameworks, cluster availability, service commitments, and failure recovery. Compare the engineering effort required to reach production, not only accelerator throughput.

The Vultr AMD Helios order has created a credible commercial test. Now the industry needs deployment evidence that separates an ambitious architecture from a dependable cloud platform.