AMD Helios networking strategy leans on Meta co-design and Ethernet

AMD Helios networking was the center of the company’s infrastructure pitch at Advancing AI 2026, where Advanced Micro Devices Inc. argued that its Helios rack-scale AI platform depends on open, co-designed networking rather than proprietary fabric alone. The company did not disclose Helios pricing or customer deployment figures in the discussion, but it framed networking as a constraint that will determine whether large AI systems can run reliably at data-center scale.

Soni Jiandani, senior vice president and general manager at AMD, said monthly token consumption has increased 158 times over two years, a load profile that puts throughput, availability and programmability closer to the core of AI system design. Her comments came in an interview with Omar Baldonado, senior director of data center and AI networking at Meta Platforms Inc., during SiliconANGLE’s theCUBE coverage of AMD’s Advancing AI 2026 event.

The practical point for operators is that AMD is treating Helios less like a standalone rack product and more like a piece of a larger data-center architecture. As AI deployments move from individual servers and racks toward coordinated pools of accelerators, the network becomes part of the compute system rather than plumbing around it.

Why does AMD Helios need open networking?

AMD says Helios needs open networking because frontier-model training, inference and agentic workloads require GPUs, CPUs, storage and distributed processing to interoperate across many machines. Open co-design networking, in this context, means vendors and hyperscale customers define parts of the fabric together so components can be mixed, scaled and operated across a shared infrastructure model.

Jiandani said AMD and Meta worked together on the scale-up interconnect for Helios, using UAL over Ethernet as the fabric intended to bind GPUs into one larger resource pool. She also said Helios has 50% more memory than an unnamed competitor, which raises the availability challenge because failure domains can involve dozens of GPUs acting as a single system.

That claim is useful but incomplete. AMD did not identify the competing platform in the discussion, and it did not provide benchmark data in the interview segment. For buyers comparing AI infrastructure stacks, memory capacity is only one part of the decision alongside software maturity, utilization, network failure handling and supply commitments.

Meta’s role in the Helios fabric

Baldonado linked Meta’s involvement to its earlier work in the Open Compute Project’s networking effort. He said networking depends on openness because many technologies across the stack must connect and operate together. That position tracks with Meta’s broader preference for infrastructure components that can be specified, tested and evolved with suppliers rather than accepted as sealed systems.

The discussion also pointed to a shift in AI back-end networks. Fierce Network has reported that Ethernet has overtaken InfiniBand in AI back-end deployments, a notable backdrop for AMD’s decision to emphasize Ethernet-based scale-up fabric for Helios. Ethernet’s appeal in this market is not that it is new, but that hyperscalers already have deep operational experience with it and want more control over the stack.

Agentic AI adds another networking problem: context-heavy applications can generate large key-value cache demands that need to move across servers and storage. Jiandani said AMD is positioning its data processing units, or DPUs, to take on some of that work so GPUs and CPUs can be used for higher-value computation.

Both AMD and Meta presented the Helios networking effort as a co-design problem that no single vendor can solve on its own. TheCUBE disclosed that it was a paid media partner for the AMD event and said sponsors did not have editorial control over its coverage.

This story draws on original reporting from SiliconANGLE.