AMD Pensando en Helios: la red deja de ser tubería y se vuelve parte de la fábrica de IA

En una PC gamer, muchas veces nos obsesionamos con la GPU, el CPU y la RAM, pero dejamos la red como si fuera un cable que “solo tiene que funcionar” o bien nos entregamos al wifi por comodidad... Pero obviar eso en una fábrica de IA, es un error y ese error sale carísimo. Cuando hablamos de racks con decenas de GPUs, modelos enormes, ventanas de contexto largas, inferencia distribuida, entrenamiento de modelos frontera y agentes que disparan múltiples llamadas a herramientas, la red deja de ser una autopista invisible y se convierte en una de las piezas que decide si todo el sistema corre, se ahoga o se queda esperando datos como tráiler atorado en caseta.

Por eso esta parte de AMD Advancing AI 2026 es importante. Después de hablar de Helios, MI455X y EPYC Venice, AMD dedicó espacio a la capa de networking basada en AMD Pensando, donde aparecen nombres como Salina DPU, Vulcano AI NIC, UALink over Ethernet, scale-up, scale-out y administración inteligente del tráfico. La idea de fondo es clara: si AMD quiere vender una fábrica completa de IA, no puede limitarse a decir “tenemos GPUs rápidas”; necesita demostrar que también puede mover datos, aislar tráfico, manejar congestión, mantener baja latencia y sostener operación continua a escala de rack.

La red dentro de AMD Helios

Capa	Componente / tecnología	Función principal
Front-end	AMD Pensando Salina DPU	Servicios de red, seguridad, almacenamiento y conectividad cliente-servidor
Scale-up	UALink over Ethernet	Conectar GPUs dentro del rack con alto ancho de banda y baja latencia
Scale-out	AMD Pensando Vulcano AI NIC	Conectar racks y clusters con Ethernet de alto rendimiento
Gestión	Fabric / Traffic Manager	Observabilidad, monitoreo, administración de estado y confiabilidad
Software	ROCm y stack AMD	Integración del cómputo con la capa de red y aceleración
Estándares	OCP, UALink, UEC	Reducir dependencia de arquitecturas cerradas y abrir ecosistema

AMD describe Helios como un diseño rack-scale que integra 72 GPUs AMD Instinct MI455X, CPUs EPYC Venice, networking AMD Pensando Vulcano y software ROCm en una plataforma abierta para entrenamiento e inferencia de IA a gran escala. La propia página de Helios también lista la Salina DPU como una pieza enfocada en conectividad front-end, con programación P4, operación line-rate, 16 núcleos Arm N1 y descarga de servicios de red, almacenamiento y seguridad.

La presentación separa la red de Helios en tres grandes zonas: front-end, scale-up y scale-out. El front-end es donde entran servicios, clientes, tenants, seguridad, cifrado y tráfico tradicional de nube. El scale-up es el dominio interno donde las GPUs necesitan comportarse como una unidad muy acoplada, con baja latencia y alto ancho de banda. El scale-out es la conexión entre racks, clusters y dominios más grandes. En otras palabras: no es una sola “red”, son varias redes con problemas distintos y requisitos distintos.

Ahí entra Salina, la DPU pensada para descargar trabajo que no debería estar consumiendo recursos valiosos del host. AMD posiciona sus DPUs Pensando como aceleradores de infraestructura para offload de red, seguridad y almacenamiento, y específicamente describe la Pensando Salina 400 DPU como una solución P4 programable, optimizada para baja latencia, jitter reducido y menor consumo. Para un entorno con múltiples tenants, tráfico sensible y cargas de IA cada vez más distribuidas, esta capa no es menor: si el CPU y la GPU están para cómputo, alguien tiene que encargarse de mover paquetes, aplicar políticas y no convertir cada conexión en una pequeña deuda técnica.

Salina DPU: el frente de la fábrica

Punto	Qué aporta	Lectura DD
Programabilidad P4	Permite definir comportamiento de red y servicios	Útil para hyperscalers con necesidades propias
16 núcleos Arm N1	Capacidad local para tareas de infraestructura	Descarga trabajo del host
Line-rate networking	Procesamiento de red a velocidad de línea	Evita que seguridad o servicios frenen el tráfico
Offload de red	Libera CPU para otras tareas	El host no debería cargar todo
Seguridad y aislamiento	Ayuda a separar tenants y políticas	Clave en nube e IA empresarial
Front-end connectivity	Conecta servicios externos con la infraestructura	La fábrica de IA también necesita atender clientes

El scale-up es la parte más espectacular porque ahí AMD habla de conectar hasta 72 GPUs dentro de Helios mediante UALink over Ethernet, con hasta 260 TB/s de ancho de banda agregado scale-up. Esto importa porque los modelos frontera y los flujos multiagente pueden depender de dominios de memoria enormes, comunicación constante entre aceleradores y coordinación muy fina. Si la red interna no aguanta, puedes tener GPUs carísimas trabajando como si estuvieran en una junta mal organizada: todas con potencia, ninguna con la información a tiempo.

El argumento de AMD es que una arquitectura abierta basada en Ethernet puede dar a hyperscalers, OEMs y socios más flexibilidad que un camino completamente cerrado. Helios se apoya en estándares como OCP Open Rack Wide, UALink y arquitecturas del Ultra Ethernet Consortium, con un enfoque que busca combinar scale-up y scale-out abiertos dentro de una plataforma rack-scale. En esa misma línea, AMD ha explicado que UALink puede usarse directamente entre GPUs y NICs, y también tunelarse sobre Ethernet para interconexión entre GPUs, lo que encaja con su narrativa de infraestructura abierta.

Aquí conviene poner los pies en la tierra: “abierto” no significa automáticamente “mejor”, ni “Ethernet” significa automáticamente “más barato y listo”. La magia no está en usar una palabra conocida, sino en que el sistema completo tenga baja latencia, buen control de congestión, visibilidad, confiabilidad y software capaz de administrar trabajos largos sin convertir cualquier falla menor en un reinicio carísimo. En IA a gran escala, un drop, un enlace problemático o una mala distribución de tráfico puede tener impacto real en entrenamientos que duran días o semanas.

La parte de Vulcano apunta justo a ese scale-out. AMD describe sus Pensando AI NICs como componentes para redes de IA a gran escala, con hardware y software programables, RDMA preparado para UEC, Ethernet de alto rendimiento, administración inteligente de tráfico, control avanzado de congestión y conectividad inter-rack de alto throughput. En materiales técnicos sobre transporte de red para entrenamiento de IA, AMD también menciona que la segunda generación Pensando “Vulcano” 800 AI NIC está en calificación para clusters AMD Instinct MI400, con soporte para forwarding basado en SRv6, control explícito de rutas, ingeniería de tráfico fina, ECMP y balanceo dinámico de carga.

Vulcano AI NIC: la escala hacia afuera

Punto	Qué significa
800 Gbps	Alto throughput para interconexión de IA
PCIe Gen 6	Mejor conectividad hacia sistemas modernos
OCP form factors	Enfoque en integración abierta para data center
UEC-ready RDMA	Preparación para redes Ethernet optimizadas para IA
SRv6	Control explícito de rutas e ingeniería de tráfico
ECMP / balanceo dinámico	Distribución de tráfico para evitar cuellos de botella
Congestion management	Menos desperdicio por saturación de red
Rápida detección y recuperación	Menor impacto de fallas durante trabajos largos

La lectura interesante es que AMD está usando Pensando para contar una historia más completa contra NVIDIA. NVIDIA no domina solo por tener GPUs potentes; domina porque vende un sistema completo donde cómputo, interconexión, software, librerías, networking y operación trabajan bajo una misma visión. AMD necesita responder con algo equivalente, pero con su propio ángulo: estándares abiertos, Ethernet, UALink, UEC, OCP, ROCm y una red programable capaz de adaptarse a distintas arquitecturas de cliente.

También se entiende mejor por qué AMD insiste tanto en la IA agéntica. Un chatbot simple puede parecer una llamada relativamente directa a un modelo. Un sistema agéntico puede activar varias rondas de inferencia, consultar herramientas, ejecutar código, mantener memoria, dividir tareas, coordinar subagentes y comunicarse con servicios empresariales. Cada una de esas acciones genera tráfico, estado, contexto y latencia. En ese mundo, una buena red no solo mueve datos; ayuda a decidir cuántos agentes puedes sostener, cuánto contexto puedes mantener activo y qué tan rápido se recupera el sistema cuando algo empieza a fallar.

La participación de socios también importa. HPE anunció una solución Helios con networking scale-up Ethernet en colaboración con Broadcom, basada en UALink over Ethernet, capaz de soportar tráfico de entrenamiento de modelos de trillones de parámetros, alta inferencia y modelos masivos. Esa solución integra 72 GPUs AMD Instinct MI455X por rack, 260 TB/s de ancho de banda scale-up agregado y hasta 2.9 AI exaFLOPS FP4 por rack. Esto refuerza que AMD no quiere que Helios sea solo una arquitectura bonita en escenario, sino un diseño que pueda convertirse en sistemas reales con OEMs y socios de infraestructura.

Por qué la red importa en IA agéntica

Problema	Por qué la red se vuelve crítica
Modelos grandes	Requieren mover pesos, activaciones, contexto y datos entre aceleradores
Inferencia distribuida	La latencia afecta directamente la experiencia del usuario
Agentes múltiples	Cada agente puede disparar herramientas, memoria, APIs y subprocesos
Trabajos largos	Una falla pequeña puede arruinar horas o días de cómputo
Multi-tenant cloud	Se necesita aislamiento, seguridad y políticas claras
Escala de rack	Las GPUs deben compartir datos como sistema, no como islas
Scale-out	Varios racks deben funcionar como una infraestructura coordinada
Costo por token	La red también impacta utilización de GPU y eficiencia económica

El punto menos sexy, pero probablemente más importante, es la operación. En el transcript aparece la idea de un fabric manager o traffic manager con observabilidad, monitoreo, detección de problemas y administración del ciclo de vida de la red. Esa parte no presume tantos titulares como “432 GB de HBM4 por GPU”, pero en un data center real puede ser igual de crítica. Si un operador no puede ver qué pasa en la red, anticipar congestión, aislar fallas o mantener trabajos vivos cuando una parte del sistema se degrada, entonces la fábrica de IA se vuelve una máquina muy cara para producir frustración.

La lectura DD es que AMD está tratando de resolver el problema correcto: en IA a escala, el cuello de botella no siempre es el FLOP. A veces es memoria. A veces es red. A veces es software. A veces es disponibilidad. A veces es la incapacidad de operar una infraestructura enorme sin que cada falla parezca incendio forestal. Pensando, Salina y Vulcano son importantes porque le permiten a AMD decir que Helios no es solo “GPU + CPU”, sino una plataforma donde también hay control de tráfico, aislamiento, descarga de servicios, conectividad scale-up y red scale-out pensada para IA.

Esta parte de Advancing AI 2026 es menos vistosa que enseñar una GPU gigante, pero puede ser igual o más importante para que Helios funcione en el mundo real. La red es la parte que decide si 72 GPUs pueden comportarse como una fábrica de IA o como 72 máquinas caras gritando entre sí. Salina se encarga del frente: servicios, seguridad, tenants y tráfico de nube. Vulcano mira hacia la escala: racks, clusters, congestión, rutas y alto throughput. Y UALink over Ethernet es el intento de AMD por empujar una alternativa abierta para interconectar aceleradores sin encerrarse en una sola ruta propietaria. Como siempre, la promesa se validará en producción: si la red sostiene cargas largas, reduce latencia y mantiene los aceleradores ocupados, AMD tendrá una historia mucho más fuerte. Si no, los exaFLOPS se quedan esperando paquetes.