On October 12, 2026, AMD announced Helion, a rack design for AI agents. The CPU-only configuration, built on 6th-generation EPYC, supports up to 32,768 cores, and for enterprises AMD offers a configuration that places CPUs and Instinct MI350P GPUs in the same rack. AMD already offers "Helios" for large-scale model training and inference, and with Helion it extends rack-level design to the side that supports code execution and business processing by agents. Helion proposes placing the work of running agents and the work of having models generate answers according to each customer's facilities and use cases.
CPUs run the agents, GPUs run the models
Helion's CPU-only rack is designed to connect to a separate model-inference infrastructure. AMD's announcement explains that the CPU side handles agent execution and provides the connection to the inference side. A large operator that already runs inference equipment such as GPUs can keep using it and add CPU capacity for running agents. Even in a configuration with no GPUs in the rack, the step of calling a model remains.
After a model generates code or a next action, there is still the work of actually running the program, receiving the result and moving on to the next step. In its July 23 technical explanation of EPYC 9006, AMD cited isolated execution of agent-generated code and tasks, and the retention of state and memory, as CPU roles. It also separates the hosts that feed data to GPUs from the business services that agents use. Helion can be read as turning the workload-specific CPU choices shown there into a way of assembling a rack.
For example, even if a coding agent generates a fix, the job is not finished if compilation or testing gets stuck. A fast model response and an agent finishing its work quickly are different metrics. How much CPU-side execution capacity to provide, and how to combine it with inference equipment, becomes an operational choice.
Competitors are targeting the same stage. In its May 31 Vera announcement, NVIDIA cited Python execution environments and code execution in isolated environments as use cases, and showed CPU-only servers and high-density racks. Competition is advancing not only over the volume of tokens GPUs generate but also over how to speed up the CPU processing before and after. Seen in this context, Helion's position becomes clearer.
256-core density versus 96-core speed
With Helion, agent CPU blades can be mixed according to use. The EPYC 9006 options shown in AMD's product materials are a high-density 256-core, 400W part; a balanced 256-core, 600W part; and a high-performance 96-core, 5.0GHz part. The 400W and 600W figures here are CPU values, not the power consumption of the whole rack.
| CPU blade option | Published CPU specs | Agent use AMD matches it to |
|---|---|---|
| High density | 256 cores, 400W | Running many personal agents per unit of power |
| Balanced | 256 cores, 600W | Supporting enterprise agent processing |
| High performance | 96 cores, 5.0GHz | Technical-computing agents that need fast responses |
This table lines up AMD's configuration examples by use; it is not a measured speed comparison. Core density tends to matter when many jobs run at once, while per-core performance matters when you want to shorten the CPU processing of a single job. The ability to mix both in the same rack is a design choice that the maximum core count alone does not reveal.
However, core and thread counts cannot be read directly as the number of agents usable in practice. The "agents per CPU power" comparison AMD presented in July is, according to the footnotes of its technical explanation, an estimate based on published core counts and CPU power. It differs from a value measuring how many times real agents complete business tasks. If the code being processed, the memory required or the wait for model responses changes, the results from the same CPU configuration will change too.
Even with 16 GPUs, the connectivity is not the same as Helios
The GPU inference blade in enterprise Helion is a configuration with eight Instinct MI350P GPUs in a 5U server. According to AMD's FAQ, a rack can hold up to two of these servers, for a total of 16 GPUs. However, the two nodes operate independently, and there is no interconnect between nodes that unifies the GPUs. The constraint is stated for the link between the two nodes, not for GPU connectivity within a node.
Helion's CPU-only configuration connects to a separate inference infrastructure, while the enterprise configuration carries up to two independent 8-GPU nodes.
| Rack design | Placement of agent execution and inference | GPU connectivity and main use |
|---|---|---|
| Helion CPU-only | Agents run on CPUs in the rack; model inference connects to a separate infrastructure | For large operators that already have inference equipment |
| Helion enterprise | CPU execution, inference on MI350P and general-purpose business compute in the same rack | Up to 8 GPUs × 2 nodes. The nodes are independent, with no interconnect unifying GPUs across nodes |
| Helios | MI455X, EPYC and networking integrated across the whole rack | For large-scale inference with 72 GPUs and training of frontier models, with an interconnect that unifies the GPUs |
This compares AMD's published designs as of October 13, 2026 by inference placement and GPU connectivity role. It is based on Helion's configuration and FAQ and the July 23 Helios announcement, and it does not rank performance or price. Nor does the table show that Helion's maximum CPU core count and maximum GPU count are achieved in the same configuration.
Helios is a design for coordinating multiple GPUs to handle large models. Enterprise Helion, by contrast, fits CPU execution of agents and GPU inference into a single rack. Even as the number of GPUs grows, adding independent nodes is not the same as expanding a single GPU compute domain. Buyers need to check, against the model size and concurrency they require, which configurations can be handled node by node.
AMD also touts a maximum network bandwidth of 102Tbps, but the product materials do not state how it is aggregated or under what latency conditions. A bandwidth figure alone cannot be used to judge GPU connectivity between nodes or agent response times.
Model routing and the OCP standards change the conditions for adoption
Enterprise Helion routes inference requests between open-source models running in the rack and cutting-edge large models in the cloud. AMD builds a "token router" that handles this routing into Helion. The design does not fix the place where agents run on CPUs and the place of the models they call to the same rack.
With this configuration, an organization can run inference GPUs in-house while also using external models. However, neither the announcement nor the product materials show the rules for selecting models, the individual supported models, or measured performance and cost results from routing. The CPU/GPU ratio an enterprise should choose is decided together with which jobs go to in-house models and which go outside. It is hard to estimate the required amount from the maximum hardware configuration alone.
On the hardware side, it adopts a 21-inch ORv3 rack and offers a choice of direct liquid cooling or air cooling. The OCP-related specifications AMD cites go beyond rack form to power-delivery busbars, host modules, and management and security. They serve as a common design foundation for partners combining compute nodes and management systems.
Still, using common specifications and fitting into existing facilities as-is are separate things to check. The OCP Rack & Power project also covers power conversion and control between facilities and IT equipment, in addition to rack standards. Even where air cooling is an option, you need to confirm whether the configuration fits the facility, including incoming power capacity and how power is delivered to the rack.
AMD also indicated plans to contribute Helion's specifications to OCP. As of the announcement this is a plan, and it cannot be treated as a specification already contributed. Which standards are currently adopted and the future provision of Helion's overall specifications to the community should be considered separately.
In November, watch completed work, not core counts
Helion's rack configurations are under development with partners, and AMD plans to make them available in November 2026. Dell Technologies, HPE and Lenovo expressed support in the announcement, and on the manufacturing and integration side Foxconn, QCT, Supermicro and others are also involved. This is not a promise that every configuration will ship from every company on the same day; product-specific specifications and availability terms await each partner's detailing.
The announcement and product materials do not show the rack price, the power consumption of the whole rack, or measured values for how quickly agents complete work. When products appear, it would be worth comparing the number of successfully completed jobs and the response times, using the same models, the same tasks and the same completion criteria. If measuring efficiency per unit of power, the whole rack should be the target, not just the CPU, and for configurations that use external models, the usage fees should be added. Such an evaluation would confirm how much the gain in CPU density actually helps real work.
The value enterprises seek in Helion is the ability to place CPU execution environments and model inference to match their own workloads. If partner products validate that combination in real business operations and show facility requirements and total cost, enterprises will be able to identify the stages where agent processing stalls and add the compute resources they need.