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á.
# Escalabilidade e desempenho de aplicativos
**dica**
[Explore as](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) melhores práticas por meio de workshops do Amazon EKS.
## 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.
### 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 (como pesos e 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. Observe que, ao nos referirmos ao armazenamento do “modelo”, estamos nos referindo aos artefatos do modelo (como parâmetros treinados e pesos do modelo). Existem diferentes 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 seu modelo. Considere as seguintes abordagens, da menos para a mais recomendada:
+ **Inserindo 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. Isso garante consistência e reprodutibilidade, não atrasa o carregamento e simplifica o gerenciamento de dependências, mas 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 e não é ideal para modelos grandes devido à taxa de transferência do registro.
+ **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. Isso mantém as imagens do contêiner focadas code/runtime, permite atualizações fáceis do modelo sem reconstruções, oferece suporte ao controle de versão por meio de metadados de armazenamento, mas introduz possíveis falhas de rede (requer lógica de repetição), requer autenticação e armazenamento em cache.
Para saber mais, consulte [Acelerando o processo de extração](https://awslabs.github.io/ai-on-eks/docs/guidance/container-startup-time/accelerate-pull-process) no AI on EKS Workshop.
### 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 Python-based configurações 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 dos contêineres (vários GBs) devido às dependências, o que pode afetar 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, sem infraestrutura extra, compatível Python-only 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 scaling/monitoring, falta 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, gerenciando carregamento, roteamento e otimização de modelos. Esses formatos de suporte, como sensores de segurança, com compilação ou plug-ins opcionais.
+ **Prós**: oferece lotes (em static/in voo ou contínuo), quantização (INT8, FP8, GPTQ), otimizações de hardware (NVIDIA, AMD, Intel, Inferentia) e suporte a várias GPUs (paralelismo). Tensor/Pipeline TensorRT-LLM oferece suporte a diversos modelos (LLMs Encoder-Decoder), enquanto o TGI aproveita HuggingFace a integração.
+ **Contras**: TensorRT-LLM precisa de compilação e é NVIDIA-only; o TGI pode ser menos eficiente no agrupamento 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 serviço de LLM com lotes em andamento e quantização (INT8, AWQ) PagedAttention, integráveis ao escalonamento automático do EKS. FP8-KV
+ **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, LLama), 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.
## Otimizando os tempos de extração da imagem do contêiner
Imagens de contêineres grandes podem causar atrasos na inicialização a frio que afetam a latência de inicialização do pod. Para cargas de trabalho sensíveis à latência, como cargas de trabalho de inferência em tempo real escaladas horizontalmente, a inicialização rápida do pod é fundamental. Considere as seguintes abordagens para otimizar os tempos de extração da imagem do contêiner:
### 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 `RUN` `COPY` comandos para criar um número menor de camadas maiores. Para AI/ML estruturas, 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, `COPY —from=` por meio de registros ou contextos locais) e selecione variantes, como imagens somente em tempo de execução (por exemplo, `pytorch/pytorch:2.7.1-cuda11.8-cudnn9-runtime` em 3,03 GB versus desenvolvimento em 6,66 GB). Para saber mais, consulte [Redução do tamanho da imagem do contêiner](https://awslabs.github.io/ai-on-eks/docs/guidance/container-startup-time/reduce-container-image-size) no AI on EKS Workshop.
### Reduza a latência de extração de imagem
Para clusters EKS executados em sub-redes privadas, configure endpoints de interface VPC para o Amazon ECR para manter o tráfego de extração de imagens na rede privada da AWS, reduzindo a latência e eliminando as cobranças de processamento de dados do gateway NAT. Consulte [Criar os endpoints VPC para o Amazon ECR para obter](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html) instruções de configuração.
Além disso, se suas cargas de trabalho dependem de imagens de contêiner upstream de registros externos, considere usar o [cache pull through do ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache.html) para proxy e armazenar essas imagens em seu registro ECR privado.
### Otimize a largura de banda da rede para extração de imagens
Ao extrair imagens de contêineres grandes, a largura de banda da rede disponível para os nós de trabalho do EKS afeta diretamente o tempo de início das cargas de trabalho de treinamento e inferência. Todas as Nitro-based instâncias da geração atual usam o Elastic Network Adapter (ENA), mas a largura de banda disponível varia significativamente de acordo com o tamanho da instância, e é fundamental entender a diferença entre a largura de banda básica e a largura de banda máxima (consulte Largura de banda de rede da instância Amazon [EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html)). Para minimizar o tempo de preparação de suas cargas de trabalho, selecione tamanhos de instância com largura de banda de rede básica suficiente em relação aos tamanhos das imagens e extraia a simultaneidade.
### Usando o snapshotter SOCI para imagens Pre-pull
Para imagens muito grandes que você não pode minimizar facilmente, você pode usar o snapshotter Seekable OCI (SOCI) de código aberto configurado no modo pull and unpack paralelo. Essa solução permite que você use imagens existentes sem reconstruir ou modificar seus pipelines de criação. Essa opção é especialmente eficaz ao implantar cargas de trabalho com imagens muito grandes em instâncias de computação EC2 de alto desempenho. Ele funciona bem com redes de alto rendimento e configurações de armazenamento de alto desempenho, como é típico com cargas de trabalho escalonadas. AI/ML
O pull/unpack modo paralelo SOCI melhora o desempenho de extração de imagem de ponta a ponta por meio de estratégias de paralelização configuráveis. A coleta e a preparação mais rápidas de imagens afetam diretamente a rapidez com que você pode implantar novas cargas de trabalho e escalar seu cluster com eficiência. A extração de imagens tem duas fases principais:
**1. Buscando camadas do registro para o nó**
Para otimizar a busca por camada, o SOCI cria várias conexões HTTP simultâneas por camada, multiplicando a taxa de transferência de download além da limitação de conexão única. Ele divide grandes camadas em partes e as baixa simultaneamente em várias conexões. Essa abordagem ajuda a saturar a largura de banda de rede disponível e a reduzir significativamente os tempos de download. Isso é particularmente valioso para AI/ML cargas de trabalho em que uma única camada pode ter vários gigabytes.
**2. Desembalando e preparando essas camadas para criar contêineres**
Para otimizar o desempacotamento de camadas, o SOCI processa várias camadas simultaneamente. Em vez de esperar que cada camada seja totalmente descompactada antes de iniciar a próxima, ele usa os núcleos de CPU disponíveis para descompactar e extrair várias camadas simultaneamente. Esse processamento paralelo transforma a fase tradicional de I/O-bound desempacotamento em uma CPU-optimized operação que se adapta aos núcleos disponíveis. O sistema orquestra cuidadosamente essa paralelização para manter a consistência do sistema de arquivos e, ao mesmo tempo, maximizar a taxa de transferência.
O modo SOCI parallel pull usa um sistema de controle de limite duplo com parâmetros configuráveis para simultaneidade de download e paralelismo de descompactação. Esse controle granular permite que você ajuste o comportamento do SOCI para atender aos seus requisitos específicos de desempenho e condições ambientais. A compreensão desses parâmetros ajuda você a otimizar seu tempo de execução para obter o melhor desempenho de extração.
**Referências**
+ Para obter mais informações sobre a solução e as vantagens e desvantagens do ajuste, consulte a [documentação do recurso no repositório](https://github.com/awslabs/soci-snapshotter/blob/main/docs/parallel-mode.md) do projeto [SOCI](https://github.com/awslabs/soci-snapshotter) em. GitHub
+ Para ver um exemplo prático com o Karpenter no Amazon EKS, consulte o [Karpenter Blueprint usando o modo paralelo do snapshotter](https://github.com/aws-samples/karpenter-blueprints/tree/main/blueprints/soci-snapshotter) SOCI. pull/unpack
+ Para obter informações sobre como configurar o Bottlerocket para tração paralela, [consulte soci-snapshotter](https://bottlerocket.dev/en/os/1.44.x/api/settings/container-runtime-plugins/#tag-soci-parallel-pull-configuration) Parallel Pull Unpack Mode no Bottlerocket Documentation.o
### Usando instantâneos do EBS em imagens Pre-pull
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 [Reduzir o tempo de inicialização do contêiner no Amazon EKS com o volume de dados do Bottlerocket](https://aws.amazon.com/blogs/containers/reduce-container-startup-time-on-amazon-eks-with-bottlerocket-data-volume/) para obter mais informações sobre o uso do Karpenter e do [EKS Terraform](https://aws-ia.github.io/terraform-aws-eks-blueprints/patterns/machine-learning/ml-container-cache/) Blueprints para grupos de nós gerenciados.
Para saber mais, consulte [Usando snapshotter containerd](https://awslabs.github.io/ai-on-eks/docs/guidance/container-startup-time/accelerate-pull-process/containerd-snapshotter) [e Pré-carregar imagens de contêiner em volumes de dados do Bottlerocket com instantâneos do EBS no](https://awslabs.github.io/ai-on-eks/docs/guidance/container-startup-time/accelerate-pull-process/prefecthing-images-on-br) AI on EKS Workshop.
### Usando o Container Runtime Cache para Pre-pull 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/)), onde as imagens são armazenadas após serem retiradas de um registro. Pre-pulling garante que as imagens estejam disponíveis localmente, evitando atrasos no download durante a inicialização do pod. Essa abordagem é particularmente útil quando as imagens mudam com frequência (por exemplo, atualizações frequentes), quando os instantâneos do EBS não estão pré-configurados, quando a criação de um volume do EBS seria mais demorada do que a extração direta de um registro de contêiner ou quando os nós já estão no cluster e precisam ativar pods sob demanda usando uma das várias imagens possíveis.
Pre-pulling todas as variantes garantem um tempo de inicialização rápido, independentemente da imagem necessária. Por exemplo, em uma carga de trabalho de ML massivamente paralela que exige 100.000 modelos pequenos criados usando 10 técnicas diferentes, a pré-extração de 10 imagens DaemonSet em um grande cluster (por exemplo, milhares de nós) minimiza o tempo de inicialização do pod, permitindo a conclusão em menos de 10 segundos, evitando solicitações sob demanda. Usar a abordagem de cache de tempo de execução de contêiner elimina a necessidade de gerenciar instantâneos do EBS e garante que você sempre obtenha a versão mais recente da imagem do contêiner DaemonSets, mas para cargas de trabalho de inferência em tempo real em que os nós escalam in/out, novos nós adicionados por ferramentas como o Cluster Autoscaler podem agendar 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. Além disso, 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 in/out padrões de escala, 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.
Consulte o [ GitHub repositório da AWS](https://github.com/aws-samples/aws-do-eks/tree/main/Container-Root/eks/deployment/prepull) para ver exemplos de pré-extração de imagens para o cache de tempo de execução do contêiner.
## Considere o NVMe para armazenamento em kubelet e containerd
Considere configurar `kubelet` e usar discos de armazenamento `containerd` de instância NVMe efêmeros para aumentar o desempenho do disco. O processo de extração do contêiner envolve o download de uma imagem do contêiner de um registro e a descompactação de suas camadas em um formato utilizável. Para otimizar I/O as operações durante a descompressão, você deve avaliar o que fornece níveis mais altos de I/O desempenho e taxa de transferência para o tipo de instância do seu host de contêiner: [instâncias apoiadas por NVMe](https://docs.aws.amazon.com/en_us/documentdb/latest/developerguide/db-instance-nvme.html) com armazenamento local versus volume do EBS. IOPS/throughput Para instâncias EC2 com armazenamento local NVMe, considere configurar o sistema de arquivos subjacente do nó para kubelet (), containerd () e Pod logs (`/var/log/pods`) para usar `/var/lib/kubelet` discos de armazenamento de instâncias NVMe efêmeros para obter níveis mais altos de desempenho e taxa de transferência. `/var/lib/containerd` I/O
O armazenamento efêmero do nó pode ser compartilhado entre pods que solicitam armazenamento efêmero e imagens de contêiner que são baixadas para o nó. [Se estiver usando Karpenter com Bottlerocket ou AL2023 EKS Optimized AMIs, isso pode ser configurado definindo [EC2NodeClass](https://karpenter.sh/docs/concepts/nodeclasses/#specinstancestorepolicy)a StorePolicy instância como RAID0 ou, se estiver usando grupos de nós gerenciados, definindo o local como parte dos dados do usuário. StoragePolicy [NodeConfig](https://eksctl.io/usage/node-bootstrapping/#configuring-the-bootstrapping-process)](https://docs.aws.amazon.com/ebs/latest/userguide/raid-config.html)