Las redes de Meta OCP 2026 ponen diseños abiertos a trabajar en clústeres de IA

Meta ha publicado sus presentaciones sobre redes para OCP, detallando su primer rack de red refrigerado por líquido y un impulso más amplio para conectar una infraestructura de IA cada vez más distribuida. Las redes de Meta OCP 2026 combinan nuevo hardware de conmutación, software de transporte y especificaciones compartidas. El desafío central consiste en hacer que esos componentes funcionen juntos entre distintos proveedores y entornos operativos.

El resumen de la compañía del 26 de octubre sigue al Open Compute Project Global Summit, celebrado del 12 al 15 de octubre en San José, California. Sus presentaciones sobre redes de IA describen la infraestructura que respalda Muse Wonder, Muse Spark y el superclúster Prometheus. Se trata de relatos de la empresa sobre su arquitectura, no de evaluaciones independientes de cada afirmación de rendimiento.

La tensión principal se da entre infraestructura reutilizable y el trabajo de integración que sigue siendo específico de cada implementación. NVIDIA ilustra por qué esa distinción importa. Suministra tecnología y colabora con Meta, al tiempo que participa en un mercado donde los proveedores compiten por ofrecer sistemas de IA completos. Las interfaces abiertas no eliminan esa competencia. Cambian dónde deben demostrar su valor los proveedores.

Las redes de Meta OCP 2026 se expanden más allá del switch

El anuncio de Meta importa porque aborda conjuntamente varios límites de la infraestructura de IA, en vez de presentar de forma aislada un switch más rápido.

Las redes scale-up conectan aceleradores dentro de un sistema estrechamente coordinado. Las redes scale-out conectan esos sistemas en clústeres más grandes. Las redes scale-across extienden las conexiones entre infraestructura distribuida en distintas ubicaciones. La cartera de Meta aborda los tres ámbitos, aunque sus componentes presentan diferentes niveles de implementación y desarrollo.

IcePack es el primer rack de redes refrigerado por líquido de Meta. Sus blades de switches IceCube ofrecen una capacidad de conmutación de 102,4 terabits por segundo, con 128 conexiones operando a 800 gigabits por segundo cada una. Meta identifica variantes que utilizan silicio de conmutación Broadcom Tomahawk 6C y NVIDIA Spectrum-6.

Ambas variantes ejecutan FBOSS, el sistema operativo de red de código abierto de Meta. Un sistema operativo de red gestiona cómo un switch reenvía tráfico y expone controles operativos. Utilizar software compartido entre variantes de hardware proporciona a Meta un punto de partida común para operar equipos de distintos proveedores.

La cartera de redes abiertas también incluye una arquitectura de clúster actualizada y conexiones basadas en Ethernet para los aceleradores propios de Meta. Estos anuncios amplían el debate desde las especificaciones de los equipos hasta el diseño de sistemas.

Esa distinción cambia la forma en que los compradores deberían interpretar la noticia. La capacidad anunciada de un switch describe una capacidad del equipo. No establece con qué rapidez termina un trabajo de entrenamiento, con qué frecuencia falla la infraestructura ni cuánto mantenimiento requiere intervención humana.

Por tanto, una evaluación útil separa el componente de su contexto operativo. Las preguntas relevantes incluyen cómo llega el tráfico al switch, cómo se desarrolla la congestión y cómo responden las aplicaciones cuando desaparece capacidad. La refrigeración y el mantenimiento también forman parte de esa evaluación.

Consideremos a un operador que elige entre variantes de switches. Un sistema operativo común ofrece una razón para investigar ambas opciones. No garantiza un comportamiento intercambiable bajo todas las cargas de trabajo, versiones de firmware o condiciones de fallo. La validación sigue determinando si una opción está lista para producción.

El mismo razonamiento se aplica a la refrigeración líquida. Admitir equipos más densos introduce dependencias relacionadas con la preparación de las instalaciones, la monitorización y los procedimientos de reparación. Un equipo de redes no puede evaluar el rack por completo al margen de las personas responsables del edificio.

Por tanto, las redes de Meta OCP 2026 se entienden mejor como una dirección de ingeniería coordinada. La empresa intenta hacer que el hardware de redes, el software y la infraestructura física evolucionen de forma conjunta. Los materiales públicos proporcionan un punto de partida técnico para evaluar esa dirección.

No demuestran que toda organización deba reproducir la arquitectura de Meta. La pregunta más útil es qué interfaces y prácticas operativas siguen siendo valiosas cuando cambia la infraestructura circundante.

La capacidad de IA distribuida presiona a operadores y socios de nube

Las organizaciones bajo presión inmediata son las responsables de convertir aceleradores disponibles en capacidad de entrenamiento fiable.

Meta describe Prometheus como un superclúster repartido entre edificios interconectados en New Albany, Ohio. Su informe del 19 de octubre afirma que la fase inicial está completa. La empresa distingue esa infraestructura ya implementada de su ambición de expandirse hasta aproximadamente un millón de GPU, procesadores utilizados para computación paralela.

Esa distinción evita una interpretación errónea habitual. El objetivo de diseño final de un clúster no equivale a su número actual de equipos. Del mismo modo, anunciar una expansión de infraestructura no establece cuándo todos los recursos previstos estarán disponibles para los equipos de entrenamiento.

El informe de Meta sobre la infraestructura de Prometheus afirma que su primera fase entrenó modelos fundacionales Muse. Informa de más del 85% de goodput para el preentrenamiento de Muse Wonder. El goodput mide el progreso útil del entrenamiento, en lugar de limitarse a indicar si los equipos están en funcionamiento.

Estas cifras son resultados operativos comunicados por Meta. No deberían convertirse en promesas de rendimiento para clústeres no relacionados. Su relevancia más amplia reside en la elección de la métrica: el trabajo útil importa más que el hardware instalado por sí solo.

Para los operadores de infraestructura, este enfoque cambia los criterios de aceptación. La disponibilidad de los equipos es necesaria, pero no responde a si una carga de trabajo distribuida avanza de forma consistente. Los equipos necesitan comprender las interrupciones, el comportamiento de recuperación y los retrasos de comunicación que dejan recursos de cómputo esperando.

Los proveedores de nube afrontan un desafío relacionado. Un cliente que incorpora una gran carga de trabajo distribuida necesita más que una colección de máquinas alquilables. Necesita un comportamiento predecible en las conexiones que unen esas máquinas.

Eso ejerce presión sobre ambas partes. Los proveedores deben explicar los límites de sus entornos. Los clientes deben especificar los patrones de comunicación que requieren sus cargas de trabajo. Ninguna de las dos partes se beneficia de tratar una demostración pequeña como evidencia suficiente para una implementación mayor.

Una decisión de compra ilustrativa vuelve concreto el asunto. Un equipo de entrenamiento podría encontrar capacidad disponible en varias ubicaciones. Antes de asignar un trabajo coordinado entre ellas, debe evaluar si la sobrecarga de comunicación supera el beneficio de aceleradores adicionales.

La respuesta depende del diseño de la carga de trabajo. Algunas tareas pueden dividirse en piezas relativamente independientes. Otras intercambian repetidamente resultados intermedios y esperan a los participantes más lentos. Disponer de más hardware no resuelve por sí solo esa dependencia.

Esto también explica por qué los anuncios de infraestructura importan a los equipos de productos de IA. En última instancia, la hoja de ruta de un modelo depende de capacidad de cómputo utilizable, incluso cuando los desarrolladores de aplicaciones nunca configuran un switch de red. Los retrasos en la validación pueden afectar qué experimentos pueden ejecutar los equipos.

Los compradores empresariales deberían evitar convertir esa relación en previsiones de producto sin respaldo. Las divulgaciones de Meta sobre redes no establecen futuros tiempos de respuesta de aplicaciones, fechas de lanzamiento de modelos ni disponibilidad para clientes. Muestran el esfuerzo de ingeniería que respalda el suministro de capacidad de IA.

La presión práctica es clara: los operadores y proveedores deben validar el sistema que pretenden entregar. El número de componentes y el ancho de banda nominal no pueden sustituir la evidencia sobre la carga de trabajo que ese sistema debe sostener.

Trasladar las decisiones de tráfico a los endpoints cambia la carga de ingeniería

La dirección arquitectónica de Meta desplaza más responsabilidad hacia los dispositivos que envían tráfico, haciendo que el comportamiento del transporte sea central para el diseño de la red.

MetaRoCE es el protocolo de transporte de Meta para acceso remoto directo a memoria, que permite a las máquinas intercambiar datos con una participación limitada del procesador. La empresa lo diseñó para cargas de trabajo de IA sobre Ethernet, una familia de tecnologías de red ampliamente utilizada.

Según el diseño de transporte para IA de Meta, MetaRoCE distribuye paquetes por múltiples rutas y acepta que lleguen en órdenes diferentes. Sus endpoints realizan seguimiento de rutas individuales y reaccionan ante congestión o fallos.

Este diseño importa porque distribuir paquetes crea un problema de recepción además de una oportunidad de enrutamiento. Si el tráfico recorre rutas con diferentes retrasos, su orden original de transmisión no tiene por qué coincidir con el orden de llegada. El transporte debe gestionar ese comportamiento de forma deliberada.

El enfoque declarado de Meta proporciona a los dispositivos emisores y receptores más información sobre el progreso de la comunicación. La empresa afirma que su protocolo está diseñado para tolerar pérdidas de paquetes sin exigir que la red pause el tráfico para preservar una operación sin pérdidas.

Se trata de afirmaciones arquitectónicas, no de un veredicto universal contra los transportes existentes. El valor de un enfoque depende de su implementación, carga de trabajo y condiciones operativas. La descripción de un protocolo establece el comportamiento previsto; las pruebas establecen cómo se comporta una implementación concreta.

El mecanismo más amplio es una redistribución de responsabilidades. En lugar de esperar que la red por sí sola preserve todas las condiciones que requieren las aplicaciones, los endpoints participan más activamente en la gestión de la comunicación. Esto puede ofrecer a un sistema formas adicionales de responder cuando las rutas se comportan de manera diferente.

También crea nuevas obligaciones. El software y hardware de los endpoints deben interpretar correctamente las señales. Los operadores necesitan visibilidad sobre las decisiones que toman esos endpoints. La resolución de problemas debe conectar lo que observó la red con lo que decidió el transporte.

Una conexión hipotética degradada muestra por qué esa visibilidad importa. Una aplicación se ralentiza, pero ningún enlace está completamente caído. La investigación debe distinguir la congestión de los problemas de equipo y determinar si el tráfico se alejó de la ruta afectada.

Una arquitectura puede exponer más opciones sin hacer que sean fáciles de diagnosticar. Los equipos que evalúen redes multipath al estilo de Meta deberían preguntarse cómo reconstruirían un fallo después de que ocurra. Un diagrama de diseño no responde a esa pregunta operativa.

También hay una secuencia de adopción que considerar. Una especificación publicada, una implementación de software y una implementación de hardware compatible son hitos diferentes. Las organizaciones deben identificar de cuál de esos hitos depende realmente una implementación propuesta.

Aquí es donde las comparaciones entre proveedores deberían mantenerse neutrales. NVIDIA, Broadcom, AMD y otros participantes aportan distintas combinaciones de silicio, software de redes y capacidades de integración de sistemas. Una interfaz abierta crea espacio para comparar implementaciones; no determina de antemano al ganador.

Para los compradores, la consecuencia útil es un proceso de evaluación más preciso. Pueden preguntar qué comportamientos están estandarizados, cuáles requieren extensiones del proveedor y cuáles dependen de la ingeniería del cliente. Eso es más informativo que elegir entre etiquetas amplias como abierto y propietario.

La orientación centrada en los endpoints es relevante porque cambia quién asume la responsabilidad de la corrección y la recuperación. Su éxito debe evaluarse a través del comportamiento observable de las aplicaciones, las implementaciones compatibles y procedimientos de diagnóstico claros.

Las interfaces abiertas aún plantean un problema de integración de plataforma

Una interfaz de reenvío compartida no estandariza automáticamente el equipamiento que rodea al chip de conmutación.

La iniciativa Open Switch Platform Architecture, u OSPA, aborda esa capa restante. Meta, Microsoft y Alibaba iniciaron el esfuerzo. OCP describe su especificación como una contribución en curso sometida a revisión, una salvedad importante al hablar de su estado.

La arquitectura de plataforma de conmutación abarca funciones como la gestión de energía, el inventario de equipos, la supervisión ambiental, el mantenimiento de firmware y los diagnósticos. Los protocolos de enrutamiento y la gestión del reenvío quedan fuera de su alcance declarado.

Ese límite es central para esta historia. Un switch debe hacer más que mover paquetes correctamente. Su software debe identificar los componentes conectados, supervisar temperaturas, gestionar actualizaciones y proporcionar información útil cuando algo falla.

Cuando esas interfaces difieren entre productos, adoptar equipos de otro proveedor puede requerir ingeniería adicional. La propuesta de OSPA consiste en hacer reutilizable una mayor parte de ese trabajo mediante una arquitectura de referencia común.

El beneficio potencial es directo. Si los operadores pueden reutilizar software y procedimientos de gestión, evaluar equipos alternativos depende menos de reconstruir la integración básica. Los proveedores pueden competir por la calidad de implementación mientras exponen interfaces operativas más predecibles.

Esto sigue siendo un beneficio propuesto, no un resultado demostrado en todo el mercado. Una especificación no determina cuántos productos la implementan, con qué fidelidad lo hacen ni cuánto tiempo de ingeniería ahorran los clientes.

Por tanto, el ángulo escéptico más sólido se refiere a la evidencia de implementación. Los equipos pueden afirmar compatibilidad mientras dejan sin documentar comportamientos importantes. Una evaluación significativa debe examinar las rutas de recuperación, los cambios de firmware y las condiciones anómalas junto con la operación habitual.

Pensemos en una actualización de firmware que falla a mitad del proceso. Las preguntas pertinentes incluyen si la recuperación funciona, qué componentes siguen siendo accesibles y qué información recibe el operador. Una especificación de interfaz ayuda a plantear esas preguntas, pero el hardware aún debe responderlas.

Esto importa especialmente en despliegues mixtos. Un modelo de gestión común tiene un valor limitado si cada plataforma requiere un manual operativo independiente para fallos rutinarios. La reutilización debe extenderse más allá de la puesta en marcha inicial, hasta el mantenimiento durante toda la vida útil del equipo.

OSPA también aporta una dimensión más práctica a la estrategia general de Meta. La empresa está abordando un trabajo que suele recibir menos atención que los anuncios de ancho de banda. La integración de plataforma determina si las opciones adicionales de hardware se convierten en opciones operativas utilizables.

Para los equipos de ingeniería que siguen estos cambios, la documentación debe preservar la distinción entre el comportamiento previsto y los resultados observados. Mantener los hallazgos de cualificación en una base de conocimientos con capacidad de búsqueda puede facilitar las comparaciones posteriores.

Esto resulta especialmente útil cuando el equipamiento, el firmware y las especificaciones evolucionan con calendarios distintos. Un resultado de una configuración anterior debe seguir siendo rastreable hasta esa configuración. De lo contrario, los equipos corren el riesgo de trasladar supuestos a despliegues donde ya no son aplicables.

La implicación comercial es condicional, pero concreta. Los proveedores que reducen el trabajo de integración y mantenimiento ofrecen a los compradores un motivo para considerarlos. Los compradores aún necesitan evidencia de que esa reducción se mantiene en condiciones operativas reales.

Ethernet Scale-Up cuestiona el límite de los sistemas integrados

El trabajo de Meta en Ethernet scale-up cuestiona un límite de diseño, pero no demuestra que todos los sistemas de aceleradores puedan utilizar la misma interconexión.

Ethernet for Scale-Up Networking, o ESUN, es una línea de trabajo de OCP centrada en la conmutación y el encapsulado Ethernet para sistemas de aceleradores estrechamente conectados. Su alcance incluye el comportamiento de red, no toda la pila de software y hardware que rodea a un acelerador.

El alcance de Ethernet scale-up de OCP separa explícitamente las funciones de red de las funciones de endpoint. Estas últimas incluyen aspectos estrechamente vinculados con la arquitectura del acelerador, como la partición de cargas de trabajo y el ordenamiento de memoria.

Esa separación limita lo que los lectores deberían inferir de la participación en la iniciativa. Un proveedor que respalda ESUN no está prometiendo necesariamente que todos los aceleradores, bibliotecas de comunicación y diseños de rack se volverán intercambiables.

Meta presenta Tahan, un switch basado en Ethernet para su sistema de entrenamiento MTIA 300, como parte de su orientación scale-up. MTIA es la familia de aceleradores desarrollados internamente por Meta. La empresa también analiza diseños futuros y el desarrollo continuo de estándares.

La distinción entre un sistema operativo y una arquitectura futura también importa aquí. El equipamiento actual aporta evidencia sobre una implementación concreta. Una vista previa describe un desarrollo previsto. Ninguno debe sustituirse silenciosamente por el otro.

NVIDIA ofrece una referencia competitiva útil sin convertir la historia en una simple rivalidad. La infraestructura de Meta utiliza tecnología de NVIDIA, mientras Meta también desarrolla sus propios aceleradores y participa en trabajos de redes compartidas. Estas relaciones pueden coexistir.

Para los compradores, la comparación importante es entre distintos modelos de integración. Un sistema estrechamente coordinado ofrece un conjunto establecido de combinaciones compatibles. Un diseño más modular ofrece opciones adicionales de componentes, junto con la responsabilidad de validar esas combinaciones.

Ningún modelo elimina las restricciones de ingeniería. Un sistema integrado aún necesita cualificación para la carga de trabajo del cliente. Un sistema modular aún necesita un acuerdo de soporte coherente cuando los fallos cruzan las fronteras entre proveedores.

Por tanto, la cuestión financiera debe incluir el esfuerzo de ingeniería, no solo la selección del equipo. Un grupo más amplio de proveedores tiene un valor práctico limitado si una organización no puede dar soporte a las combinaciones resultantes. A la inversa, una interfaz estandarizada puede ser valiosa incluso sin una sustitución inmediata de proveedores.

Puede ofrecer a un comprador una ruta de migración más clara, una prueba de aceptación más específica o una forma de comparar propuestas competidoras. Esos beneficios dependen de cuán completamente la interfaz capture el comportamiento que necesita el cliente.

Para los desarrolladores, las consecuencias aparecen en capas superiores de la pila. Las bibliotecas de comunicación y la colocación de cargas de trabajo determinan qué tan bien utilizan las aplicaciones las conexiones disponibles. Un estándar de red no puede elegir de forma independiente la mejor partición para cada modelo.

Por eso Ethernet scale-up merece atención como una vía de ingeniería, no como un resultado de mercado declarado. Su progreso debe medirse mediante sistemas compatibles, resultados de interoperabilidad y evidencia de cargas de trabajo. Los anuncios de participación por sí solos no pueden resolver esas cuestiones.

Las redes Meta OCP 2026 refuerzan el argumento para evaluar esa vía. No justifican asumir que todos los límites existentes entre sistemas han desaparecido.

Las próximas señales son especificaciones, implementaciones y evidencia operativa

La evidencia de seguimiento más útil conectará los diseños públicos con equipos y software que las organizaciones puedan evaluar por sí mismas.

La primera señal es el avance en las especificaciones. Durante los próximos meses, observe cómo la revisión de OSPA y el desarrollo de ESUN se traducen en requisitos de implementación más claros. El avance relevante es una mayor precisión sobre el comportamiento compatible y la conformidad.

Un documento revisado importa cuando resuelve una ambigüedad a la que se enfrentan los implementadores. Una lista más extensa de participantes importa menos si no aporta contribuciones técnicas correspondientes o productos compatibles. Los lectores deben distinguir el impulso organizativo del progreso de implementación.

Requisitos más claros reforzarían el argumento de Meta de que las interfaces compartidas pueden reducir el trabajo repetido. Una ambigüedad persistente debilitaría ese argumento, especialmente cuando los proveedores interpretan de forma distinta el mismo requisito.

La segunda señal es la disponibilidad de implementaciones. El resumen de Meta de octubre identifica una implementación MetaRoCE disponible en espacio de usuario y describe como próximo trabajo adicional de software. El software en espacio de usuario se ejecuta fuera del kernel del sistema operativo, lo que lo convierte en una categoría de implementación distinta.

Observe si el código disponible viene acompañado de documentación utilizable, pruebas y limitaciones claramente descritas. La existencia de un repositorio es una invitación a investigar. No equivale a un soporte amplio en producción.

Las implementaciones compatibles adicionales facilitarían la evaluación de la arquitectura en distintos entornos. Los retrasos o límites de soporte poco claros reducirían lo que las organizaciones externas pueden adoptar razonablemente, independientemente del atractivo del diseño subyacente.

La tercera señal es la evidencia operativa. Busque mediciones de cargas de trabajo que expliquen configuraciones, condiciones de fallo y comportamiento de recuperación. Las evaluaciones independientes añadirían una perspectiva que las presentaciones de las empresas no pueden aportar por sí solas.

La evidencia útil debe responder a una pregunta específica. ¿Mantiene un sistema el progreso de la aplicación cuando una conexión se degrada? ¿Pueden los operadores identificar el problema? ¿Sustituir un componente requiere cambios fuera de la interfaz prometida?

Los resultados que respondan a esas preguntas reforzarían el argumento práctico a favor de una infraestructura reutilizable. Los resultados que muestren un trabajo sustancial específico de cada despliegue revelarían dónde sigue incompleta la estandarización. Cualquiera de los dos resultados sería más informativo que otro titular sobre capacidad máxima.

Para los compradores empresariales, la acción inmediata es perfeccionar los criterios de evaluación. Pida a los proveedores que identifiquen las interfaces estandarizadas, las dependencias de implementación y las condiciones cubiertas por su validación. Exija una distinción clara entre productos disponibles y planes futuros.

Para los desarrolladores y equipos de producto de IA, la lección es seguir la infraestructura utilizable, no solo la capacidad anunciada. El progreso de las redes importa cuando amplía los experimentos y las cargas de trabajo que un equipo puede ejecutar de forma fiable.

Comience con la arquitectura publicada y siga la evidencia hasta las implementaciones, los informes de cualificación y el comportamiento de mantenimiento. Compare sistemas utilizando la carga de trabajo que realmente necesita operar. Mantenga los despliegues actuales separados de las vistas previas, y las mediciones de las empresas separadas de los hallazgos independientes. Las redes Meta OCP 2026 ofrecen una orientación detallada para una infraestructura de IA abierta; el siguiente paso útil es examinar qué partes se traducen en resultados operativos repetibles. Al revisar la próxima propuesta de proveedor o actualización técnica, formule una pregunta concreta: ¿qué interfaz documentada, implementación compatible o comportamiento medido hace que este sistema sea más fácil de desplegar y mantener en funcionamiento?