View a markdown version of this page

Implantação de modelos na Amazon SageMaker HyperPod - SageMaker IA da Amazon

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á.

Implantação de modelos na Amazon SageMaker HyperPod

SageMaker HyperPod Agora, a Amazon vai além do treinamento para oferecer uma plataforma de inferência abrangente que combina a flexibilidade do Kubernetes com a excelência operacional dos serviços gerenciados. AWS Implante, escale e otimize seus modelos de aprendizado de máquina com confiabilidade de nível corporativo usando a mesma HyperPod computação em todo o ciclo de vida do modelo.

SageMaker HyperPod A Amazon oferece interfaces de implantação flexíveis que permitem que você implante modelos por meio de vários métodos, incluindo kubectl, Python SDK, Amazon SageMaker Studio UI ou CLI. HyperPod O serviço fornece recursos avançados de ajuste de escala automático com alocação dinâmica de recursos que se ajusta automaticamente com base na demanda. Além disso, inclui recursos abrangentes de observabilidade e monitoramento que rastreiam métricas críticas, como tempo até o primeiro token, latência e utilização de GPU, para ajudar você a otimizar o desempenho.

nota

Ao implantar em GPU-enabled instâncias, você pode usar o particionamento de GPU com a tecnologia Multi-Instance GPU (MIG) para executar várias cargas de trabalho de inferência em uma única GPU. Isso permite uma melhor utilização da GPU e otimização de custos. Para obter mais informações sobre como configurar o particionamento de GPU, consulte. Usando partições de GPU na Amazon SageMaker HyperPod

Infraestrutura unificada para treinamento e inferência

Maximize a utilização de GPU fazendo a transição perfeita dos recursos de computação entre workloads de treinamento e inferência. Isso reduz o custo total de propriedade e, ao mesmo tempo, mantém a continuidade operacional.

Enterprise-ready opções de implantação

Implante modelos de várias fontes, incluindo modelos abertos e fechados da Amazon e modelos personalizados do Amazon S3 SageMaker JumpStart e do Amazon FSx com suporte para arquiteturas de inferência de nó único e de vários nós.

Cache gerenciado em camadas Key-value (KV) e roteamento inteligente

O cache KV salva os vetores de valores-chave pré-computados após o processamento dos tokens anteriores. Quando o próximo token for processado, os vetores não precisarão ser recalculados. Por meio de uma arquitetura de cache de duas camadas, você pode configurar um cache L1 que usa memória de CPU para reutilização local de baixa latência e um cache L2 que aproveita o Redis para permitir o compartilhamento de cache escalável em nível de nó.

O roteamento inteligente analisa as solicitações recebidas e as direciona para a instância de inferência com maior probabilidade de ter pares de valores-chave relevantes em cache. O sistema examina a solicitação e a encaminha com base em uma das seguintes estratégias de roteamento:

  1. prefixaware— Solicitações subsequentes com o mesmo prefixo de prompt são roteadas para a mesma instância

  2. kvaware— As solicitações recebidas são roteadas para a instância com a maior taxa de acerto de cache de KV.

  3. session— As solicitações da mesma sessão de usuário são roteadas para a mesma instância.

  4. roundrobin— Distribuição uniforme de solicitações sem considerar o estado do cache KV.

Para obter mais informações sobre como ativar esse recurso, consulteConfigurar o cache KV e o roteamento inteligente.

Cache L2 embutido Suporte de armazenamento hierárquico para armazenamento em cache KV

Com base na infraestrutura de cache KV existente, HyperPod agora integra o armazenamento em camadas como uma opção adicional de back-end L2 junto com o Redis. Com o armazenamento hierárquico SageMaker gerenciado incorporado, isso oferece melhor desempenho. Esse aprimoramento oferece aos clientes uma opção mais escalável e eficiente para o descarregamento de cache, particularmente benéfica para cargas de trabalho de inferência LLM de alto rendimento. A integração mantém a compatibilidade com os servidores do modelo vLLM e os recursos de roteamento existentes, ao mesmo tempo em que oferece melhor desempenho.

nota

Criptografia de dados: os dados de cache KV (chaves e valores de atenção) são armazenados sem criptografia em repouso para otimizar a latência da inferência e melhorar o desempenho. Para cargas de trabalho com requisitos rígidos de criptografia em repouso, considere a criptografia de solicitações e respostas na camada de aplicativo ou desative o armazenamento em cache.

Isolamento de dados: ao usar o armazenamento hierárquico gerenciado como back-end de cache L2, várias implantações de inferência em um cluster compartilham o armazenamento em cache sem isolamento. Os dados de cache L2 KV (chaves e valores de atenção) de diferentes implantações não são separados. Para cargas de trabalho que exigem isolamento de dados (cenários de vários locatários, diferentes níveis de classificação de dados), implante em clusters separados ou use instâncias Redis dedicadas.

Você pode reduzir a latência de inicialização a frio ao escalar as implantações armazenando em cache os pesos dos modelos no armazenamento NVMe local do host e transferindo previamente a imagem do contêiner do servidor de inferência para os nós de destino. Você pode ativar esses recursos de forma independente ou em conjunto em modelCacheConfig campo, e eles funcionam com modelos da Amazon SageMaker JumpStart, Amazon S3 e Amazon FSx. Para obter mais informações, consulte Armazenamento em cache de pesos de modelos e cache de imagens.

Multi-instance tipo de implantação com failover automático

HyperPod A inferência oferece suporte à implantação do tipo de várias instâncias para melhorar a confiabilidade da implantação e a utilização de recursos. Especifique uma lista priorizada de tipos de instância em sua configuração de implantação e o sistema selecionará automaticamente as alternativas disponíveis quando seu tipo de instância preferido não tiver capacidade. O agendador do Kubernetes usa a afinidade de preferredDuringSchedulingIgnoredDuringExecution nós para avaliar os tipos de instância em ordem de prioridade, colocando as cargas de trabalho no tipo de instância de maior prioridade disponível e garantindo a implantação mesmo quando os recursos preferenciais não estão disponíveis. Esse recurso evita falhas de implantação devido a restrições de capacidade e, ao mesmo tempo, mantém suas preferências de custo e desempenho, garantindo a disponibilidade contínua do serviço mesmo durante flutuações na capacidade do cluster.

Afinidade de nós personalizada para controle de agendamento granular

HyperPod A inferência oferece suporte à afinidade de nós personalizada para controlar o posicionamento da carga de trabalho além da seleção do tipo de instância. Especifique critérios de seleção de nós, como distribuição da zona de disponibilidade, filtragem do tipo de capacidade (sob demanda versus spot) ou rótulos de nós personalizados por meio do nodeAffinity campo. O sistema suporta restrições obrigatórias de posicionamento, uso requiredDuringSchedulingIgnoredDuringExecution e preferências opcionaispreferredDuringSchedulingIgnoredDuringExecution, fornecendo controle total sobre as decisões de agendamento de pods e mantendo a flexibilidade de implantação.

nota

Coletamos determinadas métricas operacionais de rotina para fornecer a disponibilidade essencial do serviço. A criação dessas métricas é totalmente automatizada e não envolve a revisão humana da carga de trabalho de inferência do modelo subjacente. Essas métricas estão relacionadas às operações de implantação, gerenciamento de recursos e registro de terminais.

Tópicos