Ao executar o treinamento e a inferência de modelos de inteligência artificial (IA) e aprendizado de máquina (ML) no Kubernetes, o escalonamento dinâmico de recursos torna-se um elemento essencial. Além de exigir armazenamento e rede de alta largura de banda para a ingestão de dados, o treinamento de modelos de IA também demanda uma capacidade computacional considerável (e cara), proveniente principalmente de GPUs ou de outros processadores especializados. Mesmo ao utilizar modelos pré-treinados, tarefas como a disponibilização de modelos e o ajuste fino em produção ainda exigem mais recursos computacionais do que a maioria das cargas de trabalho empresariais.
O Kubernetes nativo da nuvem foi projetado para escalar rapidamente, tanto para cima quanto para baixo. Ele também foi desenvolvido para proporcionar mais agilidade e uso econômico de recursos para cargas de trabalho dinâmicas em ambientes híbridos e multinuvem.
Neste blog, abordamos as três maneiras mais comuns de escalar cargas de trabalho de IA/ML no Kubernetes para que você possa obter desempenho ideal, economia de custos e adaptabilidade para o escalonamento dinâmico em diversos ambientes.
Três modalidades de escalabilidade para cargas de trabalho de IA/ML no Kubernetes
As três formas mais comuns de o Kubernetes escalar uma carga de trabalho são por meio do Horizontal Pod Autoscaler (HPA), do Vertical Pod Autoscaler (VPA) e do Cluster Autoscaler.
Veja a seguir uma análise detalhada desses três métodos:
- HPA – O equivalente a adicionar instâncias ou réplicas de pods a uma aplicação, proporcionando maior escalabilidade, capacidade e taxa de transferência.
- VPA – O equivalente a redimensionar um pod para aumentar sua capacidade, com mais recursos de computação e memória.
- Cluster Autoscaler – Aumenta ou diminui automaticamente o número de nós em um cluster do Kubernetes, dependendo da demanda atual de recursos dos pods.
Cada modalidade oferece benefícios para o treinamento e a inferência de modelos, que você pode explorar nos casos de uso abaixo.
Casos de uso de HPA
Em muitos casos, as cargas de trabalho distribuídas de treinamento e inferência de modelos de IA podem ser dimensionadas horizontalmente (ou seja, adicionando mais pods para acelerar o processo de treinamento ou o processamento de solicitações). Isso permite que as cargas de trabalho se beneficiem do HPA, que pode aumentar o número de pods com base em métricas como uso de CPU e memória, ou até mesmo em métricas personalizadas e externas relevantes para a carga de trabalho. Em cenários nos quais a carga de trabalho varia ao longo do tempo, o HPA pode ajustar dinamicamente o número de pods para garantir a utilização ideal dos recursos.
Outro aspecto do escalonamento horizontal de cargas de trabalho de IA no Kubernetes é o balanceamento de carga. Para garantir o desempenho ideal e o processamento ágil das solicitações, as solicitações recebidas precisam ser distribuídas entre várias instâncias ou pods. Por isso, uma das ferramentas ideais que podem ser usadas em conjunto com o HPA é um controlador de Ingress.
Casos de uso do VPA
As tarefas de treinamento de modelos de IA geralmente consomem muitos recursos, exigindo uma quantidade significativa de CPU, GPU e memória. O VPA pode ajustar dinamicamente a alocação desses recursos. Isso ajuda a garantir que cada pod tenha recursos suficientes para processar com eficiência a carga de trabalho de treinamento e que todos os pods designados tenham capacidade computacional suficiente para realizar os cálculos. Além disso, os requisitos de memória podem variar significativamente durante o treinamento de modelos de grande porte. O VPA pode ajudar a evitar erros de falta de memória aumentando a alocação de memória conforme necessário.
Embora seja tecnicamente possível usar HPA e VPA em conjunto, isso exige uma configuração cuidadosa para evitar conflitos, pois eles podem tentar escalar a mesma carga de trabalho de maneiras diferentes (ou seja, horizontalmente ou verticalmente). É essencial definir claramente os limites de atuação de cada recurso de escalabilidade automática, garantindo que eles se complementem em vez de entrarem em conflito. Uma abordagem emergente é usar ambos com escopos diferentes — por exemplo, o HPA para escalar vários pods com base na carga de trabalho e o VPA para ajustar com precisão a alocação de recursos de cada pod dentro dos limites definidos pelo HPA.
Casos de uso do Cluster Autoscaler
O Cluster Autoscaler pode ajudar a ajustar dinamicamente o conjunto geral de recursos de infraestrutura de computação, armazenamento e rede disponíveis em todo o cluster para atender às demandas das cargas de trabalho de IA/ML. Ao ajustar o número de nós em um cluster com base nas demandas atuais, uma organização pode balancear a carga em nível macro. Isso é necessário para garantir o desempenho ideal, pois as cargas de trabalho de IA/ML podem exigir, de forma imprevisível, recursos computacionais significativos.
HPA, VPA e Cluster Autoscaler: cada um tem sua função
Em resumo, estas são as três formas pelas quais o dimensionamento automático do Kubernetes funciona e beneficia as cargas de trabalho de IA:
- O HPA dimensiona os endpoints de disponibilização de modelos de IA que precisam lidar com taxas de requisição variáveis.
- O VPA otimiza a alocação de recursos para cargas de trabalho de IA/ML e garante que cada pod tenha recursos suficientes para um processamento eficiente, sem provisionamento excessivo.
- O Cluster Autoscaler adiciona nós a um cluster para garantir que ele possa acomodar cargas de trabalho de IA que exigem muitos recursos ou remove nós quando a demanda por capacidade computacional é baixa.
O HPA, o VPA e o Cluster Autoscaler se complementam no gerenciamento de cargas de trabalho de IA/ML no Kubernetes. O Cluster Autoscaler garante que haja nós suficientes para atender às demandas das cargas de trabalho, o HPA distribui essas cargas com eficiência entre vários pods e o VPA otimiza a alocação de recursos desses pods. Juntos, eles oferecem uma solução abrangente de escalabilidade e gerenciamento de recursos para aplicações de IA/ML em ambientes Kubernetes.
Acesse nossa página Potencialize e proteja sua jornada de IA para saber mais sobre como a F5 e o NGINX podem ajudar a disponibilizar, proteger e otimizar suas cargas de trabalho de IA/ML.
Sobre o autor
Publicações relacionadas no blog
Como o F5 NGINX One aprimora o gerenciamento e a observabilidade
Descubra como o F5 NGINX One aprimora o gerenciamento e a observabilidade de ambientes híbridos e multicloud ao oferecer um console web centralizado baseado em SaaS, com insights em tempo real, conformidade automatizada e gerenciamento simplificado de configurações.
Do OpenAPI ao NGINX como gateway de API usando uma API declarativa
Descubra como transformar uma definição de esquema OpenAPI em uma configuração NGINX totalmente funcional, operando como um API Gateway com a segurança de um Web Application Firewall e um Portal do Desenvolvedor, usando uma abordagem declarativa de API.
Como gerenciar picos repentinos de tráfego e sobrecarga do servidor
Picos de tráfego e sobrecarga de servidores são preocupações sérias para varejistas online em qualquer época, mas especialmente durante a “Cyber Season” de compras de fim de ano. Detalhamos como você pode aproveitar as soluções de entrega de aplicações de nível de produção da NGINX para se preparar para aumentos repentinos de tráfego.
Distribuição segura de chaves privadas SSL com o NGINX
Descrevemos três maneiras progressivamente mais seguras de proteger chaves privadas SSL ao configurar o NGINX para processar tráfego HTTPS: permitir acesso de leitura apenas ao usuário root, criptografar as chaves com senhas armazenadas separadamente e distribuir as senhas a partir de um repositório central.
Agrupando solicitações de API em lotes com NGINX Plus e o módulo JavaScript do NGINX
O módulo JavaScript do NGINX lançado com o NGINX Plus R15 oferece suporte a subsolicitações, possibilitando uma classe totalmente nova de casos de uso para o NGINX Plus. Este exemplo completo também usa a API do NGINX Plus e os módulos de chave-valor para converter solicitações de API dos clientes em solicitações separadas para as APIs dos microsserviços que compõem um aplicativo.
Como superar o esgotamento de portas efêmeras no NGINX e no NGINX Plus
Confira dicas para evitar o esgotamento de portas efêmeras com ajustes no kernel do Linux, conexões keepalive e conexões vinculadas dinamicamente a endereços IP locais.