AMD celebró su mayor evento de IA avanzada hasta la fecha, haciendo hincapié en la escalabilidad como tema central. La compañía presentó la GPU Instinct MI455X, el rack Helios de 72 GPU y las CPU EPYC Venice de sexta generación. La MI455X cuenta con 432 GB de HBM4, un aumento del 50 % con respecto a las B300 o Rubin de NVIDIA, con un ancho de banda de memoria de 23.3 TB/s y hasta 40.26 PFLOPS de cómputo MXFP4. Un rack Helios completo multiplica estas cifras por 72, alcanzando 2.9 exaFLOPS de FP4, 31 TB de HBM4, un ancho de banda de memoria de 1.7 PB/s, una escalabilidad ascendente de 260 TB/s y una escalabilidad horizontal de 43 TB/s para el centro de datos. En todos los aspectos, AMD aspira a liderar la industria. Este artículo analiza la MI455X y Helios; el lanzamiento de Venice se aborda en un análisis aparte.

El otro tema central es la apertura, presente en cada capa, comenzando por la interconexión. Dentro del rack, las 72 GPU comparten memoria a través de UALink, una arquitectura de consorcio abierto que AMD ejecuta en Ethernet como UALink-over-Ethernet (UALoE). Una vez que el tráfico sale del rack, se transmite a través de Ultra Ethernet, el estándar abierto de escalabilidad horizontal del Consorcio Ultra Ethernet. El mismo principio Instinct se aplica en toda la pila. Las operaciones matemáticas de baja precisión utilizan los formatos de datos abiertos MXFP4, MXFP6 y MXFP8 de OCP, y el rack que lo alberga todo está construido según el diseño Open Rack Wide del Open Compute Project. Incluso el software se desarrolla de forma abierta, con el compilador, el entorno de ejecución y las bibliotecas de ROCm disponibles en código fuente.

Dado que todas las especificaciones de la pila están publicadas y disponibles para su descarga, un proveedor de servicios en la nube a gran escala puede usar Helios como plantilla y crear una versión personalizada adaptada a sus propias instalaciones y cargas de trabajo, modificando la red, el suministro de energía o la gestión según sea necesario. Esto significa que todo lo que se describe en este artículo corresponde al diseño de referencia presentado por AMD; las unidades que implementan los clientes pueden diferir significativamente. Ya hay clientes interesados: AMD afirma que OpenAI, Meta, Anthropic, Microsoft , Oracle y otros están adoptando Helios.

AMD Instinct MI455X: el procesador insignia con arquitectura CDNA 5.

El MI455X es el primer acelerador CDNA 5, compuesto por 320 mil millones de transistores. Incorpora ocho chips aceleradores complejos (XCD) fabricados en el nodo N2 de TSMC, dos chips de E/S y dos chips de interconexión y caché en el nodo N3, además de doce pilas HBM4. Es el chip más grande jamás fabricado con el encapsulado CoWoS-L de TSMC.

La memoria es uno de los aspectos más destacados. Esos doce módulos HBM4 suman un total de 432 GB a 23.3 TB/s, con HBM4 duplicando la interfaz por módulo a 2,048 bits, y los dos chips Fabric y Cache añaden una caché L2 de 192 MB que funciona a 54 TB/s.

El MI455X tampoco escatima en E/S. Ofrece 72 líneas UALoE para un ancho de banda bidireccional de escalado ascendente de 3.6 TB/s al resto del rack, 256 GB/s de Infinity Fabric bidireccional a su CPU principal y la opción de dos enlaces PCIe Gen6 x16 o tres AMD AI-NIC para escalado horizontal.

En comparación con el chip al que reemplaza y las ofertas de NVIDIA, el MI455X lidera en todos los aspectos.

Especificación	AMD MI455X	NVIDIA Rubin	AMD MI355X	Nvidia B300
Arquitectura de interiores	ADNC 5	Rubin	ADNC 4	Blackwell Ultra
Transistores	320B	336B	185B	208B
Capacidad de HBM	432GB HBM4	288GB HBM4	HBM3E de 288 GB	HBM3E de 288 GB
Ancho de banda HBM	23.3 TB / s	22 TB / s	8 TB / s	8 TB / s
Escalabilidad por GPU	3.6 TB / s	3.6 TB / s	1.08 TB / s	1.8 TB / s
Escalabilidad horizontal por GPU	2,400 Gb / s	1,600 Gb / s	400 Gb / s	800 Gb / s
Enlace CPU-GPU	Infinity Fabric de 256 GB/s	1.8 TB/s C2C (1:2)	PCIe 5	900 GB/s C2C (1:2)

 

Empecemos por donde AMD lidera. Con 432 GB, la MI455X cuenta con un 50 % más de HBM que la MI355X, la B300 o la Rubin, que alcanzan un máximo de 288 GB. Su ancho de banda de memoria de 23.3 TB/s también es el más alto del grupo. La escalabilidad horizontal se inclina en la misma dirección: 2,400 Gbit/s por GPU frente a 1,600 para la Rubin y 800 para la B300. Cada MI455X sale del rack con un 50 % más de ancho de banda de red que su competidor más cercano.

AMD finalmente también se ha puesto al día en escalabilidad. NVLink ha sido la principal arquitectura de interconexión de GPU durante años y, durante dos generaciones, fue la única forma de obtener el máximo rendimiento en los modelos MoE con WideEP. UALoE cierra esa brecha en una sola generación: con 3.6 TB/s, el MI455X iguala a NVLink 6 de Rubin. NVIDIA aún mantiene una clara ventaja en el enlace de host. Una CPU Vera alimenta dos GPU Rubin a través de 1.8 TB/s de C2C, mientras que cada MI455X se comunica con su host Venice a través de un enlace Infinity Fabric de 256 GB/s. Esa diferencia determina cómo divergen las dos arquitecturas de rack más adelante en este artículo.

En cuanto a rendimiento bruto, el MI455X lidera en todos los aspectos, con una salvedad: los formatos OCP MX de AMD y NVFP4 de NVIDIA escalan de forma diferente, por lo que conviene considerarlos como picos anunciados; el rendimiento real es otra cuestión.

Formato	AMD MI455X	NVIDIA Rubin	AMD MI355X	Nvidia B300
MXFP4 / NVFP4	40.26 FP	35 FP	10.1 FP	15 FP
MXFP6 / FP6	20.13 FP	17.5 FP	10.1 FP	5 FP
MXFP8 / FP8	20.13 FP	17.5 FP	5 FP	5 FP
FP16 / BF16	5.03 FP	4 FP	2.5 FP	2.5 FP
FP32	315 TF	130 TF	157.3 TF	75 TF

 

En relación con el MI355X, el MI455X ofrece cuatro veces el rendimiento de MXFP4 y MXFP8 y el doble de las tasas de FP16/BF16 y FP32. La comparación con NVIDIA se divide en dos partes. Frente al B300, el MI455X ofrece 2.7 veces el rendimiento de FP4 y cuatro veces las tasas de FP6 y FP8. Rubin es el benchmark significativo, y frente a él el MI455X mantiene una ventaja constante: 15% en FP4, 15% en FP6 y FP8, y 26% en FP16/BF16. La mayor diferencia aparece en FP32, donde los 315 TF del MI455X son aproximadamente 2.4 veces los 130 TF de Rubin y más de cuatro veces los 75 TF del B300. Esa cifra proviene del linaje HPC de Instinct y sigue siendo relevante para el trabajo de IA, ya que los pesos maestros, la acumulación de alta precisión y las cargas de trabajo científicas continúan ejecutándose por encima de los formatos de baja resolución.

Dentro del ADNc 5

Analicemos en detalle la arquitectura y veamos qué es lo que realmente impulsa este rendimiento líder en su clase.

De XCD a SIMD

Recorrer la jerarquía desde el paquete hacia abajo muestra cuánto se reconstruyó porque CDNA 4 organizó el chip de cómputo de manera muy diferente. En el MI355X, cada XCD contenía 32 unidades de cómputo activas y una caché L2 privada de 4 MB que agrupaba el tráfico del chip antes de que llegara a Infinity Fabric. CDNA 5 mantiene los ocho XCD, pero reconstruye lo que hay dentro de ellos, tomando prestada la estructura y la terminología de la línea de gráficos RDNA de AMD. Cada XCD del MI455X ahora se divide en dos motores de sombreado. Cada motor de sombreado contiene físicamente 17 procesadores de grupo de trabajo, con 16 habilitados y uno de reserva para rendimiento. La caché L2 por XCD se eliminó por completo, se trasladó del chip de cómputo a los chips base inferiores, a los que regresa la sección de memoria.

Lo que importa en términos matemáticos es lo que no cambió. Un XCD sigue aportando 32 unidades activas, y la GPU sigue sumando 256, la misma cantidad que tenía el MI355X como Unidades de Cómputo. Ninguna de las mejoras generacionales de cuatro veces en el rendimiento de baja precisión proviene de la adición de unidades de ejecución; todas provienen de que cada WGP realiza más trabajo por ciclo, y es en el WGP donde se concentra el rediseño.

Un WGP se construye a partir de cuatro unidades SIMD de 32 carriles y cuatro unidades escalares que comparten una caché constante. El cambio más importante radica en cómo fluyen los hilos a través de él: el paso de Wave64 a Wave32. Una onda es el conjunto de hilos que una SIMD ejecuta de forma sincronizada. CDNA 4 utilizaba Wave64, haciendo pasar cada onda de 64 hilos a través de una SIMD de 16 carriles durante cuatro ciclos de reloj. CDNA 5 elimina por completo la compatibilidad con Wave64, siendo la primera arquitectura Instinct en hacerlo, y ejecuta Wave32 de forma nativa. Una onda de 32 hilos se asigna uno a uno a cada una de las cuatro unidades SIMD de 32 carriles del WGP, se emite en un solo ciclo y permite que cada SIMD inicie una nueva instrucción en cada ciclo de reloj.

Las ondas más estrechas y rápidas modifican la forma en que el trabajo se mueve por la máquina. La latencia de las instrucciones disminuye porque una onda finaliza antes. La divergencia de bifurcaciones cuesta menos, ya que una división de tipo "tomada o no" ahora afecta a un máximo de 32 hilos en lugar de 64. La presión sobre los registros se reduce, por lo que más ondas permanecen residentes, hasta 64 por WGP, frente a la mitad anterior. Esto proporciona al planificador más tareas pequeñas e independientes para ocultar la latencia de la memoria. Wave32 también facilita la asignación de diferentes tamaños de bloques para operaciones tensoriales al hardware, simplificando el desarrollo del kernel.

Single-cycle issue is only the start of the throughput story. The SIMDs co-execute, starting new instructions while earlier multi-cycle operations drain underneath, and packed vector instructions carry 64 threads' worth of work in a single issue, details AMD's architects confirmed in the post-briefing Q&A. The vector pipeline also gains native BF16 support and a set of new data-conversion instructions for moving tensors between formats. The transcendental units double their throughput over the MI355X and add a native tanh instruction, so the softmax and activation math inside attention keeps pace with the tensor hardware around it. That path is becoming a habit: CDNA 4 doubled the transcendental rates to accelerate attention, and CDNA 5 doubles them again.

La jerarquía de la memoria

Detrás de las unidades de ejecución se encuentra una jerarquía reconstruida de arriba abajo, y la forma más clara de verla es nivel por nivel comparándola con el MI355X.

Nivel	MI455X (CDNA 5)	MI355X (CDNA 4)
Registros vectoriales	128 KB por SIMD; 1,024 por hilo; 2 × ancho de banda	128 KB por SIMD; 256 por hilo
Tienda local WGP/CU	384 KB (320 KB LDS + 64 KB de caché vectorial); ancho de banda 2×	192 KB (160 KB LDS + 32 KB L1)
Caché de instrucciones/constantes	64 KB + 16 KB por WGP	64 KB compartidos por cada dos CU + 16 KB
L2	2 × 96 MB en los FCD; 54 TB/s	8 × 4 MB, uno por XCD
Caché del lado de la memoria	eliminado	Caché infinito de 256 MB
HBM	432 GB HBM4; 12 pilas de 2,048 bits; 23.3 TB/s	288 GB HBM3E; 8 pilas de 1,024 bits; 8 TB/s

 

Las filas de caché son donde la arquitectura cambió de forma. CDNA 4 utilizaba un diseño de tres niveles: la caché L2 privada de 4 MB de cada XCD consolidaba el tráfico de ese chip antes de que llegara a la Infinity Fabric, y una Infinity Cache compartida de 256 MB en los chips de E/S se ubicaba en el lado de la memoria delante de los controladores HBM. CDNA 5 elimina ambas capas y las reemplaza con dos cachés L2 independientes de 96 MB, una por Fabric y Cache Die, cada una construida como 96 bloques de un megabyte. La disposición es vertical: cuatro XCD, u ocho Shader Engines, están unidos híbridamente sobre cada FCD, que también contiene seis de los doce sitios HBM4, y los dos FCD se unen en una Infinity Fabric central en el medio del paquete con los chips de E/S en cada extremo. Cualquiera de las L2 puede almacenar cualquier dirección en la memoria de la GPU, e Infinity Fabric mantiene la coherencia entre ambas. La razón que aduce AMD es el ancho de banda: una sola de estas cachés ofrece 1.5 veces el ancho de banda total de la Infinity Cache completa del MI355X, el par ofrece el triple, y ninguno de esos datos de tráfico tiene que cruzar la bisección entre chips que limitaba el diseño anterior.

La caché también asume nuevas funciones. Las operaciones atómicas a nivel de dispositivo, que antes se ejecutaban en la estructura de la caché, ahora se ejecutan dentro de la L2 a velocidades mucho mayores, mientras que las operaciones atómicas a nivel de sistema permanecen en la Infinity Fabric como antes. Un nuevo árbitro de difusión completa el conjunto, enviando bloques de tensores a todos los WGP que cooperan en la misma matriz. Por lo tanto, un peso obtenido una sola vez sirve a todos, lo que amplifica el ancho de banda de lectura efectivo hasta cuatro veces.

Los niveles superiores se escalan para coincidir. El almacenamiento local por WGP se duplica a 384 KB, dividido en 320 KB de LDS y una caché de datos vectoriales de 64 KB, con el doble de ancho de banda de lectura. Esto proporciona espacio para que FlashAttention almacene consultas, claves, valores y reducciones parciales en el chip en lugar de escribir la matriz de atención completa. También admite núcleos MoE fusionados para mantener el estado de enrutamiento y los acumuladores residentes. El archivo de registros vectoriales mantiene su capacidad de 128 KB por SIMD, pero se reorganiza para Wave32. Esto da como resultado el doble de ondas, permite que un solo hilo acceda a 1,024 registros en lugar de 256, y duplica el ancho de banda de los registros para alimentar los SIMD más amplios y sus unidades de coejecución.

La parte escalar se reconstruye para que coincida, con 128 registros escalares por onda y 32 KB por WGP. En la base, HBM4 pasa de ocho pilas de 1,024 bits a doce pilas de 2,048 bits, aumentando la capacidad un 50 % hasta los 432 GB y el ancho de banda 2.9 veces hasta los 23.3 TB/s a través de una interfaz de 192 canales.

Todo esto se alimenta mediante un nuevo Tensor Data Mover, uno por WGP, que entiende esquemas de teselado tensorial de hasta cinco dimensiones y transmite teselas de forma asíncrona entre la DRAM y el almacenamiento local sin almacenamiento intermedio en registros. Las transferencias se describen mediante descriptores cargados desde los registros escalares y se comprueban los límites en hardware para mayor seguridad. Se admiten cargas multicast, por lo que las unidades SIMD nunca se bloquean esperando una copia ni queman registros almacenando una. Es la respuesta de CDNA 5 a los aceleradores de memoria tensorial de las últimas piezas de NVIDIA. Un conjunto de funciones de utilización completa la interfaz de la máquina: los clústeres de grupos de trabajo dan a los kernels un control explícito sobre la ubicación y la concurrencia para cargas de trabajo de intercambio de datos, las barreras divididas y con nombre permiten que un productor señale la finalización y continúe sin esperar la respuesta del consumidor, los prefetchers en cada nivel de la jerarquía preparan los datos hacia su punto de consumo, y una interfaz de comandos rediseñada reduce la latencia de lanzamiento y despacho del kernel para los kernels cortos que dominan la inferencia.

El sistema DMA se reconstruyó siguiendo la misma filosofía. El software programa las transferencias en los front-ends DMA, mientras que los back-ends, con capacidad de procesamiento físico y ubicados junto a los enlaces UALoE, dividen cada tarea, la distribuyen entre todos los enlaces disponibles y extraen los búferes de la memoria directamente, en lugar de transferir los datos a través del chip a un motor remoto. Los back-ends también reaccionan a la presión de congestión de la red escalable y evitan las rutas sobrecargadas, de modo que las bibliotecas de comunicación obtienen un tráfico de red equilibrado sin necesidad de comprender la topología subyacente.

Segmentación de la GPU: NPS y SR-IOV

La disposición física de dos L2 ofrece una segunda ventaja en la forma en que la GPU se particiona. En NPS1, todo el chip es un dominio NUMA: las direcciones se intercalan en las doce pilas HBM y en ambas mitades para un ancho de banda uniforme, el modo fácil para la portabilidad y para patrones de acceso distribuidos uniformemente. NPS2 divide la GPU en dos dominios NUMA, cada uno con seis pilas HBM, un Fabric y un Cache Die, y los XCD apilados sobre él. Cada referencia de memoria permanece dentro de su propia mitad, y cada dominio obtiene efectivamente una L2 privada de 96 MB. Esto hace más que acortar la ruta física. Al no compartirse líneas de caché entre las mitades, el tráfico de coherencia de Infinity Fabric entre las dos L2 prácticamente desaparece, y AMD afirma que el resultado es una menor latencia y una mayor eficiencia para las aplicaciones compatibles con NUMA. CDNA 4 ofrecía la misma compensación general, con NPS2 manteniendo el tráfico dentro de un chip de E/S, pero CDNA 5 la optimiza porque ahora lo que se localiza es la caché L2 completa en lugar de una porción de un búfer del lado de la memoria.

La partición de cómputo se apila en la parte superior. Los ocho XCD permiten que la GPU arranque como una, dos, cuatro u ocho particiones espaciales, dividiendo los 432 GB de HBM en segmentos iguales de 432, 216, 108 o 54 GB respaldados por ocho hasta un XCD cada uno. El emparejamiento de particiones con los dominios NUMA permite que el tiempo de ejecución envíe el trabajo y coloque las asignaciones espacialmente, de modo que un trabajo se ejecuta en los XCD más cercanos a su memoria. SR-IOV luego virtualiza las particiones en hasta ocho máquinas virtuales aisladas por hardware, con el aislamiento aplicado en el propio sistema de memoria, independientemente del modo NUMA en ejecución. El MI355X ofrecía las mismas opciones de partición de una a ocho, por lo que la granularidad no es nueva; lo que CDNA 5 agrega subyacentemente es el comportamiento de L2 privado, y por encima de esto los Virtual Pods a nivel de rack que cubre la sección Helios.

AMD Helios

Un solo MI455X es rápido. Pero con este lanzamiento, AMD se une al club de los procesadores a escala de rack y de gran escala.

Físicamente, Helios abandona los tradicionales racks de 19 y 21 pulgadas para adoptar el formato Open Rack Wide, un formato que AMD ayudó a desarrollar con Meta en OCP: un gabinete de 1.2 metros de ancho y 1.3 metros de profundidad con 44 OU de espacio vertical. En su interior, las 72 GPU se ubican en dos bancos de nueve bandejas de computación con las seis bandejas de conmutación apiladas entre ellas, y cada enlace entre la GPU y el conmutador se realiza mediante cables de cobre que pasan a través de cuatro cartuchos de cables de conexión ciega en la parte posterior, de modo que las bandejas se deslizan para su mantenimiento sin necesidad de desconectar cables manualmente.

El rack completo consume entre 225 y 245 kW, según la carga de trabajo, y se suministra a través de una barra colectora refrigerada por líquido de 50 V. Los colectores traseros impulsan aproximadamente 385 litros de refrigerante por minuto desde el circuito de la instalación. Las bandejas en sí son componentes robustos: cada una pesa alrededor de 170 kg, y para conectar los 1,728 pares diferenciales de una bandeja de interruptores se requiere una fuerza de inserción de unos 690 kg, razón por la cual sus manijas de leva abarcan casi todo el ancho de la bandeja.

Los bloques de construcción

Bandeja de cálculo

En el diseño de referencia, cada bandeja de cómputo es un nodo autónomo construido alrededor de 4 módulos MI455X y una CPU Venice SP7 de 96 núcleos de alta frecuencia que alcanza los 5 GHz. Sus 16 zócalos DIMM admiten 1 TB de DRAM como 16 módulos DDR5 ECC RDIMM de 64 GB, con 5 ranuras NVMe E1.S conectadas a la CPU. La plataforma está diseñada para mucho más: los 16 canales de memoria de Venice admiten hasta 1.6 TB/s de ancho de banda, y con los módulos RDIMM de 256 GB en el extremo superior de la gama DDR5 actual, un zócalo de 16 canales con 1 DIMM por canal alcanza un máximo de 4 TB.

Siguiendo los pasos de NVIDIA, la CPU se une al dominio de memoria coherente a través de Infinity Fabric en lugar de ubicarse detrás de las GPU como un host PCIe simple, y AMD argumenta que la relación 1:4 CPU-GPU es deliberada: el núcleo en sí supera a la competencia, con estimaciones de AMD en igualdad de condiciones que sitúan al núcleo Zen 6 de 5 GHz aproximadamente un 20 % por delante de Vera de NVIDIA en rendimiento por núcleo, y debido a que el socket es un SP7 estándar, los clientes que desean más capacidad de cómputo de host pueden instalar cualquier SKU de Venice hasta el modelo insignia de 256 núcleos. Un socket Venice también tiene mucha más capacidad DDR5 que un diseño de host LPDDR, y su ancho de banda de memoria se satura en las 4 GPU a través de los enlaces Infinity Fabric.

Vale la pena examinar más de cerca ese enlace Infinity Fabric. Hablando sobre la conexión Venice-to-MI455X con George Cozma de Chips and Cheese , sugirió que el enlace coherente se basa en los carriles PCIe de la CPU, de la misma manera que EPYC ha llevado sus enlaces de socket xGMI a través de PHY PCIe durante años. Las cifras respaldan esta teoría. PCIe Gen 6 transmite señales a 64 Gb/s por carril, y un enlace x16 a esa velocidad resulta en 128 GB/s en cada dirección, exactamente la cifra bidireccional de 256 GB/s que AMD cita por GPU. El propio diagrama de bloques del documento técnico de CDNA 5 etiqueta la interfaz Infinity Fabric del host a 64 Gb/s por carril, la velocidad de señalización Gen 6 exacta. La teoría también explica por qué cualquier SKU de Venice se integra: las 4 GPU consumen 64 de los 128 carriles Gen 6 de la CPU, dejando el resto libre para DPU, almacenamiento y otras necesidades del sistema.

Tres redes independientes atraviesan cada bandeja de cómputo, y cada una está destinada a una tarea diferente. La más convencional es la de interfaz: una única DPU Pensando Salina 400G conecta el nodo a la red del centro de datos, que analizaremos con más detalle más adelante.

La segunda es la escalabilidad horizontal, la red que une los racks en clústeres, y la forma más clara de entenderla es mediante countSerDess. La escalabilidad horizontal del MI455X puede usar PCIe Gen 6 a 64 Gb/s por carril o UALink128 a 128 Gb/s, y una NIC Vulcano 800 necesita aproximadamente 128 Gb/s de conexión en cada dirección para mantener alimentado su puerto 800 GbE. A velocidades Gen 6, eso requiere un enlace x16 completo por NIC, por lo que la GPU maneja 2 NIC; a la velocidad de señalización duplicada de UALink128, un enlace x8 hace el mismo trabajo en la mitad del SerDes, por lo que la GPU maneja 3, que es la configuración que envía Helios. De cualquier manera, el salto UALink128 no es más que un cable privado entre la GPU y la NIC; la red en sí comienza en el Vulcano. Cada tarjeta de red (NIC) gestiona un puerto 800GbE con protocolos de transporte compatibles con UEC, incluido MRC, el protocolo de rutas múltiples que OpenAI desarrolló con AMD y otros socios. Físicamente, las NIC se ubican en dos placas personalizadas por bandeja, cada una con cuatro o seis ASIC Vulcano, lo que coincide con las configuraciones de dos y tres tarjetas por GPU. En la configuración completa, esto representa 12 NIC por bandeja y un ancho de banda escalable de 2,400 Gb/s por GPU. Dado que las NIC están conectadas a las GPU, sin la CPU en la ruta, el tráfico entre racks nunca pasa por el enlace del host.

La tercera característica es la escalabilidad, la arquitectura que convierte a Helios en un verdadero sistema a escala de rack. Cada GPU cuenta con 36 enlaces UALoE que ejecutan la semántica de memoria de UALink a través de Ethernet ESUN, cada enlace con una capacidad de 400 Gb/s, lo que suma un ancho de banda bidireccional de hasta 3.6 TB/s por GPU. Estos enlaces salen por la parte posterior de la bandeja hacia las bandejas de conmutación, transportando el tráfico de carga y almacenamiento que fusiona las 72 GPU en un único módulo de memoria compartida.

Cambiar bandeja

A continuación, las bandejas de conmutación, y lo más llamativo de ellas es lo común que es su silicio. Cada una de las 6 bandejas contiene 2 ASIC Broadcom Tomahawk 6, los mismos chips de conmutación Ethernet comerciales que los hiperescaladores implementan en sus redes leaf-spine, cada uno con 512 carriles de 200G.

Cada GPU envía 3 enlaces UALoE (cada enlace UALoE tiene 2 carriles de 200G) a cada uno de los 12 conmutadores, con 144 enlaces que salen de cada bandeja de cómputo a través de los cartuchos de cables traseros. Por lo tanto, cada Tomahawk termina 216 enlaces a 400 Gb/s, moviendo 21.6 TB/s de ancho de banda bidireccional, mientras que cada GPU mantiene sus 36 enlaces completos (72 carriles de 200G) y 3.6 TB/s. Los conmutadores no necesitan nada especial para lograr esto: la encapsulación de UALoE es un protocolo L2 simple, el reenvío se basa en la programación MAC estática que el silicio Ethernet ha ofrecido durante dos décadas, y el control de flujo es el control de flujo de prioridad estándar.

Con una única capa, se evitan por completo los problemas de congestión en los centros de datos: no hay congestión entre múltiples capas y cada GPU se encuentra a una distancia fija de todas las demás. En comparación con una malla directa, el enfoque conmutado permite que un único flujo utilice todo el ancho de banda de una ruta cuando una carga de trabajo lo requiere, manteniendo todas las GPU a la misma distancia. Por lo tanto, la planificación no tiene que considerar la localidad y proporciona a cada enlace la misma protección contra fallos.

Tolerancia a fallos

Helios considera los fallos de hardware como un factor de diseño. A esta escala, siempre hay algún problema: un cable defectuoso, un paquete perdido, un conmutador desconectado para actualizar su firmware, una unidad de procesamiento que deja de funcionar por completo. La infraestructura está diseñada para que ninguno de estos eventos interrumpa el funcionamiento del sistema. Los paquetes perdidos se recuperan mediante retransmisión, y cuando falla un enlace, cable o conmutador, el tráfico se redirige automáticamente tras una breve pausa, y la carga de trabajo continúa con el ancho de banda restante en lugar de reiniciarse desde un punto de control.

La topología de 12 planos es lo que hace que la degradación sea gradual, y el striping de 3 vías establece el tamaño del paso. Si se pierde 1 de los 3 enlaces que una GPU usa para un switch, ese plano conserva dos tercios de su ancho de banda. Si se pierde un Tomahawk completo, cada GPU cede 1/12 de su ancho de banda de escalado ascendente mientras que la comunicación total sigue funcionando a través de los otros 11 planos. Incluso perder una bandeja de switches completa, 2 de los 12 switches, le cuesta a cada GPU una sexta parte de su ancho de banda sin interrumpir la conectividad, porque ninguna GPU depende de un solo switch para conectarse con otra. En comparación, Vera Rubin NVL72 distribuye cada GPU en 36 ASIC NVSwitch 6 en 9 bandejas, por lo que una falla en una bandeja de switches allí cuesta cerca de una novena parte. NVIDIA obtiene pasos de degradación más pequeños con 3 veces más ASIC de switch; AMD responde que 12 switches de mayor radix significan menos componentes, cables y conectores que puedan fallar en primer lugar. En un periodo de entrenamiento que se mide en semanas, la diferencia entre perder una sexta parte del ancho de banda de la red y perder el trabajo representa la totalidad de la rentabilidad del rack.

Cápsulas virtuales

La misma maquinaria que divide la estructura en torno a fallos puede dividirla a propósito. AMD denomina a esta estructura Virtual Pods, o vPods, y la unidad es el nodo de cómputo: cualquier combinación de los 18 nodos de 4 GPU del rack puede aislarse en un pod, desde 1 nodo para un inquilino pequeño hasta la mayor parte del rack para una tarea de entrenamiento de gran envergadura. El aislamiento se aplica en el hardware de la estructura, por debajo de cualquier decisión del planificador. Un vPod está vinculado a su inquilino; otros pods no tienen acceso a su memoria ni a su tráfico, y el cifrado AES-256-GCM a velocidad de línea en cada enlace UALoE, con soporte para claves de clúster propiedad del cliente, mantiene los tensores de un inquilino opacos para el siguiente. Una máquina virtual invitada que abarca varias GPU tiene su dominio de seguridad extendido de forma transparente a través de ellas, sin necesidad de confiar en el sistema operativo anfitrión. NVIDIA resuelve el mismo problema en sus racks NVL72 dividiendo el dominio NVLink en particiones, con su servicio IMEX gestionando qué nodos pueden exportar e importar memoria entre sí; los vPods son el equivalente en el mundo UALoE, por lo que los operadores que provengan de flotas GB200 o GB300 encontrarán el concepto familiar.

Si una bandeja de computación falla, el radio de impacto se detiene en su vPod: esa carga de trabajo se reinicia desde el punto de control mientras que todos los demás pods continúan sin cambios, y el límite del inquilino también funciona como límite de falla. La historia de particionamiento también se extiende a todos los niveles, ya que un solo MI455X puede dividirse en hasta 8 máquinas virtuales SR-IOV, de modo que el mismo rack puede dar servicio a un cliente que ejecuta las 72 GPU como un solo pod o hasta 576 inquilinos de división de GPU en el extremo, con aislamiento de hardware en cada nivel de esa jerarquía.

El plano de gestión

Todo esto se ejecuta mediante una pila de software dedicada que sigue la misma filosofía de apertura que el hardware. AMD Fabric Manager (AFM) es el plano de control: descubre y aprovisiona la estructura de 72 GPU con puesta en marcha sin intervención, de modo que basta con encender el rack para que se inicien las 72 GPU; luego valida el cableado de los cartuchos de cables para detectar errores de montaje, divide el rack en vPods y coordina el redireccionamiento y la recuperación descritos anteriormente. No hay una bandeja de administración dedicada. AFM se ejecuta en los propios procesadores de administración de las bandejas de conmutación como 3 instancias redundantes distribuidas entre las 6 bandejas con una base de datos distribuida entre ellas, por lo que la pérdida de una bandeja de conmutación no afecta al plano de control, y una API REST de nivel superior expone la estructura a los controladores de clúster que administran múltiples racks.

Internamente, AFM toma prestada su infraestructura del mundo nativo de la nube, construida sobre controladores estándar de estilo Kubernetes con agentes en cada bandeja, y gestiona los detalles de la estructura que los usuarios nunca desean ver, incluso la asignación de los ID de acelerador que UALink utiliza para direccionar cada GPU. También es la capa de observabilidad del rack. Un único panel de control monitoriza la utilización de la GPU y la estructura, el estado del enlace y los eventos de fallo; cuando algo falla, muestra la corrección en curso y genera alertas que los operadores pueden integrar en sus propias herramientas. La captura de pantalla superior muestra a AFM monitorizando un clúster Helios en los laboratorios de AMD. La gestión funciona dentro o fuera de banda, por lo que el diagnóstico y la configuración nunca interrumpen las cargas de trabajo en ejecución. Los conmutadores bajo AFM ejecutan un sistema operativo de red basado en SONiC, el NOS de código abierto, y AMD afirma que sus adiciones UALoE se incorporarán al repositorio principal y se expondrán a través de las API gNMI estándar. Encima del rack, un Rack Infrastructure Manager cubre el ciclo de vida de los nodos y conmutadores, la alimentación y la detección de fugas, y un Cluster Controller conecta Helios a Kubernetes y Slurm para la programación.

Helios vs. NVIDIA Vera Rubin NVL72

Veamos entonces cómo se compara esto con la oferta de NVIDIA que Helios realmente igualará en el mercado: la Vera Rubin NVL72.

Métrica de rack	AMD Helios	Vera Rubin NVL72
GPU	72 MI455X	72 rubíes
CPUs	18 Venecia	36 Vera
Capacidad de HBM	31TB	20.7TB
Ancho de banda HBM	1.7 PB/s	1.58 PB/s
Escalabilidad por GPU	3.6 TB / s	3.6 TB / s
Ampliación de la capacidad de la estantería	260 TB / s	260 TB / s
Escalabilidad horizontal por GPU	2,400 Gb / s	1,600 Gb / s
Interruptores de escalado	Tomahawk 12 de 6	36 NVSwitch 6
Formato de estante	ORW de doble ancho	MGX de ancho simple

Sobre el papel, la puntuación favorece a AMD: un 50 % más de HBM, la misma capacidad de escalado ascendente de 3.6 TB/s por GPU con un tercio de ASIC de conmutación, y un 50 % más de ancho de banda de escalado horizontal por GPU. Las pruebas internas de AMD convierten estas especificaciones en una afirmación de rendimiento, logrando entre un 10 % y un 15 % más de tokens por segundo por GPU en Kimi K2 Thinking y hasta un 30 % más de tokens por dólar. Estas son las cifras de AMD frente a las cifras publicadas por NVIDIA, no mediciones independientes, pero establecen el estándar por el que AMD espera ser juzgada. Las diferencias más interesantes se encuentran en cómo cada diseño conecta sus GPU con el mundo exterior.

Comencemos con la escalabilidad horizontal. Las NIC del MI455X se conectan directamente a la GPU. Según SemiAnalysis, las de Rubin no: según SemiAnalysis, el paquete carece de PCIe para alimentar ambas NIC ConnectX-9, por lo que se conectan a la CPU Vera, y el tráfico de la GPU toma un camino más largo: Rubin a NVLink-C2C a Vera a PCIe a ConnectX-9. El desvío cuesta un salto de latencia y hace que el enlace C2C tenga doble función. Con el procesamiento, el tráfico del host y la red saturados a la vez, parte del ancho de banda C2C de Vera se destina a transportar la carga útil de la NIC, y el ancho de banda efectivo del host que ve una GPU cae por debajo de los 1.8 TB/s anunciados.

El cálculo del ancho de banda lo agrava. Cada MI455X ofrece una escalabilidad de 2,400 Gbit/s frente a los 1,600 de Rubin, por lo que Helios gestiona más tráfico de red por FLOP. Las simulaciones de AMD de una prueba de entrenamiento con 8,000 GPU atribuyen a la tercera NIC una velocidad de finalización de tareas de aproximadamente un 13 % mayor.

Rubin contraataca en el almacenamiento, y la razón radica, una vez más, en la ubicación de la tarjeta de red. ConnectX-9 cuenta con un conmutador PCIe integrado, lo que permite que NVMe se conecte directamente a la tarjeta de red y que la GPU acceda a los datos a través de GPUDirect Storage sin pasar por la CPU. El MI455X no dispone de un equivalente: su almacenamiento se conecta al host Venice, por lo que cualquier dato procesado por GPUDirect debe pasar por la CPU y regresar a través del enlace Infinity Fabric. AMD optimizó la ruta de red, pero esto repercutió negativamente en la ruta de almacenamiento; NVIDIA optó por la estrategia opuesta. La prioridad depende de si la carga de trabajo implica mover activaciones entre GPU o transmitir datos desde el disco.

Lo que los clientes pueden cambiar

En resumen, todo lo anterior describe el diseño de referencia de AMD, y varias de las cifras representan los límites mínimos que los clientes pueden superar. El caso más evidente es el de la CPU principal. La Vera de Rubin viene en una configuración fija; la Venice en una bandeja Helios es una pieza SP7 estándar con zócalo, y AMD confirmó que cualquier SKU de Venice se instala sin personalización específica para Helios. La bandeja de referencia utiliza la pieza de 96 núcleos a 5 GHz porque la velocidad de un solo hilo mantiene las GPU alimentadas. Aun así, nada impide que un cliente configure su versión con el procesador insignia de 256 núcleos, o con la Venice-X con sus 1,152 MB de caché L3 apilada para el preprocesamiento que requiere mucha caché.

La memoria y la red siguen la misma lógica de zócalos y ranuras. La referencia de 1 TB de DRAM son 16 modestos RDIMM de 64 GB; los DIMM de mayor densidad ocupan una bandeja hasta 4 TB, y el MRDIMM-12800 desbloquea los 1.6 TB/s completos de Venice. En el lado de la red, una configuración puede pasar de 3 NIC por GPU a 2 a través de PCIe Gen 6 estándar; cada puerto Vulcano puede funcionar como 1x800G, 2x400G, 4x200G u 8x100G con telares Tomahawk 5 o Tomahawk 6, y la canalización P4 deja el transporte, RoCEv2, MRC o algún protocolo propietario, a elección del operador. Incluso el plano de gestión es intercambiable, ya que el NOS del conmutador es SONiC de código abierto y AFM expone todo el tejido a través de su API de interfaz superior.

El presupuesto de energía también depende del zócalo. Los superchips de NVIDIA comparten una misma configuración: Vera es un componente de 450 W con un límite de potencia, y las generaciones más recientes distribuyen la energía hacia las GPU bajo carga. AMD no ha especificado si el diseño de referencia limita o distribuye la energía del host, pero con el diseño de AMD, la decisión recae en el cliente, quien puede personalizar el sistema con un mayor consumo de energía sin que se produzca una distribución excesiva.

La arquitectura PCIe del enlace de host, desglosada en la sección de la bandeja de computación, abre una última puerta, esta vez puramente especulativa. Venice admite configuraciones 2P, y algunas plataformas de host de IA pueden ejecutar 2P con hasta 160 carriles PCIe utilizables a cambio de ancho de banda xGMI entre sockets para E/S. Un cliente podría, en teoría, construir una bandeja de dos sockets para igualar la relación CPU-GPU 1:2 de NVIDIA, o reajustar los enlaces xGMI para aumentar el ancho de banda efectivo CPU-GPU. Nada indica que alguien esté construyendo algo así hoy en día, y nada de esto reduce la brecha con NVLink-C2C a 1.8 TB/s. La clave está en quién tiene el control: en Helios, el host, su memoria, su alimentación y, potencialmente, su topología son decisiones del cliente, y el superchip de NVIDIA no le da ninguna opción al cliente.

La unidad de policía de Salina

Volvamos ahora a la red front-end que dejamos pendiente. Salina, la DPU Pensando de tercera generación de AMD, es una tarjeta de 400G con una ruta de datos totalmente programable mediante P4, lo que significa que una nueva encapsulación, gancho de telemetría o transporte se implementa mediante una actualización de firmware, aplicada en tiempo real sin pérdida de tráfico. Los servicios de envío ya cubren la lista de verificación front-end: SDN con VXLAN o NVGRE, un firewall con estado que escala a millones de reglas, IPsec a velocidad de línea, PSP, DTLS o cifrado personalizado, NAT y balanceo de carga. También es el silicio más probado en condiciones reales del mercado. Las DPU Pensando se utilizan en hiperescaladores desde 2019; Salina lidera implementaciones en Microsoft, Oracle e IBM actualmente; Oracle le atribuye a esta línea una ganancia de SDN de 5 veces, y un hiperescalador recuperó 22 núcleos de CPU por servidor al descargarle las E/S.

El almacenamiento es el segundo acto. Salina expone los dispositivos NVMe-over-Fabrics al host, virtualizando grupos de SSD remotos a través de TCP o RDMA con cifrado, resúmenes y compresión realizados en la tarjeta. En Helios, agrega un truco de la era de los agentes: un motor de memoria de contexto presenta un dispositivo KV emulado, por lo que la caché KV desbordada se derrama a la DRAM de la CPU, SSD local o almacenamiento remoto y se transmite de vuelta a HBM a velocidad de línea en lugar de ser recalculada. Como se señaló en la comparación de Rubin, el MI455X carece de GPUDirect Storage; esta descarga KV es la respuesta parcial de AMD para el tráfico que más le importa.

Aquí es donde radican nuestras reservas. La brecha de ancho de banda es evidente: Salina es una tarjeta de 400G, y la BlueField-4 que se envía a los racks de Vera Rubin duplica esa cifra a 800G con una CPU Grace de 64 núcleos y un ConnectX-9 integrado. La brecha de software es más discutible, pero real. DOCA de NVIDIA ofrece a los desarrolladores servicios preconfigurados y en contenedores, programables en C y C++ estándar; P4 es un lenguaje de plano de datos especializado que la mayoría de los equipos nunca ha utilizado. La comparación no es "el catálogo de DOCA frente a P4 puro", ya que Salina incluye sus principales servicios completos, y los proveedores de servicios en la nube que lo implementan lo eligieron en parte porque P4 permite que nuevos protocolos como MRC se integren en el firmware antes del ciclo de vida del silicio. La verdadera distinción radica en a quién beneficia la programabilidad. La flexibilidad de Salina es una ventaja para AMD y los equipos de proveedores de servicios en la nube con experiencia en P4; DOCA es un conjunto de herramientas que un desarrollador empresarial común puede utilizar. Para el mercado general, la integración de software de NVIDIA es más sencilla, y AMD lo sabe.

ROCm.AI

Hablando de software, AMD reservó uno de sus anuncios más importantes para la propia plataforma. ROCm.AI, que llegará en agosto, es el intento de AMD de convertir la plataforma GPU en una plataforma con capacidad de gestión de agentes desde cero. AI Skills integra ROCm con los agentes de codificación que los desarrolladores ya utilizan (Claude, Codex, Cursor y Gemini), de modo que la instalación, el servicio y la depuración en Instinct se realizan en lenguaje natural. Hyperloom es la pieza más ambiciosa: un optimizador automatizado que analiza una carga de trabajo, ajusta su configuración de servicio, reescribe los kernels de la GPU y valida los resultados mientras el operador descansa. AMD afirma que actualmente optimiza continuamente unos 14 000 modelos, y una demostración en vivo logró un aumento del 38 % en el rendimiento de MiniMax M3. Bajo los agentes, FlyDSL aporta un control casi a nivel de ensamblador a Python, ROCm adopta un ciclo de lanzamiento fijo de 6 semanas, y AMD afirma que ROCm.AI ofrece una mejora promedio de 3.3 veces en inferencia y 2.4 veces en entrenamiento con respecto a ROCm 7 en hardware idéntico. ROCm 7 ya marcó una mejora real; ahora AMD apuesta por la IA para acelerar el ritmo.

Podría decirse que la diapositiva más importante de la sesión de software fue la del hardware. AMD enfatizó que cada número que mostraba estaba medido, dando a entender que el chip MI455X ya está funcionando a pleno rendimiento y con gran velocidad bajo ROCm. Las cifras: 20 TB/s en decodificación FP8 MLA, 20 PFLOPS de cómputo FP4, 3.2 TB/s de ancho de banda de escalado ascendente y 190 GB/s de escalado descendente. En la sesión de preguntas y respuestas, AMD reconoció que el resultado de FP4 es una medición de FLOPS de multimatriz máxima alcanzable (MAMF), ejecutada con la forma de matriz que mejor se adapta al dispositivo, lo cual es práctica habitual para este tipo de benchmark. También es una declaración audaz: AMD admite abiertamente que el MI455X mantiene aproximadamente el 50 % de su pico de 40.26 PFLOPS en MXFP4, un dato que la mayoría de los fabricantes ocultarían.

AMD afirma que este es el mayor rendimiento de cálculo demostrado por cualquier acelerador del mercado, y ahí es donde entra en juego la cautela. El FP4 de AMD es OCP MXFP4; el de NVIDIA es NVFP4. Son recetas diferentes: NVFP4 aplica una escala fraccional FP8 a cada bloque de 16 elementos más una escala a nivel de tensor, mientras que el MXFP4 base utiliza una escala más gruesa de potencia de dos por cada 32 elementos, por lo que un FLOP de NVFP4 lleva más trabajo que un FLOP de MXFP4. CDNA 5 también puede aplicar escala fraccional a MXFP4, pero AMD no especificó qué receta utilizó para la medición. Una ejecución de Rubin MAMF y una ejecución de MI455X MAMF no miden las mismas operaciones matemáticas, por lo que las comparaciones de FP4 entre proveedores solo se establecen a nivel de aplicación: tokens por segundo con la misma precisión. Las mediciones superan las proyecciones, pero estas cifras se leen con mayor honestidad en comparación con la generación anterior de AMD, donde las ganancias de 3× a 4× son inequívocas.

También hay un contrapeso a favor de AMD. Estos son resultados preliminares de ROCm.AI en silicio completamente nuevo, por lo que, en todo caso, subestiman el rendimiento que alcanzará una implementación de producción optimizada manualmente. El veredicto definitivo llegará cuando estos racks se instalen en las plantas de los hiperescaladores.

Pensamientos Finales

Helios es el sistema más completo que AMD ha lanzado hasta la fecha, y el primero que compite directamente con NVIDIA a escala de rack en lugar de chip por chip. La hoja de puntuación muestra la superioridad de AMD en los aspectos que determinan la capacidad de IA actual: un 50 % más de HBM por GPU, paridad de escalabilidad vertical con Rubin, un 50 % más de ancho de banda de escalabilidad horizontal y, según los propios modelos de AMD, hasta un 30 % más de tokens por dólar. Igual de importante es cómo se logró: conmutadores Tomahawk comerciales, estándares abiertos desde los formatos numéricos hasta el gabinete y un host con zócalo que deja la configuración final en manos del cliente. NVIDIA mantiene ventajas reales en el enlace host C2C, la DPU y su rampa de acceso de software, pero por primera vez, el argumento general del hardware sobre el papel favorece a AMD.

Y los compradores coinciden. OpenAI, Meta, Anthropic, Microsoft y Oracle se encuentran entre las empresas que, según AMD, están adoptando Helios, y AMD destaca que los racks ya están en producción. Siguiendo los pasos de NVIDIA, la hoja de ruta ahora tiene una periodicidad anual: la serie MI500 basada en CDNA 6 llegará en 2027 con HBM de próxima generación, además de interconexión de cobre y óptica, y la serie MI600 ya está en desarrollo para 2028.

Lo que nos lleva al software, y por primera vez en años, no terminamos un artículo sobre GPU de AMD con esa salvedad. ROCm 7 cerró brechas reales, ROCm.AI llega en agosto con ganancias medidas adicionales, y el ciclo de lanzamiento ahora es fijo de seis semanas. También importa quién compra. Los laboratorios y los proveedores de servicios en la nube que firman estos acuerdos codiseñan con AMD y emplean suficientes ingenieros para solucionar cualquier problema que surja. Las empresas que necesitan una solución integral son otra historia, y ese mercado sigue siendo de NVIDIA por ahora. Pero Helios fue diseñado para los proveedores de servicios en la nube y los laboratorios de IA, y para ellos, el hardware está listo, el software se mantiene al día y los racks se están enviando. AMD nunca ha estado en una posición más fuerte.