Como dimensionar a inferência de aprendizado de máquina para casos de uso de SaaS multilocatários

Republicado por Platão

seguidores: 0

Este post foi escrito em parceria com Sowmya Manusani, engenheiro sênior de aprendizado de máquina da Zendesk

Zendesk é uma empresa de SaaS que cria software de suporte, vendas e envolvimento do cliente para todos, com a simplicidade como base. Ela prospera fazendo com que mais de 170,000 empresas em todo o mundo atendam suas centenas de milhões de clientes com eficiência. A equipe de Machine Learning da Zendcaesk é responsável por aprimorar as equipes de experiência do cliente para alcançar o seu melhor. Ao combinar o poder dos dados e das pessoas, a Zendesk oferece produtos inteligentes que tornam seus clientes mais produtivos ao automatizar o trabalho manual.

A Zendesk desenvolve produtos de ML desde 2015, incluindo Bot de resposta, Previsão de satisfação, Dicas de conteúdo, Macros sugeridas, e muitos mais. Nos últimos anos, com o crescimento do aprendizado profundo, especialmente em PNL, eles viram muitas oportunidades para automatizar fluxos de trabalho e auxiliar os agentes no suporte a seus clientes com soluções Zendesk. Atualmente, a Zendesk usa o TensorFlow e o PyTorch para criar modelos de aprendizado profundo.

Clientes como a Zendesk construíram negócios bem-sucedidos de software como serviço (SaaS) de alta escala na Amazon Web Services (AWS). Um fator-chave para um modelo de negócios SaaS bem-sucedido é a capacidade de aplicar multilocação no aplicativo e na infraestrutura. Isso permite eficiências operacionais e de custo porque o aplicativo só precisa ser construído uma vez, mas pode ser usado muitas vezes e a infraestrutura pode ser compartilhada. Vemos muitos clientes criando sistemas multilocatários seguros e econômicos na AWS em todas as camadas da pilha, desde computação, armazenamento, banco de dados até rede, e agora vemos clientes precisando aplicá-lo ao aprendizado de máquina (ML ).

Fazendo a difícil troca entre reutilização de modelo e hiperpersonalização

A multilocação para empresas SaaS normalmente significa que um único aplicativo é reutilizado entre muitos usuários (clientes SaaS). Isso cria eficiências de custo e reduz a sobrecarga operacional. No entanto, os modelos de aprendizado de máquina às vezes precisam ser personalizados com um alto grau de especificidade (hiperpersonalizados) para fazer previsões precisas. Isso significa que o paradigma SaaS “construir uma vez, usar muitas vezes” nem sempre pode ser aplicado ao ML se os modelos tiverem especificidade. Tomemos, por exemplo, o caso de uso de plataformas de suporte ao cliente. O idioma que os usuários incluem em um ticket de suporte varia dependendo se é um problema de compartilhamento de carona (“a viagem demorou demais”) ou um problema de compra de roupas (“descoloração ao lavar”). Nesse caso de uso, melhorar a precisão da previsão da melhor ação de correção pode exigir o treinamento de um modelo de processamento de linguagem natural (NLP) em um conjunto de dados específico para um domínio de negócios ou uma indústria vertical. A Zendesk enfrenta exatamente esse desafio ao tentar alavancar o ML em suas soluções. Eles precisavam criar milhares de modelos de ML altamente personalizados, cada um adaptado para um cliente específico. Para resolver esse desafio de implantar milhares de modelos de forma econômica, a Zendesk recorreu ao Amazon SageMaker.

Neste post, mostramos como usar alguns dos recursos mais recentes do Amazon Sage Maker, um serviço de aprendizado de máquina totalmente gerenciado, para criar um recurso de inferência de ML multilocatário. Também compartilhamos um exemplo do mundo real de como a Zendesk alcançou o mesmo resultado com sucesso ao implantar um meio-termo entre a capacidade de oferecer suporte à hiperpersonalização em seus modelos de ML e o uso compartilhado e econômico de infraestrutura usando endpoints multimodelo SageMaker ( MME).

Pontos de extremidade de vários modelos do SageMaker

Os endpoints de vários modelos do SageMaker permitem que você implante vários modelos por trás de um único endpoint de inferência que pode conter uma ou mais instâncias. Cada instância é projetada para carregar e servir vários modelos até sua capacidade de memória e CPU. Com essa arquitetura, uma empresa de SaaS pode quebrar o custo linearmente crescente de hospedar vários modelos e obter a reutilização da infraestrutura consistente com o modelo de multilocação aplicado em outras partes da pilha de aplicativos.

O diagrama a seguir ilustra a arquitetura de um endpoint multimodelo SageMaker.

O endpoint multimodelo SageMaker carrega dinamicamente modelos de Serviço de armazenamento simples da Amazon (Amazon S3) quando invocado, em vez de baixar todos os modelos quando o endpoint é criado pela primeira vez. Como resultado, uma invocação inicial a um modelo pode apresentar latência de inferência mais alta do que as inferências subsequentes, que são concluídas com baixa latência. Se o modelo já estiver carregado no contêiner quando invocado, a etapa de download será ignorada e o modelo retornará as inferências com baixa latência. Por exemplo, suponha que você tenha um modelo que é usado apenas algumas vezes por dia. Ele é carregado automaticamente sob demanda, enquanto os modelos acessados com frequência são retidos na memória e invocados com latência consistentemente baixa.

Vamos examinar mais de perto como a Zendesk usou o SageMaker MME para obter uma implantação de ML econômica e em grande escala com o recurso ML de macros sugeridas.

Por que a Zendesk criou modelos hiperpersonalizados

Os clientes da Zendesk estão espalhados globalmente em diferentes verticais do setor com diferentes semânticas de tíquetes de suporte. Portanto, para atender melhor seus clientes, eles geralmente precisam criar modelos personalizados que são treinados em dados de tíquetes de suporte específicos do cliente para identificar corretamente a intenção, macros e muito mais.

Em outubro de 2021, eles lançaram um novo recurso NLP ML, Suggested Macros, que recomenda macros (ações predefinidas) com base em milhares de previsões de modelos específicos do cliente. A equipe de ML da Zendesk construiu um modelo de classificador NLP baseado em TensorFlow treinado a partir do histórico anterior de conteúdo de tickets e macros por cliente. Com esses modelos disponíveis, uma previsão de macro é recomendada sempre que um agente visualizar o ticket (conforme mostrado na captura de tela a seguir), o que auxilia o agente a atender os clientes rapidamente. Como as macros são específicas para os clientes, o Zendesk precisa de modelos específicos do cliente para fornecer previsões precisas.

Sob o capô das macros sugeridas do Zendesk

Os modelos de macros sugeridos são redes neurais baseadas em NLP que têm cerca de 7 a 15 MB de tamanho. O principal desafio é colocar milhares desses modelos em produção com soluções econômicas, confiáveis e escaláveis.

Cada modelo tem padrões de tráfego diferentes, com um mínimo de duas solicitações por segundo e um pico de centenas de solicitações por segundo, atendendo milhões de previsões por dia com uma latência do modelo de aproximadamente 100 milissegundos quando o modelo está disponível na memória. Os endpoints do SageMaker são implantados em várias regiões da AWS, atendendo a milhares de solicitações por minuto por endpoint.

Com sua capacidade de hospedar vários modelos em um único endpoint, o SageMaker ajudou o Zendesk a reduzir a sobrecarga de implantação e criar uma solução econômica em comparação com a implantação de um endpoint de modelo único por cliente. A compensação aqui é menos controle no gerenciamento por modelo; no entanto, essa é uma área em que a Zendesk está colaborando com a AWS para melhorar os endpoints de vários modelos.

Um dos recursos de vários modelos do SageMaker é o carregamento lento de modelos, ou seja, os modelos são carregados na memória quando chamados pela primeira vez. Isso é para otimizar a utilização da memória; no entanto, causa picos de tempo de resposta no primeiro carregamento, o que pode ser visto como um problema de partida a frio. Para Macros Sugeridas, isso foi um desafio; no entanto, o Zendesk superou isso implementando uma funcionalidade de pré-carregamento sobre o provisionamento de endpoint do SageMaker para carregar os modelos na memória antes de atender ao tráfego de produção. Em segundo lugar, o MME descarrega da memória modelos usados com pouca frequência, portanto, para obter uma baixa latência consistente em todos os modelos e evitar que “vizinhos barulhentos” afetem outros modelos menos ativos, a Zendesk está colaborando com a AWS para adicionar novos recursos, discutidos mais adiante no post, para habilitar gerenciamento mais explícito por modelo. Além disso, como solução provisória, a Zendesk dimensionou corretamente a frota de MME para minimizar o descarregamento de muitos modelos. Com isso, o Zendesk é capaz de servir previsões para todos os seus clientes com baixa latência, em torno de 100 milissegundos, e ainda obter 90% de economia de custos quando comparado aos endpoints dedicados.

No dimensionamento correto do MME, a Zendesk observou durante o teste de carga que ter um número maior de instâncias menores (viés no dimensionamento horizontal) atrás do MME era uma escolha melhor do que ter menos instâncias de memória maiores (escalonamento vertical). A Zendesk observou que o empacotamento de muitos modelos (além de 500 modelos do TensorFlow em seu caso) em uma única instância de memória grande não funcionou bem porque a memória não é o único recurso em uma instância que pode ser um gargalo. Mais especificamente, eles observaram que o TensorFlow gerou vários threads (3 x vCPUs de instância total) por modelo, portanto, carregar mais de 500 modelos em uma única instância fez com que os limites de nível do kernel fossem violados no número máximo de threads que poderiam ser gerados em uma instância. Outro problema com o uso de menos instâncias maiores ocorreu quando o Zendesk experimentou limitação (como um mecanismo de segurança) em algumas instâncias por trás do MME porque a taxa de invocação de modelo exclusivo por segundo excedeu o que o Servidor de vários modelos (MMS) em uma única instância pode ser tratada com segurança sem deixar a instância desativada. Esse foi outro problema que foi resolvido com o uso de mais e menores instâncias.

Do ponto de vista da observabilidade, que é um componente crucial de qualquer aplicativo de produção, Amazon CloudWatch métricas como invocações, CPU, utilização de memória e métricas específicas de vários modelos, como modelos carregados na memória, tempo de carregamento do modelo, tempo de espera de carregamento do modelo e acerto do cache do modelo, são informativas. Especificamente, o detalhamento da latência do modelo ajudou o Zendesk a entender o problema da inicialização a frio e seu impacto.

Sob o capô do escalonamento automático do MME

Atrás de cada endpoint multimodelo, há instâncias de hospedagem de modelo, conforme descrito no diagrama a seguir. Essas instâncias carregam e despejam vários modelos de e para a memória com base nos padrões de tráfego para os modelos.

O SageMaker continua a rotear solicitações de inferência de um modelo para a instância em que o modelo já está carregado, de modo que as solicitações sejam atendidas da cópia do modelo em cache (consulte o diagrama a seguir, que mostra o caminho da solicitação para a primeira solicitação de previsão versus a solicitação de previsão em cache caminho). No entanto, se o modelo receber muitas solicitações de invocação e houver instâncias adicionais para o endpoint multimodelo, o SageMaker roteará algumas solicitações para outra instância para acomodar o aumento. Para aproveitar o dimensionamento automatizado de modelos no SageMaker, certifique-se de ter configuração do escalonamento automático da instância para provisionar capacidade de instância adicional. Configure sua política de escalabilidade em nível de endpoint com parâmetros personalizados ou invocações por minuto (recomendado) para adicionar mais instâncias à frota de endpoints.

Casos de uso mais adequados para MME

Os endpoints de vários modelos do SageMaker são adequados para hospedar um grande número de modelos semelhantes que você pode servir por meio de um contêiner de serviço compartilhado e não precisa acessar todos os modelos ao mesmo tempo. O MME é mais adequado para modelos semelhantes em tamanho e latências de invocação. Alguma variação no tamanho do modelo é aceitável; por exemplo, os modelos do Zendesk variam de 10 a 50 Mb, o que funciona bem, mas variações de tamanho que são um fator de 10, 50 ou 100 vezes maiores não são adequadas. Modelos maiores podem causar um número maior de carregamentos e descarregamentos de modelos menores para acomodar espaço de memória suficiente, o que pode resultar em latência adicional no endpoint. As diferenças nas características de desempenho de modelos maiores também podem consumir recursos como CPU de forma desigual, o que pode afetar outros modelos na instância.

O MME também foi projetado para co-hospedar modelos que usam a mesma estrutura de ML porque usam o contêiner compartilhado para carregar vários modelos. Portanto, se você tiver uma combinação de estruturas de ML em sua frota de modelos (como PyTorch e TensorFlow), os endpoints dedicados do SageMaker ou a hospedagem de vários contêineres são a melhor escolha. Por fim, o MME é adequado para aplicativos que podem tolerar uma penalidade ocasional de latência de inicialização a frio porque modelos usados com pouca frequência podem ser descarregados em favor de modelos invocados com frequência. Se você tiver uma longa cauda de modelos acessados com pouca frequência, um endpoint multimodelo pode atender a esse tráfego com eficiência e permitir economias de custo significativas.

Resumo

Neste post, você aprendeu como SaaS e multilocação se relacionam com ML e como os endpoints multimodelo SageMaker permitem multilocação e economia para inferência de ML. Você aprendeu sobre o caso de uso multilocatário de modelos de ML por cliente da Zendesk e como eles hospedavam milhares de modelos de ML no SageMaker MME para o recurso Macros sugeridos e obtiveram 90% de economia de custo em inferência quando comparados a endpoints dedicados. Os casos de uso de hiperpersonalização podem exigir milhares de modelos de ML, e o MME é uma opção econômica para esse caso de uso. Continuaremos a fazer melhorias no MME para permitir que você hospede modelos com baixa latência e com controles mais granulares para cada modelo personalizado. Para começar com o MME, consulte Hospede vários modelos em um contêiner atrás de um endpoint.

Sobre os autores

Syed Jaffry é arquiteto de soluções sênior da AWS. Ele trabalha com uma variedade de empresas, de organizações de médio porte a grandes empresas, de serviços financeiros a ISVs, ajudando-os a criar e operar aplicativos seguros, resilientes, escaláveis e de alto desempenho na nuvem.

Sowmya Manusani é engenheiro sênior de aprendizado de máquina da Zendesk. Ela trabalha na produção de recursos de aprendizado de máquina baseados em NLP que se concentram em melhorar a produtividade do agente para milhares de clientes do Zendesk Enterprise. Ela tem experiência na criação de pipelines de treinamento automatizados para milhares de modelos personalizados e em atendê-los usando aplicativos seguros, resilientes, escaláveis e de alto desempenho. Em seu tempo livre, ela gosta de resolver quebra-cabeças e tentar pintar.

Saurabh Trikande é gerente de produto sênior da Amazon SageMaker Inference. Ele é apaixonado por trabalhar com clientes e tornar o aprendizado de máquina mais acessível. Em seu tempo livre, Saurabh gosta de caminhar, aprender sobre tecnologias inovadoras, seguir o TechCrunch e passar tempo com sua família.

Deepti Ragha é engenheiro de desenvolvimento de software na equipe do Amazon SageMaker. Seu trabalho atual se concentra na criação de recursos para hospedar modelos de aprendizado de máquina com eficiência. Em seu tempo livre, ela gosta de viajar, fazer caminhadas e cultivar plantas.