Por que testar antes de aceitar
Uma rede de cluster pode ligar e mesmo assim render menos do que deveria. Um cabo mal encaixado faz a porta subir em velocidade menor, um transceptor com defeito gera erros que obrigam a retransmitir dados, e uma configuração de Ethernet incompleta perde pacotes sob carga. Nada disso aparece até o primeiro treinamento ficar lento.
O roteiro abaixo é o que entregamos registrado em relatório. Ele usa ferramentas públicas, que a sua equipe pode repetir depois. As condições de cada teste e os critérios de aprovação de banda, latência e comunicação entre GPUs são definidos no projeto, antes da instalação, de acordo com o equipamento comprado.
1. Cada ligação na velocidade e largura certas
Primeiro se confere se todas as portas subiram na velocidade e na largura esperadas. Na InfiniBand, o ibdiagnet varre a rede inteira, aponta ligações abaixo da velocidade ou da largura máxima, lê os contadores de erro e mede a taxa de erro de bits de cada ligação. Ele também lê as informações dos cabos e transceptores instalados.
Critério de entrega: todas as ligações na velocidade e na largura do projeto, sem contadores de erro acima dos limites definidos no roteiro (os padrões da ferramenta ou os do projeto) e sem ligação apontada com taxa de erro alta.
2. Banda e latência entre pares de servidores
Depois se mede o desempenho entre servidores com o perftest, um conjunto de testes sobre a interface RDMA. Os mais usados são ib_write_bw para banda e ib_write_lat para latência. Medir vários pares, inclusive servidores ligados a folhas diferentes, mostra se o caminho pelas espinhas entrega o mesmo que o caminho dentro de uma folha.
Na InfiniBand, o gerenciador da subrede precisa estar ativo antes desses testes.
3. Comunicação entre GPUs
Em cluster de IA, o teste que mais se aproxima do uso real é o das operações coletivas entre GPUs. Os nccl-tests conferem o desempenho e a correção das operações da biblioteca NCCL, e o all_reduce_perf mede a operação que mais pesa no treinamento distribuído. Rodar primeiro dentro de um servidor e depois entre vários separa o que é rede do que é servidor.
4. Na Ethernet, filas e congestionamento
Em Ethernet com RDMA (RoCE), a configuração de filas e de congestionamento precisa ser a mesma de ponta a ponta, nos switches e nas placas, no modo que a solução escolhida recomenda. No modo sem perda, isso inclui controle de prioridade (PFC) e marcação de congestionamento (ECN). Nos switches com Cumulus Linux, por exemplo, um único comando aplica o modo sem perda, e a própria ferramenta mostra a prioridade, os limites de marcação e os buffers aplicados.
O teste confirma a configuração em todos os equipamentos e repete as medições de banda com várias transmissões simultâneas, a situação em que uma configuração incompleta começa a perder desempenho.
5. O relatório de entrega
O relatório reúne o mapa de portas, a saída do diagnóstico da rede, as medições de banda e latência por par, os resultados entre GPUs e as versões de firmware de cada equipamento. Ele vira a referência da rede: quando alguma coisa piorar meses depois, a comparação com a entrega mostra onde procurar.
Na sustentação, o monitoramento por time especializado 24/7 acompanha os mesmos contadores, e os testes são refeitos depois de cada troca de peça ou atualização de firmware.
Perguntas frequentes
Minha equipe consegue repetir os testes?
Sim. As ferramentas são públicas e o relatório traz os comandos e os resultados de referência, para comparar quando for preciso.
Com que frequência refazer os testes?
Depois de cada troca de peça, mudança de cabo ou atualização de firmware, e sempre que o desempenho cair. Na sustentação, os contadores de erro ficam sob acompanhamento contínuo.