Óptica para clústeres IA: tejidos por rail y límites CPO
Los clústeres de GPU no escalan como las capas web. El tejido que los une falla de forma distinta, presupuesta de forma distinta y se compra de forma distinta.
Un pod de entrenamiento de 1024 GPU contiene aproximadamente dos mil módulos ópticos. A una tasa de falla de campo de unos pocos por ciento al año, son docenas de reemplazos de módulos anuales, y cada reemplazo es un evento de enlace que puede detener un trabajo de entrenamiento síncrono. Este es el hecho que replantea la interconexión óptica en clústeres de IA: la pregunta no es si la óptica es lo bastante rápida, es si el tejido puede absorber la tasa de falla que viene con el número de módulos.
Ese es un problema de diseño distinto de una red de centro de datos de frontend, donde un enlace flameante es absorbido por el enrutamiento y no lo nota nadie. También es por lo que los operadores de IA se preocupan por contadores de codewords corregidos y temperaturas de caja de una forma que parecería obsesiva en un equipo de escala web.
Por qué el tráfico de IA no se comporta como el tráfico de centro de datos
Tres propiedades de la comunicación colectiva dirigen cada decisión posterior.
| Propiedad | Qué hace a la capa óptica |
|---|---|
| Ráfagas sincronizadas | La utilización del enlace oscila de inactivo a saturado dentro de un paso. Un solo enlace lento se vuelve un rezagado que retrasa todo el colectivo |
| Matriz de tráfico consciente del rango | La topología puede emparejarse al patrón de tráfico en lugar del ancho de banda de bisección genérico, que es toda la premisa de la optimización por rail |
| Baja tolerancia a reintentos | Un paso reintentado cuesta más que un paso más lento. La calidad del enlace es una característica de throughput, no una casilla de cumplimiento |
El efecto rezagado, y por qué importan los márgenes FEC
En un all-reduce síncrono, cada rango espera al más lento. Un enlace corriendo a 1e-7 BER pre-FEC con corrección FEC pesada aún entrega datos correctos, pero su latencia efectiva tiembla a medida que sube la carga de corrección. A lo largo de un colectivo de 512 rangos, la probabilidad de que al menos un enlace esté en un minuto malo se acerca a uno.
Esta es la razón mecánica por la que los tejidos de IA se especifican con más margen óptico del que el estándar requiere. Un margen de potencia de 2 dB que una red de frontend llamaría generoso es, en un pod de IA, aproximadamente la diferencia entre un trabajo que termina y uno que se cuelga al 90%.
Topología: qué compra y qué cuesta la optimización por rail
La espina-hoja clásica conecta cualquier GPU con cualquier otra en dos saltos. La optimizada por rail conecta el índice de GPU n en todos los servidores al conmutador de rail n, de modo que los rangos que participan en un colectivo suelen estar a un salto de distancia.
Spine-leaf: GPU server -- leaf -- spine -- leaf -- GPU server
Rail-optimised: GPU0 of all servers -- rail-0 switch group
GPU1 of all servers -- rail-1 switch group
El beneficio es latencia y número de saltos para el tráfico que realmente domina. Los costes son reales y vale la pena enunciarlos.
La complejidad de cableado escala con el número de rail. Ocho rails por servidor significan ocho planos de tejido paralelos, cada uno con su propia disciplina de cableado, su propia convención de polaridad y su propio dominio de falla. El explicador de polaridad MPO se vuelve lectura obligatoria para el equipo de cableado en lugar de un documento de referencia.
Los dominios de falla se vuelven más estrechos y numerosos. Un rail caído degrada un conjunto específico de colectivos en lugar de todo el tejido. Eso es mejor para disponibilidad parcial y peor para el diagnóstico, porque el síntoma parece un problema de software.
La óptica por GPU sube. Cada puerto GPU es un módulo. La optimización por rail no crea puertos, pero sí elimina la suscripción excesiva que de otro modo te permitiría compartirlos, por lo que los pods optimizados por rail quedan en aproximadamente 1:1.
Suscripción excesiva: dónde 1:1 es realmente requerido
Los pods de entrenamiento denso necesitan tejidos sin bloqueo o casi sin bloqueo porque los colectivos están sincronizados por ancho de banda. La inferencia y el ajuste fino toleran 2:1 o 3:1 porque su tráfico es menos simétrico.
La consecuencia óptica es directa: un pod 3:1 usa un tercio de la óptica en la capa con suscripción excesiva. Elegir la proporción es por tanto una decisión de presupuesto óptico tanto como de rendimiento de red, y debe tomarse con el número de módulos sobre la mesa. La guía de selección 800G cubre cuánto cuestan esos módulos en potencia y refrigeración una vez fijo el conteo.
La escala de medios, con los números que la deciden
| Medio | Alcance a 800G | Potencia por puerto | Cuándo gana | Qué lo rompe |
|---|---|---|---|---|
| DAC pasivo | 1-2 m | ~0 W | Host mismo rack a ToR | Atenuación PAM4; rigidez de cable a alto número de líneas |
| AEC | 3-5 m | 4-8 W | En fila, rack a rack | Inconsistencia de firmware de redriver entre proveedores |
| LPO | 50-100 m | 8-10 W | Filas adyacentes, pods con restricción de potencia | El SerDes del host debe absorber la pérdida del canal; necesita emparejamiento validado |
| Óptica pluggable (DR8 / 2xFR4) | 100-500 m / 2 km | 12-16 W | Fila a fila, hoja a espina | Densidad de calor de jaula, diseño de flujo de aire |
| CPO | En el paquete | La más baja por bit | ASIC de conmutador de próxima generación | La óptica no es reemplazable en campo |
La regla de los 3 metros y sus excepciones
Por debajo de 3 m, el DAC casi siempre es correcto: cero potencia, sin óptica que falle, sin diagnósticos que monitorear. Entre 3 y 5 m, el AEC gana en potencia pero introduce un nuevo modo de falla, que es el redriver. Por encima de 5 m, la decisión es entre LPO y pluggables convencionales.
La excepción que vale la pena conocer: un pod que está limitado por potencia antes que por alcance pagará una prima por LPO incluso a distancias donde el DAC funcionaría, porque la restricción no es el cable, es la PDU. Las salas limitadas por potencia toman decisiones extrañas pero racionales.
LPO es una decisión de sistema, no de módulo
Las ópticas lineales pluggable eliminan el DSP y entregan el trabajo de ecualización al SerDes del host. La potencia del módulo se reduce aproximadamente a la mitad, que es toda la atracción. El coste es que el enlace ahora depende de que el SerDes del host tenga suficiente rango de ecualización para el canal específico, y de que el fabricante del conmutador haya validado esa combinación.
Esta es la razón por la que la adopción de LPO parece desigual: funciona bien donde host y canal son conocidos y validados juntos, y mal donde los módulos se obtienen independientemente del conmutador. Si tu proceso de adquisición trata la óptica como una mercancía comprada separada de los conmutadores, LPO te decepcionará.
La restricción real de CPO es la reparabilidad, no la potencia
Las ópticas co-empaquetadas entregan la mejor potencia por bit al eliminar por completo la interfaz pluggable. Los datos publicados de fiabilidad de campo en despliegues tempranos de CPO son genuinamente alentadores en el lado de la tasa de falla, porque eliminar conectores y manejo en campo elimina una gran parte de los modos de falla.
La restricción que queda es operacional: cuando falla un puerto CPO, reemplazas un conmutador, no un módulo. Para un pod con dos mil módulos, la desventaja del modelo pluggable es que los módulos fallan; su ventaja es que un técnico con un repuesto lo arregla en cuatro minutos. Si la ganancia de fiabilidad de CPO supera su granularidad de reparación depende de tu modelo de repuestos y tu ventana de mantenimiento, y aún no está resuelto por los datos.
Realidad térmica a 800G, expresada en vatios
Un chasis 800G de 64 puertos a 16 W por módulo lleva unos 1 kW de calor de óptica, llegando al panel frontal donde el flujo de aire es más débil. Este no es un detalle a cargo del equipo de instalaciones después de congelar el diseño; restringe qué factor de forma puedes usar. La comparación de factores de forma cubre por qué existe el volumen extra de OSFP.
Dos consecuencias prácticas para los pods de IA específicamente:
La densidad de rack y la potencia óptica se contradicen. Duplicar la densidad de GPU duplica el calor óptico en la misma huella, y el sistema de refrigeración que era adecuado a media densidad no lo es a densidad completa. Modela esto antes de fijar el diseño del rack.
El enrutamiento de jaula a jaula es un ítem de presupuesto óptico. Los ensamblajes MPO terminados de fábrica frente a pigtails terminados en campo difieren hasta en 0,5 dB de pérdida de inserción. En un presupuesto de clase DR de 1,9 dB eso es un cuarto del margen, gastado en una decisión de cableado que normalmente la toma quien contesta el teléfono primero. El recorrido del presupuesto de enlace tiene la aritmética.
Especificar un pod 800G en 2026
- Factor de forma: sigue la jaula nativa del fabricante del conmutador. OSFP donde la holgura térmica es la restricción vinculante, QSFP-DD800 donde la densidad de puerto lo es.
- PMD: DR8 para cableado estructurado MPO nuevo, 2xFR4 para plantas duplex existentes, clase VR8 o LPO solo para mismo rack con emparejamiento de host validado.
- Gestión: CMIS 4.0 o posterior, para que diagnósticos, clases de potencia y mapeo de líneas sean scriptables desde el día uno.
- Telemetría: conecta contadores de codewords corregidos y BER pre-FEC al programador del clúster. Trata un enlace que se degrada como un evento de mantenimiento en lugar de ruido, porque en un colectivo síncrono es una caída futura.
- Holgura: reserva capacidad de jaula y refrigeración para óptica de 200G por línea aunque hoy compres silicio de 100G por línea. El análisis de hoja de ruta 1.6T explica cuánto vale realmente esa holgura y dónde es especulativa.
- Repuestos: dimensiona el pool de repuestos contra el número de módulos, no contra el número de conmutadores. Un pod con 2000 módulos necesita un pool de repuestos dimensionado para fallas de módulos, y el pool debe ser una familia SKU para mantener comparables las líneas base de diagnóstico.
Fuentes
- IEEE 802.3df - las definiciones PMD 800G (SR8, DR8, 2FR4, 2LR4) detrás de la tabla de medios.
- IEEE P802.3dj - el trabajo de 200G por línea citado en la recomendación de holgura.
- OSFP MSA - envolvente térmica y mecánica para los módulos 800G OSFP discutidos.
- QSFP-DD MSA - extensiones térmicas QSFP-DD800 e interfaz de gestión CMIS.
- OIF - interfaces eléctricas CEI y los proyectos coherentes que definen los límites DCI.
- Ethernet Alliance - demostraciones de interoperabilidad multi-fabricante para óptica 800G y LPO.
Los conteos de módulos y cifras de potencia son estimaciones de planificación para hardware 2026. Los conteos de óptica a nivel de pod varían con la topología, la suscripción excesiva y el diseño de almacenamiento; calcúlalos para tu propio tejido en lugar de adoptar una regla general.
FAQ
- ¿Por qué los clústeres de IA prefieren topologías optimizadas por rail?
- El tráfico de comunicación colectiva es consciente del rango. La optimización por rail coloca el mismo índice de GPU a través de servidores en el mismo conmutador, dejando que la mayoría del tráfico complete en un salto y reduciendo la latencia de cola que detiene los pasos de entrenamiento síncrono.
- ¿Sigue siendo viable el DAC a 800G dentro de un rack?
- Apenas. El alcance del DAC 800G pasivo es de unos 1-2 m por la atenuación PAM4; los AEC lo extienden a unos 3-5 m con redrivers activos. Más allá, domina la óptica. La potencia es el intercambio: 12-16 W por módulo óptico contra 4-8 W de un AEC 800G.
- ¿Cuál es la diferencia práctica entre LPO y CPO hoy?
- LPO elimina el DSP del módulo, reduciendo aproximadamente a la mitad la potencia del módulo, pero requiere que el SerDes del host compense la pérdida del canal, lo que lo hace sensible a la calidad del host y del canal. CPO mueve la óptica al paquete del conmutador: mejor eficiencia de potencia, pero la óptica deja de ser reemplazable en campo.
- ¿Cuánta óptica necesita realmente un pod 800G de GPU?
- En un pod optimizado por rail sin bloqueo con un puerto 800G por GPU, el conteo de óptica es aproximadamente un módulo por GPU para el tejido más uno por GPU-equivalente para almacenamiento y gestión, así que un pod de 1024 GPU llega a unas 2000-2500 módulos antes de repuestos. Ese conteo, no el número de conmutadores, dirige el presupuesto de repuestos y tasa de falla.