Crie um cluster Kubernetes com GPUs para treinamento e inferência de IA

Construir um cluster Kubernetes com GPUs não é o mesmo que conectar GPUs a alguns nós de trabalho. Para treinamento e inferência de IA, o Kubernetes precisa expor aceleradores com segurança, alocar jobs nos nós certos, enfileirar capacidade escassa, manter conjuntos de dados e pesos de modelos próximos o suficiente da computação e informar aos operadores por que uma execução cara falhou.

A regra prática: construa o menor cluster Kubernetes com GPUs que valide a carga de trabalho e, em seguida, expanda somente depois que o agendador, os drivers, a rede, o armazenamento, a observabilidade e o modelo de custos tiverem passado nos testes de aceitação. Um cluster que não consegue explicar o tempo na fila, a utilização de GPU, o tempo de restauração de checkpoint e as causas de falha ainda não é infraestrutura de produção.

Este guia aborda a arquitetura e o modelo operacional de um cluster Kubernetes com GPUs usado para treinamento e inferência de IA. Ele cobre o design dos nós, a exposição de GPUs, o enfileiramento, APIs de carga de trabalho, observabilidade, um prático diagrama de cluster Kubernetes com GPUs, ferramentas de gerenciamento e as perguntas a fazer ao provedor antes de alugar ou reservar capacidade.

Se o produto precisa apenas das saídas do modelo, compare primeiro uma API de modelo ou uma opção de inferência gerenciada. Se você precisa de pesos personalizados, controle de posicionamento, serviço privado, treinamento distribuído ou propriedade de benchmarks reproduzíveis, um cluster Kubernetes com GPUs pode ser o plano de controle adequado.

Resposta rápida sobre cluster Kubernetes com GPUs

Um cluster Kubernetes com GPUs de produção tem seis camadas:

A principal questão de design não é "O Kubernetes pode executar GPUs?" Ele pode, com o plugin de dispositivo e a configuração de nó corretos. A questão mais difícil é se sua infraestrutura de IA: cluster Kubernetes com GPUs consegue manter as GPUs produtivas com dados reais, usuários reais, falhas reais e restrições orçamentárias reais.

Diagrama de cluster Kubernetes com GPUs

Use este diagrama de cluster Kubernetes com GPUs como modelo de revisão antes de escolher ferramentas:

                 desenvolvedores / CI / notebooks / tráfego de API
                                  |
                                  v
        +--------------------------------------------------+
        | plano de controle do Kubernetes                  |
        | servidor de API, agendador, RBAC, admissão, segredos |
        +--------------------------------------------------+
                                  |
                 +----------------+----------------+
                 |                                 |
                 v                                 v
        +------------------+              +------------------+
        | camada de filas  |              | complementos da   |
        | Kueue / Volcano  |              | plataforma        |
        | cotas, coortes,  |              | GPU Operator,     |
        | tipos de recurso |              | plugin de dispos.,|
        +------------------+              | exportador DCGM   |
                 |                        +------------------+
                 +----------------+----------------+
                                  |
                                  v
        +--------------------------------------------------+
        | pools de nós de trabalho com GPU                 |
        | H100/H200/B200/A100/L40S/etc., CPU, RAM, NVMe,   |
        | NICs, CUDA/runtime, rótulos, taints, topologia   |
        +--------------------------------------------------+
                 |                 |                 |
                 v                 v                 v
        jobs de treinamento  serviços de inferência   jobs em lote
        PyTorch/JAX          vLLM/SGLang/Triton       Ray/Kubeflow
                 \                 |                 /
                  \                |                /
                   v               v               v
        +--------------------------------------------------+
        | rede e caminho de dados                          |
        | rede de alta velocidade, armazenamento de objetos,|
        | FS compartilhado, cache de modelo, checkpoints,  |
        | logs, métricas, backups                          |
        +--------------------------------------------------+

Este diagrama é intencionalmente simples. Uma arquitetura real de cluster Kubernetes com GPUs adicionará balanceadores de carga, registros privados, limites de service mesh, IAM, armazenamentos de artefatos, rastreamento de experimentos e exportações de faturamento. A função do diagrama é forçar uma conversa: qual camada é responsável por cada modo de falha?

Etapa 1: decidir se o Kubernetes é o plano de controle de GPU adequado

O Kubernetes é uma ótima opção quando sua plataforma de IA precisa de implantação nativa de contêineres, automação orientada por API, namespaces multilocatários, endpoints de serviço, controles de políticas e integração com a observabilidade cloud-native existente.

Em geral, ele é adequado para:

• Serviços de inferência online que precisam de rollouts, limites de escalonamento automático, roteamento e verificações de integridade de serviços.
• Cargas de trabalho de inferência em lote ou de embeddings executadas como Jobs, cargas de trabalho do Ray ou operadores personalizados.
• Cargas de trabalho de ajuste fino e treinamento nas quais as equipes desejam infraestrutura compartilhada em vez de máquinas GPU individuais.
• Plataformas mistas nas quais notebooks, jobs de treinamento, serving de modelos e serviços de suporte compartilham o mesmo modelo operacional.
• Equipes que já executam Kubernetes e podem estender os sistemas existentes de identidade, CI/CD, registro, logging e políticas.

O Kubernetes pode ser a escolha inicial errada quando a equipe precisa apenas de acesso ocasional para pesquisa, jobs em lote pontuais no estilo HPC ou treinamento simples orientado por SSH. Nesses casos, Slurm, um serviço de treinamento gerenciado, um ambiente de notebook hospedado ou o aluguel direto de GPUs podem gerar trabalho útil mais rapidamente.

Antes de criar um cluster Kubernetes com GPUs, defina o limite da carga de trabalho:

Para um projeto de sistema mais abrangente, conecte este plano de implementação à sua análise de arquitetura de cluster de GPU: computação, rede, armazenamento e plano de controle devem ser projetados em conjunto.

Etapa 2: projetar pools de nós com GPU em torno dos perfis das cargas de trabalho

Um cluster Kubernetes com GPUs deve ter pools de nós deliberados, e não uma combinação aleatória de máquinas aceleradoras.

Para cada pool de nós, especifique:

• Modelo de GPU e tamanho da memória.
• GPUs por nó.
• Detalhes de topologia de PCIe, SXM, NVLink, NVSwitch ou outros, quando relevantes.
• Modelo de CPU, quantidade de CPUs, RAM e layout NUMA.
• Tamanho e throughput do NVMe local.
• Quantidade de NICs, velocidade das NICs e tipo de fabric.
• Imagem do SO, kernel, driver, CUDA, runtime de contêiner e processo de aplicação de patches.
• Labels, taints, tolerations e labels de topologia do Kubernetes.
• Se as cargas de trabalho usam GPUs completas, MIG, time-slicing ou outro modo de compartilhamento.

Mantenha as necessidades de treinamento e inferência separadas, a menos que haja uma forte razão para uni-las. O treinamento pode se preocupar principalmente com o desempenho de all-reduce, a largura de banda de checkpoints e o agendamento em grupo. A inferência online pode se preocupar mais com o tempo de inicialização a frio, a localidade do cache de modelos, a latência de cauda e a segurança de rollouts.

Um padrão útil para nomear pools de nós é:

gpu-pool:
  accelerator: h100-80gb
  topology: 8gpu-sxm-nvlink
  fabric: infiniband
  workload: distributed-training
  sharing: full-gpu

Esses labels não são apenas documentação. Eles se tornam seletores de agendamento, dimensões de cota, tags de custo e contexto de depuração.

Etapa 3: expor GPUs com o mecanismo Kubernetes adequado

O Kubernetes agenda GPUs por meio de mecanismos especializados de recursos. A base comum é um plugin de dispositivo do fornecedor que anuncia recursos de GPU ao kubelet para que os pods possam solicitá-los como recursos estendidos. O Kubernetes documenta o modelo de solicitação e as restrições de seleção de nós em seu guia de agendamento de GPUs. O plugin de dispositivo Kubernetes da NVIDIA é o caminho padrão para GPUs NVIDIA, e o NVIDIA GPU Operator empacota diversos componentes operacionais, incluindo gerenciamento de drivers e runtime, implantação do plugin de dispositivo, gerenciamento de MIG e telemetria de GPU.

Para muitas equipes, o primeiro caminho para produção é:

node image + kernel prerequisites
  -> NVIDIA driver and container runtime
  -> NVIDIA GPU Operator
  -> Kubernetes device plugin
  -> DCGM exporter metrics
  -> workload namespaces and quotas

A Alocação Dinâmica de Recursos do Kubernetes também é importante para equipes que avaliam um modelo mais avançado de alocação de dispositivos. O DRA é projetado em torno de reivindicações de recursos e classes de dispositivos, o que pode ser útil quando solicitações simples de recursos estendidos não expressam requisitos suficientes de posicionamento ou específicos de dispositivo. Trate-o como uma escolha deliberada de plataforma: o driver, a versão do Kubernetes, a API de carga de trabalho e a estratégia de observabilidade devem ser testados em conjunto.

A decisão prática é:

Não oculte essa camada das equipes de aplicação. Elas precisam saber se um pod recebe um acelerador inteiro, uma fatia MIG ou um dispositivo compartilhado por tempo, pois as premissas de desempenho e depuração mudam.

Etapa 4: adicione uma camada de fila antes que as equipes disputem GPUs

O agendador padrão do Kubernetes não é, por si só, uma fila completa de IA multi-tenant. As equipes de IA geralmente precisam de admissão de cargas de trabalho, compartilhamento justo, cotas, política de preempção e visibilidade sobre o motivo pelo qual os trabalhos estão aguardando.

O Kueue é o projeto nativo do Kubernetes a ser avaliado quando o enfileiramento de lotes e IA/ML é importante. Seus conceitos centrais incluem cargas de trabalho, filas locais, filas de cluster, coortes e variantes de recursos. Isso permite que as equipes de plataforma modelem pools escassos de GPUs e decidam quais trabalhos são admitidos quando os recursos estão disponíveis.

O Volcano é outra opção de agendamento em lote do Kubernetes para cargas de trabalho de IA, big data e estilo HPC. Seu agendador de gangue usa uma condição mínima de pods de tudo ou nada, que é útil avaliar para trabalhos distribuídos que, de outra forma, desperdiçariam GPUs parcialmente alocadas enquanto aguardam os pares.

Para uma infraestrutura de IA com cluster Kubernetes de GPU, defina por escrito a política de filas:

A política de filas é um mecanismo de controle de custos. Sem ela, a equipe mais insistente pode consumir a capacidade mais cara enquanto trabalhos menores aguardam ou são movidos para uma infraestrutura paralela não gerenciada.

Etapa 5: escolha APIs de carga de trabalho para treinamento e inferência

Um cluster Kubernetes de GPU é mais útil quando as equipes de aplicação podem enviar cargas de trabalho sem escrever manualmente especificações de pods de baixo nível todas as vezes.

Para treinamento, avalie:

• Jobs nativos do Kubernetes para execuções simples em um único nó.
• Kubeflow Trainer para fluxos de trabalho de treinamento distribuído entre frameworks.
• Ray e KubeRay para Python distribuído, inferência em lote e padrões de serving.
• Integração com Volcano ou Kueue quando forem necessários agendamento de gangue ou admissão em fila.
• Operadores personalizados somente quando a plataforma tiver padrões internos estáveis que ferramentas genéricas não cobrem.

Para inferência, avalie:

• Deployments ou StatefulSets para serviços simples.
• Contêineres de serving vLLM, SGLang, Triton ou TensorRT-LLM, dependendo do modelo e das metas de desempenho.
• KServe ou outra camada de serving de modelos quando as equipes precisarem de abstrações de ciclo de vida de modelos.
• Regras de escalabilidade horizontal e vertical com base na profundidade da fila, latência, memória de GPU e combinação de solicitações.
• Pools de nós separados para tráfego de produção sensível à latência e cargas de trabalho em lote.

Mantenha a API de carga de trabalho simples no início. Um modelo de Job limpo com rótulos, solicitações de recursos, montagens de armazenamento e exportação de logs é melhor do que uma plataforma complexa que ninguém consegue depurar.

Etapa 6: valide o caminho de rede e armazenamento

A diferença entre uma demonstração funcional e uma infraestrutura de IA com cluster Kubernetes de GPU em produção geralmente aparece nos testes de rede e armazenamento.

Para treinamento distribuído, valide:

• Posicionamento entre nós.
• Comportamento de all-reduce do NCCL em todos os nós pretendidos.
• Erros na malha, retransmissões, congestionamento e variação entre nós.
• Versões do driver, CUDA, NCCL e da imagem de contêiner.
• Desempenho após a instalação da imagem de contêiner de produção, não apenas em uma imagem de benchmark limpa.

Para armazenamento, valide:

• Tempo de preparação do conjunto de dados.
• Download dos pesos do modelo e aquecimento do cache.
• Frequência e duração da gravação de checkpoints.
• Tempo de restauração após falha de nó ou pod.
• Comportamento do sistema de arquivos compartilhado sob jobs simultâneos.
• Região do armazenamento de objetos, egress e regras de ciclo de vida.

Um teste mínimo de aceitação é assim:

1. Submit a queued training job with the production container.
2. Pull the real dataset sample and base model weights.
3. Run a multi-node communication benchmark if the workload is distributed.
4. Train or fine-tune for a fixed window.
5. Write a checkpoint, delete a pod, and restore from checkpoint.
6. Export GPU, network, storage, queue, and cost labels.
7. Compare useful work against the model/API or GPU rental baseline.

Esse teste deve ser executado antes de reservas longas ou compromissos de alto valor. É mais barato descobrir uma malha fraca ou um caminho lento de checkpoint durante um benchmark do que durante uma janela de lançamento.

Ferramentas de gerenciamento de clusters Kubernetes com GPUs

A expressão ferramentas de gerenciamento de clusters Kubernetes com GPUs abrange vários trabalhos diferentes. Não compre nem instale ferramentas antes de definir o trabalho que elas realizam.

Evite uma plataforma que apenas informe horas de GPU alocadas. Um gerenciamento útil mostra por que as GPUs ficaram ociosas, quais jobs com falha consumiram capacidade e se as saídas de inferência ou os marcos de treinamento justificaram o gasto.

Perguntas sobre clusters Kubernetes com GPUs da CoreWeave

Algumas equipes pesquisam por um cluster Kubernetes com GPUs da CoreWeave porque desejam acesso nativo do Kubernetes à capacidade de GPUs na nuvem, em vez de máquinas virtuais genéricas. Trate essa consulta modificada pelo provedor como um estímulo para a diligência prévia: para a CoreWeave ou qualquer provedor de nuvem de GPU semelhante, verifique o modelo exato de acesso ao Kubernetes, os controles de pool de nós, a compatibilidade de operadores, as exportações de cotas e o limite de suporte antes de comprometer workloads de produção.

Use a mesma diligência prévia para qualquer provedor:

O Kubernetes do provedor não elimina a necessidade de testes de aceitação. Ele muda quais camadas você opera diretamente e quais camadas você verifica por meio de evidências de nível de serviço.

Checklist de segurança e multilocação

Clusters de GPU frequentemente se tornam infraestrutura compartilhada rapidamente. A segurança precisa ser projetada antes que a segunda equipe comece a usar o cluster.

Controles mínimos:

• Namespace por equipe, ambiente ou limite de carga de trabalho.
• RBAC vinculado ao seu provedor de identidade.
• ResourceQuota e LimitRange para GPU, CPU, memória e armazenamento.
• Política explícita para pods privilegiados, montagens do host, rede do host e acesso a dispositivos.
• Gerenciamento e rotação de secrets.
• Política de registro privado de imagens, assinatura, varredura ou verificações de admissão.
• Política de rede para tráfego de saída, acesso a conjuntos de dados e limites de serviços.
• Logs de auditoria para envio de jobs, acesso a secrets, uso de imagens e ações administrativas.
• Regras de limpeza de dados para NVMe local, volumes temporários, checkpoints, logs e jobs com falha.

Se o cluster manipula dados de clientes ou pesos de modelos proprietários, trate os nós de trabalho como infraestrutura sensível. Um pod com acesso à GPU também pode ter acesso a dados de alto valor, artefatos de modelo e credenciais.

Observabilidade e modelo de custos

Um kubernetes gpu cluster de produção precisa de três visões ao mesmo tempo:

1. Visão da plataforma: integridade dos nós, integridade das GPUs, rede, armazenamento, estado da fila e eventos do Kubernetes.
2. Visão da carga de trabalho: proprietário do job, imagem, modelo, conjunto de dados, runtime, contagem de tentativas, motivo da saída e qualidade da saída.
3. Visão financeira: tempo de GPU alocado, tempo útil de GPU, tempo ocioso, custo de jobs com falha e custo por unidade aceita.

Acompanhe pelo menos:

• Utilização da GPU, memória da GPU, energia, temperatura e eventos de erro.
• Rótulos de pod, job, namespace, pool de nós, modelo e equipe.
• Tempo de espera na fila e motivo da admissão.
• Taxa de processamento do treinamento, duração do checkpoint e tempo de restauração.
• Latência de inferência, taxa de processamento, tamanho do lote, taxa de acerto de cache e taxa de erro.
• Taxa de processamento do armazenamento e tempo de transferência do armazenamento de objetos.
• Falhas de nós, remoções, preempções e tentativas.

Depois, normalize o custo:

effective_kubernetes_gpu_cluster_cost =
  (compute + network + storage + support + idle + failed_runs + operations)
  / accepted_workload_units

O denominador deve corresponder ao negócio: execuções de treinamento concluídas, saídas de modelo aceitas, jobs de geração de mídia, lotes de indexação ou solicitações de clientes. Para uma análise mais profunda de custos, use a planilha de TCO de cluster de GPU e compare com nuvem de GPU vs. API de modelo antes de expandir o cluster.

Checklist de implementação

Use isto como ordem de construção para a primeira etapa de produção:

Não escale de 8 GPUs para 80 GPUs até que este checklist seja rotineiro. Rotineiro é o objetivo: envio de jobs repetível, alocação previsível, recuperação de falhas conhecida, custo visível e responsabilidade clara.

Erros comuns

• Comprar capacidade de GPU antes de comprovar a movimentação de dados e a recuperação de checkpoints.
• Tratar o plugin de dispositivo como toda a plataforma.
• Misturar treinamento e inferência de produção no mesmo pool de nós sem regras de prioridade e isolamento.
• Permitir que cada equipe escreva especificações de pod exclusivas sem rótulos comuns.
• Acompanhar o tempo de GPU alocado, mas não o trabalho útil.
• Ignorar a política de filas até que o cluster já esteja sobrecarregado.
• Presumir que Kubernetes gerenciado significa infraestrutura de IA gerenciada.
• Executar benchmarks em uma imagem limpa e a produção em uma imagem diferente.
• Esquecer um caminho de saída para conjuntos de dados, pesos, checkpoints e logs.

Esses erros são caros porque consomem tempo escasso de GPU sem produzir trabalho aceito.

Perguntas frequentes

O que é um cluster Kubernetes com GPUs?

Um cluster Kubernetes com GPUs é um cluster Kubernetes com nós de trabalho compatíveis com GPU, exposição de dispositivos, política de agendamento, armazenamento, rede e observabilidade configurados para que pods e jobs possam usar aceleradores para treinamento, inferência, processamento em lote ou cargas de trabalho de pesquisa.

Preciso do NVIDIA GPU Operator?

Nem sempre, mas muitas plataformas Kubernetes com GPUs baseadas em NVIDIA o avaliam porque ele reúne componentes de driver, runtime, plugin de dispositivo, MIG e telemetria em um fluxo de trabalho gerenciado por operador. Alguns provedores gerenciados cuidam de partes dessa pilha para você; portanto, confirme o limite de responsabilidade antes de instalá-lo por conta própria.

O Kueue é necessário para um cluster Kubernetes com GPUs?

O Kueue não é necessário para todos os clusters, mas vale a pena avaliá-lo quando uma capacidade escassa de GPU é compartilhada entre equipes ou trabalhos de IA em lote. Sem uma camada de filas, os usuários frequentemente têm pouca visibilidade sobre por que os trabalhos aguardam ou por que as cotas são negadas.

O Kubernetes pode executar treinamento multinó?

Sim, mas o treinamento multinó exige mais do que o agendamento de GPUs. Você precisa de posicionamento, validação de rede de alta velocidade, contêineres compatíveis, pontos de verificação e, frequentemente, comportamento de filas ou agendamento em grupo. Teste o pool de nós exato e a imagem de produção antes de comprometer uma grande capacidade.

A inferência e o treinamento devem compartilhar o mesmo cluster de GPUs?

Podem, mas apenas com pools de nós, regras de prioridade, cotas e isolamento bem definidos. A inferência em produção normalmente tem requisitos de latência e disponibilidade que entram em conflito com grandes trabalhos de treinamento. Comece separadamente, a menos que você consiga comprovar a política compartilhada sob carga.

Quando devo usar uma API de modelo em vez de um cluster Kubernetes com GPUs?

Use primeiro uma API de modelo quando você precisa apenas das saídas do modelo, sua combinação de modelos muda com frequência, a utilização é baixa ou sua equipe não está pronta para operar drivers de GPU, filas, armazenamento, monitoramento e incidentes. Crie um cluster quando controle, privacidade, pesos personalizados ou a economia das cargas de trabalho justificarem a sobrecarga operacional.

Referências oficiais

• Kubernetes: Agendar GPUs
• Kubernetes: Plugins de dispositivo
• Kubernetes: Alocação dinâmica de recursos
• Kubernetes: Atribuir Pods a nós
• NVIDIA GPU Operator
• NVIDIA: Instalar o GPU Operator
• NVIDIA: Instalar o DCGM Exporter
• Conceitos do Kueue
• Agendamento em grupo do Volcano
• Visão geral do Kubeflow Trainer

Conclusão

Vale a pena criar um cluster Kubernetes com GPUs quando o Kubernetes oferece à sua infraestrutura de IA mais controle sobre posicionamento, repetibilidade, segurança, observabilidade e custo do que máquinas GPU improvisadas ou APIs gerenciadas. Comece com uma carga de trabalho restrita, comprove o pool de nós, exponha as GPUs adequadamente, adicione filas antes que a contenção comece e meça a produção útil em vez da mera alocação de GPUs.

Quando o cluster não consegue superar uma locação mais simples de GPU ou uma abordagem de modelo/API em termos de trabalho aceito, não o expanda. Quando consegue, o Kubernetes se torna o plano de controle que transforma aceleradores escassos em uma plataforma de IA compartilhada.