Arquitetura de Cluster GPU: Computação, Rede, Armazenamento e Plano de Controle

A arquitetura de cluster GPU é a forma de todo o sistema, não apenas a contagem de GPUs. Um cluster de produção precisa coordenar nós de computação, rede de alta velocidade, armazenamento, um scheduler, controles de acesso, telemetria e caminhos de recuperação antes de conseguir transformar aceleradores caros em execuções de treinamento úteis ou inferência confiável.

A questão prática é simples: sua equipe consegue mover dados, agendar jobs, recuperar falhas e medir custo rápido o suficiente para manter as GPUs ocupadas? Se não, um cluster com placas melhores ainda pode entregar uma economia pior do que um serviço gerenciado de GPU menor ou uma API de modelo.

Este guia oferece às equipes de plataforma de IA um modelo prático para gpu cluster architecture: o que pertence à camada de computação, o que a rede precisa comprovar, como armazenamento e checkpointing se encaixam, como Kubernetes ou Slurm se torna o plano de controle e o que testar antes de alugar ou comprar capacidade multinó.

A regra prática da Flatkey é começar pelo limite da carga de trabalho. Se o produto só precisa de saídas de modelo, avalie primeiro um caminho de GPU cloud vs model API. Se você precisa de pesos personalizados, controle de posicionamento, treinamento de longa duração ou infraestrutura privada de serving, então projete o cluster GPU em torno dos requisitos de computação, rede, armazenamento e plano de controle da carga de trabalho.

Resposta rápida sobre a arquitetura de cluster GPU

Um cluster GPU útil tem quatro planos:

Uma multi-node gpu cluster architecture tem sucesso quando esses planos são projetados juntos. Computação sem fabric é capacidade isolada. Fabric sem armazenamento apenas desloca gargalos. Kubernetes sem cota, telemetria e runbooks é apenas um mecanismo de lançamento.

Diagrama da arquitetura de cluster GPU

Use este diagrama como estrutura de revisão antes de comparar provedores ou aprovar o design de um rack.

                  usuários / CI / tráfego do produto / clientes de API
                                  |
                                  v
        +------------------------------------------------------+
        | plano de controle                                    |
        | agendador Kubernetes ou Slurm, filas, cotas,         |
        | segredos, acesso ao registry, política, telemetria,  |
        | cobrança                                             |
        +------------------------------------------------------+
              |                    |                    |
              v                    v                    v
   +-------------------+   +-------------------+   +-------------------+
   | nó de computação  |   | nó de computação  |   | nó de computação  |
   | GPU, CPU, RAM,    |   | GPU, CPU, RAM,    |   | GPU, CPU, RAM,    |
   | NVMe local, NICs  |   | NVMe local, NICs  |   | NVMe local, NICs  |
   +-------------------+   +-------------------+   +-------------------+
              \                  |                  /
               \                 |                 /
                v                v                v
        +------------------------------------------------------+
        | fabric de alta velocidade                           |
        | NVLink/NVSwitch dentro do nó; InfiniBand, RoCE, EFA,|
        | ou Ethernet entre nós; posicionamento e roteamento  |
        +------------------------------------------------------+
                                  |
                                  v
        +------------------------------------------------------+
        | armazenamento e caminho de dados                   |
        | object store, sistema de arquivos compartilhado,    |
        | scratch local, cache de modelo, checkpoints,        |
        | snapshots, backups                                  |
        +------------------------------------------------------+

Para um kubernetes gpu cluster architecture diagram, adicione os objetos específicos do Kubernetes ao redor do plano de controle:

administradores do cluster -> imagens de nó -> GPU Operator / plugin de dispositivo -> nós GPU
equipes de app         -> namespace -> cota -> fila de jobs -> Pod / Job / RayJob
finanças               -> labels -> exportação de uso -> custo por job / equipe / modelo
segurança              -> segredos -> política de imagem -> política de rede -> logs de auditoria

O diagrama é intencionalmente simples. O objetivo não é desenhar todos os serviços. O objetivo é detectar responsabilidades ausentes antes que o cluster se torne uma dependência de produção.

Comece pela carga de trabalho, não pelo rack

Antes de escolher Kubernetes, Slurm, uma reserva em nuvem ou um fornecedor bare-metal, escreva um resumo de uma página da carga de trabalho.

Se você não conseguir preencher esta tabela, ainda não assine um contrato longo de capacidade. Alugue uma fatia menor, execute benchmarks e transforme os logs no briefing de compras. O guia de aluguel de cluster GPU fornece a lista de verificação do lado da compra quando a forma da arquitetura estiver clara.

Plano de computação: nós GPU não são intercambiáveis

O plano de computação define o que uma tarefa pode realmente usar. Uma especificação completa de computação inclui mais do que "8x H100" ou "cluster B200".

Solicite:

• Modelo da GPU, tamanho da memória e PCIe versus SXM quando relevante.
• GPUs por nó e a topologia intra-nó.
• Modelo de CPU, quantidade de CPUs, RAM do sistema e layout NUMA.
• Capacidade de NVMe local e throughput esperado.
• Contagem de NICs, velocidade da NIC e se caminhos GPU-direct são suportados.
• Ciclo de vida do driver, CUDA, runtime de contêiner e imagem do sistema operacional.
• Política de MIG, vGPU, time-slicing ou alocação de GPU completa.
• Homogeneidade dos nós e política de substituição.

A topologia intra-nó importa porque oito GPUs em um servidor não são equivalentes a oito nós com GPU única. O design do nó define pressão de memória, gargalos de CPU, velocidade de staging local e o custo da comunicação entre nós.

A documentação do NVIDIA Kubernetes GPU Operator é útil aqui porque mostra como drivers, o NVIDIA Container Toolkit, o device plugin, a telemetria do DCGM e componentes relacionados podem ser gerenciados como uma pilha de cluster em vez de uma configuração pontual de nó. A documentação do Kubernetes device plugin explica o ponto de extensão geral usado para expor dispositivos de fornecedores como recursos agendáveis.

Plano de rede: prove a fabric com um benchmark

Treinamento multinó e serving de alto throughput dependem da rede. A especificação de um cluster deve declarar a fabric e o teste de aceitação, e não apenas o destaque de largura de banda.

Solicite:

• Detalhes de NVLink ou NVSwitch intra-nó.
• Design de InfiniBand, RoCE, EFA ou Ethernet entre nós.
• Contagem e velocidade da NIC por nó.
• Garantia de placement e domínio de falha.
• Relação de oversubscription.
• Suporte a GPUDirect RDMA quando relevante.
• Modelo de rede de contêiner e host.
• Observabilidade para erros de fabric, retransmissões, congestionamento e falhas de nós.

Use um teste de aceitação antes do início do compromisso:

teste de aceitação da rede:
  executar NCCL all_reduce em todos os nós alugados
  registrar largura de banda, latência, IDs dos nós, modelo da GPU, driver, CUDA, versão do NCCL
  repetir após instalar a imagem de contêiner de produção
  salvar logs e compará-los com a topologia informada pelo provedor

NVIDIA NCCL e os testes NCCL são referências padrão para validar o comportamento da comunicação coletiva em cargas de trabalho distribuídas de GPU. O ponto não é perseguir um único número de benchmark. O ponto é detectar nós incompatíveis, placement ruim, congestionamento da fabric ou drift de driver/contêiner antes que uma execução completa de treinamento falhe.

Para inferência, o teste de rede deve incluir o caminho real do tráfego: entrada de requisições, comunicação entre shards do modelo, comportamento do KV-cache quando relevante, fetches de storage e egress. Uma fabric de treinamento que parece forte isoladamente ainda pode produzir baixa latência para o usuário se a stack de serving cruzar limites de rede demais.

Plano de armazenamento: mantenha dados, pesos e checkpoints fora do caminho crítico

O armazenamento é onde muitos planos de arquitetura de cluster GPU se tornam caros. A cotação da GPU é visível. O caminho de dados geralmente fica oculto até a primeira execução em produção.

Projete o armazenamento em torno de quatro fluxos:

Para treinamento, throughput de checkpoints e tempo de restauração são preocupações de arquitetura, não detalhes de backup. Para inferência, o carregamento dos pesos do modelo, o aquecimento do cache local e o comportamento do volume persistente afetam o tempo de implantação e o tempo de failover.

A documentação do NVIDIA GPUDirect Storage é uma fonte útil quando a arquitetura exige um caminho de dados direto entre o armazenamento local ou remoto e a memória da GPU. Nem todo cluster precisa de GPUDirect Storage, mas as equipes que movem grandes conjuntos de dados ou checkpoints devem decidir explicitamente se a pilha de armazenamento é comum, otimizada ou um gargalo que elas aceitam.

Plano de controle: Kubernetes, Slurm, ou ambos?

O plano de controle transforma hardware em uma plataforma. Ele decide quem pode executar o quê, quando os jobs começam, como as falhas são repetidas e como as equipes entendem o uso.

Arquitetura de cluster GPU com Kubernetes

O Kubernetes se encaixa em plataformas GPU que precisam de implantação de serviços, namespaces multi-tenant, fluxos de trabalho nativos de contêiner, automação orientada por API, políticas e integração com observabilidade nativa da nuvem. Uma arquitetura de cluster GPU com Kubernetes em produção geralmente inclui:

• Imagens de nó e automação de bootstrap.
• Gerenciamento do GPU Operator ou de driver/device plugin específico do fornecedor.
• Device plugin ou Dynamic Resource Allocation para exposição da GPU.
• Namespaces, RBAC, secrets, política de pull de imagem e política de rede.
• Jobs, Deployments, RayJob, operadores de treinamento ou serviços de inferência.
• Kueue ou outra camada de enfileiramento quando a justiça em batch importa.
• Quotas por equipe, projeto, ambiente ou cliente.
• DCGM, Prometheus, logs, traces e rótulos de billing.
• Controles de admissão para imagens, workloads privilegiadas, montagens do host e compartilhamento de GPU.

Os device plugins do Kubernetes expõem GPUs como recursos estendidos. O Dynamic Resource Allocation do Kubernetes adiciona um modelo de recursos mais rico, baseado em claims, para dispositivos e outros recursos especializados. O Kueue adiciona conceitos de enfileiramento de jobs, como workloads, filas, cohorts e resource flavors para agendamento em batch e em IA/ML. Juntas, essas ferramentas podem transformar um pool de GPU em uma plataforma governada em vez de um conjunto de máquinas acessíveis por SSH.

Arquitetura de cluster GPU com Slurm

O Slurm se encaixa bem em muitos ambientes de HPC e pesquisa porque foi criado em torno de filas, partições, accounting, reservas e jobs em batch. A documentação de GRES do Slurm cobre recursos de GPU e como os jobs os solicitam.

O Slurm costuma ser uma boa opção quando:

• Os usuários enviam jobs de treinamento em batch.
• A política de fila é central.
• As equipes já têm experiência operacional em HPC.
• A carga de trabalho é menos orientada a serviços.
• MPI, testes NCCL e accounting em batch são primitivos operacionais familiares.

Algumas organizações usam ambos: Slurm para pesquisa e grandes filas de treinamento, Kubernetes para serviços de inferência e APIs de plataforma. Isso pode funcionar, mas somente se identidade, acesso a dados, observabilidade e alocação de custos forem projetados entre os dois sistemas.

Observabilidade e controles de custo pertencem ao primeiro desenho

Não adicione telemetria depois que o cluster estiver em produção. As perguntas que importam para engenharia e finanças são previsíveis:

• Quais jobs usaram quais GPUs?
• Qual namespace, equipe, cliente, modelo ou experimento gerou o gasto?
• Qual foi a utilização útil, e não apenas o tempo de GPU alocado?
• Quanto tempo foi gasto aguardando na fila?
• Quais falhas consumiram mais GPU-hours?
• Qual gargalo de armazenamento ou rede causou GPUs ociosas?
• Qual foi o custo por execução concluída ou saída aceita?

A telemetria mínima deve incluir:

• Utilização da GPU, utilização de memória, energia, temperatura e eventos ECC.
• Tempo de execução por job, tempo na fila, contagem de tentativas, motivo de saída e responsável.
• Saúde do fabric de rede e histórico de benchmarks.
• Throughput de armazenamento, latência, tempo de checkpoint e tempo de restauração.
• Eventos de alocação do scheduler e recusas de quota.
• Rótulos de billing ou exports de uso vinculados às unidades de negócio.

A linha de base do modelo/API da Flatkey é importante aqui. Se uma API de modelo gerenciado produz a mesma saída aceita com custo unitário mais claro e menor carga operacional, o cluster precisa superar essa linha de base depois que o tempo ocioso, as tentativas, o armazenamento e a mão de obra forem contabilizados.

Segurança, isolamento e design de acesso

Clusters de GPU frequentemente começam como projetos de engenharia e se tornam infraestrutura compartilhada. Trate o design de acesso como parte da arquitetura.

Defina:

• Fonte de autenticação e identidade.
• Isolamento por namespace, projeto ou conta.
• Política de SSH, se houver.
• Registry de imagens de contêiner, assinatura e varredura.
• Gerenciamento de secrets.
• Política de saída de rede.
• Exclusão de dados e limpeza após os jobs.
• Retenção de logs de auditoria.
• Acesso break-glass.
• Acesso de suporte do fornecedor e fluxo de trabalho de hands remotos.

Para clusters multi-tenant, decida se o compartilhamento de GPU é permitido. A alocação de GPU inteira é mais simples. MIG, vGPU ou time-slicing podem melhorar a utilização, mas também mudam as expectativas de isolamento, telemetria, agendamento e desempenho.

Dimensionamento do cluster: transformar a arquitetura em números

O dimensionamento deve ser orientado pela unidade útil:

required_gpu_capacity =
  target_work_completed_per_month
  / useful_work_per_gpu_month_after_failures_idle_and_retries

Em seguida, faça um teste de estresse:

Para um modelo de custos, conecte este artigo à sua planilha de TCO de cluster GPU:

effective_cluster_unit_cost =
  (compute + network + storage + support + operations + idle + retries)
  / accepted workload units

O denominador deve corresponder ao produto: execuções de treinamento concluídas, tokens de inferência aceitos, jobs de mídia gerados, atualizações de índice de busca ou solicitações de clientes.

Checklist de revisão da arquitetura

Use esta lista antes de aprovar um diagrama de arquitetura de cluster gpu multi node ou uma proposta de fornecedor.

Referências oficiais para manter abertas

Use a documentação oficial como checagem de fonte durante a revisão da arquitetura:

Trate isso como referências de arquitetura, e não como substituto para testes de aceitação no cluster exato que você vai executar.

Quando um cluster GPU é a arquitetura errada

Não construa nem reserve um cluster apenas porque o preço por hora de GPU parece atraente. Um cluster GPU direto pode ser a arquitetura errada quando:

• O produto só precisa de saídas do modelo.
• A combinação de modelos muda semanalmente.
• A equipe não consegue operar drivers, schedulers, storage, networking e incidentes.
• A carga de trabalho é intermitente e de baixa utilização.
• O movimento de dados domina a computação.
• A área de compras quer um compromisso de três anos antes de existir evidência de benchmark.
• O financeiro não consegue mapear o gasto do cluster às saídas aceitas.

Nesses casos, compare primeiro preços de aluguel de GPU em nuvem, GPU serverless ou uma API de modelo. A arquitetura certa é a que entrega saída aceita de forma confiável com o menor custo operacional total, não a que tem o maior inventário de aceleradores. Para uma varredura de mercado em nível de provedor, use a comparação de cloud GPU antes de solicitar cotações.

Consideração final

Uma arquitetura de cluster GPU sólida é um design de sistema: nós de computação que correspondem à carga de trabalho, uma malha de rede comprovada por benchmarks, armazenamento que não deixa as GPUs sem alimentação e um plano de controle que possa agendar, proteger, observar e fazer a cobrança pelo uso.

Para experimentos pequenos, comece com aluguel ou APIs gerenciadas. Para treinamento sério em vários nós ou inferência privada, use o diagrama e a lista de verificação acima antes de se comprometer com um provedor, rack ou reserva. O erro caro não é escolher Kubernetes em vez de Slurm, ou H100 em vez de H200. O erro caro é comprar capacidade de GPU antes que a arquitetura prove que consegue transformar essa capacidade em trabalho útil.