Esta postagem do blog foi co-escrita por Jonathan Lee, Nelson Leung, Paul Min e Troy Squillaci da Intel.
In Parte 1 deste post, discutimos como o Intel®3DAT colaborou com Serviços profissionais de aprendizado de máquina da AWS (MLPS) para criar um aplicativo SaaS de IA escalável. O 3DAT usa visão computacional e IA para reconhecer, rastrear e analisar mais de 1,000 pontos de dados biomecânicos de vídeo padrão. Ele permite que os clientes criem produtos ricos e poderosos baseados em biomecânica, como aplicativos da Web e móveis com dados de desempenho detalhados e visualizações tridimensionais.
Na Parte 2 deste post, nos aprofundamos em cada estágio da arquitetura. Exploramos os serviços da AWS usados para atender aos requisitos de design 3DAT, incluindo Fluxos de dados do Amazon Kinesis e Serviço Amazon Elastic Kubernetes (Amazon EKS), a fim de implantar de forma escalável os modelos de estimativa de pose necessários para este aplicativo de software como serviço (SaaS).
Visão geral da arquitetura
O objetivo principal da equipe do MLPS era produzir os pipelines do modelo de estimativa de pose 2D e 3D e criar um aplicativo funcional e escalável. O diagrama a seguir ilustra a arquitetura da solução.
A arquitetura completa é dividida em cinco componentes principais:
- Camadas da interface do aplicativo do usuário
- banco de dados
- Orquestração de fluxo de trabalho
- Geração de inferência de estimativa de pose escalável
- Monitoramento operacional
Vamos entrar em detalhes sobre cada componente, suas interações e a lógica por trás das escolhas de design.
Camadas da interface do aplicativo do usuário
O diagrama a seguir mostra as camadas da interface do aplicativo que fornecem acesso ao usuário e controle do aplicativo e seus recursos.
Esses pontos de acesso oferecem suporte a diferentes casos de uso com base em diferentes personas do cliente. Por exemplo, um usuário de aplicativo pode enviar um trabalho por meio da CLI, enquanto um desenvolvedor pode criar um aplicativo usando o Python SDK e incorporar inteligência de estimativa de pose em seus aplicativos. A CLI e o SDK são construídos como componentes modulares - ambas as camadas são wrappers da camada API, que é construída usando Gateway de API da Amazon para resolver as chamadas de API e AWS Lambda associado funções, que cuidam da lógica de back-end associada a cada chamada de API. Essas camadas foram um componente crucial para a equipe do Intel OTG porque abrem uma ampla base de clientes que podem usar efetivamente esse aplicativo SaaS.
camada de API
A solução possui um conjunto central de nove APIs, que correspondem aos tipos de objetos que operam nesta plataforma. Cada API tem um arquivo Python que define as ações da API que podem ser executadas. A criação de novos objetos recebe automaticamente um ID de objeto sequencialmente. Os atributos desses objetos são armazenados e rastreados no Amazon Aurora sem servidor banco de dados usando este ID. Portanto, as ações da API estão vinculadas a funções definidas em um arquivo central que contém a lógica de back-end para consultar o banco de dados do Aurora. Esta lógica de back-end usa o Boto3 Cliente Amazon RDS DataService para acessar o cluster de banco de dados.
A única exceção é o /job
API, que tem um create_job
método que lida com o envio de vídeo para criar um novo trabalho de processamento. Este método inicia o Funções de etapa da AWS lógica de fluxo de trabalho para executar o trabalho. Ao passar em um job_id
, este método usa o Boto3 Cliente do Step Functions chamar o start_execution
método para um determinado stateMachineARN
(Nome do Recurso Amazon).
As oito APIs de objeto têm os métodos e padrão de acesso semelhante, conforme resumido na tabela a seguir.
Tipo de Método | Nome da Função | Descrição |
ENTRE | list_[object_name]s |
Seleciona todos os objetos desse tipo do banco de dados e exibe. |
POST | create_[object] |
Insere um novo registro de objeto com as entradas necessárias no banco de dados. |
ENTRE | get_[object] |
Seleciona os atributos do objeto com base no ID do objeto do banco de dados e exibe. |
PUT | update_[object] |
Atualiza um registro de objeto existente com as entradas necessárias. |
EXCLUIR | delete_[object] |
Exclui um registro de objeto existente do banco de dados com base no ID do objeto. |
Os detalhes das nove APIs são os seguintes:
- /do utilizador – Um usuário é a identidade de alguém autorizado a enviar trabalhos para este aplicativo. A criação de um usuário requer um nome de usuário, e-mail de usuário e ID de grupo ao qual o usuário pertence.
- /grupo de usuários – Um grupo de usuários é uma coleção de usuários. Cada grupo de usuários é mapeado para um projeto e um conjunto de parâmetros de pipeline. Para ter diferentes camadas (em termos de recursos de infraestrutura e parâmetros de pipeline), os usuários são divididos em grupos de usuários. Cada usuário pode pertencer a apenas um grupo de usuários. A criação de um grupo de usuários requer um ID do projeto, ID do conjunto de parâmetros do pipeline, nome do grupo de usuários e descrição do grupo de usuários. Observe que os grupos de usuários são diferentes das funções de usuário definidas na conta da AWS. O último é usado para fornecer diferentes níveis de acesso com base em suas funções de acesso (por exemplo, admin).
- /projeto – Um projeto é usado para agrupar diferentes conjuntos de recursos de infraestrutura. Um projeto está associado a um único
project_cluster_url
(cluster Aurora) para gravar usuários, trabalhos e outros metadados, umproject_queue_arn
(Kinesis Data Streams ARN) e um ambiente de tempo de execução de computação (atualmente controlado via Cortex) usado para executar inferência nos lotes de quadros ou pós-processamento nos vídeos. Cada grupo de usuários está associado a um projeto e esse mecanismo é como as diferentes camadas são habilitadas em termos de latência e poder de computação para diferentes grupos de usuários. A criação de um projeto requer um nome de projeto, URL de cluster de projeto e ARN de fila de projeto. - /pipeline – Um pipeline é associado a uma configuração única para uma sequência de contêineres de processamento que executam o processamento de vídeo no cluster de geração de inferência do Amazon EKS coordenado pelo Cortex (consulte a seção sobre geração de inferência de processamento de vídeo para obter mais detalhes). Normalmente, isso consiste em três contêineres: pré-processamento e decodificação, detecção de objetos e estimativa de pose. Por exemplo, a etapa de decodificação e detecção de objeto é a mesma para os pipelines 2D e 3D, mas a troca do último contêiner usando HRNet ou 3DMPPE resulta no parâmetro definido para pipelines de processamento 2D versus 3D. Você pode criar novas configurações para definir possíveis pipelines que podem ser usados para processamento, e isso requer como entrada um novo arquivo Python no repositório Cortex que detalha a sequência de chamadas de endpoints do modelo que definem esse pipeline (consulte a seção sobre geração de inferência de processamento de vídeo ). O endpoint do pipeline é o endpoint do Cortex que é chamado para processar um único quadro. A criação de um pipeline requer um nome de pipeline, descrição de pipeline e endpoint de pipeline.
- /pipeline_parameter_set – Um conjunto de parâmetros de pipeline é uma coleção JSON flexível de vários parâmetros (um tempo de execução de configuração de pipeline) para um pipeline específico e é adicionado para fornecer flexibilidade para personalização futura quando vários tempos de execução de configuração de pipeline são necessários. Os grupos de usuários podem ser associados a um conjunto de parâmetros de pipeline específico e sua finalidade é ter diferentes grupos de parâmetros por grupo de usuários e por pipeline. Essa foi uma adição importante para o futuro do Intel OTG para incorporar a personalização que oferece suporte à portabilidade à medida que diferentes clientes, principalmente ISVs, começam a usar o aplicativo.
- /pipeline_parameters – Uma única coleção de parâmetros de pipeline é uma instanciação de um conjunto de parâmetros de pipeline. Isso o torna um mapeamento 1:muitos de um parâmetro de pipeline definido para parâmetros de pipeline. Essa API requer um ID de pipeline para associar ao conjunto de parâmetros de pipeline que permite a criação de um pipeline para um mapeamento 1:1 de parâmetros de pipeline para o pipeline. As outras entradas exigidas por essa API são um ID do conjunto de parâmetros do pipeline, o valor dos parâmetros do pipeline e o nome dos parâmetros do pipeline.
- /vídeo – Um objeto de vídeo é usado para definir vídeos individuais que compõem um pacote .zip enviado durante um trabalho. Este arquivo é dividido em vários vídeos após o envio. Um vídeo está relacionado com o
job_id
para o trabalho em que o pacote .zip é enviado e Serviço de armazenamento simples da Amazon (Amazon S3) caminhos para a localização dos vídeos brutos separados e os resultados de pós-processamento de cada vídeo. O objeto de vídeo também contém uma porcentagem de progresso de vídeo, que é atualizada consistentemente durante o processamento de lotes de quadros individuais desse vídeo, bem como um sinalizador de status de vídeo para concluído ou não concluído. A criação de um vídeo requer um ID de trabalho, caminho de vídeo, caminho de resultados de vídeo, porcentagem de progresso de vídeo e status de vídeo. - /frame_batch - UMA
frame_batch
objeto é um mini-lote de quadros criado por amostragem de um único vídeo. Separar um vídeo em lotes de quadros de tamanho normal fornece uma alavanca para ajustar a latência e aumenta a paralelização e a taxa de transferência. Essa é a unidade granular executada por meio do Kinesis Data Streams para inferência. A criação de um lote de quadros requer um ID de vídeo, número de início do lote de quadros, número final do lote de quadros, caminho de entrada do lote de quadros, caminho de resultados do lote de quadros e status do lote de quadros. - /trabalho – Essa API de interação é usada para envio de arquivo para iniciar um trabalho de processamento. Essa API tem uma função diferente de outras APIs de objeto porque é o caminho direto para interagir com a coordenação do fluxo de trabalho do Step Functions de back-end de processamento de vídeo e o cluster do Amazon EKS. Essa API requer um ID do usuário, ID do projeto, ID do pipeline, ID do conjunto de parâmetros do pipeline, parâmetros do job e status do job. Nos parâmetros do trabalho, é especificado um caminho de arquivo de entrada, que é o local no Amazon S3 onde está localizado o pacote .zip de vídeos a serem processados. O upload de arquivos é feito com o
upload_handler
método, que gera um URL do S3 pré-assinado para o usuário colocar um arquivo. Um WORKFLOW_STATEMACHINE_ARN é uma variável de ambiente que é passada para ocreate_job
API para especificar onde um pacote .zip de vídeo com um caminho de arquivo de entrada é enviado para iniciar um trabalho.
A tabela a seguir resume as funções da API.
Tipo de Método | função | Descrição |
ENTRE | list_jobs |
Seleciona todos os trabalhos do banco de dados e exibe. |
POST | create_ job |
Insere um novo registro de trabalho com ID do usuário, ID do projeto, ID do pipeline, ID do conjunto de parâmetros do pipeline, caminho de resultados do trabalho, parâmetros do trabalho e status do trabalho. |
ENTRE | get_ job |
Seleciona os atributos do trabalho com base no ID do trabalho do banco de dados e exibe. |
ENTRE | upload_handler |
Gera um URL do S3 pré-assinado como o local para o upload do arquivo .zip. Requer um nome de bucket do S3 e espera um tipo de arquivo de aplicativo/zip. |
Camada do SDK do Python
Com base nas APIs, a equipe criou uma biblioteca cliente Python SDK como um wrapper para facilitar o acesso dos desenvolvedores aos métodos da API. Eles usaram o código aberto Poesia, que lida com o empacotamento do Python e o gerenciamento de dependências. Eles criaram um client.py
arquivo que contém funções que envolvem cada uma das APIs usando o Python requests
biblioteca para lidar com solicitações e exceções de API.
Para os desenvolvedores iniciarem o Intel 3DAT SDK, eles precisam instalar e construir o pacote Poetry. Em seguida, eles podem adicionar uma importação simples do Python de intel_3dat_sdk
para qualquer código Python.
Para usar o cliente, você pode criar uma instância do cliente, especificando o endpoint da API:
Você pode então usar o cliente para chamar os métodos individuais, como o create_pipeline
método (consulte o código a seguir), recebendo os argumentos apropriados, como nome do pipeline e descrição do pipeline.
camada CLI
Da mesma forma, a equipe desenvolveu as APIs para criar uma interface de linha de comando para usuários que desejam acessar os métodos da API com uma interface direta sem precisar escrever código Python. Eles usaram o pacote Python de código aberto Clique (Kit de criação de interface de linha de comando). Os benefícios dessa estrutura são o aninhamento arbitrário de comandos, a geração automática de páginas de ajuda e o suporte ao carregamento lento de subcomandos em tempo de execução. No mesmo client.py
como no SDK, cada método de cliente SDK foi encapsulado usando Click e os argumentos de método necessários foram convertidos em sinalizadores de linha de comando. As entradas de sinalizador são usadas ao chamar o comando SDK.
Para iniciar a CLI, você pode usar o CLI configure
comando. Você é solicitado a fornecer o URL do endpoint:
Agora você pode usar a CLI para chamar diferentes comandos relacionados aos métodos da API, por exemplo:
banco de dados
Como um banco de dados, esse aplicativo usa o Aurora Serverless para armazenar metadados associados a cada uma das APIs com MYSQL como mecanismo de banco de dados. A escolha do serviço de banco de dados Aurora Serverless segue o princípio de design para minimizar a sobrecarga de infraestrutura utilizando serviços da AWS sem servidor quando possível. O diagrama a seguir ilustra essa arquitetura.
A modo de mecanismo sem servidor atende ao padrão de uso intermitente porque esse aplicativo é dimensionado para novos clientes e as cargas de trabalho ainda são incertas. Ao iniciar um endpoint de banco de dados, não é necessário um tamanho de instância de banco de dados específico, apenas um intervalo mínimo e máximo para a capacidade do cluster. O Aurora Serverless lida com o provisionamento apropriado de uma frota de roteadores e distribui a carga de trabalho entre os recursos. O Aurora Serverless realiza automaticamente a retenção de backup por no mínimo 1 dia até 35 dias. A equipe otimizou a segurança, definindo o padrão para o valor máximo de 35.
Além disso, a equipe utilizou o API de dados para lidar com o acesso ao cluster do Aurora Serverless, que não requer uma conexão persistente e, em vez disso, fornece um endpoint HTTP seguro e integração com AWS SDKs. Este recurso usa Gerenciador de segredos da AWS para armazenar as credenciais do banco de dados para que não seja necessário passar as credenciais explicitamente. Os scripts CREATE TABLE foram escritos em arquivos .sql para cada uma das nove tabelas que correspondem às nove APIs. Como esse banco de dados continha todos os metadados e o estado dos objetos no sistema, os métodos da API eram executados usando os comandos SQL apropriados (por exemplo, select * from Job
para o list_jobs
API) e passado para o execute_statement
método do cliente Amazon RDS na API de dados.
Orquestração de fluxo de trabalho
O backbone funcional do aplicativo foi tratado usando Step Functions para coordenar o fluxo de trabalho, conforme mostrado no diagrama a seguir.
A máquina de estado consistia em uma sequência de quatro funções Lambda, que iniciam quando um trabalho é enviado usando o create_job
método do job
API. O ID do usuário, ID do projeto, ID do pipeline, ID do conjunto de parâmetros do pipeline, caminho de resultados do trabalho, parâmetros do trabalho e status do trabalho são necessários para a criação do trabalho. Você pode primeiro carregar um pacote .zip de arquivos de vídeo usando o upload_handler
método da API de trabalho para gerar um URL do S3 pré-assinado. Durante o envio do trabalho, o caminho do arquivo de entrada é passado por meio dos parâmetros do trabalho, para especificar o local do arquivo. Isso inicia a execução da máquina de estado do fluxo de trabalho, acionando quatro etapas principais:
- Função Lambda inicializadora
- Função Lambda do remetente
- Verificação de conclusão da função Lambda
- Função do coletor Lambda
Função Lambda inicializadora
A principal função do Inicializador é separar o pacote .zip em arquivos de vídeo individuais e prepará-los para o Remetente. Primeiro, o arquivo .zip é baixado e, em seguida, cada arquivo individual, incluindo arquivos de vídeo, é descompactado e extraído. Os vídeos, preferencialmente no formato .mp4, são carregados de volta em um bucket do S3. Usando o create_video
método no video
API, um objeto de vídeo é criado com o caminho do vídeo como entrada. Isso insere dados em cada vídeo no banco de dados do Aurora. Quaisquer outros tipos de arquivo, como arquivos JSON, são considerados metadados e enviados de forma semelhante, mas nenhum objeto de vídeo é criado. Uma lista dos nomes dos arquivos e arquivos de vídeo extraídos é passada para a próxima etapa.
Função Lambda do remetente
A função Submitter pega os arquivos de vídeo que foram extraídos pelo Inicializador e cria minilotes de quadros de vídeo como imagens. A maioria dos modelos atuais de visão computacional em produção foram treinados em imagens, de modo que, mesmo quando o vídeo é processado, eles são separados em quadros de imagem antes da inferência do modelo. Essa solução atual que usa um modelo de estimativa de pose de última geração não é diferente — os lotes de quadros do remetente são passados para o Kinesis Data Streams para iniciar a etapa de geração de inferência.
Primeiro, o arquivo de vídeo é baixado pela função Lambda. A taxa de quadros e o número de quadros são calculados usando o FileVideoStream
módulo do imutils.video
biblioteca de processamento. Os quadros são extraídos e agrupados de acordo com um tamanho de mini-lote especificado, que é um dos principais parâmetros ajustáveis desse pipeline. Usando a biblioteca Python pickle, os dados são serializados e carregados no Amazon S3. Posteriormente, um objeto de lote de quadros é criado e a entrada de metadados é criada no banco de dados do Aurora. Esta função Lambda foi construída usando um Dockerfile com dependências em opencv-python
, numpy
e imutils
bibliotecas.
Verificação de conclusão da função Lambda
A função de verificação de conclusão continua a consultar o banco de dados do Aurora para ver, para cada vídeo no pacote .zip para este trabalho atual, quantos lotes de quadros estão no status COMPLETED. Quando todos os lotes de quadros para todos os vídeos estiverem concluídos, esse processo de verificação estará concluído.
Função do coletor Lambda
A função Collector pega as saídas das inferências que foram realizadas em cada quadro durante o estágio Consumidor e as combina em um lote de quadros e em um vídeo. Os dados mesclados combinados são então carregados em um bucket do S3. A função então invoca a API de pós-processamento do Cortex para um pipeline de ML específico para realizar quaisquer cálculos de pós-processamento e adiciona os resultados agregados por vídeo ao bucket de saída. Muitas dessas métricas são calculadas em quadros, como velocidade, aceleração e ângulo da junta, portanto, esse cálculo precisa ser realizado nos dados agregados. As principais saídas incluem dados de pontos-chave do corpo (agregados em formato CSV), cálculos de BMA (como aceleração) e sobreposição visual de pontos-chave adicionados a cada quadro em um arquivo de imagem.
Geração de inferência de estimativa de pose escalável
O mecanismo de processamento que alimenta o dimensionamento da inferência de ML acontece neste estágio. Ele envolve três peças principais, cada uma com suas próprias alavancas de simultaneidade que podem ser ajustadas para compensações de latência (veja o diagrama a seguir).
Essa arquitetura permite a experimentação nos testes de ganhos de latência, bem como flexibilidade para o futuro, quando as cargas de trabalho podem mudar com diferentes combinações de segmentos de usuários finais que acessam o aplicativo.
Streams de dados Kinesis
A equipe escolheu o Kinesis Data Streams porque normalmente é usado para lidar com dados de streaming e, nesse caso, é uma boa opção porque pode lidar com lotes de quadros de maneira semelhante para fornecer escalabilidade e paralelização. Na função Submitter Lambda, é usado o cliente Kinesis Boto3, com o put_record
método que transmite os metadados associados a um único lote de quadros, como o ID do lote de quadros, o quadro inicial do lote de quadros, o quadro final do lote de quadros, o formato da imagem, a taxa de quadros e o ID do vídeo.
Definimos várias configurações de fila de tarefas e fluxo de dados do Kinesis para definir níveis de taxa de transferência que se vinculam ao nível de prioridade de diferentes grupos de usuários. O acesso a diferentes níveis de poder de processamento é vinculado ao passar um ARN de fila de projeto ao criar um novo projeto usando o project
API. Cada grupo de usuários é então vinculado a um projeto específico durante a criação do grupo de usuários. Três configurações de fluxo padrão são definidas no Modelo de aplicativo sem servidor da AWS (AWS SAM) modelo de infraestrutura:
- Padrão -
JobStreamShardCount
- Prioridade -
PriorityJobStreamShardCount
- Prioridade máxima -
HighPriorityJobStreamShardCount
A equipe usou algumas alavancas diferentes para diferenciar o poder de processamento de cada fluxo ou ajustar a latência do sistema, conforme resumido na tabela a seguir.
Alavanca | Descrição | Valor padrão |
Estilhaço | Um estilhaço é nativo do Kinesis Data Streams; é a unidade básica de taxa de transferência para ingestão. O padrão é 1 MB/s, o que equivale a 1,000 registros de dados por segundo. | 2 |
KinesisBatchSize |
O número máximo de registros que o Kinesis Data Streams recupera em um único lote antes de invocar a função do Lambda do consumidor. | 1 |
KinesisParallelizationFactor |
O número de lotes a serem processados de cada estilhaço simultaneamente. | 1 |
Fan-out aprimorado | Os consumidores de dados que ativaram a distribuição aprimorada têm uma taxa de transferência de ingestão dedicada por consumidor (como o padrão de 1 MB/s) em vez de compartilhar a taxa de transferência entre os consumidores. | Off |
Função Lambda do consumidor
Da perspectiva do Kinesis Data Streams, um consumidor de dados é um serviço da AWS que recupera dados de um fragmento de fluxo de dados à medida que os dados são gerados em um fluxo. Esse aplicativo usa uma função Consumer Lambda, que é invocada quando as mensagens são transmitidas das filas de fluxo de dados. Cada função Consumidor processa um lote de quadros executando as etapas a seguir. Primeiro, é feita uma chamada para a API do processador Cortex de forma síncrona, que é o endpoint que hospeda o pipeline de inferência do modelo (consulte a próxima seção sobre Amazon EKS com Cortex para obter mais detalhes). Os resultados são armazenados no Amazon S3 e uma atualização é feita no banco de dados alterando o status do lote de quadros processado para Complete
. O tratamento de erros é integrado para gerenciar a chamada da API Cortex com um loop de repetição para lidar com quaisquer erros 504 do cluster Cortex, com o número de tentativas definido como 5.
Amazon EKS com Cortex para inferência de ML
A equipe usou o Amazon EKS, um serviço gerenciado do Kubernetes na AWS, como mecanismo de computação para inferência de ML. Foi feita uma escolha de design para usar o Amazon EKS para hospedar endpoints de ML, oferecendo a flexibilidade de executar Kubernetes upstream com a opção de clusters totalmente gerenciados na AWS via AWS Fargate, ou hardware local por meio de Amazon EKS em qualquer lugar. Essa era uma funcionalidade crítica desejada pela Intel OTG, que oferecia a opção de conectar esse aplicativo a hardware local especializado, por exemplo.
Os três modelos de ML que foram os blocos de construção para a construção dos pipelines de inferência foram um modelo Yolo personalizado (para detecção de objetos), um modelo HRNet personalizado (para estimativa de pose 2D) e um modelo 3DMPPE (para estimativa de pose 3D) (consulte o anterior seção ML para mais detalhes). Eles usaram o código aberto Córtex biblioteca para lidar com a implantação e o gerenciamento de endpoints de pipeline de inferência de ML e o lançamento e a implantação dos clusters do Amazon EKS. Cada um desses modelos foi empacotado em contêineres do Docker — os arquivos de modelo foram armazenados no Amazon S3 e as imagens de modelo foram armazenadas em Registro do Amazon Elastic Container (Amazon ECR)—e implantado como APIs Cortex Realtime. As versões dos contêineres de modelo que são executados em CPU e GPU foram criadas para fornecer flexibilidade para o tipo de hardware de computação. No futuro, se modelos adicionais ou pipelines de modelo precisarem ser adicionados, eles poderão simplesmente criar APIs Cortex Realtime adicionais.
Em seguida, eles construíram pipelines de inferência compondo as APIs de modelo Cortex Realtime em APIs de pipeline Cortex Realtime. Uma única API de pipeline em tempo real consistia em chamar uma sequência de APIs de modelo em tempo real. As funções Consumer Lambda trataram um pipeline
API como uma caixa preta, usando uma única chamada de API para recuperar a saída de inferência final de uma imagem. Dois pipelines foram criados: um pipeline 2D e um pipeline 3D.
O pipeline 2D combina uma etapa de pré-processamento de decodificação, detecção de objetos usando um modelo Yolo personalizado para localizar o atleta e produzir caixas delimitadoras e, finalmente, um modelo HRNet personalizado para criar pontos-chave 2D para estimativa de pose.
O pipeline 3D combina uma etapa de pré-processamento de decodificação, detecção de objetos usando um modelo Yolo personalizado para localizar o atleta e produzir caixas delimitadoras e, finalmente, um modelo 3DMPPE para criar pontos-chave 3D para estimativa de pose.
Depois de gerar inferências em um lote de quadros, cada pipeline também inclui um endpoint de pós-processamento Realtime Cortex separado que gera três saídas principais:
- Dados agregados de pontos-chave do corpo em um único arquivo CSV
- Cálculos BMA (como aceleração)
- Sobreposição visual de pontos-chave adicionados a cada quadro em um arquivo de imagem
A função Collector Lambda envia os metadados apropriados associados a um vídeo específico, como os IDs de quadro e os locais S3 das saídas de inferência de estimativa de pose, ao endpoint para gerar essas saídas de pós-processamento.
O Cortex foi projetado para ser integrado ao Amazon EKS e requer apenas um arquivo de configuração de cluster e um comando simples para iniciar um cluster Kubernetes:
Outra alavanca para ajuste de desempenho foi a configuração de instância para os clusters de computação. Três camadas foram criadas com combinações variadas de instâncias M5 e G4dn, codificadas como arquivos .yaml com especificações como nome do cluster, região e configuração e combinação da instância. As instâncias M5 são baseadas em CPU de custo mais baixo e G4dn são baseadas em GPU de custo mais alto para fornecer algumas compensações de custo/desempenho.
Monitoramento operacional
Para manter os padrões operacionais de log, todas as funções do Lambda incluem código para gravar e ingerir logs por meio de Mangueira de incêndio de dados do Amazon Kinesis. Por exemplo, cada lote de quadro processado pela função do Lambda do remetente é registrado com o carimbo de data/hora, o nome da ação e o JSON de resposta da função do Lambda e salvo no Amazon S3. O diagrama a seguir ilustra essa etapa na arquitetura.
desenvolvimento
A implantação é feita usando o AWS SAM, uma estrutura de código aberto para criar aplicativos sem servidor na AWS. O AWS SAM permite que o projeto de infraestrutura, incluindo funções, APIs, bancos de dados e mapeamentos de origem de eventos, seja codificado e facilmente implantado em novos ambientes da AWS. Durante a implantação, a sintaxe do AWS SAM é traduzida em Formação da Nuvem AWS para lidar com o provisionamento de infraestrutura.
A template.yaml
contém as especificações de infraestrutura junto com parâmetros ajustáveis, como alavancas de latência do Kinesis Data Streams detalhadas nas seções anteriores. UMA samconfig.toml
O arquivo contém parâmetros de implantação, como nome da pilha, nome do bucket do S3 onde os arquivos do aplicativo, como o código de função do Lambda, são armazenados e tags de recursos para acompanhamento de custo. Um script de shell deploy.sh com os comandos simples é tudo o que é necessário para construir e implantar todo o modelo:
Fluxo de trabalho do usuário
Resumindo, após a implantação da infraestrutura, você pode seguir este fluxo de trabalho para começar:
- Crie um cliente Intel 3DAT usando a biblioteca cliente.
- Use a API para criar uma nova instância de um pipeline correspondente ao tipo de processamento necessário, como um para estimativa de pose 3D.
- Crie uma nova instância de um projeto, passando o ARN do cluster e o ARN da fila do Kinesis.
- Crie uma nova instância de um conjunto de parâmetros de pipeline.
- Crie uma nova instância de parâmetros de pipeline que mapeiam para o conjunto de parâmetros de pipeline.
- Crie um novo grupo de usuários associado a uma ID de projeto e a uma ID de conjunto de parâmetros de pipeline.
- Crie um novo usuário associado ao grupo de usuários.
- Faça upload de um arquivo .zip de vídeos para o Amazon S3 usando um URL do S3 pré-assinado gerado pela função de upload na API do trabalho.
- Envie um
create_job
Chamada de API, com parâmetros de trabalho que especificam a localização dos arquivos de vídeo. Isso inicia o trabalho de processamento.
Conclusão
O aplicativo já está ativo e pronto para ser testado com atletas e treinadores. A Intel OTG está entusiasmada em tornar a tecnologia inovadora de estimativa de pose usando visão computacional acessível para uma variedade de usuários, de desenvolvedores a atletas e parceiros de fornecedores de software.
A equipe da AWS é apaixonada por ajudar clientes como o Intel OTG a acelerar sua jornada de ML, desde o estágio de concepção e descoberta com o ML Solutions Lab até o estágio de fortalecimento e implantação com o AWS ML ProServe. Todos estaremos assistindo de perto as Olimpíadas de Tóquio de 2021 neste verão para visualizar todo o progresso que o ML pode desbloquear nos esportes.
Comece hoje! Explore seu caso de uso com os serviços mencionados neste post e muitos outros no Console de gerenciamento da AWS.
Sobre os autores
Homem Han é gerente sênior de aprendizado de máquina e IA na AWS com sede em San Diego, CA. Ele é PhD em engenharia pela Northwestern University e tem vários anos de experiência como consultor de gestão, assessorando clientes em manufatura, serviços financeiros e energia. Hoje, ele trabalha apaixonadamente com clientes de diversos setores para desenvolver e implementar soluções de machine learning e IA na AWS. Ele gosta de seguir a NBA e jogar basquete em seu tempo livre.
Iman Kamyabi é engenheiro de ML com AWS Professional Services. Ele trabalhou com uma ampla gama de clientes da AWS para defender as melhores práticas na configuração de pipelines de ML repetíveis e confiáveis.
Jonathan Lee é o Diretor de Tecnologia de Desempenho Esportivo, Grupo de Tecnologia Olímpica da Intel. Ele estudou a aplicação do aprendizado de máquina à saúde durante sua graduação na UCLA e durante seu trabalho de graduação na University of Oxford. Sua carreira se concentrou no desenvolvimento de algoritmos e sensores para saúde e desempenho humano. Ele agora lidera o projeto 3D Athlete Tracking na Intel.
Nelson Leung é arquiteto de plataforma no Sports Performance CoE da Intel, onde define a arquitetura de ponta a ponta para produtos de ponta que melhoram o desempenho do atleta. Ele também lidera a implementação, implantação e produção dessas soluções de aprendizado de máquina em escala para diferentes parceiros da Intel.
Troy Squillaci é engenheiro de DecSecOps na Intel, onde oferece soluções de software profissionais para clientes por meio das práticas recomendadas de DevOps. Ele gosta de integrar soluções de IA em plataformas escaláveis em vários domínios.
Paulo Min é um estagiário de arquiteto de soluções associado na Amazon Web Services (AWS), onde ajuda clientes em diferentes verticais do setor a avançar em sua missão e acelerar a adoção da nuvem. Anteriormente na Intel, ele trabalhou como estagiário de engenharia de software para ajudar a desenvolver o 3D Athlete Tracking Cloud SDK. Fora do trabalho, Paul gosta de jogar golfe e pode ser ouvido cantando.
- 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/the-intel3d-athlete-tracking-3dat-scalable-architecture-deploys-pose-estimation-models-using-amazon-kinesis-data-streams- e-amazon-eks/
- "
- &
- 000
- 100
- 2021
- 3d
- Sobre
- acelerar
- Acesso
- acessível
- Segundo
- Conta
- em
- Açao Social
- ações
- Adição
- Adicional
- admin
- Adoção
- AI
- algoritmo
- Todos os Produtos
- Amazon
- Amazon Web Services
- entre
- api
- APIs
- Aplicação
- aplicações
- apropriado
- arquitetura
- argumentos
- atribuído
- Jurídico
- atletas
- atributos
- Automático
- AWS
- backup
- Basquetebol
- antes
- Benefícios
- MELHOR
- melhores práticas
- Preto
- Blog
- corpo
- Caixa
- construir
- Prédio
- chamada
- Capacidade
- Cuidado
- Oportunidades
- casos
- central
- campeão
- alterar
- escolhas
- clientes
- Na nuvem
- código
- coleção
- coletor
- combinado
- componente
- Computar
- computador
- Configuração
- da conexão
- consultor
- consumidor
- Consumidores
- Recipiente
- Containers
- contém
- continua
- ao controle
- coordenar
- núcleo
- Correspondente
- crio
- criado
- cria
- Criar
- criação
- Credenciais
- crítico
- crucial
- Atual
- Atualmente
- personalizadas
- cliente
- Clientes
- ponta
- dados,
- banco de dados
- bases de dados
- dia
- dedicado
- mais profunda
- entrega
- implantar
- implantado
- desenvolvimento
- implanta
- Design
- projetado
- detalhe
- detalhado
- detalhes
- Detecção
- desenvolver
- Developer
- desenvolvedores
- Desenvolvimento
- diferente
- diferenciar
- diretamente
- Diretor
- descoberta
- monitores
- Estivador
- Não faz
- domínios
- down
- durante
- facilmente
- Ponto final
- energia
- Motor
- engenheiro
- Engenharia
- Meio Ambiente
- Evento
- exemplo
- animado
- existente
- espera
- vasta experiência
- explorar
- Característica
- Finalmente
- financeiro
- serviços financeiros
- Primeiro nome
- caber
- ANIMARIS
- Flexibilidade
- flexível
- focado
- seguir
- seguinte
- segue
- formato
- voltado para o futuro
- QUADRO
- Quadro
- função
- funcional
- funcionalidade
- funções
- futuro
- gerar
- gerando
- geração
- Dando
- meta
- Bom estado, com sinais de uso
- GPU
- pós-graduação
- Grupo
- Do grupo
- manipular
- Manipulação
- Hardware
- Saúde
- ouviu
- ajudar
- ajuda
- ajuda
- SUA PARTICIPAÇÃO FAZ A DIFERENÇA
- superior
- Como funciona o dobrador de carta de canal
- HTTPS
- humano
- Dados de identificação:
- imagem
- executar
- implementação
- importante
- incluir
- inclui
- Incluindo
- Individual
- indústrias
- indústria
- Infraestrutura
- inovadores
- entrada
- Inserções
- instalar
- integrado
- integração
- Intel
- Inteligência
- interação
- Interface
- IT
- Trabalho
- Empregos
- viagem
- Chave
- laboratório
- lançamento
- de lançamento
- Leads
- aprendizagem
- Nível
- Biblioteca
- Line
- Lista
- carregamento
- localização
- locais
- máquina
- aprendizado de máquina
- moldadas
- a manter
- principal
- FAZ
- homem
- gerencia
- gerenciados
- de grupos
- fabrica
- mapa,
- mapeamento
- mencionado
- métodos
- Métrica
- mínimo
- Missão
- ML
- Móvel Esteira
- Aplicações móveis
- modelo
- modelos
- modulares
- mais
- a maioria
- múltiplo
- nomes
- NBA
- necessário
- Cria
- número
- Jogos Olímpicos
- abre
- operar
- otimizado
- Opção
- ordem
- Outros
- próprio
- Oxford
- pacote
- parte
- particular
- particularmente
- Parceiros
- Passagem
- apaixonado
- padrão
- percentagem
- atuação
- realização
- perspectiva
- peça
- plataforma
- Plataformas
- jogar
- Poesia
- pontos
- possível
- poder
- poderoso
- Preparar
- anterior
- primário
- princípio
- prioridade
- processo
- processos
- em processamento
- Subcontratante
- produzir
- Produção
- Produtos
- profissional
- projeto
- fornecer
- fornece
- propósito
- alcance
- Cru
- em tempo real
- reconhecer
- registro
- registros
- em relação a
- confiável
- pedidos
- requerer
- requeridos
- Requisitos
- exige
- recurso
- Recursos
- resposta
- Resultados
- Execute
- corrida
- Segurança
- San
- AMPLIAR
- escalável
- Escala
- dimensionamento
- Sdk
- seguro
- segmentos
- Serverless
- serviço
- Serviços
- conjunto
- contexto
- Shape
- compartilhando
- concha
- mostrando
- semelhante
- Similarmente
- simples
- Tamanho
- So
- Software
- software como serviço
- Engenharia de software
- solução
- Soluções
- alguns
- Alguém
- especializado
- especificações
- velocidade
- Esportes
- pilha
- Etapa
- padrão
- padrões
- começo
- começado
- começa
- Estado
- estado-da-arte
- Status
- armazenamento
- loja
- transmitir canais
- de streaming
- apresentado
- Subseqüentemente
- verão
- ajuda
- suportes
- .
- tomar
- Profissionais
- Equipar
- ensaio
- assim sendo
- Através da
- GRAVATA
- tempo
- hoje
- juntos
- Tóquio
- pista
- Rastreamento
- tipos
- tipicamente
- UCLA
- universidade
- Universidade de Oxford
- destravar
- Atualizar
- usar
- usuários
- Utilizando
- valor
- variedade
- vário
- Verticais
- Vídeo
- VÍDEOS
- visão
- web
- serviços web
- QUEM
- sem
- Atividades:
- trabalhou
- trabalhar
- anos