Run:ai aberto: escolha o gargalo de GPU antes de instalar a plataforma inteira
A abertura inclui componentes independentes de orquestração. Cotas, fracionamento e descrição de workloads resolvem problemas distintos em Kubernetes.
A NVIDIA disponibilizou o código da plataforma completa Run:ai no ecossistema DSX AI Factory para orquestração de cargas de IA em Kubernetes.[14] A abertura inclui quatro componentes adotáveis separadamente, além da plataforma integrada.[14] A decisão de engenharia não deveria começar pela instalação de tudo. Comece pelo problema que impede usar bem a capacidade disponível.
O que muda para quem desenvolve
O KAI Scheduler, sob Apache 2.0 e contribuído ao CNCF Sandbox, oferece recursos como gang scheduling, cotas, compartilhamento justo e percepção de topologia.[14] Ele pode ser usado sem exigir todo o Run:ai.[14] Isso permite formular um piloto focado em filas e alocação, sem transformar a avaliação em uma migração completa de plataforma.
O GPU Fractioning Operator expõe o fracionamento nativo do CUDA 13.4, com limite rígido de memória imposto pelo driver e métricas por pod.[14] Já o KAI Resource Management acrescenta hierarquia de projetos e departamentos, garantias e cotas de capacidade.[14] Fracionamento de um recurso e distribuição entre equipes são problemas relacionados, mas não equivalentes.
O Workload Map descreve a estrutura de workloads como PyTorchJob, RayCluster e KServe.[14] É uma biblioteca Go que trabalha offline sobre objetos não estruturados; não agenda, não cria filas e não faz autoscaling.[14] Não atribua à descrição do workload as responsabilidades do scheduler ou do controlador.
Minha análise é que a modularidade só reduz complexidade quando o limite de cada módulo permanece claro. Adotar um componente deveria corresponder a uma hipótese mensurável, com dependências e responsabilidade operacional conhecidas.
Como aplicar
Escolha um gargalo: tempo em fila, fragmentação de memória, disputa entre equipes ou demora no carregamento dos modelos. Registre uma referência antes da mudança com workloads representativos e condições reproduzíveis.
Para cotas, simule concorrência entre projetos com prioridades diferentes. Observe espera, utilização e respeito aos limites. Para fracionamento, teste em homologação uma carga que exceda sua parcela de memória e confira se a contenção ocorre conforme o contrato esperado. Não faça esse ensaio sobre cargas críticas.
Separe desempenho de isolamento no relatório. Um ganho agregado pode vir acompanhado de latência pior para um serviço interativo. Defina qual classe de trabalho pode compartilhar capacidade e qual precisa de reserva.
A plataforma comunitária integrada pode ser instalada por Helm a partir do NGC e não exige assinatura paga do Run:ai.[14] Ainda assim, estime o esforço de atualização, observabilidade e suporte antes de comparar essa opção com um serviço comercial.
Cuidados e limites
O produto comunitário não inclui suporte empresarial NVIDIA, e seu download no NGC exige aceitar termos específicos; o código segue as licenças aplicáveis.[14] Código, pacote de distribuição e suporte devem aparecer como itens distintos na avaliação.
O artigo também apresenta ganhos de carregamento com Model Streamer em configurações específicas de armazenamento, rede e GPUs.[14] Não os converta em promessa para qualquer cluster. A adoção faz sentido quando resolve o gargalo observado e quando alguém está claramente responsável por operar a solução depois do piloto.
Fonte
[14] Fonte: NVIDIA Technical Blog