Obtenha desempenho de hiperescala para servir de modelo usando o NVIDIA Triton Inference Server no Amazon SageMaker

Os aplicativos de aprendizado de máquina (ML) são complexos de implantar e geralmente exigem vários modelos de ML para atender a uma única solicitação de inferência. Uma solicitação típica pode fluir por vários modelos com etapas como pré-processamento, transformações de dados, lógica de seleção de modelo, agregação de modelo e pós-processamento. Isso levou à evolução de padrões de design comuns, como pipelines de inferência serial, conjuntos (coleção de dispersão) e fluxos de trabalho de lógica de negócios, resultando na realização de todo o fluxo de trabalho da solicitação como um gráfico acíclico dirigido (DAG). No entanto, à medida que os fluxos de trabalho se tornam mais complexos, isso leva a um aumento nos tempos de resposta gerais, ou latência, desses aplicativos, o que, por sua vez, afeta a experiência geral do usuário. Além disso, se esses componentes estiverem hospedados em instâncias diferentes, a latência de rede adicional entre essas instâncias aumentará a latência geral. Considere um exemplo de um caso de uso de ML popular para um assistente virtual no suporte ao cliente. Uma solicitação típica pode ter que passar por várias etapas envolvendo reconhecimento de fala, processamento de linguagem natural (NLP), rastreamento de estado de diálogo, política de diálogo, geração de texto e, finalmente, texto para fala. Além disso, para tornar a interação do usuário mais personalizada, você também pode usar modelos de PNL baseados em transformadores de última geração, como diferentes versões de BERT, BART e GPT. O resultado final são tempos de resposta longos para esses conjuntos de modelos e uma experiência ruim do cliente.

Um padrão comum para reduzir os tempos de resposta sem comprometer a taxa de transferência geral é hospedar esses modelos na mesma instância junto com a lógica de negócios leve incorporada a ela. Esses modelos podem ser encapsulados em contêineres únicos ou múltiplos na mesma instância para fornecer isolamento para processos em execução e manter a latência baixa. Além disso, a latência geral também depende da lógica do aplicativo de inferência, otimizações de modelo, infraestrutura subjacente (incluindo computação, armazenamento e rede) e o servidor Web subjacente que recebe solicitações de inferência. Servidor de inferência NVIDIA Triton é um software de serviço de inferência de código aberto com recursos para maximizar a taxa de transferência e a utilização de hardware com latência de inferência ultrabaixa (milissegundos de um dígito). Possui amplo suporte a estruturas de ML (incluindo TensorFlow, PyTorch, ONNX, XGBoost e NVIDIA TensorRT) e back-ends de infraestrutura, incluindo GPUs, CPUs e Inferência da AWS. Além disso, o Triton Inference Server é integrado com Amazon Sage Maker, um serviço de ML de ponta a ponta totalmente gerenciado, oferecendo opções de inferência em tempo real, incluindo solteiro e multimodelo hospedagem. Essas opções de inferência incluem hospedar vários modelos no mesmo contêiner por trás de um ponto final único, e hospedagem vários modelos com vários contêineres atrás de um único ponto final.

Em novembro de 2021, anunciamos a integração do Triton Inference Server no SageMaker. A AWS trabalhou em estreita colaboração com a NVIDIA para permitir que você obtenha o melhor dos dois mundos e facilite a implantação de modelos com o Triton na AWS.

Nesta postagem, analisamos as práticas recomendadas para implantar modelos de transformador em escala em GPUs usando o Triton Inference Server no SageMaker. Primeiro, começamos com um resumo dos principais conceitos sobre latência no SageMaker e uma visão geral das diretrizes de ajuste de desempenho. Em seguida, fornecemos uma visão geral do Triton e seus recursos, bem como um código de exemplo para implantação no SageMaker. Por fim, realizamos testes de carga usando Recomendador de inferência do SageMaker e resuma os insights e conclusões do teste de carga de um modelo de transformador popular fornecido pelo Hugging Face.

Você pode revisar o caderno costumávamos implantar modelos e realizar testes de carga por conta própria usando o código em GitHub.

Ajuste e otimização de desempenho para veiculação de modelo no SageMaker

O ajuste e a otimização de desempenho são um processo empírico que geralmente envolve várias iterações. O número de parâmetros a serem ajustados é combinatório e o conjunto de valores de parâmetros de configuração não é independente um do outro. Vários fatores afetam o ajuste de parâmetro ideal, incluindo tamanho da carga útil, tipo e número de modelos de ML no gráfico de fluxo de solicitação de inferência, tipo de armazenamento, tipo de instância de computação, infraestrutura de rede, código do aplicativo, tempo de execução e configuração do software de serviço de inferência e muito mais.

Se você estiver usando o SageMaker para implantar modelos de ML, precisará selecionar uma instância de computação com o melhor preço-desempenho, que é um processo complicado e iterativo que pode levar semanas de experimentação. Primeiro, você precisa escolher o tipo de instância de ML correto entre mais de 70 opções com base nos requisitos de recursos de seus modelos e no tamanho dos dados de entrada. Em seguida, você precisa otimizar o modelo para o tipo de instância selecionado. Por fim, você precisa provisionar e gerenciar a infraestrutura para executar testes de carga e ajustar a configuração da nuvem para obter desempenho e custo ideais. Tudo isso pode atrasar a implantação do modelo e o tempo de lançamento no mercado. Além disso, você precisa avaliar as compensações entre latência, taxa de transferência e custo para selecionar a configuração de implantação ideal. Recomendador de inferência do SageMaker seleciona automaticamente o tipo de instância de computação correto, contagem de instâncias, parâmetros de contêiner e otimizações de modelo para inferência para maximizar a taxa de transferência, reduzir a latência e minimizar o custo.

Inferência e latência em tempo real no SageMaker

Inferência em tempo real do SageMaker é ideal para cargas de trabalho de inferência onde você tem requisitos de baixa latência, interativos e em tempo real. Há quatro métricas mais usadas para monitorar a latência da solicitação de inferência para endpoints de inferência do SageMaker

• Latência do contêiner – O tempo que leva para enviar a solicitação, buscar a resposta do contêiner do modelo e concluir a inferência no contêiner. Essa métrica está disponível no Amazon CloudWatch como parte do Métricas de invocação publicado por SageMaker.
• Latência do modelo – O tempo total gasto por todos os contêineres SageMaker em um pipeline de inferência. Essa métrica está disponível no Amazon CloudWatch como parte do Métricas de invocação publicado por SageMaker.
• Latência de sobrecarga – Medido desde o momento em que o SageMaker recebe a solicitação até retornar uma resposta ao cliente, menos a latência do modelo. Essa métrica está disponível no Amazon CloudWatch como parte do Métricas de invocação publicado por SageMaker.
• Latência de ponta a ponta – Medido desde o momento em que o cliente envia a solicitação de inferência até receber uma resposta de volta. Os clientes podem publicar isso como uma métrica personalizada no Amazon CloudWatch.

O diagrama a seguir ilustra esses componentes.

A latência do contêiner depende de vários fatores; os seguintes estão entre os mais importantes:

• Protocolo subjacente (HTTP(s)/gRPC) usado para se comunicar com o servidor de inferência
• Sobrecarga relacionada à criação de novas conexões TLS
• Tempo de desserialização da carga de solicitação/resposta
• Solicitar recursos de enfileiramento e lotes fornecidos pelo servidor de inferência subjacente
• Solicitar recursos de agendamento fornecidos pelo servidor de inferência subjacente
• Desempenho de tempo de execução subjacente do servidor de inferência
• Desempenho de bibliotecas de pré-processamento e pós-processamento antes de chamar a função de previsão do modelo
• Desempenho de back-end da estrutura de ML subjacente
• Otimizações específicas do modelo e específicas do hardware

Neste post, nos concentramos principalmente na otimização da latência do contêiner, juntamente com a taxa de transferência e o custo gerais. Especificamente, exploramos o ajuste de desempenho do Triton Inference Server em execução dentro de um contêiner SageMaker.

Visão geral do caso de uso

Implantar e dimensionar modelos de NLP em uma configuração de produção pode ser bastante desafiador. Os modelos de PNL geralmente são muito grandes em tamanho, contendo milhões de parâmetros de modelo. As configurações ideais do modelo são necessárias para atender aos requisitos rigorosos de desempenho e escalabilidade dos aplicativos NLP de nível de produção.

Nesta postagem, comparamos um caso de uso de NLP usando um endpoint em tempo real do SageMaker com base em um contêiner Triton Inference Server e recomendamos otimizações de ajuste de desempenho para nosso caso de uso de ML. Usamos um rosto de abraço grande e pré-treinado baseado em transformador BERT grande sem caixa modelo, que tem cerca de 336 milhões de parâmetros de modelo. A sentença de entrada usada para o modelo de classificação binária é preenchida e truncada para um comprimento máximo de sequência de entrada de 512 tokens. O teste de carga de inferência simula 500 invocações por segundo (30,000 invocações máximas por minuto) e ModelLatency de menos de 0.5 segundos (500 milissegundos).

A tabela a seguir resume nossa configuração de benchmark.

Servidor de inferência NVIDIA Triton

O Triton Inference Server foi projetado especificamente para permitir a implantação escalável, rápida e fácil de modelos em produção. O Triton suporta uma variedade de estruturas de IA importantes, incluindo TensorFlow, TensorRT, PyTorch, XGBoost e ONNX. Com o back-end personalizado do Python e do C++, você também pode implementar sua carga de trabalho de inferência para casos de uso mais personalizados.

Mais importante ainda, o Triton fornece uma configuração simples baseada em configuração para hospedar seus modelos, que expõe um rico conjunto de recursos de otimização de desempenho que você pode usar com pouco esforço de codificação.

O Triton aumenta o desempenho da inferência maximizando a utilização do hardware com diferentes técnicas de otimização (execuções de modelos simultâneos e lotes dinâmicos são os mais usados). Encontrar as configurações de modelo ideais a partir de várias combinações de tamanhos de lote dinâmicos e o número de instâncias de modelo simultâneas é fundamental para obter inferência em tempo real em serviços de baixo custo usando o Triton.

Lote dinâmico

Muitos profissionais tendem a executar a inferência sequencialmente quando o servidor é invocado com várias solicitações independentes. Embora seja mais fácil de configurar, geralmente não é a melhor prática utilizar o poder de computação da GPU. Para resolver isso, a Triton oferece otimizações integradas de lote dinâmico para combinar essas solicitações de inferência independentes no lado do servidor para formar um lote maior dinamicamente para aumentar o rendimento. O diagrama a seguir ilustra a arquitetura de tempo de execução do Triton.

Na arquitetura anterior, todas as solicitações chegam primeiro ao batcher dinâmico antes de entrar nas filas do planejador de modelo real para aguardar a inferência. Você pode definir seus tamanhos de lote preferidos para lotes dinâmicos usando o tamanho_lote_preferido configurações na configuração do modelo. (Observe que o tamanho do lote formado precisa ser menor que o max_batch_size o modelo suporta.) Você também pode configurar max_queue_delay_microseconds para especificar o tempo máximo de atraso no batcher para aguardar outras solicitações para ingressar no lote com base em seus requisitos de latência.

O trecho de código a seguir mostra como você pode adicionar esse recurso com arquivos de configuração de modelo para definir o lote dinâmico com um tamanho de lote preferencial de 16 para a inferência real. Com as configurações atuais, a instância do modelo é invocada instantaneamente quando o tamanho de lote preferido de 16 é atingido ou o tempo de atraso de 100 microssegundos decorrido desde que a primeira solicitação atingiu o batcher dinâmico.

dynamic_batching { preferred_batch_size: 16 max_queue_delay_microseconds: 100 }

Executando modelos simultaneamente

Outra otimização essencial oferecida no Triton para maximizar a utilização do hardware sem sobrecarga de latência adicional é execução de modelo simultâneo, que permite que vários modelos ou várias cópias do mesmo modelo sejam executados em paralelo. Esse recurso permite que a Triton lide com várias solicitações de inferência simultaneamente, o que aumenta a taxa de transferência de inferência utilizando energia de computação ociosa no hardware.

A figura a seguir mostra como você pode configurar facilmente diferentes políticas de implantação de modelo com apenas algumas linhas de alterações de código. Por exemplo, a configuração A (esquerda) mostra que você pode transmitir a mesma configuração de duas instâncias de modelo de bert-large-uncased para todas as GPUs disponíveis. Por outro lado, a configuração B (meio) mostra uma configuração diferente apenas para a GPU 0, sem alterar as políticas nas outras GPUs. Você também pode implantar instâncias de diferentes modelos em uma única GPU, conforme mostrado na configuração C (direita).

Na configuração C, a instância de computação pode lidar com duas solicitações simultâneas para o modelo DistilGPT-2 e sete solicitações simultâneas para o bert-large-uncased modelo em paralelo. Com essas otimizações, os recursos de hardware podem ser melhor utilizados para o processo de atendimento, melhorando assim a taxa de transferência e proporcionando melhor custo-benefício para sua carga de trabalho.

TensorRT

NVIDIA TensorRT é um SDK para inferência de aprendizado profundo de alto desempenho que funciona perfeitamente com o Triton. O TensorRT, que oferece suporte a todas as principais estruturas de aprendizado profundo, inclui um otimizador de inferência e tempo de execução que oferece baixa latência e alta taxa de transferência para executar inferências com grandes volumes de dados por meio de otimizações poderosas.

O TensorRT otimiza o gráfico para minimizar o consumo de memória, liberando memória desnecessária e reutilizando-a com eficiência. Além disso, a compilação TensorRT funde as operações esparsas dentro do gráfico do modelo para formar um kernel maior para evitar a sobrecarga de vários lançamentos de kernel pequenos. O ajuste automático do kernel ajuda você a utilizar totalmente o hardware selecionando o melhor algoritmo em sua GPU de destino. Os fluxos CUDA permitem que os modelos sejam executados em paralelo para maximizar a utilização da GPU para obter o melhor desempenho. Por último, mas não menos importante, a técnica de quantização pode usar totalmente a aceleração de precisão mista dos núcleos do Tensor para executar o modelo em FP32, TF32, FP16 e INT8 para obter o melhor desempenho de inferência.

Triton na hospedagem do 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 Contêineres de Aprendizado Profundo do SageMaker (DLC).

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.

Recomendador de inferência do SageMaker para resultados de testes de benchmarking

Usamos o SageMaker Inference Recommender para executar nossos experimentos. O SageMaker Inference Recommender oferece dois tipos de trabalhos: padrão e avançado, conforme ilustrado no diagrama a seguir.

O trabalho padrão fornece recomendações sobre tipos de instância com apenas o modelo e uma carga útil de amostra para comparação. Além das recomendações de instância, o serviço também oferece parâmetros de tempo de execução que melhoram o desempenho. As recomendações do trabalho padrão destinam-se a restringir a pesquisa de instâncias. Em alguns casos, pode ser a família de instâncias e, em outros, podem ser os tipos de instância específicos. Os resultados do trabalho padrão são então inseridos no trabalho avançado.

O trabalho avançado oferece mais controles para ajustar ainda mais o desempenho. Esses controles simulam o ambiente real e os requisitos de produção. Entre esses controles está o padrão de tráfego, que visa encenar o padrão de requisição para os benchmarks. Você pode definir rampas ou tráfego estável usando as várias fases do padrão de tráfego. Por exemplo, um NúmeroInicialDeUsuários de 1, Taxa de desova de 1, e Duração em segundos de 600 pode resultar em tráfego de rampa de 10 minutos com 1 usuário simultâneo no início e 10 no final. Além disso, nos controles, MaxInvocações e Limites de latência do modelo defina o limite de produção, portanto, quando um dos limites for excedido, o benchmarking será interrompido.

Finalmente, métricas de recomendação incluem taxa de transferência, latência na taxa de transferência máxima e custo por inferência, para que seja fácil compará-los.

Usamos o tipo de trabalho avançado do SageMaker Inference Recommender para executar nossos experimentos para obter controle adicional sobre os padrões de tráfego e ajustar a configuração do contêiner de veiculação.

Configuração do experimento

Usamos o recurso de teste de carga personalizado do SageMaker Inference Recommender para comparar o perfil de PNL descrito em nosso caso de uso. Primeiro, definimos os seguintes pré-requisitos relacionados ao modelo de PNL e à tarefa de ML. O SageMaker Inference Recommender usa essas informações para extrair uma imagem do Docker de inferência de Registro do Amazon Elastic Container (Amazon ECR) e registre o modelo no registro de modelo do SageMaker.

As configurações de padrão de tráfego no SageMaker Inference Recommender nos permitem definir diferentes fases para o teste de carga personalizado. O teste de carga começa com dois usuários iniciais e gera dois novos usuários a cada minuto, com duração total de 25 minutos (1500 segundos), conforme mostrado no código a seguir:

"TrafficPattern": { "TrafficType": "PHASES", "Phases": [ { "InitialNumberOfUsers": 2, "SpawnRate": 2, "DurationInSeconds": 1500 }, ],
}

Experimentamos o teste de carga do mesmo modelo em dois estados diferentes. Os experimentos baseados em PyTorch usam o modelo PyTorch padrão e inalterado. Para os experimentos baseados em TensorRT, convertemos o modelo PyTorch em um mecanismo TensorRT antecipadamente.

Aplicamos diferentes combinações dos recursos de otimização de desempenho nesses dois modelos, resumidos na tabela a seguir.

Resultados de testes e observações

Realizamos testes de carga para três tipos de instância dentro da mesma família g4dn: ml.g4dn.xlarge, ml.g4dn.2xlarge e ml.g4dn.12xlarge. Todos os tipos de instância g4dn têm acesso a GPUs NVIDIA T4 Tensor Core e processadores Intel Cascade Lake de 2ª geração. A lógica por trás da escolha dos tipos de instância era ter uma instância com apenas uma GPU disponível, bem como uma instância com acesso a várias GPUs — quatro no caso de ml.g4dn.12xlarge. Além disso, queríamos testar se aumentar a capacidade de vCPU na instância com apenas uma GPU disponível resultaria em uma melhoria na relação custo-desempenho.

Vamos analisar primeiro a aceleração da otimização individual. O gráfico a seguir mostra que a otimização do TensorRT fornece uma redução de 50% na latência do modelo em comparação com o nativo no PyTorch na instância ml.g4dn.xlarge. Essa redução de latência aumenta para mais de três vezes nas instâncias multi-GPU de ml.g4dn.12xlarge. Enquanto isso, a melhoria de 30% na taxa de transferência é consistente em ambas as instâncias, resultando em melhor custo-benefício após a aplicação das otimizações do TensorRT.

Com o batching dinâmico, podemos obter uma melhoria de quase 2x na taxa de transferência usando a mesma arquitetura de hardware em todas as instâncias de experimentos de ml.g4dn.xlarge, ml.g4dn.2xlarge e ml.g4dn.12xlarge sem aumento perceptível de latência.

Da mesma forma, a execução de modelo simultâneo nos permite obter cerca de 3 a 4 vezes de melhoria na taxa de transferência maximizando a utilização da GPU na instância ml.g4dn.xlarge e cerca de 2 vezes na instância ml.g4dn.2xlarge e na instância multi-GPU de ml. g4dn.12xlarge.. Este aumento de throughput vem sem nenhuma sobrecarga na latência.

Melhor ainda, podemos integrar todas essas otimizações para fornecer o melhor desempenho utilizando ao máximo os recursos de hardware. A tabela e os gráficos a seguir resumem os resultados que obtivemos em nossos experimentos.

[1] A contagem inicial de instâncias na tabela acima é o número recomendado de instâncias a serem usadas com uma política de escalonamento automático para manter os requisitos de taxa de transferência e latência para sua carga de trabalho.

[2] O custo por hora na tabela acima é calculado com base na contagem inicial de instâncias e no preço do tipo de instância.

Os resultados validam principalmente o impacto esperado de diferentes recursos de otimização de desempenho:

• A compilação do TensorRT tem o impacto mais confiável em todos os tipos de instância. As transações por minuto por instância aumentaram de 30 a 35%, com uma redução de custo consistente de aproximadamente 25% quando comparado ao desempenho do mecanismo TensorRT para o PyTorch BERT padrão (pt-base). O desempenho aprimorado do mecanismo TensorRT é composto e explorado por outros recursos de ajuste de desempenho testados.
• O carregamento de dois modelos em cada GPU (grupo de instâncias) quase dobrou todas as métricas medidas. As invocações por minuto por instância aumentaram aproximadamente 80–90%, gerando uma redução de custo na faixa de 50%, quase como se estivéssemos usando duas GPUs. Na verdade, Amazon CloudWatch as métricas para nossos experimentos em g4dn.2xlarge (como exemplo) confirmam que a utilização de CPU e GPU dobra quando configuramos um grupo de instâncias de dois modelos.

Mais dicas de desempenho e otimização de custos

O benchmark apresentado neste post apenas arranhou a superfície dos possíveis recursos e técnicas que você pode usar com o Triton para melhorar o desempenho da inferência. Eles variam de técnicas de pré-processamento de dados, como o envio de cargas binárias para o servidor de modelo ou cargas com lotes maiores, até recursos nativos do Triton, como os seguintes:

• Aquecimento do modelo, que evita solicitações de inferência iniciais e lentas inicializando completamente o modelo antes que a primeira solicitação de inferência seja recebida.
• Cache de resposta, que armazena em cache solicitações repetidas.
• Conjunto de modelos, que permite criar um pipeline de um ou mais modelos e a conexão de tensores de entrada e saída entre esses modelos. Isso abre a possibilidade de adicionar etapas de pré-processamento e pós-processamento, ou mesmo inferência com outros modelos, ao fluxo de processamento de cada solicitação.

Esperamos testar e comparar essas técnicas e recursos em um post futuro, portanto, fique atento!

Conclusão

Neste post, exploramos alguns parâmetros que você pode usar para maximizar o desempenho do seu endpoint em tempo real do SageMaker para servir os modelos PyTorch BERT com o Triton Inference Server. Usamos o SageMaker Inference Recommender para realizar os testes de benchmarking para ajustar esses parâmetros. Esses parâmetros estão essencialmente relacionados à otimização do modelo baseado em TensorRT, levando a uma melhoria de quase 50% nos tempos de resposta em comparação com a versão não otimizada. Além disso, a execução de modelos simultaneamente e o uso de lotes dinâmicos do Triton levaram a um aumento de quase 70% no rendimento. O ajuste fino desses parâmetros também levou a uma redução geral do custo de inferência.

A melhor maneira de derivar os valores corretos é através da experimentação. No entanto, para começar a construir conhecimento empírico sobre ajuste e otimização de desempenho, você pode observar as combinações de diferentes parâmetros relacionados ao Triton e seu efeito no desempenho em modelos de ML e instâncias de ML do 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.

Você pode encontrar o notebook usado para teste de carga e implantação em GitHub. Você pode atualizar as configurações do Triton e as configurações do SageMaker Inference Recommender para melhor se adequar ao seu caso de uso para obter cargas de trabalho de inferência econômicas e de melhor desempenho.

Sobre os autores

Vikram Elango é um arquiteto de soluções especialista em IA/ML na Amazon Web Services, com sede na Virgínia, EUA. A Vikram ajuda os clientes do setor financeiro e de seguros com design e liderança de pensamento para criar e implantar aplicativos de aprendizado de máquina em escala. Atualmente, ele está focado em processamento de linguagem natural, IA responsável, otimização de inferência e dimensionamento de ML em toda a empresa. Nas horas vagas, gosta de viajar, fazer caminhadas, cozinhar e acampar com a família.

João moura é arquiteto de soluções especialista em IA/ML na Amazon Web Services. Ele se concentra principalmente em casos de uso de PNL e em ajudar os clientes a otimizar o treinamento e a implantação do modelo de Deep Learning. Ele também é um defensor ativo de soluções de ML de baixo código e hardware especializado em ML.

Mohan Gandhi é engenheiro de software sênior na AWS. Ele está na AWS nos últimos 9 anos e trabalhou em vários serviços da AWS, como EMR, EFA e RDS em Outposts. Atualmente, ele está focado em melhorar a experiência de inferência do SageMaker. Em seu tempo livre, ele gosta de caminhar e correr maratonas.

Dhawal Patel é Arquiteto Principal de Machine Learning na AWS. Ele trabalhou com organizações que vão desde grandes empresas até startups de médio porte em problemas relacionados à computação distribuída e Inteligência Artificial. Ele se concentra em aprendizado profundo, incluindo domínios de PNL e Visão Computacional. Ele ajuda os clientes a obter inferência de modelo de alto desempenho no SageMaker.

Santosh Bhavani é gerente de produto técnico sênior da equipe Amazon SageMaker Elastic Inference. Ele se concentra em ajudar os clientes da SageMaker a acelerar a inferência e implantação de modelos. Em seu tempo livre, ele gosta de viajar, jogar tênis e beber muito chá Pu'er.

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.

• Coinsmart. A melhor troca de Bitcoin e criptografia da Europa.
• Platoblockchain. Inteligência Metaverso Web3. Conhecimento Ampliado. ACESSO LIVRE.
• CryptoHawk. Radar Altcoin. Teste grátis.
• Fonte: https://aws.amazon.com/blogs/machine-learning/achieve-hyperscale-performance-for-model-serving-using-nvidia-triton-inference-server-on-amazon-sagemaker/