Por que o Escalonamento Ciente de Topologia é Crucial para o GB200 NVL72
Modelos de IA modernos—especialmente LLMs de trilhões de parâmetros e arquiteturas mixture-of-experts—exigem comunicação massiva e de baixa latência entre GPUs. O NVIDIA GB200 NVL72 entrega poder de exascale em um único rack, com 72 GPUs Blackwell interconectadas via NVLink a 130 TB/s. Mas de que adianta hardware potente se o seu escalonador de jobs espalha as cargas de trabalho por domínios de rede desconexos?
Em clusters compartilhados, o escalonamento ingênuo (ex.: plugin cons_res padrão do Slurm) trata todos os nós como iguais, frequentemente fragmentando jobs entre switches. Isso causa degradação severa de desempenho: um job que poderia usar toda a largura de banda do NVLink acaba limitado por links inter-switch mais lentos. A solução é o escalonamento ciente de topologia, que alinha as alocações de jobs com a hierarquia física da rede.
A NVIDIA e a SchedMD colaboraram para introduzir o plugin topology/block no Slurm 23.11, feito sob medida para sistemas rack-scale como GB200 NVL72 e GB300 NVL72. Este post explica como ele funciona, como configurar tamanhos de segmento e o que os resultados de simulação revelam sobre os trade-offs de ocupação.
Entendendo o Plugin Block Topology
O plugin topology/block substitui a abordagem de 'melhor esforço' do antigo topology/tree por uma estratégia de alocação determinística em blocos. Ele agrupa nós em domínios NVLink (conjuntos de nós que podem se comunicar inteiramente via NVLink sem cruzar switches).
Parâmetros Chave
TopologyBlockSched: Habilita o escalonamento em blocos noslurm.conf.SwitchNames: Define os limites dos domínios (ex.:sw0para domínio 0).SegmentSize: Número de nós alocados contiguamente dentro de um domínio.
Exemplo de Configuração
# slurm.conf
TopologyPlugin=topology/block
TopologyBlockSched=yes
SwitchNames=sw0 Nodes=node[01-18]
SwitchNames=sw1 Nodes=node[19-36]
SwitchNames=sw2 Nodes=node[37-54]
SwitchNames=sw3 Nodes=node[55-72]
Quando um job solicita 32 GPUs (8 nós), o escalonador em blocos do Slurm tentará alocar todos os 8 nós dentro do mesmo domínio NVLink (ex.: sw0). Se não houver nós livres suficientes, ele recorrerá a domínios adjacentes, mas somente após esgotar as opções dentro do domínio.
Regras de Polegar para Tamanho de Segmento
| Tamanho do Job (GPUs) | Tamanho de Segmento Recomendado (Nós) | Exemplo de Carga de Trabalho |
|---|---|---|
| 128+ | 16 | Treinamento MoE |
| 32–64 | 4 | LLM denso grande |
| <32 | 1 | Fine-tuning, inferência |
Importante: Escolha tamanhos de segmento que sejam potências de dois para alinhamento ideal com a topologia NVLink. Tamanhos não potência de dois (ex.: 12 nós) podem funcionar, mas teste a eficiência da sua carga de trabalho específica.
Resultados da Simulação: Ocupação vs. Fragmentação
Construímos um simulador Slurm independente (acelerado no tempo, baseado em VM) para avaliar estratégias de escalonamento em um cluster GB200 NVL72 de 5.000 nós executando 15.000 jobs em 7 dias, com taxa de falha de nós de 2,5%.
Principais Descobertas
-
A fragmentação é mínima com
topology/block. Jobs pequenos (1–18 nós) tendem a se alocar nos últimos dois nós de cada domínio, deixando blocos contíguos maiores livres para jobs grandes. -
A penalidade de ocupação é de ~1% em comparação com uma linha de base teórica
noTopo(que ignora restrições de topologia). Isso significa que você pode alcançar utilização quase ótima sem sacrificar o desempenho. -
Jobs grandes se beneficiam mais. Jobs com ≥32 nós usando tamanho de segmento 16 apresentaram melhoria de até 2,6× na taxa de transferência de treinamento (de acordo com o MLPerf) em comparação com a alocação ingênua.
Política Recomendada: Large_Perf_Custom
- Jobs ≥32 nós → tamanho de segmento 16
- Jobs <32 nós → tamanho de segmento 2
- Monitore a fragmentação semanalmente; ajuste os tamanhos de segmento se mais de 10% dos domínios estiverem com fragmentação >50%
Limitações e Cuidados
- Não é bala de prata: Se seu cluster executa muitos jobs minúsculos (nó único), o plugin de blocos pode restringir demais e aumentar o tempo de fila. Nesses casos, considere uma política híbrida que relaxe as restrições de topologia para jobs com menos de 4 GPUs.
- Ajuste do tamanho do segmento exige experimentação: O tamanho ideal depende da estratégia de paralelismo do modelo (FSDP, TP, PP, EP). Use o simulador para validar antes de implantar em produção.
- Falhas de nó podem quebrar a continuidade do domínio: O plugin de blocos não rebalanceia automaticamente após falhas. Você precisa drenar ou substituir manualmente os nós com falha para manter a integridade do domínio.
Próximos Passos
- Atualize para o Slurm 23.11+ e habilite
topology/block. - Execute o framework de simulação (disponível no GitHub da NVIDIA) com o trace da sua carga de trabalho.
- Comece com tamanhos de segmento conservadores (potência de dois) e itere com base nos dados de monitoramento.
Para um mergulho mais profundo nos algoritmos de escalonamento de segmento, veja o post original no blog da NVIDIA.
Conclusão
O escalonamento ciente de topologia não é mais opcional para clusters de IA exascale. O NVIDIA GB200 NVL72, combinado com o plugin block topology do Slurm, oferece alto desempenho e alta utilização—desde que você configure os tamanhos de segmento com sabedoria. Nossas simulações mostram que a penalidade de ocupação das restrições de topologia pode ser reduzida para ~1%, tornando-se uma vitória clara para qualquer infraestrutura de IA séria.
Comece hoje: revise sua configuração do Slurm, modele sua carga de trabalho com o simulador e implante o escalonamento em blocos. Suas horas de GPU—e seus pesquisadores—agradecerão.