AMD unveils Helion, an open rack blueprint that runs AI agents on EPYC CPUs

What did AMD announce on 12 October?

In a press release datelined Santa Clara, AMD introduced the Helion agentic AI rack, which it calls “an open blueprint for agentic AI infrastructure based on an Open Compute Project spec-design and powered by AMD compute”. AMD published a Helion product page at the same time, and the release went out on GlobeNewswire.

Helion is a reference design. AMD defines the rack, the node types and the software around them, and server makers build and sell the actual systems. The company says Helion configurations “are currently under development with ecosystem partners and are planned to be available in November 2026”, and that it plans to contribute the Helion specification to the Open Compute Project (OCP), the industry group that publishes open datacenter hardware designs.

The name is close to Helios, AMD’s existing rack-scale system for GPU training and large-scale inference, and the press release says Helion builds on Helios’s open-platform approach. The two are meant to sit side by side: Helios for the models, Helion for the agents that call them.

Why does AMD think agents need CPU racks?

AMD’s case is that agentic AI is not one workload. “It spans personal agents, enterprise applications, code execution and complex workflows, each with different compute requirements,” said Dan McNamara, AMD’s senior vice president and general manager for Compute and Enterprise AI.

An agent does more than generate tokens. Between model calls it runs shell commands, executes code in sandboxes, queries databases and moves files, and most of that runs on general-purpose CPUs. As our explainer on AI agents describes, each step of an agent loop mixes a model call with tool use, and the tool side scales with the number of agents running at once, not with model size.

AMD’s product page frames the trade-off by agent type. For high-volume personal agents, it says, the priority is the most agents per watt; for enterprise agents, the largest number of high-performing agents; and for technical agents, the highest performance per agent. Helion lets builders mix CPU blades to match that blend, rather than buying one server type for everything.

That is also a commercial argument. AMD sells EPYC server processors as well as Instinct GPUs, and a rack design that makes CPU core counts central to agent capacity favours its CPU business.

What is in the hyperscale and enterprise configurations?

AMD describes two starting configurations, both in a 21-inch ORv3 44OU rack that can be liquid- or air-cooled, with up to 102 Tbps of programmable networking and an open-source software stack, according to AMD’s materials as reported by StorageReview.

The hyperscale configuration is CPU-only. AMD says it supports up to 32,768 CPU cores of 6th Gen EPYC and is aimed at hyperscalers, neoclouds and sovereign AI operators that already run separate accelerator infrastructure. StorageReview, citing AMD’s briefing diagrams, reports three CPU node types: dense servers with 256-core Venice processors at 400 W for personal agents, balanced 256-core parts at 600 W for enterprise agents, and 96-core high-frequency parts for technical agents. At 256 cores per socket, 32,768 cores works out to 128 processors in one rack.

The enterprise configuration is all-in-one. It combines EPYC “sandbox” nodes where agents execute, Instinct MI350P GPU nodes for inference, and general-purpose EPYC nodes for databases, storage and technical computing. According to AMD’s FAQ, the GPUs come as eight MI350P cards in a 5U server, and a rack can take two such servers for 16 GPUs. The two servers operate independently, with no scale-up GPU fabric between them, because the configuration is meant for agentic workloads and inference rather than frontier-scale training. StorageReview puts the 16 GPUs at 74 petaflops of FP4 combined.

AMD lists the OCP standards it implements at each layer: ORv3 for the rack and busbar, DC-MHS for the host processor module, DC-SCM for management and security, HPRv2 for power shelves, OCP NIC 3.0 for networking and Caliptra for the silicon root of trust.

How does the token router fit in?

Both configurations include what AMD calls an integrated token router that “directs agents’ model calls across frontier and open-source models”. The product page puts it more concretely: route an agent’s inference requests either to frontier models running in the cloud or to open-source models running inside the same rack.

Routing like this is a cost and latency decision: easy steps go to a small local model and hard ones to a large hosted model. It is the same idea behind open projects such as the vLLM Semantic Router, and AMD already publishes an LLM Router blueprint in its Enterprise AI documentation that classifies prompts and sends them to different model backends through an OpenAI-compatible API.

AMD has not said whether Helion’s router is that blueprint, how it decides where to send a request, or which frontier providers it supports. Until the software ships, the router is a description, not a feature anyone can test.

Who is building Helion systems, and when?

The press release carries statements from Cisco, Dell Technologies, Hon Hai Technology Group (Foxconn), HPE, Lenovo, QCT, Supermicro and Wiwynn. Dell says it will support the Helion reference design in Dell PowerRack; Supermicro says it will bring Helion to market through its Data Center Building Block Solutions; HPE ties it to its recent agreement to deploy Helios for a customer. StorageReview reports that MiTAC, Inventec, ASUS, ASRock Rack and Gigabyte also appear on AMD’s partner list.

The timing in the release is “planned to be available in November 2026”. Neither AMD nor the partners named a first customer, a price or a shipping configuration.

What does Helion mean for buyers and rivals?

For buyers, the practical point is that agent capacity may be limited by CPU cores, memory and networking as much as by GPUs. The same day, Microsoft described its Maia 300 inference chip in terms of tokens per megawatt; AMD is making the matching argument for the work agents do between tokens. Both treat power, not chip supply alone, as the constraint.

For enterprises that do not want to run two racks, the all-in-one configuration is the more interesting option: sandboxes, a modest inference tier and supporting databases in one OCP rack. That sandbox tier is where controls like those in our agent sandboxing guide would run, so isolation and logging matter as much as core counts.

For rivals, Helion is a bet on open, mixed-vendor racks against vertically integrated systems. AMD positions it as complementary to Helios rather than a replacement, and says Helios remains the system for frontier-scale training with a unified scale-up GPU domain.

What has AMD not said yet?

AMD has not published per-rack power, node counts for the hyperscale version, agents-per-rack figures, prices, or any benchmark showing agents run better on Helion than on existing servers. Its claims about agents per watt are design goals, not measurements.

Some of the detail in this article, including the per-node Venice parts and the 74-petaflop figure, comes from StorageReview’s reading of AMD’s briefing slides rather than from the press release. We did not see those slides ourselves. The Helion specification itself is not yet public; AMD says it will be contributed to OCP.