Obtenha hospedagem de baixa latência para modelos de ML baseados em árvore de decisão no NVIDIA Triton Inference Server no Amazon SageMaker

As implantações do modelo de aprendizado de máquina (ML) podem ter requisitos de desempenho e latência muito exigentes para as empresas atuais. Casos de uso como detecção de fraudes e posicionamento de anúncios são exemplos em que os milissegundos são importantes e críticos para o sucesso dos negócios. Contratos de nível de serviço (SLAs) rigorosos precisam ser atendidos e uma solicitação típica pode exigir várias etapas, como pré-processamento, transformação de dados, lógica de seleção de modelo, agregação de modelo e pós-processamento. Em escala, isso geralmente significa manter um grande volume de tráfego enquanto mantém baixa latência. Padrões de design comuns incluem pipelines de inferência serial, conjuntos (scatter-gather) e fluxos de trabalho de lógica de negócios, que resultam na realização de todo o fluxo de trabalho da solicitação como um Directed Acyclic Graph (DAG). No entanto, à medida que os fluxos de trabalho se tornam mais complexos, isso pode levar a um aumento nos tempos de resposta gerais, o que, por sua vez, pode afetar negativamente a experiência do usuário final e comprometer as metas de negócios. A Triton pode abordar esses casos de uso em que vários modelos são compostos em um pipeline com tensores de entrada e saída conectados entre eles, ajudando você a lidar com essas cargas de trabalho.

Ao avaliar seus objetivos em relação à inferência do modelo de ML, muitas opções podem ser consideradas, mas poucas são tão capazes e comprovadas quanto Amazon Sage Maker de Servidor de Inferência Triton. O SageMaker com Triton Inference Server tem sido uma escolha popular para muitos clientes porque foi desenvolvido especificamente para maximizar o rendimento e a utilização de hardware com latência de inferência ultrabaixa (milissegundos de um dígito). Possui uma ampla variedade de estruturas de ML suportadas (incluindo TensorFlow, PyTorch, ONNX, XGBoost e NVIDIA TensorRT) e back-ends de infraestrutura, incluindo GPUs NVIDIA, CPUs e Inferência da AWS. Além disso, o Triton Inference Server é integrado ao SageMaker, um serviço de ML de ponta a ponta totalmente gerenciado, oferecendo opções de inferência em tempo real para hospedagem de modelos.

Nesta postagem, explicamos a implantação de uma carga de trabalho de conjunto de detecção de fraudes no SageMaker com o Triton Inference Server.

Visão geral da solução

É essencial para qualquer projeto ter uma lista de requisitos e uma estimativa de esforço, a fim de aproximar o custo total do projeto. É importante estimar o retorno do investimento (ROI) que suporta a decisão de uma organização. Algumas considerações a serem consideradas ao mover uma carga de trabalho para o Triton incluem:

A estimativa de esforço é fundamental no desenvolvimento de software e sua medição geralmente é baseada em entradas incompletas, incertas e ruidosas. As cargas de trabalho de ML não são diferentes. Vários fatores afetarão uma arquitetura para inferência de ML, alguns dos quais incluem:

• Orçamento de latência do lado do cliente – Especifica o tempo de espera máximo aceitável de ida e volta do lado do cliente para uma resposta de inferência, geralmente expresso em percentis. Para cargas de trabalho que exigem um orçamento de latência próximo a dezenas de milissegundos, as transferências de rede podem se tornar caras, portanto, o uso de modelos na borda seria mais adequado.
• Tamanho da distribuição da carga de dados – Carga útil, muitas vezes referida como Corpo da mensagem, são os dados de solicitação transmitidos do cliente para o modelo, bem como os dados de resposta transmitidos do modelo para o cliente. O tamanho da carga útil geralmente tem um grande impacto na latência e deve ser levado em consideração.
• Formato de dados – Isso especifica como a carga útil é enviada para o modelo de ML. O formato pode ser legível por humanos, como JSON e CSV, mas também existem formatos binários, que geralmente são compactados e de tamanho menor. Esta é uma compensação entre a sobrecarga de compactação e o tamanho da transferência, o que significa que os ciclos e a latência da CPU são adicionados para compactar ou descompactar, a fim de economizar bytes transferidos pela rede. Esta postagem mostra como utilizar os formatos JSON e binário.
• Pilha de software e componentes necessários – Uma pilha é uma coleção de componentes que operam juntos para dar suporte a um aplicativo de ML, incluindo sistema operacional, tempos de execução e camadas de software. O Triton vem com estruturas de ML populares integradas, chamadas backends, como ONNX, TensorFlow, FIL, OpenVINO, Python nativo e outros. Você também pode criar um back-end personalizado para seus próprios componentes caseiros. Esta postagem aborda um modelo XGBoost e pré-processamento de dados, que migramos para os back-ends FIL e Python Triton fornecidos pela NVIDIA, respectivamente.

Todos esses fatores devem desempenhar um papel vital na avaliação do desempenho de suas cargas de trabalho, mas neste caso de uso nos concentramos no trabalho necessário para mover seus modelos de ML para serem hospedados no SageMaker com o Triton Inference Server. Especificamente, usamos um exemplo de um conjunto de detecção de fraudes composto por um modelo XGBoost com lógica de pré-processamento escrito em Python.

Servidor de inferência NVIDIA Triton

O Triton Inference Server foi projetado desde o início para permitir que as equipes implantem, executem e dimensionem modelos de IA treinados a partir de qualquer estrutura em infraestrutura baseada em GPU ou CPU. Além disso, ele foi otimizado para oferecer inferência de alto desempenho em escala com recursos como lotes dinâmicos, execuções simultâneas, configuração de modelo ideal, conjunto de modelos e suporte para entradas de streaming.

O diagrama a seguir mostra um exemplo de pipeline do conjunto NVIDIA Triton.

As cargas de trabalho devem levar em consideração os recursos que a Triton fornece junto com a hospedagem SageMaker para maximizar os benefícios oferecidos. Por exemplo, Triton suporta HTTP, bem como um API C, que permitem flexibilidade e otimização de carga útil quando necessário. Como mencionado anteriormente, o Triton suporta várias estruturas populares prontas para uso, incluindo TensorFlow, PyTorch, ONNX, XGBoost e NVIDIA TensorRT. Esses frameworks são suportados por back-ends Triton e, no caso raro de um back-end não oferecer suporte ao seu caso de uso, Triton permite que você implemente o seu próprio e integre-o facilmente.

O diagrama a seguir mostra um exemplo da arquitetura NVIDIA Triton.

NVIDIA Triton no SageMaker

Hospedagem SageMaker services são o conjunto de recursos do SageMaker destinados a facilitar a implantação e o atendimento do modelo. Ele oferece uma variedade de opções para implantar, dimensionar automaticamente, monitorar e otimizar facilmente modelos de ML adaptados para diferentes casos de uso. Isso significa que você pode otimizar suas implantações para todos os tipos de padrões de uso, desde persistentes e sempre disponíveis com opções sem servidor, até necessidades transitórias, de longa duração ou de inferência em lote.

Sob o guarda-chuva de hospedagem do SageMaker, também está o conjunto de Contêineres de Aprendizado Profundo (DLCs) de inferência do SageMaker, que vêm pré-empacotados com o software de servidor de modelo apropriado para sua estrutura de ML compatível correspondente. Isso permite que você obtenha alto desempenho de inferência sem configuração de servidor de modelo, que geralmente é o aspecto técnico mais complexo da implantação de modelo e, em geral, não faz parte do conjunto de habilidades de um cientista de dados. O servidor de inferência Triton agora é disponível em DLCs do SageMaker.

Essa amplitude de opções, modularidade e facilidade de uso de diferentes estruturas de serviço tornam o SageMaker e o Triton uma combinação poderosa.

Suporte de back-end NVIDIA FIL

Com o 22.05 lançamento da versão de Triton, a NVIDIA agora oferece suporte a modelos de floresta treinados por várias estruturas de ML populares, incluindo XGBoost, LightGBM, Scikit-learn e cuML. Ao usar o backend FIL para Triton, você deve garantir que os artefatos de modelo fornecidos sejam suportados. Por exemplo, FIL suporta model_type xgboost, xgboost_json, lightgbmou treelite_checkpoint, indicando se o modelo fornecido está no formato binário XGBoost, formato XGBoost JSON, formato de texto LightGBM ou formato binário Treelite, respectivamente.

Esse suporte de backend é essencial para usarmos em nosso exemplo porque o FIL suporta modelos XGBoost. A única consideração a ser verificada é garantir que o modelo que implantamos seja compatível com formatos binários ou JSON.

Além de garantir que você tenha o formato de modelo adequado, outras considerações devem ser tomadas. O back-end FIL para Triton oferece opções configuráveis ​​para que os desenvolvedores ajustem suas cargas de trabalho e otimizem o desempenho da execução do modelo. A configuração dynamic_batching permite que o Triton mantenha solicitações do lado do cliente e as lote no lado do servidor, a fim de usar eficientemente a computação paralela do FIL para inferir todo o lote juntos. A opção max_queue_delay_microseconds oferece um controle à prova de falhas de quanto tempo Triton espera para formar um lote. O FIL vem com o explicador Shapley, que pode ser ativado pela configuração treeshap_output; no entanto, você deve ter em mente que as saídas Shapley prejudicam o desempenho devido ao tamanho da saída. Outro aspecto importante é storage_type a fim de compensar entre a pegada de memória e o tempo de execução. Por exemplo, usar o armazenamento como SPARSE pode reduzir o consumo de memória, enquanto o DENSE pode reduzir o desempenho de execução do modelo às custas de maior uso de memória. Decidir a melhor escolha para cada um deles depende de sua carga de trabalho e seu orçamento de latência, por isso recomendamos uma análise mais profunda de todas as opções no Perguntas frequentes sobre o back-end do FIL e os votos de lista de configurações disponíveis em FIL.

Etapas para hospedar um modelo no triton

Vejamos nosso caso de uso de detecção de fraude como um exemplo do que considerar ao mover uma carga de trabalho para a Triton.

Identifique sua carga de trabalho

Neste caso de uso, temos um modelo de detecção de fraudes utilizado durante o processo de checkout de um cliente de varejo. O pipeline de inferência está usando um algoritmo XGBoost com lógica de pré-processamento que inclui preparação de dados para pré-processamento.

Identifique as métricas de desempenho atuais e alvo e outras metas que podem ser aplicadas

Você pode achar que seu tempo de inferência de ponta a ponta está demorando muito para ser aceitável. Seu objetivo pode ser passar de dezenas de milissegundos de latência para latência de um dígito para o mesmo volume de solicitações e respectiva taxa de transferência. Você determina que a maior parte do tempo é consumida pelo pré-processamento de dados e pelo modelo XGBoost. Outros fatores, como o tamanho da rede e da carga útil, desempenham um papel mínimo na sobrecarga associada ao tempo de inferência de ponta a ponta.

Trabalhe para trás para determinar se a Triton pode hospedar sua carga de trabalho com base em seus requisitos

Para determinar se a Triton pode atender às suas necessidades, você deve prestar atenção a duas áreas principais de preocupação. A primeira é garantir que o Triton possa servir com uma opção de front-end aceitável, como HTTP ou API C.

Conforme mencionado anteriormente, também é fundamental determinar se o Triton oferece suporte a um back-end que possa servir seus artefatos. Triton suporta uma série de backends que são feitos sob medida para suportar vários frameworks como PyTorch e TensorFlow. Verifique se seus modelos são compatíveis e se você tem o formato de modelo adequado que a Triton espera. Para fazer isso, primeiro verifique quais formatos de modelo o backend Triton suporta. Em muitos casos, isso não requer nenhuma alteração no modelo. Em outros casos, seu modelo pode exigir transformação para um formato diferente. Dependendo do formato de origem e destino, existem várias opções, como transformar um Arquivo de picles do Python para usar o formato de ponto de verificação binário do Treelite.

Para este caso de uso, determinamos o FIL back-end pode suportar o modelo XGBoost sem necessidade de alterações e que podemos usar o back-end Python para o pré-processamento. Com o recurso de conjunto do Triton, você pode otimizar ainda mais sua carga de trabalho evitando chamadas de rede caras entre instâncias de hospedagem.

Crie um plano e estime o esforço necessário para usar o Triton para hospedagem

Vamos falar sobre o plano de transferir seus modelos para Triton. Cada implantação do Triton requer o seguinte:

• Artefatos de modelo exigidos pelos back-ends do Triton
• Arquivos de configuração do Triton
• Uma pasta de repositório de modelo com a estrutura adequada

Mostramos um exemplo de como criar essas dependências de implantação posteriormente neste post.

Execute o plano e valide os resultados

Depois de criar os arquivos e artefatos necessários no repositório de modelo estruturado corretamente, você precisa ajustar sua implantação e testá-la para validar que agora atingiu suas métricas de destino.

Neste ponto, você pode usar Recomendador de inferência do SageMaker para determinar qual tipo de instância de endpoint é melhor para você com base em seus requisitos. Além disso, a Triton fornece ferramentas para fazer otimizações de compilação para obter melhor desempenho.

Implementação

Agora vamos ver os detalhes de implementação. Para isso preparamos dois cadernos que dão um exemplo do que se pode esperar. o primeiro caderno mostra o treinamento do modelo XGBoost fornecido, bem como a lógica de pré-processamento usada para treinamento e tempo de inferência. o segundo caderno mostra como preparamos os artefatos necessários para implantação no Triton.

O primeiro notebook mostra um notebook existente que sua organização tem que usa o RÁPIDOS conjunto de bibliotecas e o kernel RAPIDS Conda. Essa instância é executada em um tipo de instância G4DN fornecido pela AWS, que é acelerado por GPU usando processadores NVIDIA T4.

As tarefas de pré-processamento neste exemplo se beneficiam da aceleração de GPU e usam intensamente as bibliotecas cuML e cuDF. Um exemplo disso está no código a seguir, onde mostramos a codificação de rótulo categórico usando cuML. Também geramos um label_encoders.pkl arquivo que podemos usar para serializar os codificadores e usá-los para pré-processamento durante o tempo de inferência.

O primeiro notebook conclui treinando nosso modelo XGBoost e salvando os artefatos de acordo.

Nesse cenário, o código de treinamento já existia e nenhuma alteração é necessária para o modelo no momento do treinamento. Além disso, embora tenhamos usado aceleração de GPU para pré-processamento durante o treinamento, planejamos usar CPUs para pré-processamento no momento da inferência. Explicamos mais adiante no post.

Vamos agora passar para o segundo notebook e relembrar o que precisamos para uma implantação bem-sucedida do Triton.

Primeiro, precisamos dos artefatos de modelo exigidos pelos back-ends. Os arquivos que precisamos criar para este conjunto incluem:

• Artefatos de pré-processamento (model.py, label_encoders.pkl)
• Artefatos do modelo XGBoost (xgboost.json)

O backend Python no Triton exige que usemos um ambiente Conda como dependência. Nesse caso, usamos o backend Python para pré-processar os dados brutos antes de alimentá-los no modelo XGBoost que está sendo executado no backend FIL. Embora originalmente tenhamos usado as bibliotecas RAPIDS cuDF e cuML para fazer o pré-processamento de dados (conforme mencionado anteriormente usando nossa GPU), aqui usamos Pandas e Scikit-learn como dependências de pré-processamento para tempo de inferência (usando nossa CPU). Fazemos isso por três motivos:

• Para mostrar como criar um ambiente Conda para suas dependências e como empacotá-lo no formato esperado pelo backend Python da Triton.
• Ao mostrar o modelo de pré-processamento em execução no backend Python na CPU enquanto o modelo XGBoost é executado na GPU no backend FIL, ilustramos como cada modelo no pipeline do ensemble do Triton pode ser executado em um backend de estrutura diferente e executado em hardware diferente com diferentes configurações.
• Ele destaca como as bibliotecas RAPIDS (cuDF, cuML) são compatíveis com suas contrapartes de CPU (Pandas, Scikit-learn). Dessa forma, podemos mostrar como LabelEncoders criado em cuML pode ser usado no Scikit-learn e vice-versa. Observe que, se você espera pré-processar grandes quantidades de dados tabulares durante o tempo de inferência, ainda pode usar RAPIDS para acelerá-los por GPU.

Lembre-se que criamos o label_encoders.pkl arquivo no primeiro caderno. Não há nada mais a fazer para a codificação de categoria além de incluí-la em nosso model.py arquivo para pré-processamento.

Para criar o arquivo model.py exigido pelo back-end Triton Python, aderimos ao formatação exigida pelo back-end e inclua nossa lógica Python para processar o tensor de entrada e usar o codificador de rótulo mencionado anteriormente. Você pode revisar o lima usado para pré-processamento.

Para o modelo XGBoost, nada mais precisa ser feito. Treinamos o modelo no primeiro notebook e o backend FIL da Triton não requer esforço adicional para os modelos XGBoost.

Em seguida, precisamos dos arquivos de configuração do Triton. Cada modelo do conjunto Triton requer um config.pbtxt Arquivo. Além disso, também criamos um config.pbtxt arquivo para o conjunto como um todo. Esses arquivos permitem que a Triton conheça os metadados sobre o conjunto com informações como as entradas e saídas que esperamos, além de ajudar a definir o DAG associado ao conjunto.

Por fim, para implantar um modelo no Triton, precisamos que nossa pasta de repositório de modelos tenha a estrutura de pastas adequada. A Triton possui requisitos específicos para o layout do repositório de modelos. Dentro do diretório de repositório de modelo de nível superior, cada modelo possui seu próprio subdiretório contendo as informações para o modelo correspondente. Cada diretório de modelo no Triton deve ter pelo menos um subdiretório numérico representando uma versão do modelo. Para nosso caso de uso, a estrutura resultante deve se parecer com a seguinte.

Após termos esses três pré-requisitos, criamos um arquivo compactado como empacotamento para implantação e o carregamos para Serviço de armazenamento simples da Amazon (Amazônia S3).

Agora podemos criar um modelo do SageMaker a partir do repositório de modelos que carregamos no Amazon S3 na etapa anterior.

Nesta etapa, também fornecemos a variável de ambiente adicional SAGEMAKER_TRITON_DEFAULT_MODEL_NAME, que especifica o nome do modelo a ser carregado pelo Triton. O valor dessa chave deve corresponder ao nome da pasta no pacote de modelo carregado no Amazon S3. Esta variável é opcional no caso de um único modelo. No caso de modelos ensemble, esta chave deve ser especificada para que o Triton inicie no SageMaker.

Além disso, você pode definir SAGEMAKER_TRITON_BUFFER_MANAGER_THREAD_COUNT e SAGEMAKER_TRITON_THREAD_COUNT para otimizar a contagem de threads. Ambos os valores de configuração ajudam a ajustar o número de threads em execução em suas CPUs, para que você possa obter uma melhor utilização aumentando esses valores para CPUs com um número maior de núcleos. Na maioria dos casos, os valores padrão geralmente funcionam bem, mas pode valer a pena experimentar para ver se é possível obter mais eficiência para suas cargas de trabalho.

Com o modelo anterior, criamos uma configuração de endpoint onde podemos especificar o tipo e o número de instâncias que queremos no endpoint.

Por fim, usamos a configuração de endpoint anterior para criar um novo endpoint do SageMaker e aguardar a conclusão da implantação. O estado muda para InService após a implantação ser bem-sucedida.

É isso! Seu endpoint agora está pronto para teste e validação. Neste ponto, convém usar várias ferramentas para ajudar a otimizar seus tipos de instância e configuração para obter o melhor desempenho possível. A figura a seguir fornece um exemplo dos ganhos que podem ser obtidos usando o backend FIL para um modelo XGBoost no Triton.

Resumo

Neste post, orientamos você na implantação de uma carga de trabalho de conjunto XGBoost no SageMaker com o Triton Inference Server. Mover cargas de trabalho para Triton no SageMaker pode ser um retorno benéfico do investimento. Como em qualquer adoção de tecnologia, um processo e um plano de verificação são fundamentais, e detalhamos um processo de cinco etapas para orientá-lo sobre o que considerar ao mover suas cargas de trabalho. Além disso, nos aprofundamos nas etapas necessárias para implantar um conjunto que usa o pré-processamento Python e um modelo XGBoost no Triton no SageMaker.

O SageMaker fornece as ferramentas para remover o trabalho pesado indiferenciado de cada estágio do ciclo de vida de ML, facilitando assim a rápida experimentação e exploração necessárias para otimizar totalmente suas implantações de modelo. O suporte de hospedagem do SageMaker para o Triton Inference Server permite cargas de trabalho de baixa latência e altas transações por segundo (TPS).

Você pode encontrar os notebooks usados ​​para este exemplo em GitHub.

---

Sobre o autor

James Park é Arquiteto de Soluções na Amazon Web Services. Ele trabalha com a Amazon.com para projetar, criar e implantar soluções de tecnologia na AWS e tem um interesse particular em IA e aprendizado de máquina. Em seu tempo livre, gosta de buscar novas culturas, novas experiências e manter-se atualizado com as últimas tendências tecnológicas.

Jiahong Liu é arquiteto de soluções na equipe de provedores de serviços de nuvem da NVIDIA. Ele auxilia os clientes na adoção de soluções de aprendizado de máquina e IA que aproveitam a computação acelerada da NVIDIA para enfrentar seus desafios de treinamento e inferência. Em seu tempo de lazer, ele gosta de origami, projetos de bricolage e jogar basquete.

Kshitiz Gupta é arquiteto de soluções da NVIDIA. Ele gosta de educar os clientes de nuvem sobre as tecnologias de IA de GPU que a NVIDIA tem a oferecer e ajudá-los a acelerar seus aplicativos de aprendizado de máquina e aprendizado profundo. Fora do trabalho, ele gosta de correr, fazer caminhadas e observar a vida selvagem.

Bruno Aguiar de Melo é engenheiro de desenvolvimento de software na Amazon.com, onde ajuda equipes científicas a criar, implantar e liberar cargas de trabalho de ML. Ele está interessado em instrumentação e aspectos controláveis ​​na fase de modelagem/design de ML que devem ser considerados e medidos com a percepção de que o desempenho da execução do modelo é tão importante quanto o desempenho da qualidade do modelo, principalmente em casos de uso com restrição de latência. Em seu tempo livre, ele gosta de vinho, jogos de tabuleiro e cozinhar.

Eliuth Triana é Gerente de Relações com Desenvolvedores da NVIDIA. Ele conecta líderes de produtos, desenvolvedores e cientistas da Amazon e AWS com tecnólogos e líderes de produtos da NVIDIA para acelerar cargas de trabalho de ML/DL da Amazon, produtos EC2 e serviços de IA da AWS. Além disso, Eliuth é um apaixonado por mountain bike, esquiador e jogador de pôquer.