AMD publica Helion: un rack de 32 768 núcleos de CPU para agentes de IA

AMD ha publicado Helion, un diseño abierto de rack para ejecutar agentes de IA, no para entrenar modelos. En la versión sin aceleradores, solo con procesadores, caben hasta 32 768 núcleos en un único rack. Los primeros sistemas de socios deberían llegar en noviembre. AMD vende Helion por su eficiencia: cuántos agentes caben en cada vatio.

Un rack para otra carga de trabajo

Durante los últimos tres años, la industria de los centros de datos se ha construido en torno al entrenamiento: racks densos de GPU, refrigeración líquida y redes rápidas entre aceleradores. Los sistemas de agentes funcionan de otra manera. Un agente rara vez ocupa la GPU de forma continua. Llama a herramientas, consulta API, ejecuta código en un entorno aislado (sandbox), mantiene el contexto, espera respuestas y coordina a otros agentes. Son muchos procesos paralelos y relativamente ligeros, y buena parte de ellos depende del procesador, no del acelerador.

Según el anuncio, Helion se apoya en esta observación. AMD propone un diseño de rack estándar que los socios podrán reproducir. El formato es abierto: las especificaciones están al alcance de cualquiera que ensamble servidores.

Lo que se sabe hasta ahora

• Nombre y formato: Helion, un blueprint abierto de rack.
• Finalidad: ejecutar y escalar agentes, no entrenar modelos.
• Configuración solo con CPU: hasta 32 768 núcleos en un único rack.
• Plazos: los sistemas de socios se esperan en noviembre de 2026.
• Métrica clave: número de agentes por vatio.
• No se revela en el anuncio: el modelo exacto de procesadores, el consumo del rack, la red, la refrigeración ni el precio.

El último punto es importante. Por ahora tenemos una declaración de intenciones y una cifra general, pero no una ficha técnica del producto.

La aritmética y la métrica

El número 32 768 equivale a 2 elevado a la 15.ª potencia y parece una configuración redonda y cómoda. Para hacerse una idea de la escala: con 256 núcleos por socket saldrían 128 procesadores por rack. Es un cálculo nuestro a modo ilustrativo, no un dato de AMD. La distribución real puede ser distinta.

La métrica de «agente por vatio» plantea más dudas. El entrenamiento tiene unidades consolidadas: FLOPS, tokens por segundo, tiempo hasta la convergencia. Para los agentes no existe ningún estándar. ¿Qué cuenta como un agente: un ciclo sencillo con un par de llamadas a API o un proceso complejo con navegador y ejecución de código? ¿Qué carga de trabajo, qué latencias, qué proporción de tiempo en reposo? Sin respuestas a estas preguntas, la cifra de AMD solo será comparable consigo misma. Las mediciones independientes no serán posibles hasta que el hardware llegue a los clientes.

El reparto de fuerzas en el mercado

Helion muestra que los fabricantes de chips buscan una segunda fuente de demanda además de los costosos aceleradores. Si la carga de los agentes se traslada realmente a las CPU, saldrán ganando quienes tengan procesadores de servidor potentes y un ecosistema de socios de ensamblaje. Un diseño abierto reduce la barrera de entrada para los integradores y genera menos temor a la dependencia de un único proveedor que una plataforma cerrada. Pero los competidores también ofrecen CPU de servidor, incluidas soluciones Arm, y cada uno tratará de demostrar su eficiencia con sus propias pruebas.

Qué deberían hacer los equipos que construyen agentes

Antes de esperar a noviembre, conviene medir la carga propia. ¿Cuánto tiempo pasa realmente el agente en la GPU y cuánto esperando herramientas y en la CPU? Si la segunda proporción es grande, pagar por aceleradores para la orquestación no compensa, y un rack de CPU puede resultar más barato por tarea completada. Calculen el coste por tarea, no el coste del servidor.

Cuando los socios anuncien configuraciones, pídanles el consumo con su carga de trabajo, no el de la ficha técnica. Revisen además las licencias y el coste por núcleo del software: con decenas de miles de núcleos por rack, pueden anular la ventaja energética. Por ahora Helion sigue siendo una declaración de intenciones, pero la dirección está clara: la infraestructura para agentes empieza a separarse de la infraestructura para entrenamiento.