Como a Veriff reduziu o tempo de implantação em 80% usando endpoints multimodelos do Amazon SageMaker | Amazon Web Services

Veriff é uma plataforma parceira de verificação de identidade para organizações inovadoras voltadas para o crescimento, incluindo pioneiras em serviços financeiros, FinTech, criptografia, jogos, mobilidade e mercados online. Eles fornecem tecnologia avançada que combina automação alimentada por IA com feedback humano, insights profundos e experiência.

A Veriff oferece uma infraestrutura comprovada que permite que seus clientes confiem nas identidades e atributos pessoais de seus usuários em todos os momentos relevantes da jornada do cliente. A Veriff conta com a confiança de clientes como Bolt, Deel, Monese, Starship, Super Awesome, Trustpilot e Wise.

Como uma solução baseada em IA, a Veriff precisa criar e executar dezenas de modelos de aprendizado de máquina (ML) de maneira econômica. Esses modelos variam de modelos leves baseados em árvore a modelos de visão computacional de aprendizado profundo, que precisam ser executados em GPUs para atingir baixa latência e melhorar a experiência do usuário. A Veriff também está atualmente adicionando mais produtos à sua oferta, visando uma solução hiperpersonalizada para seus clientes. Atender modelos diferentes para clientes diferentes aumenta a necessidade de uma solução escalonável de atendimento de modelos.

Nesta postagem, mostramos como a Veriff padronizou o fluxo de trabalho de implantação de modelo usando Amazon Sage Maker, reduzindo custos e tempo de desenvolvimento.

Desafios de infraestrutura e desenvolvimento

A arquitetura backend da Veriff é baseada em um padrão de microsserviços, com serviços executados em diferentes clusters Kubernetes hospedados na infraestrutura AWS. Essa abordagem foi usada inicialmente para todos os serviços da empresa, incluindo microsserviços que executam modelos caros de ML de visão computacional.

Alguns desses modelos exigiam implantação em instâncias de GPU. Consciente do custo comparativamente mais alto dos tipos de instância apoiados por GPU, a Veriff desenvolveu um solução personalizada no Kubernetes para compartilhar os recursos de uma determinada GPU entre diferentes réplicas de serviço. Uma única GPU normalmente tem VRAM suficiente para armazenar vários modelos de visão computacional da Veriff na memória.

Embora a solução tenha aliviado os custos da GPU, ela também veio com a restrição de que os cientistas de dados precisavam indicar antecipadamente quanta memória da GPU seu modelo exigiria. Além disso, o DevOps estava sobrecarregado com o provisionamento manual de instâncias de GPU em resposta aos padrões de demanda. Isso causou uma sobrecarga operacional e um provisionamento excessivo de instâncias, o que resultou em um perfil de custo abaixo do ideal.

Além do provisionamento de GPU, essa configuração também exigia que os cientistas de dados construíssem um wrapper de API REST para cada modelo, que era necessário para fornecer uma interface genérica para consumo de outros serviços da empresa e para encapsular o pré-processamento e o pós-processamento dos dados do modelo. Essas APIs exigiam código de nível de produção, o que tornava um desafio para os cientistas de dados produzir modelos.

A equipe da plataforma de ciência de dados da Veriff procurou formas alternativas para essa abordagem. O principal objetivo era apoiar os cientistas de dados da empresa numa melhor transição da investigação para a produção, fornecendo pipelines de implementação mais simples. O objetivo secundário era reduzir os custos operacionais de provisionamento de instâncias de GPU.

Visão geral da solução

Veriff precisava de uma nova solução que resolvesse dois problemas:

• Permita a construção de wrappers de API REST em torno de modelos de ML com facilidade
• Permitir o gerenciamento otimizado da capacidade da instância de GPU provisionada e, se possível, automaticamente

No final das contas, a equipe da plataforma de ML convergiu para a decisão de usar Endpoints multimodelo Sagemaker (MME). Esta decisão foi motivada pelo apoio do MME ao software da NVIDIA Servidor de Inferência Triton (um servidor focado em ML que facilita o empacotamento de modelos como APIs REST; a Veriff também já estava experimentando o Triton), bem como sua capacidade de gerenciar nativamente o escalonamento automático de instâncias de GPU por meio de políticas simples de escalonamento automático.

Dois MMEs foram criados na Veriff, um para encenação e outro para produção. Essa abordagem permite executar etapas de teste em um ambiente de teste sem afetar os modelos de produção.

MMEs SageMaker

O SageMaker é um serviço totalmente gerenciado que oferece aos desenvolvedores e cientistas de dados a capacidade de criar, treinar e implantar modelos de ML rapidamente. Os MMEs SageMaker fornecem uma solução escalável e econômica para implantar um grande número de modelos para inferência em tempo real. Os MMEs usam um contêiner de serviço compartilhado e uma frota de recursos que podem usar instâncias aceleradas, como GPUs, para hospedar todos os seus modelos. Isso reduz os custos de hospedagem maximizando a utilização do endpoint em comparação com o uso de endpoints de modelo único. Ele também reduz a sobrecarga de implantação porque o SageMaker gerencia o carregamento e o descarregamento de modelos na memória e os dimensiona com base nos padrões de tráfego do endpoint. Além disso, todos os endpoints em tempo real do SageMaker se beneficiam de recursos integrados para gerenciar e monitorar modelos, como incluir variantes de sombra, dimensionamento automáticoe integração nativa com Amazon CloudWatch (para mais informações, consulte Métricas do CloudWatch para implantações de endpoint de vários modelos).

Modelos de conjunto Triton personalizados

Houve vários motivos pelos quais a Veriff decidiu usar o Triton Inference Server, sendo os principais:

• Ele permite que os cientistas de dados criem APIs REST a partir de modelos, organizando arquivos de artefatos de modelo em um formato de diretório padrão (sem solução de código).
• É compatível com todas as principais estruturas de IA (PyTorch, Tensorflow, XGBoost e mais)
• Ele fornece otimizações de servidor e de baixo nível específicas de ML, como lote dinâmico de solicitações

O uso do Triton permite que os cientistas de dados implantem modelos com facilidade porque eles só precisam construir repositórios de modelos formatados em vez de escrever código para construir APIs REST (o Triton também suporta Modelos Python se a lógica de inferência personalizada for necessária). Isso diminui o tempo de implantação de modelos e dá aos cientistas de dados mais tempo para se concentrarem na construção de modelos em vez de implantá-los.

Outra característica importante do Triton é que ele permite construir conjuntos de modelos, que são grupos de modelos encadeados. Esses conjuntos podem ser executados como se fossem um único modelo Triton. Atualmente, a Veriff emprega esse recurso para implantar lógica de pré-processamento e pós-processamento com cada modelo de ML usando modelos Python (conforme mencionado anteriormente), garantindo que não haja incompatibilidades nos dados de entrada ou na saída do modelo quando os modelos são usados ​​na produção.

Veja a seguir a aparência de um repositório de modelo Triton típico para esta carga de trabalho:

A model.py arquivo contém código de pré-processamento e pós-processamento. Os pesos do modelo treinado estão no screen_detection_inferencer diretório, na versão do modelo 1 (o modelo está no formato ONNX neste exemplo, mas também pode ser no formato TensorFlow, PyTorch ou outros). A definição do modelo de conjunto está no screen_detection_pipeline diretório, onde as entradas e saídas entre as etapas são mapeadas em um arquivo de configuração.

Dependências adicionais necessárias para executar os modelos Python são detalhadas em um requirements.txt arquivo e precisa ser compactado com conda para construir um ambiente Conda (python_env.tar.gz). Para obter mais informações, consulte Gerenciando bibliotecas e tempo de execução do Python. Além disso, os arquivos de configuração das etapas do Python precisam apontar para python_env.tar.gz usando o EXECUTION_ENV_PATH Directiva.

A pasta do modelo precisa então ser compactada em TAR e renomeada usando model_version.txt. Finalmente, o resultante <model_name>_<model_version>.tar.gz arquivo é copiado para o Serviço de armazenamento simples da Amazon (Amazon S3) conectado ao MME, permitindo que o SageMaker detecte e atenda o modelo.

Versionamento de modelo e implantação contínua

Como a seção anterior deixou claro, construir um repositório de modelo Triton é simples. No entanto, executar todas as etapas necessárias para implantá-lo é tedioso e sujeito a erros, se executado manualmente. Para superar isso, a Veriff construiu um monorepo contendo todos os modelos a serem implantados nas MMEs, onde os cientistas de dados colaboram em uma abordagem semelhante ao Gitflow. Este monorepo possui os seguintes recursos:

• É gerenciado usando Calças.
• Ferramentas de qualidade de código como Black e MyPy são aplicadas usando Pants.
• Testes unitários são definidos para cada modelo, que verificam se a saída do modelo é a saída esperada para uma determinada entrada do modelo.
• Os pesos do modelo são armazenados junto com os repositórios de modelos. Esses pesos podem ser arquivos binários grandes, então DVC é usado para sincronizá-los com o Git de maneira versionada.

Este monorepo está integrado a uma ferramenta de integração contínua (CI). Para cada novo push para o repositório ou novo modelo, as seguintes etapas são executadas:

1. Passe na verificação de qualidade do código.
2. Baixe os pesos do modelo.
3. Construa o ambiente Conda.
4. Crie um servidor Triton usando o ambiente Conda e use-o para processar solicitações definidas em testes unitários.
5. Crie o arquivo TAR do modelo final (<model_name>_<model_version>.tar.gz).

Essas etapas garantem que os modelos tenham a qualidade necessária para implantação, portanto, para cada envio para uma ramificação do repositório, o arquivo TAR resultante é copiado (em outra etapa do CI) para o bucket S3 de teste. Quando os push são feitos na ramificação principal, o arquivo do modelo é copiado para o bucket S3 de produção. O diagrama a seguir descreve esse sistema CI/CD.

Benefícios de custo e velocidade de implantação

O uso de MMEs permite que a Veriff use uma abordagem monorepo para implantar modelos em produção. Em resumo, o novo fluxo de trabalho de implantação de modelo da Veriff consiste nas seguintes etapas:

1. Crie uma ramificação no monorepo com o novo modelo ou versão do modelo.
2. Defina e execute testes unitários em uma máquina de desenvolvimento.
3. Envie o branch quando o modelo estiver pronto para ser testado no ambiente de teste.
4. Mesclar o branch no main quando o modelo estiver pronto para ser usado na produção.

Com esta nova solução implementada, a implantação de um modelo na Veriff é uma parte simples do processo de desenvolvimento. O tempo de desenvolvimento do novo modelo diminuiu de 10 dias para uma média de 2 dias.

O provisionamento de infraestrutura gerenciada e os recursos de escalonamento automático do SageMaker trouxeram benefícios adicionais à Veriff. Eles usaram o ChamadasPorInstância Métrica do CloudWatch para escalar de acordo com padrões de tráfego, economizando custos sem sacrificar a confiabilidade. Para definir o valor limite da métrica, eles realizaram testes de carga no endpoint de preparo para encontrar a melhor relação entre latência e custo.

Depois de implantar sete modelos de produção para MMEs e analisar os gastos, a Veriff relatou uma redução de custo de 75% no modelo de GPU servindo em comparação com a solução original baseada em Kubernetes. Os custos operacionais também foram reduzidos, porque a carga de provisionamento manual de instâncias foi retirada dos engenheiros de DevOps da empresa.

Conclusão

Nesta postagem, revisamos por que a Veriff escolheu MMEs Sagemaker em vez da implantação de modelo autogerenciado no Kubernetes. O SageMaker assume o trabalho pesado indiferenciado, permitindo que a Veriff diminua o tempo de desenvolvimento do modelo, aumente a eficiência da engenharia e reduza drasticamente o custo da inferência em tempo real, mantendo o desempenho necessário para suas operações críticas para os negócios. Por fim, apresentamos o pipeline de CI/CD de implantação de modelo simples, mas eficaz, e o mecanismo de versionamento de modelo da Veriff, que pode ser usado como uma implementação de referência para combinar as melhores práticas de desenvolvimento de software e MMEs SageMaker. Você pode encontrar exemplos de código sobre hospedagem de vários modelos usando MMEs SageMaker em GitHub.

---

Sobre os autores

Ricard Borras é sênior de aprendizado de máquina na Veriff, onde lidera os esforços de MLOps na empresa. Ele ajuda cientistas de dados a construir produtos de IA/ML melhores e mais rápidos, construindo uma plataforma de ciência de dados na empresa e combinando várias soluções de código aberto com serviços AWS.

João moura é arquiteto de soluções especialista em IA/ML na AWS, com sede na Espanha. Ele ajuda os clientes com modelos de aprendizado profundo, treinamento em larga escala e otimização de inferência, além de construir plataformas de ML em grande escala na AWS de maneira mais ampla.

Miguel Ferreira trabalha como arquiteto de soluções sênior na AWS com sede em Helsinque, Finlândia. AI/ML sempre foi um interesse e ele ajudou vários clientes a integrar o Amazon SageMaker em seus fluxos de trabalho de ML.

• Conteúdo com tecnologia de SEO e distribuição de relações públicas. Seja amplificado hoje.
• PlatoData.Network Gerativa Vertical Ai. Capacite-se. Acesse aqui.
• PlatoAiStream. Inteligência Web3. Conhecimento Amplificado. Acesse aqui.
• PlatãoESG. Carbono Tecnologia Limpa, Energia, Ambiente, Solar, Gestão de resíduos. Acesse aqui.
• PlatoHealth. Inteligência em Biotecnologia e Ensaios Clínicos. Acesse aqui.
• Fonte: https://aws.amazon.com/blogs/machine-learning/how-veriff-decreased-deployment-time-by-80-using-amazon-sagemaker-multi-model-endpoints/