Rede de data center de computação de IA: quando as GPUs estão ociosas, geralmente é a rede
Você comprou os aceleradores e o gráfico de utilização continua na metade. Raramente são as placas — é um fabric que descarta pacotes na comunicação coletiva, e uma única perda faz o job inteiro esperar por uma retransmissão. Projetamos redes de cluster de IA conforme o job realmente se comporta: um fabric spine-leaf sem sobreassinatura, Ethernet sem perdas com RoCEv2, PFC e ECN ajustados para o seu cluster em vez de copiados de um guia, e um plano de gestão fora de banda que ainda responde quando o fabric não responde. Dimensionada honestamente de um único rack de 8 placas a uma implantação multissala — e orçada para as ópticas e NICs, não só para os switches.
Por que fabrics de IA falham de outro jeito
Quatro problemas que encontramos em quase todo cluster que nos procura:
As GPUs estão ociosas e ninguém sabe por quêA utilização fica na metade e o fornecedor diz que as placas estão bem. Geralmente estão. As placas estão esperando umas pelas outras, e o que as faz esperar é o fabric entre elas — que ninguém instrumentou, porque se assumiu que era encanamento.
Uma perda e a execução recomeçaUm job de treinamento não é um servidor web. Ele não degrada com elegância — uma perda durante uma operação coletiva trava todos os ranks até a retransmissão chegar, e no pior caso uma execução longa precisa recomeçar do último checkpoint. Horas de tempo de acelerador por um único quadro descartado.
Nunca se pediu isso à Ethernet comumA comunicação coletiva envia tudo de uma vez, para todos, em uma rajada. Um fabric projetado para tráfego médio de escritório responde a isso com buffer cheio e descarte — está se comportando exatamente como projetado, e esse é o problema.
Quando o fabric quebra, você não consegue entrarA gestão trafega pelo mesmo fabric que deveria consertar. Na noite em que ele congestiona, o console também fica inalcançável, e alguém dirige até o site para plugar numa porta de console — uma lição que todo mundo aprende exatamente uma vez.
Arquitetura: fabric spine-leaf sem perdas + gestão fora de banda
Um fabric plano e não bloqueante construído em torno de um requisito — não descarte o pacote:
Arquitetura desenhada pela AtlasCommTech seguindo práticas de projeto de nível operadora. Os rótulos do diagrama permanecem em inglês para clareza técnica.
Por que nós: nosso fundador passou 13 anos dentro do ecossistema de parceiros da Huawei entregando redes de operadora. É no mundo das operadoras que se aprende que um fabric é julgado pelo seu pior momento, não pela média — exatamente a disciplina de que um cluster de IA precisa, porque um job de treinamento é tão rápido quanto sua operação coletiva mais lenta.
Opções de equipamento
A solução é dimensionada primeiro conforme seus requisitos e orçamento — a mesma arquitetura pode ser entregue sobre as linhas de vários fabricantes. Ajudamos você a escolher pela disponibilidade de fornecimento no país de destino, pelo orçamento e pelos hábitos de operação da sua equipe.
Huawei — linhas de campus corporativo, WAN e segurançaEcossistema maduro com rede de serviço global.
ZTE e Wantong — linhas datacom comparáveisDireção custo-benefício; o fornecimento flui melhor em alguns mercados.
H3C — linhas de campus e data centerPortfólio de campus e data center amplamente implantado.
Switches industriais Atlas — camada de acesso em cenários industriaisNossa própria linha industrial — compatível com a camada núcleo de qualquer marca.
O que o projeto entrega
Seis coisas que um fabric de IA faz e que nunca se pedem a uma rede de data center comum:
Sem sobreassinatura no fabricCada leaf sobe para cada spine, e a capacidade de uplink corresponde ao que o leaf pode receber. Multiplexação estatística é uma premissa sobre tráfego médio — e uma operação coletiva é justamente a carga que se recusa a ser média.
Transporte sem perdas, ajustado e não copiadoRoCEv2 com PFC por classe de prioridade e marcação ECN, com limiares definidos para o tamanho e o tráfego do seu cluster. Uma configuração de PFC copiada de um guia não é sem perdas — é um deadlock esperando a semana certa.
Topologia plana, um salto entre leavesQualquer GPU alcança qualquer outra passando por exatamente um spine. A latência é uniforme, então o escalonador não precisa conhecer o cabeamento — e adicionar um rack não muda a distância de ninguém a ninguém.
Portas 100G / 400G de alta densidadeCada acelerador ganha sua própria porta de alta velocidade no leaf, porque uma porta compartilhada faz as placas enfileirarem-se antes mesmo de o fabric ver o tráfego. A velocidade da porta é escolhida pelo layout de NICs do seu nó, não por catálogo.
Um plano fora de banda que ainda respondeSwitches separados, cabeamento separado, endereçamento separado — alcançável exatamente quando o fabric não está. Você não depura um fabric congestionado através do fabric congestionado, e a noite em que se descobre isso não é a noite para aprender.
Instrumentado antes de ser culpadoContadores por fila, estatísticas de PFC e ECN e contadores de descarte exportados desde o primeiro dia. Quando o gráfico de utilização cai, a pergunta "foi a rede?" tem uma resposta em vez de uma discussão.
Três tamanhos, uma só lógica de projeto
Diga-nos a quantidade de placas, o layout dos nós e o que seus racks realmente conseguem alimentar e resfriar — o nível diz o formato do fabric:
Números em torno dos quais projetamos:
Cada acelerador tem sua própria porta de alta velocidade — o coletivo roda na velocidade do rank mais lento
Zero sobreassinatura entre leaf e spine — multiplexação estatística é uma premissa que esta carga quebra
Ópticas e NICs geralmente custam mais que os switches — um orçamento que conta só switches fica curto antes do primeiro job
| Nível de escala | Site típico | O que o projeto inclui |
|---|---|---|
| Rack único, a partir de 8 placas | Um nó ou alguns · um piloto ou um pequeno cluster de pesquisa · uma sala | Um par de switches leaf, sem camada spine alguma — nesse tamanho os leaves conversam diretamente e um spine é uma camada comprada para o diagrama. A configuração sem perdas e a gestão fora de banda permanecem, porque são o que faz disso um cluster em vez de oito computadores caros num rack. |
| Cluster de GPU médio | Vários racks em uma sala · jobs de treinamento em produção · um escalonador à frente | Um fabric spine-leaf completo sem sobreassinatura, um par de leaves por rack, RoCEv2 com PFC e ECN ajustados ao seu tráfego real e não a um template, um caminho de armazenamento separado para que as escritas de checkpoint não colidam com o tráfego de treinamento, um plano fora de banda completo e telemetria por fila exportada desde o início. |
| Implantação multissala | Mais racks do que uma sala consegue alimentar · vários salões ou prédios · trechos longos entre eles | Um fabric por sala com uma camada entre salas acima, as distâncias dos trechos ditando a escolha de ópticas e essa escolha ditando boa parte do orçamento, uma conversa sobre alocação de jobs com quem opera o escalonador para que um job não atravesse salas desnecessariamente, e uma checagem real de energia e refrigeração antes de desenhar a topologia — porque nesse tamanho é o prédio que decide o projeto, não o contrário. |
Funções dos equipamentos (categorias, não modelos)
A solução é construída a partir destas categorias de equipamento — a marca é escolhida com você na fase de projeto. Os modelos exatos dependem da quantidade de placas, do layout de NICs dos nós, das velocidades de porta e do país — por isso especificamos modelos depois da sua lista de requisitos, não antes.
| Função | O que faz |
|---|---|
| Switches leaf (acesso de rack) | Uma porta de alta velocidade por acelerador, buffers profundos o bastante para absorver uma rajada coletiva, e a configuração sem perdas que realmente a sustenta. Dimensionados pelo layout de NICs do seu nó, não pelo que cabe num diagrama de rack. |
| Switches spine (núcleo do fabric) | Dão a cada leaf um caminho de um salto até qualquer outro leaf, sem sobreassinatura. A densidade de portas aqui decide a quantos racks o cluster poderá crescer — por isso é dimensionada para o cluster ao qual você se dirige, não o de partida. |
| Ópticas e cabeamento | Cada enlace de alta velocidade precisa de dois transceivers e um cabo, e a conta chega a centenas rápido. Alcance, tipo de conector e distâncias entre racks decidem a escolha — e este item costuma ser maior que o dos switches, razão pela qual insistimos em dimensioná-lo cedo. |
| Switches de gestão fora de banda | Uma rede pequena, barata e separada que alcança cada porta de gestão da sala. É o equipamento menos interessante desta página e a primeira coisa pela qual você será grato — porque é o único caminho de entrada na noite em que o fabric é o problema. |
| Comutação do caminho de armazenamento | Escritas de checkpoint e leituras de dataset são em rajada à sua maneira, e colocá-las nas mesmas filas do tráfego de treinamento é como um fabric bem ajustado volta a descartar. Separadas por caminho ou por classe de prioridade, conforme a sua cadência de checkpoints. |
| Plataforma de telemetria / gestão | Exporta profundidade por fila, contagens de pause PFC, marcações ECN e descartes, para que uma queda de utilização possa ser atribuída em vez de debatida. Sem isso, a rede é culpada por padrão em toda reunião — e geralmente inocente de fato. |
Envie-nos a quantidade de placas, o layout de NICs dos nós, os limites de energia e refrigeração dos racks e sua cadência de checkpoints — a lista de modelos vem depois. Essa ordem mantém o projeto honesto.
Notas de projeto e limites honestos
Leia isto antes de assumir compromisso:
- Nesse tipo de rede, as ópticas e as NICs geralmente custam mais que os switches — não orce apenas switches. Cada enlace de alta velocidade precisa de dois transceivers e um cabo, e a conta chega a centenas rápido. Um orçamento montado a partir de uma cotação de switches ficará curto antes do primeiro job, e por um valor que ninguém vai querer explicar. Dimensionamos o conjunto na fase de projeto, para que o número chegue no plano.
- Energia e refrigeração decidem a topologia, não o contrário. Nessa densidade, o limite elétrico e térmico de um rack define quantos nós cabem nele, o que define quantos racks você precisa, o que define o fabric. Se sua instalação não consegue alimentar o layout, nenhum projeto de rede o salva — por isso a primeira pergunta que fazemos é sobre o seu rack, não sobre o seu switch.
- Um fabric sem perdas é ajustado, não ligado. Os limiares de PFC e ECN dependem do tamanho do seu cluster, do seu padrão de tráfego e das suas NICs, e uma configuração copiada do guia de outra pessoa pode ser pior que nenhuma — transforma um descarte em um travamento que se espalha. Orce horas de engenharia para ajuste e validação, não apenas dias de instalação.
- A política de licenciamento e a disponibilidade de produto diferem por marca e país de destino, e as ópticas de alta velocidade em especial têm sua própria realidade de fornecimento — os prazos de algumas velocidades de porta são medidos em meses, não semanas. Verificamos e confirmamos ambos para o seu país na fase de projeto, antes de qualquer compromisso, porque uma óptica que chega depois dos aceleradores é um rack de hardware ocioso.
- Se o seu problema de utilização não for a rede, diremos. Carregamento de dados, um escalonador que empacota mal os jobs, uma camada de armazenamento subdimensionada ou um modelo que simplesmente não paraleliza — no gráfico de utilização, tudo isso parece exatamente um problema de rede. Instrumentamos primeiro e concluímos depois — e se o fabric for inocente, esse achado é a entrega, não uma cotação de switches.
Perguntas frequentes
Qual a diferença em relação à sua solução de data center resiliente?
Você está comprando proteção contra uma falha diferente. A página de data center resiliente trata de sistemas de negócio permanecerem disponíveis: se um link, um switch ou uma sala cai, a aplicação continua atendendo usuários, e uma breve reconvergência é um resultado aceitável. Esta página trata de um job de treinamento não perder pacotes: nada falhou, tudo está no ar, e uma única perda sob comunicação coletiva ainda trava todos os ranks e pode custar horas. Um projeto otimiza sobreviver a uma falha; este otimiza um fabric que nunca descarta enquanto tudo funciona perfeitamente. Se você hospeda aplicações de negócio, aquela página é a sua.
A Ethernet realmente aguenta tráfego de treinamento de IA?
Sim, quando é configurada para ser sem perdas. A Ethernet simples lida com congestionamento descartando, o que serve para um servidor web e é fatal para uma operação coletiva. RoCEv2 com PFC e ECN muda esse comportamento: o fabric aplica contrapressão e marca congestionamento em vez de descartar. A palavra importante é "configurada" — não é o protocolo que torna o fabric sem perdas, é o ajuste, e o ajuste precisa corresponder ao seu cluster. Por isso tratamos a validação como parte da obra, e não como algo que o cliente faz depois.
Só temos um rack. Precisamos de camada spine?
Não, e não vamos lhe vender um. Com um único rack os leaves conversam diretamente e um spine adiciona custo, cabeamento, ópticas e latência em troca de um diagrama que parece um cluster de verdade. O que você ainda deve comprar nesse tamanho é a configuração sem perdas, uma porta de alta velocidade por acelerador e o plano fora de banda — é isso que transforma oito computadores caros em um cluster. O spine passa a valer o dinheiro quando você tem racks suficientes para o cabeamento direto entre leaves parar de escalar, e diremos quando você chegar lá.
Podemos provar que foi a rede antes de comprar qualquer coisa?
Essa é a pergunta certa para começar, e sim. Profundidade por fila, contagens de pause PFC, marcações ECN e contadores de descarte no fabric existente dirão se os aceleradores estão esperando a rede ou outra coisa — muitas vezes é carregamento de dados ou um escalonador que empacota mal os jobs, e os dois parecem idênticos num gráfico de utilização. Preferimos fazer essa medição com você e inocentar o fabric a lhe vender uma reconstrução que não conserta nada. Se a rede estiver bem, isso é um resultado — e mais barato que a alternativa.
Podemos começar pequeno e crescer o cluster depois?
Sim, e a maioria deveria — mas o crescimento precisa ser projetado agora, em exatamente dois lugares. A densidade de portas do spine decide a quantos racks o fabric chegará, e a energia e a refrigeração da sala decidem quantos racks o prédio permitirá. Ambos são difíceis de mudar depois e baratos de planejar hoje. Todo o resto — mais leaves, mais nós, mais ópticas — é adição, não redesenho. Diga-nos o cluster ao qual você se dirige, não só o de partida, e dimensionaremos essas duas coisas para o destino e o resto para hoje.
Envie-nos a quantidade de placas e os limites de energia dos seus racks
Um engenheiro responde com um projeto de fabric, uma contagem de ópticas e NICs e a lista de categorias de equipamento. Envie sua lista de requisitos — a lista de modelos vem depois.
Soluções relacionadas
Rede de transporte IP governamentalComo um cluster do setor público chega aos seus usuários: um anel de núcleo transportando cada órgão como VPN isolada, com QoS que protege o tráfego que importa.
Rede de manufatura inteligente (IT-OT)De onde vêm os dados de treinamento: um anel de TA zoneado em switches industriais e uma fronteira com política que deixa o MES ler a linha sem expô-la.
Rede de data center resilienteO outro problema do data center: sistemas de negócio permanecerem disponíveis diante de uma falha, em vez de um job de treinamento que nunca perde um pacote.