Confiabilidade de enlaces e monitoramento em fabrics de IA

Um job de treinamento é uma computação síncrona em milhares de GPUs: cada operação coletiva espera pelo enlace mais lento. Um transceptor oscilando não deixa um servidor um pouco mais lento — ele trava o job inteiro, e se falhar de vez o job reinicia a partir do último checkpoint. Por isso, as ópticas deixam de ser um componente e passam a ser um orçamento de confiabilidade. Esta página cobre a aritmética de falhas, as métricas que preveem problemas, como as fabrics monitoram e isolam enlaces ruins, e as práticas operacionais que mantêm as taxas de falha baixas.

Por que um enlace importa

Evento	Efeito no job de treinamento
Oscilação de enlace (segundos)	as operações coletivas entram em timeout ou são repetidas; o tempo de step tem picos; com NCCL/RCCL, uma parada longa o bastante aborta o job
Enlace em velocidade/largura reduzida	cada all-reduce fica no ritmo dele; o throughput de todo o cluster cai para a fração desse enlace
BER pré-FEC elevado, sem erros não corrigíveis	nada ainda — mas a margem acabou; na próxima tarde quente, ele oscila
Erros de FEC não corrigíveis	perda de pacotes → tempestades de retransmissão de RDMA → travamento
Falha total	reinício do job a partir do checkpoint: de minutos a uma hora de computação perdida em todo o cluster

O custo de um reinício de checkpoint em um job de mil GPUs é medido em GPU-horas; esse é o número a comparar com o preço de ópticas melhores e de um QA melhor.

Aritmética de falhas

A confiabilidade de um transceptor é expressa em FIT (falhas por 10⁹ horas-dispositivo) ou em MTBF.

Premissa	Valor
Pontas ópticas na fabric	4 000 (um cluster de dois níveis com 1 024 GPUs)
FIT por ponta (ópticas de 400G maduras, bem resfriadas)	200–500
Falhas totais esperadas por mês	4 000 × 350 × 10⁻⁹ × 720 h ≈ 1
Taxa observada de oscilação de enlace na prática	5–20× maior do que as falhas totais — sujeira, margem no limite, térmico, firmware

Ou seja, falhas totais são raras e previsíveis; oscilações e enlaces degradados predominam e são, em sua maioria, evitáveis — por isso o monitoramento e o QA se pagam sozinhos.

Métricas que preveem problemas

Métrica	Fonte	Saudável	Ação
BER pré-FEC por lane	CMIS VDM; contadores de FEC do host	< 10⁻⁷	> 10⁻⁶ subindo; > 10⁻⁵ agendar substituição
Codewords não corrigíveis de FEC	host	0	qualquer incremento = incidente
Erros de símbolo por lane	host (Ethernet) / `perfquery` (IB)	equilibrado, perto de zero	uma lane dominando
Potência de Rx por lane vs. baseline	DDM	a até 1 dB do dia um, lanes a até 2 dB uma da outra	−2 dB em relação à baseline
Tendência de bias de Tx	DDM	estável	+15–20 % em relação à baseline (Bias de Tx e envelhecimento)
Temperatura do módulo	DDM	< 60 °C	> 65 °C ou +10 °C em relação aos vizinhos
eSNR (CMIS)	VDM	> 18–20 dB	caindo em uma lane
Oscilações de enlace por porta	logs do switch, fabric manager	0	qualquer uma
Velocidade/largura negociada	switch / `ibstat`	plena	abaixo do nominal

Definições e formatos: Métricas de VDM e FEC, Monitoramento.

Arquitetura de monitoramento

Fabric	Coleta	Ferramentas
InfiniBand	o subnet/fabric manager consulta os contadores de cada porta e a EEPROM/DDM do cabo	gerenciadores classe UFM, `ibdiagnet`, `mlxlink -m`
Ethernet (RoCE)	streaming gNMI/OpenConfig do estado do transceptor e do FEC a cada 10–60 s; SNMP como reserva	gnmic → Prometheus/Grafana, telemetria do fabricante (Lendo DDM com ferramentas)
Lado do host	contadores da NIC: retransmissões, CNPs, fora de ordem; logs de NCCL/RCCL para timeouts	node exporters
Lado do job	variância do tempo de step, detecção de straggler	métricas do framework de treinamento

Correlacione os três: um pico no tempo de step às 14:05, uma excursão de BER pré-FEC na lane 3 do leaf 7 às 14:04 e um pico de temperatura de módulo no rack 12 formam um diagnóstico completo.

Isolamento e remediação

Desativação automática de porta / desvio de rota quando erros não corrigíveis ou oscilações ultrapassam um limiar — fabric managers e NOS têm suporte a políticas de erro de enlace; enquanto isso, o roteamento adaptativo desvia os fluxos de um enlace degradado.
Drene o nó se a porta da NIC dele for a culpada; agende o job contornando-o.
Leve o módulo para a bancada: identidade, DDM por lane comparado com a baseline do dia um, somas de verificação, versão de firmware (Check transceiver, DDM).
Limpe e reinspecione o MPO nos dois lados antes de culpar o módulo — sujeira é a causa mais comum (Incompatibilidades físicas).
Troque e observe: se os erros seguirem o módulo, abra um RMA; se ficarem com a porta, olhe a gaiola (cage), a fibra e a extremidade remota.

Práticas que reduzem a taxa de falhas

Prática	Efeito
Inspeção de entrada e burn-in (24–72 h sob carga e temperatura)	remove a mortalidade infantil antes que ela chegue a um job
Baseline de DDM por lane no dia um	transforma a exatidão absoluta (±3 dB) em deltas precisos
Manter os módulos < 60 °C — fluxo de ar, OSFP com aletas/plano corretamente, sem admissões bloqueadas	a vida útil dobra a cada −10 °C
Limpar cada conector a cada acoplamento; tampas nas portas não usadas	a maioria das oscilações é sujeira
Firmware atualizado em módulos e hosts	correções de interoperabilidade de CMIS (Problemas de CMIS)
Ópticas homogêneas e validadas por nível	menos surpresas de interoperabilidade de DSP entre host e módulo
Sobressalentes com burn-in e baseline feitos, 3–5 %	substituição sem um segundo incidente
Revisão semanal de tendências	substituir lasers envelhecidos por cronograma, não por falha

Para onde a tecnologia está indo

Taxas de lane mais altas (200G/lane, 1,6T) espremem ainda mais as margens; ópticas lineares (LPO) e co-packaged removem o DSP e o seu monitoramento — empurrando a visibilidade de BER para o host — ao mesmo tempo que prometem menos componentes e menos calor (Modulação e DSP, Ópticas em IA). Seja qual for o módulo, a disciplina continua a mesma: estabelecer baseline, monitorar deltas, agir sobre tendências.

No CodingBox

O CodingBox é a ponta de bancada desse ciclo: leituras de inspeção de entrada e de burn-in, baselines por lane do dia um armazenadas por número de série no code database, e leituras post-mortem de módulos retirados — identidade, firmware, somas de verificação e DDM comparados com o próprio histórico — para que as decisões de RMA se apoiem em dados, e não na última linha de log da porta.

Se você encontrar uma imprecisão ou um erro neste artigo, selecione o trecho correspondente e pressione Ctrl+Enter para .