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
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 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
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 no código/tempo de execução, 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
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êiner grandes (como aquelas que contêm 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 snapshotter SOCI para pré-extrair imagens
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 EC2 computação 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 end-to-end imagem 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 de desempacotamento tradicionalmente vinculada à E/S em uma operação otimizada para CPU 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
do projeto SOCI em. GitHub -
Para ver um exemplo prático com o Karpenter no Amazon EKS, consulte o Karpenter Blueprint usando o modo paralelo do snapshotter
SOCI. pull/unpack -
Para obter informações sobre como configurar o Bottlerocket para pull paralelo, consulte soci-snapshotter Parallel Pull Unpack Mode na documentação do Bottlerocket.o
Usando instantâneos do EBS para pré-extrair imagens
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
Para saber mais, consulte Usando snapshotter containerd
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
A pré-extração de todas as variantes garante 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. O uso da abordagem de cache de tempo de execução de contêiner elimina a necessidade de gerenciar instantâneos do EBS, 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, new nodes added by tools like Cluster Autoscaler may schedule workload pods before the pre-pull DaemonSet completes image pulling. This can cause the initial pod on the new node to trigger the pull anyway, potentially delaying startup and impacting low-latency requirements. Additionally, kubelet image garbage collection can affect pre-pulled images by removing unused ones when disk usage exceeds certain thresholds or if they exceed a configured maximum unused age. In scale-in/out padrões, isso pode despejar imagens em nós ociosos, o que requer novas extraições durante escalonamentos subsequentes e reduz a confiabilidade do cache para cargas de trabalho intermitentes.
Consulte o GitHub repositório da AWS
Use NVMe para armazenamento de kubelet e containerd
Considere configurar kubelet e containerd usar discos de armazenamento de NVMe instância efêmera 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 descompactaçã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: NVMe instâncias de backup com armazenamento local versus IOPs/throughput de volume do EBS. Para EC2 instâncias com armazenamento NVMe local, considere configurar o sistema de arquivos subjacente do nó para kubelet (/var/lib/kubelet), containerd () e Pod logs /var/log/pods () para usar discos de armazenamento de instâncias /var/lib/containerd NVMe efêmeros para obter níveis mais altos de desempenho e taxa de transferência. 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 o Karpenter com Bottlerocket ou AL2 023 EKS Optimized, AMIs isso pode ser configurado no EC2NodeClass
