Um rack de servidores GPU não é apenas um gabinete cheio de aceleradores. É um limite de implantação no qual a topologia de GPU, a malha de rede, o armazenamento, o gerenciamento, a alimentação, o resfriamento e o agendamento funcionam em conjunto — ou criam gargalos dispendiosos.
Para desenvolvedores de IA e engenheiros de infraestrutura de ML, a pergunta útil não é “Quantas GPUs cabem em um rack?” É: este rack consegue fornecer o comportamento de comunicação, caminho de dados e recuperação de que a carga de trabalho precisa? Este guia transforma essa pergunta em uma lista de verificação de arquitetura e um plano de aceitação na nuvem.
O que é um rack de servidores GPU?
Um rack de servidores GPU é um rack físico ou uma alocação em escala de rack gerenciada por um provedor que contém um ou mais servidores GPU, além dos componentes de rede, alimentação, resfriamento e gerenciamento necessários para operá-los. Em uma implantação na nuvem, talvez você não controle o gabinete em si, mas ainda deve perguntar quais partes da topologia são garantidas: GPUs por host, interconexão intra-host, malha entre hosts, caminho de armazenamento, domínio de manutenção e política de posicionamento.
Um único servidor GPU é um nó. Um rack de servidores GPU é o sistema em torno de vários nós. Um cluster de GPUs pode abranger um ou mais racks. Essas distinções são importantes porque um serviço de inferência pode ser limitado pela memória GPU e pelo caminho PCIe/NVLink de um único host, enquanto o treinamento distribuído ou a inferência em larga escala podem se tornar limitados pelos caminhos de rede e armazenamento entre hosts.
A arquitetura de referência BasePOD da NVIDIA ilustra a diferença: ela separa uma rede de computação InfiniBand, uma malha Ethernet de gerenciamento e armazenamento e uma rede de gerenciamento fora de banda. Seu projeto não precisa copiar essa arquitetura de referência, mas deve tornar os caminhos equivalentes explícitos antes de contratar capacidade. Arquitetura de referência NVIDIA DGX BasePOD
Arquitetura de rack de servidores GPU: os seis pontos a mapear
Comece com um diagrama do rack que mostre o posicionamento físico e os caminhos lógicos. Se um provedor não puder divulgar todos os componentes, registre o que é garantido e teste o restante durante a janela de aceitação.
| Camada | O que documentar | Por que altera os resultados |
|---|---|---|
| Nós de computação | Modelo de GPU, quantidade de GPUs por host, CPU/RAM, NVMe local, domínio de substituição | Define a capacidade de memória, a capacidade de pré-processamento no host e o raio de impacto de uma falha de nó. |
| Topologia intra-nó | Layout PCIe, disponibilidade de NVLink/NVSwitch, afinidade entre GPU e NIC | Determina se as GPUs em um host podem trocar dados com eficiência. |
| Malha entre nós | Tipo de rede, quantidade e velocidade de NICs, camada de switches, política de sobresubscrição, posicionamento no mesmo rack | Determina o comportamento da comunicação coletiva quando o trabalho sai de um servidor. |
| Caminho de armazenamento | Cache local, sistema de arquivos compartilhado ou armazenamento de objetos, destino dos checkpoints, caminho de rede | Evita que o carregamento de dados e a criação de checkpoints roubem tempo de computação. |
| Gerenciamento e controle | Acesso BMC/fora de banda, inventário, agendador, métricas, controle de mudanças | Torna um rack operável quando um host ou driver falha. |
| Envelope da instalação | Alocação de energia do rack, redundância de PDU, projeto de fluxo de ar ou resfriamento líquido, acesso para manutenção | Restringe a densidade sustentável e a manutenção — não apenas o que cabe mecanicamente. |
1. Trate a topologia como uma entrada da carga de trabalho
O número de GPUs é uma descrição incompleta da capacidade. Para um host, inspecione como as GPUs se conectam umas às outras e às NICs. Entre hosts, identifique se um trabalho permanecerá em um servidor, em um rack ou se cruzará racks. Registre a regra de posicionamento esperada na especificação da carga de trabalho, em vez de presumir que “oito GPUs” descreve a mesma máquina em todos os lugares.
O NCCL usa caminhos diretos ponto a ponto quando o CUDA informa que as GPUs relevantes podem acessar a memória umas das outras. A NVIDIA documenta nvidia-smi topo -p2p como uma forma de inspecionar o status ponto a ponto; use-o como entrada de validação, não como substituto de um benchmark de carga de trabalho. Orientações de solução de problemas de GPU do NCCL
2. Separe o tráfego de computação, dados e gerenciamento
Um rack de servidores GPU precisa de mais do que uma rede rápida de treinamento. Tráfego de gerenciamento, downloads de artefatos, telemetria, armazenamento compartilhado e acesso de usuários podem interferir no tráfego da carga de trabalho quando compartilham um caminho subdimensionado. Use caminhos lógicos ou físicos separados quando sua arquitetura exigir e, em seguida, defina qual caminho transporta cada um dos itens a seguir:
- comunicação coletiva e tráfego GPU-direct;
- downloads de imagens, pesos de modelos, conjuntos de dados e checkpoints;
- tráfego de Kubernetes, SSH, BMC, registros e monitoramento;
- saída para APIs, armazenamento de objetos ou serviços downstream.
Isso é particularmente importante para capacidade na nuvem: pergunte se os números de largura de banda descrevem a largura de banda entre hosts, o uplink do rack, o throughput de armazenamento ou um agregado de melhor esforço. Eles não são intercambiáveis.
3. Projete a alimentação e o resfriamento como restrições de capacidade
Não dimensione um rack de servidores GPU apenas com base em unidades de rack. Uma configuração que cabe mecanicamente pode ser restringida pela energia da instalação, redundância de PDU, direção do fluxo de ar, requisitos de resfriamento líquido, raio de curvatura dos cabos ou espaço livre para manutenção. A NVIDIA observa que os layouts de rack variam conforme a potência máxima local e a infraestrutura de resfriamento; use os documentos atuais do fornecedor do servidor e do provedor de colocation para a alocação real. Perguntas frequentes do NVIDIA DGX SuperPOD
Antes da implantação, solicite uma resposta por escrito para estas perguntas:
- Qual é o envelope de energia sustentada do rack e qual premissa de redundância está incluída?
- O projeto de resfriamento usa ar, líquido direto no chip, troca de calor pela porta traseira ou uma combinação?
- Qual componente aciona primeiro a limitação de desempenho ou um evento de manutenção: o host, a PDU, o switch de rede ou o circuito da instalação?
- Um técnico consegue realizar manutenção em um nó, cabo ou componente da porta traseira sem interromper a capacidade adjacente?
Se a implementação for somente em nuvem, traduza as mesmas perguntas para os termos do provedor: posicionamento de host dedicado, domínio de manutenção, política de substituição de host e se a alocação pode alterar a topologia após o provisionamento.
4. Dê ao agendador consciência do rack somente quando isso for útil
Os rótulos de rack são valiosos quando a carga de trabalho se importa com localidade ou domínios de falha. Um trabalho de treinamento distribuído pode preferir um posicionamento em um único rack antes de se expandir entre racks. Um serviço de inferência de alta disponibilidade pode deliberadamente distribuir réplicas entre racks ou hosts. Comece com um pequeno conjunto auditável de rótulos, como topology.rack, topology.host-class, topology.fabric e topology.failure-domain, e depois verifique se o posicionamento do agendador os segue.
Para Kubernetes, valide toda a pilha de software de GPU em relação ao sistema operacional, Kubernetes, driver, runtime e opção de implantação compatíveis — não apenas à versão do cluster. A matriz de suporte do GPU Operator da NVIDIA distingue bare metal, VMs com passagem direta de GPU e implantações vGPU, além de publicar detalhes de compatibilidade para ambientes compatíveis. Suporte de plataforma do NVIDIA GPU Operator
Como escolher um rack de servidores GPU para sua carga de trabalho
Use o resumo da carga de trabalho para decidir se você precisa de um único host de alta densidade, um rack ou um cluster com vários racks.
| Padrão de carga de trabalho | Geralmente priorizar | Pergunte ao provedor ou à equipe de plataforma |
|---|---|---|
| Ajuste fino ou inferência em um único nó | Memória de GPU, topologia intra-nó, armazenamento local, substituição confiável de host | Quais GPUs e interconexões estão conectadas a um host? Todas as GPUs necessárias podem ser alocadas juntas? |
| Treinamento distribuído | Posicionamento no mesmo rack, malha de rede, afinidade de NIC, throughput de checkpoint | O que é garantido para a rede entre hosts? Como o posicionamento entre racks é exposto ou evitado? |
| Inferência em vários nós | Latência de cauda, comunicação entre fragmentos do modelo, segurança de rollout, observabilidade | As réplicas podem ser distribuídas por domínio de falha enquanto os ranks paralelos ao modelo permanecem conscientes da topologia? |
| Cargas de trabalho em lote ou de renderização | Comportamento da fila, cache local, tratamento de interrupções, preparação de imagens/dados | Qual é a garantia de posicionamento e como os trabalhos interrompidos são recuperados? |
| Plataforma interna compartilhada | Isolamento, cota, política do agendador, visibilidade de capacidade, controle de mudanças | Como as partições de GPU, os limites de locatários, os drivers e as atualizações são governados? |
Para uma nova implementação, compare a decisão pelo rack com uma alternativa mais simples. Se o trabalho não exigir controle sobre topologia, localidade dos dados ou uma pilha de serving personalizada, uma API de modelo gerenciada pode ter menor carga operacional. Use esta comparação entre nuvem de GPU e API de modelo como parte da decisão, em vez de tratar um rack de servidores GPU como a resposta padrão.
Como avaliar o desempenho de um rack de servidores GPU
Não aceite um rack de servidores GPU com base apenas em um número de pico do acelerador. Crie um teste de aceitação curto que separe os principais caminhos de desempenho.
Etapa 1: Capture um inventário e uma linha de base da topologia
Para cada host alocado, colete a identidade da GPU, versões do driver e do CUDA, topologia GPU a GPU, afinidade GPU a NIC, layout NUMA da CPU, armazenamento local e interfaces de rede. Mantenha esse registro com a revisão da implementação. Ele fornece um ponto de comparação quando o desempenho muda após uma substituição de imagem, firmware, driver ou host.
nvidia-smi -L
nvidia-smi topo -m
nvidia-smi topo -p2p p
nvidia-smi topo -p2p n
Não altere as configurações de kernel, BIOS, IOMMU ou controle de acesso PCIe com base em uma lista de verificação genérica. A NVIDIA documenta o comportamento ponto a ponto sensível à configuração em sistemas Linux bare metal; use as configurações compatíveis com o servidor e a plataforma de nuvem que você realmente opera. Solução de problemas de topologia e ponto a ponto do NCCL
Etapa 2: Teste nos limites que importam
Execute testes representativos em três escopos:
- Nó único para validar a visibilidade da GPU e o caminho local NVLink/NVSwitch ou PCIe.
- Mesmo rack para validar o posicionamento entre hosts e a malha local.
- Entre racks para entender o caminho que seu agendador usará quando a capacidade se expandir ou ocorrer failover.
A orientação de testes NCCL da NVIDIA usa explicitamente execuções em nó único, rack único e vários racks para validar a visibilidade da GPU, a interconexão intra-nó, a malha entre nós e o posicionamento. Registre a latência e a largura de banda juntamente com o comando de teste, o digest da imagem de contêiner, a lista de nós e os rótulos de posicionamento para que um resultado possa ser reproduzido. Tutorial de validação NCCL
Etapa 3: Meça o caminho real da aplicação
Em seguida, execute a carga de trabalho que você pretende atender. Para treinamento, registre o tempo por etapa, espera por dados, tempo de comunicação coletiva, tempo de checkpoint e comportamento de recuperação. Para inferência, registre o tempo até o primeiro token, a taxa de transferência de saída, a latência de cauda, o atraso na fila, o comportamento do cache e as taxas de erro ou reinicialização. Mantenha o mesmo modelo, perfil de lote/concorrência, comprimento de contexto e estado de cache ao comparar alocações.
É assim que você diferencia um problema de GPU de um problema de dados, rede, agendador ou configuração.
Etapa 4: Teste uma falha planejada
Um rack operacional de servidores GPU precisa de um caminho de recuperação. Antes do tráfego de produção, verifique o que acontece quando um worker é drenado, um nó fica indisponível, um trabalho é preemptado ou um checkpoint precisa ser retomado em outro local. Confirme que os dados persistentes estão separados da computação substituível e que as credenciais, imagens e a observabilidade continuam funcionando no caminho de substituição.
Implante um rack de servidores GPU na nuvem: uma sequência prática
A implantação na nuvem altera o limite de controle, não o trabalho de engenharia. Você ainda precisa tornar visíveis as premissas de hardware e alocação.
- Defina o contrato da carga de trabalho. Especifique o tamanho do modelo, a contagem de GPUs, o requisito de memória, o SLO de latência ou taxa de transferência, a sensibilidade de rede, a fonte de dados, o local do checkpoint, a meta de disponibilidade e a restrição orçamentária.
- Escolha o limite de topologia. Decida se o trabalho deve permanecer em um host, um rack ou uma malha definida de vários racks. Trate isso como um requisito na solicitação ao provedor, e não como uma preferência informal.
- Peça uma planilha de alocação. Solicite classe de host, contagem de GPUs, interconexão de GPU, NICs, malha de rede, opções de armazenamento, garantia de alocação, política de manutenção e quaisquer metadados de topologia expostos ao seu agendador.
- Fixe o contrato de software. Registre o sistema operacional, kernel, driver NVIDIA, CUDA, runtime de contêiner, versão do Kubernetes, versão do GPU Operator, imagem do framework e digest da imagem da aplicação. Valide a combinação em relação à matriz de suporte antes da implantação.
- Crie uma janela de aceitação restrita. Execute testes de inventário, topologia, comunicação no mesmo nó/mesmo rack/entre racks, armazenamento, aplicação e recuperação antes de direcionar tráfego contínuo.
- Instrumente cada camada. Crie alertas separados para integridade da GPU, erros de malha, espera de armazenamento, espera do agendador, eventos térmicos ou de limitação e SLOs da aplicação. Uma única métrica de utilização não consegue explicar um incidente em escala de rack.
- Mantenha opções de saída e recuperação. Mantenha definições de imagens, configuração de infraestrutura, locais de dados persistentes, checkpoints e um plano de reversão independentes de uma alocação específica.
Para as partes dessa sequência no nível do host, consulte o guia de implantação de servidor GPU. Para a perspectiva do plano de controle e da malha multinó, consulte o guia de arquitetura de cluster GPU.
Checklist de aceitação de rack de servidores GPU
Use este checklist antes de aceitar um novo rack de servidores GPU, uma alocação dedicada na nuvem ou uma implantação de colocation.
- [ ] O contrato da carga de trabalho nomeia um limite de topologia: um host, mesmo rack ou vários racks.
- [ ] A planilha de alocação identifica a contagem de GPUs por host, a interconexão de aceleradores, NICs, a malha de rede e o caminho de armazenamento.
- [ ] Energia, refrigeração, redundância de PDU, requisitos de fluxo de ar ou refrigeração líquida e espaço para manutenção têm um responsável.
- [ ] As versões de GPU, driver, CUDA, kernel, runtime de contêiner e orquestração são registradas.
- [ ] O agendador expõe e respeita rótulos de alocação ou domínio de falha onde a carga de trabalho precisa deles.
- [ ] As saídas de topologia de inventário e
nvidia-smisão armazenadas para cada classe de host. - [ ] Os testes de comunicação abrangem alocações em nó único, mesmo rack e entre racks que o agendador de produção pode criar.
- [ ] O teste da aplicação usa uma fonte de dados e um perfil de carga de trabalho representativos.
- [ ] Os caminhos de checkpoint, drenagem de host, substituição e reversão são testados.
- [ ] Os relatórios de custo separam o tempo produtivo de GPU dos custos de inatividade, repetição, dados e suporte, sem contabilizar o mesmo tempo duas vezes. Para o modelo de custos mais amplo, comece por este guia de aluguel de GPU.
Perguntas frequentes
Um rack de servidores GPU é o mesmo que um cluster GPU?
Não. Um rack de servidores GPU descreve um limite de implantação físico ou gerenciado pelo provedor, em escala de rack. Um cluster GPU é um grupo lógico de nós que pode abranger parte de um rack, um rack completo ou vários racks. A diferença importa quando rede, armazenamento, domínios de falha e agendamento atravessam limites físicos.
Quantos servidores GPU cabem em um rack de servidores GPU?
Não há um número universal útil. A profundidade do servidor e as unidades de rack são apenas a primeira restrição. A resposta prática depende do consumo de energia do servidor, do projeto de refrigeração, da capacidade e redundância de PDU, do roteamento de cabos, do acesso para manutenção e da densidade aprovada da instalação. Valide a resposta em relação ao projeto exato de host, rack e data center que você usará.
Todo rack de servidores GPU precisa de InfiniBand?
Não. A malha apropriada depende da carga de trabalho e da topologia. Cargas de trabalho em um único host podem não precisar de uma malha de alto desempenho entre nós. Cargas de trabalho distribuídas devem ser testadas no caminho de rede que realmente usarão, incluindo alocação no mesmo rack e entre racks. Evite selecionar uma malha apenas com base em uma especificação de marketing.
O que devo testar antes de aceitar capacidade de rack GPU na nuvem?
Teste a alocação que você recebeu: inventário de hardware, topologia, afinidade entre GPU e NIC, comportamento do armazenamento local e compartilhado, comunicação em nó único, comunicação no mesmo rack, comunicação entre racks se isso for possível em produção, comportamento representativo da aplicação e recuperação após uma falha planejada.
Quando devo evitar operar um rack de servidores GPU?
Evite operações em escala de rack quando sua carga de trabalho não precisar do controle que elas fornecem. Se uma API de modelo gerenciada puder atender aos requisitos de modelo, latência, disponibilidade, privacidade e custo, ela poderá eliminar o trabalho com hardware, fabric, drivers, agendador e gerenciamento de capacidade. Faça essa comparação deliberadamente antes de se comprometer com um rack de servidores GPU.
Construa o rack em torno da carga de trabalho
Um rack de servidores GPU é bem-sucedido quando seu projeto físico e sua alocação na nuvem correspondem aos caminhos de comunicação, dados e recuperação da carga de trabalho. Torne a topologia explícita, separe as classes de tráfego que podem interferir umas nas outras, valide o desempenho nos escopos de nó único, mesmo rack e entre racks, e aceite a capacidade somente depois que a aplicação real e um caminho de falha tiverem sido testados.
Se o controle em nível de rack não for necessário, compare uma abordagem de API de modelo antes de assumir a carga operacional. Se for necessário, use este guia com o guia de servidores GPU, o guia de arquitetura de clusters GPU e a lista de verificação de custos de nuvem para GPU para transformar capacidade em uma implementação verificável.
