Fiabilidad de enlaces y monitorización en fábricas de IA

Un trabajo de entrenamiento es un cómputo síncrono entre miles de GPU: cada operación colectiva espera al enlace más lento. Un transceptor intermitente no ralentiza un servidor en una fracción — detiene todo el trabajo, y si falla por completo el trabajo se reinicia desde el último checkpoint. La óptica deja entonces de ser un componente y pasa a ser un presupuesto de fiabilidad. Esta página cubre la aritmética del fallo, las métricas que predicen problemas, cómo los fabrics monitorizan y aíslan enlaces defectuosos, y las prácticas operativas que mantienen bajas las tasas de fallo.

Por qué importa un enlace

Evento	Efecto en un trabajo de entrenamiento
Caída intermitente del enlace (segundos)	los colectivos expiran o reintentan; el tiempo de paso se dispara; con NCCL/RCCL una parada suficientemente larga aborta el trabajo
Enlace a velocidad/ancho reducidos	cada all-reduce se marca por él; el rendimiento de todo el clúster cae a la proporción de ese enlace
BER pre-FEC elevado, sin no corregibles	todavía ninguno — pero el margen ha desaparecido; la próxima tarde calurosa falla de forma intermitente
Errores de FEC no corregibles	pérdida de paquetes → tormentas de retransmisión RDMA → parada
Fallo duro	reinicio del trabajo desde el checkpoint: minutos a una hora de cómputo perdido en todo el clúster

El coste de un reinicio desde checkpoint en un trabajo de mil GPU se mide en horas-GPU; ese es el número que hay que comparar con el precio de una mejor óptica y un mejor QA.

Aritmética del fallo

La fiabilidad de un transceptor se expresa en FIT (fallos por 10⁹ horas-dispositivo) o en MTBF.

Suposición	Valor
Extremos ópticos en el fabric	4 000 (un clúster de dos niveles de 1 024 GPU)
FIT por extremo (óptica de 400G madura, bien refrigerada)	200–500
Fallos duros esperados por mes	4 000 × 350 × 10⁻⁹ × 720 h ≈ 1
Tasa observada de caídas intermitentes en la práctica	de 5 a 20 veces superior a los fallos duros — suciedad, margen marginal, térmica, firmware

Así, los fallos duros son raros y predecibles; las caídas intermitentes y los enlaces degradados dominan y son en su mayoría evitables — por eso la monitorización y el QA se amortizan solos.

Métricas que predicen problemas

Métrica	Fuente	Saludable	Actuar
BER pre-FEC por carril	VDM de CMIS; contadores FEC del host	< 10⁻⁷	> 10⁻⁶ en aumento; > 10⁻⁵ programar sustitución
Codewords no corregibles de FEC	host	0	cualquier incremento = incidente
Errores de símbolo por carril	host (Ethernet) / `perfquery` (IB)	equilibrados, cercanos a cero	un carril que domina
Potencia Rx por carril frente a la línea base	DDM	dentro de 1 dB del primer día, carriles dentro de 2 dB entre sí	−2 dB respecto a la línea base
Tendencia del bias Tx	DDM	plana	+15–20 % respecto a la línea base (Bias Tx y envejecimiento del láser)
Temperatura del módulo	DDM	< 60 °C	> 65 °C o +10 °C respecto a los vecinos
eSNR (CMIS)	VDM	> 18–20 dB	cayendo en un carril
Caídas intermitentes por puerto	logs del switch, gestor de fabric	0	cualquiera
Velocidad/ancho negociados	switch / `ibstat`	completos	por debajo de lo nominal

Definiciones y formatos: Métricas VDM y FEC, Monitorización.

Arquitectura de monitorización

Fabric	Recolección	Herramientas
InfiniBand	el gestor de subred/fabric consulta los contadores de cada puerto y la EEPROM/DDM del cable	gestores de clase UFM, `ibdiagnet`, `mlxlink -m`
Ethernet (RoCE)	streaming gNMI/OpenConfig del estado del transceptor y del FEC cada 10–60 s; SNMP como respaldo	gnmic → Prometheus/Grafana, telemetría del fabricante (Leer DDM con herramientas)
Lado del host	contadores de NIC: retransmisiones, CNP, fuera de orden; logs de NCCL/RCCL para timeouts	node exporters
Lado del trabajo	varianza del tiempo de paso, detección de rezagados	métricas del framework de entrenamiento

Correlacione las tres: un pico en el tiempo de paso a las 14:05, una excursión del BER pre-FEC en el carril 3 del leaf 7 a las 14:04 y un pico de temperatura de módulo en el rack 12 es un diagnóstico completo.

Aislamiento y remediación

Deshabilitación automática de puerto / desvío de ruta cuando los errores no corregibles o las caídas intermitentes superan un umbral — los gestores de fabric y el NOS soportan políticas de error de enlace; el enrutamiento adaptativo desvía los flujos alrededor de un enlace degradado mientras tanto.
Vaciar el nodo si el puerto de su NIC es el culpable; programar el trabajo evitándolo.
Poner el módulo en el banco: identidad, DDM por carril frente a su línea base del primer día, sumas de comprobación, versión de firmware (Check transceiver, DDM).
Limpiar y reinspeccionar el MPO en ambos lados antes de culpar al módulo — la suciedad es la causa más común (Discrepancias físicas).
Sustituir y observar: si los errores siguen al módulo, devuélvalo (RMA); si se quedan en el puerto, revise la jaula, la fibra y el extremo remoto.

Prácticas que reducen la tasa de fallo

Práctica	Efecto
Inspección de entrada y rodaje (burn-in) (24–72 h bajo carga y temperatura)	elimina la mortalidad infantil antes de que llegue a un trabajo
Línea base de DDM por carril el primer día	convierte la precisión absoluta (±3 dB) en deltas precisos
Mantener los módulos < 60 °C — ventilación, OSFP con aletas/plano correctamente, sin admisiones bloqueadas	la vida útil se duplica por cada −10 °C
Limpiar cada conector en cada acoplamiento; tapas en puertos sin uso	la mayoría de las caídas intermitentes son suciedad
Firmware al día en módulos y hosts	correcciones de interoperabilidad de CMIS (Problemas de CMIS)
Óptica homogénea y validada por nivel	menos sorpresas de interoperabilidad DSP host/módulo
Repuestos rodados (burned-in) y con línea base, 3–5 %	sustitución sin un segundo incidente
Revisión de tendencias semanal	sustituir láseres envejecidos según calendario, no tras el fallo

Hacia dónde va la tecnología

Velocidades por carril más altas (200G/carril, 1,6T) reducen aún más los márgenes; la óptica lineal (LPO) y la óptica coempaquetada eliminan el DSP y su monitorización — desplazando la visibilidad del BER al host — a la vez que prometen menos componentes y menos calor (Modulación y DSP, Óptica en IA). Sea cual sea el módulo, la disciplina se mantiene: establecer línea base, monitorizar deltas, actuar sobre las tendencias.

En CodingBox

CodingBox es el extremo de banco de este ciclo: lecturas de inspección de entrada y rodaje, líneas base por carril del primer día almacenadas por número de serie en la base de datos de códigos, y lecturas post mortem de módulos retirados — identidad, firmware, sumas de comprobación y DDM comparados con su propio historial — de modo que las decisiones de RMA se apoyen en datos y no en la última línea de log del puerto.

Si encuentra una inexactitud o un error en este material, seleccione el fragmento correspondiente y pulse Ctrl+Enter para .