Uma «fábrica de IA» não consiste em um único modelo ou cluster Kubernetes, mas em uma frota compartilhada de unidades de processamento gráfico (GPU) utilizada simultaneamente por equipes para diferentes finalidades: ajuste fino, execução de inferência e avaliação. Um artigo publicado no blog da CNCF considera que o verdadeiro desafio empresarial já não é apenas treinar o modelo, mas conceder a cada equipe acesso seguro e isolado ao mesmo hardware, mantendo alta a utilização das unidades de GPU e permitindo medir os custos.
O material foi escrito por Hrittik Roy, na qualidade de CNCF Ambassador e Platform Advocate na vCluster, e oferece uma leitura prática de como montar esse ambiente sobre o Kubernetes. A ideia central do artigo é que o Kubernetes fornece uma base madura para contêineres, RBAC, escalabilidade automática e políticas, mas precisou de um ecossistema adicional para lidar com aceleradores e com o isolamento entre locatários nos mesmos nós.
O gargalo é a utilização, não apenas a velocidade de inferência
As unidades de GPU representam o maior gasto de capital na infraestrutura de IA e, por isso, a taxa de utilização se torna um indicador econômico mais importante do que registrar uma velocidade máxima em uma única execução. O artigo apresenta dois problemas principais: o modelo de alocação de recursos e o modelo de isolamento.
No modelo tradicional de device plugin, a carga solicita, por exemplo, nvidia.com/gpu: 1 e reserva uma unidade inteira, mesmo que utilize apenas dez por cento dela. Já o Dynamic Resource Allocation, ou DRA, que se tornou disponível de forma geral no Kubernetes 1.34, permite que o agendador trate os aceleradores como dispositivos com características, memória e topologia. No entanto, ele não divide automaticamente uma unidade de GPU em quotas; a densidade vem da camada do dispositivo, como o HAMi, um projeto em fase Incubating dentro da CNCF que impõe limites de memória e computação por software no nível do contêiner e oferece suporte a vários fabricantes de aceleradores.
Por outro lado, alocar hardware separado para cada equipe pode proporcionar um isolamento forte, mas deixa grande parte da capacidade sem utilização. Por isso, o artigo distingue entre alocar uma unidade completa quando os limites de confiança são rigorosos e dividir a unidade dentro de um mesmo domínio de confiança para aumentar a densidade. A NVIDIA MIG oferece isolamento de memória e de falhas no nível do hardware, mas o artigo observa que seu uso como barreira entre locatários hostis ainda é objeto de debate; por isso, a alocação de uma GPU inteira continua sendo a opção conservadora em situações de baixa confiança.
As camadas da fábrica, do metal à carga
O sistema começa com o provisionamento do hardware bruto. Os nós são descobertos, as unidades de GPU, o estado da memória ECC e as identidades das placas de rede são verificados, e então é instalada a imagem do sistema operacional que inclui o driver da GPU e as bibliotecas CUDA e NCCL. Em seguida, são aplicadas as configurações adequadas do BIOS, e os nós passam por testes de estresse e testes do NCCL para confirmar que as unidades de GPU se comunicam com a largura de banda total, antes que o resultado seja registrado em uma fonte de verdade, como o NetBox. Esse ciclo pode ser construído por meio de um gerenciador de hardware específico do fornecedor ou com ferramentas abertas, como o Metal3 com o Ironic ou o vMetal.
Após a alocação, ferramentas como KAI Scheduler e Volcano cuidam do agendamento em lote e orientado pela topologia, enquanto o Kueue gerencia a fila, a admissão e as quotas. Na camada de cargas, o vLLM pode ser usado para mecanismos de inferência, e o KServe para fornecer endpoints padronizados e escalabilidade automática, além do NVIDIA Dynamo e do llm-d para inferência desagregada em ambientes maiores. A Gateway API fornece o roteamento, enquanto o LiteLLM adiciona um gateway compatível com a API da OpenAI.
A plataforma não se limita aos contêineres. O artigo explica que os ambientes de treinamento podem usar o Slurm por meio do Slinky, da SchedMD, que representa os serviços do Slurm como recursos personalizados e os integra ao GPU Operator e ao DRA. O KubeVirt também pode executar máquinas virtuais como cargas do Kubernetes, permitindo gerenciar máquinas virtuais e contêineres a partir da mesma frota, com permissões e quotas unificadas.
O isolamento não é apenas uma questão de namespaces
O artigo divide o problema do isolamento em dois níveis. No nível de controle, o padrão de tenant cluster oferece a cada equipe uma interface Kubernetes virtual que inclui servidor de API, recursos dedicados, regras de admissão e RBAC independentes, executando-a como uma carga sobre um único cluster subjacente. O vCluster é apresentado como um exemplo disso, com a possibilidade de usar ferramentas familiares como kubectl, Helm e Argo CD sem extensões proprietárias.
Já o nível de dados exige isolamento de redes, armazenamento, quotas e ambiente de execução. É possível usar o Cilium para CNI e políticas, e Multus e SR-IOV para o caminho rápido, com InfiniBand ou RoCEv2 para transportar o tráfego de GPU entre os nós. Também são usadas VPCs separadas por meio de VXLAN e EVPN, ou chaves de particionamento em InfiniBand, enquanto unidades DPU como NVIDIA BlueField ou AMD Pensando transferem parte das funções de isolamento e criptografia para longe do processador hospedeiro. O artigo enfatiza que o padrão de uma verdadeira nuvem é o isolamento imposto pelo hardware quando necessário, e não a dependência exclusiva de namespaces.
O que transforma a frota em um serviço de nuvem?
Leitura editorial: o valor prático dessa abordagem é transferir a discussão de «qual modelo é mais rápido?» para a questão da operação da própria infraestrutura. A plataforma não se torna um serviço de nuvem simplesmente por reunir unidades de GPU; isso acontece quando o locatário consegue criar e excluir clusters por meio de uma API, Terraform ou GitOps, e quando os recursos são definidos de forma declarativa e gerenciados pelo Flux ou Argo CD, com identidade OIDC e permissões RBAC.
O serviço também precisa de medição e faturamento compreensíveis. O artigo propõe usar dados do DCGM para calcular segundos de GPU e, em seguida, distribuí-los entre os locatários por meio do OpenCost. O monitoramento e a confiabilidade também fazem parte do produto, e não são um complemento operacional: o DCGM monitora a degradação, o Node Problem Detector transforma sinais de falhas em estados dos nós, enquanto o ciclo de processamento isola o nó suspeito e o drena antes do agendamento de novas cargas. A camada de segurança inclui ferramentas como Keycloak por meio de OIDC, OpenBao com External Secrets Operator, Kyverno ou OPA para os controles, e Falco e Trivy para a segurança da execução e da cadeia de suprimentos.
O teste mais difícil continua sendo a transição de uma demonstração para uma produção em larga escala. O exemplo que executa duas equipes e dois modelos em uma única GPU particionada, por si só, não comprova a validade do projeto em centenas de nós e vários data centers. O artigo menciona o papel de ferramentas de validação como o NVIDIA AI Cluster Runtime e o programa Kubernetes AI Conformance, apresentado com a versão 1.35, mas deixa em aberto questões operacionais sobre o raio de explosão, os limites do isolamento entre locatários e a escolha entre o pacote NVIDIA DSX OS e a composição de camadas de código aberto.
A conclusão é que o sucesso de uma «fábrica de IA» depende da combinação entre densidade, isolamento e faturamento, levando em conta a topologia do hardware: a localização das unidades de GPU em relação ao NVLink ou NVSwitch, sua conexão com a rede InfiniBand ou RoCE e as posições de GPU, NIC e CPU nos nós NUMA. Agendar a carga sem essas informações pode fazer com que as operações de comunicação coletiva desacelerem na ligação mais lenta, mesmo que a plataforma pareça íntegra no nível do software.