La apuesta de AMD y Google por los estándares se mide con Nvidia en la prueba de redes de IA de Vulcano
AMD ha presentado su NIC de IA Pensando Vulcano de 800 Gbps, pese a la ventaja de Nvidia en redes estrechamente integradas para grandes clústeres de GPU. La conexión entre AMD y Google es relevante porque ambas empresas respaldan estándares abiertos de interconexión diseñados para ofrecer a los compradores de infraestructura más opciones de hardware. Sin embargo, Google no ha anunciado planes para desplegar Vulcano.
Vulcano aborda un costoso problema dentro de los centros de datos de IA. Los aceleradores pueden permanecer inactivos cuando la congestión de red, la pérdida de paquetes o una recuperación lenta retrasan la comunicación entre servidores. AMD afirma que tres tarjetas Vulcano pueden proporcionar 2,4 terabits por segundo de ancho de banda de escalado horizontal para cada GPU.
Esa cifra ofrece a AMD un titular claro, pero no una victoria automática. Nvidia ya vende una combinación consolidada de GPU, Ethernet Spectrum-X, InfiniBand, NVLink, switches y software de red. Vulcano debe demostrar que un enfoque Ethernet abierto y programable puede ofrecer una consistencia operativa comparable sin requerir la pila completa de un solo proveedor.
Qué cambió con AMD Pensando Vulcano 800
Vulcano convierte las redes en una parte central de la plataforma de IA a escala de rack de AMD, en lugar de un accesorio añadido después de seleccionar las GPU.
AMD detalló públicamente la NIC de IA Pensando Vulcano 800 el 23 de julio de 2026. El adaptador está diseñado para redes de escalado horizontal, que conectan aceleradores entre servidores y racks después de que sus enlaces locales de escalado vertical alcanzan límites prácticos.
Cada tarjeta proporciona una conexión de red de 800 Gbps. AMD admite configuraciones con hasta tres NIC asignadas a una GPU, creando el ancho de banda agregado anunciado de 2,4 Tbps.
Esta disposición difiere de tratar un adaptador de red como un punto final compartido para varios aceleradores. Múltiples enlaces independientes pueden aumentar el ancho de banda disponible y ofrecer al tráfico más de una ruta a través del clúster.
AMD denomina a esto una arquitectura multiplano. Un plano de red es una ruta de datos independiente que contiene sus propios enlaces y recursos de conmutación. Dividir el tráfico entre planos puede limitar el impacto de un enlace averiado o una ruta congestionada.
La empresa también afirma que Vulcano puede reducir los costes de conmutación hasta en un 33 por ciento. AMD atribuye esa estimación a un menor número de cables y transceptores dentro de su configuración de referencia, no a una reducción universal en cada despliegue.
Su afirmación de rendimiento merece la misma cautela. AMD asegura que Vulcano puede mejorar el tiempo de finalización de trabajos de IA hasta en un 13 por ciento. Ese resultado es un benchmark de la empresa vinculado a cargas de trabajo y supuestos de sistema específicos.
Ninguno de los dos porcentajes debe tratarse como rendimiento verificado de forma independiente para cada clúster. Los compradores necesitan pruebas a nivel de carga de trabajo que incluyan switches, óptica, topología, versiones de software, comportamiento ante fallos y utilización de aceleradores.
El mecanismo subyacente sigue siendo creíble. El entrenamiento distribuido intercambia repetidamente parámetros del modelo y resultados intermedios entre aceleradores. Una ruta retrasada puede bloquear una operación colectiva y dejar GPU costosas esperando a sus pares.
La inferencia distribuida crea otro patrón de tráfico. Puede mover solicitudes, estados del modelo y datos en caché entre sistemas mientras cambia la demanda de los usuarios. La latencia predecible puede importar tanto como el rendimiento máximo.
Vulcano aborda estos patrones con lógica de transporte programable, controles de congestión, aislamiento de fallos y diagnósticos en servicio. AMD afirma que los operadores pueden actualizar partes de ese comportamiento mediante software en vez de sustituir el silicio de red.
La NIC utiliza motores P4 programables de tercera generación. P4 es un lenguaje y una arquitectura para definir cómo los dispositivos de red procesan paquetes. Permite a los proveedores modificar comportamientos seleccionados de reenvío y transporte dentro de los límites compatibles con el hardware.
El diseño de Vulcano de AMD también incluye opciones de conectividad PCIe y UALink. Esa flexibilidad permite que el adaptador se conecte con CPU o aceleradores en distintos diseños de rack.
Por tanto, el producto representa más que un puerto Ethernet más rápido. AMD intenta coordinar GPU, CPU, silicio de red, transportes abiertos y software de gestión como un único sistema a escala de rack.
Por qué importa el vínculo entre AMD, Google y los estándares
La relación entre AMD y Google es una alianza de estándares, no una prueba de que Google Cloud haya seleccionado Vulcano para producción.
AMD y Google estuvieron entre las empresas originales detrás del grupo promotor de Ultra Accelerator Link en 2024. Broadcom, Cisco, Hewlett Packard Enterprise, Intel, Meta y Microsoft también participaron.
UALink se dirige a la comunicación de escalado vertical entre aceleradores dentro de un pod de computación. Las redes de escalado vertical crean un dominio de aceleradores estrechamente conectado, mientras que las redes de escalado horizontal enlazan varios servidores o dominios a través de una estructura de red más amplia.
Estas funciones se solapan en el límite del sistema, pero no son intercambiables. Vulcano gestiona principalmente el tráfico de escalado horizontal y entre dominios. Su interfaz UALink le ayuda a conectarse directamente con aceleradores dentro de arquitecturas abiertas de rack emergentes.
Por tanto, la palabra clave amd google puede crear una impresión engañosa. Ningún anuncio verificado afirma que Google codiseñó Vulcano, compró la NIC o comprometió capacidad de Google Cloud para ella.
La importancia de Google proviene de su posición como operador de hiperescala y participante en estándares. Su participación da mayor relevancia al trabajo de interconexión abierta porque Google comprende las exigencias de tráfico, fiabilidad y gestión de flotas de los grandes sistemas de IA.
El consorcio UALink publicó su primera especificación para conectar hasta 1.024 aceleradores dentro de un pod. El respaldo de varios operadores de nube y proveedores de chips puede reducir el riesgo de que el estándar dependa de un solo proveedor.
Vulcano también admite Ultra Ethernet para la comunicación entre sistemas. La especificación UEC define una pila de comunicación basada en Ethernet para IA y computación de alto rendimiento.
Ultra Ethernet cambia más que la velocidad bruta del enlace. Aborda la entrega de paquetes, la gestión de congestión, el enrutamiento por múltiples rutas, la seguridad y las semánticas de comunicación requeridas por cargas de trabajo estrechamente sincronizadas.
AMD también está impulsando Multipath Reliable Connection, o MRC. Este transporte puede distribuir datos entre varias rutas al tiempo que mantiene una entrega fiable y responde a la congestión o los fallos.
AMD afirma que codesarrolló MRC con OpenAI para grandes entornos de entrenamiento. La empresa implementó el transporte en su anterior NIC Pollara 400 y afirma que Vulcano lo admitirá cuando la plataforma más reciente esté disponible de forma general.
Según la implementación de MRC de AMD, Pollara fue validada en laboratorios de la empresa con clústeres Instinct MI350 y MI355. AMD afirma que OpenAI participó en esa validación.
MRC puede operar con enrutamiento por segmentos sobre IPv6, lo que otorga a los operadores control explícito sobre las rutas de los paquetes. También puede funcionar con enrutamiento multipath de igual coste y balanceo dinámico de carga.
Esta adaptabilidad respalda el argumento más amplio de AMD. Los operadores deberían poder adoptar nuevos comportamientos de transporte sin sustituir cada switch, cable y proceso de gestión alrededor del clúster de aceleradores.
La participación de Google en los estándares refuerza ese argumento, pero no valida las afirmaciones de producto de AMD. Las especificaciones definen comportamientos comunes, mientras que los despliegues de producción revelan la calidad de la implementación.
Un estándar escrito no puede garantizar tiempos de trabajo estables durante la congestión. No demuestra que las herramientas de diagnóstico identifiquen fallos rápidamente ni que distintos proveedores interpreten de forma idéntica cada función opcional.
Para los compradores, la historia de AMD y Google trata por tanto de alineamiento estratégico. Ambas empresas han respaldado alternativas a las estructuras cerradas de aceleradores, pero Vulcano debe ganarse la adopción mediante un rendimiento de clúster medible.
Esa distinción importa para los equipos de compras. Deben evaluar Vulcano como un producto de AMD dentro de un entorno emergente de múltiples proveedores, no como una tarjeta de red respaldada por Google.
El mecanismo de Vulcano es ancho de banda más programabilidad
El argumento técnico más sólido de Vulcano no son solo los 800 Gbps, sino su combinación de múltiples rutas, transporte programable y rápida recuperación ante fallos.
Las redes de IA implican comunicación sincronizada entre muchos puntos finales. Durante el entrenamiento, las operaciones colectivas combinan o redistribuyen datos producidos por cada acelerador participante.
Si un flujo encuentra congestión, todo un paso de entrenamiento puede ralentizarse. Las GPU restantes pueden terminar su trabajo local, pero no pueden avanzar hasta que se complete la comunicación colectiva.
El Ethernet convencional suele distribuir flujos entre rutas mediante un hash de su información identificativa. Un flujo grande puede quedar atrapado en una ruta congestionada incluso cuando otra ruta tiene capacidad sin usar.
MRC está diseñado para usar varias rutas de forma más deliberada. Puede separar el tráfico en partes, reaccionar a las condiciones de las rutas y recuperarse sin obligar a una aplicación a reiniciar la comunicación completa.
Los motores programables de procesamiento de paquetes de Vulcano sitúan parte de ese control cerca del borde de la red. Esa ubicación importa porque la NIC observa el tráfico que entra y sale de cada servidor.
La tarjeta también puede aislar fallos y realizar diagnósticos mientras un clúster permanece activo. AMD afirma que estas funciones reducen el tiempo de reparación y evitan algunas ventanas de mantenimiento de todo el clúster.
Estas capacidades adquieren valor a medida que crece el tamaño del clúster. Un sistema con miles de componentes experimenta fallos rutinarios de enlaces, óptica, firmware y switches, incluso cuando cada componente tiene una alta fiabilidad individual.
La red debe degradarse de forma predecible en lugar de convertir un fallo en un trabajo bloqueado. Varios planos proporcionan rutas alternativas, mientras que la lógica de transporte decide cómo debe circular el tráfico entre ellas.
Tres NIC de 800 Gbps por GPU crean una capacidad física considerable. Sin embargo, el ancho de banda agregado no significa que cada carga de trabajo vaya a transferir continuamente 2,4 Tbps de datos útiles.
La GPU, la interfaz del host, la biblioteca colectiva, la topología y los puntos finales remotos deben suministrar tráfico de forma eficiente. La sobrecarga de protocolo y la sincronización de las cargas de trabajo también reducen el rendimiento a nivel de aplicación.
La arquitectura de AMD admite conexiones de host tanto PCIe como UALink. PCIe sigue siendo una interfaz familiar para CPU y periféricos. UALink se dirige a la conectividad directa de aceleradores con menor dependencia de un único proveedor de GPU.
Vulcano también está vinculado a AMD Helios, el diseño a escala de rack de la empresa que utiliza aceleradores Instinct de la serie MI400 y procesadores EPYC Venice. AMD ha posicionado la NIC como el componente predeterminado de red de escalado horizontal de Helios.
Esa integración da a AMD mayor control sobre la validación. La empresa puede probar firmware, bibliotecas de comunicación ROCm, comportamiento de aceleradores y telemetría de red como una plataforma coordinada.
Sin embargo, la programabilidad tiene costes operativos. Una canalización de paquetes modificable exige procesos disciplinados de control de versiones, pruebas, observabilidad y reversión.
Los equipos de red deben saber qué ajustes de firmware y transporte estaban activos durante un trabajo fallido. También necesitan herramientas que correlacionen eventos de congestión con el rendimiento de las aplicaciones.
La etiqueta P4 no elimina esos requisitos. Solo ofrece a AMD y a los operadores autorizados más margen para cambiar cómo se comportan las funciones compatibles de procesamiento de paquetes.
Los estándares abiertos plantean otro reto de implementación. Dos productos pueden afirmar que admiten la misma especificación y, aun así, diferir en funciones opcionales, límites de rendimiento o interfaces de gestión.
Por ello, las pruebas de interoperabilidad serán decisivas. Los compradores necesitan evidencias de que Vulcano funciona de forma fiable con switches, ópticas, software de enrutamiento y sistemas de monitorización de terceros.
La página de AMD AI NIC pone el foco en los hyperscalers y los proveedores de nube. Estos clientes cuentan con los equipos de ingeniería necesarios para probar comportamientos de red complejos a gran escala.
La adopción empresarial podría avanzar con mayor lentitud. Muchas empresas compran sistemas completos porque no disponen del personal necesario para integrar de forma independiente aceleradores, NIC, switches, firmware y ajustes de transporte.
Vulcano aún puede ayudar a estas organizaciones mediante sistemas Helios validados o servicios en la nube. El grado de apertura dependerá de cuántos proveedores comercialicen configuraciones compatibles.
Esta es la prueba práctica detrás del producto. La programabilidad debe reducir el coste de adaptar una red sin trasladar al cliente una carga de integración excesiva.
La pila integrada de Nvidia sigue siendo el principal rival
AMD está desafiando el control de Nvidia sobre la arquitectura de los sistemas de IA, no simplemente compitiendo con otro adaptador Ethernet de 800 Gbps.
Nvidia puede conectar sus aceleradores mediante NVLink dentro de un dominio scale-up. Después ofrece Quantum InfiniBand o Spectrum-X Ethernet para la comunicación entre servidores y racks.
Spectrum-X combina switches de Nvidia, SuperNICs, control de congestión, telemetría y software. Nvidia prueba estos componentes como un sistema integral estrechamente vinculado a su plataforma de GPU.
Esa integración puede simplificar la rendición de cuentas. Cuando un trabajo de IA rinde por debajo de lo esperado, un cliente puede pedir a un único proveedor que examine el acelerador, el adaptador de red, el switch, el firmware y las bibliotecas de comunicación.
Nvidia afirma que Spectrum-X Ethernet puede mejorar el rendimiento de red en 1,6 veces frente a Ethernet convencional. Al igual que las cifras de AMD, se trata de una afirmación del proveedor basada en configuraciones especificadas.
Spectrum-X también admite sistemas operativos de red abiertos, incluido SONiC. Por tanto, la competencia no es una simple disputa entre Ethernet abierto y una alternativa completamente cerrada.
La diferencia real se refiere al control y a la elección de componentes. Nvidia optimiza una combinación definida de su silicio y software, mientras que AMD hace hincapié en dispositivos programables y especificaciones industriales entre distintos proveedores.
La integración estrecha puede generar un comportamiento consistente, pero puede aumentar la dependencia del calendario de lanzamientos de un solo proveedor. Un diseño multiempresa puede ofrecer más opciones, pero el trabajo de certificación se vuelve más difícil.
Vulcano necesita demostrar que su enfoque abierto no sacrifica un rendimiento predecible. El rendimiento máximo por sí solo no resolverá esa cuestión.
Los operadores de clústeres de IA analizan el tiempo de finalización de los trabajos, la latencia de cola, la recuperación ante fallos, la utilización efectiva de las GPU y el aislamiento del rendimiento entre inquilinos. También controlan el consumo energético y el número de ópticas necesarias.
La afirmación de AMD de una mejora del 13 por ciento en el tiempo de finalización es relevante porque mide un resultado de aplicación. Sin embargo, el material público no establece una ventaja universal frente a Spectrum-X o InfiniBand.
La afirmación de una reducción del 33 por ciento en el coste de conmutación también requiere una interpretación cuidadosa. Menos cables y transceptores pueden reducir el gasto en equipos, el trabajo de instalación y los puntos de fallo.
Sin embargo, una configuración de tres NIC por GPU puede añadir adaptadores, interfaces de host y complejidad de gestión en otros puntos. El resultado total depende de la topología y de la referencia de comparación.
Nvidia cuenta con otra ventaja gracias a sus sistemas desplegados. Sus productos de red ya operan en grandes clústeres de IA, lo que proporciona a los clientes referencias de implementación y prácticas de soporte consolidadas.
AMD no parte sin experiencia. Pensando ya comercializó DPU y Pollara AI NICs, mientras que AMD ha trabajado con proveedores de nube y fabricantes de sistemas en redes de centros de datos.
No obstante, Vulcano llega junto con varios elementos nuevos. Helios introduce nuevos aceleradores Instinct, procesadores EPYC, conexiones UALink y una pila de software abierto en evolución.
Un problema en cualquiera de las capas puede retrasar la certificación. Los clientes pueden optar por una configuración madura incluso cuando otro diseño promete mayor flexibilidad de componentes.
El riesgo es mayor para las organizaciones que buscan capacidad de entrenamiento a corto plazo. Su prioridad suele ser poner un clúster en línea rápidamente, no maximizar la futura capacidad de elección de proveedores.
Los compradores a más largo plazo pueden valorar más el enfoque abierto. La infraestructura perdura a través de varias generaciones de aceleradores, mientras que los modelos y los patrones de comunicación cambian mucho más rápido.
La programabilidad P4 de Vulcano podría ayudar a AMD a responder a esos cambios. Nuevos controles de congestión o comportamientos de transporte podrían llegar mediante software dentro de las capacidades del hardware.
Nvidia también puede actualizar su pila. Además, se beneficia de controlar más componentes, lo que puede acelerar cambios coordinados en todo el sistema.
Por tanto, la principal competencia es operativa. AMD debe demostrar que la elección basada en estándares puede igualar la fiabilidad, las herramientas y la validación de la plataforma integrada de Nvidia.
La presencia de Google en grupos de interconexión abierta aumenta la confianza en que la alternativa cuenta con un respaldo serio de la industria. No elimina la base instalada ni la ventaja de ejecución de Nvidia.
Lo que AMD aún tiene que demostrar
La mayor incertidumbre es si las mejoras publicadas de Vulcano resisten pruebas independientes en clústeres multiempresa realistas.
Las cifras públicas de AMD describen capacidades máximas y comparaciones seleccionadas. Aún no proporcionan un conjunto amplio de resultados de terceros en entrenamiento, inferencia distribuida y cargas de trabajo mixtas.
La cifra de 2,4 Tbps es ancho de banda scale-out agregado de tres NIC de 800 Gbps. No garantiza que una aplicación de una GPU reciba esa tasa de datos de forma continua.
Las revisiones independientes deberían medir el rendimiento útil bajo congestión. También deberían informar sobre las distribuciones de latencia, el comportamiento de recuperación de paquetes y el tiempo de inactividad de los aceleradores.
Las pruebas de fallos importan tanto como la velocidad en estado estable. Los evaluadores deberían desactivar enlaces, introducir pérdida de paquetes, reiniciar switches y variar la latencia de las rutas mientras un trabajo distribuido permanece activo.
MRC también necesita evidencias de interoperabilidad. AMD afirma que el transporte admite varios enfoques de reenvío, pero los clientes querrán combinaciones verificadas de NIC, switches, firmware y software de enrutamiento.
La disponibilidad general es otro detalle sin resolver. AMD ha indicado que Vulcano está siendo certificado para clústeres Instinct de la serie MI400, mientras que se espera la disponibilidad de Helios durante 2026.
La certificación no equivale a un despliegue amplio. Un producto puede cumplir sus objetivos de diseño mientras que fabricantes de sistemas, proveedores de nube y empresas siguen necesitando meses de validación.
La cuestión de Google sigue siendo especialmente importante porque la palabra clave principal sugiere una relación directa. Google ha apoyado UALink, pero no hay pruebas públicas que confirmen que Google Cloud ofrecerá instancias basadas en Vulcano.
Un despliegue de Google proporcionaría una señal significativa de adopción. Mostraría que un hyperscaler con experiencia interna en redes consideró que Vulcano era adecuado para uso en producción.
La ausencia de tal anuncio no es una prueba en contra del producto. Los hyperscalers suelen evaluar varias arquitecturas y divulgar solo despliegues seleccionados.
La preparación del software también requiere escrutinio. ROCm debe coordinar la comunicación colectiva con la red al tiempo que expone telemetría útil a los planificadores y equipos de operaciones.
Una NIC rápida no puede compensar bibliotecas colectivas ineficientes ni una mala colocación de cargas de trabajo. La conciencia de red debe llegar a la capa de orquestación si los operadores quieren tiempos de trabajo consistentes.
La seguridad también merece atención. Los dispositivos programables amplían las posibilidades de configuración, y cada ruta de firmware requiere controles de firma, actualizaciones, acceso y reversión.
Las especificaciones abiertas no crean automáticamente una gestión abierta. Los clientes deberían examinar qué funciones requieren herramientas de AMD y si los productos de observabilidad de terceros pueden acceder a la telemetría esencial.
La afirmación de costes necesita una contabilidad completa del sistema. Una comparación justa debería incluir adaptadores, switches, cables, ópticas, espacio de rack, energía, soporte y trabajo de ingeniería.
Los equipos que evalúen Vulcano deberían conservar los registros de referencia mediante una base de conocimiento de ingeniería con capacidad de búsqueda. Las versiones de firmware y los detalles de la topología pueden determinar si las comparaciones posteriores siguen siendo útiles.
Los equipos de compras también deberían separar los requisitos scale-up de los scale-out. UALink, Ultra Ethernet, MRC y PCIe abordan distintas partes de la ruta de datos.
Confundir esas capas puede producir especificaciones impresionantes sin un despliegue coherente. Los compradores necesitan una arquitectura que muestre cómo se mueve el tráfico desde un acelerador hasta cada punto final relevante.
La dirección técnica de AMD es plausible. Su desafío consiste en convertir esa dirección en sistemas repetibles que los clientes puedan pedir, desplegar, monitorizar y reparar.
Tres señales decidirán el caso de Vulcano en redes de IA
La posición de Vulcano quedará más clara mediante resultados independientes de clústeres, clientes de producción identificados e interoperabilidad multiempresa verificada.
La primera señal son las pruebas independientes en sistemas Helios completos. Los resultados deberían comparar tiempos de finalización de trabajos, utilización de GPU, latencia de cola y recuperación en distintas condiciones de red.
Una prueba útil identificará cada componente y versión de software. Debería distinguir entre el ancho de banda medido en el enlace y el rendimiento entregado a la aplicación de IA.
Resultados sólidos en varias cargas de trabajo respaldarían la afirmación de AMD de que Vulcano elimina los cuellos de botella de comunicación. Resultados débiles o inconsistentes reducirían el valor de su ancho de banda destacado.
La segunda señal es un despliegue identificado de hyperscale o nube. Oracle ha hablado de infraestructura a escala de rack de AMD, mientras que OpenAI ha trabajado con AMD en la validación de MRC.
Google sería especialmente significativo por el interés de búsqueda amd google y su papel en los esfuerzos de interconexión abierta. Sin embargo, los lectores deberían esperar un anuncio directo de despliegue.
Un cliente debe describir algo más que una evaluación. La disponibilidad en producción, el tamaño del clúster, las cargas de trabajo compatibles y las expectativas de nivel de servicio aportarían evidencias más sólidas.
La tercera señal es la interoperabilidad más allá de un diseño de referencia totalmente AMD. Vulcano debería funcionar con varios proveedores de switches, sistemas operativos de red, ópticas y plataformas de gestión.
Una interoperabilidad satisfactoria reforzaría el argumento económico de las redes de IA abiertas. Permitiría a los clientes cambiar componentes seleccionados sin rediseñar el clúster completo.
Una compatibilidad limitada debilitaría ese argumento, incluso si Helios ofrece buen rendimiento como configuración de referencia cerrada. El sistema podría volverse integrado en la práctica pese a basarse en especificaciones abiertas.
Nvidia no se quedará quieta mientras AMD completa esta validación. Spectrum-X ya combina Ethernet basado en estándares con el control de Nvidia sobre la plataforma circundante.
Por tanto, las comparaciones futuras deben utilizar productos actuales de ambas compañías. Una victoria frente a Ethernet antiguo no demuestra una ventaja sobre la infraestructura más reciente de Nvidia.
Para los desarrolladores, el efecto inmediato seguirá siendo indirecto. La mayoría encontrará Vulcano a través de instancias en la nube, clústeres gestionados o sistemas seleccionados por equipos de infraestructura.
Aun así, las redes influyen en el tiempo de entrenamiento, la latencia de inferencia, la disponibilidad de capacidad y el coste del servicio. Las mejoras en la capa de infraestructura pueden cambiar qué cargas de trabajo de IA siguen siendo económicamente viables.
Los compradores empresariales deberían pedir a los proveedores evidencias a nivel de carga de trabajo en lugar de resúmenes de velocidad de puertos. También deberían solicitar pruebas de fallos y un límite de soporte claro entre proveedores.
La cuestión esencial ya no es si Ethernet puede transportar tráfico de IA. La cuestión es si un sistema Ethernet abierto puede ofrecer resultados consistentes a una escala en la que una sola ruta retrasada desperdicia miles de aceleradores.
AMD ha presentado ahora una respuesta concreta mediante Vulcano, MRC, Ultra Ethernet y Helios. Google y otros socios de estándares aportan mayor credibilidad a la ruta abierta, pero no garantizan la ejecución de AMD.
Habrá que seguir de cerca los primeros benchmarks independientes de Helios, el primer despliegue en la nube de Vulcano con nombre propio y los primeros informes amplios de interoperabilidad. Esas tres señales determinarán si la apuesta de AMD por los estándares se convierte en una alternativa de producción o sigue siendo una especificación atractiva.
