Broadcom Tomahawk 6 duplica el ancho de banda. Las redes de IA siguen afrontando una presión de escalabilidad
Broadcom Tomahawk 6 duplicó la capacidad de conmutación Ethernet de un solo chip hasta los 102,4 terabits por segundo, pero ese avance no duplica automáticamente la capacidad útil de un clúster de IA. Las conexiones más rápidas pueden consumir el ancho de banda adicional antes de que los operadores conecten más aceleradores. La presión resultante se extiende más allá de los switches, hacia las distribuciones de los edificios, el software y los calendarios de despliegue.
Un artículo de opinión publicado el 30 de octubre en Data Center Dynamics volvió a poner de relieve esa tensión. Su autor, Omar Hassen, cofundador de Eridu, sostiene que las redes deben dar forma a las instalaciones de IA desde el principio. Su advertencia merece atención, junto con un análisis riguroso del calendario y de los supuestos que la sustentan.
Broadcom y Nvidia ya están respondiendo con conmutación más rápida e integración óptica. El trabajo de ingeniería de Meta añade otra consideración: el ancho de banda instalado y el ancho de banda utilizable no son lo mismo. El conflicto central se sitúa entre las crecientes necesidades de comunicación y la capacidad de la red para ofrecer un rendimiento de las aplicaciones predecible.
Broadcom Tomahawk 6 cambia las cifras, no toda la ecuación
El último aumento de ancho de banda es real, pero no demuestra que la limitación de la red haya desaparecido.
Broadcom anunció que estaba enviando Tomahawk 6 el 3 de junio de 2025. Su capacidad declarada era de 102,4 terabits por segundo, una medida del movimiento agregado de datos a través del chip del switch. La empresa también describió funciones de enrutamiento y conectividad destinadas a la infraestructura de IA.
Ese anuncio es relevante al evaluar el reciente argumento sobre el muro de la red. Hassen presenta el ancho de banda insuficiente de los switches y la conectividad como limitaciones para una infraestructura de IA productiva. Defiende una conectividad más alta y redes más planas, es decir, diseños con menos capas de conmutación.
El artículo es el análisis de un ejecutivo de un proveedor, no una medición independiente de todo el mercado. Esa distinción no invalida su tesis. Sí implica que los lectores deben separar el argumento arquitectónico de las afirmaciones sobre el progreso de la industria.
El calendario exige especial cuidado. El lanzamiento de Tomahawk 5 de Broadcom se remonta al 16 de agosto de 2022, cuando la empresa anunció una capacidad de conmutación de 51,2 terabits. El siguiente anuncio llegó en junio de 2025, menos de tres años después.
Esas fechas no justifican tratar el intervalo entre los anuncios de chips como si fuera de casi cuatro años. Tampoco permiten establecer cuándo los sistemas completos estuvieron ampliamente disponibles o entraron en producción. El envío de silicio, la cualificación del equipo y el despliegue operativo representan hitos distintos.
Esta distinción cambia la pregunta que deberían formular los compradores. La cuestión no es simplemente si los fabricantes de switches están duplicando la capacidad. Es si los sistemas que pueden desplegarse aportan suficiente conectividad útil a las velocidades requeridas por la carga de trabajo prevista.
Un chip más rápido crea opciones de diseño. Los operadores pueden destinar su capacidad a conexiones más rápidas, más conexiones o una combinación de ambas. El empaquetado, el diseño del equipo y las configuraciones compatibles determinan qué opciones se convierten en productos prácticos.
Por consiguiente, un hito de ancho de banda debería iniciar una evaluación arquitectónica, no cerrarla. Los compradores deben vincular la especificación del chip con el equipo que pueden adquirir. Después, deben vincular ese equipo con el comportamiento de la aplicación.
La misma cautela se aplica a las afirmaciones de que las redes se han quedado irreversiblemente atrás respecto a la computación. No existe una proporción universal que describa todos los modelos, clústeres o despliegues. Algunas aplicaciones intercambian datos con frecuencia; otras mantienen más trabajo de forma local.
La conclusión defendible es más limitada y más útil. La capacidad de conmutación ha avanzado, mientras que la capacidad por sí sola sigue siendo una descripción incompleta de la infraestructura de IA. La presión surge cuando los requisitos de comunicación de la carga de trabajo superan la capacidad práctica de la red para atenderlos.
Los puertos más rápidos pueden absorber toda la ganancia de ancho de banda
Un switch puede ser más rápido sin conectar más aceleradores a la velocidad requerida.
La distinción crucial está entre el ancho de banda total y el radix, el número de conexiones independientes que un switch admite a una velocidad determinada. Ninguna cifra tiene sentido sin la otra. Un número alto de conexiones a una velocidad menor no describe la misma capacidad que ese número a una velocidad superior.
La aritmética explica por qué la escalabilidad del ancho de banda de los switches puede decepcionar a los planificadores de infraestructura. Si la capacidad agregada se duplica mientras que el ancho de banda requerido por conexión también se duplica, el número teórico de conexiones no cambia. Se trata de una relación condicional, no de una afirmación medida sobre todos los switches comercializados.
Esa relación importa porque las instalaciones de IA deben acomodar tanto la velocidad de comunicación como el tamaño del clúster. Satisfacer un requisito puede consumir los recursos destinados al otro. Los operadores no pueden asumir que una nueva generación de switches expande ambas dimensiones por igual.
Un conector físico añade otra complicación. No siempre corresponde a una conexión independiente de acelerador. El equipo puede combinar canales en enlaces más rápidos o dividir conexiones compatibles mediante configuraciones breakout.
Por tanto, los compradores necesitan conocer la configuración compatible, no solo una cifra destacada de conectores. También deben saber cuántas conexiones sirven a aceleradores y cuántas conectan switches. La capacidad asignada entre capas de conmutación no puede servir simultáneamente a un punto final.
Las especificaciones de Tomahawk 6 de Broadcom ilustran por qué importan los detalles de configuración. La empresa describe una red de dos niveles que admite más de 100.000 aceleradores a 200 gigabits por segundo por enlace. Se trata de una afirmación de diseño del proveedor vinculada a una velocidad de conexión declarada, no de una garantía universal para clústeres.
La cualificación de velocidad debe acompañar a la cifra de escala. Eliminarla hace que las comparaciones resulten engañosas. Un diseño que admite una gran población de puntos finales a una velocidad no puede admitir automáticamente la misma población a una velocidad mayor.
La misma disciplina se aplica a las capas de conmutación. Añadir otra capa puede ampliar una red, pero también introduce más equipos y conexiones. Que esa compensación sea aceptable depende del tráfico que la atraviese.
Una red más grande no es necesariamente más lenta en todos los sentidos útiles. Las rutas adicionales pueden proporcionar capacidad y resiliencia cuando el diseño y el software las aprovechan de forma eficaz. Del mismo modo, menos capas no garantizan un mejor rendimiento de las aplicaciones.
La limitación práctica es el patrón de comunicación que la red debe sostener. Un diseño podría gestionar bien el tráfico localizado y, al mismo tiempo, tener dificultades cuando las aplicaciones se comunican entre grupos distantes. El ancho de banda agregado puede ocultar esa diferencia.
Por eso, comparar generaciones de switches exige más que comprobar si la capacidad se duplicó. La comparación significativa mantiene constantes la velocidad de los puntos finales, la carga de trabajo, los requisitos de resiliencia y la topología. La topología es la disposición de los dispositivos y los enlaces.
Sin esas condiciones, la escalabilidad del ancho de banda de los switches puede parecer impresionante mientras el problema operativo permanece en gran medida sin cambios. Con ellas, los compradores pueden identificar qué parte del diseño se beneficia realmente.
La presión recae en los propietarios de clústeres antes que en los usuarios de aplicaciones
Las limitaciones de red se convierten en un problema operativo cuando la capacidad de computación pagada espera a la comunicación.
Considere un trabajo de entrenamiento distribuido, en el que varios aceleradores colaboran para actualizar un modelo. Cada acelerador realiza una parte del cálculo. En puntos determinados, los participantes intercambian información antes de continuar.
Una operación colectiva coordina ese intercambio entre un grupo de procesadores. All-reduce, por ejemplo, combina contribuciones y distribuye el resultado combinado. Su finalización depende de la comunicación que requiere el grupo.
La consecuencia importante es la coordinación. Un acelerador que termina su trabajo local no siempre puede avanzar de forma independiente. Una comunicación retrasada puede prolongar el tiempo antes de que se reanude el cálculo útil.
Esto no significa que las redes expliquen cada acelerador inactivo. La preparación de datos, el comportamiento del software, los límites de memoria y la planificación también pueden restringir el rendimiento. Atribuir toda la infrautilización a la red ocultaría el diagnóstico real.
Para el propietario de un clúster, la pregunta relevante es qué limitación controla la finalización del trabajo. Los switches más rápidos tienen un valor limitado cuando otro recurso determina el ritmo. A la inversa, los procesadores más rápidos aportan menos beneficios cuando la comunicación sigue estando en la ruta crítica.
Esto genera presión sobre la planificación de infraestructura. Los equipos de compras pueden adquirir aceleradores y redes mediante procesos separados, pero la aplicación los experimenta en conjunto. Un desajuste se hace visible durante la ejecución de la carga de trabajo, después de que las decisiones de equipamiento ya hayan limitado las soluciones disponibles.
La misma relación aparece en la inferencia, el proceso de ejecutar un modelo entrenado para generar un resultado. Cuando un modelo se distribuye entre aceleradores, la comunicación pasa a formar parte de la atención de la solicitud. Su importancia depende de cómo la aplicación divide el trabajo.
Los modelos de mezcla de expertos seleccionan componentes especializados del modelo para diferentes entradas. Cuando esos componentes residen en dispositivos distintos, el enrutamiento del trabajo entre ellos añade requisitos de comunicación. La disposición del despliegue determina cuánto tráfico cruza la red.
Otra disposición separa el prefill, que procesa un prompt de entrada, del decode, que genera la salida posterior. Mover el estado intermedio de atención del modelo entre esas etapas introduce un requisito de transferencia. Esa compensación puede ser valiosa, pero su valor depende en parte del comportamiento de la red.
Estos ejemplos explican por qué los cuellos de botella de las redes de IA deben evaluarse según la carga de trabajo. Los resultados de entrenamiento no pueden predecir automáticamente el rendimiento de inferencia. Una configuración optimizada para un patrón de comunicación puede comportarse de otra forma con otro.
Los usuarios de aplicaciones encuentran estas limitaciones de forma indirecta. Experimentan tiempos de finalización, consistencia del servicio y capacidad disponible, en lugar de especificaciones de switches. Por ello, los compradores empresariales necesitan pruebas de servicio que reflejen el uso que esperan realizar.
Los operadores de clústeres afrontan la obligación más inmediata: identificar dónde la comunicación limita el trabajo útil y decidir después si los cambios de hardware, software o ubicación lo resuelven. Aumentar el ancho de banda en todas partes es un sustituto costoso de comprender la limitación.
El cambio resultante en la planificación es concreto. Los requisitos de red deben formar parte del diseño de las cargas de trabajo y de las decisiones sobre las instalaciones antes de que las compras fijen la arquitectura. Esperar a que aparezca congestión visible deja menos opciones prácticas.
Más capacidad de conmutación no puede resolver todos los problemas de tráfico
Una red puede contener suficiente capacidad agregada y, aun así, dirigir el tráfico por las rutas equivocadas.
Piense en una red con varias rutas disponibles entre dispositivos que se comunican. Si las transferencias intensivas se concentran en la misma ruta, otra puede permanecer infrautilizada. Aumentar el ancho de banda total instalado no garantiza que el tráfico se distribuya de forma eficaz.
Aquí es donde las especificaciones de hardware se encuentran con el comportamiento del transporte: las reglas que usan los endpoints para enviar, confirmar y recuperar datos. Estas reglas influyen en la eficiencia con la que una aplicación utiliza las rutas disponibles. También determinan qué ocurre cuando la congestión o las pérdidas interrumpen la comunicación.
El trabajo publicado por Meta sobre su red de entrenamiento distribuido ofrece un ejemplo operativo. Sus ingenieros describieron desafíos de enrutamiento, coordinación con el software de comunicación y planificación que tiene en cuenta la topología de red. Su experiencia respalda la idea de tratar las redes como un sistema, y no como la compra de un switch.
RoCE, o acceso directo remoto a memoria sobre Ethernet convergente, permite a los dispositivos acceder a memoria remota a través de una red Ethernet. El relato de Meta describe cómo operar estas redes exigió cambios más allá de la velocidad bruta de los enlaces. La lección trata sobre integración, no sobre un respaldo universal de una configuración concreta.
La ubicación de los trabajos es una parte de esa integración. Mantener cerca, dentro de la red, los dispositivos que se comunican intensamente puede reducir el tráfico a través de enlaces limitados. Distribuirlos de otra manera puede aumentar la presión incluso cuando el número total de aceleradores se mantiene sin cambios.
Por consiguiente, las decisiones de planificación afectan a la calidad aparente del hardware. Un benchmark con una ubicación favorable puede producir resultados que desaparecen en condiciones de producción menos ordenadas. Los compradores deberían comprender esa distinción antes de considerar el rendimiento de un benchmark como un compromiso de servicio.
El diseño de transporte MetaRoCE de Meta, publicado el 24 de agosto de 2026, amplía el mismo debate. La empresa describe cómo traslada una mayor parte de la gestión de rutas a los endpoints de la red y admite paquetes que llegan fuera de orden. Informa de validaciones con hardware de red AMD Pensando.
Son resultados comunicados por la empresa, bajo las condiciones de prueba que declara. No establecen un comportamiento equivalente en todos los aceleradores, adaptadores o entornos de producción. Su importancia radica en que un gran operador está abordando los límites de red mediante el diseño del transporte junto con la infraestructura física.
Por tanto, Broadcom, Nvidia y Meta no deberían reducirse a una simple competición por la capacidad de los switches. Su trabajo abarca distintas partes del sistema de comunicación. Las mejoras de hardware y software pueden complementarse.
Para los compradores, esto complica las comparaciones entre proveedores, pero mejora las preguntas disponibles. ¿El rendimiento depende de un adaptador específico? ¿La biblioteca de comunicación requiere ajustes concretos? ¿Cómo se redistribuye el tráfico tras un fallo de enlace?
Estas preguntas conectan los cuellos de botella de las redes de IA con la responsabilidad operativa. Alguien debe mantener la configuración que ofrece el resultado prometido. Una función de rendimiento tiene un valor práctico limitado si el equipo de operaciones no puede observarla ni solucionar sus problemas.
La implicación más amplia es que el rendimiento de una aplicación no puede deducirse únicamente de la capacidad agregada. El enrutamiento eficaz, los endpoints compatibles y la ubicación de la carga de trabajo determinan qué parte de esa capacidad resulta útil. El silicio más rápido crea margen; el sistema decide cuán eficazmente se utiliza.
La integración óptica aborda la energía, pero plantea cuestiones operativas
Reducir el consumo energético de las comunicaciones es valioso, pero las afirmaciones de eficiencia necesitan límites claramente definidos.
Nvidia anunció switches de red fotónicos en marzo de 2025, incluidos productos Ethernet Spectrum-X e InfiniBand Quantum-X. Su anuncio situó la integración óptica en el centro de su estrategia de redes. Broadcom también describió opciones de integración óptica para Tomahawk 6.
La óptica coempaquetada coloca componentes ópticos cerca del chip del switch dentro de un paquete integrado. Este enfoque acorta parte de la ruta eléctrica que recorren las señales antes de convertirse en luz. Los proveedores lo presentan como una forma de mejorar la eficiencia de las comunicaciones de alta velocidad.
Esto aborda una parte importante del problema, pero no todas sus partes. Una conexión óptica más eficiente no resuelve por sí sola una mala ubicación del tráfico. Tampoco establece que una instalación completa use menos energía para obtener la misma producción de aplicaciones.
El límite de medición importa. Una comparación puede abarcar componentes ópticos, equipos de red o toda la instalación informática. Son afirmaciones distintas y deberían mantenerse separadas.
Del mismo modo, una mayor eficiencia de comunicación no se traduce automáticamente en una mejora equivalente de la aplicación. El resultado depende de cuánto tiempo dedica la aplicación a comunicarse. También depende de si otra restricción pasa a ser dominante tras mejorar las comunicaciones.
Se trata de una relación general de rendimiento, no de evidencia contra la integración óptica. Eliminar una restricción puede dejar expuesta otra. Los compradores necesitan saber qué mejora se mantiene al medirla a nivel de aplicación.
El diseño operativo introduce más preguntas. Los equipos con componentes integrados pueden cambiar los procedimientos de sustitución y la planificación de repuestos. Los detalles pertinentes dependen del sistema específico, por lo que las afirmaciones generales sobre mantenibilidad exigen cautela.
Un equipo de compras debería establecer qué componentes pueden sustituir los técnicos de forma independiente. También debería comprender el procedimiento para aislar una avería. Estos hechos afectan a cómo encaja una mejora de eficiencia en un entorno operativo.
Las comparaciones de fiabilidad requieren una disciplina similar. El comportamiento ante fallos de un componente y la disponibilidad del servicio están relacionados, pero son distintos. Las rutas redundantes y el software de recuperación pueden preservar el progreso de la aplicación incluso cuando fallan componentes individuales.
A la inversa, un componente muy fiable no garantiza un servicio ininterrumpido. Los errores de software, las equivocaciones de configuración y los fallos en otros puntos pueden seguir afectando a la aplicación. Evaluar el diseño completo evita que una métrica de fiabilidad limitada se convierta en una afirmación de servicio sin respaldo.
Por tanto, el ángulo escéptico más sólido tiene que ver con el alcance. La conmutación más rápida y la integración óptica resuelven problemas de ingeniería identificables. La evidencia debe mostrar cómo estas soluciones afectan a la carga de trabajo, la instalación y el proceso de mantenimiento que se está adquiriendo.
Ese estándar también se aplica a las predicciones sobre un muro permanente de red. Las restricciones pueden desplazarse a medida que cambian las aplicaciones, el software de transporte y los equipos. La pregunta útil es qué limitación domina el próximo despliegue, no si una tecnología gana indefinidamente.
Para los operadores, Broadcom Tomahawk 6 forma parte de esa evaluación como un avance concreto de hardware. Su valor depende del diseño que posibilita y de los resultados que ese diseño ofrece.
Observe los sistemas desplegables, los resultados de las cargas de trabajo y el comportamiento de recuperación
La próxima evidencia debería conectar la capacidad del producto con resultados operativos repetibles.
En los próximos meses, la primera señal será la disponibilidad de sistemas completos en configuraciones especificadas. Los anuncios de chips establecen progreso técnico, pero los compradores necesitan equipos que puedan calificar, instalar y mantener. La conexión entre esos hitos merece una cobertura explícita.
Para los sistemas Broadcom Tomahawk 6, las divulgaciones útiles identificarían velocidades de endpoint compatibles, cantidades de conexiones y topologías de red. Distinguirían las configuraciones disponibles de las opciones previstas. También explicarían qué funciones de software están listas para uso operativo.
Esa evidencia reforzaría el argumento de que una conmutación más reciente puede aliviar las restricciones actuales. Las brechas persistentes entre las capacidades anunciadas y los equipos cualificados lo debilitarían. Ningún resultado exige suponer que todos los operadores siguen el mismo calendario de despliegue.
La siguiente señal es el rendimiento de las cargas de trabajo en condiciones comparables. Una comparación útil mantiene constantes la aplicación y la configuración de aceleradores, al tiempo que identifica los cambios de red. De otro modo, las mejoras pueden proceder de cambios no relacionados en el software o el hardware de cómputo.
Las comparaciones de entrenamiento deberían informar sobre el comportamiento de finalización de la aplicación junto con las mediciones de comunicación. Las comparaciones de inferencia deberían describir las características de las solicitudes y las condiciones de servicio. Un resultado sin el contexto de su carga de trabajo ofrece orientación limitada para las compras.
La latencia de cola, es decir, los tiempos de finalización inusualmente lentos, también merece atención. El rendimiento medio puede ocultar retrasos que afectan al trabajo coordinado o a la experiencia del usuario. Los compradores necesitan saber si las mejoras se mantienen constantes bajo una demanda sostenida.
Los resultados sólidos mostrarían que la capacidad añadida o un transporte mejorado reducen una restricción significativa de la aplicación. Los resultados débiles mostrarían poco beneficio una vez que las condiciones operativas realistas entran en la comparación. Cualquiera de los dos hallazgos es más informativo que otro récord aislado de ancho de banda.
La señal final es el comportamiento de recuperación ante fallos y demanda mixta. Una red debería evaluarse cuando fallen enlaces, cambie el tráfico o compitan varias aplicaciones. Esas condiciones revelan si la arquitectura preserva trabajo útil más allá de una demostración cuidadosamente preparada.
Para el transporte impulsado por endpoints, la evidencia relevante incluye el hardware compatible y el comportamiento en distintas topologías de red. Para la integración óptica, incluye procedimientos de mantenimiento y continuidad del servicio durante problemas de componentes. Son extensiones prácticas de las afirmaciones técnicas, no preocupaciones independientes.
Los resultados de recuperación repetibles respaldarían la confianza en despliegues más grandes. La resolución de problemas difícil o un comportamiento inestable matizarían los beneficios aparentes de una mayor capacidad. El resultado importa porque los operadores deben respaldar el sistema durante toda su vida útil.
Los equipos de ingeniería deberían conservar las suposiciones detrás de cada comparación, incluida la ubicación de la carga de trabajo, la configuración de los equipos y las versiones de software. Una base de conocimiento de ingeniería con capacidad de búsqueda puede ayudar a mantener disponibles esas decisiones cuando cambian las condiciones de despliegue.
Antes de aprobar el próximo clúster, pida a los proveedores que demuestren la aplicación que pretende ejecutar en las condiciones en las que espera operar. Exija la configuración de conexión compatible, las suposiciones del software de comunicación y el comportamiento tras un fallo. Mantenga esos hallazgos vinculados a la decisión de compra, para que los equipos posteriores puedan distinguir un límite de diseño de un problema de configuración. Broadcom Tomahawk 6 establece que la capacidad de los switches está avanzando; sus criterios de aceptación deberían establecer si ese avance mejora el trabajo útil. Empiece por los requisitos de comunicación de la carga de trabajo, compare sistemas completos con ellos y haga que la preparación para el despliegue forme parte de la discusión sobre rendimiento. ¿Qué red puede sostener su aplicación cuando la instalación está ocupada, es imperfecta y funciona más allá del benchmark?
