As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Performance
Escalabilidade e desempenho de aplicativos
Gerenciamento de artefatos de ML, estruturas de serviço e otimização de startups
A implantação de modelos de aprendizado de máquina (ML) no Amazon EKS exige uma análise cuidadosa de como os modelos são integrados às imagens de contêineres e aos ambientes de execução. Isso garante escalabilidade, reprodutibilidade e utilização eficiente dos recursos. Este tópico descreve as diferentes abordagens para lidar com artefatos do modelo de ML, selecionar estruturas de serviço e otimizar os tempos de inicialização de contêineres por meio de técnicas como pré-armazenamento em cache, todas adaptadas para reduzir os tempos de inicialização de contêineres.
Reduzindo tamanhos de imagens de contêiner
-
Reduzir o tamanho das imagens do contêiner durante a inicialização é outra forma de tornar as imagens menores. Você pode fazer reduções em cada etapa do processo de criação da imagem do contêiner. Para começar, escolha imagens básicas que contenham o menor número de dependências necessárias. Durante a criação de imagens, inclua somente as bibliotecas e artefatos essenciais necessários. Ao criar imagens, tente combinar vários comandos RUN ou COPY para criar um número menor de camadas maiores. Criar imagens menores tem os seguintes prós e contras:
-
Prós:
-
A extração de imagens é mais rápida e, em geral, é necessário menos armazenamento.
-
Imagens menores têm menos vetor de ataque.
-
-
Contras:
-
Com as imagens de contêiner sendo mais simplificadas, você precisará criar várias imagens para atender às necessidades de execução em ambientes diferentes.
-
Às vezes, a economia de tamanho com a combinação de comandos pode ser insignificante, então você deve testar diferentes abordagens de criação para ver o que traz os melhores resultados. Para AI/ML estruturas, selecione variantes como imagens somente em tempo de execução (por exemplo,
pytorch/pytorch:2.7.1-cuda11.8-cudnn9-runtimeem 3,03 GB versus desenvolvimento em 6,66 GB), mas comparar cargas de trabalho como imagens menores pode ignorar a compilação do JIT, resultando em caminhos de código mais lentos. Use compilações de vários estágios para separar a compilação e o tempo de execução, copiando somente os artefatos necessários (por exemplo, via COPY —from= para registros ou contextos locais). Empregue a otimização de camadas combinando COPY em um estágio de montagem para menos camadas, embora tenha em conta a redução da eficiência do cache e os tempos de construção mais longos.
-
Lidando com artefatos do modelo de ML em implantações
Uma decisão importante é como lidar com os próprios artefatos do modelo de ML (por exemplo, pesos, configurações). A escolha afeta o tamanho da imagem, a velocidade de implantação, a frequência de atualização do modelo e a sobrecarga operacional. Não que, ao nos referirmos ao armazenamento do “modelo”, estejamos nos referindo aos artefatos do modelo (por exemplo, parâmetros treinados, pesos do modelo). Há três abordagens para lidar com artefatos do modelo de ML no Amazon EKS. Cada um tem suas vantagens e desvantagens, e a melhor depende do tamanho, da cadência de atualização e das necessidades de infraestrutura do modelo, listadas da menos para a mais recomendada:
Cozendo o modelo na imagem do contêiner Copie os arquivos do modelo (por exemplo, .safetensors, .pth, .h5) na imagem do contêiner (por exemplo, Dockerfile) durante a criação da imagem. O modelo faz parte da imagem imutável. Recomendamos usar essa abordagem para modelos menores com atualizações pouco frequentes.
-
Prós: Garante consistência e reprodutibilidade, sem atrasos no carregamento, simplifica o gerenciamento de dependências.
-
Contras: resulta em tamanhos de imagem maiores, reduz a velocidade de compilação e envio, requer reconstrução e reimplantação para atualizações de modelos, o que não é ideal para modelos grandes devido à taxa de transferência do registro. Além disso, isso pode levar a ciclos de feedback mais longos para experimentação, depuração e teste devido à configuração mais complexa, e pode aumentar os custos de armazenamento se a localização for compartilhada em imagens diferentes.
Baixando o modelo em tempo de execução Na inicialização do contêiner, o aplicativo baixa o modelo do armazenamento externo (por exemplo, Amazon S3, apoiado pelo S3 CRT para transferências otimizadas de alto rendimento usando métodos como Mountpoint for S3 CSI driver, AWS S3 CLI ou s5cmd OSS CLI) por meio de scripts em um contêiner inicial ou ponto de entrada. Recomendamos começar com essa abordagem para modelos grandes com atualizações frequentes.
-
Vantagens: mantém as imagens de contêiner focadas em code/runtime, enables easy model updates without rebuilds, supports versioning via storage metadata. It also allows for A/B testes, troca dinâmica ou reversão de modelos sem aumentar o tamanho da imagem de contêiner e oferece a capacidade de compartilhar modelos entre aplicativos diferentes sem empacotá-los em todas as imagens de contêiner. Além disso, ele introduz mudanças mínimas nos fluxos de trabalho de ML ou das equipes de aplicativos e permite a criação mais rápida de contêineres para auxiliar na experimentação e nos testes. O uso de ferramentas baseadas no S3 CRT, como o AWS CLI, o s5cmd
ou o driver Mountpoint S3 CSI, pode reduzir significativamente a latência do download e melhorar o desempenho de arquivos grandes, geralmente resultando em tempos gerais de inicialização mais rápidos do que a extração de grandes imagens de contêineres de registros como o ECR, dependendo do desempenho da rede e do registro. -
Contras: introduz possíveis falhas de rede (requer lógica de repetição), requer autenticação e armazenamento em cache. A complexidade operacional adicional surge da manipulação do processo de download, incluindo novas tentativas, tratamento de erros e atrasos, além do gerenciamento extra de armazenamento e limpeza que replica a funcionalidade do ECR.
Montando o modelo por meio de volumes persistentes Armazene o modelo em armazenamento externo (por exemplo, Amazon EFS, EBS, FSx para NetApp ONTAP, para Lustre, FSx para OpenZFS ou S3 FSx por meio do driver CSI Mountpoint S3) e monte-o como um Kubernetes (PV). PersistentVolume Esses são os arquivos e dados gerados durante o processo de treinamento do modelo que permitem fazer previsões ou inferências. Recomendamos usar essa abordagem para modelos compartilhados entre pods ou clusters.
-
Vantagens: Separa o modelo da imagem para acesso compartilhado, facilita as atualizações sem reinicializações (se suportado pela sua estrutura) e lida com grandes conjuntos de dados de forma eficiente. Ele também permite o provisionamento e o controle de acesso orientados pelo Kubernetes por meio de recursos como clonagem, compartilhamento e instantâneos, reduzindo a necessidade de copiar modelos e criar novas operações. O controle de acesso aos modelos baseado em POSIX é possível, juntamente com a capacidade de atualizar as versões do modelo separadamente do aplicativo sem reconstruir a imagem do contêiner, e a criação mais rápida de contêineres para experimentação e teste. Para aplicativos de AI/ML inferência que leem artefatos na memória, isso permite carregar os dados diretamente do sistema de arquivos externo sem precisar armazená-los intermediariamente no disco local do nó, melhorando o desempenho do carregamento. Além disso, para armazenar modelos grandes em grande escala, serviços como FSx o NetApp ONTAP e o Lustre fornecem técnicas de otimização de armazenamento (por exemplo, desduplicação, compactação, provisionamento reduzido), controle de versão por meio de instantâneos e suporte para reutilização do mesmo arquivo sem desperdiçar espaço de armazenamento. FSx Outros serviços, como o S3, oferecem versionamento nativo. Essa abordagem também pode abranger clusters e potencialmente regiões, dependendo da configuração de replicação (por exemplo, replicação assíncrona em FSx ou entre regiões no S3 e no EFS).
-
Contras: pode aumentar a I/O latência se estiver conectado à rede, requer provisionamento de armazenamento e controles de acesso, pode ser menos portátil (por exemplo, EBS) se o armazenamento for específico do cluster. As compensações incluem complexidade operacional adicional para CI/CD mudanças e manutenção dos processos do carregador, a necessidade de TTL/retention mecanismos personalizados para reduzir os custos de armazenamento e uma replicação mais complexa entre regiões. O desempenho de leitura dos artefatos do modelo deve ser medido em relação ao tempo de download da imagem do contêiner.
Servindo modelos de ML
A implantação e a distribuição de modelos de aprendizado de máquina (ML) no Amazon EKS exigem a seleção de uma abordagem apropriada de distribuição de modelos para otimizar a latência, a taxa de transferência, a escalabilidade e a simplicidade operacional. A escolha depende do tipo de modelo (por exemplo, linguagem, modelo de visão), das demandas de carga de trabalho (por exemplo, inferência em tempo real) e da experiência da equipe. As abordagens comuns incluem configurações baseadas em Python para prototipagem, servidores de modelos dedicados para recursos de nível de produção e mecanismos de inferência especializados para alto desempenho e eficiência. Cada método envolve compensações na complexidade da configuração, no desempenho e na utilização de recursos. Observe que as estruturas de serviço podem aumentar o tamanho das imagens de contêineres (múltiplas GBs) devido a dependências, potencialmente afetando os tempos de inicialização. Considere a desacoplamento usando técnicas de manipulação de artefatos para mitigar isso. As opções estão listadas da menos para a mais recomendada:
Usando estruturas Python (por exemplo, FastAPI, HuggingFace Transformers with PyTorch) Desenvolva um aplicativo personalizado usando estruturas Python, incorporando arquivos de modelo (pesos, configuração, tokenizador) em uma configuração de nó em contêiner.
-
Prós: prototipagem fácil, somente em Python sem infraestrutura extra, compatível com todos os HuggingFace modelos, implantação simples do Kubernetes.
-
Contras: restringe a um único request/simple lote, geração lenta de tokens (sem kernels otimizados), memória ineficiente, falta escalabilidade e monitoramento e envolve longos tempos de inicialização.
-
Recomendação: use para prototipagem inicial ou tarefas de nó único que exijam integração lógica personalizada.
Usando estruturas dedicadas de fornecimento de modelos (por exemplo, TensorRT-LLM, TGI) Adote servidores especializados, como TensorRT-LLM ou TGI, para inferência de ML, gerenciamento de carregamento, roteamento e otimização de modelos. Esses formatos de suporte, como sensores de segurança, com compilação ou plug-ins opcionais.
-
Vantagens: Oferece agrupamento em lotes (static/in-flight or continuous), quantization (INT8, FP8, GPTQ), hardware optimizations (NVIDIA, AMD, Intel, Inferentia), and multi-GPU support (Tensor/Pipelineparalelismo). O Tensorrt-LLM oferece suporte a diversos modelos (LLMs, Encoder-Decoder), enquanto o TGI aproveita a integração. HuggingFace
-
Contras: o TensorRT-LLM precisa de compilação e é exclusivo para NVIDIA; o TGI pode ser menos eficiente em lotes; ambos adicionam sobrecarga de configuração e podem não se adequar a todos os tipos de modelos (por exemplo, não transformadores).
-
Recomendação: Adequado para PyTorch/TensorFlow modelos que precisam de recursos de produção, como A/B testes ou alto rendimento com hardware compatível.
Usando mecanismos de inferência especializados de alto rendimento (por exemplo, vLLM) Utilize mecanismos de inferência avançados como o vLLM, otimizando o atendimento do LLM com lotes em andamento e quantização (, -KV, AWQ) PagedAttention, integráveis ao escalonamento automático do EKS. INT8 FP8
-
Prós: alto rendimento e eficiência de memória (40 a 60% de economia de VRAM), tratamento dinâmico de solicitações, streaming de tokens, suporte a várias GPUs Tensor Parallel de nó único e ampla compatibilidade de hardware.
-
Contras: Otimizado para transformadores somente para decodificadores (por exemplo, LLa MA), menos eficaz para modelos sem transformadores, requer hardware compatível (por exemplo, GPUs NVIDIA) e esforço de configuração.
-
Recomendação: A melhor opção para inferência LLM de alto volume e baixa latência no EKS, maximizando a escalabilidade e o desempenho.
Pré-armazenamento em cache de imagens de contêiner
Imagens de contêineres grandes (por exemplo, modelos como PyTorch) podem causar atrasos na inicialização a frio que afetam a latência. Para cargas de trabalho sensíveis à latência, como cargas de trabalho de inferência em tempo real escaladas horizontalmente e a inicialização rápida do pod, recomendamos pré-carregar as imagens do contêiner para minimizar os atrasos na inicialização. Considere as seguintes abordagens, da menos para a mais recomendada:
Usando o Container Runtime Cache para pré-extrair imagens
-
Você pode pré-inserir imagens de contêiner em nós usando recursos do Kubernetes (por exemplo, DaemonSet ou implantação) para preencher o cache de tempo de execução do contêiner do nó. O cache de tempo de execução do contêiner é o armazenamento local gerenciado pelo tempo de execução do contêiner (por exemplo, [containerd] (https://containerd.io/
)) em que as imagens são armazenadas após serem retiradas de um registro. A pré-extração garante que as imagens estejam disponíveis localmente, evitando atrasos no download durante a inicialização do pod. Essa abordagem é útil quando os instantâneos do EBS não estão pré-configurados ou quando a pré-extração da imagem é preferida. Consulte o [AWS Samples GitHub repository] (https://github.com/aws-samples/aws-do-eks/tree/main/Container-Root/eks/deployment/prepull ) para ver exemplos de pré-extração de imagens. Observe que alternativas como o carregamento lento com o [SOCI Snapshotter] (https://github.com/awslabs/soci-snapshotter ) (um plug-in containerd para extração parcial de imagens) podem complementar esses métodos, embora exijam configuração personalizada e possam não se adequar a todos os cenários. O uso do cache de tempo de execução do contêiner traz os seguintes prós e contras: -
Prós:
-
Não é necessário gerenciar instantâneos do EBS.
-
Com DaemonSets você, sempre obtenha a versão mais recente da imagem do contêiner.
-
Mais flexível, pois as imagens podem ser atualizadas sem recriar instantâneos.
-
Ainda reduz o tempo de inicialização do pod, garantindo que as imagens já estejam no nó.
-
-
Contras:
-
A extração inicial de imagens grandes ainda pode levar tempo, embora seja feita com antecedência.
-
Pode não ser tão eficiente quanto os instantâneos do EBS para imagens muito grandes (acima de 10 GB), pois a extração ainda é necessária, embora não na inicialização do pod.
-
Com DaemonSets, uma imagem é pré-transferida para todos os nós em que o pod pode ser executado. Por exemplo, se 1000 nós estivessem executando apenas uma instância de um pod, o espaço seria consumido em todos os 1000 nós apenas para executar uma instância em um nó.
-
Para cargas de trabalho de inferência em tempo real em que os nós aumentam e diminuem a escala, novos nós adicionados por ferramentas como o Cluster Autoscaler podem programar pods de carga de trabalho antes que a pré-extração conclua a extração da imagem. DaemonSet Isso pode fazer com que o pod inicial no novo nó acione a extração de qualquer maneira, potencialmente atrasando a inicialização e afetando os requisitos de baixa latência.
-
A coleta de lixo de imagens do Kubelet pode afetar as imagens pré-extraídas removendo as não utilizadas quando o uso do disco excede certos limites ou se elas excedem uma idade máxima não utilizada configurada. Em padrões de ampliação e redução, isso pode despejar imagens em nós ociosos, o que requer repuxamentos durante aumentos de escala subsequentes e reduz a confiabilidade do cache para cargas de trabalho intermitentes.
-
Usando snapshots do EBS
-
Você pode tirar um snapshot do Amazon Elastic Block Store (EBS) de imagens de contêineres em cache e reutilizar esse snapshot para os nós de trabalho do EKS. Isso garante que as imagens sejam pré-buscadas localmente na inicialização do nó, reduzindo o tempo de inicialização do pod. Consulte Reduza o tempo de inicialização do contêiner no Amazon EKS com o volume de dados do Bottlerocket
para obter mais informações sobre o Karpenter e este EKS Terraform Blueprints para grupos de nós gerenciados. Recomendamos automatizar a criação de instantâneos do EBS como parte do seu CI/CD pipeline para mantê-los up-to-date com as versões mais recentes da imagem de contêiner. O uso de snapshots do EBS traz os seguintes prós e contras: -
Prós:
-
Elimina a necessidade de extrair imagens de contêineres grandes na inicialização do pod, reduzindo significativamente o tempo de inicialização (por exemplo, de 10 a 15 minutos para segundos para imagens maiores que 10 GB).
-
Garante que as imagens estejam disponíveis localmente na inicialização do nó.
-
Especialmente útil para cargas de trabalho de inferência com imagens de contêineres grandes.
-
-
Contras:
-
Requer a manutenção e a atualização de snapshots do EBS com cada atualização de imagem ou versão.
-
Requer etapas adicionais para garantir que todas as suas cargas de trabalho usem a versão mais recente da imagem de contêiner.
-
Envolve atividades operacionais adicionais para criar e gerenciar instantâneos.
-
Pode incluir imagens desnecessárias se não forem gerenciadas adequadamente, embora isso possa ser atenuado com a configuração adequada do pool de nós.
-
Otimize o desempenho do Image Pull
É altamente recomendável otimizar o desempenho de extração de imagens de contêineres para clusters Amazon EKS que executam AI/ML cargas de trabalho. Usar imagens de base grandes e não otimizadas ou ordenação ineficiente de camadas pode levar a tempos de inicialização lentos do pod, aumento do consumo de recursos e diminuição da latência de inferência. Para resolver isso, adote imagens básicas pequenas e leves com dependências mínimas, adaptadas às suas cargas de trabalho. Você também pode considerar os AWS Deep Learning Containers (DLCs), que são imagens de contêiner pré-criadas que facilitam a execução de estruturas populares de aprendizado profundo (por exemplo, PyTorch
Reduza os tempos de inicialização de contêineres pré-carregando imagens de contêineres em volumes de dados
Para cargas de trabalho de aprendizado de máquina que exigem baixa latência de inicialização do pod, como inferência em tempo real, recomendamos pré-carregar imagens de contêiner para minimizar os atrasos na inicialização. Imagens de contêineres grandes podem retardar a inicialização do pod, especialmente em nós com largura de banda limitada. Além de usar imagens básicas mínimas, compilações de vários estágios e técnicas de carregamento lento, considere as seguintes abordagens para pré-carregar imagens no Amazon EKS. Além de usar imagens básicas mínimas, compilações de vários estágios e técnicas de carregamento lento, considere as seguintes opções:
-
Pré-carregue imagens usando instantâneos do EBS: faça um instantâneo Amazon Elastic Block Store (EBS) de imagens de contêineres em cache e reutilize esse instantâneo para os nós de trabalho do EKS. Embora isso acrescente atividades operacionais adicionais, ele garante que as imagens sejam pré-buscadas localmente na inicialização do nó, reduzindo o tempo de inicialização do pod. Consulte Reduza o tempo de inicialização do contêiner no Amazon EKS com o volume de dados do Bottlerocket
para obter mais informações sobre o Karpenter e este EKS Terraform Blueprints para grupos de nós gerenciados. -
Pré-extraia imagens para o cache de tempo de execução do contêiner: pré-puxe imagens de contêiner para os nós usando recursos do Kubernetes (por exemplo, DaemonSet ou implantação) para preencher o cache de tempo de execução do contêiner do nó. O cache de tempo de execução do contêiner é o armazenamento local gerenciado pelo tempo de execução do contêiner (por exemplo, containerd
) em que as imagens são armazenadas após serem retiradas de um registro. A pré-extração garante que as imagens estejam disponíveis localmente, evitando atrasos no download durante a inicialização do pod. Essa abordagem é útil quando os instantâneos do EBS não estão pré-configurados ou quando a pré-extração da imagem é preferida. Teste essa abordagem em um ambiente de teste para validar as melhorias na latência. Consulte o GitHub repositório AWS Samples para ver exemplos de pré-extração de imagens.
